Skip to content
  1. Mar 30, 2021
    • Thierry Reding's avatar
      drm/tegra: sor: Grab runtime PM reference across reset · ac097aec
      Thierry Reding authored 
      

The SOR resets are exclusively shared with the SOR power domain. This
means that exclusive access can only be granted temporarily and in order
for that to work, a rigorous sequence must be observed. To ensure that a
single consumer gets exclusive access to a reset, each consumer must
implement a rigorous protocol using the reset_control_acquire() and
reset_control_release() functions.

However, these functions alone don't provide any guarantees at the
system level. Drivers need to ensure that the only a single consumer has
access to the reset at the same time. In order for the SOR to be able to
exclusively access its reset, it must therefore ensure that the SOR
power domain is not powered off by holding on to a runtime PM reference
to that power domain across the reset assert/deassert operation.

This used to work fine by accident, but was revealed when recently more
devices started to rely on the SOR power domain.

Fixes: 11c632e1 ("drm/tegra: sor: Implement acquire/release for reset")
Reported-by: default avatarJonathan Hunter <jonathanh@nvidia.com>
Signed-off-by: default avatarThierry Reding <treding@nvidia.com>
      ac097aec
    • Thierry Reding's avatar
      drm/tegra: dc: Restore coupling of display controllers · a31500fe
      Thierry Reding authored 
      

Coupling of display controllers used to rely on runtime PM to take the
companion controller out of reset. Commit fd67e9c6 ("drm/tegra: Do
not implement runtime PM") accidentally broke this when runtime PM was
removed.

Restore this functionality by reusing the hierarchical host1x client
suspend/resume infrastructure that's similar to runtime PM and which
perfectly fits this use-case.

Fixes: fd67e9c6 ("drm/tegra: Do not implement runtime PM")
Reported-by: default avatarDmitry Osipenko <digetx@gmail.com>
Reported-by: default avatarPaul Fertser <fercerpav@gmail.com>
Tested-by: default avatarDmitry Osipenko <digetx@gmail.com>
Signed-off-by: default avatarThierry Reding <treding@nvidia.com>
      a31500fe
    • Dmitry Osipenko's avatar
      drm/tegra: dc: Don't set PLL clock to 0Hz · f8fb97c9
      Dmitry Osipenko authored 
      

RGB output doesn't allow to change parent clock rate of the display and
PCLK rate is set to 0Hz in this case. The tegra_dc_commit_state() shall
not set the display clock to 0Hz since this change propagates to the
parent clock. The DISP clock is defined as a NODIV clock by the tegra-clk
driver and all NODIV clocks use the CLK_SET_RATE_PARENT flag.

This bug stayed unnoticed because by default PLLP is used as the parent
clock for the display controller and PLLP silently skips the erroneous 0Hz
rate changes because it always has active child clocks that don't permit
rate changes. The PLLP isn't acceptable for some devices that we want to
upstream (like Samsung Galaxy Tab and ASUS TF700T) due to a display panel
clock rate requirements that can't be fulfilled by using PLLP and then the
bug pops up in this case since parent clock is set to 0Hz, killing the
display output.

Don't touch DC clock if pclk=0 in order to fix the problem.

Signed-off-by: default avatarDmitry Osipenko <digetx@gmail.com>
Signed-off-by: default avatarThierry Reding <treding@nvidia.com>
      f8fb97c9
  3. Mar 13, 2021
  5. Mar 12, 2021
  7. Mar 11, 2021
  9. Mar 10, 2021
  11. Mar 04, 2021