summaryrefslogtreecommitdiff
path: root/drivers/gpu
AgeCommit message (Collapse)Author
2024-09-10drm/panel: samsung-s6e3fa7: transition to mipi_dsi wrapped functionsTejas Vipin
Changes the samsung-s6e3fa7 panel to use multi style functions for improved error handling. Signed-off-by: Tejas Vipin <tejasvipin76@gmail.com> Reviewed-by: Douglas Anderson <dianders@chromium.org> Reviewed-by: Jessica Zhang <quic_jesszhan@quicinc.com> Signed-off-by: Douglas Anderson <dianders@chromium.org> Link: https://patchwork.freedesktop.org/patch/msgid/20240902071019.351158-1-tejasvipin76@gmail.com
2024-09-10drm/amd/pm: fix the pp_dpm_pcie issue on smu v14.0.2/3Kenneth Feng
fix the pp_dpm_pcie issue on smu v14.0.2/3 as below: 0: 2.5GT/s, x4 250Mhz 1: 8.0GT/s, x4 616Mhz * 2: 8.0GT/s, x4 1143Mhz * the middle level can be removed since it is always skipped on smu v14.0.2/3 Signed-off-by: Kenneth Feng <kenneth.feng@amd.com> Acked-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> (cherry picked from commit fedf6db3ea9dc5eda0b78cfbbb8f7a88b97e5b24)
2024-09-10drm/amd/pm: update the features set on smu v14.0.2/3Kenneth Feng
update the features set on smu v14.0.2/3 Signed-off-by: Kenneth Feng <kenneth.feng@amd.com> Reviewed-by: Yang Wang <kevinyang.wang@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> (cherry picked from commit 25d48f2eb0af1f0e6f09f54a1a1716f48c0722c9)
2024-09-10drm/amd/display: Do not reset planes based on crtc zpos_changedLeo Li
[Why] drm_normalize_zpos will set the crtc_state->zpos_changed to 1 if any of it's assigned planes changes zpos, or is removed/added from it. To have amdgpu_dm request a plane reset on this is too broad. For example, if only the cursor plane was moved from one crtc to another, the crtc's zpos_changed will be set to true. But that does not mean that the underlying primary plane requires a reset. [How] Narrow it down so that only the plane that has a change in zpos will require a reset. As a future TODO, we can further optimize this by only requiring a reset on z-order change. Z-order is different from z-pos, since a zpos change doesn't necessarily mean the z-ordering changed, and DC should only require a reset if the z-ordering changed. For example, the following zpos update does not change z-ordering: Plane A: zpos 2 -> 3 Plane B: zpos 1 -> 2 => Plane A is still on top of plane B: no reset needed Whereas this one does change z-ordering: Plane A: zpos 2 -> 1 Plane B: zpos 1 -> 2 => Plane A changed from on top, to below plane B: reset needed Fixes: 38e0c3df6dbd ("drm/amd/display: Move PRIMARY plane zpos higher") Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/3569 Signed-off-by: Leo Li <sunpeng.li@amd.com> Reviewed-by: Harry Wentland <harry.wentland@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> (cherry picked from commit 578aab4ecc73476393389440724b7a391cc0cea9)
2024-09-10drm/amd/display: Avoid race between dcn35_set_drr() and dc_state_destruct()Tobias Jakobi
dc_state_destruct() nulls the resource context of the DC state. The pipe context passed to dcn35_set_drr() is a member of this resource context. If dc_state_destruct() is called parallel to the IRQ processing (which calls dcn35_set_drr() at some point), we can end up using already nulled function callback fields of struct stream_resource. The logic in dcn35_set_drr() already tries to avoid this, by checking tg against NULL. But if the nulling happens exactly after the NULL check and before the next access, then we get a race. Avoid this by copying tg first to a local variable, and then use this variable for all the operations. This should work, as long as nobody frees the resource pool where the timing generators live. Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/3142 Fixes: 06ad7e164256 ("drm/amd/display: Destroy DC context while keeping DML and DML2") Signed-off-by: Tobias Jakobi <tjakobi@math.uni-bielefeld.de> Reviewed-by: Harry Wentland <harry.wentland@amd.com> Signed-off-by: Mario Limonciello <mario.limonciello@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> (cherry picked from commit 0607a50c004798a96e62c089a4c34c220179dcb5) Cc: stable@vger.kernel.org
2024-09-10drm/amd/display: Avoid race between dcn10_set_drr() and dc_state_destruct()Tobias Jakobi
dc_state_destruct() nulls the resource context of the DC state. The pipe context passed to dcn10_set_drr() is a member of this resource context. If dc_state_destruct() is called parallel to the IRQ processing (which calls dcn10_set_drr() at some point), we can end up using already nulled function callback fields of struct stream_resource. The logic in dcn10_set_drr() already tries to avoid this, by checking tg against NULL. But if the nulling happens exactly after the NULL check and before the next access, then we get a race. Avoid this by copying tg first to a local variable, and then use this variable for all the operations. This should work, as long as nobody frees the resource pool where the timing generators live. Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/3142 Fixes: 06ad7e164256 ("drm/amd/display: Destroy DC context while keeping DML and DML2") Signed-off-by: Tobias Jakobi <tjakobi@math.uni-bielefeld.de> Tested-by: Raoul van Rüschen <raoul.van.rueschen@gmail.com> Tested-by: Christopher Snowhill <chris@kode54.net> Reviewed-by: Harry Wentland <harry.wentland@amd.com> Tested-by: Sefa Eyeoglu <contact@scrumplex.net> Signed-off-by: Mario Limonciello <mario.limonciello@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> (cherry picked from commit a3cc326a43bdc48fbdf53443e1027a03e309b643) Cc: stable@vger.kernel.org
2024-09-10drm/amdkfd: Add cache line size infoDavid Belanger
Populate cache line size info in topology based on information from IP discovery table. Signed-off-by: David Belanger <david.belanger@amd.com> Reviewed-by: Sreekant Somasekharan <Sreekant.Somasekharan@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> (cherry picked from commit 4e9fadacddca96a2e6fcee9cc9488b78eb7a6953)
2024-09-10drm/tegra: Use iommu_paging_domain_alloc()Lu Baolu
Commit <17de3f5fdd35> ("iommu: Retire bus ops") removes iommu ops from the bus structure. The iommu subsystem no longer relies on bus for operations. So iommu_domain_alloc() interface is no longer relevant. Replace iommu_domain_alloc() with iommu_paging_domain_alloc() which takes the physical device from which the host1x_device virtual device was instantiated. This physical device is a common parent to all physical devices that are part of the virtual device. Suggested-by: Thierry Reding <thierry.reding@gmail.com> Signed-off-by: Lu Baolu <baolu.lu@linux.intel.com> Signed-off-by: Lyude Paul <lyude@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240902014700.66095-4-baolu.lu@linux.intel.com
2024-09-10drm/rockchip: Use iommu_paging_domain_alloc()Lu Baolu
Commit <421be3ee36a4> ("drm/rockchip: Refactor IOMMU initialisation") has refactored rockchip_drm_init_iommu() to pass a device that the domain is allocated for. Replace iommu_domain_alloc() with iommu_paging_domain_alloc() to retire the former. Signed-off-by: Lu Baolu <baolu.lu@linux.intel.com> Reviewed-by: Jason Gunthorpe <jgg@nvidia.com> Acked-by: Andy Yan <andyshrk@163.com> Signed-off-by: Lyude Paul <lyude@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240902014700.66095-3-baolu.lu@linux.intel.com
2024-09-10drm/amdgpu: get rid of bogus includes of fdtable.hAl Viro
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2024-09-10drm/amdkfd: CRIU fixesAl Viro
Instead of trying to use close_fd() on failure exits, just have criu_get_prime_handle() store the file reference without inserting it into descriptor table. Then, once the callers are past the last failure exit, they can go and either insert all those file references into the corresponding slots of descriptor table, or drop all those file references and free the unused descriptors. Reviewed-by: Felix Kuehling <felix.kuehling@amd.com> Signed-off-by: Al Viro <viro@zeniv.linux.org.uk> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2024-09-10drm/amdgpu: fix a race in kfd_mem_export_dmabuf()Al Viro
Using drm_gem_prime_handle_to_fd() to set dmabuf up and insert it into descriptor table, only to have it looked up by file descriptor and remove it from descriptor table is not just too convoluted - it's racy; another thread might have modified the descriptor table while we'd been going through that song and dance. Switch kfd_mem_export_dmabuf() to using drm_gem_prime_handle_to_dmabuf() and leave the descriptor table alone... Reviewed-by: Felix Kuehling <felix.kuehling@amd.com> Signed-off-by: Al Viro <viro@zeniv.linux.org.uk> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2024-09-10drm: new helper: drm_gem_prime_handle_to_dmabuf()Al Viro
Once something had been put into descriptor table, the only thing you can do with it is returning descriptor to userland - you can't withdraw it on subsequent failure exit, etc. You certainly can't count upon it staying in the same slot of descriptor table - another thread could've played with close(2)/dup2(2)/whatnot. drm_gem_prime_handle_to_fd() creates a dmabuf, allocates a descriptor and attaches dmabuf's file to it (the last two steps are done in dma_buf_fd()). That's nice when all you are going to do is passing a descriptor to userland. If you just need to work with the resulting object or have something else to be done that might fail, drm_gem_prime_handle_to_fd() is racy. The problem is analogous to one with anon_inode_getfd(), and solution is similar to what anon_inode_getfile() provides. Add drm_gem_prime_handle_to_dmabuf() - the "set dmabuf up" parts of drm_gem_prime_handle_to_fd() without the descriptor-related ones. Instead of inserting into descriptor table and returning the file descriptor it just returns the struct file. drm_gem_prime_handle_to_fd() becomes a wrapper for it. Other users will be introduced in the next commit. Acked-by: Thomas Zimmermann <tzimmermann@suse.de> Signed-off-by: Al Viro <viro@zeniv.linux.org.uk> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2024-09-10drm/amdgpu/atomfirmware: Silence UBSAN warningAlex Deucher
Per the comments, these are variable sized arrays. Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/3613 Reviewed-by: Harry Wentland <harry.wentland@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2024-09-10drm/amdgpu: Fix kdoc entry in 'amdgpu_vm_cpu_prepare'Srinivasan Shanmugam
This commit updates described non-existent parameters 'resv' and 'sync_mode', and failed to describe the existing 'sync' parameter. Fixes the below with gcc W=1: drivers/gpu/drm/amd/amdgpu/amdgpu_vm_cpu.c:50: warning: Function parameter or struct member 'sync' not described in 'amdgpu_vm_cpu_prepare' drivers/gpu/drm/amd/amdgpu/amdgpu_vm_cpu.c:50: warning: Excess function parameter 'resv' description in 'amdgpu_vm_cpu_prepare' drivers/gpu/drm/amd/amdgpu/amdgpu_vm_cpu.c:50: warning: Excess function parameter 'sync_mode' description in 'amdgpu_vm_cpu_prepare' Cc: Christian König <christian.koenig@amd.com> Cc: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Srinivasan Shanmugam <srinivasan.shanmugam@amd.com> Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2024-09-10drm/amd/amdgpu: apply command submission parser for JPEG v1David (Ming Qiang) Wu
Similar to jpeg_v2_dec_ring_parse_cs() but it has different register ranges and a few other registers access. Acked-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: David (Ming Qiang) Wu <David.Wu3@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2024-09-10drm/amd/amdgpu: apply command submission parser for JPEG v2+David (Ming Qiang) Wu
This patch extends the same cs parser from JPEG v4.0.3 to other JPEG versions (v2 and above). Rename to more common name as jpeg_v2_dec_ring_parse_cs() from jpeg_v4_0_3_dec_ring_parse_cs(). Acked-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: David (Ming Qiang) Wu <David.Wu3@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2024-09-10drm/amd/pm: fix the pp_dpm_pcie issue on smu v14.0.2/3Kenneth Feng
fix the pp_dpm_pcie issue on smu v14.0.2/3 as below: 0: 2.5GT/s, x4 250Mhz 1: 8.0GT/s, x4 616Mhz * 2: 8.0GT/s, x4 1143Mhz * the middle level can be removed since it is always skipped on smu v14.0.2/3 Signed-off-by: Kenneth Feng <kenneth.feng@amd.com> Acked-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2024-09-10drm/amd/pm: update the features set on smu v14.0.2/3Kenneth Feng
update the features set on smu v14.0.2/3 Signed-off-by: Kenneth Feng <kenneth.feng@amd.com> Reviewed-by: Yang Wang <kevinyang.wang@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2024-09-10drm/amdkfd: Fix resource leak in criu restore queueJesse Zhang
To avoid memory leaks, release q_extra_data when exiting the restore queue. v2: Correct the proto (Alex) Signed-off-by: Jesse Zhang <jesse.zhang@amd.com> Reviewed-by: Tim Huang <tim.huang@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2024-09-10drm/amd/display: Do not reset planes based on crtc zpos_changedLeo Li
[Why] drm_normalize_zpos will set the crtc_state->zpos_changed to 1 if any of it's assigned planes changes zpos, or is removed/added from it. To have amdgpu_dm request a plane reset on this is too broad. For example, if only the cursor plane was moved from one crtc to another, the crtc's zpos_changed will be set to true. But that does not mean that the underlying primary plane requires a reset. [How] Narrow it down so that only the plane that has a change in zpos will require a reset. As a future TODO, we can further optimize this by only requiring a reset on z-order change. Z-order is different from z-pos, since a zpos change doesn't necessarily mean the z-ordering changed, and DC should only require a reset if the z-ordering changed. For example, the following zpos update does not change z-ordering: Plane A: zpos 2 -> 3 Plane B: zpos 1 -> 2 => Plane A is still on top of plane B: no reset needed Whereas this one does change z-ordering: Plane A: zpos 2 -> 1 Plane B: zpos 1 -> 2 => Plane A changed from on top, to below plane B: reset needed Fixes: 38e0c3df6dbd ("drm/amd/display: Move PRIMARY plane zpos higher") Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/3569 Signed-off-by: Leo Li <sunpeng.li@amd.com> Reviewed-by: Harry Wentland <harry.wentland@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2024-09-10drm/syncobj: Fix syncobj leak in drm_syncobj_eventfd_ioctlT.J. Mercier
A syncobj reference is taken in drm_syncobj_find, but not released if eventfd_ctx_fdget or kzalloc fails. Put the reference in these error paths. Reported-by: Xingyu Jin <xingyuj@google.com> Fixes: c7a472297169 ("drm/syncobj: add IOCTL to register an eventfd") Signed-off-by: T.J. Mercier <tjmercier@google.com> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@igalia.com> Reviewed-by. Christian König <christian.koenig@amd.com> CC: stable@vger.kernel.org # 6.6+ Link: https://patchwork.freedesktop.org/patch/msgid/20240909205400.3498337-1-tjmercier@google.com Signed-off-by: Christian König <christian.koenig@amd.com>
2024-09-10drm/stm: add COMMON_CLK dependencyArnd Bergmann
The added lvds driver and a change in the dsi driver resulted in failed builds when COMMON_CLK is disabled: x86_64-linux-ld: drivers/gpu/drm/stm/dw_mipi_dsi-stm.o: in function `dw_mipi_dsi_stm_remove': dw_mipi_dsi-stm.c:(.text+0x51e): undefined reference to `clk_hw_unregister' x86_64-linux-ld: drivers/gpu/drm/stm/lvds.o: in function `lvds_remove': lvds.c:(.text+0xe3): undefined reference to `of_clk_del_provider' x86_64-linux-ld: lvds.c:(.text+0xec): undefined reference to `clk_hw_unregister' x86_64-linux-ld: drivers/gpu/drm/stm/lvds.o: in function `lvds_pll_config': lvds.c:(.text+0xb5d): undefined reference to `clk_hw_get_rate' x86_64-linux-ld: drivers/gpu/drm/stm/lvds.o: in function `lvds_probe': lvds.c:(.text+0x1476): undefined reference to `clk_hw_register' x86_64-linux-ld: lvds.c:(.text+0x148b): undefined reference to `of_clk_hw_simple_get' x86_64-linux-ld: lvds.c:(.text+0x1493): undefined reference to `of_clk_add_hw_provider' x86_64-linux-ld: lvds.c:(.text+0x1535): undefined reference to `clk_hw_unregister' Add this as a dependency for the stm driver itself, since it will be required in practice anyway. Fixes: 185f99b61442 ("drm/stm: dsi: expose DSI PHY internal clock") Fixes: aca1cbc1c986 ("drm/stm: lvds: add new STM32 LVDS Display Interface Transmitter driver") Signed-off-by: Arnd Bergmann <arnd@arndb.de> Link: https://patchwork.freedesktop.org/patch/msgid/20240719075454.3595358-1-arnd@kernel.org Signed-off-by: Raphael Gallais-Pou <raphael.gallais-pou@foss.st.com> (cherry picked from commit 26dbffb2a4c4d4639c7b336f6b74a437c23dadd4) Signed-off-by: Maxime Ripard <mripard@kernel.org>
2024-09-10Merge branch 'linus' into timers/coreThomas Gleixner
To update with the latest fixes.
2024-09-10drm/nouveau/fb: restore init() for ramgp102Ben Skeggs
init() was removed from ramgp102 when reworking the memory detection, as it was thought that the code was only necessary when the driver performs mclk changes, which nouveau doesn't support on pascal. However, it turns out that we still need to execute this on some GPUs to restore settings after DEVINIT, so revert to the original behaviour. v2: fix tags in commit message, cc stable Closes: https://gitlab.freedesktop.org/drm/nouveau/-/issues/319 Fixes: 2c0c15a22fa0 ("drm/nouveau/fb/gp102-ga100: switch to simpler vram size detection method") Cc: stable@vger.kernel.org # 6.6+ Signed-off-by: Ben Skeggs <bskeggs@nvidia.com> Signed-off-by: Danilo Krummrich <dakr@kernel.org> Link: https://patchwork.freedesktop.org/patch/msgid/20240904232418.8590-1-bskeggs@nvidia.com
2024-09-10drm/i915/guc: prevent a possible int overflow in wq offsetsNikita Zhandarovich
It may be possible for the sum of the values derived from i915_ggtt_offset() and __get_parent_scratch_offset()/ i915_ggtt_offset() to go over the u32 limit before being assigned to wq offsets of u64 type. Mitigate these issues by expanding one of the right operands to u64 to avoid any overflow issues just in case. Found by Linux Verification Center (linuxtesting.org) with static analysis tool SVACE. Fixes: c2aa552ff09d ("drm/i915/guc: Add multi-lrc context registration") Cc: Matthew Brost <matthew.brost@intel.com> Cc: John Harrison <John.C.Harrison@Intel.com> Signed-off-by: Nikita Zhandarovich <n.zhandarovich@fintech.ru> Link: https://patchwork.freedesktop.org/patch/msgid/20240725155925.14707-1-n.zhandarovich@fintech.ru Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> (cherry picked from commit 1f1c1bd56620b80ae407c5790743e17caad69cec) Signed-off-by: Tvrtko Ursulin <tursulin@ursulin.net>
2024-09-10Merge tag 'drm-xe-next-2024-09-05' of ↵Dave Airlie
https://gitlab.freedesktop.org/drm/xe/kernel into drm-next Cross-subsystem Changes: - Split dma fence array creation into alloc and arm (Matthew Brost) Driver Changes: - Move kernel_lrc to execlist backend (Ilia) - Fix type width for pcode coommand (Karthik) - Make xe_drm.h include unambiguous (Jani) - Fixes and debug improvements for GSC load (Daniele) - Track resources and VF state by PF (Michal Wajdeczko) - Fix memory leak on error path (Nirmoy) - Cleanup header includes (Matt Roper) - Move pcode logic to tile scope (Matt Roper) - Move hwmon logic to device scope (Matt Roper) - Fix media TLB invalidation (Matthew Brost) - Threshold config fixes for PF (Michal Wajdeczko) - Remove extra "[drm]" from logs (Michal Wajdeczko) - Add missing runtime ref (Rodrigo Vivi) - Fix circular locking on runtime suspend (Rodrigo Vivi) - Fix rpm in TTM swapout path (Thomas) Signed-off-by: Dave Airlie <airlied@redhat.com> From: Lucas De Marchi <lucas.demarchi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/eirx5vdvoflbbqlrzi5cip6bpu3zjojm2pxseufu3rlq4pp6xv@eytjvhizfyu6
2024-09-09treewide: correct the typo 'retun'WangYuli
There are some spelling mistakes of 'retun' in comments which should be instead of 'return'. Link: https://lkml.kernel.org/r/63D0F870EE8E87A0+20240906054008.390188-1-wangyuli@uniontech.com Signed-off-by: WangYuli <wangyuli@uniontech.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2024-09-09drm/xe: fix build warning with CONFIG_PM=nArnd Bergmann
The 'runtime_status' field is an implementation detail of the power management code, so a device driver should not normally touch this: drivers/gpu/drm/xe/xe_pm.c: In function 'xe_pm_suspending_or_resuming': drivers/gpu/drm/xe/xe_pm.c:606:26: error: 'struct dev_pm_info' has no member named 'runtime_status' 606 | return dev->power.runtime_status == RPM_SUSPENDING || | ^ drivers/gpu/drm/xe/xe_pm.c:607:27: error: 'struct dev_pm_info' has no member named 'runtime_status' 607 | dev->power.runtime_status == RPM_RESUMING; | ^ drivers/gpu/drm/xe/xe_pm.c:608:1: error: control reaches end of non-void function [-Werror=return-type] Add an #ifdef check to avoid the build regression. Fixes: cb85e39dc5d1 ("drm/xe: Suppress missing outer rpm protection warning") Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Arnd Bergmann <arnd@arndb.de> Link: https://patchwork.freedesktop.org/patch/msgid/20240909202521.1018439-1-arnd@kernel.org Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2024-09-09drm/xe: Don't keep stale pointer to bo->ggtt_nodeMichal Wajdeczko
When we fail to map a BO in the GGTT, we release our GGTT node placeholder, but leave stale bo->ggtt_node pointer to it, which triggers an assert immediately followed by a crash, due to UAF: [ ] xe 0000:00:02.0: [drm] Assertion `bo->ggtt_node->base.size == bo->size` failed! [ ] WARNING: CPU: 4 PID: 126 at drivers/gpu/drm/xe/xe_ggtt.c:689 xe_ggtt_remove_bo+0x1d9/0x250 [xe] [ ] RIP: 0010:xe_ggtt_remove_bo+0x1d9/0x250 [xe] [ ] Call Trace: [ ] <TASK> [ ] ? __warn+0x88/0x190 [ ] ? xe_ggtt_remove_bo+0x1d9/0x250 [xe] [ ] ? report_bug+0x1c3/0x1d0 [ ] ? handle_bug+0x42/0x70 [ ] ? exc_invalid_op+0x14/0x70 [ ] ? asm_exc_invalid_op+0x16/0x20 [ ] ? xe_ggtt_remove_bo+0x1d9/0x250 [xe] [ ] ? xe_ggtt_remove_bo+0x1d9/0x250 [xe] [ ] xe_ttm_bo_destroy+0x11f/0x260 [xe] [ ] ? ttm_bo_release+0x31c/0x350 [ttm] [ ] ? __mutex_unlock_slowpath+0x35/0x270 [ ] __xe_bo_create_locked+0x4a0/0x550 [xe] [ ] ? mark_held_locks+0x49/0x80 [ ] xe_bo_create_pin_map_at+0x37/0x200 [xe] [ ] xe_bo_create_pin_map+0x11/0x20 [xe] While around, for similar reason, also don't keep an error pointer if we fail to allocate ggtt_node placeholder. Fixes: 34e804220f69 ("drm/xe: Make xe_ggtt_node struct independent") Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240906220348.1836-1-michal.wajdeczko@intel.com
2024-09-09drm/xe: Mark reserved engines in snapshotLucas De Marchi
When printing <debufs>/gt*/hw_engines, it's useful to mark what engines are reserved so it doesn't mislead developers while debugging. Cc: José Roberto de Souza <jose.souza@intel.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com> Reviewed-by: José Roberto de Souza <jose.souza@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240906205609.3131330-1-lucas.demarchi@intel.com Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
2024-09-09drm/xe: Fix arg to pci_iomap()Lucas De Marchi
Commit 2d8865b27724 ("drm/xe: Move BAR definitions to dedicated file") moved the BAR definition to the header, but replaced the wrong arg in the pci_iomap() function - the last arg is actuall the length, not the BAR. Luckily GTTMMADR_BAR == 0, so it still works. Fix the argument to avoid confusion. Cc: Michal Wajdeczko <michal.wajdeczko@intel.com> Reviewed-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Reviewed-by: Alan Previn <alan.previn.teres.alexis@intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240906032507.2952859-1-lucas.demarchi@intel.com Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
2024-09-09drm/vc4: hvs: Correct logic on stopping an HVS channelDave Stevenson
When factoring out __vc4_hvs_stop_channel, the logic got inverted from if (condition) // stop channel to if (condition) goto out //stop channel out: and also changed the exact register writes used to stop the channel. Correct the logic so that the channel is actually stopped, and revert to the original register writes. Fixes: 6d01a106b4c8 ("drm/vc4: crtc: Move HVS init and close to a function") Reviewed-by: Maxime Ripard <mripard@kernel.org> Link: https://patchwork.freedesktop.org/patch/msgid/20240621152055.4180873-32-dave.stevenson@raspberrypi.com Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
2024-09-09drm/vc4: hvs: Enable SCALER_CONTROL early in HVS initTim Gover
Always enable SCALER_CONTROL before attempting other HVS operations. It's safe to write to some parts of the HVS but in general it's dangerous to do this because it can cause bus lockups. Signed-off-by: Tim Gover <tim.gover@raspberrypi.com> Reviewed-by: Maxime Ripard <mripard@kernel.org> Link: https://patchwork.freedesktop.org/patch/msgid/20240621152055.4180873-31-dave.stevenson@raspberrypi.com Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
2024-09-09drm/vc4: plane: Move the buffer offset out of the vc4_plane_stateDave Stevenson
The offset fields in vc4_plane_state are described as being the offset for each buffer in the bo, however it is used to store the complete DMA address that is then written into the register. The DMA address including the fb ofset can be retrieved using drm_fb_dma_get_gem_addr, and the offset adjustment due to clipping is local to vc4_plane_mode_set. Drop the offset field from the state, and compute the complete DMA address in vc4_plane_mode_set. Reviewed-by: Maxime Ripard <mripard@kernel.org> Link: https://patchwork.freedesktop.org/patch/msgid/20240621152055.4180873-30-dave.stevenson@raspberrypi.com Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
2024-09-09drm/vc4: hvs: Change prototype of __vc4_hvs_alloc to pass registersMaxime Ripard
The BCM2712 HVS has registers to report the size of the various SRAM the driver uses, and their size actually differ depending on the stepping. The initialisation of the memory pools happen in the __vc4_hvs_alloc() function that also allocates the main HVS structure, that will then hold the pointer to the memory mapping of the registers. This creates some kind of circular dependency that we can break by passing the mapping pointer as an argument for __vc4_hvs_alloc() to use to query to get the SRAM sizes and initialise the memory pools accordingly. Signed-off-by: Maxime Ripard <mripard@kernel.org> Reviewed-by: Maxime Ripard <mripard@kernel.org> Link: https://patchwork.freedesktop.org/patch/msgid/20240621152055.4180873-29-dave.stevenson@raspberrypi.com Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
2024-09-09drm/vc4: hvs: Rework LBM alignmentMaxime Ripard
With the introduction of the support for BCM2712, the check of whether we're running on vc5 or not to compute the LBM alignment requirement doesn't work anymore. Moreover, the LBM size will need to be computed in words for the BCM2712, while we've had sizes in bytes so far. Aligning on either 64 or 32 words is thus fairly harmful on BCM2712, so let's just explicitly align the size when needed, and then call drm_mm_insert_node_generic() with an alignment of 1. Signed-off-by: Maxime Ripard <mripard@kernel.org> Reviewed-by: Maxime Ripard <mripard@kernel.org> Link: https://patchwork.freedesktop.org/patch/msgid/20240621152055.4180873-28-dave.stevenson@raspberrypi.com Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
2024-09-09drm/vc4: plane: Change ptr0_offset to an arrayMaxime Ripard
The BCM2712 will have a fairly different dlist, that will feature one Pointer 0 word for each plane. Let's prepare by changing the ptr0_offset variable that holds the offset in a dlist of the pointer 0 word to an array. Signed-off-by: Maxime Ripard <mripard@kernel.org> Reviewed-by: Maxime Ripard <mripard@kernel.org> Link: https://patchwork.freedesktop.org/patch/msgid/20240621152055.4180873-27-dave.stevenson@raspberrypi.com Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
2024-09-09drm/vc4: hvs: Rename hvs_regs listMaxime Ripard
The HVS register set has been heavily modified in the BCM2712, and we'll thus need a separate debugfs_reg32 array for it. The name hvs_regs is thus a bit too generic, so let's rename it to something more specific. Signed-off-by: Maxime Ripard <mripard@kernel.org> Reviewed-by: Maxime Ripard <mripard@kernel.org> Link: https://patchwork.freedesktop.org/patch/msgid/20240621152055.4180873-26-dave.stevenson@raspberrypi.com Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
2024-09-09drm/vc4: hvs: Create cob_init functionMaxime Ripard
Just like the HVS itself, the COB parameters will be fairly different in the BCM2712. Let's move the COB parameters computation and its initialisation to a separate function that will be easier to extend in the future. Signed-off-by: Maxime Ripard <mripard@kernel.org> Reviewed-by: Maxime Ripard <mripard@kernel.org> Link: https://patchwork.freedesktop.org/patch/msgid/20240621152055.4180873-25-dave.stevenson@raspberrypi.com Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
2024-09-09drm/vc4: hvs: Create hw_init functionMaxime Ripard
Since the BCM2712 will feature a significantly different HVS, let's move the hardware initialisation part of our bind function into a separate function. That way, it will be easier to extend in the future. Signed-off-by: Maxime Ripard <mripard@kernel.org> Reviewed-by: Maxime Ripard <mripard@kernel.org> Link: https://patchwork.freedesktop.org/patch/msgid/20240621152055.4180873-24-dave.stevenson@raspberrypi.com Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
2024-09-09drm/vc4: hvs: Use switch statement to simplify vc4_hvs_get_fifo_from_outputMaxime Ripard
Since we'll support BCM2712 soon, let's move the logic behind vc4_hvs_get_fifo_from_output() to a switch to extend it more easily. Signed-off-by: Maxime Ripard <mripard@kernel.org> Reviewed-by: Maxime Ripard <mripard@kernel.org> Link: https://patchwork.freedesktop.org/patch/msgid/20240621152055.4180873-23-dave.stevenson@raspberrypi.com Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
2024-09-09drm/vc4: Make v3d paths unavailable on any generation newer than vc4Maxime Ripard
The V3D IP has been separate since BCM2711, so let's make sure we issue a WARN if we're running not only on BCM2711, but also anything newer. Signed-off-by: Maxime Ripard <mripard@kernel.org> Reviewed-by: Maxime Ripard <mripard@kernel.org> Link: https://patchwork.freedesktop.org/patch/msgid/20240621152055.4180873-22-dave.stevenson@raspberrypi.com Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
2024-09-09drm/vc4: Introduce generation number enumMaxime Ripard
With the introduction of the BCM2712 support, we will get yet another generation of display engine to support. The binary check of whether it's VC5 or not thus doesn't work anymore, especially since some parts of the driver will have changed with BCM2711, and some others with BCM2712. Let's introduce an enum to store the generation the driver is running on, which should provide more flexibility. Signed-off-by: Maxime Ripard <mripard@kernel.org> Reviewed-by: Maxime Ripard <mripard@kernel.org> Link: https://patchwork.freedesktop.org/patch/msgid/20240621152055.4180873-21-dave.stevenson@raspberrypi.com Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
2024-09-09drm/vc4: hvs: Remove ABORT_ON_EMPTY flagDom Cobley
ABORT_ON_EMPTY chooses whether the HVS abandons the current frame when it experiences an underflow, or attempts to continue. In theory the frame should be black from the point of underflow, compared to a shift of sebsequent pixels to the left. Unfortunately it seems to put the HVS is a bad state where it is not possible to recover simply. This typically requires a reboot following the 'flip done timed out message'. Discussion with Broadcom has suggested we don't use this flag. All their testing is done with it disabled. Additionally setting BLANK_INSERT_EN causes the HDMI to output blank pixels on an underflow which avoids it losing sync. After this change a 'flip done timed out' due to sdram bandwidth starvation or too low a clock is recoverable once the situation improves. Signed-off-by: Dom Cobley <popcornmix@gmail.com> Reviewed-by: Maxime Ripard <mripard@kernel.org> Link: https://patchwork.freedesktop.org/patch/msgid/20240621152055.4180873-20-dave.stevenson@raspberrypi.com Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
2024-09-09drm/vc4: hvs: Remove incorrect limit from hvs_dlist debugfs functionDave Stevenson
The debugfs function to dump dlists aborted at 256 bytes, when actually the dlist memory is generally significantly larger but varies based on SoC. We already have the correct limit in __vc4_hvs_alloc, so store it for use in the debugfs dlist function. Fixes: c6dac00340fc ("drm/vc4: hvs: Add debugfs node that dumps the current display lists") Reviewed-by: Maxime Ripard <mripard@kernel.org> Link: https://patchwork.freedesktop.org/patch/msgid/20240621152055.4180873-19-dave.stevenson@raspberrypi.com Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
2024-09-09drm/vc4: hvs: Fix dlist debug not resetting the next entry pointerDave Stevenson
The debug function to display the dlists didn't reset next_entry_start when starting each display, so resulting in not stopping the list at the correct place. Fixes: c6dac00340fc ("drm/vc4: hvs: Add debugfs node that dumps the current display lists") Reviewed-by: Maxime Ripard <mripard@kernel.org> Link: https://patchwork.freedesktop.org/patch/msgid/20240621152055.4180873-18-dave.stevenson@raspberrypi.com Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
2024-09-09drm/vc4: hdmi: Avoid hang with debug registers when suspendedDom Cobley
Trying to read /sys/kernel/debug/dri/1/hdmi1_regs when the hdmi is disconnected results in a fatal system hang. This is due to the pm suspend code disabling the dvp clock. That is just a gate of the 108MHz clock in DVP_HT_RPI_MISC_CONFIG, which results in accesses hanging AXI bus. Protect against this. Fixes: 25eb441d55d4 ("drm/vc4: hdmi: Add all the vc5 HDMI registers into the debugfs dumps") Signed-off-by: Dom Cobley <popcornmix@gmail.com> Reviewed-by: Maxime Ripard <mripard@kernel.org> Link: https://patchwork.freedesktop.org/patch/msgid/20240621152055.4180873-17-dave.stevenson@raspberrypi.com Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
2024-09-09drm/vc4: plane: YUV planes require vertical scaling to always be enabledDave Stevenson
It has been observed that a YUV422 unity scaled plane isn't displayed. Enabling vertical scaling on the UV planes solves this. There is already a similar clause to always enable horizontal scaling on the UV planes. Reviewed-by: Maxime Ripard <mripard@kernel.org> Link: https://patchwork.freedesktop.org/patch/msgid/20240621152055.4180873-16-dave.stevenson@raspberrypi.com Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
2024-09-09drm/vc4: hvs: Don't write gamma luts on 2711Dave Stevenson
The gamma block has changed in 2711, therefore writing the lut in vc4_hvs_lut_load is incorrect. Whilst the gamma property isn't created for 2711, it is called from vc4_hvs_init_channel, so abort if attempted. Fixes: c54619b0bfb3 ("drm/vc4: Add support for the BCM2711 HVS5") Reviewed-by: Maxime Ripard <mripard@kernel.org> Link: https://patchwork.freedesktop.org/patch/msgid/20240621152055.4180873-15-dave.stevenson@raspberrypi.com Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
generated by cgit v1.2.3 (git 2.51.0) at 2026-11-09 13:19:05 +0000