Revert "ARM: dts: rockchip: add startup delay to rk3288-veyron panel-regulators"
diff mbox series

Message ID 20190620182056.61552-1-dianders@chromium.org
State New
Headers show
Series
  • Revert "ARM: dts: rockchip: add startup delay to rk3288-veyron panel-regulators"
Related show

Commit Message

Doug Anderson June 20, 2019, 6:20 p.m. UTC
This reverts commit 1f45e8c6d0161f044d679f242fe7514e2625af4a.

This 100 ms mystery delay is not on downstream kernels and no longer
seems needed on upstream kernels either [1].  Presumably something in the
meantime has made things better.  A few possibilities for patches that
have landed in the meantime that could have made this better are
commit 3157694d8c7f ("pwm-backlight: Add support for PWM delays
proprieties."), commit 5fb5caee92ba ("pwm-backlight: Enable/disable
the PWM before/after LCD enable toggle."), and commit 6d5922dd0d60
("ARM: dts: rockchip: set PWM delay backlight settings for Veyron")

Let's revert and get our 100 ms back.

[1] https://lkml.kernel.org/r/2226970.BAPq4liE1j@diego

Signed-off-by: Douglas Anderson <dianders@chromium.org>
---

 arch/arm/boot/dts/rk3288-veyron-jaq.dts    | 1 -
 arch/arm/boot/dts/rk3288-veyron-jerry.dts  | 1 -
 arch/arm/boot/dts/rk3288-veyron-minnie.dts | 1 -
 arch/arm/boot/dts/rk3288-veyron-speedy.dts | 1 -
 4 files changed, 4 deletions(-)

Comments

Doug Anderson June 20, 2019, 8:31 p.m. UTC | #1
Hi,

On Thu, Jun 20, 2019 at 11:21 AM Douglas Anderson <dianders@chromium.org> wrote:
>
> This reverts commit 1f45e8c6d0161f044d679f242fe7514e2625af4a.
>
> This 100 ms mystery delay is not on downstream kernels and no longer
> seems needed on upstream kernels either [1].  Presumably something in the
> meantime has made things better.  A few possibilities for patches that
> have landed in the meantime that could have made this better are
> commit 3157694d8c7f ("pwm-backlight: Add support for PWM delays
> proprieties."), commit 5fb5caee92ba ("pwm-backlight: Enable/disable
> the PWM before/after LCD enable toggle."), and commit 6d5922dd0d60
> ("ARM: dts: rockchip: set PWM delay backlight settings for Veyron")
>
> Let's revert and get our 100 ms back.
>
> [1] https://lkml.kernel.org/r/2226970.BAPq4liE1j@diego
>
> Signed-off-by: Douglas Anderson <dianders@chromium.org>
> ---
>
>  arch/arm/boot/dts/rk3288-veyron-jaq.dts    | 1 -
>  arch/arm/boot/dts/rk3288-veyron-jerry.dts  | 1 -
>  arch/arm/boot/dts/rk3288-veyron-minnie.dts | 1 -
>  arch/arm/boot/dts/rk3288-veyron-speedy.dts | 1 -
>  4 files changed, 4 deletions(-)

Maybe wait before applying.  I've been running reboot tests now with
this patch applied (among others) and with enough reboots I managed to
see:

[    5.682418] rockchip-dp ff970000.dp: eDP link training failed (-5)

I'll see if I can confirm that it's this patch and why things are
different compared to downstream.

-Doug
Doug Anderson July 3, 2019, 4:54 a.m. UTC | #2
Hi,

On Thu, Jun 20, 2019 at 1:31 PM Doug Anderson <dianders@chromium.org> wrote:
>
> Hi,
>
> On Thu, Jun 20, 2019 at 11:21 AM Douglas Anderson <dianders@chromium.org> wrote:
> >
> > This reverts commit 1f45e8c6d0161f044d679f242fe7514e2625af4a.
> >
> > This 100 ms mystery delay is not on downstream kernels and no longer
> > seems needed on upstream kernels either [1].  Presumably something in the
> > meantime has made things better.  A few possibilities for patches that
> > have landed in the meantime that could have made this better are
> > commit 3157694d8c7f ("pwm-backlight: Add support for PWM delays
> > proprieties."), commit 5fb5caee92ba ("pwm-backlight: Enable/disable
> > the PWM before/after LCD enable toggle."), and commit 6d5922dd0d60
> > ("ARM: dts: rockchip: set PWM delay backlight settings for Veyron")
> >
> > Let's revert and get our 100 ms back.
> >
> > [1] https://lkml.kernel.org/r/2226970.BAPq4liE1j@diego
> >
> > Signed-off-by: Douglas Anderson <dianders@chromium.org>
> > ---
> >
> >  arch/arm/boot/dts/rk3288-veyron-jaq.dts    | 1 -
> >  arch/arm/boot/dts/rk3288-veyron-jerry.dts  | 1 -
> >  arch/arm/boot/dts/rk3288-veyron-minnie.dts | 1 -
> >  arch/arm/boot/dts/rk3288-veyron-speedy.dts | 1 -
> >  4 files changed, 4 deletions(-)
>
> Maybe wait before applying.  I've been running reboot tests now with
> this patch applied (among others) and with enough reboots I managed to
> see:
>
> [    5.682418] rockchip-dp ff970000.dp: eDP link training failed (-5)
>
> I'll see if I can confirm that it's this patch and why things are
> different compared to downstream.

OK, I finally got back to this and confirmed:

1. The above error is actually somewhat harmless.  The eDP failure
will be retried automatically despite the scary message.  Specifically
see the loop in analogix_dp_bridge_enable().  I confirmed that after
seeing the error the screen came up just fine (I looked at the screen
in two actual instances but I believe it's pretty much always fine).

2. I haven't seen any evidence that the eDP link training happens any
more often with this revert in place.  Specifically, I see the same
message in the logs (at what appears to be the same rate) with or
without this revert.

3. Probably the link-training failures here are the same ones we
debugged for PSR for rk3399-gru-kevin that we fixed by making the eDP
PCLK rate exactly 24 MHz.  See <https://crrev.com/c/433393> for
details.  On rk3399-gru-kevin it was super important to resolve the
root cause of these errors because we had PSR (which meant we were
constantly taking to the eDP controller).  On rk3288-veyron devices
with no PSR the retry should be a fine solution and it doesn't seem
like a good idea to fully rejigger our clock plan to fix the root
cause.


NOTE: I saw _one_ case on rk3288-veyron-minnie where the screen looked
wonky at bootup and I saw the eDP link training error in the logs.
That's what originally made me cautious.  I haven't been able to
reproduce this, but presumably I just got super unlucky in that one
case.  I've left devices rebooting all day at work and haven't seen
the wonky screen since then.


Summary: I think this revert is just fine.


-Doug
Heiko Stübner July 25, 2019, 9:33 p.m. UTC | #3
Am Mittwoch, 3. Juli 2019, 06:54:58 CEST schrieb Doug Anderson:
> Hi,
> 
> On Thu, Jun 20, 2019 at 1:31 PM Doug Anderson <dianders@chromium.org> wrote:
> >
> > Hi,
> >
> > On Thu, Jun 20, 2019 at 11:21 AM Douglas Anderson <dianders@chromium.org> wrote:
> > >
> > > This reverts commit 1f45e8c6d0161f044d679f242fe7514e2625af4a.
> > >
> > > This 100 ms mystery delay is not on downstream kernels and no longer
> > > seems needed on upstream kernels either [1].  Presumably something in the
> > > meantime has made things better.  A few possibilities for patches that
> > > have landed in the meantime that could have made this better are
> > > commit 3157694d8c7f ("pwm-backlight: Add support for PWM delays
> > > proprieties."), commit 5fb5caee92ba ("pwm-backlight: Enable/disable
> > > the PWM before/after LCD enable toggle."), and commit 6d5922dd0d60
> > > ("ARM: dts: rockchip: set PWM delay backlight settings for Veyron")
> > >
> > > Let's revert and get our 100 ms back.
> > >
> > > [1] https://lkml.kernel.org/r/2226970.BAPq4liE1j@diego
> > >
> > > Signed-off-by: Douglas Anderson <dianders@chromium.org>
> > > ---
> > >
> > >  arch/arm/boot/dts/rk3288-veyron-jaq.dts    | 1 -
> > >  arch/arm/boot/dts/rk3288-veyron-jerry.dts  | 1 -
> > >  arch/arm/boot/dts/rk3288-veyron-minnie.dts | 1 -
> > >  arch/arm/boot/dts/rk3288-veyron-speedy.dts | 1 -
> > >  4 files changed, 4 deletions(-)
> >
> > Maybe wait before applying.  I've been running reboot tests now with
> > this patch applied (among others) and with enough reboots I managed to
> > see:
> >
> > [    5.682418] rockchip-dp ff970000.dp: eDP link training failed (-5)
> >
> > I'll see if I can confirm that it's this patch and why things are
> > different compared to downstream.
> 
> OK, I finally got back to this and confirmed:
> 
> 1. The above error is actually somewhat harmless.  The eDP failure
> will be retried automatically despite the scary message.  Specifically
> see the loop in analogix_dp_bridge_enable().  I confirmed that after
> seeing the error the screen came up just fine (I looked at the screen
> in two actual instances but I believe it's pretty much always fine).
> 
> 2. I haven't seen any evidence that the eDP link training happens any
> more often with this revert in place.  Specifically, I see the same
> message in the logs (at what appears to be the same rate) with or
> without this revert.
> 
> 3. Probably the link-training failures here are the same ones we
> debugged for PSR for rk3399-gru-kevin that we fixed by making the eDP
> PCLK rate exactly 24 MHz.  See <https://crrev.com/c/433393> for
> details.  On rk3399-gru-kevin it was super important to resolve the
> root cause of these errors because we had PSR (which meant we were
> constantly taking to the eDP controller).  On rk3288-veyron devices
> with no PSR the retry should be a fine solution and it doesn't seem
> like a good idea to fully rejigger our clock plan to fix the root
> cause.
> 
> 
> NOTE: I saw _one_ case on rk3288-veyron-minnie where the screen looked
> wonky at bootup and I saw the eDP link training error in the logs.
> That's what originally made me cautious.  I haven't been able to
> reproduce this, but presumably I just got super unlucky in that one
> case.  I've left devices rebooting all day at work and haven't seen
> the wonky screen since then.
> 
> 
> Summary: I think this revert is just fine.

it looks like by picking Matthias' cleanups of the veyron displays
first I broke this patch. I guess we just need to remove the
	startup-delay-us = <100000>;
from the panel_regulator in the new rk3288-veyron-edp.dtsi ?


Heiko
Doug Anderson July 25, 2019, 11:35 p.m. UTC | #4
Hi,

On Thu, Jul 25, 2019 at 2:33 PM Heiko Stuebner <heiko@sntech.de> wrote:
>
> Am Mittwoch, 3. Juli 2019, 06:54:58 CEST schrieb Doug Anderson:
> > Hi,
> >
> > On Thu, Jun 20, 2019 at 1:31 PM Doug Anderson <dianders@chromium.org> wrote:
> > >
> > > Hi,
> > >
> > > On Thu, Jun 20, 2019 at 11:21 AM Douglas Anderson <dianders@chromium.org> wrote:
> > > >
> > > > This reverts commit 1f45e8c6d0161f044d679f242fe7514e2625af4a.
> > > >
> > > > This 100 ms mystery delay is not on downstream kernels and no longer
> > > > seems needed on upstream kernels either [1].  Presumably something in the
> > > > meantime has made things better.  A few possibilities for patches that
> > > > have landed in the meantime that could have made this better are
> > > > commit 3157694d8c7f ("pwm-backlight: Add support for PWM delays
> > > > proprieties."), commit 5fb5caee92ba ("pwm-backlight: Enable/disable
> > > > the PWM before/after LCD enable toggle."), and commit 6d5922dd0d60
> > > > ("ARM: dts: rockchip: set PWM delay backlight settings for Veyron")
> > > >
> > > > Let's revert and get our 100 ms back.
> > > >
> > > > [1] https://lkml.kernel.org/r/2226970.BAPq4liE1j@diego
> > > >
> > > > Signed-off-by: Douglas Anderson <dianders@chromium.org>
> > > > ---
> > > >
> > > >  arch/arm/boot/dts/rk3288-veyron-jaq.dts    | 1 -
> > > >  arch/arm/boot/dts/rk3288-veyron-jerry.dts  | 1 -
> > > >  arch/arm/boot/dts/rk3288-veyron-minnie.dts | 1 -
> > > >  arch/arm/boot/dts/rk3288-veyron-speedy.dts | 1 -
> > > >  4 files changed, 4 deletions(-)
> > >
> > > Maybe wait before applying.  I've been running reboot tests now with
> > > this patch applied (among others) and with enough reboots I managed to
> > > see:
> > >
> > > [    5.682418] rockchip-dp ff970000.dp: eDP link training failed (-5)
> > >
> > > I'll see if I can confirm that it's this patch and why things are
> > > different compared to downstream.
> >
> > OK, I finally got back to this and confirmed:
> >
> > 1. The above error is actually somewhat harmless.  The eDP failure
> > will be retried automatically despite the scary message.  Specifically
> > see the loop in analogix_dp_bridge_enable().  I confirmed that after
> > seeing the error the screen came up just fine (I looked at the screen
> > in two actual instances but I believe it's pretty much always fine).
> >
> > 2. I haven't seen any evidence that the eDP link training happens any
> > more often with this revert in place.  Specifically, I see the same
> > message in the logs (at what appears to be the same rate) with or
> > without this revert.
> >
> > 3. Probably the link-training failures here are the same ones we
> > debugged for PSR for rk3399-gru-kevin that we fixed by making the eDP
> > PCLK rate exactly 24 MHz.  See <https://crrev.com/c/433393> for
> > details.  On rk3399-gru-kevin it was super important to resolve the
> > root cause of these errors because we had PSR (which meant we were
> > constantly taking to the eDP controller).  On rk3288-veyron devices
> > with no PSR the retry should be a fine solution and it doesn't seem
> > like a good idea to fully rejigger our clock plan to fix the root
> > cause.
> >
> >
> > NOTE: I saw _one_ case on rk3288-veyron-minnie where the screen looked
> > wonky at bootup and I saw the eDP link training error in the logs.
> > That's what originally made me cautious.  I haven't been able to
> > reproduce this, but presumably I just got super unlucky in that one
> > case.  I've left devices rebooting all day at work and haven't seen
> > the wonky screen since then.
> >
> >
> > Summary: I think this revert is just fine.
>
> it looks like by picking Matthias' cleanups of the veyron displays
> first I broke this patch. I guess we just need to remove the
>         startup-delay-us = <100000>;
> from the panel_regulator in the new rk3288-veyron-edp.dtsi ?

Oops, I only checked Matthias's change against the current status of
your for-next tree and forgot about this change.  Yes, the
startup-delay should be removed there.  Do you want to resolve that
when applying the patch or would you prefer a resend?

-Doug
Heiko Stübner Aug. 16, 2019, 11:28 a.m. UTC | #5
Am Donnerstag, 20. Juni 2019, 20:20:56 CEST schrieb Douglas Anderson:
> This reverts commit 1f45e8c6d0161f044d679f242fe7514e2625af4a.
> 
> This 100 ms mystery delay is not on downstream kernels and no longer
> seems needed on upstream kernels either [1].  Presumably something in the
> meantime has made things better.  A few possibilities for patches that
> have landed in the meantime that could have made this better are
> commit 3157694d8c7f ("pwm-backlight: Add support for PWM delays
> proprieties."), commit 5fb5caee92ba ("pwm-backlight: Enable/disable
> the PWM before/after LCD enable toggle."), and commit 6d5922dd0d60
> ("ARM: dts: rockchip: set PWM delay backlight settings for Veyron")
> 
> Let's revert and get our 100 ms back.
> 
> [1] https://lkml.kernel.org/r/2226970.BAPq4liE1j@diego
> 
> Signed-off-by: Douglas Anderson <dianders@chromium.org>

I've rebased the change on top of Matthias' veyron display reorganization
and applied it for 5.4

Thanks
Heiko

Patch
diff mbox series

diff --git a/arch/arm/boot/dts/rk3288-veyron-jaq.dts b/arch/arm/boot/dts/rk3288-veyron-jaq.dts
index fcd119168cb6..5411ce148890 100644
--- a/arch/arm/boot/dts/rk3288-veyron-jaq.dts
+++ b/arch/arm/boot/dts/rk3288-veyron-jaq.dts
@@ -24,7 +24,6 @@ 
 		pinctrl-names = "default";
 		pinctrl-0 = <&lcd_enable_h>;
 		regulator-name = "panel_regulator";
-		startup-delay-us = <100000>;
 		vin-supply = <&vcc33_sys>;
 	};
 
diff --git a/arch/arm/boot/dts/rk3288-veyron-jerry.dts b/arch/arm/boot/dts/rk3288-veyron-jerry.dts
index 164561f04c1d..82ac9d23480e 100644
--- a/arch/arm/boot/dts/rk3288-veyron-jerry.dts
+++ b/arch/arm/boot/dts/rk3288-veyron-jerry.dts
@@ -26,7 +26,6 @@ 
 		pinctrl-names = "default";
 		pinctrl-0 = <&lcd_enable_h>;
 		regulator-name = "panel_regulator";
-		startup-delay-us = <100000>;
 		vin-supply = <&vcc33_sys>;
 	};
 
diff --git a/arch/arm/boot/dts/rk3288-veyron-minnie.dts b/arch/arm/boot/dts/rk3288-veyron-minnie.dts
index b2cc70a08554..f29501d8ff07 100644
--- a/arch/arm/boot/dts/rk3288-veyron-minnie.dts
+++ b/arch/arm/boot/dts/rk3288-veyron-minnie.dts
@@ -33,7 +33,6 @@ 
 		pinctrl-names = "default";
 		pinctrl-0 = <&lcd_enable_h>;
 		regulator-name = "panel_regulator";
-		startup-delay-us = <100000>;
 		vin-supply = <&vcc33_sys>;
 	};
 
diff --git a/arch/arm/boot/dts/rk3288-veyron-speedy.dts b/arch/arm/boot/dts/rk3288-veyron-speedy.dts
index 9b140db04456..a0f6fefc95f1 100644
--- a/arch/arm/boot/dts/rk3288-veyron-speedy.dts
+++ b/arch/arm/boot/dts/rk3288-veyron-speedy.dts
@@ -24,7 +24,6 @@ 
 		pinctrl-names = "default";
 		pinctrl-0 = <&lcd_enable_h>;
 		regulator-name = "panel_regulator";
-		startup-delay-us = <100000>;
 		vin-supply = <&vcc33_sys>;
 	};