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)
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>
1 files changed, 13 insertions, 4 deletions
diff --git a/drivers/gpu/drm/tegra/sor.c b/drivers/gpu/drm/tegra/sor.c
index 07a077bd73e4..ef8692b7075a 100644
--- a/drivers/gpu/drm/tegra/sor.c
+++ b/drivers/gpu/drm/tegra/sor.c
@@ -3340,14 +3340,23 @@ static int tegra_sor_probe(struct platform_device *pdev)
goto remove;
- if (!pdev->dev.pm_domain) {
- sor->rst = devm_reset_control_get(&pdev->dev, "sor");
- if (IS_ERR(sor->rst)) {
- err = PTR_ERR(sor->rst);
+ sor->rst = devm_reset_control_get(&pdev->dev, "sor");
+ if (IS_ERR(sor->rst)) {
+ err = PTR_ERR(sor->rst);
+ if (err != -EBUSY || WARN_ON(!pdev->dev.pm_domain)) {
dev_err(&pdev->dev, "failed to get reset control: %d\n",
goto remove;
+ /*
+ * At this point, the reset control is most likely being used
+ * by the generic power domain implementation. With any luck
+ * the power domain will have taken care of resetting the SOR
+ * and we don't have to do anything.
+ */
+ sor->rst = NULL;
sor->clk = devm_clk_get(&pdev->dev, NULL);