[lkml]   [2012]   [Jan]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [Intel-gfx] [PATCH 1/2] drm/i915: Force explicit bpp selection for intel_dp_link_required
On Wed, 25 Jan 2012 22:50:55 +0100, Daniel Vetter <> 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.

[unhandled content-type:application/pgp-signature]
 \ /
  Last update: 2012-01-25 23:49    [W:0.037 / U:0.360 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site