From: Doug Anderson <dianders@chromium.org>
To: Sandeep Panda <spanda@codeaurora.org>, Sean Paul <seanpaul@chromium.org>
Cc: linux-arm-msm <linux-arm-msm@vger.kernel.org>,
Jeykumar Sankaran <jsanka@codeaurora.org>,
ryandcase@chromium.org, Andrzej Hajda <a.hajda@samsung.com>,
Archit Taneja <architt@codeaurora.org>,
LKML <linux-kernel@vger.kernel.org>,
dri-devel <dri-devel@lists.freedesktop.org>,
David Airlie <airlied@linux.ie>,
Laurent Pinchart <Laurent.pinchart@ideasonboard.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: <20181019201940.138179-2-dianders@chromium.org>
Hi,
On Fri, Oct 19, 2018 at 1:20 PM Douglas Anderson <dianders@chromium.org> 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 "8.4.5.1 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 <dianders@chromium.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' \
--to=dianders@chromium.org \
--cc=Laurent.pinchart@ideasonboard.com \
--cc=a.hajda@samsung.com \
--cc=airlied@linux.ie \
--cc=architt@codeaurora.org \
--cc=dri-devel@lists.freedesktop.org \
--cc=jsanka@codeaurora.org \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=ryandcase@chromium.org \
--cc=seanpaul@chromium.org \
--cc=spanda@codeaurora.org \
/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
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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).