On Wed, 25 Jan 2012 22:50:55 +0100, Daniel Vetter <daniel at 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. -- keith.packard at intel.com -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 827 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/intel-gfx/attachments/20120125/743e859b/attachment.pgp>
