Messages in this thread | | | From | Keith Packard <> | Subject | Re: [Intel-gfx] [PATCH 1/2] drm/i915: Force explicit bpp selection for intel_dp_link_required | Date | Wed, 25 Jan 2012 14:45:44 -0800 |
| |
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.
-- keith.packard@intel.com [unhandled content-type:application/pgp-signature] | |