APPLIED[U]: [PATCH V2 2/2][SRU][U/I/OEM-5.13/OEM-5.14] UBUNTU: SAUCE: drm/i915: Stop force enabling pipe bottom color gammma/csc

[Andrea Righi]

On Mon, Oct 04, 2021 at 01:48:39PM +0800, Koba Ko wrote:
> From: Ville Syrjälä <ville.syrjala at linux.intel.com>
> 
> BugLink: https://bugs.launchpad.net/bugs/1945932
> 
> While sanitizing the hardware state we're currently forcing
> the pipe bottom color legacy csc/gamma bits on. That is not a
> good idea as BIOSen are likely to leave gabage in the LUTs and
> so doing this causes ugly visual glitches if and when the
> planes covering the background get disabled. This was exactly
> the case on this Dell Precision 5560 tgl laptop.
> 
> On icl+ we don't normally even use these legacy bits
> anymore and instead use their GAMMA_MODE counterparts.
> On earlier platforms the bits are used, but we still
> shouldn't force them on without knowing what's in the LUT.
> 
> So two options, get rid of the whole thing, or do what
> intel_color_commit() does to make sure the bottom color state
> matches whatever out hardware readout produced. I chose the
> latter since it'll match what happens on older platforms when
> the primary plane gets turned off. In fact let's just call
> intel_color_commit(). It'll also do some CSC programming but
> since we don't have readout for that it'll actually just set
> to all zeros. So in the unlikely case of CSC actually being
> enabld by the BIOS we'll end up with all black until the first
> atomic commit happens.
> 
> Still not totally sure what we should do about color management
> features here in general. Probably the safest  thing would be to
> force everything off exactly at the same time when we disable
> the primary plane as there is no guarantees that whatever the
> LUTs/CSCs contain make any sense whatsoever without the
> specific pixel data in the BIOS fb. And if we preserve the
> primary plane then we should disable the color management
> features exactly when the primary plane fb contents first
> changes since the new content assumes more or less no
> transformations. But of course synchronizing front buffer
> rendering with anything else is a bit hard...
> 
> Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/3534
> Signed-off-by: Ville Syrjälä <ville.syrjala at linux.intel.com>
> Ref: https://patchwork.freedesktop.org/series/95171/
> Signed-off-by: Koba Ko <koba.ko at canonical.com>

Applied to unstable with adjustments:
 - drop SAUCE
 - replace backport s-o-b with the linux-next sha1

Thanks,
-Andrea