Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
MIME-Version: 1.0
References: <20181019201940.138179-1-dianders@chromium.org>
 <20181019201940.138179-2-dianders@chromium.org> <9d5b42b94772fb3adb86e20eff72cd88@codeaurora.org>
In-Reply-To: <9d5b42b94772fb3adb86e20eff72cd88@codeaurora.org>
From:   Doug Anderson <dianders@chromium.org>
Date:   Wed, 24 Oct 2018 11:37:13 -0700
Message-ID: <CAD=FV=UJYu6uBcbHVOa=fhMbiCzTwpxB6GZY9A2fgEWPinycwA@mail.gmail.com>
Subject: Re: [PATCH 2/2] drm/bridge: ti-sn65dsi86: Allow DT to set "HPD delay"
To:     Sandeep Panda <spanda@codeaurora.org>
Cc:     Sean Paul <seanpaul@chromium.org>,
        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>
Content-Type: text/plain; charset="UTF-8"
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

Hi,

On Wed, Oct 24, 2018 at 11:32 AM <spanda@codeaurora.org> wrote:
>
> On 2018-10-20 01:49, 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 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.
> >
>
> Thanks for very detailed explanation.

Note: I already replied to myself and left breadcrumbs, but please
assume that ${SUBJECT} patch is abandoned and see my new series that
moves this delay into the panel.

-Doug