From: Doug Anderson <firstname.lastname@example.org> To: Sandeep Panda <email@example.com>, Sean Paul <firstname.lastname@example.org> Cc: linux-arm-msm <email@example.com>, Jeykumar Sankaran <firstname.lastname@example.org>, email@example.com, Andrzej Hajda <firstname.lastname@example.org>, Archit Taneja <email@example.com>, LKML <firstname.lastname@example.org>, dri-devel <email@example.com>, David Airlie <firstname.lastname@example.org>, Laurent Pinchart <Laurent.email@example.com> Subject: Re: [PATCH 2/2] drm/bridge: ti-sn65dsi86: Allow DT to set "HPD delay" Date: Mon, 22 Oct 2018 13:54:26 -0700 [thread overview] Message-ID: <CAD=FV=U6bbVMF3CcDWfdQDOiEQyi1Tk76p2LXN5TE1EDv5Fk6Q@mail.gmail.com> (raw) In-Reply-To: <firstname.lastname@example.org> Hi, On Fri, Oct 19, 2018 at 1:20 PM Douglas Anderson <email@example.com> wrote: > > Let's solve the mystery of commit bf1178c98930 ("drm/bridge: > ti-sn65dsi86: Add mystery delay to enable()"). Specifically the > reason we needed that mystery delay is that we weren't paying > attention to HPD. > > Looking at the datasheet for the same panel that was tested for the > original commit, I see there's a timing "t3" that times from power on > to the aux channel being operational. This time is specced as 0 - 200 > ms. The datasheet says that the aux channel is operational at exactly > the same time that HPD is asserted. > > Scoping the signals on this board showed that HPD was asserted 84 ms > after power was asserted. That very closely matches the magic 70 ms > delay that we had. ...and actually, in my esting the 70 ms wasn't > quite enough of a delay and some percentage of the time the display > didn't come up until I bumped it to 100 ms. > > To solve this, we tried to hook up the HPD signal in the bridge. > ...but in doing so we found that that the bridge didn't report that > HPD was asserted until ~280 ms after we powered it (!). This is > explained by looking at the sn65dsi86 datasheet section "184.108.40.206 HPD > (Hot Plug/Unplug Detection)". Reading there we see that the bridge > isn't even intended to report HPD until 100 ms after it's asserted. > ...but that would have left us at 184 ms. The extra 100 ms > (presumably) comes from this part in the datasheet: > > > The HPD state machine operates off an internal ring oscillator. The > > ring oscillator frequency will vary [ ... ]. The min/max range in > > the HPD State Diagram refers to the possible times based off > > variation in the ring oscillator frequency. > > Given that the 280 ms we'll end up delaying if we hook up HPD is > _slower_ than the 200 ms we could just hardcode, for now we'll solve > the problem by just allowing boards to hardcode a value. If someone > using this part finds that they can get things to work more quickly by > actually hooking up HPD that can always be a future patch. > > One last note is that I tried to solve this through another way: In > ti_sn_bridge_enable() I tried to use various combinations of > dp_dpcd_writeb() and dp_dpcd_readb() to detect when the aux channel > was up. In theory that would let me detect _exactly_ when I could > continue and do link training. Unfortunately even if I did an aux > transfer w/out waiting I couldn't see any errors. Possibly I could > keep looping over link training until it came back with success, but > that seemed a little overly hacky to me. > > Signed-off-by: Douglas Anderson <firstname.lastname@example.org> > --- > > drivers/gpu/drm/bridge/ti-sn65dsi86.c | 45 ++++++++++++++++++++++----- > 1 file changed, 37 insertions(+), 8 deletions(-) Adding breadcrumbs to point to the new version of this patch at <https://lore.kernel.org/patchwork/patch/1002549/> AKA ("[4/6] drm/bridge: ti-sn65dsi86: Remove the mystery delay"). I didn't call that a v2 since it's a pretty different approach compared to this one, but (assuming people are OK w/ it) it replaces this patch. Thanks! -Doug
next prev parent reply other threads:[~2018-10-22 20:54 UTC|newest] Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top 2018-10-19 20:19 [PATCH 1/2] dt-bindings: drm/bridge: sn65dsi86: Add panel-hpd-delay Douglas Anderson 2018-10-19 20:19 ` [PATCH 2/2] drm/bridge: ti-sn65dsi86: Allow DT to set "HPD delay" Douglas Anderson 2018-10-22 20:54 ` Doug Anderson [this message] 2018-10-24 18:32 ` spanda 2018-10-24 18:37 ` Doug Anderson 2018-10-21 9:06 ` [PATCH 1/2] dt-bindings: drm/bridge: sn65dsi86: Add panel-hpd-delay Laurent Pinchart 2018-10-22 20:52 ` Doug Anderson
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to='CAD=FV=U6bbVMF3CcDWfdQDOiEQyi1Tk76p2LXN5TE1EDv5Fk6Q@mail.gmail.com' \ --email@example.com \ --cc=Laurent.firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --subject='Re: [PATCH 2/2] drm/bridge: ti-sn65dsi86: Allow DT to set "HPD delay"' \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).