path: root/Documentation
diff options
authorThierry Reding <treding@nvidia.com>2018-12-06 18:56:47 +0100
committerThierry Reding <treding@nvidia.com>2018-12-06 18:58:32 +0100
commit180b46ecdc9f7762aba65c0b029f59c7a6b314fd (patch)
treec519957f5e0d9ccd8c7814773273bf72ef72981a /Documentation
parentdrm/tegra: sor: Remove temporary workaround (diff)
drm/tegra: sor: Reset the SOR if possible
If the SOR is already up and running when the kernel driver is probed, setting a mode will typically fail. This can be seen for example on Jetson TX2. Under certain circumstances the generic power domain code will cause the SOR to be reset. However, if the power domain is never powered off (this can happen if the HDA controller is enabled, which is part of the same power domain as the SOR), then the SOR will end up not getting reset and fail to properly set a mode. To work around this, try to get the reset control and assert/deassert it, irrespective of whether or not a generic power domain is attached to the SOR. On platforms where the kernel implements generic power domains (up to Tegra210) this will fail, because the power domain will already have acquired an exclusive reference to the reset control. But on recent platforms there the BPMP provides an ABI to control power domains, it's possible to acquire the reset control from SOR and use it to put the SOR into a known good state at probe time. The proper solution for this is to make the SOR driver capable of dealing with hardware that's already up and running (by first grace- fully shutting it down, or perhaps by seamlessly transitioning to the kernel driver and taking over the running display configuration). That is fairly involved, though, so we'll go with this quickfix for now. Signed-off-by: Thierry Reding <treding@nvidia.com>
Diffstat (limited to 'Documentation')
0 files changed, 0 insertions, 0 deletions