summaryrefslogtreecommitdiff
path: root/drivers/gpu
AgeCommit message (Collapse)Author
2025-03-04drm/i915: Reoder CHV EU/slice fuse bitsVille Syrjälä
We customarily define the bits of a register in big endian order. Reorder the CHV fuse bits to match. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.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/20250211231941.22769-9-ville.syrjala@linux.intel.com
2025-03-04drm/i915: Use REG_BIT() & co. for CHV EU/slice fuse bitsVille Syrjälä
Convert the CHV EU/slice fuse bits to the modern REG_BIT()/etc. style. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.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/20250211231941.22769-8-ville.syrjala@linux.intel.com
2025-03-04drm/i915: Extract gen8_report_fault()Ville Syrjälä
gen8_check_faults() and xehp_check_faults() are nearly identical. Refactor the common bits into gen8_report_fault(). Signed-off-by: Ville Syrjälä <ville.syrjala@linux.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/20250211231941.22769-7-ville.syrjala@linux.intel.com
2025-03-04drm/i915: Introduce RING_FAULT_VADDR_MASKVille Syrjälä
Add a proper bitmask definition for the pre-bdw fault virtual address bits insted of abusing PAGE_MASK. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.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/20250211231941.22769-6-ville.syrjala@linux.intel.com
2025-03-04drm/i915: Document which RING_FAULT bits apply to which platformsVille Syrjälä
The RING_FAULT bits have change a bit over the years. Document which platforms use which bits. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.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/20250211231941.22769-5-ville.syrjala@linux.intel.com
2025-03-04drm/i915: Use REG_BIT() & co. for ring fault registersVille Syrjälä
Update the ring fault registers to use the modern REG_BIT() stuff. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.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/20250211231941.22769-4-ville.syrjala@linux.intel.com
2025-03-04drm/i915: Relocate RING_FAULT bitsVille Syrjälä
We share the bit definitions between the older RING_FAULT registers and their various gen12+ counterparts. Currently the bits are defined next to the new registers which isn't what we typically do. Move the bit definitions next the older register offsets, and leave breadcrumbs around the gen12+ registers to make it easier to find the right bits. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.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/20250211231941.22769-3-ville.syrjala@linux.intel.com
2025-03-04drm/i915: Bump RING_FAULT engine ID bitsVille Syrjälä
The fault engine ID field has been 5 bits since icl. Bump our define to match. The extra bits were unused before icl so we should be able to use the larger mask unconditionally. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.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/20250211231941.22769-2-ville.syrjala@linux.intel.com
2025-03-03drm/rockchip: vop2: add missing bitfield.h includeHeiko Stuebner
Commit 328e6885996c ("drm/rockchip: vop2: Add platform specific callback") moved per soc configuration code to the other per-soc data into rockchip_vop2_reg.c, but forgot to also include bitfield.h for the used FIELD_PREP macro. Add this missing include. Fixes: 328e6885996c ("drm/rockchip: vop2: Add platform specific callback") Reported-by: kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202503040135.fgoyWdLB-lkp@intel.com/ Reviewed-by: Sebastian Reichel <sebastian.reichel@collabora.com> Signed-off-by: Heiko Stuebner <heiko@sntech.de> Link: https://patchwork.freedesktop.org/patch/msgid/20250303182256.1727178-1-heiko@sntech.de
2025-03-03drm/rockchip: vop2: Add support for rk3576Andy Yan
VOP2 on rk3576: Three video ports: VP0 Max 4096x2160 VP1 Max 2560x1600 VP2 Max 1920x1080 2 4K Cluster windows with AFBC/RFBC, line RGB and YUV 4 Esmart windows with line RGB/YUV support: Esmart0/1: 4K Esmart2/3: 2k, or worked together as a single 4K plane at shared line buffer mode. Compared to the previous VOP, another difference is that each VP has its own independent vsync interrupt number. Signed-off-by: Andy Yan <andy.yan@rock-chips.com> Tested-by: Michael Riesch <michael.riesch@wolfvision.net> # on RK3568 Tested-by: Detlev Casanova <detlev.casanova@collabora.com> Signed-off-by: Heiko Stuebner <heiko@sntech.de> Link: https://patchwork.freedesktop.org/patch/msgid/20250303034436.192400-8-andyshrk@163.com
2025-03-03drm/rockchip: vop2: Add uv swap for cluster windowAndy Yan
The Cluster windows of upcoming VOP on rk3576 also support linear YUV support, we need to set uv swap bit for it. As the VOP2_WIN_UV_SWA register defined on rk3568/rk3588 is 0xffffffff, so this register will not be touched on these two platforms. Signed-off-by: Andy Yan <andy.yan@rock-chips.com> Tested-by: Michael Riesch <michael.riesch@wolfvision.net> # on RK3568 Tested-by: Detlev Casanova <detlev.casanova@collabora.com> Signed-off-by: Heiko Stuebner <heiko@sntech.de> Link: https://patchwork.freedesktop.org/patch/msgid/20250303034436.192400-4-andyshrk@163.com
2025-03-03drm/rockchip: vop2: Set plane possible crtcs by possible vp maskAndy Yan
In the upcoming VOP of rk3576, a window cannot attach to all Video Ports, we introduce a possible_vp_mask for every window to indicate which Video Ports this window can attach to. Signed-off-by: Andy Yan <andy.yan@rock-chips.com> Tested-by: Michael Riesch <michael.riesch@wolfvision.net> # on RK3568 Tested-by: Detlev Casanova <detlev.casanova@collabora.com> Signed-off-by: Heiko Stuebner <heiko@sntech.de> Link: https://patchwork.freedesktop.org/patch/msgid/20250303034436.192400-3-andyshrk@163.com
2025-03-03drm/rockchip: vop2: Register the primary plane and overlay plane separatelyAndy Yan
In the upcoming VOP of rk3576, a Window cannot attach to all Video Ports, so make sure all VP find it's suitable primary plane, then register the remain windows as overlay plane will make code easier. Signed-off-by: Andy Yan <andy.yan@rock-chips.com> Tested-by: Michael Riesch <michael.riesch@wolfvision.net> # on RK3568 Tested-by: Detlev Casanova <detlev.casanova@collabora.com> Signed-off-by: Heiko Stuebner <heiko@sntech.de> Link: https://patchwork.freedesktop.org/patch/msgid/20250303034436.192400-2-andyshrk@163.com
2025-03-03drm: adp: Add Apple Display Pipe driverSasha Finkelstein
This display controller is present on M-series chips and is used to drive the touchbar display. Co-developed-by: Janne Grunau <j@jannau.net> Signed-off-by: Janne Grunau <j@jannau.net> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Reviewed-by: Neal Gompa <neal@gompa.dev> Signed-off-by: Sasha Finkelstein <fnkl.kernel@gmail.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250224-adpdrm-v8-2-cccf96710f0f@gmail.com Signed-off-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
2025-03-03drm/tiny: add driver for Apple Touch Bars in x86 MacsKerem Karabay
The Touch Bars found on x86 Macs support two USB configurations: one where the device presents itself as a HID keyboard and can display predefined sets of keys, and one where the operating system has full control over what is displayed. This commit adds support for the display functionality of the second configuration. Functionality for the first configuration has been merged in the HID tree. Note that this driver has only been tested on T2 Macs, and only includes the USB device ID for these devices. Testing on T1 Macs would be appreciated. Credit goes to Ben (Bingxing) Wang on GitHub for reverse engineering most of the protocol. Also, as requested by Andy, I would like to clarify the use of __packed structs in this driver: - All the packed structs are aligned except for appletbdrm_msg_information. - We have to pack appletbdrm_msg_information since it is requirement of the protocol. - We compared binaries compiled by keeping the rest structs __packed and not __packed using bloat-o-meter, and __packed was not affecting code generation. - To maintain consistency, rest structs have been kept __packed. I would also like to point out that since the driver was reverse-engineered the actual data types of the protocol might be different, including, but not limited to, endianness. Link: https://github.com/imbushuo/DFRDisplayKm Signed-off-by: Kerem Karabay <kekrby@gmail.com> Co-developed-by: Atharva Tiwari <evepolonium@gmail.com> Signed-off-by: Atharva Tiwari <evepolonium@gmail.com> Co-developed-by: Aditya Garg <gargaditya08@live.com> Signed-off-by: Aditya Garg <gargaditya08@live.com> Signed-off-by: Aun-Ali Zaidi <admin@kodeit.net> Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de> Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Link: https://patchwork.freedesktop.org/patch/msgid/FCAC702C-F84A-47F9-8C78-BBBB34D08500@live.com
2025-03-03drm/format-helper: Add conversion from XRGB8888 to BGR888Kerem Karabay
Add XRGB8888 emulation helper for devices that only support BGR888. Signed-off-by: Kerem Karabay <kekrby@gmail.com> Signed-off-by: Aditya Garg <gargaditya08@live.com> Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de> Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Link: https://patchwork.freedesktop.org/patch/msgid/9A67EA95-9BC7-4D56-8F87-05EAC1C166AD@live.com
2025-03-03drm/sched: Fix preprocessor guardPhilipp Stanner
When writing the header guard for gpu_scheduler_trace.h, a typo, apparently, occurred. Fix the typo and document the scope of the guard. Fixes: 353da3c520b4 ("drm/amdgpu: add tracepoint for scheduler (v2)") Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@igalia.com> Signed-off-by: Philipp Stanner <phasta@kernel.org> Link: https://patchwork.freedesktop.org/patch/msgid/20250218124149.118002-2-phasta@kernel.org
2025-03-03drm/vc4: hdmi: Fix some NULL vs IS_ERR() bugsDan Carpenter
The devm_platform_ioremap_resource_byname() function doesn't return NULL, it returns error pointers. Update the checking to match. Fixes: b93f07cf090a ("drm/vc4: move to devm_platform_ioremap_resource() usage") Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/a952e2b4-d4b8-49ac-abd9-9967c50f4a80@stanley.mountain Signed-off-by: Maxime Ripard <mripard@kernel.org>
2025-03-03drm/tests: Drop drm_kunit_helper_acquire_ctx_alloc()Maxime Ripard
lockdep complains when a lock is released in a separate thread the lock is taken in, and it turns out that kunit does run its actions in a separate thread than the test ran in. This means that drm_kunit_helper_acquire_ctx_alloc() just cannot work as it's supposed to, so let's just get rid of it. Suggested-by: Simona Vetter <simona.vetter@ffwll.ch> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20250220132537.2834168-1-mripard@kernel.org Signed-off-by: Maxime Ripard <mripard@kernel.org>
2025-03-03drm/i915/fbc: handle dirty rect coords for the first frameVinod Govindapillai
During enabling FBC, for the very first frame, the prepare dirty rect routine wouldnt have executed as at that time the plane reference in the fbc_state would be NULL. So this could make driver program some invalid entries as the damage area. Though fbc hw ignores the dirty rect values programmed for the first frame after enabling FBC, driver must ensure that valid dirty rect coords are programmed. So ensure that for the first frame correct dirty rect coords are updated to the HW. Signed-off-by: Vinod Govindapillai <vinod.govindapillai@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Mika Kahola <mika.kahola@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250228093802.27091-10-vinod.govindapillai@intel.com
2025-03-03drm/i915/fbc: disable FBC if PSR2 selective fetch is enabledVinod Govindapillai
It is not recommended to have both FBC dirty rect and PSR2 selective fetch be enabled at the same time. Mark FBC as not possible, if PSR2 selective fetch is enabled. v2: fix the condition to disable FBC if PSR2 enabled (Jani) v3: use HAS_FBC_DIRTY_RECT() v4: Update to patch description Bspec: 68881 Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Vinod Govindapillai <vinod.govindapillai@intel.com> Signed-off-by: Mika Kahola <mika.kahola@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250228093802.27091-9-vinod.govindapillai@intel.com
2025-03-03drm/i915/fbc: dirty rect support for FBCVinod Govindapillai
Dirty rectangle feature allows FBC to recompress a subsection of a frame. When this feature is enabled, display will read the scan lines between dirty rectangle start line and dirty rectangle end line in subsequent frames. Use the merged damage clip stored in the plane state to configure the FBC dirty rect areas. v2: - Move dirty rect handling to fbc state (Ville) v3: - Use intel_fbc_dirty_rect_update_noarm (Ville) - Split plane damage collection and dirty rect preparation - Handle case where dirty rect fall outside the visible region v4: - A state variable to check if we need to update dirty rect registers in case intel_fbc_can_flip_nuke() (Ville) v5: - No need to use a separate valid flag, updates to the conditions for prepare damage rect (Ville) - Usage of locks in fbc dirty rect related functions (Ville) v6: - updates dirty rect handling (Ville) v7: - Loop through all planes in atomic state is good enough (Ville) Bspec: 68881, 71675, 73424 Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Vinod Govindapillai <vinod.govindapillai@intel.com> Signed-off-by: Mika Kahola <mika.kahola@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250228093802.27091-8-vinod.govindapillai@intel.com
2025-03-03drm/i915/fbc: avoid calling fbc activate if fbc is activeVinod Govindapillai
If FBC is already active, we don't need to call FBC activate routine again unless there are changes to the fences. So skip this on all platforms that don't have fences. Any FBC register updates done after enabling the dirty rect support in xe3 will trigger nuke by FBC which is counter productive to the fbc dirty rect feature. The front buffer rendering sequence will call intel_fbc_flush() and which will call intel_fbc_nuke() or intel_fbc_activate() based on FBC status explicitly and won't get impacted by this change. v2: use HAS_FBC_DIRTY_RECT() move this functionality within intel_fbc_activate() v3: update to intel_fbc_activate logic (Ville) update to the patch description Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Vinod Govindapillai <vinod.govindapillai@intel.com> Signed-off-by: Mika Kahola <mika.kahola@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250228093802.27091-7-vinod.govindapillai@intel.com
2025-03-03drm/i915/fbc: introduce HAS_FBC_DIRTY_RECT() for FBC dirty rect supportVinod Govindapillai
Introduce a macro to check if the platform supports FBC dirty rect capability. v2: - update to the patch subject Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Vinod Govindapillai <vinod.govindapillai@intel.com> Signed-off-by: Mika Kahola <mika.kahola@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250228093802.27091-6-vinod.govindapillai@intel.com
2025-03-03drm/i915/fbc: add register definitions for fbc dirty rect supportVinod Govindapillai
Register definitions for FBC dirty rect support v2: - update to the patch subject Bspec: 71675, 73424 Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Vinod Govindapillai <vinod.govindapillai@intel.com> Signed-off-by: Mika Kahola <mika.kahola@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250228093802.27091-5-vinod.govindapillai@intel.com
2025-03-03drm/i915/display: update and store the plane damage clipsVinod Govindapillai
Userspace can pass damage area clips per plane to track changes in a plane and some display components can utilze these damage clips for efficiently handling use cases like FBC, PSR etc. A merged damage area is generated and its coordinates are updated relative to viewport and HW and stored in the plane_state. This merged damage areas will be used for FBC dirty rect support in xe3 in the follow-up patch. Big thanks to Ville Syrjala for his contribuitions in shaping up of this series. v1: - Move damage_merged helper to cover bigjoiner case and use the correct plane state for damage find helper (Ville) - Damage handling code under HAS_FBC_DIRTY_RECT() so the the related part will be executed only for xe3+ - Changed dev_priv to i915 in one of the functions v2: - damage reported is stored in the plane state after coords adjustmentments irrespective of fbc dirty rect support. - Damage to be empty in case of plane not visible (Ville) - Handle fb could be NULL and plane not visible cases (Ville) v3: - No need to empty damage in case disp ver < 12 (Ville) - update to the patch subject Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Vinod Govindapillai <vinod.govindapillai@intel.com> Signed-off-by: Mika Kahola <mika.kahola@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250228093802.27091-4-vinod.govindapillai@intel.com
2025-03-03drm/damage-helper: add const qualifier in drm_atomic_helper_damage_merged()Vinod Govindapillai
Add a const qualifier for the "state" parameter as well as we could use this helper to get the combined damage in cases of const drm_plane_state as well. Needed mainly for xe driver big joiner cases where we need to track the damage from immutable plane state. Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Vinod Govindapillai <vinod.govindapillai@intel.com> Acked-by: Thomas Zimmermann <tzimmermann@suse.de> Signed-off-by: Mika Kahola <mika.kahola@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250228093802.27091-3-vinod.govindapillai@intel.com
2025-03-03drm/i915/fbc: remove one duplicate forward declarationVinod Govindapillai
Remove the duplicate "intel_display"declaration from intel_fbc.h Signed-off-by: Vinod Govindapillai <vinod.govindapillai@intel.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Mika Kahola <mika.kahola@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250228093802.27091-2-vinod.govindapillai@intel.com
2025-03-03drm/imagination: Fix timestamps in firmware tracesAlessio Belle
When firmware traces are enabled, the firmware dumps 48-bit timestamps for each trace as two 32-bit values, highest 32 bits (of which only 16 useful) first. The driver was reassembling them the other way round i.e. interpreting the first value in memory as the lowest 32 bits, and the second value as the highest 32 bits (then truncated to 16 bits). Due to this, firmware trace dumps showed very large timestamps even for traces recorded shortly after GPU boot. The timestamps in these dumps would also sometimes jump backwards because of the truncation. Example trace dumped after loading the powervr module and enabling firmware traces, where each line is commented with the timestamp value in hexadecimal to better show both issues: [93540092739584] : Host Sync Partition marker: 1 // 0x551300000000 [28419798597632] : GPU units deinit // 0x19d900000000 [28548647616512] : GPU deinit // 0x19f700000000 Update logic to reassemble the timestamps halves in the correct order. Fixes: cb56cd610866 ("drm/imagination: Add firmware trace to debugfs") Signed-off-by: Alessio Belle <alessio.belle@imgtec.com> Reviewed-by: Matt Coster <matt.coster@imgtec.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250221-fix-fw-trace-timestamps-v1-1-dba4aeb030ca@imgtec.com Signed-off-by: Matt Coster <matt.coster@imgtec.com>
2025-03-03drm/imagination: only init job done fences onceBrendan King
Ensure job done fences are only initialised once. This fixes a memory manager not clean warning from drm_mm_takedown on module unload. Cc: stable@vger.kernel.org Fixes: eaf01ee5ba28 ("drm/imagination: Implement job submission and scheduling") Signed-off-by: Brendan King <brendan.king@imgtec.com> Reviewed-by: Matt Coster <matt.coster@imgtec.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250226-init-done-fences-once-v2-1-c1b2f556b329@imgtec.com Signed-off-by: Matt Coster <matt.coster@imgtec.com>
2025-03-03drm/imagination: Hold drm_gem_gpuva lock for unmapBrendan King
Avoid a warning from drm_gem_gpuva_assert_lock_held in drm_gpuva_unlink. The Imagination driver uses the GEM object reservation lock to protect the gpuva list, but the GEM object was not always known in the code paths that ended up calling drm_gpuva_unlink. When the GEM object isn't known, it is found by calling drm_gpuva_find to lookup the object associated with a given virtual address range, or by calling drm_gpuva_find_first when removing all mappings. Cc: stable@vger.kernel.org Fixes: 4bc736f890ce ("drm/imagination: vm: make use of GPUVM's drm_exec helper") Signed-off-by: Brendan King <brendan.king@imgtec.com> Reviewed-by: Matt Coster <matt.coster@imgtec.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250226-hold-drm_gem_gpuva-lock-for-unmap-v2-1-3fdacded227f@imgtec.com Signed-off-by: Matt Coster <matt.coster@imgtec.com>
2025-03-03drm/imagination: avoid deadlock on fence releaseBrendan King
Do scheduler queue fence release processing on a workqueue, rather than in the release function itself. Fixes deadlock issues such as the following: [ 607.400437] ============================================ [ 607.405755] WARNING: possible recursive locking detected [ 607.415500] -------------------------------------------- [ 607.420817] weston:zfq0/24149 is trying to acquire lock: [ 607.426131] ffff000017d041a0 (reservation_ww_class_mutex){+.+.}-{3:3}, at: pvr_gem_object_vunmap+0x40/0xc0 [powervr] [ 607.436728] but task is already holding lock: [ 607.442554] ffff000017d105a0 (reservation_ww_class_mutex){+.+.}-{3:3}, at: dma_buf_ioctl+0x250/0x554 [ 607.451727] other info that might help us debug this: [ 607.458245] Possible unsafe locking scenario: [ 607.464155] CPU0 [ 607.466601] ---- [ 607.469044] lock(reservation_ww_class_mutex); [ 607.473584] lock(reservation_ww_class_mutex); [ 607.478114] *** DEADLOCK *** Cc: stable@vger.kernel.org Fixes: eaf01ee5ba28 ("drm/imagination: Implement job submission and scheduling") Signed-off-by: Brendan King <brendan.king@imgtec.com> Reviewed-by: Matt Coster <matt.coster@imgtec.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250226-fence-release-deadlock-v2-1-6fed2fc1fe88@imgtec.com Signed-off-by: Matt Coster <matt.coster@imgtec.com>
2025-03-03drm/i915: split out i915_gtt_view_types.h from i915_vma_types.hJani Nikula
In the interest of limiting the display dependencies on i915 core headers, split out i915_gtt_view_types.h from i915_vma_types.h, and only include the new header from intel_display_types.h. Reuse the new header from xe compat code too, failing build if partial view is used in display code. Side note: Why would we ever have set enum i915_gtt_view_type values to size of each type?! What an insane hack. Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/bb31885c32dbddad76d634c6fdb98a73b546b42e.1740412806.git.jani.nikula@intel.com
2025-03-03drm/i915: relocate intel_plane_ggtt_offset() to intel_atomic_plane.cJani Nikula
With the primary goal of removing #include "i915_vma.h" from intel_display_types.h, move intel_plane_ggtt_offset() to a proper function in intel_atomic_plane.c. This reveals tons of implicit dependencies all over the place that we pulled in via i915_vma.h. Fix the fallout. Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/70ac6d19518f355abf37ac8c4b0f1d18878be28c.1740412806.git.jani.nikula@intel.com
2025-03-03drm/i915/pxp & drm/xe/pxp: Figure out pxp instance from the gem objectJani Nikula
It's undesirable to have to figure out the pxp pointer in display code. For one thing, its type is different for i915 and xe. Since we can figure the pxp pointer out in the pxp code from the gem object, offload it there. v2: Rebase Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Alan Previn <alan.previn.teres.alexis@intel.com> Reviewed-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250228114527.3091620-1-jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2025-03-03drm/bridge: Fix spelling mistake "gettin" -> "getting"Colin Ian King
There is a spelling mistake in a dev_err message. Fix it. Signed-off-by: Colin Ian King <colin.i.king@gmail.com> Fixes: ff5781634c41 ("drm/bridge: sii902x: Implement HDMI audio support") Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Signed-off-by: Robert Foss <rfoss@kernel.org> Link: https://patchwork.freedesktop.org/patch/msgid/20250228083248.676473-1-colin.i.king@gmail.com
2025-03-03drm/i915/hdcp: add hdcp sub-struct to struct intel_digital_portJani Nikula
Move hdcp_mutex, num_hdcp_streams, hdcp_auth_status, hdcp_port_data, and hdcp_mst_type1_capable members of struct intel_digital_port under an hdcp sub-struct to group hdcp related things together. Rename them mutex, num_streams, auth_status, port_data, and mst_type1_capable for clarity. Cc: Suraj Kandpal <suraj.kandpal@intel.com> Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/9da4be57b068acd06dec8b93977f0a70627103d4.1740746939.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2025-03-03drm/i915/mst: add mst sub-struct to struct intel_connectorJani Nikula
Move port and mst_port members of struct intel_connector under an mst sub-struct to group mst related things together. Rename the latter dp for clarity. Cc: Imre Deak <imre.deak@intel.com> Reviewed-by: Imre Deak <imre.deak@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/e2afaf4595ae8e3241aaca1c1bb4d6356b07e44a.1740746939.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2025-03-03drm/i915/mst: add mst sub-struct to struct intel_dpJani Nikula
Move active_mst_links, mst_encoders[], and mst_mgr members of struct intel_dp under an mst sub-struct to group mst related things together. Rename them active_links, stream_encoders[] and mgr for clarity. Note that is_mst and mst_detect are not included, as they're also relevant for non-mst. The sub-struct is for active mst. Cc: Imre Deak <imre.deak@intel.com> Reviewed-by: Imre Deak <imre.deak@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/6f282f90bfe2dd9162e2dee8f681c84313971992.1740746939.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2025-03-02drm/rockchip: vop2: Introduce vop hardware versionAndy Yan
There is a version number hardcoded in the VOP VERSION_INFO register, and the version number increments sequentially based on the production order of the SoC. So using this version number to distinguish different VOP features will simplify the code. Signed-off-by: Andy Yan <andy.yan@rock-chips.com> Tested-by: Michael Riesch <michael.riesch@wolfvision.net> # on RK3568 Tested-by: Detlev Casanova <detlev.casanova@collabora.com> Signed-off-by: Heiko Stuebner <heiko@sntech.de> Link: https://patchwork.freedesktop.org/patch/msgid/20250218112744.34433-7-andyshrk@163.com
2025-03-02drm/rockchip: vop2: Support for different layer select configuration between VPsAndy Yan
In the upcoming VOP for rk3576, every VP has it's own LAYER_SEL register, and the configuration value of each VP for the same window maybe different, so extend the layer_sel_id to array, let it can descption the layer select configuration value for different VP. Signed-off-by: Andy Yan <andy.yan@rock-chips.com> Tested-by: Michael Riesch <michael.riesch@wolfvision.net> # on RK3568 Tested-by: Detlev Casanova <detlev.casanova@collabora.com> Signed-off-by: Heiko Stuebner <heiko@sntech.de> Link: https://patchwork.freedesktop.org/patch/msgid/20250218112744.34433-6-andyshrk@163.com
2025-03-02drm/rockchip: vop2: Merge vop2_cluster/esmart_init functionAndy Yan
Now these two function share the same logic, they can be merged as one. 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/20250218112744.34433-5-andyshrk@163.com
2025-03-02drm/rockchip: vop2: Add platform specific callbackAndy Yan
The VOP interface mux, overlay, background delay cycle configuration of different SOC are much different. Add platform specific callback ops to let the core driver look cleaner and more refined. Signed-off-by: Andy Yan <andy.yan@rock-chips.com> Tested-by: Michael Riesch <michael.riesch@wolfvision.net> # on RK3568 Tested-by: Detlev Casanova <detlev.casanova@collabora.com> Signed-off-by: Heiko Stuebner <heiko@sntech.de> Link: https://patchwork.freedesktop.org/patch/msgid/20250218112744.34433-4-andyshrk@163.com
2025-03-02drm/rockchip: vop2: Remove AFBC from TRANSFORM_OFFSET register macroAndy Yan
This TRANSFORM_OFFSET register needs to be configured not only in AFBC mode, but also in tile mode, so remove the AFBC/AFBCD prefix. This also help avoid "exceeds 100 columns" warning from checkpatch. 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/20250218112744.34433-3-andyshrk@163.com
2025-03-02drm/rockchip: vop2: use devm_regmap_field_alloc for cluster-regsAndy Yan
Right now vop2_cluster_init() copies the base vop2_cluster_regs and adapts the reg value with the current window's offset before adding the fields to the regmap. This conflicts with the notion of reg_fields being const, see https://lore.kernel.org/all/20240706-regmap-const-structs-v1-1-d08c776da787@weissschuh.net/ for reference, which now causes checkpatch to actually warn about that. So instead of creating one big copy and changing it afterwards, add the reg_fields individually using devm_regmap_field_alloc(). Functional it is the same, just that the reg_field we're handling can stay const. 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/20250218112744.34433-2-andyshrk@163.com
2025-03-02drm/mediatek: Move to devm_platform_ioremap_resource() usageAnusha Srivatsa
Replace platform_get_resource + devm_ioremap_resource with just devm_platform_ioremap_resource() Cc: Chun-Kuang Hu <chunkuang.hu@kernel.org> Cc: Philipp Zabel <p.zabel@pengutronix.de> Reviewed-by: Maxime Ripard <mripard@kernel.org> Reviewed-by: CK Hu <ck.hu@mediatek.com> Signed-off-by: Anusha Srivatsa <asrivats@redhat.com> Link: https://patchwork.kernel.org/project/dri-devel/patch/20250213-mem-cocci-v3-v1-4-93466d165349@redhat.com/ Signed-off-by: Chun-Kuang Hu <chunkuang.hu@kernel.org>
2025-03-02drm/mediatek: Add support for MT8195 Digital Parallel InterfaceAngeloGioacchino Del Regno
Add support for the DPI block found in the MT8195 and MT8188 SoCs. Inside of the SoC, this block is directly connected to the HDMI IP. Reviewed-by: CK Hu <ck.hu@mediatek.com> Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Link: https://patchwork.kernel.org/project/dri-devel/patch/20250217154836.108895-11-angelogioacchino.delregno@collabora.com/ Signed-off-by: Chun-Kuang Hu <chunkuang.hu@kernel.org>
2025-03-02drm/mediatek: mtk_dpi: Explicitly manage TVD clock in power on/offAngeloGioacchino Del Regno
In preparation for adding support for MT8195's HDMI reserved DPI, add calls to clk_prepare_enable() / clk_disable_unprepare() for the TVD clock: in this particular case, the aforementioned clock is not (and cannot be) parented to neither pixel or engine clocks hence it won't get enabled automatically by the clock framework. Please note that on all of the currently supported MediaTek platforms, the TVD clock is always a parent of either pixel or engine clocks, and this means that the common clock framework is already enabling this clock before the children. On such platforms, this commit will only increase the refcount of the TVD clock without any functional change. Reviewed-by: CK Hu <ck.hu@mediatek.com> Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Link: https://patchwork.kernel.org/project/dri-devel/patch/20250217154836.108895-10-angelogioacchino.delregno@collabora.com/ Signed-off-by: Chun-Kuang Hu <chunkuang.hu@kernel.org>
2025-03-02drm/mediatek: mtk_dpi: Support AFIFO 1T1P output and conversionAngeloGioacchino Del Regno
On some SoCs, like MT8195 and MT8188, the DPI's FIFO controller (afifo) supports outputting either one or two pixels per round regardless of the input being 1T1P or 1T2P. Add a `output_1pixel` member to struct mtk_dpi_conf which, if set, will enable outputting one pixel per clock. In case the input is two pixel per clock (1T2P), the AFIFO HW will automatically (and internally) convert it to 1T1P. Reviewed-by: CK Hu <ck.hu@mediatek.com> Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Link: https://patchwork.kernel.org/project/dri-devel/patch/20250217154836.108895-9-angelogioacchino.delregno@collabora.com/ Signed-off-by: Chun-Kuang Hu <chunkuang.hu@kernel.org>
2025-03-02drm/mediatek: mtk_dpi: Add support for DPI input clock from HDMIAngeloGioacchino Del Regno
On some SoCs, like MT8195 and MT8188, the DPI instance that is reserved to the HDMI Transmitter uses a different clock topology. In this case, the DPI is clocked by the HDMI IP, and this outputs its clock to the MM input of dpi_pixel_clk, which is essential to enable register access to the DPI IP. Add a `clocked_by_hdmi` member to struct mtk_dpi_conf, and check it to avoid enabling the DPI clocks in the mediatek-drm internal .start() callback (and avoid disabing in the .stop() component callback): this will make sure that the clock configuration sequence is respected during display pipeline setup by following the bridge ops between DPI and HDMI, where the HDMI driver is expected to enable the clocks in the bridge's pre_enable(), and DPI in the enable() cb. Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Reviewed-by: CK Hu <ck.hu@mediatek.com> Signed-off-by: Chun-Kuang Hu <chunkuang.hu@kernel.org>
generated by cgit v1.3 (git 2.53.0) at 2026-11-08 14:47:37 +0000