9984d6664ce9 ("drm/vc4: hdmi: Make sure the controller is powered in detect")
411efa18e4b0 ("drm/vc4: hdmi: Move the HSM clock enable to runtime_pm")
as Michael Stapelberg reports that the new runtime PM changes cause his
Raspberry Pi 3 to hang on boot, probably due to interactions with other
changes in the DRM tree (because a bisect points to the merge in commit
e058a84bfddc: "Merge tag 'drm-next-2021-07-01' of git://.../drm").
Revert these two commits until it's been resolved.
Link: https://<email address hidden>/
Reported-and-tested-by: Michael Stapelberg <email address hidden>
Cc: Maxime Ripard <email address hidden>
Cc: Dave Stevenson <email address hidden>
Cc: Dave Airlie <email address hidden>
Signed-off-by: Linus Torvalds <email address hidden>
Signed-off-by: Sasha Levin <email address hidden>
Signed-off-by: Timo Aaltonen <email address hidden>
8c8a0be...
by
Meenakshikumar Somasundaram <email address hidden>
drm/amd/display: Link training retry fix for abort case
[Why]
If link training is aborted, it shall be retried if sink is present.
[How]
Check hpd status to find out whether sink is present or not. If sink is
present, then link training shall be tried again with same settings.
Otherwise, link training shall be aborted.
[Why]
Intermittently, there presents two occurrences of 0 stream
commits in a single HPD event. Current HDCP sequence does
not consider such scenerio, and will thus disable HDCP.
[How]
Add condition check to include stream remove and re-enable
case for HDCP enable.
On some GPUs the PCIe atomic requirement for KFD depends on the MEC
firmware version. Add a firmware version check for this. The minimum
firmware version that works without atomics can be updated in the
device_info structure for each GPU type.
Move PCIe atomic detection from kgd2kfd_probe into kgd2kfd_device_init
because the MEC firmware is not loaded yet at the probe stage.
Signed-off-by: Felix Kuehling <email address hidden>
Reviewed-by: Guchun Chen <email address hidden>
Signed-off-by: Alex Deucher <email address hidden>
Signed-off-by: Sasha Levin <email address hidden>
Signed-off-by: Timo Aaltonen <email address hidden>
On sparc64, __fls() returns an "int", but the drm TTM code expected it
to be "unsigned long" as on x86. As a result, on sparc (and arc, and
m68k) you get build errors because 'min()' checks that the types match.
As suggested by Linus, it can use min_t instead of min to force the type
to be "unsigned int".
Suggested-by: Linus Torvalds <email address hidden>
Signed-off-by: Huang Rui <email address hidden>
Reviewed-by: Christian König <email address hidden>
Cc: Alex Deucher <email address hidden>
Cc: David Airlie <email address hidden>
Cc: Daniel Vetter <email address hidden>
Cc: Guenter Roeck <email address hidden>
Signed-off-by: Linus Torvalds <email address hidden>
Signed-off-by: Sasha Levin <email address hidden>
Signed-off-by: Timo Aaltonen <email address hidden>
For xnack off, restore work dma unmap previous system memory page, and
dma map the updated system memory page to update GPU mapping, this is
not dma mapping leaking, remove the WARN_ONCE for dma mapping leaking.
prange->dma_addr store the VRAM page pfn after the range migrated to
VRAM, should not dma unmap VRAM page when updating GPU mapping or
remove prange. Add helper svm_is_valid_dma_mapping_addr to check VRAM
page and error cases.
Mask out SVM_RANGE_VRAM_DOMAIN flag in dma_addr before calling amdgpu vm
update to avoid BUG_ON(*addr & 0xFFFF00000000003FULL), and set it again
immediately after. This flag is used to know the type of page later to
dma unmapping system memory page.
Fixes: 1d5dbfe6c06a ("drm/amdkfd: classify and map mixed svm range pages in GPU")
Signed-off-by: Philip Yang <email address hidden>
Reviewed-by: Felix Kuehling <email address hidden>
Signed-off-by: Alex Deucher <email address hidden>
Signed-off-by: Sasha Levin <email address hidden>
Signed-off-by: Timo Aaltonen <email address hidden>
