[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CAD=FV=XCOPeEgpjvCuDjT=OjEk1P8vszL6iJqkY-DcpXtpXTjA@mail.gmail.com>
Date: Thu, 28 Aug 2025 15:52:32 -0700
From: Doug Anderson <dianders@...omium.org>
To: Michael Walle <mwalle@...nel.org>
Cc: Andrzej Hajda <andrzej.hajda@...el.com>, Neil Armstrong <neil.armstrong@...aro.org>,
Robert Foss <rfoss@...nel.org>, Laurent Pinchart <Laurent.pinchart@...asonboard.com>,
Jonas Karlman <jonas@...boo.se>, Jernej Skrabec <jernej.skrabec@...il.com>,
Maarten Lankhorst <maarten.lankhorst@...ux.intel.com>, Maxime Ripard <mripard@...nel.org>,
Thomas Zimmermann <tzimmermann@...e.de>, David Airlie <airlied@...il.com>, Simona Vetter <simona@...ll.ch>,
dri-devel@...ts.freedesktop.org, linux-kernel@...r.kernel.org,
Devarsh Thakkar <devarsht@...com>
Subject: Re: [PATCH v2] drm/bridge: ti-sn65dsi86: fix REFCLK setting
Hi,
On Thu, Aug 21, 2025 at 7:36 AM Doug Anderson <dianders@...omium.org> wrote:
>
> Hi,
>
> On Thu, Aug 21, 2025 at 5:23 AM Michael Walle <mwalle@...nel.org> wrote:
> >
> > The bridge has three bootstrap pins which are sampled to determine the
> > frequency of the external reference clock. The driver will also
> > (over)write that setting. But it seems this is racy after the bridge is
> > enabled. It was observed that although the driver write the correct
> > value (by sniffing on the I2C bus), the register has the wrong value.
> > The datasheet states that the GPIO lines have to be stable for at least
> > 5us after asserting the EN signal. Thus, there seems to be some logic
> > which samples the GPIO lines and this logic appears to overwrite the
> > register value which was set by the driver. Waiting 20us after
> > asserting the EN line resolves this issue.
> >
> > Signed-off-by: Michael Walle <mwalle@...nel.org>
> > Reviewed-by: Douglas Anderson <dianders@...omium.org>
>
> nit: officially you're supposed to move your Signed-off-by all the way
> at the bottom of all the other tags any time you post a patch. I don't
> think it's important enough to re-send, though.
>
> In any case, thanks for re-posting. I guess it kinda stagnated. I'll
> give this another week on the list and then plan to apply to
> drm-misc-fixes unless there are any other comments.
I realized that this is lacking a Fixes: tag. I went back and
confirmed that even in the first version of the driver, AKA commit
a095f15c00e2 ("drm/bridge: add support for sn65dsi86 bridge driver"),
we still had no delay between these two lines:
pm_runtime_get_sync(pdata->dev);
/* configure bridge ref_clk */
ti_sn_bridge_set_refclk_freq(pdata);
...and the last line of the runtime resume function was turning on the
enable. So I believe this means that the bug has always been there.
Does that sound right to others? If so, I'll add that Fixes tag when
applying.,..
-Doug
Powered by blists - more mailing lists