summaryrefslogtreecommitdiff
path: root/drivers/gpu
AgeCommit message (Collapse)Author
2024-10-17drm/xe/gsc: Update handling of xe_force_wake_get returnHimal Prasad Ghimiray
xe_force_wake_get() now returns the reference count-incremented domain mask. If it fails for individual domains, the return value will always be 0. However, for XE_FORCEWAKE_ALL, it may return a non-zero value even in the event of failure. Update the return handling of xe_force_wake_get() to reflect this behavior, and ensure that the return value is passed as input to xe_force_wake_put(). v3 - return xe_wakeref_t instead of int in xe_force_wake_get() v5 - return unsigned int for xe_force_wake_get() - No need to WARN from caller in case of forcewake get failure. v7 - Fix commit message Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Lucas De Marchi <lucas.demarchi@intel.com> Signed-off-by: Himal Prasad Ghimiray <himal.prasad.ghimiray@intel.com> Reviewed-by: Badal Nilawar <badal.nilawar@intel.com> Reviewed-by: Nirmoy Das <nirmoy.das@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241014075601.2324382-9-himal.prasad.ghimiray@intel.com Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2024-10-17drm/xe/hdcp: Update handling of xe_force_wake_get returnHimal Prasad Ghimiray
xe_force_wake_get() now returns the reference count-incremented domain mask. If it fails for individual domains, the return value will always be 0. However, for XE_FORCEWAKE_ALL, it may return a non-zero value even in the event of failure. Update the return handling of xe_force_wake_get() to reflect this behavior, and ensure that the return value is passed as input to xe_force_wake_put(). v3 - return xe_wakeref_t instead of int in xe_force_wake_get() v5 - return unsigned int for xe_force_wake_get() v7 - Fix commit message Cc: Suraj Kandpal <suraj.kandpal@intel.com> Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Lucas De Marchi <lucas.demarchi@intel.com> Signed-off-by: Himal Prasad Ghimiray <himal.prasad.ghimiray@intel.com> Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com> Reviewed-by: Nirmoy Das <nirmoy.das@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241014075601.2324382-8-himal.prasad.ghimiray@intel.com Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2024-10-17drm/xe/device: Update handling of xe_force_wake_get returnHimal Prasad Ghimiray
xe_force_wake_get() now returns the reference count-incremented domain mask. If it fails for individual domains, the return value will always be 0. However, for XE_FORCEWAKE_ALL, it may return a non-zero value even in the event of failure. Update the return handling of xe_force_wake_get() to reflect this behavior, and ensure that the return value is passed as input to xe_force_wake_put(). v3 - return xe_wakeref_t instead of int in xe_force_wake_get() - xe_force_wake_put() error doesn't need to be escalated/considered as probing error. It internally WARNS on domain ack failure. v5 - return unsigned int xe_force_wake_get() v7 - Fix commit message(Badal) v9 - s/uint/unsigned int (Nikula) Cc: Jani Nikula <jani.nikula@intel.com> Cc: Badal Nilawar <badal.nilawar@intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Himal Prasad Ghimiray <himal.prasad.ghimiray@intel.com> Reviewed-by: Nirmoy Das <nirmoy.das@intel.com> Reviewed-by: Badal Nilawar <badal.nilawar@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241014075601.2324382-7-himal.prasad.ghimiray@intel.com Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2024-10-17drm/xe: Modify xe_force_wake_put to handle _get returned maskHimal Prasad Ghimiray
Instead of calling xe_force_wake_put on all domains that were input to xe_force_wake_get, call _put only on the domains whose reference counts were successfully incremented by the _get call. Since the return value of _get can be a mask that does not match any specific value in the enum xe_force_wake_domains, change the input parameter of _put to unsigned int. v3 - Move WARN to this patch (Badal) - use xe_gt_WARN instead of XE_WARN (Michal) - Stop using xe_force_wake_domains for non enum values. - Remove kernel-doc from this patch (Badal) -v5 - Fix global awake_domain -v6 - put all initialized domains in case of FORCEWAKE_ALL. - Modify ret variable name (Michal) - Modify input var name (Michal) - Modify commit message and warn (Badal) -v9 - Add assert condition. Cc: Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: Badal Nilawar <badal.nilawar@intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Lucas De Marchi <lucas.demarchi@intel.com> Cc: Nirmoy Das <nirmoy.das@intel.com> Reviewed-by: Badal Nilawar <badal.nilawar@intel.com> Signed-off-by: Himal Prasad Ghimiray <himal.prasad.ghimiray@intel.com> Reviewed-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Reviewed-by: Nirmoy Das <nirmoy.das@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241014075601.2324382-6-himal.prasad.ghimiray@intel.com Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2024-10-17drm/xe: Error handling in xe_force_wake_get()Himal Prasad Ghimiray
If an acknowledgment timeout occurs for a forcewake domain awake request, do not increment the reference count for the domain. This ensures that subsequent _get calls do not incorrectly assume the domain is awake. The return value is a mask of domains that got refcounted, and these domains need to be provided for subsequent xe_force_wake_put call. While at it, add simple kernel-doc for xe_force_wake_get() v3 - Use explicit type for mask (Michal/Badal) - Improve kernel-doc (Michal) - Use unsigned int instead of abusing enum (Michal) v5 - Use unsigned int for return (MattB/Badal/Rodrigo) - use xe_gt_WARN for domain awake ack failure (Badal/Rodrigo) v6 - Change XE_FORCEWAKE_ALL to single bit, this helps accommodate actually refcounted domains in return. (Michal) - Modify commit message and warn message (Badal) - Remove unnecessary information in kernel-doc (Michal) v7 - Add assert condition for valid input domains (Badal) v9 - Update kernel-doc and simplify conditions (Michal) Cc: Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: Badal Nilawar <badal.nilawar@intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Lucas De Marchi <lucas.demarchi@intel.com> Cc: Nirmoy Das <nirmoy.das@intel.com> Reviewed-by: Badal Nilawar <badal.nilawar@intel.com> Reviewed-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Signed-off-by: Himal Prasad Ghimiray <himal.prasad.ghimiray@intel.com> Reviewed-by: Nirmoy Das <nirmoy.das@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241014075601.2324382-5-himal.prasad.ghimiray@intel.com Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2024-10-17drm/xe/forcewake: Add a helper xe_force_wake_ref_has_domain()Himal Prasad Ghimiray
The helper xe_force_wake_ref_has_domain() checks if the input domain has been successfully reference-counted and awakened in the reference. v2 - Fix commit message and kernel-doc (Michal) - Remove unnecessary paranthesis (Michal) Cc: Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: Badal Nilawar <badal.nilawar@intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Himal Prasad Ghimiray <himal.prasad.ghimiray@intel.com> Reviewed-by: Badal Nilawar <badal.nilawar@intel.com> Reviewed-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241014075601.2324382-4-himal.prasad.ghimiray@intel.com Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2024-10-17drm/xe/forcewake: Change awake_domain datatypeHimal Prasad Ghimiray
Change the datatype of awake_domains to unsigned int to accommodate values that differ from the enum xe_force_wake_domains. Cc: Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: Badal Nilawar <badal.nilawar@intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Himal Prasad Ghimiray <himal.prasad.ghimiray@intel.com> Reviewed-by: Badal Nilawar <badal.nilawar@intel.com> Reviewed-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241014075601.2324382-3-himal.prasad.ghimiray@intel.com Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2024-10-17drm/xe: Add member initialized_domains to xe_force_wake()Himal Prasad Ghimiray
This field serves as a bitmask representing all initialized forcewake domains on the GT. v2 - Move awake_domains datatype change out of this patch (Michal) - Rename domain_init to init_domain (Michal) - optimize alignment (Michal) Cc: Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: Badal Nilawar <badal.nilawar@intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Himal Prasad Ghimiray <himal.prasad.ghimiray@intel.com> Reviewed-by: Badal Nilawar <badal.nilawar@intel.com> Reviewed-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241014075601.2324382-2-himal.prasad.ghimiray@intel.com Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2024-10-17drm/rockchip: Add basic RK3588 HDMI output supportCristian Ciocaltea
The RK3588 SoC family integrates the newer Synopsys DesignWare HDMI 2.1 Quad-Pixel (QP) TX controller IP and a HDMI/eDP TX Combo PHY based on a Samsung IP block. Add just the basic support for now, i.e. RGB output up to 4K@60Hz, without audio, CEC or any of the HDMI 2.1 specific features. Co-developed-by: Algea Cao <algea.cao@rock-chips.com> Signed-off-by: Algea Cao <algea.cao@rock-chips.com> Tested-by: Heiko Stuebner <heiko@sntech.de> Reviewed-by: Maxime Ripard <mripard@kernel.org> Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241016-b4-rk3588-bridge-upstream-v10-3-87ef92a6d14e@collabora.com Signed-off-by: Maxime Ripard <mripard@kernel.org>
2024-10-17drm/bridge: synopsys: Add DW HDMI QP TX Controller support libraryCristian Ciocaltea
The Synopsys DesignWare HDMI 2.1 Quad-Pixel (QP) TX Controller IP supports the following features, among others: * Fixed Rate Link (FRL) * Display Stream Compression (DSC) * 4K@120Hz and 8K@60Hz video modes * Variable Refresh Rate (VRR) including Quick Media Switching (QMS), aka Cinema VRR * Fast Vactive (FVA), aka Quick Frame Transport (QFT) * SCDC I2C DDC access * TMDS Scrambler enabling 2160p@60Hz with RGB/YCbCr4:4:4 * YCbCr4:2:0 enabling 2160p@60Hz at lower HDMI link speeds * Multi-stream audio * Enhanced Audio Return Channel (EARC) Add library containing common helpers to enable basic support, i.e. RGB output up to 4K@30Hz, without audio, CEC or any HDMI 2.1 specific features. Co-developed-by: Algea Cao <algea.cao@rock-chips.com> Signed-off-by: Algea Cao <algea.cao@rock-chips.com> Tested-by: Heiko Stuebner <heiko@sntech.de> Reviewed-by: Maxime Ripard <mripard@kernel.org> Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com> Acked-by: Maxime Ripard <mripard@kernel.org> Link: https://patchwork.freedesktop.org/patch/msgid/20241016-b4-rk3588-bridge-upstream-v10-1-87ef92a6d14e@collabora.com Signed-off-by: Maxime Ripard <mripard@kernel.org>
2024-10-17drm/xe: Add caller info to xe_gt_reset_asyncNirmoy Das
Add caller info to the xe_gt_reset_async() to help debug issues. v2: s/%pS/%ps(Matt) Cc: Matthew Auld <matthew.auld@intel.com> Link: https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/2874 Reviewed-by: Matthew Auld <matthew.auld@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241016141717.881143-1-nirmoy.das@intel.com Signed-off-by: Nirmoy Das <nirmoy.das@intel.com>
2024-10-17drm/i915/dp: Fix memory leak in parse_lfp_panel_dtd()Shuicheng Lin
The function parse_lfp_panel_dtd() is called when the driver attempts to initialize the eDP connector, and it allocates memory, which is recorded in panel->vbt.lfp_vbt_mode. However, since no eDP panel is connected, the driver fails at intel_edp_init_dpcd() and follows the failure path. Unfortunately, the allocated memory is not freed in this case. To fix this issue, free the memory in the failure path. leak info from kmemleak: " unreferenced object 0xffff8881252f8800 (size 128): comm "systemd-udevd", pid 192, jiffies 4294896880 hex dump (first 32 bytes): e8 fd 00 00 00 04 18 04 a0 04 40 05 00 00 00 03 ..........@..... 03 03 09 03 26 03 00 00 0a 00 00 00 00 00 00 00 ....&........... backtrace (crc 7448f6b4): [<ffffffff82475c9b>] kmemleak_alloc+0x4b/0x80 [<ffffffff814bb50e>] __kmalloc_cache_noprof+0x2be/0x390 [<ffffffffa069862c>] intel_bios_init_panel+0x1c4c/0x2720 [xe] [<ffffffffa0699123>] intel_bios_init_panel_early+0x13/0x20 [xe] [<ffffffffa06fceb9>] intel_dp_init_connector+0x2f9/0x1080 [xe] [<ffffffffa06c370a>] intel_ddi_init+0xbba/0xf50 [xe] [<ffffffffa069b906>] intel_bios_for_each_encoder+0x36/0x60 [xe] [<ffffffffa06d7bd6>] intel_setup_outputs+0x206/0x450 [xe] [<ffffffffa06dad33>] intel_display_driver_probe_nogem+0x163/0x1f0 [xe] [<ffffffffa0680fc7>] xe_display_init_noaccel+0x27/0x70 [xe] [<ffffffffa05b30d6>] xe_device_probe+0x806/0x9a0 [xe] [<ffffffffa0612f0f>] xe_pci_probe+0x31f/0x590 [xe] [<ffffffff81b41718>] local_pci_probe+0x48/0xb0 [<ffffffff81b432c8>] pci_device_probe+0xc8/0x280 [<ffffffff81d5dde8>] really_probe+0xf8/0x390 [<ffffffff81d5e11a>] __driver_probe_device+0x8a/0x170 " v2 (Jani): -use intel_bios_fini_panel() to pair with intel_bios_init_panel_early() Signed-off-by: Shuicheng Lin <shuicheng.lin@intel.com> Cc: Jani Nikula <jani.nikula@intel.com> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241016150154.1466131-1-shuicheng.lin@intel.com
2024-10-17drm/sched: Further optimise drm_sched_entity_push_jobTvrtko Ursulin
Having removed one re-lock cycle on the entity->lock in a patch titled "drm/sched: Optimise drm_sched_entity_push_job", with only a tiny bit larger refactoring we can do the same optimisation on the rq->lock. (Currently both drm_sched_rq_add_entity() and drm_sched_rq_update_fifo_locked() take and release the same lock.) To achieve this we make drm_sched_rq_update_fifo_locked() and drm_sched_rq_add_entity() expect the rq->lock to be held. We also align drm_sched_rq_update_fifo_locked(), drm_sched_rq_add_entity() and drm_sched_rq_remove_fifo_locked() function signatures, by adding rq as a parameter to the latter. v2: * Fix after rebase of the series. * Avoid naming inconsistency between drm_sched_rq_add/remove. (Christian) Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@igalia.com> Cc: Christian König <christian.koenig@amd.com> Cc: Alex Deucher <alexander.deucher@amd.com> Cc: Luben Tuikov <ltuikov89@gmail.com> Cc: Matthew Brost <matthew.brost@intel.com> Cc: Philipp Stanner <pstanner@redhat.com> Reviewed-by: Christian König <christian.koenig@amd.com> Reviewed-by: Philipp Stanner <pstanner@redhat.com> Signed-off-by: Philipp Stanner <pstanner@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241016122013.7857-6-tursulin@igalia.com
2024-10-17drm/sched: Re-group and rename the entity run-queue lockTvrtko Ursulin
When writing to a drm_sched_entity's run-queue, writers are protected through the lock drm_sched_entity.rq_lock. This naming, however, frequently collides with the separate internal lock of struct drm_sched_rq, resulting in uses like this: spin_lock(&entity->rq_lock); spin_lock(&entity->rq->lock); Rename drm_sched_entity.rq_lock to improve readability. While at it, re-order that struct's members to make it more obvious what the lock protects. v2: * Rename some rq_lock straddlers in kerneldoc, improve commit text. (Philipp) Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@igalia.com> Suggested-by: Christian König <christian.koenig@amd.com> Cc: Alex Deucher <alexander.deucher@amd.com> Cc: Luben Tuikov <ltuikov89@gmail.com> Cc: Matthew Brost <matthew.brost@intel.com> Cc: Philipp Stanner <pstanner@redhat.com> Reviewed-by: Christian König <christian.koenig@amd.com> [pstanner: Fix typo in docstring] Signed-off-by: Philipp Stanner <pstanner@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241016122013.7857-5-tursulin@igalia.com
2024-10-17drm/sched: Stop setting current entity in FIFO modeTvrtko Ursulin
It does not seem there is a need to set the current entity in FIFO mode since ot only serves as being a "cursor" in round-robin mode. Even if scheduling mode is changed at runtime the change in behaviour is simply to restart from the first entity, instead of continuing in RR mode from where FIFO left it, and that sounds completely fine. Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@igalia.com> Cc: Christian König <christian.koenig@amd.com> Cc: Alex Deucher <alexander.deucher@amd.com> Cc: Luben Tuikov <ltuikov89@gmail.com> Cc: Matthew Brost <matthew.brost@intel.com> Cc: Philipp Stanner <pstanner@redhat.com> Acked-by: Christian König <christian.koenig@amd.com> Reviewed-by: Philipp Stanner <pstanner@redhat.com> Signed-off-by: Philipp Stanner <pstanner@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241016122013.7857-3-tursulin@igalia.com
2024-10-17drm/sched: Optimise drm_sched_entity_push_jobTvrtko Ursulin
In FIFO mode (which is the default), both drm_sched_entity_push_job() and drm_sched_rq_update_fifo(), where the latter calls the former, are currently taking and releasing the same entity->rq_lock. We can avoid that design inelegance, and also have a miniscule efficiency improvement on the submit from idle path, by introducing a new drm_sched_rq_update_fifo_locked() helper and pulling up the lock taking to its callers. v2: * Remove drm_sched_rq_update_fifo() altogether. (Christian) v3: * Improved commit message. (Philipp) Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@igalia.com> Cc: Christian König <christian.koenig@amd.com> Cc: Alex Deucher <alexander.deucher@amd.com> Cc: Luben Tuikov <ltuikov89@gmail.com> Cc: Matthew Brost <matthew.brost@intel.com> Cc: Philipp Stanner <pstanner@redhat.com> Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Philipp Stanner <pstanner@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241016122013.7857-2-tursulin@igalia.com
2024-10-17Merge tag 'drm-msm-fixes-2024-10-16' of ↵Dave Airlie
https://gitlab.freedesktop.org/drm/msm into drm-fixes Fixes for v6.12 Display: - move CRTC resource assignment to atomic_check otherwise to make consecutive calls to atomic_check() consistent - fix rounding / sign-extension issues with pclk calculation in case of DSC - cleanups to drop incorrect null checks in dpu snapshots - fix to use kvzalloc in dpu snapshot to avoid allocation issues in heavily loaded system cases - Fix to not program merge_3d block if dual LM is not being used - Fix to not flush merge_3d block if its not enabled otherwise this leads to false timeouts GPU: - a7xx: add a fence wait before SMMU table update Signed-off-by: Dave Airlie <airlied@redhat.com> From: Rob Clark <robdclark@gmail.com> Link: https://patchwork.freedesktop.org/patch/msgid/CAF6AEGsp3Zbd_H3FhHdRz9yCYA4wxX4SenpYRSk=Mx2d8GMSuQ@mail.gmail.com
2024-10-17drm/ast: vga: Clear EDID if no display is connectedThomas Zimmermann
Do not keep the obsolete EDID around after unplugging the display from the connector. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Fixes: 2a2391f857cd ("drm/ast: vga: Transparently handle BMC support") Cc: Thomas Zimmermann <tzimmermann@suse.de> Cc: Jocelyn Falempe <jfalempe@redhat.com> Cc: Dave Airlie <airlied@redhat.com> Cc: dri-devel@lists.freedesktop.org Reviewed-by: Jocelyn Falempe <jfalempe@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241015065113.11790-3-tzimmermann@suse.de
2024-10-17drm/ast: sil164: Clear EDID if no display is connectedThomas Zimmermann
Do not keep the obsolete EDID around after unplugging the display from the connector. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Fixes: d20c2f846428 ("drm/ast: sil164: Transparently handle BMC support") Cc: Thomas Zimmermann <tzimmermann@suse.de> Cc: Jocelyn Falempe <jfalempe@redhat.com> Cc: Dave Airlie <airlied@redhat.com> Cc: dri-devel@lists.freedesktop.org Reviewed-by: Jocelyn Falempe <jfalempe@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241015065113.11790-2-tzimmermann@suse.de
2024-10-17Revert "drm/mgag200: Add vblank support"Thomas Zimmermann
This reverts commit 6c9e14ee9f519ee605a3694fbfa4711284781d22. This reverts commit d5070c9b29440c270b534bbacd636b8fa558e82b. This reverts commit 89c6ea2006e2d39b125848fb0195c08fa0b354be. The VLINE interrupt doesn't work correctly on G200SE-A (at least). We have also seen missing interrupts on G200ER. So revert vblank support. Fixes frozen displays and warnings about missed vblanks. [ 33.818362] [CRTC:34:crtc-0] vblank wait timed out From the vblank code, the driver only keeps the register constants and the line that disables all interrupts in mgag200_device_init(). Both is still useful without vblank handling. Reported-by: Tony Luck <tony.luck@intel.com> Closes: https://lore.kernel.org/dri-devel/Zvx6lSi7oq5xvTZb@agluck-desk3.sc.intel.com/raw Tested-by: Tony Luck <tony.luck@intel.com> Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Jocelyn Falempe <jfalempe@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241015063932.8620-1-tzimmermann@suse.de
2024-10-16drm/amdgpu/swsmu: default to fullscreen 3D profile for dGPUsAlex Deucher
This uses more aggressive hueristics than the the bootup default profile. On windows the OS has a special fullscreen 3D mode where this is used. Since we don't have the equivalent on Linux default to this profile for dGPUs. Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/3618 Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/1500 Link: https://gitlab.freedesktop.org/drm/amd/-/issues/3131 Reviewed-by: Kenneth Feng <kenneth.feng@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> (cherry picked from commit 336568de918e08c825b3b1cbe2ec809f2fc26d94)
2024-10-16drm/xe: Enlarge the invalidation timeout from 150 to 500Shuicheng Lin
There are error messages like below that are occurring during stress testing: "[ 31.004009] xe 0000:03:00.0: [drm] ERROR GT0: Global invalidation timeout". Previously it was hitting this 3 out of 1000 executions of warm reboot. After raising it to 500, 1000 warm reboot executions passed and it didn't fail. Due to the way xe_mmio_wait32() is implemented, the timeout is able to expire early when the register matches the expected value due to the wait increments starting small. So, the larger timeout value should have no effect during normal use cases. v2 (Jonathan): - rework the commit message v3 (Lucas): - add conclusive message for the fail rate and test case v4: - add suggested-by Suggested-by: Jia Yao <jia.yao@intel.com> Signed-off-by: Shuicheng Lin <shuicheng.lin@intel.com> Cc: Lucas De Marchi <lucas.demarchi@intel.com> Cc: Matthew Auld <matthew.auld@intel.com> Cc: Nirmoy Das <nirmoy.das@intel.com> Reviewed-by: Jonathan Cavitt <jonathan.cavitt@intel.com> Tested-by: Zongyao Bai <zongyao.bai@intel.com> Reviewed-by: Nirmoy Das <nirmoy.das@intel.com> Signed-off-by: Matthew Auld <matthew.auld@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241015161207.1373401-1-shuicheng.lin@intel.com
2024-10-16drm/xe/xe3lpg: Extend Wa_18034896535 to Xe3_LPG.Shekhar Chauhan
Extend Wa_18034896535 to Xe3_LPG (IP 30.00), steppings A0 to B0. BSpec: 56852 Signed-off-by: Shekhar Chauhan <shekhar.chauhan@intel.com> Reviewed-by: Sai Teja Pottumuttu <sai.teja.pottumuttu@intel.com> Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241015161938.845996-1-shekhar.chauhan@intel.com
2024-10-16drm/i915/panelreplay: Panel replay workaround with VRRAnimesh Manna
Panel Replay VSC SDP not getting sent when VRR is enabled and W1 and W2 are 0. So Program Set Context Latency in TRANS_SET_CONTEXT_LATENCY register to at least a value of 1. The same is applicable for PSR1/PSR2 as well. HSD: 14015406119 v1: Initial version. v2: Update timings stored in adjusted_mode struct. [Ville] v3: Add WA in compute_config(). [Ville] v4: - Add DISPLAY_VER() check and improve code comment. [Rodrigo] - Introduce centralized intel_crtc_vblank_delay(). [Ville] v5: Move to crtc_compute_config(). [Ville] v6: Restrict DISPLAY_VER till 14. [Mitul] v7: - Corrected code-comment. [Mitul] - dev_priv local variable removed. [Jani] v8: Introduce late_compute_config() which will take care late vblank-delay adjustment. [Ville] v9: Implementation simplified and split into multiple patches. v10: - Split vrr changes and use struct intel_display in DISPLAY_VER(). [Ankit] - Use for_each_new_intel_connector_in_state(). [Jani] v11: Remove loop and use flipline instead of vrr.enable flag. [Ville] v12: - Use intel_Vrr_possible helper. - Correct flag check for flipline. v13: - Refactor workaround [Jonathan] - Drop the comment around woraround number. [Ville] Signed-off-by: Animesh Manna <animesh.manna@intel.com> Signed-off-by: Mitul Golani <mitulkumar.ajitkumar.golani@intel.com> Reviewed-by: Jonathan Cavitt <jonathan.cavitt@intel.com> [vsyrjala: Make adjusted_modeg const, and drop redundant parens] Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241010040503.1795399-4-mitulkumar.ajitkumar.golani@intel.com
2024-10-16drm/i915/vrr: Split vrr-compute-config in two phasesAnimesh Manna
As vrr guardband calculation is dependent on modified vblank start so better to compute late after all vblank adjustement. v1: Initial version. v2: Split in a separate patch from panel-replay workaround. [Ankit] v3: Add a function for late vrr related computation. [Ville] v4: Use flipline instead of vrr.enable and some cosmetic changes. [Ville] v5: Use intel_vrr_possible helper. Signed-off-by: Animesh Manna <animesh.manna@intel.com> Signed-off-by: Mitul Golani <mitulkumar.ajitkumar.golani@intel.com> Reviewed-by: Jonathan Cavitt <jonathan.cavitt@intel.com> [vsyrjala: Make adjusted_mode const] Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241010040503.1795399-3-mitulkumar.ajitkumar.golani@intel.com
2024-10-16drm/i915/vrr: Add helper to check if vrr possibleMitul Golani
Add helper to check if vrr is possible based on flipline is computed. --v1: return just flipline instead using ternary operator [Jonathan, Ville]. Signed-off-by: Mitul Golani <mitulkumar.ajitkumar.golani@intel.com> Reviewed-by: Jonathan Cavitt <jonathan.cavitt@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241010040503.1795399-2-mitulkumar.ajitkumar.golani@intel.com
2024-10-16drm/i915/display: Don't allow tile4 framebuffer to do hflip on display20 or ↵Juha-Pekka Heikkila
greater On display ver 20 onwards tile4 is not supported with horizontal flip Bspec: 69853 Signed-off-by: Juha-Pekka Heikkila <juhapekka.heikkila@gmail.com> Reviewed-by: Sai Teja Pottumuttu <sai.teja.pottumuttu@intel.com> Signed-off-by: Mika Kahola <mika.kahola@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241007182841.2104740-1-juhapekka.heikkila@gmail.com (cherry picked from commit 73e8e2f9a358caa005ed6e52dcb7fa2bca59d132) Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
2024-10-16drm/xe/bmg: improve cache flushing behaviourMatthew Auld
The BSpec says that EN_L3_RW_CCS_CACHE_FLUSH must be toggled on for manual global invalidation to take effect and actually flush device cache, however this also turns on flushing for things like pipecontrol, which occurs between submissions for compute/render. This sounds like massive overkill for our needs, where we already have the manual flushing on the display side with the global invalidation. Some observations on BMG: 1. Disabling l2 caching for host writes and stubbing out the driver global invalidation but keeping EN_L3_RW_CCS_CACHE_FLUSH enabled, has no impact on wb-transient-vs-display IGT, which makes sense since the pipecontrol is now flushing the device cache after the render copy. Without EN_L3_RW_CCS_CACHE_FLUSH the test then fails, which is also expected since device cache is now dirty and display engine can't see the writes. 2. Disabling EN_L3_RW_CCS_CACHE_FLUSH, but keeping the driver global invalidation also has no impact on wb-transient-vs-display. This suggests that the global invalidation still works as expected and is flushing the device cache without EN_L3_RW_CCS_CACHE_FLUSH turned on. With that drop EN_L3_RW_CCS_CACHE_FLUSH. This helps some workloads since we no longer flush the device cache between submissions as part of pipecontrol. Edit: We now also have clarification from HW side that BSpec was indeed wrong here. v2: - Rebase and update commit message. BSpec: 71718 Signed-off-by: Matthew Auld <matthew.auld@intel.com> Cc: Vitasta Wattal <vitasta.wattal@intel.com> Cc: Matt Roper <matthew.d.roper@intel.com> Cc: Nirmoy Das <nirmoy.das@intel.com> Reviewed-by: Nirmoy Das <nirmoy.das@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241007074541.33937-2-matthew.auld@intel.com (cherry picked from commit 67ec9f87bd6c57db1251bb2244d242f7ca5a0b6a) [ Fix conflict due to changed xe_mmio_write32() signature ] Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
2024-10-16drm/xe/xe_sync: initialise ufence.signalledMatthew Auld
We can incorrectly think that the fence has signalled, if we get a non-zero value here from the kmalloc, which is quite plausible. Just use kzalloc to prevent stuff like this. Fixes: 977e5b82e090 ("drm/xe: Expose user fence from xe_sync_entry") Signed-off-by: Matthew Auld <matthew.auld@intel.com> Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com> Cc: Matthew Brost <matthew.brost@intel.com> Cc: Nirmoy Das <nirmoy.das@intel.com> Cc: <stable@vger.kernel.org> # v6.10+ Reviewed-by: Nirmoy Das <nirmoy.das@intel.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241011133633.388008-2-matthew.auld@intel.com (cherry picked from commit 26f69e88dcc95fffc62ed2aea30ad7b1fdf31fdb) Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
2024-10-16drm/xe/ufence: ufence can be signaled right after wait_wokenNirmoy Das
do_comapre() can return success after a timedout wait_woken() which was treated as -ETIME. The loop calling wait_woken() sets correct err so there is no need to re-evaluate err. v2: Remove entire check that reevaluate err at the end(Matt) Fixes: e670f0b4ef24 ("drm/xe/uapi: Return correct error code for xe_wait_user_fence_ioctl") Link: https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/1630 Cc: stable@vger.kernel.org # v6.8+ Cc: Bommu Krishnaiah <krishnaiah.bommu@intel.com> Cc: Matthew Auld <matthew.auld@intel.com> Cc: Matthew Brost <matthew.brost@intel.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com> Reviewed-by: Matthew Auld <matthew.auld@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241011151029.4160630-1-nirmoy.das@intel.com Signed-off-by: Nirmoy Das <nirmoy.das@intel.com> (cherry picked from commit ec7e6a1d527755fc3c7a3303eaa5577aac5cf6be) Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
2024-10-16drm/xe: Use bookkeep slots for external BO's in exec IOCTLMatthew Brost
Fix external BO's dma-resv usage in exec IOCTL using bookkeep slots rather than write slots. This leaves syncing to user space rather than the KMD blindly enforcing write semantics on every external BO. Fixes: dd08ebf6c352 ("drm/xe: Introduce a new DRM driver for Intel GPUs") Cc: José Roberto de Souza <jose.souza@intel.com> Cc: Kenneth Graunke <kenneth.w.graunke@intel.com> Cc: Paulo Zanoni <paulo.r.zanoni@intel.com> Reported-by: Simona Vetter <simona.vetter@ffwll.ch> Closes: https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/2673 Signed-off-by: Matthew Brost <matthew.brost@intel.com> Reviewed-by: José Roberto de Souza <jose.souza@intel.com> Reviewed-by: Kenneth Graunke <kenneth@whitecape.org> Link: https://patchwork.freedesktop.org/patch/msgid/20240911152622.903058-1-matthew.brost@intel.com (cherry picked from commit b8b1163248759ba18509f7443a2d19b15b4c1df8) Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
2024-10-16drm/xe/query: Increase timestamp widthLucas De Marchi
Starting with Xe2 the timestamp is a full 64 bit counter, contrary to the 36 bit that was available before. Although 36 should be sufficient for any reasonable delta calculation (for Xe2, of about 30min), it's surprising to userspace to get something truncated. Also if the timestamp being compared to is coming from the GPU and the application is not careful enough to apply the width there, a delta calculation would be wrong. Extend it to full 64-bits starting with Xe2. v2: Expand width=64 to media gt, as it's just a wrong tagging in the spec - empirical tests show it goes beyond 36 bits and match the engines for the main gt Bspec: 60411 Cc: Szymon Morek <szymon.morek@intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241011035618.1057602-1-lucas.demarchi@intel.com Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com> (cherry picked from commit 9d559cdcb21f42188d4c3ff3b4fe42b240f4af5d) Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
2024-10-16drm/xe: Don't free job in TDRMatthew Brost
Freeing job in TDR is not safe as TDR can pass the run_job thread resulting in UAF. It is only safe for free job to naturally be called by the scheduler. Rather free job in TDR, add to pending list. Closes: https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/2811 Cc: Matthew Auld <matthew.auld@intel.com> Fixes: e275d61c5f3f ("drm/xe/guc: Handle timing out of signaled jobs gracefully") Signed-off-by: Matthew Brost <matthew.brost@intel.com> Reviewed-by: Matthew Auld <matthew.auld@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241003001657.3517883-3-matthew.brost@intel.com (cherry picked from commit ea2f6a77d0c40d97f4a4dc93fee4afe15d94926d) Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
2024-10-16drm/xe: Take job list lock in xe_sched_add_pending_jobMatthew Brost
A fragile micro optimization in xe_sched_add_pending_job relied on both the GPU scheduler being stopped and fence signaling stopped to safely add a job to the pending list without the job list lock in xe_sched_add_pending_job. Remove this optimization and just take the job list lock. Fixes: 7ddb9403dd74 ("drm/xe: Sample ctx timestamp to determine if jobs have timed out") Signed-off-by: Matthew Brost <matthew.brost@intel.com> Reviewed-by: Matthew Auld <matthew.auld@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241003001657.3517883-2-matthew.brost@intel.com (cherry picked from commit 90521df5fc43980e4575bd8c5b1cb62afe1a9f5f) Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
2024-10-16drm/xe: fix unbalanced rpm put() with declare_wedged()Matthew Auld
Technically the or_reset() means we call the action on failure, however that would lead to unbalanced rpm put(). Move the get() earlier to fix this. It should be extremely unlikely to ever trigger this in practice. Fixes: 90936a0a4c54 ("drm/xe: Don't suspend device upon wedge") Signed-off-by: Matthew Auld <matthew.auld@intel.com> Cc: Matthew Brost <matthew.brost@intel.com> Cc: Nirmoy Das <nirmoy.das@intel.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com> Reviewed-by: Nirmoy Das <nirmoy.das@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241009084808.204432-4-matthew.auld@intel.com (cherry picked from commit a187c1b0a800565a4db6372268692aff99df7f53) Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
2024-10-16drm/xe: fix unbalanced rpm put() with fence_fini()Matthew Auld
Currently we can call fence_fini() twice if something goes wrong when sending the GuC CT for the tlb request, since we signal the fence and return an error, leading to the caller also calling fini() on the error path in the case of stack version of the flow, which leads to an extra rpm put() which might later cause device to enter suspend when it shouldn't. It looks like we can just drop the fini() call since the fence signaller side will already call this for us. There are known mysterious splats with device going to sleep even with an rpm ref, and this could be one candidate. v2 (Matt B): - Prefer warning if we detect double fini() Fixes: f002702290fc ("drm/xe: Hold a PM ref when GT TLB invalidations are inflight") Signed-off-by: Matthew Auld <matthew.auld@intel.com> Cc: Matthew Brost <matthew.brost@intel.com> Cc: Nirmoy Das <nirmoy.das@intel.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com> Reviewed-by: Nirmoy Das <nirmoy.das@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241009084808.204432-3-matthew.auld@intel.com (cherry picked from commit cfcbc0520d5055825f0647ab922b655688605183) Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
2024-10-16drm/xe/xe2lpg: Extend Wa_15016589081 for xe2lpgAradhya Bhatia
Add workaround (wa) 15016589081 which applies to Xe2_v3_LPG_MD. Xe2_v3_LPG_MD is a Lunar Lake platform with GFX version: 20.04. This wa is type: permanent, and hence is applicable on all steppings. Signed-off-by: Aradhya Bhatia <aradhya.bhatia@intel.com> Reviewed-by: Tejas Upadhyay <tejas.upadhyay@intel.com> Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241009065542.283151-1-aradhya.bhatia@intel.com (cherry picked from commit 8fb1da9f9bfb02f710a7f826d50781b0b030cf53) Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
2024-10-16drm/i915/dp_mst: Don't require DSC hblank quirk for a non-DSC compatible modeImre Deak
If an MST branch device doesn't support DSC for a given mode, but the MST link has enough BW for the mode, assume that the branch device does support the mode using an uncompressed stream. Fixes: 55eaef164174 ("drm/i915/dp_mst: Handle the Synaptics HBlank expansion quirk") Cc: stable@vger.kernel.org # v6.8+ Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241009110135.1216498-2-imre.deak@intel.com (cherry picked from commit 4e75c3e208a06ad6fd9b3517fb77337460d7c2b0) Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
2024-10-16drm/i915/dp_mst: Handle error during DSC BW overhead/slice calculationImre Deak
The MST branch device may not support the number of DSC slices a mode requires, handle the error in this case. Fixes: 4e0837a8d00a ("drm/i915/dp_mst: Account for FEC and DSC overhead during BW allocation") Cc: stable@vger.kernel.org # v6.8+ Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241009110135.1216498-1-imre.deak@intel.com (cherry picked from commit 802a69b6b8a0502a9e2309afec7e1b77f67874f2) Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
2024-10-16drm/panel: s6e3ha8: select CONFIG_DRM_DISPLAY_DSC_HELPERArnd Bergmann
The new driver needs the dsc helper code to be available: x86_64-linux-ld: vmlinux.o: in function `s6e3ha8_amb577px01_wqhd_prepare': panel-samsung-s6e3ha8.c:(.text+0x16b1e65): undefined reference to `drm_dsc_pps_payload_pack' Select it from Kconfig as we do for other similar drivers. Fixes: 779679d3c164 ("drm/panel: Add support for S6E3HA8 panel driver") Signed-off-by: Arnd Bergmann <arnd@arndb.de> Reviewed-by: Jessica Zhang <quic_jesszhan@quicinc.com> Link: https://lore.kernel.org/r/20241015153442.3757061-1-arnd@kernel.org Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20241015153442.3757061-1-arnd@kernel.org
2024-10-16drm/panel: Add Samsung AMS581VF01 panel driverDanila Tikhonov
Add the driver for Samsung AMS581VF01 SOFEF01-based 5.81" FHD Plus CMD mode OLED panel support found in Google Pixel 4a (sm7150-google-sunfish) Signed-off-by: Danila Tikhonov <danila@jiaxyga.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Link: https://lore.kernel.org/r/20241013212402.15624-3-danila@jiaxyga.com Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20241013212402.15624-3-danila@jiaxyga.com
2024-10-15drm/msm/a6xx+: Insert a fence wait before SMMU table updateRob Clark
The CP_SMMU_TABLE_UPDATE _should_ be waiting for idle, but on some devices (x1-85, possibly others), it seems to pass that barrier while there are still things in the event completion FIFO waiting to be written back to memory. Work around that by adding a fence wait before context switch. The CP_EVENT_WRITE that writes the fence is the last write from a submit, so seeing this value hit memory is a reliable indication that it is safe to proceed with the context switch. v2: Only emit CP_WAIT_TIMESTAMP on a7xx, as it is not supported on a6xx. Conversely, I've not been able to reproduce this issue on a6xx, so hopefully it is limited to a7xx, or perhaps just certain a7xx devices. Fixes: af66706accdf ("drm/msm/a6xx: Add skeleton A7xx support") Closes: https://gitlab.freedesktop.org/drm/msm/-/issues/63 Signed-off-by: Rob Clark <robdclark@chromium.org> Reviewed-by: Akhil P Oommen <quic_akhilpo@quicinc.com> Signed-off-by: Abhinav Kumar <quic_abhinavk@quicinc.com>
2024-10-16drm: i915: Change fault type to unsigned longVincenzo Frascino
Fault is currently of type u32 and with the introduction of the generalized vdso/page.h we trigger the error below: drivers/gpu/drm/i915/gt/intel_gt_print.h:29:36: error: format ‘%lx’ expects argument of type ‘long unsigned int’, but argument 6 has type ‘u32’ {aka ‘unsigned int’} [-Werror=format=] 29 | drm_dbg(&(_gt)->i915->drm, "GT%u: " _fmt, (_gt)->info.id, | ^~~~~~~~ include/drm/drm_print.h:424:39: note: in definition of macro ‘drm_dev_dbg’ 424 | __drm_dev_dbg(NULL, dev, cat, fmt, ##__VA_ARGS__) | ^~~ include/drm/drm_print.h:524:33: note: in expansion of macro ‘drm_dbg_driver’ 524 | #define drm_dbg(drm, fmt, ...) drm_dbg_driver(drm, fmt, ##__VA_ARGS__) | ^~~~~~~~~~~~~~ linux/drivers/gpu/drm/i915/gt/intel_gt_print.h:29:9: note: in expansion of macro ‘drm_dbg’ 29 | drm_dbg(&(_gt)->i915->drm, "GT%u: " _fmt, (_gt)->info.id, | ^~~~~~~ drivers/gpu/drm/i915/gt/intel_gt.c:310:25: note: in expansion of macro ‘gt_dbg’ 310 | gt_dbg(gt, "Unexpected fault\n" | ^~~~~~ This happens because the type of PAGE_MASK depends on the architecture. Prevent the compilation error changing the 'fault' type to unsigned long. Signed-off-by: Vincenzo Frascino <vincenzo.frascino@arm.com> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Reviewed-by: Arnd Bergmann <arnd@arndb.de> Link: https://lore.kernel.org/all/20241014151340.1639555-2-vincenzo.frascino@arm.com
2024-10-15drm/msm/dpu: don't always program merge_3d blockJessica Zhang
Only program the merge_3d block for the video phys encoder when the 3d blend mode is not NONE Fixes: 3e79527a33a8 ("drm/msm/dpu: enable merge_3d support on sm8150/sm8250") Suggested-by: Abhinav Kumar <quic_abhinavk@quicinc.com> Signed-off-by: Jessica Zhang <quic_jesszhan@quicinc.com> Patchwork: https://patchwork.freedesktop.org/patch/619095/ Link: https://lore.kernel.org/r/20241009-merge3d-fix-v1-1-0d0b6f5c244e@quicinc.com Signed-off-by: Abhinav Kumar <quic_abhinavk@quicinc.com>
2024-10-15drm/msm/dpu: Don't always set merge_3d pending flushJessica Zhang
Don't set the merge_3d pending flush bits if the mode_3d is BLEND_3D_NONE. Always flushing merge_3d can cause timeout issues when there are multiple commits with concurrent writeback enabled. This is because the video phys enc waits for the hw_ctl flush register to be completely cleared [1] in its wait_for_commit_done(), but the WB encoder always sets the merge_3d pending flush during each commit regardless of if the merge_3d is actually active. This means that the hw_ctl flush register will never be 0 when there are multiple CWB commits and the video phys enc will hit vblank timeout errors after the first CWB commit. [1] commit fe9df3f50c39 ("drm/msm/dpu: add real wait_for_commit_done()") Fixes: 3e79527a33a8 ("drm/msm/dpu: enable merge_3d support on sm8150/sm8250") Fixes: d7d0e73f7de3 ("drm/msm/dpu: introduce the dpu_encoder_phys_* for writeback") Signed-off-by: Jessica Zhang <quic_jesszhan@quicinc.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Patchwork: https://patchwork.freedesktop.org/patch/619092/ Link: https://lore.kernel.org/r/20241009-mode3d-fix-v1-1-c0258354fadc@quicinc.com Signed-off-by: Abhinav Kumar <quic_abhinavk@quicinc.com>
2024-10-15gpu: host1x: Set up device DMA parametersThierry Reding
In order to store device DMA parameters, the DMA framework depends on the device's dma_parms field to point at a valid memory location. Add backing storage for this in struct host1x_memory_context and point to it. Reported-by: Jonathan Hunter <jonathanh@nvidia.com> Reviewed-by: Christoph Hellwig <hch@lst.de> Tested-by: Jon Hunter <jonathanh@nvidia.com> Signed-off-by: Thierry Reding <treding@nvidia.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240916133320.368620-1-thierry.reding@gmail.com (cherry picked from commit b4ad4ef374d66cc8df3188bb1ddb65bce5fc9e50) Signed-off-by: Thierry Reding <treding@nvidia.com>
2024-10-15drm/amdgpu/swsmu: Only force workload setup on initAlex Deucher
Needed to set the workload type at init time so that we can apply the navi3x margin optimization. Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/3618 Link: https://gitlab.freedesktop.org/drm/amd/-/issues/3131 Fixes: c50fe289ed72 ("drm/amdgpu/swsmu: always force a state reprogram on init") Reviewed-by: Kenneth Feng <kenneth.feng@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> (cherry picked from commit 580ad7cbd4b7be8d2cb5ab5c1fca6bb76045eb0e) Cc: stable@vger.kernel.org
2024-10-15drm/radeon: Fix encoder->possible_clonesVille Syrjälä
Include the encoder itself in its possible_clones bitmask. In the past nothing validated that drivers were populating possible_clones correctly, but that changed in commit 74d2aacbe840 ("drm: Validate encoder->possible_clones"). Looks like radeon never got the memo and is still not following the rules 100% correctly. This results in some warnings during driver initialization: Bogus possible_clones: [ENCODER:46:TV-46] possible_clones=0x4 (full encoder mask=0x7) WARNING: CPU: 0 PID: 170 at drivers/gpu/drm/drm_mode_config.c:615 drm_mode_config_validate+0x113/0x39c ... Cc: Alex Deucher <alexander.deucher@amd.com> Cc: amd-gfx@lists.freedesktop.org Fixes: 74d2aacbe840 ("drm: Validate encoder->possible_clones") Reported-by: Erhard Furtner <erhard_f@mailbox.org> Closes: https://lore.kernel.org/dri-devel/20241009000321.418e4294@yea/ Tested-by: Erhard Furtner <erhard_f@mailbox.org> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> (cherry picked from commit 3b6e7d40649c0d75572039aff9d0911864c689db) Cc: stable@vger.kernel.org
2024-10-15drm/amdgpu/smu13: always apply the powersave optimizationAlex Deucher
It can avoid margin issues in some very demanding applications. Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/3618 Link: https://gitlab.freedesktop.org/drm/amd/-/issues/3131 Fixes: c50fe289ed72 ("drm/amdgpu/swsmu: always force a state reprogram on init") Reviewed-by: Kenneth Feng <kenneth.feng@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> (cherry picked from commit 62f38b4ccaa6aa063ca781d80b10aacd39dc5c76) Cc: stable@vger.kernel.org
2024-10-15drm/amdkfd: Accounting pdd vram_usage for svmPhilip Yang
Process device data pdd->vram_usage is read by rocm-smi via sysfs, this is currently missing the svm_bo usage accounting, so "rocm-smi --showpids" per process VRAM usage report is incorrect. Add pdd->vram_usage accounting when svm_bo allocation and release, change to atomic64_t type because it is updated outside process mutex now. Signed-off-by: Philip Yang <Philip.Yang@amd.com> Reviewed-by: Felix Kuehling <felix.kuehling@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> (cherry picked from commit 98c0b0efcc11f2a5ddf3ce33af1e48eedf808b04)
generated by cgit v1.2.3 (git 2.25.1) at 2026-04-01 06:24:07 +0000