summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2025-11-04drm/etnaviv: add HWDB entry for GC8000 Nano Ultra VIP r6205Marek Vasut
This is the GPU/NPU combined device found on the ST STM32MP25 SoC. Feature bits taken from the downstream kernel driver 6.4.21. Signed-off-by: Marek Vasut <marek.vasut@mailbox.org> Acked-by: Christian Gmeiner <cgmeiner@igalia.com> Signed-off-by: Christian Gmeiner <cgmeiner@igalia.com> Link: https://patch.msgid.link/20250919183042.273687-1-marek.vasut@mailbox.org
2025-11-04drm/displayid: add quirk to ignore DisplayID checksum errorsJani Nikula
Add a mechanism for DisplayID specific quirks, and add the first quirk to ignore DisplayID section checksum errors. It would be quite inconvenient to pass existing EDID quirks from drm_edid.c for DisplayID parsing. Not all places doing DisplayID iteration have the quirks readily available, and would have to pass it in all places. Simply add a separate array of DisplayID specific EDID quirks. We do end up checking it every time we iterate DisplayID blocks, but hopefully the number of quirks remains small. There are a few laptop models with DisplayID checksum failures, leading to higher refresh rates only present in the DisplayID blocks being ignored. Add a quirk for the panel in the machines. Reported-by: Tiago Martins Araújo <tiago.martins.araujo@gmail.com> Closes: https://lore.kernel.org/r/CACRbrPGvLP5LANXuFi6z0S7XMbAG4X5y2YOLBDxfOVtfGGqiKQ@mail.gmail.com Closes: https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/14703 Acked-by: Alex Deucher <alexander.deucher@amd.com> Tested-by: Tiago Martins Araújo <tiago.martins.araujo@gmail.com> Cc: stable@vger.kernel.org Link: https://patch.msgid.link/c04d81ae648c5f21b3f5b7953f924718051f2798.1761681968.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2025-11-04drm/edid: add DRM_EDID_IDENT_INIT() to initialize struct drm_edid_identJani Nikula
Add a convenience helper for initializing struct drm_edid_ident. Cc: Tiago Martins Araújo <tiago.martins.araujo@gmail.com> Acked-by: Alex Deucher <alexander.deucher@amd.com> Tested-by: Tiago Martins Araújo <tiago.martins.araujo@gmail.com> Cc: stable@vger.kernel.org Link: https://patch.msgid.link/710b2ac6a211606ec1f90afa57b79e8c7375a27e.1761681968.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2025-11-04drm/displayid: pass iter to drm_find_displayid_extension()Jani Nikula
It's more convenient to pass iter than a handful of its members to drm_find_displayid_extension(), especially as we're about to add another member. Rename the function find_next_displayid_extension() while at it, to be more descriptive. Cc: Tiago Martins Araújo <tiago.martins.araujo@gmail.com> Acked-by: Alex Deucher <alexander.deucher@amd.com> Tested-by: Tiago Martins Araújo <tiago.martins.araujo@gmail.com> Cc: stable@vger.kernel.org Link: https://patch.msgid.link/3837ae7f095e77a082ac2422ce2fac96c4f9373d.1761681968.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2025-11-04drm/hyperv: include drm_print.h where neededJani Nikula
hyperv_drm_drv.c and hyperv_drm_modeset.c depend on drm_print.h being indirectly included via drm_buddy.h, drm_mm.h, or ttm/ttm_resource.h. Include drm_print.h explicitly. Reported-by: Stephen Rothwell <sfr@canb.auug.org.au> Closes: https://lore.kernel.org/r/20251104101158.1cc9abcd@canb.auug.org.au Fixes: f6e8dc9edf96 ("drm: include drm_print.h where needed") Cc: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de> Link: https://patch.msgid.link/20251104100253.646577-1-jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2025-11-04drm/vkms: Update testing with IGT IGT_DEVICEJosé Expósito
VKMS is no longer in the platform bus, instead, it is in the faux bus. In addition, when present, IGT picks hardware drivers instead of virtual drivers, like VKMS or vgem, if they are not forced. Update the documentation to use IGT_FORCE_DRIVER instead of IGT_DEVICE. Signed-off-by: José Expósito <jose.exposito89@gmail.com> Reviewed-by: Louis Chauvet <louis.chauvet@bootlin.com> Link: https://lore.kernel.org/r/20251024110014.4614-2-jose.exposito89@gmail.com Signed-off-by: Louis Chauvet <louis.chauvet@bootlin.com>
2025-11-04drm/vkms: Fix run-tests.sh script nameJosé Expósito
The script is "run-tests.sh", no "run-test.sh". Signed-off-by: José Expósito <jose.exposito89@gmail.com> Reviewed-by: Louis Chauvet <louis.chauvet@bootlin.com> Link: https://lore.kernel.org/r/20251024110014.4614-1-jose.exposito89@gmail.com Signed-off-by: Louis Chauvet <louis.chauvet@bootlin.com>
2025-11-04drm/vkms: Fix use after frees on error pathsDan Carpenter
These error paths free a pointer and then dereference it on the next line to get the error code. Save the error code first and then free the memory. Fixes: 3e4d5b30d2b2 ("drm/vkms: Allow to configure multiple CRTCs via configfs") Fixes: 2f1734ba271b ("drm/vkms: Allow to configure multiple planes via configfs") Fixes: 67d8cf92e13e ("drm/vkms: Allow to configure multiple encoders via configfs") Fixes: 272acbca96a3 ("drm/vkms: Allow to configure multiple connectors via configfs") Fixes: 13fc9b9745cc ("drm/vkms: Add and remove VKMS instances via configfs") Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org> Reviewed-by: José Expósito <jose.exposito89@gmail.com> Link: https://lore.kernel.org/r/aPtfy2jCI_kb3Df7@stanley.mountain Signed-off-by: Louis Chauvet <louis.chauvet@bootlin.com>
2025-11-03accel/amdxdna: Use MSG_OP_CHAIN_EXEC_NPU when supportedLizhi Hou
MSG_OP_CHAIN_EXEC_NPU is a unified mailbox message that replaces MSG_OP_CHAIN_EXEC_BUFFER_CF and MSG_OP_CHAIN_EXEC_DPU. Add driver logic to check firmware version, and if MSG_OP_CHAIN_EXEC_NPU is supported, uses it to submit firmware commands. Reviewed-by: Mario Limonciello (AMD) <superm1@kernel.org> Signed-off-by: Lizhi Hou <lizhi.hou@amd.com> Link: https://patch.msgid.link/20251031014700.2919349-1-lizhi.hou@amd.com
2025-11-03drm/panthor: Use existing OPP table if presentNicolas Frattaroli
On SoCs where the GPU's power-domain is in charge of setting performance levels, the OPP table of the GPU node will have already been populated during said power-domain's attach_dev operation. To avoid initialising an OPP table twice, only set the OPP regulator and the OPPs from DT if there's no OPP table present. Reviewed-by: Chia-I Wu <olvaffe@gmail.com> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Reviewed-by: Steven Price <steven.price@arm.com> Reviewed-by: Liviu Dudau <liviu.dudau@arm.com> Signed-off-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com> Link: https://patch.msgid.link/20251017-mt8196-gpufreq-v8-4-98fc1cc566a1@collabora.com Signed-off-by: Liviu Dudau <liviu.dudau@arm.com>
2025-11-03drm/panthor: call into devfreq for current frequencyNicolas Frattaroli
As it stands, panthor keeps a cached current frequency value for when it wants to retrieve it. This doesn't work well for when things might switch frequency without panthor's knowledge. Instead, implement the get_cur_freq operation, and expose it through a helper function to the rest of panthor. Reviewed-by: Chia-I Wu <olvaffe@gmail.com> Reviewed-by: Steven Price <steven.price@arm.com> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Reviewed-by: Karunika Choo <karunika.choo@arm.com> Reviewed-by: Liviu Dudau <liviu.dudau@arm.com> Signed-off-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com> Link: https://patch.msgid.link/20251017-mt8196-gpufreq-v8-3-98fc1cc566a1@collabora.com Signed-off-by: Liviu Dudau <liviu.dudau@arm.com>
2025-11-03dt-bindings: gpu: mali-valhall-csf: add mediatek,mt8196-mali variantNicolas Frattaroli
The Mali-based GPU on the MediaTek MT8196 SoC uses a separate MCU to control the power and frequency of the GPU. This is modelled as a power domain and clock provider. It lets us omit the OPP tables from the device tree, as those can now be enumerated at runtime from the MCU. Add the necessary schema logic to handle what this SoC expects in terms of clocks and power-domains. Reviewed-by: Rob Herring (Arm) <robh@kernel.org> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Reviewed-by: Liviu Dudau <liviu.dudau@arm.com> Signed-off-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com> Link: https://patch.msgid.link/20251017-mt8196-gpufreq-v8-1-98fc1cc566a1@collabora.com Signed-off-by: Liviu Dudau <liviu.dudau@arm.com>
2025-11-03arm64: dts: imx95: Describe Mali G310 GPUMarek Vasut
The instance of the GPU populated in i.MX95 is the G310, describe this GPU in the DT. Include dummy GPU voltage regulator and OPP tables. Reviewed-by: Frank Li <Frank.Li@nxp.com> Signed-off-by: Marek Vasut <marek.vasut@mailbox.org> Link: https://patch.msgid.link/20251102160927.45157-2-marek.vasut@mailbox.org Signed-off-by: Liviu Dudau <liviu.dudau@arm.com>
2025-11-03dt-bindings: gpu: mali-valhall-csf: Document i.MX95 supportMarek Vasut
The instance of the GPU populated in Freescale i.MX95 is the Mali G310, document support for this variant. Reviewed-by: Alexander Stein <alexander.stein@ew.tq-group.com> Reviewed-by: Frank Li <Frank.Li@nxp.com> Reviewed-by: Rob Herring (Arm) <robh@kernel.org> Signed-off-by: Marek Vasut <marek.vasut@mailbox.org> Link: https://patch.msgid.link/20251102160927.45157-1-marek.vasut@mailbox.org Signed-off-by: Liviu Dudau <liviu.dudau@arm.com>
2025-11-03drm/panthor: attach the driver's multiple power domainsRain Yang
Some platforms, such as i.MX95, utilize multiple power domains that need to be attached explicitly. This patch ensures that the driver properly attaches all available power domains using devm_pm_domain_attach_list(). Suggested-by: Boris Brezillon <boris.brezillon@collabora.com> Suggested-by: Steven Price <steven.price@arm.com> Signed-off-by: Prabhu Sundararaj <prabhu.sundararaj@nxp.com> Signed-off-by: Rain Yang <jiyu.yang@nxp.com> Reviewed-by: Liviu Dudau <liviu.dudau@arm.com> Link: https://patch.msgid.link/20251022092604.181752-1-jiyu.yang@oss.nxp.com Signed-off-by: Liviu Dudau <liviu.dudau@arm.com>
2025-11-03drm/panthor: Fix UAF on kernel BO VA nodesBoris Brezillon
If the MMU is down, panthor_vm_unmap_range() might return an error. We expect the page table to be updated still, and if the MMU is blocked, the rest of the GPU should be blocked too, so no risk of accessing physical memory returned to the system (which the current code doesn't cover for anyway). Proceed with the rest of the cleanup instead of bailing out and leaving the va_node inserted in the drm_mm, which leads to UAF when other adjacent nodes are removed from the drm_mm tree. Reported-by: Lars-Ivar Hesselberg Simonsen <lars-ivar.simonsen@arm.com> Closes: https://gitlab.freedesktop.org/panfrost/linux/-/issues/57 Fixes: 8a1cc07578bf ("drm/panthor: Add GEM logical block") Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com> Reviewed-by: Liviu Dudau <liviu.dudau@arm.com> Link: https://patch.msgid.link/20251031154818.821054-2-boris.brezillon@collabora.com Signed-off-by: Liviu Dudau <liviu.dudau@arm.com>
2025-11-03drm/panthor: Fix race with suspend during unplugKetil Johnsen
There is a race between panthor_device_unplug() and panthor_device_suspend() which can lead to IRQ handlers running on a powered down GPU. This is how it can happen: - unplug routine calls drm_dev_unplug() - panthor_device_suspend() can now execute, and will skip a lot of important work because the device is currently marked as unplugged. - IRQs will remain active in this case and IRQ handlers can therefore try to access a powered down GPU. The fix is simply to take the PM ref in panthor_device_unplug() a little bit earlier, before drm_dev_unplug(). Signed-off-by: Ketil Johnsen <ketil.johnsen@arm.com> Fixes: 5fe909cae118a ("drm/panthor: Add the device logical block") Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com> Reviewed-by: Liviu Dudau <liviu.dudau@arm.com> Reviewed-by: Steven Price <steven.price@arm.com> Link: https://patch.msgid.link/20251022103242.1083311-1-ketil.johnsen@arm.com Signed-off-by: Liviu Dudau <liviu.dudau@arm.com>
2025-11-03drm/panthor: disable async work during unplugKetil Johnsen
A previous change, "drm/panthor: Fix UAF race between device unplug and FW event processing", fixes a real issue where new work was unexpectedly queued after cancellation. This was fixed by a disable instead. Apply the same disable logic to other device level async work on device unplug as a precaution. Signed-off-by: Ketil Johnsen <ketil.johnsen@arm.com> Reviewed-by: Liviu Dudau <liviu.dudau@arm.com> Link: https://patch.msgid.link/20251029111412.924104-1-ketil.johnsen@arm.com Signed-off-by: Liviu Dudau <liviu.dudau@arm.com>
2025-11-03drm/panthor: Fix UAF race between device unplug and FW event processingKetil Johnsen
The function panthor_fw_unplug() will free the FW memory sections. The problem is that there could still be pending FW events which are yet not handled at this point. process_fw_events_work() can in this case try to access said freed memory. Simply call disable_work_sync() to both drain and prevent future invocation of process_fw_events_work(). Signed-off-by: Ketil Johnsen <ketil.johnsen@arm.com> Fixes: de85488138247 ("drm/panthor: Add the scheduler logical block") Reviewed-by: Liviu Dudau <liviu.dudau@arm.com> Link: https://patch.msgid.link/20251027140217.121274-1-ketil.johnsen@arm.com Signed-off-by: Liviu Dudau <liviu.dudau@arm.com>
2025-11-03drm/panthor: Fix group_free_queue() for partially initialized queuesBoris Brezillon
group_free_queue() can be called on a partially initialized queue object if something fails in group_create_queue(). Make sure we don't call drm_sched_entity_destroy() on an entity that hasn't been initialized. Fixes: 7d9c3442b02a ("drm/panthor: Defer scheduler entitiy destruction to queue release") Reviewed-by: Adrián Larumbe <adrian.larumbe@collabora.com> Reviewed-by: Liviu Dudau <liviu.dudau@arm.com> Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com> Link: https://patch.msgid.link/20251031160318.832427-2-boris.brezillon@collabora.com Signed-off-by: Liviu Dudau <liviu.dudau@arm.com>
2025-11-03drm/panthor: Handle errors returned by drm_sched_entity_init()Boris Brezillon
In practice it's not going to fail because we're passing the current sanity checks done by drm_sched_entity_init(), and that's the only reason it would return an error, but better safe than sorry. Fixes: de8548813824 ("drm/panthor: Add the scheduler logical block") Reviewed-by: Liviu Dudau <liviu.dudau@arm.com> Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com> Link: https://patch.msgid.link/20251031160318.832427-1-boris.brezillon@collabora.com Signed-off-by: Liviu Dudau <liviu.dudau@arm.com>
2025-11-03drm/rockchip: include drm_print.h where neededJani Nikula
rockchip_drm_vop2.c depends on drm_print.h being indirectly included via drm_buddy.h, drm_mm.h, or ttm/ttm_resource.h. Include drm_print.h explicitly. Reported-by: Thomas Zimmermann <tzimmermann@suse.de> Closes: https://lore.kernel.org/r/9c67c29b-06e9-469b-9273-eaac368632d6@suse.de Fixes: f6e8dc9edf96 ("drm: include drm_print.h where needed") Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de> Link: https://patch.msgid.link/59277a2dd7939ef5fe6e8fc61311873775141ef8.1762161597.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2025-11-03drm/renesas: include drm_print.h where neededJani Nikula
rzg2l_du_drv.c depends on drm_print.h being indirectly included via drm_buddy.h, drm_mm.h, or ttm/ttm_resource.h. Include drm_print.h explicitly. Reported-by: Stephen Rothwell <sfr@canb.auug.org.au> Closes: https://lore.kernel.org/r/20251103112418.031b3f8c@canb.auug.org.au Fixes: f6e8dc9edf96 ("drm: include drm_print.h where needed") Cc: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de> Link: https://patch.msgid.link/04f617d5fe37f92d750efbb73065df3997f5c6b5.1762161597.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2025-11-03drm/bridge: synopsys: dw-dp: add bridge before attachingLuca Ceresoli
DRM bridges should be always added to the global bridge list before being attached. Reviewed-by: Raphael Gallais-Pou <rgallaispou@gmail.com> Link: https://patch.msgid.link/20251028-b4-drm-bridge-alloc-add-before-attach-v3-6-bb8611acbbfb@bootlin.com Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
2025-11-03drm/bridge: add warning for bridges using neither devm_drm_bridge_alloc() ↵Luca Ceresoli
nor drm_bridge_add() The correct sequence for bridge initialization is: 1. devm_drm_bridge_alloc() 2. drm_bridge_add() 3. drm_bridge_attach() For bridges missing either 1 or 2 there are warnings in place already, presenting an explanatory error message. Bridges missing both 1 and 2 would still face a poorly understandable message, as reported in a recent regression report [0]: WARNING: [...] at [...]/lib/refcount.c:25 drm_bridge_attach+0x2c/0x1dc ... Call trace: ... drm_bridge_attach ... Add a new warning to ensure an understandable message is logged in such cases. Use the same message and warning message already in place in drm_bridge_add(). [0] https://lore.kernel.org/all/hlf4wdopapxnh4rekl5s3kvoi6egaga3lrjfbx6r223ar3txri@3ik53xw5idyh/ Reviewed-by: Maxime Ripard <mripard@kernel.org> Link: https://patch.msgid.link/20251028-b4-drm-bridge-alloc-add-before-attach-v3-5-bb8611acbbfb@bootlin.com Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
2025-11-03drm/bridge: add warning for bridges attached without being addedLuca Ceresoli
DRM bridges must be added before they are attached. Add a warning to catch violations. The warning is based on the bridge not being part of any list, so it will trigger if the bridge is being attached without ever having been added. It won't catch cases of bridges attached after having been added and then removed, because in that case the bridge will be in bridge_lingering_list. However such a case is both more demanding to detect and less likely to happen, so it can be left unchecked, at least for now. Suggested-by: Maxime Ripard <mripard@kernel.org> Link: https://lore.kernel.org/all/20250709-sophisticated-loon-of-rain-6ccdd8@houat/ Reviewed-by: Raphael Gallais-Pou <rgallaispou@gmail.com> Reviewed-by: Maxime Ripard <mripard@kernel.org> Link: https://patch.msgid.link/20251028-b4-drm-bridge-alloc-add-before-attach-v3-4-bb8611acbbfb@bootlin.com Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
2025-11-03drm/bridge: document that adding a bridge is mandatory before attachLuca Ceresoli
At the moment it's not documented that you need to add a bridge before attaching it. Clarify that. Suggested-by: Maxime Ripard <mripard@kernel.org> Link: https://lore.kernel.org/all/20250709-sophisticated-loon-of-rain-6ccdd8@houat/ Reviewed-by: Raphael Gallais-Pou <rgallaispou@gmail.com> Reviewed-by: Maxime Ripard <mripard@kernel.org> Link: https://patch.msgid.link/20251028-b4-drm-bridge-alloc-add-before-attach-v3-3-bb8611acbbfb@bootlin.com Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
2025-11-03drm/sti: hdmi: add bridge before attachingLuca Ceresoli
DRM bridges should be always added to the global bridge list before being attached. Acked-by: Raphael Gallais-Pou <rgallaispou@gmail.com> Acked-by: Alain Volmat <alain.volmat@foss.st.com> Link: https://patch.msgid.link/20251028-b4-drm-bridge-alloc-add-before-attach-v3-2-bb8611acbbfb@bootlin.com Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
2025-11-03drm/sti: hda: add bridge before attachingLuca Ceresoli
DRM bridges should be always added to the global bridge list before being attached. Acked-by: Raphael Gallais-Pou <rgallaispou@gmail.com> Acked-by: Alain Volmat <alain.volmat@foss.st.com> Link: https://patch.msgid.link/20251028-b4-drm-bridge-alloc-add-before-attach-v3-1-bb8611acbbfb@bootlin.com Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
2025-11-03drm/display: bridge_connector: get/put the panel_bridgeLuca Ceresoli
The panel_bridge pointer is taken inside the loop and used after the loop. Being a local variable, use a cleanup action to ensure it is put on return. Based on the code structure the panel_bridge pointer might be assigned during multiple loop iterations. Even though this is probably not possible in the practice, ensure there is no reference leak by putting the reference to the old value before overwriting with the new value. Reviewed-by: Louis Chauvet <louis.chauvet@bootlin.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Tested-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> # db410c Tested-by: Geert Uytterhoeven <geert+renesas@glider.be> Tested-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com> Tested-by: Tommaso Merciai <tommaso.merciai.xr@bp.renesas.com> Tested-by: Marek Szyprowski <m.szyprowski@samsung.com> Link: https://patch.msgid.link/20251017-drm-bridge-alloc-getput-bridge-connector-fix-hdmi_cec-v2-3-667abf6d47c0@bootlin.com Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
2025-11-03drm/display: bridge_connector: get/put the stored bridgesLuca Ceresoli
drm_bridge_connector_init() takes eight pointers to various bridges, some of which can be identical, and stores them in pointers inside struct drm_bridge_connector. Get a reference to each of the taken bridges and put it on cleanup. Achieve this by adding a drmm cleanup callback whic puts all the non-NULL bridges. Using drmm ensures the cleanup happens on drm_device teardown, whichever is the return value of this function. Four of these pointers (edid, hpd, detect and modes) can be written multiple times (up to once per loop iterations), in order to eventually store the last matching bridge. So when one of those pointers is overwritten, we need to put the reference that we got during the previous assignment. Add a drm_bridge_put() before writing them to handle this. Reviewed-by: Louis Chauvet <louis.chauvet@bootlin.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Tested-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> # db410c Tested-by: Geert Uytterhoeven <geert+renesas@glider.be> Tested-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com> Tested-by: Tommaso Merciai <tommaso.merciai.xr@bp.renesas.com> Tested-by: Marek Szyprowski <m.szyprowski@samsung.com> Link: https://patch.msgid.link/20251017-drm-bridge-alloc-getput-bridge-connector-fix-hdmi_cec-v2-2-667abf6d47c0@bootlin.com Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
2025-11-03Revert "drm/display: bridge_connector: get/put the stored bridges"Luca Ceresoli
This reverts commit 2be300f9a0b6f6b0ae2a90be97e558ec0535be54. The commit being reverted moved all the bridge_connector->bridge_* assignments to just before the final successful return in order to handle the bridge refcounting in a clean way. This introduced a bug, because a bit before the successful return drmm_connector_hdmi_cec_register() is called, which calls funcs->init() which is drm_bridge_connector_hdmi_cec_init() which needs bridge_connector->bridge_hdmi_cec to be set. The reported bug may be fixed in a relatively simple way, but other similar patterns are potentially present, so just revert the offending commit. A different approach will be implemented. Fixes: 2be300f9a0b6 ("drm/display: bridge_connector: get/put the stored bridges") Reported-by: Marek Szyprowski <m.szyprowski@samsung.com> Closes: https://lore.kernel.org/all/336fbfdd-c424-490e-b5d1-8ee84043dc80@samsung.com/ Reported-by: Naresh Kamboju <naresh.kamboju@linaro.org> Closes: https://lore.kernel.org/r/CA+G9fYuKHp3QgPKjgFY3TfkDdh5Vf=Ae5pCW+eU41Bu=D7th2g@mail.gmail.com Reviewed-by: Louis Chauvet <louis.chauvet@bootlin.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Tested-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> # db410c Tested-by: Geert Uytterhoeven <geert+renesas@glider.be> Tested-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com> Tested-by: Tommaso Merciai <tommaso.merciai.xr@bp.renesas.com> Tested-by: Marek Szyprowski <m.szyprowski@samsung.com> Link: https://patch.msgid.link/20251017-drm-bridge-alloc-getput-bridge-connector-fix-hdmi_cec-v2-1-667abf6d47c0@bootlin.com Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
2025-10-31drm/tidss: Set vblank (event) time at crtc_atomic_enableTomi Valkeinen
It was reported that Weston stops at an assert, which checks that the page flip event timestamp is the same or newer than the previous timestamp: weston_output_finish_frame: Assertion `timespec_sub_to_nsec(stamp, &output->frame_time) >= 0' failed. With manual tests, I can see that when I enable the CRTC, I get a page flip event with a timestamp of 0. Tracking this down led to drm_reset_vblank_timestamp() which does "t_vblank = 0" if "high-precision query" is not available. TI DSS does not have any hardware timestamping, and thus the default ktime_get() is used in the DRM framework to get the vblank timestamp, and ktime_get() is not "high precision" here. It is not quite clear why the framework behaves this way, but I assume the idea is that drm_crtc_vblank_on(), which calls drm_reset_vblank_timestamp(), can be called at any time, and thus ktime_get() wouldn't give a good timestamp. And, the idea is that the driver would wait until next vblank after the CRTC enable, and then we could get a good timestamp. This is hinted in the comment: "reinitialize delayed at next vblank interrupt and assign 0 for now". I think that makes sense. However, when we enable the CRTC in TI DSS, i.e. we write the enable bit to the hardware, that's the exact moment when the "vblank cycle" starts. It is the zero point in the cycle, and thus ktime_get() would give a good timestamp. I am not sure if this is applicable to other hardware, and if so, how should it be solved in the framework. So, let's fix this in the tidss driver at least for now. This patch updates the vblank->time manually to ktime_get() just before sending the vblank event, and we enable the crtc just before calling ktime_get(). To get even more exact timing, the dispc_vp_enable() is moved inside the event_lock spinlock. With this, we get a proper timestamp for the page flip event from enabling the CRTC, and Weston is happy. Reviewed-by: Devarsh Thakkar <devarsht@ti.com> Link: https://patch.msgid.link/20250905-tidss-fix-timestamp-v1-2-c2aedf31e2c9@ideasonboard.com Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com> Closes: https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1553964/processor-sdk-am62x-weston-fails-to-wake-from-idle-time-sleep-restarts-after-sigterm Closes: https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1416342/am625-am625-doesn-t-wake-up-from-standy-when-idle-time-is-configured-in-weston-ini
2025-10-31drm/tidss: Restructure dispc_vp_prepare() and dispc_vp_enable()Tomi Valkeinen
tidss_crtc.c calls dispc_vp_prepare() and dispc_vp_enable() in that order, next to each other. dispc_vp_prepare() does preparations for enabling the crtc, by writing some registers, and dispc_vp_enable() does more preparations. As the last thing, dispc_vp_enable() enables the CRTC by writing the enable bit. There might have been a reason at some point in the history for this split, but I can't find any point to it. They also do a bit of overlapping work: both call dispc_vp_find_bus_fmt(). They could as well be a single function. But instead of combining them, this patch moves everything from dispc_vp_enable() to dispc_vp_prepare(), except the actual CRTC enable bit write. The reason for this is that unlike all the preparatory register writes, CRTC enable has an immediate effect, starting the timing generator and the CRTC as a whole. Thus it may be important to time the enable just right (as we do in the next patch). No functional changes. Reviewed-by: Devarsh Thakkar <devarsht@ti.com> Link: https://patch.msgid.link/20250905-tidss-fix-timestamp-v1-1-c2aedf31e2c9@ideasonboard.com Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
2025-10-31drm/sched: Add warning for removing hack in drm_sched_fini()Philipp Stanner
The assembled developers agreed at the X.Org Developers Conference 2025 that the hack added for amdgpu in drm_sched_fini() shall be removed. It shouldn't be needed by amdgpu anymore. As it's unclear whether all drivers really follow the life time rule of entities having to be torn down before their scheduler, it is reasonable to warn for a while before removing the hack. Add a warning in drm_sched_fini() that fires if an entity is still active. Acked-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com> Signed-off-by: Philipp Stanner <phasta@kernel.org> Link: https://patch.msgid.link/20251023123429.139848-2-phasta@kernel.org
2025-10-31drm/imagination: Fix reference to devm_platform_get_and_ioremap_resource()Geert Uytterhoeven
The call to devm_platform_ioremap_resource() was replaced by a call to devm_platform_get_and_ioremap_resource(), but the comment referring to the function's possible returned error codes was not updated. Fixes: 927f3e0253c11276 ("drm/imagination: Implement MIPS firmware processor and MMU support") Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Reviewed-by: Matt Coster <matt.coster@imgtec.com> Link: https://patch.msgid.link/2266514318480d17f52c7e5e67578dae6827914e.1761745586.git.geert+renesas@glider.be Signed-off-by: Matt Coster <matt.coster@imgtec.com>
2025-10-31dt-bindings: gpu: img,powervr-rogue: Drop duplicate newlineMarek Vasut
Fix the following DT schema check warning: ./Documentation/devicetree/bindings/gpu/img,powervr-rogue.yaml:103:1: [warning] too many blank lines (2 > 1) (empty-lines) One newline is enough. No functional change. Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org> Reviewed-by: Matt Coster <matt.coster@imgtec.com> Acked-by: Rob Herring (Arm) <robh@kernel.org> Link: https://patch.msgid.link/20251029194210.129326-1-marek.vasut+renesas@mailbox.org Signed-off-by: Matt Coster <matt.coster@imgtec.com>
2025-10-31drm/panel: ilitek-ili9882t: Add support for Ilitek IL79900A-based panelsLangyan Ye
The Ilitek IL79900A display controller is similar to the ILI9882T and can be supported within the existing `panel-ilitek-ili9882t.c` driver. This patch extends the ILI9882T driver to handle IL79900A-based panels, such as the Tianma TL121BVMS07-00. The IL79900A uses a similar command sequence and initialization flow, with minor differences in power supply configuration and timing. Signed-off-by: Langyan Ye <yelangyan@huaqin.corp-partner.google.com> Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org> Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org> Link: https://patch.msgid.link/20251031100447.253164-3-yelangyan@huaqin.corp-partner.google.com
2025-10-31dt-bindings: display: panel: Add Tianma TL121BVMS07-00 panelLangyan Ye
Add device tree bindings for the Tianma TL121BVMS07-00 12.1-inch MIPI-DSI TFT LCD panel. The panel is based on the Ilitek IL79900A controller. Signed-off-by: Langyan Ye <yelangyan@huaqin.corp-partner.google.com> Reviewed-by: Conor Dooley <conor.dooley@microchip.com> Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org> Link: https://patch.msgid.link/20251031100447.253164-2-yelangyan@huaqin.corp-partner.google.com
2025-10-31drm/sched: Fix comment in drm_sched_run_job_work()Philipp Stanner
drm_sched_run_job_work() contains a comment which explains that an entity being NULL means that there is no more work to do. It can, however, also mean that there is work, but the scheduler doesn't have enough credits to process the jobs right now. Provide this detail in the comment. Reviewed-by: Matthew Brost <matthew.brost@intel.com> Signed-off-by: Philipp Stanner <phasta@kernel.org> Link: https://patch.msgid.link/20251028134602.94125-3-phasta@kernel.org
2025-10-31drm/ttm: Add an allocation flag to propagate -ENOSPC on OOMTvrtko Ursulin
Some graphics APIs differentiate between out-of-graphics-memory and out-of-host-memory (system memory). Add a device init flag to have -ENOSPC propagated from the resource managers instead of being converted to -ENOMEM, to aid driver stacks in determining what error code to return or whether corrective action can be taken at the driver level. Co-developed-by: Thomas Hellström <thomas.hellstrom@linux.intel.com> Cc: Christian König <christian.koenig@amd.com> Cc: Matthew Brost <matthew.brost@intel.com> Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@igalia.com> Reviewed-by: Thomas Hellström <thomas.hellstrom@linux.intel.com> Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Tvrtko Ursulin <tursulin@ursulin.net> Link: https://lore.kernel.org/r/20251020115411.36818-7-tvrtko.ursulin@igalia.com
2025-10-31drm/amdgpu: Configure max beneficial TTM pool allocation orderTvrtko Ursulin
Let the TTM pool allocator know that we can afford for it to expend less effort for satisfying contiguous allocations larger than 2MiB. The latter is the maximum relevant PTE entry size and the driver and hardware are happy to get larger blocks only opportunistically. Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@igalia.com> Cc: Alex Deucher <alexander.deucher@amd.com> Cc: Christian König <christian.koenig@amd.com> Cc: Thadeu Lima de Souza Cascardo <cascardo@igalia.com> Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Tvrtko Ursulin <tursulin@ursulin.net> Link: https://lore.kernel.org/r/20251020115411.36818-6-tvrtko.ursulin@igalia.com
2025-10-31drm/ttm: Allow drivers to specify maximum beneficial TTM pool sizeTvrtko Ursulin
GPUs typically benefit from contiguous memory via reduced TLB pressure and improved caching performance, where the maximum size of contiguous block which adds a performance benefit is related to hardware design. TTM pool allocator by default tries (hard) to allocate up to the system MAX_PAGE_ORDER blocks. This varies by the CPU platform and can also be configured via Kconfig. If that limit was set to be higher than the GPU can make an extra use of, lets allow the individual drivers to let TTM know over which allocation order can the pool allocator afford to make a little bit less effort with. We implement this by disabling direct reclaim for those allocations, which reduces the allocation latency and lowers the demands on the page allocator, in cases where expending this effort is not critical for the GPU in question. Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@igalia.com> Cc: Christian König <christian.koenig@amd.com> Cc: Thadeu Lima de Souza Cascardo <cascardo@igalia.com> Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Tvrtko Ursulin <tursulin@ursulin.net> Link: https://lore.kernel.org/r/20251020115411.36818-5-tvrtko.ursulin@igalia.com
2025-10-31drm/ttm: Replace multiple booleans with flags in device initTvrtko Ursulin
Multiple consecutive boolean function arguments are usually not very readable. Replace the ones in ttm_device_init() with flags with the additional benefit of soon being able to pass in more data with just a one off code base churning cost. Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@igalia.com> Cc: Alex Deucher <alexander.deucher@amd.com> Cc: Christian König <christian.koenig@amd.com> Cc: Danilo Krummrich <dakr@kernel.org> Cc: Dave Airlie <airlied@redhat.com> Cc: Gerd Hoffmann <kraxel@redhat.com> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Lucas De Marchi <lucas.demarchi@intel.com> Cc: Lyude Paul <lyude@redhat.com> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Maxime Ripard <mripard@kernel.org> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Sui Jingfeng <suijingfeng@loongson.cn> Cc: Thomas Hellström <thomas.hellstrom@linux.intel.com> Cc: Thomas Zimmermann <tzimmermann@suse.de> Cc: Zack Rusin <zack.rusin@broadcom.com> Acked-by: Christian König <christian.koenig@amd.com> Acked-by: Zack Rusin <zack.rusin@broadcom.com> Acked-by: Thomas Hellström <thomas.hellstrom@linux.intel.com> # For xe Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Tvrtko Ursulin <tursulin@ursulin.net> Link: https://lore.kernel.org/r/20251020115411.36818-4-tvrtko.ursulin@igalia.com [tursulin: fixup checkpatch while applying]
2025-10-31drm/ttm: Replace multiple booleans with flags in pool initTvrtko Ursulin
Multiple consecutive boolean function arguments are usually not very readable. Replace the ones in ttm_pool_init() with flags with the additional benefit of soon being able to pass in more data with just this one code base churning cost. Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@igalia.com> Cc: Alex Deucher <alexander.deucher@amd.com> Cc: Christian König <christian.koenig@amd.com> Cc: Thomas Hellström <thomas.hellstrom@linux.intel.com> Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Tvrtko Ursulin <tursulin@ursulin.net> Link: https://lore.kernel.org/r/20251020115411.36818-3-tvrtko.ursulin@igalia.com
2025-10-31drm/ttm: Add getter for some pool propertiesTvrtko Ursulin
No functional change but to allow easier refactoring in the future. Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@igalia.com> Cc: Christian König <christian.koenig@amd.com> Cc: Thomas Hellström <thomas.hellstrom@linux.intel.com> Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Tvrtko Ursulin <tursulin@ursulin.net> Link: https://lore.kernel.org/r/20251020115411.36818-2-tvrtko.ursulin@igalia.com
2025-10-31drm/ttm: replace drm_print.h include with a forward declarationJani Nikula
The ttm/ttm_resource.h header does not really need anything from drm_print.h. A simple forward declaration for struct drm_printer is sufficient. An explicit drm_print.h include has previously been added to all the files that indirectly depended on this include. v3: Only remove the include here (Thomas) Cc: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://lore.kernel.org/r/cfdb1095033112c2a7e58767481c98929984a33c.1761734313.git.jani.nikula@intel.com
2025-10-31drm/mm: replace drm_print.h include with a forward declarationJani Nikula
The drm_mm.h header does not really need anything from drm_print.h. A simple forward declaration for struct drm_printer is sufficient. An explicit drm_print.h include has previously been added to all the files that indirectly depended on this include. v3: Only remove the include here (Thomas) Cc: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://lore.kernel.org/r/7d570ed1f0f0f14cac346bea50bce9ef02ddd166.1761734313.git.jani.nikula@intel.com
2025-10-31drm/buddy: replace drm_print.h include with a forward declarationJani Nikula
The drm_buddy.h header does not really need anything from drm_print.h. A simple forward declaration for struct drm_printer is sufficient. An explicit drm_print.h include has previously been added to all the files that indirectly depended on this include. v3: Only remove the include here (Thomas) Cc: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://lore.kernel.org/r/b303996b407fcbe2c7357bea036f79c45d6dae49.1761734313.git.jani.nikula@intel.com
2025-10-31drm: include drm_print.h where neededJani Nikula
There are a gazillion files that depend on drm_print.h being indirectly included via drm_buddy.h, drm_mm.h, or ttm/ttm_resource.h. In preparation for removing those includes, explicitly include drm_print.h where needed. Cc: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://lore.kernel.org/r/5fe67395907be33eb5199ea6d540e29fddee71c8.1761734313.git.jani.nikula@intel.com