Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
MIME-Version: 1.0
References: <20220417181538.57fa1303@blackhole> <CA+E=qVeX2aU0hiDMxLXzVk-YiMsqKKFKpm=cc=72joMhZmNV1g@mail.gmail.com>
In-Reply-To: <CA+E=qVeX2aU0hiDMxLXzVk-YiMsqKKFKpm=cc=72joMhZmNV1g@mail.gmail.com>
From:   Vasily Khoruzhick <anarsoul@gmail.com>
Date:   Mon, 18 Apr 2022 17:25:57 -0700
Message-ID: <CA+E=qVdEtx8wVbcrMQYGB1ur1ykvNRp1L174mVSMkB0zeOPYNQ@mail.gmail.com>
Subject: Re: [PATCH] drm/bridge: fix anx6345 power up sequence
To:     Torsten Duwe <duwe@lst.de>
Cc:     Neil Armstrong <narmstrong@baylibre.com>,
        Robert Foss <robert.foss@linaro.org>,
        Laurent Pinchart <Laurent.pinchart@ideasonboard.com>,
        Jonas Karlman <jonas@kwiboo.se>,
        Jernej Skrabec <jernej.skrabec@gmail.com>,
        David Airlie <airlied@linux.ie>,
        Daniel Vetter <daniel@ffwll.ch>,
        Thierry Reding <treding@nvidia.com>,
        Lyude Paul <lyude@redhat.com>,
        dri-devel <dri-devel@lists.freedesktop.org>,
        linux-kernel <linux-kernel@vger.kernel.org>,
        Harald Geyer <harald@ccbib.org>, stable@vger.kernel.org
Content-Type: text/plain; charset="UTF-8"
Precedence: bulk

On Sun, Apr 17, 2022 at 11:52 AM Vasily Khoruzhick <anarsoul@gmail.com> wrote:
>
> On Sun, Apr 17, 2022 at 9:15 AM Torsten Duwe <duwe@lst.de> wrote:
> >
> > Align the power-up sequence with the known-good procedure documented in [1]:
> > un-swap dvdd12 and dvdd25, and allow a little extra time for them to settle
> > before de-asserting reset.
>
> Hi Torsten,
>
> Interesting find! I tried to fix the issue several times by playing
> with the delays to no avail.
>
> What's interesting, ANX6345 datasheet allows DVDD12 to come up either
> earlier or later than DVDD25 with the delay of T1 (2ms typical)
> between them, and actually bringing up DVDD12 first works fine in
> u-boot.
>
> The datasheet also requires reset to be deasserted no earlier than T2
> (2-5ms) after all the rails are stable.
>
> Another thing it mentions is that the system clock must be stable for
> T3 (1-3ms) before reset is deasserted, T3 is already a part of T2,
> however it cannot be gated on Pinebook, see [1], page 15
>
> The change looks good to me, but I'll need some time to actually test
> it. If you don't hear from me for longer than a week please ping me.

Your change doesn't fix the issue for me. Running "xrandr --output
eDP-1 --off; xrandr --output eDP-1 --auto" in a loop triggers the
issue pretty quickly even with the patch.