[Intel-gfx] [PATCH 10/12] drm/i915: Update link training automated test function for Displayport compliance

Jesse Barnes jbarnes at virtuousgeek.org
Tue Jul 22 23:03:20 CEST 2014


On Tue, 22 Jul 2014 22:44:54 +0200
Daniel Vetter <daniel at ffwll.ch> wrote:

> On Tue, Jul 22, 2014 at 10:40 PM, Jesse Barnes <jbarnes at virtuousgeek.org> wrote:
> >> > +   /* Set link rate directly */
> >> > +   intel_dp->link_bw = rxdata[0];
> >> > +   /* Preserve 7:5 when setting lane count */
> >> > +   intel_dp->lane_count &= 0xE0;
> >> > +   intel_dp->lane_count |= rxdata[1];
> >>
> >> This won't work - if you change the link config you need to do a full
> >> recomputation of the modeset config and a full modeset. No, we dont (yet)
> >> have the infrastructure for this, which is why dp is such a pain since we
> >> can change the link config once we've decided on something :(
> >
> > I think that depends on how we're going to structure the code.  For
> > simply calling the link train functions, it looks like messing with the
> > intel_dp->foo fields will roughly do what Todd wants, which is to
> > simply try a re-train with a different set of params, ignoring the
> > actual fb and pipe configuration.
> >
> > Or is that what you had in mind?  You'd like to see valid data and mode
> > timings to drive a given lane count and bw instead?  I'm not sure the
> > testing spec cares about that; Todd?
> 
> If you change the link_bw then you need to do a full modeset sequence
> since that's the only way to convince our hw to switch to the new
> clock. The current code in this patch falls short and only retrains
> the link.
> 
> But even if we'd do the full modeset the compute_config stage would
> overwrite the link parameters again. So the correct way to do this is
> to pimp the compute config code to have limits (we might as well
> expose them as connector properties while at it for debugging) and
> then do a full modeset sequence here. Then we could finally implement
> (with a bit more code) the transparent fallback to a different config
> if the first one doesn't work.

Right, yeah going through the full sequence sounds like it's required
for most of the tests based on what Todd tells me, since the test sink
will look at the active mode transmitted etc.

So the simple re-train and send misc isn't sufficient, even if the
training succeeds.

-- 
Jesse Barnes, Intel Open Source Technology Center



More information about the Intel-gfx mailing list