summaryrefslogtreecommitdiff
path: root/drivers/gpu
AgeCommit message (Collapse)Author
2024-03-07drm/tests/buddy: fix print formatMatthew Auld
This will report a build warning once we have: 806cb2270237 ("kunit: Annotate _MSG assertion variants with gnu printf specifiers"). Reported-by: Stephen Rothwell <sfr@canb.auug.org.au> Fixes: c70703320e55 ("drm/tests/drm_buddy: add alloc_range_bias test") Signed-off-by: Matthew Auld <matthew.auld@intel.com> Cc: Arunpravin Paneer Selvam <Arunpravin.PaneerSelvam@amd.com> Cc: Christian König <christian.koenig@amd.com> Reviewed-by: Arunpravin Paneer Selvam <Arunpravin.PaneerSelvam@amd.com> Link: https://lore.kernel.org/r/20240229095225.242795-2-matthew.auld@intel.com Signed-off-by: Maxime Ripard <mripard@kernel.org>
2024-03-07drm/xe: Return immediately on tile_init failureRodrigo Vivi
There's no reason to proceed with applying workaround and initing sysfs if we are going to abort the probe upon failure. Fixes: e5a845fd8fa4 ("drm/xe: Add sysfs entry for tile") Cc: Lucas De Marchi <lucas.demarchi@intel.com> Cc: Matt Roper <matthew.d.roper@intel.com> Cc: Matthew Auld <matthew.auld@intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240306203110.146387-1-rodrigo.vivi@intel.com Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> (cherry picked from commit af7b93d1d7eeeef674681ddea875be6a29857a5d) Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
2024-03-07drm/i915/dsi: Go back to the previous INIT_OTP/DISPLAY_ON order, mostlyVille Syrjälä
Reinstate commit 88b065943cb5 ("drm/i915/dsi: Do display on sequence later on icl+"), for the most part. Turns out some machines (eg. Chuwi Minibook X) really do need that updated order. It is also the order the Windows driver uses. However we can't just undo the revert since that would again break Lenovo 82TQ. After staring at the VBT sequences for both machines I've concluded that the Lenovo 82TQ sequences look somewhat broken: - INIT_OTP is not present at all - what should be in INIT_OTP is found in DISPLAY_ON - what should be in DISPLAY_ON is found in BACKLIGHT_ON (along with the actual backlight stuff) The Chuwi Minibook X on the other hand has a full complement of sequences in its VBT. So let's try to deal with the broken sequences in the Lenovo 82TQ VBT by simply swapping the (non-existent) INIT_OTP sequence with the DISPLAY_ON sequence. Thus we execute DISPLAY_ON when intending to execute INIT_OTP, and execute nothing at all when intending to execute DISPLAY_ON. That should be 100% equivalent to the revert, for such broken VBTs. Cc: stable@vger.kernel.org Fixes: dc524d05974f ("Revert "drm/i915/dsi: Do display on sequence later on icl+"") References: https://gitlab.freedesktop.org/drm/intel/-/issues/10071 Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/10334 Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240305083659.8396-1-ville.syrjala@linux.intel.com Acked-by: Jani Nikula <jani.nikula@intel.com>
2024-03-06drm/xe: Return immediately on tile_init failureRodrigo Vivi
There's no reason to proceed with applying workaround and initing sysfs if we are going to abort the probe upon failure. Fixes: e5a845fd8fa4 ("drm/xe: Add sysfs entry for tile") Cc: Lucas De Marchi <lucas.demarchi@intel.com> Cc: Matt Roper <matthew.d.roper@intel.com> Cc: Matthew Auld <matthew.auld@intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240306203110.146387-1-rodrigo.vivi@intel.com Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2024-03-06drm/amdgpu/pm: Fix the error of pwm1_enable settingMa Jun
Fix the pwm_mode value error which used for pwm1_enable setting Signed-off-by: Ma Jun <Jun.Ma2@amd.com> Reviewed-by: Lijo Lazar <lijo.lazar@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org
2024-03-06drm/amd/display: handle range offsets in VRR rangesAlex Deucher
Need to check the offset bits for values greater than 255. v2: also update amdgpu_dm_connector values. Suggested-by: Mano Ségransan <mano.segransan@protonmail.com> Tested-by: Mano Ségransan <mano.segransan@protonmail.com> Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/3203 Reviewed-by: Harry Wentland <harry.wentland@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org
2024-03-06drm/amd/display: check dc_link before dereferencingMelissa Wen
drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.c:6683 amdgpu_dm_connector_funcs_force() warn: variable dereferenced before check 'dc_link' (see line 6663) Fixes: 967176179215 ("drm/amd/display: fix null-pointer dereference on edid reading") Reported-by: Dan Carpenter <dan.carpenter@linaro.org> Signed-off-by: Melissa Wen <mwen@igalia.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2024-03-06drm/amd/swsmu: modify the gfx activity scalingLi Ma
Add an if condition for gfx activity because the scaling has been changed after smu fw version 5d4600. And remove a warning log. Signed-off-by: Li Ma <li.ma@amd.com> Reviewed-by: Yifan Zhang <yifan1.zhang@amd.com> Acked-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org # 6.7.x
2024-03-06drm/amdkfd: make kfd_class constantRicardo B. Marliere
Since commit 43a7206b0963 ("driver core: class: make class_register() take a const *"), the driver core allows for struct class to be in read-only memory, so move the kfd_class structure to be declared at build time placing it into read-only memory, instead of having to be dynamically allocated at boot time. Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Suggested-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Ricardo B. Marliere <ricardo@marliere.net> Signed-off-by: Felix Kuehling <felix.kuehling@amd.com> Reviewed-by: Felix Kuehling <felix.kuehling@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2024-03-06drm/amdgpu: add ring timeout information in devcoredumpSunil Khatri
Add ring timeout related information in the amdgpu devcoredump file for debugging purposes. During the gpu recovery process the registered call is triggered and add the debug information in data file created by devcoredump framework under the directory /sys/class/devcoredump/devcdx/ Signed-off-by: Sunil Khatri <sunil.khatri@amd.com> Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2024-03-06drm/amdgpu: add dcn3.5.1 supportYifan Zhang
This patch to add dcn3.5.1 support. Signed-off-by: Yifan Zhang <yifan1.zhang@amd.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2024-03-06drm/amdkfd: Use SQC when TCP would fail in gfx10.1 context saveLaurent Morichetti
Similarly to gfx9, gfx10.1 drops vector stores when an xnack error is raised. To work around this issue, use scalar stores instead of vector stores when trapsts.xnack_error == 1. Signed-off-by: Laurent Morichetti <laurent.morichetti@amd.com> Reviewed-by: Jay Cornwall <jay.cornwall@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2024-03-06drm/amdkfd: Increase the size of the memory reserved for the TBALaurent Morichetti
In a future commit, the cwsr trap handler code size for gfx10.1 will increase to slightly above the one page mark. Since the TMA does not need to be page aligned, and only 2 pointers are stored in it, push the TMA offset by 2 KiB and keep the TBA+TMA reserved memory size to two pages. Signed-off-by: Laurent Morichetti <laurent.morichetti@amd.com> Reviewed-by: Felix Kuehling <felix.kuehling@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2024-03-06drm/amdgpu: disable ring_muxer if mcbp is offPierre-Eric Pelloux-Prayer
Using the ring_muxer without preemption adds overhead for no reason since mcbp cannot be triggered. Moving back to a single queue in this case also helps when high priority app are used: in this case the gpu_scheduler priority handling will work as expected - much better than ring_muxer with its 2 independant schedulers competing for the same hardware queue. This change requires moving amdgpu_device_set_mcbp above amdgpu_device_ip_early_init because we use adev->gfx.mcbp. Signed-off-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Acked-by: Christian König <christian.koenig@amd.com> Acked-by: Jiadong Zhu <Jiadong.Zhu@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2024-03-06drm/amd/pm: disable pp_dpm_dcefclk node for gfx 11.0.3 sriovYang Wang
the dce dpm is not available on gfx 11.0.3 sriov device. Signed-off-by: Yang Wang <kevinyang.wang@amd.com> Reviewed-by: Kenneth Feng <kenneth.feng@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2024-03-06drm/amdgpu: remove unused codeJesse Zhang
Remove the unused function - amdgpu_vm_pt_is_root_clean and remove the impossible condition v1: entries == 0 is not possible any more, so this condition could probably be removed (Felix) Signed-off-by: Jesse Zhang <jesse.zhang@amd.com> Suggested-by：Felix Kuehling <felix.kuehling@amd.com> Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2024-03-06Revert "drm/udl: Add ARGB8888 as a format"Douglas Anderson
This reverts commit 95bf25bb9ed5dedb7fb39f76489f7d6843ab0475. Apparently there was a previous discussion about emulation of formats and it was decided XRGB8888 was the only format to support for legacy userspace [1]. Remove ARGB8888. Userspace needs to be fixed to accept XRGB8888. [1] https://lore.kernel.org/r/60dc7697-d7a0-4bf4-a22e-32f1bbb792c2@suse.de Acked-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Javier Martinez Canillas <javierm@redhat.com> Signed-off-by: Douglas Anderson <dianders@chromium.org> Link: https://patchwork.freedesktop.org/patch/msgid/20240306063721.1.I4a32475190334e1fa4eef4700ecd2787a43c94b5@changeid
2024-03-06drm/xe: Remove unused 'create' parameter from queue property logicNirmoy Das
The 'create' parameter in exec_queue_user_extensions was always true. This commit removes the dead parameter and all the relevant dead code. v2: rebase. Signed-off-by: Nirmoy Das <nirmoy.das@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240223143043.22779-1-nirmoy.das@intel.com Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2024-03-06drm/i915/display: Disable AuxCCS framebuffers if built for XeJuha-Pekka Heikkila
AuxCCS framebuffers don't work on Xe driver hence disable them from plane capabilities until they are fixed. FlatCCS framebuffers work and they are left enabled. CCS is left untouched for i915 driver. Closes: https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/933 Signed-off-by: Juha-Pekka Heikkila <juhapekka.heikkila@gmail.com> Reviewed-by: José Roberto de Souza <jose.souza@intel.com> Tested-by: José Roberto de Souza <jose.souza@intel.com> Acked-by: Jani Nikula <jani.nikula@intel.com> Fixes: 44e694958b95 ("drm/xe/display: Implement display support") Signed-off-by: José Roberto de Souza <jose.souza@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240228140225.858145-1-juhapekka.heikkila@gmail.com
2024-03-06drm/i915/panelreplay: Move out psr_init_dpcd() from init_connector()Animesh Manna
Move psr_init_dpcd() from init-connector to connector-detect function. The dpcd probe for checking panel replay capability for external dp connector is causing delay during boot which can be optimized by moving dpcd probe to connector specific detect(). v1: Initial version. v2: Add details in commit description. [Jani] Suggested-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/10284 Signed-off-by: Animesh Manna <animesh.manna@intel.com> Fixes: cceeaa312d39 ("drm/i915/panelreplay: Enable panel replay dpcd initialization for DP") Reviewed-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240229043716.4065760-1-animesh.manna@intel.com (cherry picked from commit 1cca19bf296fae0636a637b48d195ac6b4d430c9) Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
2024-03-06drm/i915/dp: Fix connector DSC HW state readoutImre Deak
The DSC HW state of DP connectors is read out during driver loading and system resume in intel_modeset_update_connector_atomic_state(). This function is called for all connectors though and so the state of DSI connectors will also get updated incorrectly, triggering a WARN there wrt. the DSC decompression AUX device. Fix the above by moving the DSC state readout to a new DP connector specific sync_state() hook. This is anyway the logical place to update the connector object's state vs. the connector's atomic state. Fixes: b2608c6b3212 ("drm/i915/dp_mst: Enable MST DSC decompression for all streams") Reported-and-tested-by: Drew Davenport <ddavenport@chromium.org> Closes: https://lore.kernel.org/all/Zb0q8IDVXS0HxJyj@chromium.org Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240205132631.1588577-1-imre.deak@intel.com (cherry picked from commit a62e145981500996ea76af3d740ce0c0d74c5be0) Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
2024-03-06drm/i915/selftests: Fix dependency of some timeouts on HZJanusz Krzysztofik
Third argument of i915_request_wait() accepts a timeout value in jiffies. Most users pass either a simple HZ based expression, or a result of msecs_to_jiffies(), or MAX_SCHEDULE_TIMEOUT, or a very small number not exceeding 4 if applicable as that value. However, there is one user -- intel_selftest_wait_for_rq() -- that passes a WAIT_FOR_RESET_TIME symbol, defined as a large constant value that most probably represents a desired timeout in ms. While that usage results in the intended value of timeout on usual x86_64 kernel configurations, it is not portable across different architectures and custom kernel configs. Rename the symbol to clearly indicate intended units and convert it to jiffies before use. Fixes: 3a4bfa091c46 ("drm/i915/selftest: Fix workarounds selftest for GuC submission") Signed-off-by: Janusz Krzysztofik <janusz.krzysztofik@linux.intel.com> Cc: Rahul Kumar Singh <rahul.kumar.singh@intel.com> Cc: John Harrison <John.C.Harrison@Intel.com> Cc: Matthew Brost <matthew.brost@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/20240222113347.648945-2-janusz.krzysztofik@linux.intel.com (cherry picked from commit 6ee3f54b880c91ab2e244eb4ffd4bfed37832b25) Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
2024-03-06drm/xe: Drop WA 16015675438Lucas De Marchi
With dynamic load-balancing disabled on the compute side, there's no reason left to enable WA 16015675438. Drop it from both PVC and DG2. Note that this can be done because now the driver always set a fixed partition of EUs during initialization via the ccs_mode configuration. Cc: Mateusz Jablonski <mateusz.jablonski@intel.com> Cc: Michal Mrozek <michal.mrozek@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Acked-by: Michal Mrozek <michal.mrozek@intel.com> Acked-by: Mateusz Jablonski <mateusz.jablonski@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240304233103.1687412-1-lucas.demarchi@intel.com Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
2024-03-06drm/i915: Stop doing double audio enable/disable on SDVO and g4x+ DPVille Syrjälä
Looks like I misplaced a few hunks when I moved the audio enable/disable out from the encoder enable/disable hooks. So we are now doing a double audio enable/disable on SDVO and g4x+ DP. Probably harmless as doing it twice shouldn't really change anything, but let's do it just once, as intended. Fixes: cff742cc6851 ("drm/i915: Hoist the encoder->audio_{enable,disable}() calls higher up") Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240226193251.29619-1-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2024-03-06drm/xe/hdcp: Enable HDCP for XESuraj Kandpal
Enable HDCP for Xe by defining functions which take care of interaction of HDCP as a client with the GSC CS interface. Add intel_hdcp_gsc_message to Makefile and add corresponding changes to xe_hdcp_gsc.c to make it build. --v2 -add kfree at appropriate place [Daniele] -remove useless define [Daniele] -move host session logic to xe_gsc_submit.c [Daniele] -call xe_gsc_check_and_update_pending directly in an if condition [Daniele] -use xe_device instead of drm_i915_private [Daniele] --v3 -use xe prefix for newly exposed function [Daniele] -remove client specific defines from intel_gsc_mtl_header [Daniele] -add missing kfree() [Daniele] -have NULL check for hdcp_message in finish function [Daniele] -dont have too many variable declarations in the same line [Daniele] --v4 -don't point the hdcp_message structure in xe_device to anything until it properly gets initialized [Daniele] --v5 -Squash commits for buildability --v6 -Order includes alphabetically [Lucas] Signed-off-by: Suraj Kandpal <suraj.kandpal@intel.com> Reviewed-by: Arun R Murthy <arun.r.murthy@intel.com> Signed-off-by: Mika Kahola <mika.kahola@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240306024247.1857881-6-suraj.kandpal@intel.com
2024-03-06drm/xe: Use gsc_proxy_init_done to check proxy statusSuraj Kandpal
Expose gsc_proxy_init_done so that we can check if gsc proxy has been initialized or not. --v2 -Check if GSC FW is enabled before taking forcewake ref [Daniele] --v3 -Directly call proxy check function inside if condition Signed-off-by: Suraj Kandpal <suraj.kandpal@intel.com> Reviewed-by: Arun R Murthy <arun.r.murthy@intel.com> Reviewed-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Signed-off-by: Mika Kahola <mika.kahola@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240306024247.1857881-5-suraj.kandpal@intel.com
2024-03-06drm/xe/hdcp: Use xe_device structSuraj Kandpal
Use xe_device struct instead of drm_i915_private so as to not cause confusion and comply with Xe standards as drm_i915_private is xe_device under the hood. --v2 -Fix commit message [Daniele] Signed-off-by: Suraj Kandpal <suraj.kandpal@intel.com> Reviewed-by: Arun R Murthy <arun.r.murthy@intel.com> Signed-off-by: Mika Kahola <mika.kahola@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240306024247.1857881-4-suraj.kandpal@intel.com
2024-03-06drm/i915/hdcp: Move intel_hdcp_gsc_message def away from header fileSuraj Kandpal
Move intel_hdcp_gsc_message definition into intel_hdcp_gsc.c so that intel_hdcp_gsc_message can be redefined for xe as needed. --v2 -Correct commit message to reflect what patch is actually doing [Arun] Signed-off-by: Suraj Kandpal <suraj.kandpal@intel.com> Reviewed-by: Arun R Murthy <arun.r.murthy@intel.com> Acked-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Mika Kahola <mika.kahola@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240306024741.1858039-2-suraj.kandpal@intel.com
2024-03-05drm/i915/guc: Simplify/extend platform check for Wa_14018913170John Harrison
The above w/a is required for every platform that the i915 driver supports. It is fixed on the latest platforms but they are only supported by Xe instead of i915. So just remove the platform check completely and keep the code simple. v2: Add extra comment (review feedback from Rodrigo). Signed-off-by: John Harrison <John.C.Harrison@Intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240223202846.1532176-1-John.C.Harrison@Intel.com
2024-03-05drm/xe: Do not grab forcewakes when issuing GGTT TLB invalidation via GuCMatthew Brost
Forcewakes are not required for communication with the GuC via CTB as it is a memory based interfaced. Acquring forcewakes takes considerable time. With that, do not grab a forcewake when issuing a GGTT TLB invalidation via the GuC. Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Lucas De Marchi <lucas.demarchi@intel.com> Cc: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: Matthew Brost <matthew.brost@intel.com> Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240229194520.200642-1-matthew.brost@intel.com
2024-03-05drm/xe/xelpg: Extend some workarounds to graphics version 12.74Matt Roper
A handful of Xe_LPG workarounds are also relevant to graphics version 12.74 as well. Extend the graphics version range for these workarounds accordingly. Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: Dnyaneshwar Bhadane <dnyaneshwar.bhadane@intel.com> Reviewed-by: Matt Atwood <matthew.s.atwood@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240229070806.3402641-3-dnyaneshwar.bhadane@intel.com
2024-03-05drm/xe/xelpg: Recognize graphics version 12.74 as Xe_LPGMatt Roper
Graphics version 12.74 (which is technically called "Xe_LPG+") should be handled the same as versions Xe_LPG 12.70/12.71 by the KMD. Only the workaround lists (handled in the next patch) will be a bit different. Bspec: 55420 Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: Dnyaneshwar Bhadane <dnyaneshwar.bhadane@intel.com> Reviewed-by: Matt Atwood <matthew.s.atwood@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240229070806.3402641-2-dnyaneshwar.bhadane@intel.com
2024-03-05drm/xe: Pipeline evict / restore of pinned BOs during suspend / resumeMatthew Brost
Rather than waiting for each evict / restore of pinned BOs to complete just wait on migrate exec queue to be idle once during suspend / resume. Cc: Matthew Auld <matthew.auld@intel.com> Signed-off-by: Matthew Brost <matthew.brost@intel.com> Reviewed-by: Matthew Auld <matthew.auld@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240305173503.285223-1-matthew.brost@intel.com
2024-03-05drm/i915/dp: Fix connector DSC HW state readoutImre Deak
The DSC HW state of DP connectors is read out during driver loading and system resume in intel_modeset_update_connector_atomic_state(). This function is called for all connectors though and so the state of DSI connectors will also get updated incorrectly, triggering a WARN there wrt. the DSC decompression AUX device. Fix the above by moving the DSC state readout to a new DP connector specific sync_state() hook. This is anyway the logical place to update the connector object's state vs. the connector's atomic state. Fixes: b2608c6b3212 ("drm/i915/dp_mst: Enable MST DSC decompression for all streams") Reported-and-tested-by: Drew Davenport <ddavenport@chromium.org> Closes: https://lore.kernel.org/all/Zb0q8IDVXS0HxJyj@chromium.org Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240205132631.1588577-1-imre.deak@intel.com
2024-03-05drm/i915/selftests: Fix dependency of some timeouts on HZJanusz Krzysztofik
Third argument of i915_request_wait() accepts a timeout value in jiffies. Most users pass either a simple HZ based expression, or a result of msecs_to_jiffies(), or MAX_SCHEDULE_TIMEOUT, or a very small number not exceeding 4 if applicable as that value. However, there is one user -- intel_selftest_wait_for_rq() -- that passes a WAIT_FOR_RESET_TIME symbol, defined as a large constant value that most probably represents a desired timeout in ms. While that usage results in the intended value of timeout on usual x86_64 kernel configurations, it is not portable across different architectures and custom kernel configs. Rename the symbol to clearly indicate intended units and convert it to jiffies before use. Fixes: 3a4bfa091c46 ("drm/i915/selftest: Fix workarounds selftest for GuC submission") Signed-off-by: Janusz Krzysztofik <janusz.krzysztofik@linux.intel.com> Cc: Rahul Kumar Singh <rahul.kumar.singh@intel.com> Cc: John Harrison <John.C.Harrison@Intel.com> Cc: Matthew Brost <matthew.brost@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/20240222113347.648945-2-janusz.krzysztofik@linux.intel.com
2024-03-05drm/i915/selftest_hangcheck: Check sanity with more patienceJanusz Krzysztofik
While trying to reproduce some other issues reported by CI for i915 hangcheck live selftest, I found them hidden behind timeout failures reported by igt_hang_sanitycheck -- the very first hangcheck test case executed. Feb 22 19:49:06 DUT1394ACMR kernel: calling mei_gsc_driver_init+0x0/0xff0 [mei_gsc] @ 121074 Feb 22 19:49:06 DUT1394ACMR kernel: i915 0000:03:00.0: [drm] DRM_I915_DEBUG enabled Feb 22 19:49:06 DUT1394ACMR kernel: i915 0000:03:00.0: [drm] Cannot find any crtc or sizes Feb 22 19:49:06 DUT1394ACMR kernel: probe of i915.mei-gsc.768 returned 0 after 1475 usecs Feb 22 19:49:06 DUT1394ACMR kernel: probe of i915.mei-gscfi.768 returned 0 after 1441 usecs Feb 22 19:49:06 DUT1394ACMR kernel: initcall mei_gsc_driver_init+0x0/0xff0 [mei_gsc] returned 0 after 3010 usecs Feb 22 19:49:06 DUT1394ACMR kernel: i915 0000:03:00.0: [drm] DRM_I915_DEBUG_GEM enabled Feb 22 19:49:06 DUT1394ACMR kernel: i915 0000:03:00.0: [drm] DRM_I915_DEBUG_RUNTIME_PM enabled Feb 22 19:49:06 DUT1394ACMR kernel: i915: Performing live selftests with st_random_seed=0x4c26c048 st_timeout=500 Feb 22 19:49:07 DUT1394ACMR kernel: i915: Running hangcheck Feb 22 19:49:07 DUT1394ACMR kernel: calling mei_hdcp_driver_init+0x0/0xff0 [mei_hdcp] @ 121074 Feb 22 19:49:07 DUT1394ACMR kernel: i915: Running intel_hangcheck_live_selftests/igt_hang_sanitycheck Feb 22 19:49:07 DUT1394ACMR kernel: probe of 0000:00:16.0-b638ab7e-94e2-4ea2-a552-d1c54b627f04 returned 0 after 1398 usecs Feb 22 19:49:07 DUT1394ACMR kernel: probe of i915.mei-gsc.768-b638ab7e-94e2-4ea2-a552-d1c54b627f04 returned 0 after 97 usecs Feb 22 19:49:07 DUT1394ACMR kernel: initcall mei_hdcp_driver_init+0x0/0xff0 [mei_hdcp] returned 0 after 101960 usecs Feb 22 19:49:07 DUT1394ACMR kernel: calling mei_pxp_driver_init+0x0/0xff0 [mei_pxp] @ 121094 Feb 22 19:49:07 DUT1394ACMR kernel: probe of 0000:00:16.0-fbf6fcf1-96cf-4e2e-a6a6-1bab8cbe36b1 returned 0 after 435 usecs Feb 22 19:49:07 DUT1394ACMR kernel: mei_pxp i915.mei-gsc.768-fbf6fcf1-96cf-4e2e-a6a6-1bab8cbe36b1: bound 0000:03:00.0 (ops i915_pxp_tee_component_ops [i915]) Feb 22 19:49:07 DUT1394ACMR kernel: 100ms wait for request failed on rcs0, err=-62 Feb 22 19:49:07 DUT1394ACMR kernel: probe of i915.mei-gsc.768-fbf6fcf1-96cf-4e2e-a6a6-1bab8cbe36b1 returned 0 after 158425 usecs Feb 22 19:49:07 DUT1394ACMR kernel: initcall mei_pxp_driver_init+0x0/0xff0 [mei_pxp] returned 0 after 224159 usecs Feb 22 19:49:07 DUT1394ACMR kernel: i915/intel_hangcheck_live_selftests: igt_hang_sanitycheck failed with error -5 Feb 22 19:49:07 DUT1394ACMR kernel: i915: probe of 0000:03:00.0 failed with error -5 Those request waits, once timed out after 100ms, have never been confirmed to still persist over another 100ms, always being able to complete within the originally requested wait time doubled. Taking into account potentially significant additional concurrent workload generated by new auxiliary drivers that didn't exist before and now are loaded in parallel with the i915 module also when loaded in selftest mode, relax our expectations on time consumed by the sanity check request before it completes. Signed-off-by: Janusz Krzysztofik <janusz.krzysztofik@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/20240228152500.38267-2-janusz.krzysztofik@linux.intel.com
2024-03-05drm/udl: Add ARGB8888 as a formatDouglas Anderson
Even though the UDL driver converts to RGB565 internally (see pixel32_to_be16() in udl_transfer.c), it advertises XRGB8888 for compatibility. Let's add ARGB8888 to that list. This makes UDL devices work on ChromeOS again after commit c91acda3a380 ("drm/gem: Check for valid formats"). Prior to that commit things were "working" because we'd silently treat the ARGB8888 that ChromeOS wanted as XRGB8888. Fixes: c91acda3a380 ("drm/gem: Check for valid formats") Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Signed-off-by: Douglas Anderson <dianders@chromium.org> Link: https://patchwork.freedesktop.org/patch/msgid/20240227141928.1.I24ac8d51544e4624b7e9d438d95880c4283e611b@changeid
2024-03-05drm: Add CONFIG_DRM_WERRORJani Nikula
Add kconfig to enable -Werror subsystem wide. This is useful for development and CI to keep the subsystem warning free, while avoiding issues outside of the subsystem that kernel wide CONFIG_WERROR=y might hit. v2: Don't depend on COMPILE_TEST Reviewed-by: Hamza Mahfooz <hamza.mahfooz@amd.com> # v1 Reviewed-by: Javier Martinez Canillas <javierm@redhat.com> Acked-by: Maxime Ripard <mripard@kernel.org> Link: https://patchwork.freedesktop.org/patch/msgid/afe5ed943414f7ec3044c1547503b9941686a867.1709629403.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2024-03-05drm: enable (most) W=1 warnings by default across the subsystemJani Nikula
At least the i915 and amd drivers enable a bunch more compiler warnings than the kernel defaults. Extend most of the W=1 warnings to the entire drm subsystem by default. Use the copy-pasted warnings from scripts/Makefile.extrawarn with s/KBUILD_CFLAGS/subdir-ccflags-y/ to make it easier to compare and keep up with them in the future. This is similar to the approach currently used in i915. Some of the -Wextra warnings do need to be disabled, just like in Makefile.extrawarn, but take care to not disable them for W=2 or W=3 builds, depending on the warning. There are too many -Wformat-truncation warnings to cleanly fix up front; leave that warning disabled for now. v3: - Drop -Wmissing-declarations (already enabled by default) - Drop -Wmissing-prototypes (already enabled by default) v2: - Drop -Wformat-truncation (too many warnings) - Drop -Wstringop-overflow (already enabled by default) Cc: David Airlie <airlied@gmail.com> Cc: Daniel Vetter <daniel@ffwll.ch> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Maxime Ripard <mripard@kernel.org> Cc: Thomas Zimmermann <tzimmermann@suse.de> Cc: Alex Deucher <alexander.deucher@amd.com> Cc: Christian König <christian.koenig@amd.com> Cc: Pan Cc: Karol Herbst <kherbst@redhat.com> Cc: Lyude Paul <lyude@redhat.com> Cc: Rob Clark <robdclark@gmail.com> Cc: Abhinav Kumar <quic_abhinavk@quicinc.com> Cc: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Cc: Sean Paul <sean@poorly.run> Cc: Marijn Suijten <marijn.suijten@somainline.org> Cc: Hamza Mahfooz <hamza.mahfooz@amd.com> Acked-by: Javier Martinez Canillas <javierm@redhat.com> Acked-by: Thomas Zimmermann <tzimmermann@suse.de> Acked-by: Sui Jingfeng <sui.jingfeng@linux.dev> Acked-by: Danilo Krummrich <dakr@redhat.com> Acked-by: Maxime Ripard <mripard@kernel.org> Link: https://patchwork.freedesktop.org/patch/msgid/a50f1a69d5af72e913996179a75bc3a71d81ebea.1709629403.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2024-03-05drm/nouveau: move more missing UAPI bitsKarol Herbst
Those are already de-facto UAPI, so let's just move it into the uapi header. Signed-off-by: Karol Herbst <kherbst@redhat.com> Reviewed-by: Lyude Paul <lyude@redhat.com> Reviewed-by: Danilo Krummrich <dakr@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240305133853.2214268-2-kherbst@redhat.com
2024-03-05drm/bridge: Document bridge init order with pre_enable_prev_firstJagan Teki
In order to satisfy the MIPI DSI initialization sequence the bridge init order has been altered with the help of pre_enable_prev_first in pre_enable and post_disable bridge operations. Document the affected bridge init order with an example on the bridge operations helpers. Signed-off-by: Jagan Teki <jagan@amarulasolutions.com> Reviewed-by: Dave Stevenson <dave.stevenson@raspberrypi.com> Signed-off-by: Robert Foss <rfoss@kernel.org> Link: https://patchwork.freedesktop.org/patch/msgid/20230328170752.1102347-2-jagan@amarulasolutions.com
2024-03-05drm/bridge: Fix improper bridge init order with pre_enable_prev_firstJagan Teki
For a given bridge pipeline if any bridge sets pre_enable_prev_first flag then the pre_enable for the previous bridge will be called before pre_enable of this bridge and opposite is done for post_disable. These are the potential bridge flags to alter bridge init order in order to satisfy the MIPI DSI host and downstream panel or bridge to function. However the existing pre_enable_prev_first logic with associated bridge ordering has broken for both pre_enable and post_disable calls. [pre_enable] The altered bridge ordering has failed if two consecutive bridges on a given pipeline enables the pre_enable_prev_first flag. Example: - Panel - Bridge 1 - Bridge 2 pre_enable_prev_first - Bridge 3 - Bridge 4 pre_enable_prev_first - Bridge 5 pre_enable_prev_first - Bridge 6 - Encoder In this example, Bridge 4 and Bridge 5 have pre_enable_prev_first. The logic looks for a bridge which enabled pre_enable_prev_first flag on each iteration and assigned the previou bridge to limit pointer if the bridge doesn't enable pre_enable_prev_first flags. If control found Bridge 2 is pre_enable_prev_first then the iteration looks for Bridge 3 and found it is not pre_enable_prev_first and assigns it's previous Bridge 4 to limit pointer and calls pre_enable of Bridge 3 and Bridge 2 and assign iter pointer with limit which is Bridge 4. Here is the actual problem, for the next iteration control look for Bridge 5 instead of Bridge 4 has iter pointer in previous iteration moved to Bridge 4 so this iteration skips the Bridge 4. The iteration found Bridge 6 doesn't pre_enable_prev_first flags so the limit assigned to Encoder. From next iteration Encoder skips as it is the last bridge for reverse order pipeline. So, the resulting pre_enable bridge order would be, - Panel, Bridge 1, Bridge 3, Bridge 2, Bridge 6, Bridge 5. This patch fixes this by assigning limit to next pointer instead of previous bridge since the iteration always looks for bridge that does NOT request prev so assigning next makes sure the last bridge on a given iteration what exactly the limit bridge is. So, the resulting pre_enable bridge order with fix would be, - Panel, Bridge 1, Bridge 3, Bridge 2, Bridge 6, Bridge 5, Bridge 4, Encoder. [post_disable] The altered bridge ordering has failed if two consecutive bridges on a given pipeline enables the pre_enable_prev_first flag. Example: - Panel - Bridge 1 - Bridge 2 pre_enable_prev_first - Bridge 3 - Bridge 4 pre_enable_prev_first - Bridge 5 pre_enable_prev_first - Bridge 6 - Encoder In this example Bridge 5 and Bridge 4 have pre_enable_prev_first. The logic looks for a bridge which enabled pre_enable_prev_first flags on each iteration and assigned the previou bridge to next and next to limit pointer if the bridge does enable pre_enable_prev_first flag. If control starts from Bridge 6 then it found next Bridge 5 is pre_enable_prev_first and immediately the next assigned to previous Bridge 6 and limit assignments to next Bridge 6 and call post_enable of Bridge 6 even though the next consecutive Bridge 5 is enabled with pre_enable_prev_first. This clearly misses the logic to find the state of next conducive bridge as everytime the next and limit assigns previous bridge if given bridge enabled pre_enable_prev_first. So, the resulting post_disable bridge order would be, - Encoder, Bridge 6, Bridge 5, Bridge 4, Bridge 3, Bridge 2, Bridge 1, Panel. This patch fixes this by assigning next with previou bridge only if the bridge doesn't enable pre_enable_prev_first flag and the next further assign it to limit. This way we can find the bridge that NOT requested prev to disable last. So, the resulting pre_enable bridge order with fix would be, - Encoder, Bridge 4, Bridge 5, Bridge 6, Bridge 2, Bridge 3, Bridge 1, Panel. Validated the bridge init ordering by incorporating dummy bridges in the sun6i-mipi-dsi pipeline Fixes: 4fb912e5e190 ("drm/bridge: Introduce pre_enable_prev_first to alter bridge init order") Signed-off-by: Jagan Teki <jagan@amarulasolutions.com> Tested-by: Michael Trimarchi <michael@amarulasolutions.com> Reviewed-by: Dave Stevenson <dave.stevenson@raspberrypi.com> Signed-off-by: Robert Foss <rfoss@kernel.org> Link: https://patchwork.freedesktop.org/patch/msgid/20230328170752.1102347-1-jagan@amarulasolutions.com
2024-03-05drm/nouveau: fix stale locked mutex in nouveau_gem_ioctl_pushbufKarol Herbst
If VM_BIND is enabled on the client the legacy submission ioctl can't be used, however if a client tries to do so regardless it will return an error. In this case the clients mutex remained unlocked leading to a deadlock inside nouveau_drm_postclose or any other nouveau ioctl call. Fixes: b88baab82871 ("drm/nouveau: implement new VM_BIND uAPI") Cc: Danilo Krummrich <dakr@redhat.com> Cc: <stable@vger.kernel.org> # v6.6+ Signed-off-by: Karol Herbst <kherbst@redhat.com> Reviewed-by: Lyude Paul <lyude@redhat.com> Reviewed-by: Danilo Krummrich <dakr@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240305133853.2214268-1-kherbst@redhat.com
2024-03-05drm/tidss: Use dev_err_probe() over dev_dbg() when failing to probe the portAndrew Halaney
This gets logged out to /sys/kernel/debug/devices_deferred in the -EPROBE_DEFER case and as an error otherwise. The message here provides useful information to the user when troubleshooting why their display is not working in either case, so let's make it output appropriately. Signed-off-by: Andrew Halaney <ahalaney@redhat.com> Reviewed-by: Javier Martinez Canillas <javierm@redhat.com> Tested-by: Enric Balletbo i Serra <eballetbo@kernel.org> Link: https://lore.kernel.org/r/20240228-tidss-dev-err-probe-v1-1-5482252326d3@redhat.com Signed-off-by: Maxime Ripard <mripard@kernel.org>
2024-03-05drm/i915: Don't explode when the dig port we don't have an AUX CHVille Syrjälä
The icl+ power well code currently assumes that every AUX power well maps to an encoder which is using said power well. That is by no menas guaranteed as we: - only register encoders for ports declared in the VBT - combo PHY HDMI-only encoder no longer get an AUX CH since commit 9856308c94ca ("drm/i915: Only populate aux_ch if really needed") However we have places such as intel_power_domains_sanitize_state() that blindly traverse all the possible power wells. So these bits of code may very well encounbter an aux power well with no associated encoder. In this particular case the BIOS seems to have left one AUX power well enabled even though we're dealing with a HDMI only encoder on a combo PHY. We then proceed to turn off said power well and explode when we can't find a matching encoder. As a short term fix we should be able to just skip the PHY related parts of the power well programming since we know this situation can only happen with combo PHYs. Another option might be to go back to always picking an AUX CH for all encoders. However I'm a bit wary about that since we might in theory end up conflicting with the VBT AUX CH assignment. Also that wouldn't help with encoders not declared in the VBT, should we ever need to poke the corresponding power wells. Longer term we need to figure out what the actual relationship is between the PHY vs. AUX CH vs. AUX power well. Currently this is entirely unclear. Cc: stable@vger.kernel.org Fixes: 9856308c94ca ("drm/i915: Only populate aux_ch if really needed") Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/10184 Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240223203216.15210-1-ville.syrjala@linux.intel.com Reviewed-by: Imre Deak <imre.deak@intel.com> (cherry picked from commit 6a8c66bf0e565c34ad0a18f820e0bb17951f7f91) Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
2024-03-05Merge tag 'drm-intel-fixes-2024-03-01' of ↵Daniel Vetter
https://anongit.freedesktop.org/git/drm/drm-intel into drm-fixes - Fix to extract HDCP information from primary connector - Check for NULL mmu_interval_notifier before removing Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> From: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/ZeGOUTfiA0_FNKLg@jlahtine-mobl.ger.corp.intel.com
2024-03-04drm/i915/guc: Correct capture of EIR register on hangJohn Harrison
The EIR register (0x20B0) was being included in the engine class list for render and compute as the absolute register address. However, it is actually a ring register available on all engines at an offset of (base) + 0xB0. As it was included as an RCS engine but with the absolute address, GuC was adding on another 0x2000 and coming out at an invalid location. Thus it would reject the register and complain about only managing a partial capture. So update the list to use the RING_EIR version of the register and include it for all engines. Signed-off-by: John Harrison <John.C.Harrison@Intel.com> Reviewed-by: Alan Previn <alan.previn.teres.alexis@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240223203204.1533410-1-John.C.Harrison@Intel.com
2024-03-04drm/amdgpu: workaround to avoid SET_Q_MODE packets v2Christian König
It turned out that executing the SET_Q_MODE packet on every submission creates to much overhead. Implement a workaround which allows skipping the SET_Q_MODE packet if subsequent submissions all use the same parameters. v2: add a NULL check for ring_obj Signed-off-by: Christian König <christian.koenig@amd.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2024-03-04drm/amdgpu: cleanup conditional executionChristian König
First of all calculating the number of dw to patch into a conditional execution is not something HW generation specific. This is just standard ring buffer calculations. While at it also reduce the BUG_ON() into WARN_ON(). Then instead of a random bit pattern use 0 as default value for the number of dw skipped, this way it's not mandatory any more to patch the conditional execution. And last make the address to check a parameter of the conditional execution instead of getting this from the ring. Signed-off-by: Christian König <christian.koenig@amd.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2024-03-04drm/amdgpu: Use rpm_mode flag instead of checking it again for rpmMa Jun
Because the rpm_mode flag is already set when the driver is initialized, we use it directly for runtime suspend/resume instead of checking it again Signed-off-by: Ma Jun <Jun.Ma2@amd.com> Reviewed-by: Lijo Lazar <lijo.lazar@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
generated by cgit (git 2.34.1) at 2025-09-25 19:10:08 +0000