On Wed, 25 Jan 2012 22:50:55 +0100, Daniel Vetter daniel@ffwll.ch wrote:
I think we could compute this in crtc->mode_fixup (crtc->prepare doesn't have the mode and adjusted_mode arguments). We could then store the computed bpc and dithering in one of the private fields. We'd still have to loop over all encoders, but alas ...
Alas, intel_crtc_mode_fixup is called *after* the intel_dp_mode_fixup. So, we'd either need to change drm_crtc_helper, or have intel_crtc_mode_fixup call down into intel_dp.c to set the link parameters. In either case, ick.
Afaics we'll still correctly fall back to 6bpc (undithered for 16bpp obviously) and hence things should keep on working.
Right, the problem is that the DP link parameters will be set to support 24bpp color, so we'll use a higher clock/lane-count than strictly necessary as intel_dp_mode_fixup doesn't take the frame buffer format into consideration when computing the link values.
Yeah, there are a few rough corners with the bpc computation in patch 2. I'll try to throw around a few ideas that crossed my mind while reading through it in a reply there.
Thanks. I'm not happy with it either.
In short, I think we can (and should) apply the simple first patch to drm-intel-fixes so that at least displays work consistently, and then come up with a nicer patch that computes correct link parameters, and also supports 10bpc formats.