From: Doug Anderson <dianders@chromium.org>
To: "Heiko Stübner" <heiko@sntech.de>
Cc: Enric Balletbo i Serra <enric.balletbo@collabora.com>,
Matthias Kaehlcke <mka@chromium.org>,
devicetree@vger.kernel.org, LKML <linux-kernel@vger.kernel.org>,
"open list:ARM/Rockchip SoC..."
<linux-rockchip@lists.infradead.org>,
Rob Herring <robh+dt@kernel.org>,
Mark Rutland <mark.rutland@arm.com>,
Linux ARM <linux-arm-kernel@lists.infradead.org>
Subject: Re: [PATCH] Revert "ARM: dts: rockchip: add startup delay to rk3288-veyron panel-regulators"
Date: Tue, 2 Jul 2019 21:54:58 -0700 [thread overview]
Message-ID: <CAD=FV=UhNfhVG422=huthFSptoV4FXED=xPtArO2KkyNb1U3Xw@mail.gmail.com> (raw)
In-Reply-To: <CAD=FV=Wi21Emjg7CpCJfSRiKr_EisR20UO1tbPjAeJzdJNbSVw@mail.gmail.com>
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
next prev parent reply other threads:[~2019-07-03 4:55 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-06-20 18:20 [PATCH] Revert "ARM: dts: rockchip: add startup delay to rk3288-veyron panel-regulators" Douglas Anderson
2019-06-20 20:31 ` Doug Anderson
2019-07-03 4:54 ` Doug Anderson [this message]
2019-07-25 21:33 ` Heiko Stuebner
2019-07-25 23:35 ` Doug Anderson
2019-08-16 11:28 ` Heiko Stuebner
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAD=FV=UhNfhVG422=huthFSptoV4FXED=xPtArO2KkyNb1U3Xw@mail.gmail.com' \
--to=dianders@chromium.org \
--cc=devicetree@vger.kernel.org \
--cc=enric.balletbo@collabora.com \
--cc=heiko@sntech.de \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-rockchip@lists.infradead.org \
--cc=mark.rutland@arm.com \
--cc=mka@chromium.org \
--cc=robh+dt@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).