summaryrefslogtreecommitdiff
path: root/drivers/gpu/drm
AgeCommit message (Collapse)Author
2024-12-18drm/amdgpu/vcn: reset fw_shared under SRIOVBokun Zhang
- The previous patch only considered the case for baremetal and is not applicable for SRIOV code path. We also need to init fw_share for SRIOV VF Fixes: 928cd772e18f ("drm/amdgpu/vcn: reset fw_shared when VCPU buffers corrupted on vcn v4.0.3") Acked-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Bokun Zhang <bokun.zhang@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2024-12-18drm/amd/display/dc: add helper for panic updatesAlex Deucher
Add a DC helper for panic updates. Reviewed-by: Harry Wentland <harry.wentland@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Cc: Lu Yao <yaolu@kylinos.cn> Cc: Jocelyn Falempe <jfalempe@redhat.com> Cc: Harry Wentland <harry.wentland@amd.com>
2024-12-18drm/amd/display: add clear_tiling mi callbacksAlex Deucher
This adds clear_tiling callbacks to the mi structure that will be used for drm panic support to clear the tiling on a display. Mem input (mi) is used on DCE based display IPs. Reviewed-by: Harry Wentland <harry.wentland@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Cc: Lu Yao <yaolu@kylinos.cn> Cc: Jocelyn Falempe <jfalempe@redhat.com> Cc: Harry Wentland <harry.wentland@amd.com>
2024-12-18drm/amd/display: add clear_tiling hubp callbacksAlex Deucher
This adds clear_tiling callbacks to the hubp structure that will be used for drm panic support to clear the tiling on a display. hubp3 support from Jocelyn's original patch and the rest from me. Reviewed-by: Harry Wentland <harry.wentland@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Cc: Lu Yao <yaolu@kylinos.cn> Cc: Jocelyn Falempe <jfalempe@redhat.com> Cc: Harry Wentland <harry.wentland@amd.com>
2024-12-18drm/amdgpu: add generic display panic helper codeAlex Deucher
Pull this out of Jocelyn's patch and make it generic. Reviewed-by: Harry Wentland <harry.wentland@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Cc: Lu Yao <yaolu@kylinos.cn> Cc: Jocelyn Falempe <jfalempe@redhat.com> Cc: Harry Wentland <harry.wentland@amd.com>
2024-12-18drm/rockchip: vop2: include rockchip_drm_drv.hMin-Hua Chen
Move rockchip_drm_drv.h in rockchip_drm_vop2.h to fix the follow sparse warning: ARCH=arm64 LLVM=1 make C=1 CF='-fdiagnostic-prefix -D__CHECK_ENDIAN__' mrproper defconfig all -j12 drivers/gpu/drm/rockchip/rockchip_vop2_reg.c:502:24: sparse: warning: symbol 'vop2_platform_driver' was not declared. Should it be static? It is also beneficial for the upcoming support for rk3576. Fixes: 604be85547ce ("drm/rockchip: Add VOP2 driver") Signed-off-by: Min-Hua Chen <minhuadotchen@gmail.com> Signed-off-by: Andy Yan <andy.yan@rock-chips.com> Reviewed-by: Min-Hua Chen <minhuadotchen@gmail.com> Tested-by: Detlev Casanova <detlev.casanova@collabora.com> Tested-by: Michael Riesch <michael.riesch@wolfvision.net> # on RK3568 Signed-off-by: Heiko Stuebner <heiko@sntech.de> Link: https://patchwork.freedesktop.org/patch/msgid/20241214081719.3330518-8-andyshrk@163.com
2024-12-18drm/rockchip: vop2: Add check for 32 bpp format for rk3588Andy Yan
RK3588 only support DRM_FORMAT_XRGB2101010/XBGR2101010 in afbc mode. Fixes: 5a028e8f062f ("drm/rockchip: vop2: Add support for rk3588") Signed-off-by: Andy Yan <andy.yan@rock-chips.com> Signed-off-by: Heiko Stuebner <heiko@sntech.de> Link: https://patchwork.freedesktop.org/patch/msgid/20241214081719.3330518-7-andyshrk@163.com
2024-12-18drm/rockchip: vop2: Check linear format for Cluster windows on rk3566/8Andy Yan
The Cluster windows on rk3566/8 only support afbc mode. Fixes: 604be85547ce ("drm/rockchip: Add VOP2 driver") Signed-off-by: Andy Yan <andy.yan@rock-chips.com> Signed-off-by: Heiko Stuebner <heiko@sntech.de> Link: https://patchwork.freedesktop.org/patch/msgid/20241214081719.3330518-6-andyshrk@163.com
2024-12-18drm/rockchip: vop2: Setup delay cycle for Esmart2/3Andy Yan
Each layer needs to set the correct delay cycle to display properly without unexpected offset on screen. Fixes: 5a028e8f062f ("drm/rockchip: vop2: Add support for rk3588") Signed-off-by: Andy Yan <andy.yan@rock-chips.com> Tested-by: Derek Foreman <derek.foreman@collabora.com> Tested-by: Detlev Casanova <detlev.casanova@collabora.com> Signed-off-by: Heiko Stuebner <heiko@sntech.de> Link: https://patchwork.freedesktop.org/patch/msgid/20241214081719.3330518-5-andyshrk@163.com
2024-12-18drm/rockchip: vop2: Set AXI id for rk3588Andy Yan
There are two AXI bus in vop2, windows attached on the same bus must have a unique channel YUV and RGB channel ID. The default IDs will conflict with each other on the rk3588, so they need to be reassigned. Fixes: 5a028e8f062f ("drm/rockchip: vop2: Add support for rk3588") Signed-off-by: Andy Yan <andy.yan@rock-chips.com> Tested-by: Derek Foreman <derek.foreman@collabora.com> Tested-by: Detlev Casanova <detlev.casanova@collabora.com> Signed-off-by: Heiko Stuebner <heiko@sntech.de> Link: https://patchwork.freedesktop.org/patch/msgid/20241214081719.3330518-4-andyshrk@163.com
2024-12-18drm/i915/gt: Increase a time to retry RING_HEAD resetNitin Gote
Issue seen again where engine resets fails because the engine resumes from an incorrect RING_HEAD. HEAD is still not 0 even after writing into it. This seems to be timing issue and we experimented different values from 5ms to 50ms and found out that 50ms works best based on testing. So, if write doesn't succeed at first then retry again. v2: add a comment (Andi Shyti) Closes: https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/12806 Signed-off-by: Nitin Gote <nitin.r.gote@intel.com> Reviewed-by: Andi Shyti <andi.shyti@linux.intel.com> Signed-off-by: Andi Shyti <andi.shyti@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241217063532.2729031-1-nitin.r.gote@intel.com
2024-12-18drm/i915/display: drop unnecessary i915_drv.h includesJani Nikula
Now that we don't include i915_drv.h via any headers from display, we can reliably remove unnecessary i915_drv.h includes and be sure they're not indirectly included. Add other includes where needed. v2: Fix 32-bit build Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241217132147.2008057-1-jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2024-12-18drm/panel: simple: add Multi-Inno Technology MI1010Z1T-1CP11Marek Vasut
Add Multi-Inno Technology MI1010Z1T-1CP11 10.1" 1024x600 LVDS panel support. Signed-off-by: Marek Vasut <marex@denx.de> Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org> Link: https://lore.kernel.org/r/20241212122701.25305-2-marex@denx.de Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20241212122701.25305-2-marex@denx.de
2024-12-18drm/panel: simple: Add Tianma TM070JDHG34-00 panel supportLuca Ceresoli
Add Tianma TM070JDHG34-00 7.0" 1280x800 LVDS RGB TFT LCD panel. Panel info and datasheet: https://fortec.us/products/tm070jdhg34-00/ Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org> Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com> Link: https://lore.kernel.org/r/20241216-tianma_tm070jdhg34-v2-2-0b319a0bac39@bootlin.com Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20241216-tianma_tm070jdhg34-v2-2-0b319a0bac39@bootlin.com
2024-12-18drm/bridge: ti-sn65dsi83: use dev_err_probe when failing to get panel bridgeLuca Ceresoli
When devm_drm_of_get_bridge() fails, the probe fails silently. Use dev_err_probe() instead to log an error or report the deferral reason, whichever is applicable. Reviewed-by: Andi Shyti <andi.shyti@linux.intel.com> Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com> Link: https://lore.kernel.org/r/20241217-ti-sn65dsi83-dev_err_probe-v1-1-3fdce386400c@bootlin.com Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20241217-ti-sn65dsi83-dev_err_probe-v1-1-3fdce386400c@bootlin.com
2024-12-18drm/i915/cx0_phy: Fix C10 pll programming sequenceSuraj Kandpal
According to spec VDR_CUSTOM_WIDTH register gets programmed after pll specific VDR registers and TX Lane programming registers are done. Moreover we only program into C10_VDR_CONTROL1 to update config and setup master lane once all VDR registers are written into. Bspec: 67636 Fixes: 51390cc0e00a ("drm/i915/mtl: Add Support for C10 PHY message bus and pll programming") Signed-off-by: Suraj Kandpal <suraj.kandpal@intel.com> Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241216181554.2861381-1-suraj.kandpal@intel.com
2024-12-17drm/i915/guc: Update guc_err message to show outstanding g2h responsesJesus Narvaez
Updating the guc_error message to show how many g2h responses are still outstanding, in order to help with future debugging. Signed-off-by: Jesus Narvaez <jesus.narvaez@intel.com> Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: John Harrison <John.C.Harrison@Intel.com> Reviewed-by: Jonathan Cavitt <jonathan.cavitt@intel.com> Signed-off-by: John Harrison <John.C.Harrison@Intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241213204720.3918056-1-jesus.narvaez@intel.com
2024-12-17drm: rework FB_CORE dependencyArnd Bergmann
The 'select FB_CORE' statement moved from CONFIG_DRM to DRM_CLIENT_LIB, but there are now configurations that have code calling into fb_core as built-in even though the client_lib itself is a loadable module: x86_64-linux-ld: drivers/gpu/drm/drm_fb_helper.o: in function `drm_fb_helper_set_suspend': drm_fb_helper.c:(.text+0x2c6): undefined reference to `fb_set_suspend' x86_64-linux-ld: drivers/gpu/drm/drm_fb_helper.o: in function `drm_fb_helper_resume_worker': drm_fb_helper.c:(.text+0x2e1): undefined reference to `fb_set_suspend' In addition to DRM_CLIENT_LIB, the 'select' needs to be at least in DRM_KMS_HELPER and DRM_GEM_SHMEM_HELPER, so add it here. This patch is the KMS_HELPER part of [1]. Fixes: dadd28d4142f ("drm/client: Add client-lib module") Signed-off-by: Arnd Bergmann <arnd@arndb.de> Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de> Link: https://patchwork.freedesktop.org/series/141411/ # 1 Link: https://patchwork.freedesktop.org/patch/msgid/20241216074450.8590-4-tzimmermann@suse.de Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
2024-12-17drm/fbdev: Select FB_CORE dependency for fbdev on DMA and TTMThomas Zimmermann
Select FB_CORE if GEM's DMA and TTM implementations support fbdev emulation. Fixes linker errors about missing symbols from the fbdev subsystem. Also see [1] for a related SHMEM fix. Fixes: dadd28d4142f ("drm/client: Add client-lib module") Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Link: https://patchwork.freedesktop.org/series/141411/ # 1 Reviewed-by: Arnd Bergmann <arnd@arndb.de> Link: https://patchwork.freedesktop.org/patch/msgid/20241216074450.8590-3-tzimmermann@suse.de
2024-12-17drm/connector: Allow clearing HDMI infoframesDerek Foreman
Our infoframe setting code currently lacks the ability to clear infoframes. For some of the infoframes, we only need to replace them, so if an error occurred when generating a new infoframe we would leave a stale frame instead of clearing the frame. However, the Dynamic Range and Mastering (DRM) infoframe should only be present when displaying HDR content (ie: the HDR_OUTPUT_METADATA blob is set). If we can't clear infoframes, the stale DRM infoframe will remain and we can never set the display back to SDR mode. With this change, we clear infoframes when they can not, or should not, be generated. This fixes switching to an SDR mode from an HDR one. Fixes: f378b77227bc ("drm/connector: hdmi: Add Infoframes generation") Signed-off-by: Derek Foreman <derek.foreman@collabora.com> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20241202181939.724011-1-derek.foreman@collabora.com Signed-off-by: Maxime Ripard <mripard@kernel.org>
2024-12-17drm/tests: Add tests for drm_connector_dynamic_init()/register()Imre Deak
Add kunit tests for drm_connector_dynamic_init()/drm_connector_dynamic_register() added in an earlier commit. v2: Replace the reference to the patchset with "earlier commit". (Jani) Suggested-by: Maxime Ripard <mripard@kernel.org> Reviewed-by: Lyude Paul <lyude@redhat.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Acked-by: Alex Deucher <alexander.deucher@amd.com> Reviewed-by: Maxime Ripard <mripard@kernel.org> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241211230328.4012496-10-imre.deak@intel.com
2024-12-17drm/connector: Warn if a connector is registered/added incorrectlyImre Deak
All the drivers should be converted now to use drm_connector_dynamic_init() for MST connectors, hence drm_connector_dynamic_register()->drm_connector_add() can WARN now if this was not the case (for instance if a driver inited an MST connector with one of the drm_connector_init*() functions incorrectly). Reviewed-by: Lyude Paul <lyude@redhat.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Acked-by: Alex Deucher <alexander.deucher@amd.com> Acked-by: Wayne Lin <Wayne.Lin@amd.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241211230328.4012496-9-imre.deak@intel.com
2024-12-17drm/nouveau/dp_mst: Expose a connector to kernel users after it's properly ↵Imre Deak
initialized After a connector is added to the drm_mode_config::connector_list, it's visible to any in-kernel users looking up connectors via the above list. Make sure that the connector is properly initialized before such look-ups, by initializing the connector with drm_connector_dynamic_init() - which doesn't add the connector to the list - and registering it with drm_connector_dynamic_register() - which adds the connector to the list - after the initialization is complete. v2: Fix s/drm_connector_dynamic_register()/drm_connector_dynamic_init() typo in the commit log. Cc: Karol Herbst <kherbst@redhat.com> Cc: Lyude Paul <lyude@redhat.com> Cc: Danilo Krummrich <dakr@kernel.org> Reviewed-by: Lyude Paul <lyude@redhat.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Acked-by: Alex Deucher <alexander.deucher@amd.com> Acked-by: Wayne Lin <Wayne.Lin@amd.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241211230328.4012496-8-imre.deak@intel.com
2024-12-17drm/amd/dp_mst: Expose a connector to kernel users after it's properly ↵Imre Deak
initialized After a connector is added to the drm_mode_config::connector_list, it's visible to any in-kernel users looking up connectors via the above list. Make sure that the connector is properly initialized before such look-ups, by initializing the connector with drm_connector_dynamic_init() - which doesn't add the connector to the list - and registering it with drm_connector_dynamic_register() - which adds the connector to the list - after the initialization is complete. v2: Fix s/drm_connector_dynamic_register()/drm_connector_dynamic_init() typo in the commit log. Cc: Harry Wentland <harry.wentland@amd.com> Cc: Leo Li <sunpeng.li@amd.com> Cc: Wayne Lin <wayne.lin@amd.com> Cc: Alex Deucher <alexander.deucher@amd.com> Cc: Lyude Paul <lyude@redhat.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Acked-by: Alex Deucher <alexander.deucher@amd.com> Acked-by: Wayne Lin <Wayne.Lin@amd.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241211230328.4012496-7-imre.deak@intel.com
2024-12-17drm/i915/dp_mst: Expose a connector to kernel users after it's properly ↵Imre Deak
initialized After a connector is added to the drm_mode_config::connector_list, it's visible to any in-kernel users looking up connectors via the above list. Make sure that the connector is properly initialized before such look-ups, by initializing the connector with drm_connector_dynamic_init() - which doesn't add the connector to the list - and registering it with drm_connector_dynamic_register() - which adds the connector to the list - after the initialization is complete. v2: - Rebase on the change which moves adding the connector to the connector list only later when calling drm_connector_dynamic_register(). v3: - Rebase on drm-misc-next, due to a trivial conflict with commit 5503f8112e52 ("drm/i915/mst: unify MST topology callback naming ..."), which is only in drm-intel-next. - Fix s/drm_connector_dynamic_register()/drm_connector_dynamic_init() typo in the commit log. Cc: Lyude Paul <lyude@redhat.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> (v1) Reviewed-by: Lyude Paul <lyude@redhat.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Acked-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241211230328.4012496-6-imre.deak@intel.com
2024-12-17drm/dp_mst: Register connectors via drm_connector_dynamic_register()Imre Deak
MST connectors should be initialized/registered by calling drm_connector_dynamic_init()/drm_connector_dynamic_register(). The commit adding these functions explains the issue with the current drm_connector_init*()/drm_connector_register() interface for MST connectors. Based on the above adjust here the registration part and change the initialization part in follow-up commits for each driver. For now, drivers are allowed to keep using the drm_connector_init*() functions, by drm_connector_dynamic_register() checking for this (see drm_connector_add()). A commit later will change this to WARN in such cases. v2: Replaces references to a "patch" with "commit" in the commit log. (Jani) Cc: Lyude Paul <lyude@redhat.com> Cc: Harry Wentland <harry.wentland@amd.com> Cc: Leo Li <sunpeng.li@amd.com> Cc: Wayne Lin <wayne.lin@amd.com> Cc: Alex Deucher <alexander.deucher@amd.com> Cc: Karol Herbst <kherbst@redhat.com> Cc: Danilo Krummrich <dakr@kernel.org> Reviewed-by: Lyude Paul <lyude@redhat.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Acked-by: Alex Deucher <alexander.deucher@amd.com> Acked-by: Wayne Lin <Wayne.Lin@amd.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241211230328.4012496-5-imre.deak@intel.com
2024-12-17drm/connector: Add deprecation notes for drm_connector_register/unregisterImre Deak
Drivers should register/unregister only dynamic (MST) connectors manually using drm_connector_dynamic_register()/unregister(). Static connectors are registered/unregistered by the DRM core automatically. Some drivers still call drm_connector_register()/ unregister() for static connectors, both of which should be a nop for them and hence are scheduled to be removed. Update the function documentation for these functions accordingly. v2: s/deprication/deprecation in subject line. (Jani) Reviewed-by: Lyude Paul <lyude@redhat.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Acked-by: Alex Deucher <alexander.deucher@amd.com> Acked-by: Wayne Lin <Wayne.Lin@amd.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241211230328.4012496-4-imre.deak@intel.com
2024-12-17drm/connector: Add FIXME for GETRESOURCES ioctl wrt. uninited connectorsImre Deak
The connectors enumerated by the GETRESOURCES ioctl may not be fully initialized yet wrt. to the state set up during connector registration (for instance the connector's debugfs/sysfs interfaces may not exist yet). This can happen in two ways: 1. Connectors initialized and added to the drm_mode_config::connector_list during driver loading will be visible to the GETRESOURCES ioctl caller once the driver is registered via drm_dev_register()->drm_minor_register(DRM_MINOR_PRIMARY) and before the connectors are registered via drm_dev_register()-> drm_modeset_register_all(). 2. Dynamic connectors (MST) - after being initialized - may be added to the connector_list after the driver is loaded and registered and before the connector's userspace interfaces (debugfs, sysfs etc.) are added in drm_connector_dynamic_register(). A solution for 1. would be to register the driver only after the connectors are registered, for 2. to add the connector to connector_list only after the userspace interfaces are registered. The fix requires a bigger change, for now adding a FIXME: comment for it. v2: Remove references to the patchset from the commit log. (Jani) Suggested-by: Simona Vetter <simona.vetter@ffwll.ch> Reviewed-by: Lyude Paul <lyude@redhat.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Acked-by: Alex Deucher <alexander.deucher@amd.com> Acked-by: Wayne Lin <Wayne.Lin@amd.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241211230328.4012496-3-imre.deak@intel.com
2024-12-17drm/connector: Add a way to init/add a connector in separate stepsImre Deak
Atm when the connector is added to the drm_mode_config::connector_list, the connector may not be fully initialized yet. This is not a problem for static connectors initialized/added during driver loading, for which the driver ensures that look-ups via the above list are not possible until all the connector and other required state is fully initialized already. It's also not a problem for user space looking up either a static or dynamic (see what this is below) connector, since this will be only possible once the connector is registered. A dynamic - atm only a DP MST - connector can be initialized and added after the load time initialization is done. Such a connector may be looked up by in-kernel users once it's added to the connector list. In particular a hotplug handler could perform a detection on all the connectors on the list and hence find a connector there which isn't yet initialized. For instance the connector's helper hooks may be unset, leading to a NULL dereference while the detect helper calls the connector's drm_connector_helper_funcs::detect() or detect_ctx() handler. To resolve the above issue, add a way for dynamic connectors to separately initialize the DRM core specific parts of the connector without adding it to the connector list - by calling the new drm_connector_dynamic_init() - and to add the connector to the list later once all the initialization is complete and the connector is registered - by calling the new drm_connector_dynamic_register(). Adding the above 2 functions was also motivated to make the distinction of the interface between static and dynamic connectors clearer: Drivers should manually initialize and register only dynamic connectors (with the above 2 functions). A driver should only initialize a static connector (with one of the drm_connector_init*, drmm_connector_init* functions) while the registration of the connector will be done automatically by DRM core. v2: (Jani) - Let initing DDC as well via drm_connector_init_core(). - Rename __drm_connector_init to drm_connector_init_core_and_add(). v3: - Rename drm_connector_init_core() to drm_connector_dynamic_init(). (Sima) - Instead of exporting drm_connector_add(), move adding the connector to the registration step via a new drm_connector_dynamic_register(). (Sima) - Update drm_connector_dynamic_init()'s function documentation and the commit log according to the above changes. - Update the commit log describing the problematic scenario during connector detection. (Maxime) Cc: Jani Nikula <jani.nikula@intel.com> Cc: Simona Vetter <simona@ffwll.ch> Cc: Maxime Ripard <mripard@kernel.org> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> (v1) Reviewed-by: Lyude Paul <lyude@redhat.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Maxime Ripard <mripard@kernel.org> Acked-by: Alex Deucher <alexander.deucher@amd.com> Acked-by: Wayne Lin <Wayne.Lin@amd.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241211230328.4012496-2-imre.deak@intel.com
2024-12-17drm/rcar-du: Add support for r8a779h0Tomi Valkeinen
Add support for r8a779h0. It is very similar to r8a779g0, but has only one output. Signed-off-by: Tomi Valkeinen <tomi.valkeinen+renesas@ideasonboard.com> Tested-by: Geert Uytterhoeven <geert+renesas@glider.be> Reviewed-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241217-rcar-gh-dsi-v5-7-e77421093c05@ideasonboard.com
2024-12-17drm/rcar-du: dsi: Add r8a779h0 supportTomi Valkeinen
Add support for DSI on r8a779h0. As it is identical to DSI on r8a779g0, all we need is to handle the compatible string. Signed-off-by: Tomi Valkeinen <tomi.valkeinen+renesas@ideasonboard.com> Reviewed-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Tested-by: Geert Uytterhoeven <geert+renesas@glider.be> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241217-rcar-gh-dsi-v5-6-e77421093c05@ideasonboard.com
2024-12-17drm/rcar-du: Write DPTSR only if the second source existsTomi Valkeinen
Currently the driver always writes DPTSR when setting up the hardware. However, writing the register is only meaningful when the second source for a plane is used, and the register is not even documented for SoCs that do not have the second source. So move the write behind a condition. Signed-off-by: Tomi Valkeinen <tomi.valkeinen+renesas@ideasonboard.com> Reviewed-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Tested-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> # On R-Car M3-N Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241217-rcar-gh-dsi-v5-2-e77421093c05@ideasonboard.com
2024-12-17drm/rcar-du: dsi: Fix PHY lock bit checkTomi Valkeinen
The driver checks for bit 16 (using CLOCKSET1_LOCK define) in CLOCKSET1 register when waiting for the PPI clock. However, the right bit to check is bit 17 (CLOCKSET1_LOCK_PHY define). Not only that, but there's nothing in the documents for bit 16 for V3U nor V4H. So, fix the check to use bit 17, and drop the define for bit 16. Fixes: 155358310f01 ("drm: rcar-du: Add R-Car DSI driver") Fixes: 11696c5e8924 ("drm: Place Renesas drivers in a separate dir") Cc: stable@vger.kernel.org Signed-off-by: Tomi Valkeinen <tomi.valkeinen+renesas@ideasonboard.com> Reviewed-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Tested-by: Geert Uytterhoeven <geert+renesas@glider.be> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241217-rcar-gh-dsi-v5-1-e77421093c05@ideasonboard.com
2024-12-17i915/guc: Accumulate active runtime on gt resetUmesh Nerlige Ramappa
On gt reset, if a context is running, then accumulate it's active time into the busyness counter since there will be no chance for the context to switch out and update it's run time. v2: Move comment right above the if (John) Fixes: 77cdd054dd2c ("drm/i915/pmu: Connect engine busyness stats from GuC to pmu") Signed-off-by: Umesh Nerlige Ramappa <umesh.nerlige.ramappa@intel.com> Reviewed-by: John Harrison <John.C.Harrison@Intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241127174006.190128-4-umesh.nerlige.ramappa@intel.com (cherry picked from commit 7ed047da59cfa1acb558b95169d347acc8d85da1) Signed-off-by: Tvrtko Ursulin <tursulin@ursulin.net>
2024-12-17i915/guc: Ensure busyness counter increases motonicallyUmesh Nerlige Ramappa
Active busyness of an engine is calculated using gt timestamp and the context switch in time. While capturing the gt timestamp, it's possible that the context switches out. This race could result in an active busyness value that is greater than the actual context runtime value by a small amount. This leads to a negative delta and throws off busyness calculations for the user. If a subsequent count is smaller than the previous one, just return the previous one, since we expect the busyness to catch up. Fixes: 77cdd054dd2c ("drm/i915/pmu: Connect engine busyness stats from GuC to pmu") Signed-off-by: Umesh Nerlige Ramappa <umesh.nerlige.ramappa@intel.com> Reviewed-by: John Harrison <John.C.Harrison@Intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241127174006.190128-3-umesh.nerlige.ramappa@intel.com (cherry picked from commit cf907f6d294217985e9dafd9985dce874e04ca37) Signed-off-by: Tvrtko Ursulin <tursulin@ursulin.net>
2024-12-17i915/guc: Reset engine utilization buffer before registrationUmesh Nerlige Ramappa
On GT reset, we store total busyness counts for all engines and re-register the utilization buffer with GuC. At that time we should reset the buffer, so that we don't get spurious busyness counts on subsequent queries. To repro this issue, run igt@perf_pmu@busy-hang followed by igt@perf_pmu@most-busy-idle-check-all for a couple iterations. Fixes: 77cdd054dd2c ("drm/i915/pmu: Connect engine busyness stats from GuC to pmu") Signed-off-by: Umesh Nerlige Ramappa <umesh.nerlige.ramappa@intel.com> Reviewed-by: John Harrison <John.C.Harrison@Intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241127174006.190128-2-umesh.nerlige.ramappa@intel.com (cherry picked from commit abd318237fa6556c1e5225529af145ef15d5ff0d) Signed-off-by: Tvrtko Ursulin <tursulin@ursulin.net>
2024-12-17drm/panthor: Report innocent group killBoris Brezillon
Groups can be killed during a reset even though they did nothing wrong. That usually happens when the FW is put in a bad state by other groups, resulting in group suspension failures when the reset happens. If we end up in that situation, flag the group innocent and report innocence through a new DRM_PANTHOR_GROUP_STATE flag. Bump the minor driver version to reflect the uAPI change. Changes in v4: - Add an entry to the driver version changelog - Add R-bs Changes in v3: - Actually report innocence to userspace Changes in v2: - New patch Signed-off-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://patchwork.freedesktop.org/patch/msgid/20241211080500.2349505-1-boris.brezillon@collabora.com
2024-12-17drm/i915/dsc: Expose dsc sink max slice count via debugfsSwati Sharma
Number of DSC slices can be shown in the DSC debugfs so that test can take a call whether the configuration can support forcing bigjoiner/ultrajoiner. v2: used intel_dp_is_edp() as the parameter to drm_dp_dsc_sink_max_slice_count() (Jani N) Reviewed-by: Nemesa Garg <nemesa.garg@intel.com> (v1) Closes: https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/3387 Signed-off-by: Swati Sharma <swati2.sharma@intel.com> Signed-off-by: Jouni Högander <jouni.hogander@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241213093008.2149452-1-swati2.sharma@intel.com
2024-12-16drm/xe/oa/uapi: Expose an unblock after N reports OA propertyAshutosh Dixit
Expose an "unblock after N reports" OA property, to allow userspace threads to be woken up less frequently. Co-developed-by: Umesh Nerlige Ramappa <umesh.nerlige.ramappa@intel.com> Signed-off-by: Umesh Nerlige Ramappa <umesh.nerlige.ramappa@intel.com> Signed-off-by: Ashutosh Dixit <ashutosh.dixit@intel.com> Reviewed-by: Jonathan Cavitt <jonathan.cavitt@intel.com> Reviewed-by: Umesh Nerlige Ramappa <umesh.nerlige.ramappa@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241212224903.1853862-1-ashutosh.dixit@intel.com
2024-12-16drm/xe/guc: Enable WA_DUAL_QUEUE for newer platformsDaniele Ceraolo Spurio
The DUAL_QUEUE_WA tells the GuC to not allow concurrent submissions on RCS and CCSes with different address spaces, which on DG2 is required as a WA for an HW bug. On newer platforms, this block has been moved in HW at the CS level, by stalling the RCS/CCS context switch when one of the other RCS/CCSes is busy with a different address space. While functionally correct, having a submission stalled on the HW limits the GuC ability to shuffle things around and can cause complications if the non-stalled submission runs for a long time, because the GuC doesn't know that the stalled submission isn't actually running and might declare it as hung. Therefore, we enable the DUAL_QUEUE_WA on all newer platforms to move management back to the GuC. Note that the GuC specs also recommend enabling this for all platforms starting from MTL that have a CCS. v2: only apply the WA on GTs that have CCS engines v3: split comment (Jonathan) Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: John Harrison <John.C.Harrison@Intel.com> Cc: Jesus Narvaez <jesus.narvaez@intel.com> Cc: Jonathan Cavitt <jonathan.cavitt@intel.com> Reviewed-by: Jonathan Cavitt <jonathan.cavitt@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241213181012.2178794-1-daniele.ceraolospurio@intel.com
2024-12-16rust: finish using custom FFI integer typesMiguel Ojeda
In the last kernel cycle we migrated most of the `core::ffi` cases in commit d072acda4862 ("rust: use custom FFI integer types"): Currently FFI integer types are defined in libcore. This commit creates the `ffi` crate and asks bindgen to use that crate for FFI integer types instead of `core::ffi`. This commit is preparatory and no type changes are made in this commit yet. Finish now the few remaining/new cases so that we perform the actual remapping in the next commit as planned. Acked-by: Jocelyn Falempe <jfalempe@redhat.com> # drm Link: https://lore.kernel.org/rust-for-linux/CANiq72m_rg42SvZK=bF2f0yEoBLVA33UBhiAsv8THhVu=G2dPA@mail.gmail.com/ Link: https://lore.kernel.org/all/cc9253fa-9d5f-460b-9841-94948fb6580c@redhat.com/ Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2024-12-16drm/i915/display: drop i915_drv.h include from intel_display_trace.hJani Nikula
Finish the job of removing implicit dependencies on i915_drv.h via other includes in display code. Add a few missing explicit includes. Reviewed-by: Luca Coelho <luciano.coelho@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/c51352a2152cebd56ab3597ae5a791d2bb41439e.1732104170.git.jani.nikula@intel.com
2024-12-16drm/i915/display: add struct drm_device to struct intel_display conversion ↵Jani Nikula
function Add a __drm_to_display() conversion function to hide the to_i915() usage and the implicit dependency on i915_drv.h from intel_display_types.h. The goal is for this implementation to be a transitional helper only. One idea I've floated around in the past would be to require a struct intel_display pointer member to be placed right after struct drm_device member in struct drm_i915_private and struct xe_device [1][2]. [1] https://lore.kernel.org/r/7777ff70e2be0663de4398aa6f75f0c54146cbfc.1709727127.git.jani.nikula@intel.com [2] https://lore.kernel.org/r/0b9459da6c8cba0f74bf2781d69182fa6801cd97.1709727127.git.jani.nikula@intel.com Reviewed-by: Luca Coelho <luciano.coelho@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/cbbf26fa58ef662946303c972b1a1ff1547ddcfe.1732104170.git.jani.nikula@intel.com
2024-12-16drm/i915/uncore: add to_intel_uncore() and use itJani Nikula
Add to_intel_uncore() function to avoid the inclusion of i915_drv.h from intel_de.h. This reveals a number of implicit dependencies on i915_drv.h that need to be added. For now, to_intel_uncore() can be an inline function, with all the includes in compat intel_uncore.h, as long as i915_drv.h isn't included. The implicit dependencies on i915_drv.h is a problem in display code, but the same is not true for xe_device.h etc. Reviewed-by: Luca Coelho <luciano.coelho@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/377e2b400d126776224fc49874ed9cb03ac3123c.1732104170.git.jani.nikula@intel.com
2024-12-16drm/i915/display: add intel_display_conversion.c to hide stuff betterJani Nikula
The __to_intel_display() generics require the definition of struct drm_i915_private i.e. inclusion of i915_drv.h. Add intel_display_conversion.c with a __i915_to_display() function to do the conversion without the intel_display_conversion.h having an implicit dependency on i915_drv.h. The long term goal is to remove __to_intel_display() and the intel_display_conversion.[ch] files altoghether, and this is merely a transitional step to make the dependencies on i915_drv.h explicit. Reviewed-by: Luca Coelho <luciano.coelho@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/39e99b765b8c1a05d001659c39686a661ac268e2.1732104170.git.jani.nikula@intel.com
2024-12-16drm/i915: extract intel_uncore_trace.[ch]Jani Nikula
The i915_reg_rw tracing is a small isolated part of i915_trace.h. Its users are orthogonal to the other i915_trace.h users as well, and its implementation does not require all the includes of i915_trace.h. Split i915_reg_rw tracing to separate intel_uncore_trace.[ch]. The main underlying goal is to reduce implicit includes of i915_drv.h from display code. Reviewed-by: Luca Coelho <luciano.coelho@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/1a3623fbb120adc55bc1cab1e27aca6e55487163.1732104170.git.jani.nikula@intel.com
2024-12-16drm/i915/gvt: always pass struct intel_display * to register macrosJani Nikula
The long term goal is to remove the __to_intel_display() generics from display macros, such as register macros. This requires that all such macro usage passes struct intel_display * rather than struct drm_i915_private * to the macros. The short term goal is to hide the struct drm_i915_private access in intel_display_conversions.h into a function. This is problematic with gvt, because it's a separate module, and the conversion function would need to be exported. Make the conversion to always passing struct intel_display * in gvt to unblock both of the above. Reviewed-by: Luca Coelho <luciano.coelho@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/266616e14db8d9a342fd93ec9752f561149a799b.1732104170.git.jani.nikula@intel.com
2024-12-16drm/vc4: hdmi: use eld_mutex to protect access to connector->eldDmitry Baryshkov
Reading access to connector->eld can happen at the same time the drm_edid_to_eld() updates the data. Take the newly added eld_mutex in order to protect connector->eld from concurrent access. Reviewed-by: Maxime Ripard <mripard@kernel.org> Link: https://patchwork.freedesktop.org/patch/msgid/20241206-drm-connector-eld-mutex-v2-10-c9bce1ee8bea@linaro.org Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
2024-12-16drm/sti: hdmi: use eld_mutex to protect access to connector->eldDmitry Baryshkov
Reading access to connector->eld can happen at the same time the drm_edid_to_eld() updates the data. Take the newly added eld_mutex in order to protect connector->eld from concurrent access. Reviewed-by: Maxime Ripard <mripard@kernel.org> Acked-by: Raphael Gallais-Pou <rgallaispou@gmail.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241206-drm-connector-eld-mutex-v2-9-c9bce1ee8bea@linaro.org Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
2024-12-16drm/radeon: use eld_mutex to protect access to connector->eldDmitry Baryshkov
Reading access to connector->eld can happen at the same time the drm_edid_to_eld() updates the data. Take the newly added eld_mutex in order to protect connector->eld from concurrent access. Reviewed-by: Maxime Ripard <mripard@kernel.org> Link: https://patchwork.freedesktop.org/patch/msgid/20241206-drm-connector-eld-mutex-v2-8-c9bce1ee8bea@linaro.org Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
generated by cgit (git 2.34.1) at 2025-09-15 12:09:59 +0000