linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Andrzej Hajda <a.hajda@samsung.com>
To: Douglas Anderson <dianders@chromium.org>,
	Sean Paul <seanpaul@chromium.org>,
	Thierry Reding <thierry.reding@gmail.com>,
	Sandeep Panda <spanda@codeaurora.org>
Cc: linux-arm-msm@vger.kernel.org,
	Laurent Pinchart <laurent.pinchart@ideasonboard.com>,
	jsanka@codeaurora.org, ryandcase@chromium.org,
	Archit Taneja <architt@codeaurora.org>,
	linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org,
	David Airlie <airlied@linux.ie>
Subject: Re: [PATCH v2 4/6] drm/bridge: ti-sn65dsi86: Remove the mystery delay
Date: Mon, 29 Oct 2018 10:03:24 +0100	[thread overview]
Message-ID: <f3f86ecf-0d97-1b6b-e638-1780fef929f4@samsung.com> (raw)
In-Reply-To: <20181025222134.174583-4-dianders@chromium.org>

On 26.10.2018 00:21, Douglas Anderson 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 testing 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 (presumably 84 ms would
> have worked too).
>
> 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 hardcoding a 200 ms delay in the panel driver
> using the patch in this series ("drm/panel: simple: Support panels
> with HPD where HPD isn't connected").
>
> If we later find a panel that needs to use this bridge where we need
> HPD then we'll have to come up with some new code to handle it.  Given
> the silly debouncing in the bridge chip, though, it seems unlikely.
>
> 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>
> Reviewed-by: Sean Paul <sean@poorly.run>
Reviewed-by: Andrzej Hajda <a.hajda@samsung.com>

 --
Regards
Andrzej

  reply	other threads:[~2018-10-29  9:03 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-10-25 22:21 [PATCH v2 1/6] dt-bindings: drm/panel: simple: Add no-hpd property Douglas Anderson
2018-10-25 22:21 ` [PATCH v2 2/6] drm/panel: simple: Support panels with HPD where HPD isn't connected Douglas Anderson
2018-10-26 14:41   ` Sean Paul
2018-10-25 22:21 ` [PATCH v2 3/6] drm/panel: simple: Add "no-hpd" delay for Innolux TV123WAM Douglas Anderson
2018-10-26 14:41   ` Sean Paul
2018-10-25 22:21 ` [PATCH v2 4/6] drm/bridge: ti-sn65dsi86: Remove the mystery delay Douglas Anderson
2018-10-29  9:03   ` Andrzej Hajda [this message]
2018-10-25 22:21 ` [PATCH v2 5/6] dt-bindings: drm/panel: simple: Innolux TV123WAM is actually P120ZDG-BF1 Douglas Anderson
2018-10-26 14:43   ` Sean Paul
2018-10-26 14:46     ` Sean Paul
2018-10-26 15:01       ` Doug Anderson
2018-10-29  9:10   ` Andrzej Hajda
2018-10-25 22:21 ` [PATCH v2 6/6] " Douglas Anderson
2018-10-26 14:44   ` Sean Paul
2018-10-29 16:16 ` [PATCH v2 1/6] dt-bindings: drm/panel: simple: Add no-hpd property Sean Paul

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=f3f86ecf-0d97-1b6b-e638-1780fef929f4@samsung.com \
    --to=a.hajda@samsung.com \
    --cc=airlied@linux.ie \
    --cc=architt@codeaurora.org \
    --cc=dianders@chromium.org \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=jsanka@codeaurora.org \
    --cc=laurent.pinchart@ideasonboard.com \
    --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 \
    --cc=thierry.reding@gmail.com \
    --subject='Re: [PATCH v2 4/6] drm/bridge: ti-sn65dsi86: Remove the mystery 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).