[PATCH v3 7/7] drm/bridge: ti-sn65dsi86: Add mystery delay to enable()

[Sean Paul]

On Sun, Aug 26, 2018, 1:44 AM <spanda at codeaurora.org> wrote:

> On 2018-08-23 19:55, Sean Paul wrote:
> > On Tue, Aug 14, 2018 at 10:01:45AM -0400, Sean Paul wrote:
> >> On Tue, Aug 14, 2018 at 10:00:33AM -0400, Sean Paul wrote:
> >> > On Tue, Aug 14, 2018 at 04:59:31PM +0530, spanda at codeaurora.org
> wrote:
> >> > > On 2018-08-14 03:00, Sean Paul wrote:
> >> > > > From: Sean Paul <seanpaul at chromium.org>
> >> > > >
> >> > > > This patch adds a 70ms mystery delay to the bridge driver in
> enable.
> >> > > > By experimentation, it seems like it can go anywhere up until we
> >> > > > initiate semi-auto link training. If we don't have the delay, link
> >> > > > training fails.
> >> > > >
> >> > > > I tried to root cause this as best I could, but neither the
> datasheet
> >> > > > for the panel nor the bridge mention a delay of this magnitude in
> their
> >> > > > timing requirements. So for now, add the mystery delay until
> someone
> >> > > > figures out a better fix.
> >> > > >
> >> > > > Changes in v3:
> >> > > > - Added to the set
> >> > > >
> >> > > > Cc: Sandeep Panda <spanda at codeaurora.org>
> >> > > > Signed-off-by: Sean Paul <seanpaul at chromium.org>
> >> > > > ---
> >> > > >  drivers/gpu/drm/bridge/ti-sn65dsi86.c | 12 ++++++++++++
> >> > > >  1 file changed, 12 insertions(+)
> >> > > >
> >> > > > diff --git a/drivers/gpu/drm/bridge/ti-sn65dsi86.c
> >> > > > b/drivers/gpu/drm/bridge/ti-sn65dsi86.c
> >> > > > index d3e27e52ea759..f8a931cf3665e 100644
> >> > > > --- a/drivers/gpu/drm/bridge/ti-sn65dsi86.c
> >> > > > +++ b/drivers/gpu/drm/bridge/ti-sn65dsi86.c
> >> > > > @@ -458,6 +458,18 @@ static void ti_sn_bridge_enable(struct
> drm_bridge
> >> > > > *bridge)
> >> > > >        unsigned int val;
> >> > > >        int ret;
> >> > > >
> >> > > > +      /*
> >> > > > +       * FIXME:
> >> > > > +       * This 70ms was found necessary by experimentation. If
> it's not
> >> > > > +       * present, link training fails. It seems like it can go
> anywhere from
> >> > > > +       * pre_enable() up to semi-auto link training initiation
> below.
> >> > > > +       *
> >> > > > +       * Neither the datasheet for the bridge nor the panel
> tested mention a
> >> > > > +       * delay of this magnitude in the timing requirements. So
> for now, add
> >> > > > +       * the mystery delay until someone figures out a better
> fix.
> >> > > > +       */
> >> > >
> >> > > Is this newly found issue? Specific to any board config?
> >> >
> >> > It's specific to cheza.
> >>
> >> Well, I suppose I shouldn't say that since I've not tried the bridge
> >> on another
> >> board. I should say, it reproduces on cheza.
> >
> > Ping. Sandeep: any more feedback?
> >
> > Sean
> >
> >>
> >> Sean
> >>
> >> > This was found with swboyd changed the panel regulator
> >> > from always-on/boot-on to toggle.
> >> >
> >> > I've pushed the tag "mtp-testing-0813" to dpu-staging so you can play
> around
> >> > with it. Without this delay, link training fails.
> >> >
> >> > Sean
> >> >
> >> > >
> >> > > > +      msleep(70);
> >> > > > +
> >> > > >        /* DSI_A lane config */
> >> > > >        val = CHA_DSI_LANES(4 - pdata->dsi->lanes);
> >> > > >        regmap_update_bits(pdata->regmap, SN_DSI_LANES_REG,
> >> >
> >> > --
> >> > Sean Paul, Software Engineer, Google / Chromium OS
> >>
> >> --
> >> Sean Paul, Software Engineer, Google / Chromium OS
>
> No more comments from my side.
>

So, should I find another reviewer?

Sean


> Sandeep
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20180826/2ab7ffd0/attachment.html>