linux-kernel - Re: [Intel-gfx] [PATCH 1/2] drm/i915: Force explicit bpp selection for intel_dp_link

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20120125125116.5cea2c4b@jbarnes-desktop>
Date:	Wed, 25 Jan 2012 12:51:16 -0800
From:	Jesse Barnes <jbarnes@...tuousgeek.org>
To:	Keith Packard <keithp@...thp.com>
Cc:	intel-gfx@...ts.freedesktop.org, linux-kernel@...r.kernel.org,
	dri-devel@...ts.freedesktop.org,
	Lubos Kolouch <lubos.kolouch@...il.com>
Subject: Re: [Intel-gfx] [PATCH 1/2] drm/i915: Force explicit bpp selection
 for intel_dp_link_required

On Wed, 25 Jan 2012 08:16:25 -0800
Keith Packard <keithp@...thp.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

Download attachment "signature.asc" of type "application/pgp-signature" (837 bytes)