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

[Daniel Vetter]

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.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch