An AUX transfer on any disconnected DP port results in long
timeout/retry delays the same way as this is described for TypeC port in
commit a972cd3f0e ("drm/i915/tc: Abort DP AUX transfer on a disconnected TC port")
Prevent the delay on non-TypeC ports as well by aborting the transfer if
the port is disconnected. For eDP keep the current behavior as the
support for HPD signaling is optional for it.
Link: https://patchwork.freedesktop.org/patch/msgid/20240104083008.2715733-13-imre.deak@intel.com
Reviewed-by: Jouni Högander <jouni.hogander@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Glitches deasserting the connector HPD line can lead to incorrectly
detecting a disconnect event (a glitch asserting the line will only
cause a redundant connect->disconnect transition). The source of such a
glitch can be noise on the line or a 0.5ms-1ms MST IRQ_HPD pulse. TypeC
ports in the DP-alt or TBT-alt mode filter out these glitches inernally,
but for others the driver has to do this. Make it so by polling the HPD
line on these connectors for 4 ms.
Link: https://patchwork.freedesktop.org/patch/msgid/20240104083008.2715733-12-imre.deak@intel.com
Reviewed-by: Jouni Högander <jouni.hogander@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Add hooks to intel_digital_port to lock and unlock the port and add a
helper to check the connector's detect status while the port is locked
already. This simplifies checking the connector detect status in
intel_dp_aux_xfer() and intel_digital_port_connected() in the next two
patches aborting AUX transfers on all DP connectors (except eDP) and
filtering HPD glitches.
Link: https://patchwork.freedesktop.org/patch/msgid/20240104083008.2715733-11-imre.deak@intel.com
Reviewed-by: Jouni Högander <jouni.hogander@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
As described in the previous patch, an unexpected connector
detection/modeset started from the intel_hotplug::hotplug_work can
happen during the driver init/shutdown sequence. Prevent these by
disabling the queuing of and flushing all the intel_hotplug work that
can start them at the beginning of the init/shutdown sequence and allow
the queuing only while the display is in the initialized state.
Other work items - like the intel_connector::modeset_retry_work or the
MST probe works - are still enabled and can start a detection/modeset,
but after the previous patch these will be rejected. Disabling these
works as well is for a follow-up patchset.
Link: https://patchwork.freedesktop.org/patch/msgid/20240104083008.2715733-9-imre.deak@intel.com
Reviewed-by: Jouni Högander <jouni.hogander@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
An unexpected modeset or connector detection by a user (user space or FB
console) during the initialization/shutdown sequence is possible either
via a hotplug IRQ handling work or via the connector sysfs
(status/detect) interface. These modesets/detections should be prevented
by disabling/flushing all related hotplug handling work and
unregistering the interfaces that can start them at the beginning of the
shutdown sequence. Some of this - disabling all related intel_hotplug
work - will be done by the next patch, but others - for instance
disabling the MST hotplug works - require a bigger rework.
It makes sense - for diagnostic purpose, even with all the above work and
interface disabled - to detect and reject any such user access. This
patch does that for modeset accesses and a follow-up patch for connector
detection.
During driver loading/unloading/system suspend/shutdown and during
system resume after calling intel_display_driver_disable_user_access()
or intel_display_driver_resume_access() correspondigly, the current
thread is allowed to modeset (as this thread requires to do an
initial/restoring modeset or a disabling modeset), other threads (the
user threads) are not allowed to modeset.
During driver loading/system resume after calling
intel_display_driver_enable_user_access() all threads are allowed to
modeset.
During driver unloading/system suspend/shutdown after calling
intel_display_driver_suspend_access() no threads are allowed to modeset
(as the HW got disabled and should stay in this state).
v2: Call intel_display_driver_suspend_access()/resume_access() only
for HAS_DISPLAY(). (CI)
v3: (Jouni)
- Add commit log comments explaining how the permission of modeset
changes during HW init/deinit wrt. to the current and other user
processes.
Link: https://patchwork.freedesktop.org/patch/msgid/20240104132335.2766434-1-imre.deak@intel.com
Reviewed-by: Jouni Högander <jouni.hogander@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Suspend the FB console during driver shutdown the same way this is done
during system resume. This should prevent any HPD event to trigger a new
FB probe/modeset cycle happening in parallel with the display HW
disable/uninitialize steps.
A preceding FB HPD event handling may be still pending, resulting in a
probe/modeset like the above, these will be prevented by a later change
in this patchset.
Link: https://patchwork.freedesktop.org/patch/msgid/20240104083008.2715733-6-imre.deak@intel.com
Reviewed-by: Jouni Högander <jouni.hogander@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
The only purpose of intel_hpd_poll_disable() during driver loading and
system resume - at which point polling should be disabled anyway, except
for connectors in an IRQ storm, for which the polling will stay enabled -
is to force-detect all the connectors. However this detection in
i915_hpd_poll_init_work() depends on drm.mode_config.poll_enabled, which
will get set in drm_kms_helper_poll_init(), possibly after
i915_hpd_poll_init_work() is scheduled. Hence the initial detection of
connectors during driver loading may not happen.
Fix the above by moving intel_hpd_poll_disable() after
i915_hpd_poll_init_work(), the proper place anyway for doing the above
detection after all the HW initialization steps are complete. Change the
order the same way during system resume as well. The above race
condition shouldn't matter here - as drm.mode_config.poll_enabled will
be set - but the detection should happen here as well after the HW init
steps are done.
Link: https://patchwork.freedesktop.org/patch/msgid/20240104083008.2715733-5-imre.deak@intel.com
Reviewed-by: Jouni Högander <jouni.hogander@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Deinitialize audio during driver unload after disabling polling. This is
in preparation to do all the display HW init/deinit steps at a point
where no HPD IRQ or polling initiated connector detection or modeset can
change the HW state. This may still happen here via an HPD IRQ ->
hotplug detection work or a connector sysfs (state/detect) access, but
these will be prevented by later changes in this patchset.
Link: https://patchwork.freedesktop.org/patch/msgid/20240104083008.2715733-4-imre.deak@intel.com
Reviewed-by: Jouni Högander <jouni.hogander@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
If an HPD IRQ storm is detected on a connector during driver loading or
system suspend/resume - disabling the IRQ and switching to polling - the
polling may get disabled too early - before the intended 2 minute
HPD_STORM_REENABLE_DELAY - with the HPD IRQ staying disabled for this
duration. One such sequence is:
Thread#1 Thread#2
intel_display_driver_probe()->
intel_hpd_init()->
(HPD IRQ gets enabled)
. intel_hpd_irq_handler()->
. intel_hpd_irq_storm_detect()
. intel_hpd_irq_setup()->
. (HPD IRQ gets disabled)
. queue_delayed_work(hotplug.hotplug_work)
. ...
. i915_hotplug_work_func()->
. intel_hpd_irq_storm_switch_to_polling()->
. (polling enabled)
.
intel_hpd_poll_disable()->
queue_work(hotplug.poll_init_work)
...
i915_hpd_poll_init_work()->
(polling gets disabled,
HPD IRQ is still disabled)
...
(Connector is neither polled or
detected via HPD IRQs for 2 minutes)
intel_hpd_irq_storm_reenable_work()->
(HPD IRQ gets enabled)
To avoid the above 2 minute state without either polling or enabled HPD
IRQ, leave the connector's polling mode unchanged in
i915_hpd_poll_init_work() if its HPD IRQ got disabled after an IRQ storm
indicated by the connector's HPD_DISABLED pin state.
Link: https://patchwork.freedesktop.org/patch/msgid/20240104083008.2715733-3-imre.deak@intel.com
Reviewed-by: Jouni Högander <jouni.hogander@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
After an HPD IRQ storm on a connector intel_hpd_irq_storm_detect() will
set the connector's HPD pin state to HPD_MARK_DISABLED and the IRQ gets
disabled. Subsequently intel_hpd_irq_storm_switch_to_polling() will
enable polling for these connectors, setting the pin state to
HPD_DISABLED, but only if the connector's base.polled field is set to
DRM_CONNECTOR_POLL_HPD. intel_hpd_irq_storm_reenable_work() will
reenable the IRQ - after 2 minutes - if the pin state is HPD_DISABLED.
The connectors will be created with their base.polled field set to 0,
which gets initialized only later in i915_hpd_poll_init_work() (using
intel_connector::polled). If a storm is detected on a connector after
it's created and IRQs are enabled on it - by intel_hpd_init() - and
before its bease.polled field is initialized in the above work, the
connector's HPD pin will stay in the HPD_MARK_DISABLED state - leaving
the IRQ disabled indefinitely - and polling will not get enabled on it as
intended.
I can't see a reason for initializing base.polled in a delayed manner,
so do this already when creating the connector, to prevent the above
race condition.
Link: https://patchwork.freedesktop.org/patch/msgid/20240104083008.2715733-2-imre.deak@intel.com
Reviewed-by: Jouni Högander <jouni.hogander@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
I/O video memory for the framebuffer supports write-combine caching
mode. Simplify the driver's code that sets up the caching mode.
* Map video memory with ioremap_wc(), which automatically sets up
the PAT entry with write-combine caching.
* Remove the now obsolete call to devm_arch_io_reserve_memtype_wc().
It is only required to mmap the video memory to user space, which the
driver doesn't do.
* According to the PAT documentation, arch_phys_wc_add() is best
called after remapping I/O memory, so move it after ioremap.
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Reviewed-by: Jocelyn Falempe <jfalempe@redhat.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240105082714.21881-1-tzimmermann@suse.de
A failure to load the HuC is occasionally observed where the cause is
believed to be a low GT frequency leading to very long load times.
So a) increase the timeout so that the user still gets a working
system even in the case of slow load. And b) report the frequency
during the load to see if that is the cause of the slow down.
Also update the similar code on the GuC load to not use uncore->gt
when there is a local gt available. The two should match, but no need
for unnecessary de-referencing.
Signed-off-by: John Harrison <John.C.Harrison@Intel.com>
Reviewed-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240102222202.310495-1-John.C.Harrison@Intel.com
IGT `amdgpu/amd_color/crtc-lut-accuracy` fails right at the beginning of
the test execution, during atomic check, because DC rejects the
bandwidth state for a fb sizing 64x64. The test was previously working
with the deprecated dc_commit_state(). Now using
dc_validate_with_context() approach, the atomic check needs to perform a
full state validation. Therefore, set fast_validation to false in the
dc_validate_global_state call for atomic check.
Cc: stable@vger.kernel.org
Fixes: b8272241ff ("drm/amd/display: Drop dc_commit_state in favor of dc_commit_streams")
Signed-off-by: Melissa Wen <mwen@igalia.com>
Signed-off-by: Hamza Mahfooz <hamza.mahfooz@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
These chips needs the same fix. This was previously not seen
on then since the AGP aperture expanded the system aperture,
but this showed up again when AGP was disabled.
Reviewed-and-tested-by: Jiadong Zhu <Jiadong.Zhu@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
gcc prints a warning about a possible array overflow for a couple of
callers of dp_decide_lane_settings() after commit 1b56c90018f0 ("Makefile:
Enable -Wstringop-overflow globally"):
drivers/gpu/drm/amd/amdgpu/../display/dc/link/protocols/link_dp_training_fixed_vs_pe_retimer.c: In function 'dp_perform_fixed_vs_pe_training_sequence_legacy':
drivers/gpu/drm/amd/amdgpu/../display/dc/link/protocols/link_dp_training_fixed_vs_pe_retimer.c:426:25: error: 'dp_decide_lane_settings' accessing 4 bytes in a region of size 1 [-Werror=stringop-overflow=]
426 | dp_decide_lane_settings(lt_settings, dpcd_lane_adjust,
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
427 | lt_settings->hw_lane_settings, lt_settings->dpcd_lane_settings);
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
drivers/gpu/drm/amd/amdgpu/../display/dc/link/protocols/link_dp_training_fixed_vs_pe_retimer.c:426:25: note: referencing argument 4 of type 'union dpcd_training_lane[4]'
I'm not entirely sure what caused this, but changing the prototype to expect
a pointer instead of an array avoids the warnings.
Fixes: 7727e7b60f ("drm/amd/display: Improve robustness of FIXED_VS link training at DP1 rates")
Acked-by: Randy Dunlap <rdunlap@infradead.org>
Tested-by: Randy Dunlap <rdunlap@infradead.org> # build-tested
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Place HDCP_EVENT_TRACE(hdcp, event) macro content inside do while loop
to avoid if-else issues in hdcp_log.h file
v2: fix up build (Alex)
Signed-off-by: Marcelo Mendes Spessoto Junior <marcelomspessoto@gmail.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Remove braces for single statement if expressions and change comparison
order for hdcp2_execution.c file
Signed-off-by: Marcelo Mendes Spessoto Junior <marcelomspessoto@gmail.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Fix identation inside enum and place expressions in define macros inside
() for hdcp_psp.h file
Signed-off-by: Marcelo Mendes Spessoto Junior <marcelomspessoto@gmail.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Remove braces from single statement if expression in hdcp1_execution.c
file
Signed-off-by: Marcelo Mendes Spessoto Junior <marcelomspessoto@gmail.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
The hwmgr->backend, (i.e. data) allocated by kzalloc is not freed in
the error-handling paths of smu7_get_evv_voltages and
smu7_update_edc_leakage_table. However, it did be freed in the
error-handling of phm_initializa_dynamic_state_adjustment_rule_settings,
by smu7_hwmgr_backend_fini. So the lack of free in smu7_get_evv_voltages
and smu7_update_edc_leakage_table is considered a memleak in this patch.
Fixes: 599a7e9fe1 ("drm/amd/powerplay: implement smu7 hwmgr to manager asics with smu ip version 7.")
Fixes: 8f0804c6b7 ("drm/amd/pm: add edc leakage controller setting")
Signed-off-by: Zhipeng Lu <alexious@zju.edu.cn>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Before using list_first_entry, make sure to check that list is not
empty, if list is empty return -ENODATA.
Fixes the below:
drivers/gpu/drm/amd/amdgpu/../amdkfd/kfd_topology.c:1347 kfd_create_indirect_link_prop() warn: can 'gpu_link' even be NULL?
drivers/gpu/drm/amd/amdgpu/../amdkfd/kfd_topology.c:1428 kfd_add_peer_prop() warn: can 'iolink1' even be NULL?
drivers/gpu/drm/amd/amdgpu/../amdkfd/kfd_topology.c:1433 kfd_add_peer_prop() warn: can 'iolink2' even be NULL?
Fixes: 0f28cca87e ("drm/amdkfd: Extend KFD device topology to surface peer-to-peer links")
Cc: Felix Kuehling <Felix.Kuehling@amd.com>
Cc: Christian König <christian.koenig@amd.com>
Cc: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Srinivasan Shanmugam <srinivasan.shanmugam@amd.com>
Suggested-by: Felix Kuehling <Felix.Kuehling@amd.com>
Suggested-by: Lijo Lazar <lijo.lazar@amd.com>
Reviewed-by: Felix Kuehling <felix.kuehling@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
mod_freesync header file has duplicated copyright boilerplate. Drop the
duplicate.
Signed-off-by: Marcelo Mendes Spessoto Junior <marcelomspessoto@gmail.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
The check for sending the vsc infopacket to the display was gated behind
PSR (Panel Self Refresh) being enabled.
The vsc infopacket also contains the colorimetry (specifically the
container color gamut) information for the stream on modern DP.
PSR is typically only supported on mobile phone eDP displays, thus this
was not getting sent for typical desktop monitors or TV screens.
This functionality is needed for proper HDR10 functionality on DP as it
wants BT2020 RGB/YCbCr for the container color space.
Cc: stable@vger.kernel.org
Cc: Harry Wentland <harry.wentland@amd.com>
Cc: Xaver Hugl <xaver.hugl@gmail.com>
Cc: Melissa Wen <mwen@igalia.com>
Fixes: 15f9dfd545 ("drm/amd/display: Register Colorspace property for DP and HDMI")
Tested-by: Simon Berz <simon@berz.me>
Tested-by: Xaver Hugl <xaver.hugl@kde.org>
Signed-off-by: Joshua Ashton <joshua@froggi.es>
Signed-off-by: Hamza Mahfooz <hamza.mahfooz@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Commit 5a028e8f06 ("drm/rockchip: vop2: Add support for rk3588")
introduced a variable which ended up being unused:
rockchip_drm_vop2.c:1688:23: warning: variable ‘if_dclk_rate’ set but not used [-Wunused-but-set-variable]
This has been initially used as part of a formula to compute the clock
dividers, but eventually it has been replaced by static values.
Drop the variable declaration and move its assignment to the comment
block, to serve as documentation of how the constants have been
generated.
Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Link: https://patchwork.freedesktop.org/patch/msgid/20240105174007.98054-1-cristian.ciocaltea@collabora.com
