Maarten Lankhorst
269a3f6084
drm/xe/display: Match i915 driver suspend/resume sequences better
...
Suspend fbdev sooner, and disable user access before suspending to
prevent some races. I've noticed this when comparing xe suspend to
i915's.
Matches the following commits from i915:
24b412b1bf ("drm/i915: Disable intel HPD poll after DRM poll init/enable")
1ef28d86be ("drm/i915: Suspend the framebuffer console earlier during system suspend")
bd738d859e ("drm/i915: Prevent modesets during driver init/shutdown")
Thanks to Imre for pointing me to those commits.
Driver shutdown is currently missing, but I have some idea how to
implement it next.
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com >
Cc: Imre Deak <imre.deak@intel.com >
Reviewed-by: Uma Shankar <uma.shankar@intel.com >
Link: https://patchwork.freedesktop.org/patch/msgid/20240806105044.596842-2-maarten.lankhorst@linux.intel.com
Signed-off-by: Maarten Lankhorst,,, <maarten.lankhorst@linux.intel.com >
(cherry picked from commit 492be2a070 )
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com >
2024-09-04 12:24:07 -04:00
Rodrigo Vivi
82122d1f54
drm/xe: Add missing runtime reference to wedged upon gt_reset
...
Fixes this missed case:
xe 0000:00:02.0: [drm] Missing outer runtime PM protection
WARNING: CPU: 99 PID: 1455 at drivers/gpu/drm/xe/xe_pm.c:564 xe_pm_runtime_get_noresume+0x48/0x60 [xe]
Call Trace:
<TASK>
? show_regs+0x67/0x70
? __warn+0x94/0x1b0
? xe_pm_runtime_get_noresume+0x48/0x60 [xe]
? report_bug+0x1b7/0x1d0
? handle_bug+0x46/0x80
? exc_invalid_op+0x19/0x70
? asm_exc_invalid_op+0x1b/0x20
? xe_pm_runtime_get_noresume+0x48/0x60 [xe]
xe_device_declare_wedged+0x91/0x280 [xe]
gt_reset_worker+0xa2/0x250 [xe]
v2: Also move get and get the right Fixes tag (Himal, Brost)
Fixes: fb74b205cd ("drm/xe: Introduce a simple wedged state")
Cc: Himal Prasad Ghimiray <himal.prasad.ghimiray@intel.com >
Cc: Matthew Brost <matthew.brost@intel.com >
Reviewed-by: Jonathan Cavitt <jonathan.cavitt@intel.com >
Reviewed-by: Himal Prasad Ghimiray <himal.prasad.ghimiray@intel.com >
Link: https://patchwork.freedesktop.org/patch/msgid/20240830183507.298351-1-rodrigo.vivi@intel.com
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com >
(cherry picked from commit bc947d9a8c )
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com >
2024-09-04 12:16:40 -04:00
Jason Gunthorpe
9e8354b399
ARM: 9417/1: dma-mapping: Pass device to arm_iommu_create_mapping()
...
All users of ARM IOMMU mappings create them for a particular device, so
change the interface to accept the device rather than forcing a vague
indirection through a bus type. This prepares for making a similar
change to iommu_domain_alloc() itself.
Signed-off-by: Robin Murphy <robin.murphy@arm.com >
Signed-off-by: Lu Baolu <baolu.lu@linux.intel.com >
Reviewed-by: Jason Gunthorpe <jgg@nvidia.com >
Reviewed-by: Vasant Hegde <vasant.hegde@amd.com >
Acked-by: Michael S. Tsirkin <mst@redhat.com >
Acked-by: Jeff Johnson <quic_jjohnson@quicinc.com >
Signed-off-by: Jason Gunthorpe <jgg@ziepe.ca >
Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk >
2024-09-04 15:02:07 +01:00
Thomas Hellström
34bb7b813a
drm/xe: Use xe_pm_runtime_get in xe_bo_move() if reclaim-safe.
...
xe_bo_move() might be called in the TTM swapout path from validation
by another TTM device. If so, we are not likely to have a RPM
reference. So iff xe_pm_runtime_get() is safe to call from reclaim,
use it instead of xe_pm_runtime_get_noresume().
Strictly this is currently needed only if handle_system_ccs is true,
but use xe_pm_runtime_get() if possible anyway to increase test
coverage.
At the same time warn if handle_system_ccs is true and we can't
call xe_pm_runtime_get() from reclaim context. This will likely trip
if someone tries to enable SRIOV on LNL, without fixing Xe SRIOV
runtime resume / suspend.
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com >
Cc: Matthew Brost <matthew.brost@intel.com >
Cc: Matthew Auld <matthew.auld@intel.com >
Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com >
Reviewed-by: Matthew Auld <matthew.auld@intel.com >
Link: https://patchwork.freedesktop.org/patch/msgid/20240903094232.166342-1-thomas.hellstrom@linux.intel.com
2024-09-04 09:28:09 +02:00
Rodrigo Vivi
8da19441d0
drm/xe/display: Avoid encoder_suspend at runtime suspend
...
Fix circular locking dependency on runtime suspend.
<4> [74.952215] ======================================================
<4> [74.952217] WARNING: possible circular locking dependency detected
<4> [74.952219] 6.10.0-rc7-xe #1 Not tainted
<4> [74.952221] ------------------------------------------------------
<4> [74.952223] kworker/7:1/82 is trying to acquire lock:
<4> [74.952226] ffff888120548488 (&dev->mode_config.mutex){+.+.}-{3:3}, at: drm_modeset_lock_all+0x40/0x1e0 [drm]
<4> [74.952260]
but task is already holding lock:
<4> [74.952262] ffffffffa0ae59c0 (xe_pm_runtime_lockdep_map){+.+.}-{0:0}, at: xe_pm_runtime_suspend+0x2f/0x340 [xe]
<4> [74.952322]
which lock already depends on the new lock.
The commit 'b1d90a86 ("drm/xe: Use the encoder suspend helper also used
by the i915 driver")' didn't do anything wrong. It actually fixed a
critical bug, because the encoder_suspend was never getting actually
called because it was returning if (has_display(xe)) instead of
if (!has_display(xe)). However, this ended up introducing the encoder
suspend calls in the runtime routines as well, causing the circular
locking dependency.
Closes: https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/2304
Fixes: b1d90a862c ("drm/xe: Use the encoder suspend helper also used by the i915 driver")
Cc: Imre Deak <imre.deak@intel.com >
Reviewed-by: Jonathan Cavitt <jonathan.cavitt@intel.com >
Link: https://patchwork.freedesktop.org/patch/msgid/20240830183507.298351-2-rodrigo.vivi@intel.com
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com >
2024-09-03 12:47:00 -04:00
Rodrigo Vivi
bc947d9a8c
drm/xe: Add missing runtime reference to wedged upon gt_reset
...
Fixes this missed case:
xe 0000:00:02.0: [drm] Missing outer runtime PM protection
WARNING: CPU: 99 PID: 1455 at drivers/gpu/drm/xe/xe_pm.c:564 xe_pm_runtime_get_noresume+0x48/0x60 [xe]
Call Trace:
<TASK>
? show_regs+0x67/0x70
? __warn+0x94/0x1b0
? xe_pm_runtime_get_noresume+0x48/0x60 [xe]
? report_bug+0x1b7/0x1d0
? handle_bug+0x46/0x80
? exc_invalid_op+0x19/0x70
? asm_exc_invalid_op+0x1b/0x20
? xe_pm_runtime_get_noresume+0x48/0x60 [xe]
xe_device_declare_wedged+0x91/0x280 [xe]
gt_reset_worker+0xa2/0x250 [xe]
v2: Also move get and get the right Fixes tag (Himal, Brost)
Fixes: fb74b205cd ("drm/xe: Introduce a simple wedged state")
Cc: Himal Prasad Ghimiray <himal.prasad.ghimiray@intel.com >
Cc: Matthew Brost <matthew.brost@intel.com >
Reviewed-by: Jonathan Cavitt <jonathan.cavitt@intel.com >
Reviewed-by: Himal Prasad Ghimiray <himal.prasad.ghimiray@intel.com >
Link: https://patchwork.freedesktop.org/patch/msgid/20240830183507.298351-1-rodrigo.vivi@intel.com
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com >
2024-09-03 12:46:39 -04:00
Matt Roper
fe13fd6833
drm/xe/pcode: Treat pcode as per-tile rather than per-GT
...
There's only one instance of the pcode per tile, and for GT-related
accesses both the primary and media GT share the same register
interface. Since Xe was using per-GT locking, the pcode mutex wasn't
actually protecting everything that it should since concurrent accesses
related to a tile's primary GT and media GT were possible.
Fixes: dd08ebf6c3 ("drm/xe: Introduce a new DRM driver for Intel GPUs")
Signed-off-by: Matt Roper <matthew.d.roper@intel.com >
Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com >
Link: https://patchwork.freedesktop.org/patch/msgid/20240829220619.789159-5-matthew.d.roper@intel.com
(cherry picked from commit 3034cc8107 )
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com >
2024-09-03 10:36:46 -04:00
Daniele Ceraolo Spurio
529bf8d111
drm/xe/gsc: Do not attempt to load the GSC multiple times
...
The GSC HW is only reset by driver FLR or D3cold entry. We don't support
the former at runtime, while the latter is only supported on DGFX, for
which we don't support GSC. Therefore, if GSC failed to load previously
there is no need to try again because the HW is stuck in the error state.
An assert has been added so that if we ever add DGFX support we'll know
we need to handle the D3 case.
v2: use "< 0" instead of "!= 0" in the FW state error check (Julia).
Fixes: dd0e89e5ed ("drm/xe/gsc: GSC FW load")
Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com >
Cc: John Harrison <John.C.Harrison@Intel.com >
Cc: Alan Previn <alan.previn.teres.alexis@intel.com >
Cc: <stable@vger.kernel.org > # v6.8+
Reviewed-by: Julia Filipchuk <julia.filipchuk@intel.com >
Link: https://patchwork.freedesktop.org/patch/msgid/20240828215158.2743994-2-daniele.ceraolospurio@intel.com
(cherry picked from commit 2160f6f6e3 )
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com >
2024-09-03 10:36:38 -04:00
Jani Nikula
963ed4efe0
drm/i915/dp: hide dp_to_i915() inside intel_dp.c
...
Now that only intel_dp.c uses dp_to_i915(), hide it there. This removes
a header dependency on to_i915().
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com >
Signed-off-by: Jani Nikula <jani.nikula@intel.com >
Link: https://patchwork.freedesktop.org/patch/msgid/e214aa6991aea4fc878b36dcd3eaece9f1fba592.1725012870.git.jani.nikula@intel.com
2024-09-03 17:11:25 +03:00
Jani Nikula
7134cc23fe
drm/i915/ddi: stop using dp_to_i915()
...
Switch to struct intel_display and to_intel_display() instead of using
dp_to_i915().
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com >
Signed-off-by: Jani Nikula <jani.nikula@intel.com >
Link: https://patchwork.freedesktop.org/patch/msgid/6557281bc3f8df88931c045deb08cf76b727cda2.1725012870.git.jani.nikula@intel.com
2024-09-03 17:11:20 +03:00
Jani Nikula
41a4629621
drm/i915/psr: convert intel_psr.[ch] to struct intel_display
...
Going forward, struct intel_display shall replace struct
drm_i915_private as the main display device data pointer type. Convert
intel_psr.[ch] to struct intel_display.
Some stragglers are left behind where needed.
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com >
Signed-off-by: Jani Nikula <jani.nikula@intel.com >
Link: https://patchwork.freedesktop.org/patch/msgid/4399b98b07019a8063adbec1043ff7eabb7c1080.1725012870.git.jani.nikula@intel.com
2024-09-03 17:11:00 +03:00
Jani Nikula
8a37cd4dc5
drm/i915/pps: convert intel_pps.[ch] to struct intel_display
...
Going forward, struct intel_display shall replace struct
drm_i915_private as the main display device data pointer type. Convert
intel_pps.[ch] to struct intel_display.
Some stragglers are left behind where needed.
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com >
Signed-off-by: Jani Nikula <jani.nikula@intel.com >
Link: https://patchwork.freedesktop.org/patch/msgid/bea51b0d9e4546ba21d0d4eb01ca1097fda095ab.1725012870.git.jani.nikula@intel.com
2024-09-03 17:10:55 +03:00
Jani Nikula
631ef2e6ad
drm/i915/pps: pass intel_dp to pps_name()
...
Currently all of intel_pps.c passes struct intel_dp around. Do the same
with pps_name() instead of passing both struct drm_i915_private and
struct intel_pps.
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com >
Signed-off-by: Jani Nikula <jani.nikula@intel.com >
Link: https://patchwork.freedesktop.org/patch/msgid/f2a7fec4a2ff1f09cb73e6734604fae99ab6b11a.1725012870.git.jani.nikula@intel.com
2024-09-03 17:10:52 +03:00
Jani Nikula
402bd11a53
drm/i915/dp: convert intel_dp_link_training.[ch] to struct intel_display
...
Going forward, struct intel_display shall replace struct
drm_i915_private as the main display device data pointer type. Convert
intel_dp_link_training.[ch] to struct intel_display.
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com >
Signed-off-by: Jani Nikula <jani.nikula@intel.com >
Link: https://patchwork.freedesktop.org/patch/msgid/72b202e75f5a7ecc84a906f1c49d21dbe24fb7c2.1725012870.git.jani.nikula@intel.com
2024-09-03 17:10:48 +03:00
Jani Nikula
f70e43763e
drm/i915/dp: convert intel_dp_aux.[ch] to struct intel_display
...
Going forward, struct intel_display shall replace struct
drm_i915_private as the main display device data pointer type. Convert
intel_dp_aux.[ch] to struct intel_display.
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com >
Signed-off-by: Jani Nikula <jani.nikula@intel.com >
Link: https://patchwork.freedesktop.org/patch/msgid/f295369d573d217323a624fd4b8dc477a6cf183b.1725012870.git.jani.nikula@intel.com
2024-09-03 17:10:44 +03:00
Jani Nikula
a954e0a261
drm/i915/dp: convert intel_dp_tunnel.[ch] to struct intel_display
...
Going forward, struct intel_display shall replace struct
drm_i915_private as the main display device data pointer type. Convert
intel_dp_tunnel.[ch] to struct intel_display.
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com >
Signed-off-by: Jani Nikula <jani.nikula@intel.com >
Link: https://patchwork.freedesktop.org/patch/msgid/2c83fe739ab8de05361d6eaae0249e58878a3c06.1725012870.git.jani.nikula@intel.com
2024-09-03 17:10:41 +03:00
Jani Nikula
b34b43f9cb
drm/i915/dp: convert g4x_dp.[ch] to struct intel_display
...
Going forward, struct intel_display shall replace struct
drm_i915_private as the main display device data pointer type. Convert
g4x_dp.[ch] to struct intel_display.
Some stragglers are left behind where needed.
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com >
Signed-off-by: Jani Nikula <jani.nikula@intel.com >
Link: https://patchwork.freedesktop.org/patch/msgid/b80ffb6373e9e3daaba0762ff7aebe168511b3a7.1725012870.git.jani.nikula@intel.com
2024-09-03 17:10:37 +03:00
Jani Nikula
1138137c2c
drm/i915/hdmi: convert to struct intel_display
...
Going forward, struct intel_display shall replace struct
drm_i915_private as the main display device data pointer type. Convert
intel_hdmi.[ch] to struct intel_display. Remove intel_hdmi_to_i915().
Some stragglers are left behind where needed.
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com >
Signed-off-by: Jani Nikula <jani.nikula@intel.com >
Link: https://patchwork.freedesktop.org/patch/msgid/fa74b67935eb7e8084f57688a9683a36cb1d1a4c.1725012870.git.jani.nikula@intel.com
2024-09-03 17:10:33 +03:00
Jani Nikula
059f6fc899
drm/xe/display: use xe && 0 to avoid warnings about unused variables
...
Avoid warnings about unused variables when the IS_LP(), IS_GEN9_LP(),
and IS_GEN9_BC() macros are the only users of a variable. This is not
currently the case, but prepare for future changes.
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com >
Signed-off-by: Jani Nikula <jani.nikula@intel.com >
Link: https://patchwork.freedesktop.org/patch/msgid/2a9960df4d9f6423a2cc6a29a7a7b0c1420690c7.1725012870.git.jani.nikula@intel.com
2024-09-03 17:10:18 +03:00
Michal Wajdeczko
9f6b47907e
drm/xe: Remove redundant [drm] tag from xe_assert() message
...
Since commit 178c0a33c4 ("drm/print: Add generic drm dev printk
function") the output from drm_WARN() includes previously missing
the [drm] tag, so now xe_assert() is printing it twice:
[ ] xe 0000:00:02.0: [drm] [drm] Assertion `false` failed!
Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com >
Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com >
Link: https://patchwork.freedesktop.org/patch/msgid/20240902190726.1748-1-michal.wajdeczko@intel.com
2024-09-03 11:42:42 +02:00
Dmitry Baryshkov
9a71cf8b6f
drm/bridge-connector: reset the HDMI connector state
...
On HDMI connectors which use drm_bridge_connector and DRM_BRIDGE_OP_HDMI
IGT chokes on the max_bpc property in several kms_properties tests due
to the drm_bridge_connector failing to reset HDMI-related
properties.
Call __drm_atomic_helper_connector_hdmi_reset() if the
drm_bridge_connector has bridge_hdmi.
It is impossible to call this function from HDMI bridges, none of the
bridge callbacks correspond to the drm_connector_funcs::reset().
Fixes: 6b4468b0c6 ("drm/bridge-connector: implement glue code for HDMI connector")
Reviewed-by: Maxime Ripard <mripard@kernel.org >
Acked-by: Maxime Ripard <mripard@kernel.org >
Reviewed-by: Abhinav Kumar <quic_abhinavk@quicinc.com >
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org >
Link: https://patchwork.freedesktop.org/patch/msgid/20240903-drm-bridge-connector-fix-hdmi-reset-v5-3-daebde6d9857@linaro.org
Signed-off-by: Maxime Ripard <mripard@kernel.org >
2024-09-03 10:18:31 +02:00
Dmitry Baryshkov
9da7ec9b19
drm/bridge-connector: move to DRM_DISPLAY_HELPER module
...
drm_bridge_connector is a "leaf" driver, belonging to the display
helper, rather than the "CRTC" drm_kms_helper module. Move the driver
to the drm/display and add necessary Kconfig selection clauses.
Suggested-by: Maxime Ripard <mripard@kernel.org >
Acked-by: Maxime Ripard <mripard@kernel.org >
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org >
Link: https://patchwork.freedesktop.org/patch/msgid/20240903-drm-bridge-connector-fix-hdmi-reset-v5-2-daebde6d9857@linaro.org
Signed-off-by: Maxime Ripard <mripard@kernel.org >
2024-09-03 10:18:31 +02:00
Dmitry Baryshkov
466cb3c630
drm/display: stop depending on DRM_DISPLAY_HELPER
...
Kconfig symbols should not declare dependency on DRM_DISPLAY_HELPER.
Move all parts of DRM_DISPLAY_HELPER to an if DRM_DISPLAY_HELPER block.
It is not possible to make those symbols select DRM_DISPLAY_HELPER
because of the link issues when a part of the helper is selected to be
built-in, while other part is selected to be as module. In such a case
the modular part doesn't get built at all, leading to undefined symbols.
The only viable alternative is to split drm_display_helper.ko into
several small modules, each of them having their own dependencies.
Suggested-by: Maxime Ripard <mripard@kernel.org >
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org >
Link: https://patchwork.freedesktop.org/patch/msgid/20240903-drm-bridge-connector-fix-hdmi-reset-v5-1-daebde6d9857@linaro.org
Signed-off-by: Maxime Ripard <mripard@kernel.org >
2024-09-03 10:18:28 +02:00
Jouni Högander
a13494de53
drm/i915/display: Increase Fast Wake Sync length as a quirk
...
In commit "drm/i915/display: Increase number of fast wake precharge pulses"
we were increasing Fast Wake sync pulse length to fix problems observed on
Dell Precision 5490 laptop with AUO panel. Later we have observed this is
causing problems on other panels.
Fix these problems by increasing Fast Wake sync pulse length as a quirk
applied for Dell Precision 5490 with problematic panel.
Fixes: f777728663 ("drm/i915/display: Increase number of fast wake precharge pulses")
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com >
Closes: http://gitlab.freedesktop.org/drm/i915/kernel/-/issues/9739
Closes: https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/2246
Closes: https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/11762
Signed-off-by: Jouni Högander <jouni.hogander@intel.com >
Reviewed-by: Jani Nikula <jani.nikula@intel.com >
Cc: <stable@vger.kernel.org > # v6.10+
Link: https://patchwork.freedesktop.org/patch/msgid/20240902064241.1020965-3-jouni.hogander@intel.com
(cherry picked from commit fcba2ed66b )
Requires: 43cf50eb14 ("drm/i915/display: Add mechanism to use sink model when applying quirk")
Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com >
2024-09-03 10:22:39 +03:00
Jouni Högander
43cf50eb14
drm/i915/display: Add mechanism to use sink model when applying quirk
...
Currently there is no way to apply quirk on device only if certain panel
model is installed. This patch implements such mechanism by adding new
quirk type intel_dpcd_quirk which contains also sink_oui and sink_device_id
fields and using also them to figure out if applying quirk is needed.
New intel_init_dpcd_quirks is added and called after drm_dp_read_desc with
proper sink device identity read from dpcdc.
v3:
- !mem_is_zero fixed to mem_is_zero
v2:
- instead of using struct intel_quirk add new struct intel_dpcd_quirk
Signed-off-by: Jouni Högander <jouni.hogander@intel.com >
Reviewed-by: Jani Nikula <jani.nikula@intel.com >
Link: https://patchwork.freedesktop.org/patch/msgid/20240902064241.1020965-2-jouni.hogander@intel.com
(cherry picked from commit b3b9136990 )
Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com >
2024-09-03 09:57:51 +03:00
Jouni Högander
fcba2ed66b
drm/i915/display: Increase Fast Wake Sync length as a quirk
...
In commit "drm/i915/display: Increase number of fast wake precharge pulses"
we were increasing Fast Wake sync pulse length to fix problems observed on
Dell Precision 5490 laptop with AUO panel. Later we have observed this is
causing problems on other panels.
Fix these problems by increasing Fast Wake sync pulse length as a quirk
applied for Dell Precision 5490 with problematic panel.
Fixes: f777728663 ("drm/i915/display: Increase number of fast wake precharge pulses")
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com >
Closes: http://gitlab.freedesktop.org/drm/i915/kernel/-/issues/9739
Closes: https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/2246
Closes: https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/11762
Signed-off-by: Jouni Högander <jouni.hogander@intel.com >
Reviewed-by: Jani Nikula <jani.nikula@intel.com >
Cc: <stable@vger.kernel.org > # v6.10+
Link: https://patchwork.freedesktop.org/patch/msgid/20240902064241.1020965-3-jouni.hogander@intel.com
2024-09-03 07:52:47 +03:00
Jouni Högander
b3b9136990
drm/i915/display: Add mechanism to use sink model when applying quirk
...
Currently there is no way to apply quirk on device only if certain panel
model is installed. This patch implements such mechanism by adding new
quirk type intel_dpcd_quirk which contains also sink_oui and sink_device_id
fields and using also them to figure out if applying quirk is needed.
New intel_init_dpcd_quirks is added and called after drm_dp_read_desc with
proper sink device identity read from dpcdc.
v3:
- !mem_is_zero fixed to mem_is_zero
v2:
- instead of using struct intel_quirk add new struct intel_dpcd_quirk
Signed-off-by: Jouni Högander <jouni.hogander@intel.com >
Reviewed-by: Jani Nikula <jani.nikula@intel.com >
Link: https://patchwork.freedesktop.org/patch/msgid/20240902064241.1020965-2-jouni.hogander@intel.com
2024-09-03 07:51:50 +03:00
Michal Wajdeczko
da6ec74339
drm/xe/pf: Reset thresholds when releasing a VF config
...
As part of the VF config release, we should reset all parameters,
including thresholds, to always start with the clean VF config.
Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com >
Reviewed-by: Piotr Piórkowski <piotr.piorkowski@intel.com >
Link: https://patchwork.freedesktop.org/patch/msgid/20240830132100.1704-3-michal.wajdeczko@intel.com
2024-09-02 20:51:03 +02:00
Michal Wajdeczko
a1498ab229
drm/xe/pf: Add thresholds to the VF KLV config
...
We are pushing threshold KLV to the GuC immediately during the
threshold provisioning, but those configs will be lost during a
GT reset. Include threshold KLVs while encoding full VF config
buffer to make sure the GuC receives all of the config KLVs.
Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com >
Reviewed-by: Piotr Piórkowski <piotr.piorkowski@intel.com >
Link: https://patchwork.freedesktop.org/patch/msgid/20240830132100.1704-2-michal.wajdeczko@intel.com
2024-09-02 20:51:02 +02:00
Dillon Varone
38e3285dbd
drm/amd/display: Block timing sync for different signals in PMO
...
PMO assumes that like timings can be synchronized, but DC only allows
this if the signal types match.
Reviewed-by: Austin Zheng <austin.zheng@amd.com >
Signed-off-by: Dillon Varone <dillon.varone@amd.com >
Signed-off-by: Hamza Mahfooz <hamza.mahfooz@amd.com >
Signed-off-by: Alex Deucher <alexander.deucher@amd.com >
(cherry picked from commit 29d3d6af43 )
Cc: stable@vger.kernel.org
2024-09-02 13:13:43 -04:00
Leo Li
53c3685f53
drm/amd/display: Lock DC and exit IPS when changing backlight
...
Backlight updates require aux and/or register access. Therefore, driver
needs to disallow IPS beforehand.
So, acquire the dc lock before calling into dc to update backlight - we
should be doing this regardless of IPS. Then, while the lock is held,
disallow IPS before calling into dc, then allow IPS afterwards (if it
was previously allowed).
Reviewed-by: Aurabindo Pillai <aurabindo.pillai@amd.com >
Reviewed-by: Roman Li <roman.li@amd.com >
Signed-off-by: Leo Li <sunpeng.li@amd.com >
Signed-off-by: Hamza Mahfooz <hamza.mahfooz@amd.com >
Signed-off-by: Alex Deucher <alexander.deucher@amd.com >
(cherry picked from commit 988fe28626 )
Cc: stable@vger.kernel.org # 6.10+
2024-09-02 13:12:13 -04:00
Alex Deucher
4de34b0478
drm/amdgpu: always allocate cleared VRAM for GEM allocations
...
This adds allocation latency, but aligns better with user
expectations. The latency should improve with the drm buddy
clearing patches that Arun has been working on.
In addition this fixes the high CPU spikes seen when doing
wipe on release.
v2: always set AMDGPU_GEM_CREATE_VRAM_CLEARED (Christian)
Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/3528
Fixes: a68c7eaa7a ("drm/amdgpu: Enable clear page functionality")
Acked-by: Arunpravin Paneer Selvam <Arunpravin.PaneerSelvam@amd.com >
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com > (v1)
Signed-off-by: Alex Deucher <alexander.deucher@amd.com >
Cc: Arunpravin Paneer Selvam <Arunpravin.PaneerSelvam@amd.com >
Cc: Christian König <christian.koenig@amd.com >
(cherry picked from commit 6c0a7c3c69 )
Cc: stable@vger.kernel.org # 6.10.x
2024-09-02 13:08:51 -04:00
Jack Xiao
34c36a77f4
drm/amdgpu/mes: add mes mapping legacy queue switch
...
For mes11 old firmware has issue to map legacy queue,
add a flag to switch mes to map legacy queue.
Fixes: f9d8c5c785 ("drm/amdgpu/gfx: enable mes to map legacy queue support")
Reported-by: Andrew Worsley <amworsley@gmail.com >
Link: https://lists.freedesktop.org/archives/amd-gfx/2024-August/112773.html
Signed-off-by: Jack Xiao <Jack.Xiao@amd.com >
Reviewed-by: Alex Deucher <alexander.deucher@amd.com >
Signed-off-by: Alex Deucher <alexander.deucher@amd.com >
(cherry picked from commit 52491d97aa )
2024-09-02 13:05:39 -04:00
Leo Li
65444581a4
drm/amd/display: Determine IPS mode by ASIC and PMFW versions
...
[Why]
DCN IPS interoperates with other system idle power features, such as
Zstates.
On DCN35, there is a known issue where system Z8 + DCN IPS2 causes a
hard hang. We observe this on systems where the SBIOS allows Z8.
Though there is a SBIOS fix, there's no guarantee that users will get it
any time soon, or even install it. A workaround is needed to prevent
this from rearing its head in the wild.
[How]
For DCN35, check the pmfw version to determine whether the SBIOS has the
fix. If not, set IPS1+RCG as the deepest possible state in all cases
except for s0ix and display off (DPMS). Otherwise, enable all IPS
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 28d43d0895 )
Cc: stable@vger.kernel.org
2024-09-02 13:05:09 -04:00
Alex Deucher
ead60e9c4e
drm/amdgpu/gfx10: use rlc safe mode for soft recovery
...
Protect the MMIO access with safe mode.
Acked-by: Vitaly Prosyak <vitaly.prosyak@amd.com >
Signed-off-by: Alex Deucher <alexander.deucher@amd.com >
2024-09-02 11:41:40 -04:00
Alex Deucher
3f2d35c325
drm/amdgpu/gfx11: use rlc safe mode for soft recovery
...
Protect the MMIO access with safe mode.
Acked-by: Vitaly Prosyak <vitaly.prosyak@amd.com >
Signed-off-by: Alex Deucher <alexander.deucher@amd.com >
2024-09-02 11:41:38 -04:00
Alex Deucher
21818f39be
drm/amdgpu/gfx12: use rlc safe mode for soft recovery
...
Protect the MMIO access with safe mode.
Acked-by: Vitaly Prosyak <vitaly.prosyak@amd.com >
Signed-off-by: Alex Deucher <alexander.deucher@amd.com >
2024-09-02 11:41:34 -04:00
Alex Deucher
f8eee864ba
drm/amdgpu/gfx12: use proper rlc safe mode helpers
...
Rather than open coding it for the queue reset.
Acked-by: Vitaly Prosyak <vitaly.prosyak@amd.com >
Signed-off-by: Alex Deucher <alexander.deucher@amd.com >
2024-09-02 11:41:31 -04:00
Alex Deucher
01d05521f7
drm/amdgpu/gfx11: use proper rlc safe mode helpers
...
Rather than open coding it for the queue reset.
Acked-by: Vitaly Prosyak <vitaly.prosyak@amd.com >
Signed-off-by: Alex Deucher <alexander.deucher@amd.com >
2024-09-02 11:41:28 -04:00
Alex Deucher
bcee4c3f89
drm/amdgpu/gfx10: use proper rlc safe mode helpers
...
Rather than open coding it for the queue reset.
Acked-by: Vitaly Prosyak <vitaly.prosyak@amd.com >
Signed-off-by: Alex Deucher <alexander.deucher@amd.com >
2024-09-02 11:41:24 -04:00
Alex Deucher
1a1995b1dc
drm/amdgpu/gfx12: per queue reset only on bare metal
...
It's not supported under SR-IOV at the moment.
Acked-by: Vitaly Prosyak <vitaly.prosyak@amd.com >
Signed-off-by: Alex Deucher <alexander.deucher@amd.com >
2024-09-02 11:41:22 -04:00
Alex Deucher
01163079e1
drm/amdgpu/gfx11: per queue reset only on bare metal
...
It's not supported under SR-IOV at the moment.
Acked-by: Vitaly Prosyak <vitaly.prosyak@amd.com >
Signed-off-by: Alex Deucher <alexander.deucher@amd.com >
2024-09-02 11:41:20 -04:00
Alex Deucher
4d5ddfa4b1
drm/amdgpu/gfx10: per queue reset only on bare metal
...
It's not supported under SR-IOV at the moment.
Acked-by: Vitaly Prosyak <vitaly.prosyak@amd.com >
Signed-off-by: Alex Deucher <alexander.deucher@amd.com >
2024-09-02 11:41:16 -04:00
Jiadong Zhu
178ad0e280
drm/amdgpu/mes11: implement mmio queue reset for gfx11
...
Implement queue reset for graphic and compute queue.
v2: use amdgpu_gfx_rlc funcs to enter/exit safe mode.
v3: use gfx_v11_0_request_gfx_index_mutex()
v4: fix mutex handling
Acked-by: Vitaly Prosyak <vitaly.prosyak@amd.com >
Signed-off-by: Jiadong Zhu <Jiadong.Zhu@amd.com >
Reviewed-by: Alex Deucher <alexander.deucher@amd.com >
Signed-off-by: Alex Deucher <alexander.deucher@amd.com >
2024-09-02 11:41:13 -04:00
Jiadong Zhu
01b4ae38e5
drm/amdgpu/mes: implement amdgpu_mes_reset_hw_queue_mmio
...
The reset_queue api could be used from kfd or kgd.
v2: add use_mmio parameter for mes_reset_legacy_queue.
Acked-by: Vitaly Prosyak <vitaly.prosyak@amd.com >
Signed-off-by: Jiadong Zhu <Jiadong.Zhu@amd.com >
Reviewed-by: Alex Deucher <alexander.deucher@amd.com >
Signed-off-by: Alex Deucher <alexander.deucher@amd.com >
2024-09-02 11:41:07 -04:00
Jiadong Zhu
8b2429a13f
drm/amdgpu/mes: modify mes api for mmio queue reset
...
Add me/pipe/queue parameters for queue reset input.
v2: fix build (Alex)
Acked-by: Vitaly Prosyak <vitaly.prosyak@amd.com >
Signed-off-by: Jiadong Zhu <Jiadong.Zhu@amd.com >
Reviewed-by: Alex Deucher <alexander.deucher@amd.com >
Signed-off-by: Alex Deucher <alexander.deucher@amd.com >
2024-09-02 11:41:03 -04:00
Alex Deucher
8fe4fde381
drm/amdgpu/gfx12: fallback to driver reset compute queue directly
...
Since the MES FW resets kernel compute queue always failed, this
may caused by the KIQ failed to process unmap KCQ. So, before MES
FW work properly that will fallback to driver executes dequeue and
resets SPI directly. Besides, rework the ring reset function and make
the busy ring type reset in each function respectively.
Acked-by: Vitaly Prosyak <vitaly.prosyak@amd.com >
Signed-off-by: Alex Deucher <alexander.deucher@amd.com >
2024-09-02 11:41:01 -04:00
Alex Deucher
2480599890
drm/amdgpu/gfx12: add ring reset callbacks
...
Add ring reset callbacks for gfx and compute.
Acked-by: Vitaly Prosyak <vitaly.prosyak@amd.com >
Signed-off-by: Alex Deucher <alexander.deucher@amd.com >
2024-09-02 11:40:58 -04:00
Alex Deucher
d1f2144321
drm/amdgpu/gfx10: rework reset sequence
...
To match other GFX IPs.
Acked-by: Vitaly Prosyak <vitaly.prosyak@amd.com >
Signed-off-by: Alex Deucher <alexander.deucher@amd.com >
2024-09-02 11:40:55 -04:00
Jiadong Zhu
097af47d3c
drm/amdgpu/gfx10: wait for reset done before remap
...
There is a racing condition that cp firmware modifies
MQD in reset sequence after driver updates it for
remapping. We have to wait till CP_HQD_ACTIVE becoming
false then remap the queue.
v2: fix KIQ locking (Alex)
v3: fix KIQ locking harder (Jessie)
Acked-by: Vitaly Prosyak <vitaly.prosyak@amd.com >
Signed-off-by: Jiadong Zhu <Jiadong.Zhu@amd.com >
Reviewed-by: Alex Deucher <alexander.deucher@amd.com >
Signed-off-by: Alex Deucher <alexander.deucher@amd.com >
2024-09-02 11:40:47 -04:00