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>
Remove the temporary workaround of storing the Tegra186 HDMI/DP I/O pad ID in the SOR driver. The definition has long been available in the soc/tegra/pmc.h header file. Signed-off-by: Thierry Reding <treding@nvidia.com>
This code is very similar to the audio over HDMI support on older chips. Interoperation with the audio codec is done via a pair of codec scratch registers and an interrupt that is raised at the SOR when the codec has written those registers. Signed-off-by: Thierry Reding <treding@nvidia.com>
Display controllers that don't own any windows and which therefore aren't currently being assigned a primary plane are not registered as a CRTC with the DRM framework. They request neither a syncpoint nor an interrupt because they don't use them, so avoid cleaning up those resources. Signed-off-by: Thierry Reding <treding@nvidia.com>
The display architecture on Tegra186 and Tegra194 requires that there be some valid clock on all domains before accessing any display register. A further requirement is that in addition to the host1x, hub, disp and dsc clocks, all the head clocks (pclk0-2 on Tegra186 or pclk0-3 on Tegra194) must also be enabled. Implement this logic within the display hub driver to ensure the clocks are always enabled at the right time. Signed-off-by: Thierry Reding <treding@nvidia.com>
The Video Image Composer (VIC) generation found on Tegra194 is backwards compatible with its predecessor found on Tegra186. Reviewed-by: Mikko Perttunen <mperttunen@nvidia.com> Signed-off-by: Thierry Reding <treding@nvidia.com>
Before booting the Falcon processor, make sure to wait for memory scrubbing to complete. Signed-off-by: Thierry Reding <treding@nvidia.com>
The ->alloc() callback in struct falcon_ops returns an ERR_PTR()-encoded error code on failure, so it needs to be properly checked for, otherwise subsequent code may dereference an invalid pointer. Signed-off-by: Thierry Reding <treding@nvidia.com>
Tegra supports generic PM domains on 64-bit ARM, and if that is enabled, the power domain code will make sure that resets are asserted and deasserted at appropriate points in time. If generic PM domains are not implemented, such as on 32-bit Tegra, the resets need to be asserted and deasserted explicitly by the driver. Reviewed-by: Jon Hunter <jonathanh@nvidia.com> Signed-off-by: Thierry Reding <treding@nvidia.com>
drm/tegra: Changes for v4.20-rc1 This contains initial Tegra194 support as well as a couple of fixes for DMA/IOMMU integration. Signed-off-by: Dave Airlie <airlied@redhat.com> From: Thierry Reding <thierry.reding@gmail.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180927205051.30017-1-thierry.reding@gmail.com