diff mbox

[08/22] drm/tegra: dc: Drop the reset asserts to workaround a bug

Message ID 35e1ef44da98701b2c507c31ecc0812530303d2d.1495498184.git.digetx@gmail.com (mailing list archive)
State New, archived
Headers show

Commit Message

Dmitry Osipenko May 23, 2017, 12:14 a.m. UTC
Commit 33a8eb8 ("Implement runtime PM") introduced HW reset control. It
causes a hang on Tegra20 if both display controllers are utilized (RGB
panel and HDMI). The TRM suggests that each display controller has its own
reset control, apparently it is not correct. Let's remove the interaction
with the resets for now as a workaround.

Fixes: 33a8eb8d40ee ("drm/tegra: dc: Implement runtime PM")
Signed-off-by: Dmitry Osipenko <digetx@gmail.com>
---
 drivers/gpu/drm/tegra/dc.c | 15 ---------------
 1 file changed, 15 deletions(-)

Comments

Thierry Reding June 13, 2017, 1:45 p.m. UTC | #1
On Tue, May 23, 2017 at 03:14:23AM +0300, Dmitry Osipenko wrote:
> Commit 33a8eb8 ("Implement runtime PM") introduced HW reset control. It
> causes a hang on Tegra20 if both display controllers are utilized (RGB
> panel and HDMI). The TRM suggests that each display controller has its own
> reset control, apparently it is not correct. Let's remove the interaction
> with the resets for now as a workaround.
> 
> Fixes: 33a8eb8d40ee ("drm/tegra: dc: Implement runtime PM")
> Signed-off-by: Dmitry Osipenko <digetx@gmail.com>
> ---
>  drivers/gpu/drm/tegra/dc.c | 15 ---------------
>  1 file changed, 15 deletions(-)

Do you mind if I parameterize this to restrict omission of the assert
and deassert to Tegra20? I'm fairly sure that these resets are important
on later chips in order to properly reset the display controllers.

My proposal would be to add a field to struct tegra_dc_soc_info (maybe
.broken_reset) that will be set only on Tegra20 to still allow the DC to
be reset on later generations.

Thierry
Dmitry Osipenko June 13, 2017, 2:18 p.m. UTC | #2
On 13.06.2017 16:45, Thierry Reding wrote:
> On Tue, May 23, 2017 at 03:14:23AM +0300, Dmitry Osipenko wrote:
>> Commit 33a8eb8 ("Implement runtime PM") introduced HW reset control. It
>> causes a hang on Tegra20 if both display controllers are utilized (RGB
>> panel and HDMI). The TRM suggests that each display controller has its own
>> reset control, apparently it is not correct. Let's remove the interaction
>> with the resets for now as a workaround.
>>
>> Fixes: 33a8eb8d40ee ("drm/tegra: dc: Implement runtime PM")
>> Signed-off-by: Dmitry Osipenko <digetx@gmail.com>
>> ---
>>  drivers/gpu/drm/tegra/dc.c | 15 ---------------
>>  1 file changed, 15 deletions(-)
> 
> Do you mind if I parameterize this to restrict omission of the assert
> and deassert to Tegra20? I'm fairly sure that these resets are important
> on later chips in order to properly reset the display controllers.

I don't mind at all, I can parameterize it in the next rev myself if you wish.

> My proposal would be to add a field to struct tegra_dc_soc_info (maybe
> .broken_reset) that will be set only on Tegra20 to still allow the DC to
> be reset on later generations.

Sounds good.
Thierry Reding June 13, 2017, 3:07 p.m. UTC | #3
On Tue, Jun 13, 2017 at 05:18:37PM +0300, Dmitry Osipenko wrote:
> On 13.06.2017 16:45, Thierry Reding wrote:
> > On Tue, May 23, 2017 at 03:14:23AM +0300, Dmitry Osipenko wrote:
> >> Commit 33a8eb8 ("Implement runtime PM") introduced HW reset control. It
> >> causes a hang on Tegra20 if both display controllers are utilized (RGB
> >> panel and HDMI). The TRM suggests that each display controller has its own
> >> reset control, apparently it is not correct. Let's remove the interaction
> >> with the resets for now as a workaround.
> >>
> >> Fixes: 33a8eb8d40ee ("drm/tegra: dc: Implement runtime PM")
> >> Signed-off-by: Dmitry Osipenko <digetx@gmail.com>
> >> ---
> >>  drivers/gpu/drm/tegra/dc.c | 15 ---------------
> >>  1 file changed, 15 deletions(-)
> > 
> > Do you mind if I parameterize this to restrict omission of the assert
> > and deassert to Tegra20? I'm fairly sure that these resets are important
> > on later chips in order to properly reset the display controllers.
> 
> I don't mind at all, I can parameterize it in the next rev myself if you wish.

Sure, why not.

Thierry
diff mbox

Patch

diff --git a/drivers/gpu/drm/tegra/dc.c b/drivers/gpu/drm/tegra/dc.c
index 95b373f739f2..5c9b93981af2 100644
--- a/drivers/gpu/drm/tegra/dc.c
+++ b/drivers/gpu/drm/tegra/dc.c
@@ -1989,8 +1989,6 @@  static int tegra_dc_probe(struct platform_device *pdev)
 		return PTR_ERR(dc->rst);
 	}
 
-	reset_control_assert(dc->rst);
-
 	if (dc->soc->has_powergate) {
 		if (dc->pipe == 0)
 			dc->powergate = TEGRA_POWERGATE_DIS;
@@ -2061,13 +2059,6 @@  static int tegra_dc_remove(struct platform_device *pdev)
 static int tegra_dc_suspend(struct device *dev)
 {
 	struct tegra_dc *dc = dev_get_drvdata(dev);
-	int err;
-
-	err = reset_control_assert(dc->rst);
-	if (err < 0) {
-		dev_err(dev, "failed to assert reset: %d\n", err);
-		return err;
-	}
 
 	if (dc->soc->has_powergate)
 		tegra_powergate_power_off(dc->powergate);
@@ -2095,12 +2086,6 @@  static int tegra_dc_resume(struct device *dev)
 			dev_err(dev, "failed to enable clock: %d\n", err);
 			return err;
 		}
-
-		err = reset_control_deassert(dc->rst);
-		if (err < 0) {
-			dev_err(dev, "failed to deassert reset: %d\n", err);
-			return err;
-		}
 	}
 
 	return 0;