[Intel-gfx] [PATCH 1/2] drm/i915: Fix scaler init during CRTC HW state readout

[Imre Deak]

On Thu, Jul 20, 2017 at 11:41:35AM +0200, Greg Kroah-Hartman wrote:
> On Thu, Jul 20, 2017 at 12:25:30PM +0300, Imre Deak wrote:
> > On Thu, Jul 20, 2017 at 11:58:35AM +0300, Jani Nikula wrote:
> > > On Thu, 20 Jul 2017, Imre Deak <imre.deak at intel.com> wrote:
> > > > The scaler allocation code depends on a non-zero default value for the
> > > > crtc scaler_id, so make sure we initialize the scaler state accordingly
> > > > even if the crtc is off. This fixes at least an initial YUV420 modeset
> > > > (added in a follow-up patchset by Shashank) when booting with the screen
> > > > off: after the initial HW readout and modeset which enables the scaler a
> > > > subsequent modeset will disable the scaler which isn't properly
> > > > allocated. This results in a funky HW state where the pipe scaler HW
> > > > registers can't be modified and the normally black screen is grey and
> > > > shifted to the right or jitters.
> > > >
> > > > The problem was revealed by Shashank's YUV420 patchset and first
> > > > reported by Ville.
> > > >
> > > > Cc: Shashank Sharma <shashank.sharma at intel.com>
> > > > Cc: Ville Syrjälä <ville.syrjala at linux.intel.com>
> > > > Cc: Chandra Konduru <chandra.konduru at intel.com>
> > > > Cc: Matt Roper <matthew.d.roper at intel.com>
> > > > Cc: <stable at vger.kernel.org> # 4.11.x
> > > > Reported-by: Ville Syrjälä <ville.syrjala at linux.intel.com>
> > > > Fixes: a1b2278e4dfc ("drm/i915: skylake panel fitting using shared scalers")
> > > > Signed-off-by: Imre Deak <imre.deak at intel.com>
> > > >
> > > > ---
> > > >
> > > > [ Older stable versions need backporting, so that's for a follow-up ]
> > > 
> > > I thought we'd annotate cc: stable with all the kernels that need the
> > > fix, not according to where the fix applies as-is. In this case, it
> > > would be v4.2+, right?
> > 
> > Hm, not sure. I know that this won't apply before 4.11 and I will have
> > to send a backported version anyway. So wanted to save a redundant turn
> > around after the automatic cherry picking to those stable versions
> > fail.
> > 
> > Greg, what's the proper tag in this case?
> 
> 4.2+ and then when you get the "this didn't apply" email, send the
> backported patches.  That way the stable maintainers know it "should" be
> applied there, but it just doesn't seem to work with the existing patch.

Ok, will resend with that, thanks for catching this and clarifying.

--Imre