Hi,
On Thu, Aug 21, 2025 at 7:36 AM Doug Anderson <[email protected]> wrote:
>
> Hi,
>
> On Thu, Aug 21, 2025 at 5:23 AM Michael Walle <[email protected]> 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 <[email protected]>
> > Reviewed-by: Douglas Anderson <[email protected]>
>
> 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
