diff options
author | Thierry Reding <treding@nvidia.com> | 2018-12-06 18:56:47 +0100 |
---|---|---|
committer | Thierry Reding <treding@nvidia.com> | 2018-12-06 18:58:32 +0100 |
commit | 180b46ecdc9f7762aba65c0b029f59c7a6b314fd (patch) | |
tree | c519957f5e0d9ccd8c7814773273bf72ef72981a /drivers/gpu/drm | |
parent | 016a48b3d66e94c99253b79ca16ac656a9de5740 (diff) | |
download | linux-stable-180b46ecdc9f7762aba65c0b029f59c7a6b314fd.tar.gz linux-stable-180b46ecdc9f7762aba65c0b029f59c7a6b314fd.tar.bz2 linux-stable-180b46ecdc9f7762aba65c0b029f59c7a6b314fd.zip |
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 'drivers/gpu/drm')
-rw-r--r-- | drivers/gpu/drm/tegra/sor.c | 17 |
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", err); 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); |