| Message ID | 20180813213058.184821-8-sean@poorly.run (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | drm/bridge: ti-sn65dsi86: Fix bridge for non always-on regulators | expand |
On 2018-08-14 03:00, Sean Paul wrote: > From: Sean Paul <seanpaul@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@codeaurora.org> > Signed-off-by: Sean Paul <seanpaul@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? > + msleep(70); > + > /* DSI_A lane config */ > val = CHA_DSI_LANES(4 - pdata->dsi->lanes); > regmap_update_bits(pdata->regmap, SN_DSI_LANES_REG,
On Tue, Aug 14, 2018 at 04:59:31PM +0530, spanda@codeaurora.org wrote: > On 2018-08-14 03:00, Sean Paul wrote: > > From: Sean Paul <seanpaul@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@codeaurora.org> > > Signed-off-by: Sean Paul <seanpaul@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. 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,
On Tue, Aug 14, 2018 at 10:00:33AM -0400, Sean Paul wrote: > On Tue, Aug 14, 2018 at 04:59:31PM +0530, spanda@codeaurora.org wrote: > > On 2018-08-14 03:00, Sean Paul wrote: > > > From: Sean Paul <seanpaul@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@codeaurora.org> > > > Signed-off-by: Sean Paul <seanpaul@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. 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
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@codeaurora.org wrote: > > > On 2018-08-14 03:00, Sean Paul wrote: > > > > From: Sean Paul <seanpaul@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@codeaurora.org> > > > > Signed-off-by: Sean Paul <seanpaul@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
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@codeaurora.org wrote: >> > > On 2018-08-14 03:00, Sean Paul wrote: >> > > > From: Sean Paul <seanpaul@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@codeaurora.org> >> > > > Signed-off-by: Sean Paul <seanpaul@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. Sandeep
On Sun, Aug 26, 2018, 1:44 AM <spanda@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@codeaurora.org > wrote: > >> > > On 2018-08-14 03:00, Sean Paul wrote: > >> > > > From: Sean Paul <seanpaul@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@codeaurora.org> > >> > > > Signed-off-by: Sean Paul <seanpaul@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 > <div dir="auto"><div><br><br><div class="gmail_quote"><div dir="ltr">On Sun, Aug 26, 2018, 1:44 AM <<a href="mailto:spanda@codeaurora.org" target="_blank" rel="noreferrer">spanda@codeaurora.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 2018-08-23 19:55, Sean Paul wrote:<br> > On Tue, Aug 14, 2018 at 10:01:45AM -0400, Sean Paul wrote:<br> >> On Tue, Aug 14, 2018 at 10:00:33AM -0400, Sean Paul wrote:<br> >> > On Tue, Aug 14, 2018 at 04:59:31PM +0530, <a href="mailto:spanda@codeaurora.org" rel="noreferrer noreferrer" target="_blank">spanda@codeaurora.org</a> wrote:<br> >> > > On 2018-08-14 03:00, Sean Paul wrote:<br> >> > > > From: Sean Paul <<a href="mailto:seanpaul@chromium.org" rel="noreferrer noreferrer" target="_blank">seanpaul@chromium.org</a>><br> >> > > ><br> >> > > > This patch adds a 70ms mystery delay to the bridge driver in enable.<br> >> > > > By experimentation, it seems like it can go anywhere up until we<br> >> > > > initiate semi-auto link training. If we don't have the delay, link<br> >> > > > training fails.<br> >> > > ><br> >> > > > I tried to root cause this as best I could, but neither the datasheet<br> >> > > > for the panel nor the bridge mention a delay of this magnitude in their<br> >> > > > timing requirements. So for now, add the mystery delay until someone<br> >> > > > figures out a better fix.<br> >> > > ><br> >> > > > Changes in v3:<br> >> > > > - Added to the set<br> >> > > ><br> >> > > > Cc: Sandeep Panda <<a href="mailto:spanda@codeaurora.org" rel="noreferrer noreferrer" target="_blank">spanda@codeaurora.org</a>><br> >> > > > Signed-off-by: Sean Paul <<a href="mailto:seanpaul@chromium.org" rel="noreferrer noreferrer" target="_blank">seanpaul@chromium.org</a>><br> >> > > > ---<br> >> > > > drivers/gpu/drm/bridge/ti-sn65dsi86.c | 12 ++++++++++++<br> >> > > > 1 file changed, 12 insertions(+)<br> >> > > ><br> >> > > > diff --git a/drivers/gpu/drm/bridge/ti-sn65dsi86.c<br> >> > > > b/drivers/gpu/drm/bridge/ti-sn65dsi86.c<br> >> > > > index d3e27e52ea759..f8a931cf3665e 100644<br> >> > > > --- a/drivers/gpu/drm/bridge/ti-sn65dsi86.c<br> >> > > > +++ b/drivers/gpu/drm/bridge/ti-sn65dsi86.c<br> >> > > > @@ -458,6 +458,18 @@ static void ti_sn_bridge_enable(struct drm_bridge<br> >> > > > *bridge)<br> >> > > > unsigned int val;<br> >> > > > int ret;<br> >> > > ><br> >> > > > + /*<br> >> > > > + * FIXME:<br> >> > > > + * This 70ms was found necessary by experimentation. If it's not<br> >> > > > + * present, link training fails. It seems like it can go anywhere from<br> >> > > > + * pre_enable() up to semi-auto link training initiation below.<br> >> > > > + *<br> >> > > > + * Neither the datasheet for the bridge nor the panel tested mention a<br> >> > > > + * delay of this magnitude in the timing requirements. So for now, add<br> >> > > > + * the mystery delay until someone figures out a better fix.<br> >> > > > + */<br> >> > ><br> >> > > Is this newly found issue? Specific to any board config?<br> >> ><br> >> > It's specific to cheza.<br> >> <br> >> Well, I suppose I shouldn't say that since I've not tried the bridge <br> >> on another<br> >> board. I should say, it reproduces on cheza.<br> > <br> > Ping. Sandeep: any more feedback?<br> > <br> > Sean<br> > <br> >> <br> >> Sean<br> >> <br> >> > This was found with swboyd changed the panel regulator<br> >> > from always-on/boot-on to toggle.<br> >> ><br> >> > I've pushed the tag "mtp-testing-0813" to dpu-staging so you can play around<br> >> > with it. Without this delay, link training fails.<br> >> ><br> >> > Sean<br> >> ><br> >> > ><br> >> > > > + msleep(70);<br> >> > > > +<br> >> > > > /* DSI_A lane config */<br> >> > > > val = CHA_DSI_LANES(4 - pdata->dsi->lanes);<br> >> > > > regmap_update_bits(pdata->regmap, SN_DSI_LANES_REG,<br> >> ><br> >> > --<br> >> > Sean Paul, Software Engineer, Google / Chromium OS<br> >> <br> >> --<br> >> Sean Paul, Software Engineer, Google / Chromium OS<br> <br> No more comments from my side.<br></blockquote></div></div><div dir="auto"><br></div><div dir="auto">So, should I find another reviewer? </div><div dir="auto"><br></div><div dir="auto">Sean</div><div dir="auto"><br></div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> <br> Sandeep<br> </blockquote></div></div></div>
On 2018-08-14 03:00, Sean Paul wrote: > From: Sean Paul <seanpaul@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@codeaurora.org> > Signed-off-by: Sean Paul <seanpaul@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. > + */ > + msleep(70); > + > /* DSI_A lane config */ > val = CHA_DSI_LANES(4 - pdata->dsi->lanes); > regmap_update_bits(pdata->regmap, SN_DSI_LANES_REG, Reviewed-by: Sandeep Panda <spanda@codeaurora.org>
On Mon, Aug 27, 2018 at 07:40:05AM +0530, spanda@codeaurora.org wrote: > On 2018-08-14 03:00, Sean Paul wrote: > > From: Sean Paul <seanpaul@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@codeaurora.org> > > Signed-off-by: Sean Paul <seanpaul@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. > > + */ > > + msleep(70); > > + > > /* DSI_A lane config */ > > val = CHA_DSI_LANES(4 - pdata->dsi->lanes); > > regmap_update_bits(pdata->regmap, SN_DSI_LANES_REG, > > Reviewed-by: Sandeep Panda <spanda@codeaurora.org> Pushed to -misc-next, thanks for your reviews. Sean
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. + */ + msleep(70); + /* DSI_A lane config */ val = CHA_DSI_LANES(4 - pdata->dsi->lanes); regmap_update_bits(pdata->regmap, SN_DSI_LANES_REG,