On Wed, 25 Jan 2012 08:16:25 -0800 Keith Packard <keithp at keithp.com> wrote: > It is never correct to use intel_crtc->bpp in intel_dp_link_required, > so instead pass an explicit bpp in to this function. This patch > only supports 18bpp and 24bpp modes, which means that 10bpc modes will > be computed incorrectly. Fixing that will require more extensive > changes, and so must be addressed separately from this bugfix. > > intel_dp_link_required is called from intel_dp_mode_valid and > intel_dp_mode_fixup. > > * intel_dp_mode_valid is called to list supported modes; in this case, > the current crtc values cannot be relevant as the modes in question > may never be selected. Thus, using intel_crtc->bpp is never right. > > * intel_dp_mode_fixup is called during mode setting, but it is run > well before ironlake_crtc_mode_set is called to set intel_crtc->bpp, > so using intel_crtc-bpp in this path can only ever get a stale > value. Yeah, looks like I got this wrong when I added the pipe bpp field. Wonder if there's a good way to catch this sort of bug with an assert so we don't get the order mixed up again... The big downside here is that we'll be very pessimistic about the link bw requirements for say 16 or 8bpp modes. I see you have another patch to address some of this, but I wonder if we have enough info to calculate the bpp at prepare time so it's set early on for use by both the crtc and encoder code? -- Jesse Barnes, Intel Open Source Technology Center -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/intel-gfx/attachments/20120125/15a3d7cb/attachment.pgp>
