On Tue, Jul 22, 2014 at 10:40 PM, Jesse Barnes <jbarnes@xxxxxxxxxxxxxxxx> 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 _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/intel-gfx
