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@xxxxxxxxxxxx> > Reviewed-by: Sean Paul <sean@xxxxxxxxxx> Reviewed-by: Andrzej Hajda <a.hajda@xxxxxxxxxxx> -- Regards Andrzej _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel