[Intel-gfx] [PATCH AUTOSEL for 4.9 36/56] drm/i915: Fix the level 0 max_wm hack on VLV/CHV

Greg KH gregkh at linuxfoundation.org
Fri Nov 17 12:41:23 UTC 2017


On Fri, Nov 17, 2017 at 01:28:05PM +0200, Jani Nikula wrote:
> 
> Cc: Greg
> 
> On Wed, 15 Nov 2017, Ville Syrjälä <ville.syrjala at linux.intel.com> wrote:
> > On Wed, Nov 15, 2017 at 04:44:54PM +0000, alexander.levin at verizon.com wrote:
> >> On Wed, Nov 15, 2017 at 01:08:05PM +0200, Ville Syrjälä wrote:
> >> >On Wed, Nov 15, 2017 at 02:45:43AM +0000, alexander.levin at verizon.com wrote:
> >> >> From: Ville Syrjälä <ville.syrjala at linux.intel.com>
> >> >>
> >> >> [ Upstream commit 1be4d3793d5a93daddcd9be657c429b38ad750a3 ]
> >> >>
> >> >> The watermark should never exceed the FIFO size, so we need to
> >> >> check against the current FIFO size instead of the theoretical
> >> >> maximum when we clamp the level 0 watermark.
> >> >>
> >> >> Signed-off-by: Ville Syrjälä <ville.syrjala at linux.intel.com>
> >> >> Link: https://urldefense.proofpoint.com/v2/url?u=http-3A__patchwork.freedesktop.org_patch_msgid_1480354637-2D14209-2D4-2Dgit-2Dsend-2Demail-2Dville.syrjala-40linux.intel.com&d=DwIDAw&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=bUtaaC9mlBij4OjEG_D-KPul_335azYzfC4Rjgomobo&m=iuPtUar-VEGbH1jmVH_UTr4C02X8fmjHUfNYix-Yc0Y&s=ha_F0zP3A1Aztp5S5e6_bqdhiuuPXhn0dRWQ58vv3Is&e=
> >> >> Reviewed-by: Maarten Lankhorst <maarten.lankhorst at linux.intel.com>
> >> >> Signed-off-by: Sasha Levin <alexander.levin at verizon.com>
> >> >
> >> >Why are these patches being proposed for stable? They're not straight up
> >> >fixes for known issues, and there's always a chance that something will
> >> >break. Who is doing the qa on this?
> >> 
> >> Hi Ville,
> >> 
> >> They were selected automatically as part of a new process we're trying
> >> out. If you disagree with the selection I'd be happy to drop it.
> >
> > How does that automatic process decide that a patch should be backported?
> >
> > drm and i915 are very fast moving targets so unintended side effects from
> > backported patches is a real possibility. So I would recommend against
> > backporting anything that isn't fixing a real issue affecting users. We
> > do try to add the cc:stable to such patches.
> 
> Agreed.
> 
> First, I think an automatic backport process is against the stable
> kernel rules (e.g. "It must fix a real bug that bothers people").

It's finding lots of fixes that did bother people enough to submit a fix
for.

> Second, we can't and won't take any responsibility for backports we
> didn't indicate with Cc: stable, a Fixes: tag, or a specific backport
> request.

Ok, you all are already totally messing with my normal stable workflow,
so might as well just trust you all completely.  So let's just only take
patches that you all do send me in the normal way.  It's easy for Sasha
to filter out the drm/i915 patches from his results.

Is that ok?

> If you think there's a commit that should be backported and is known to
> fix a user visible issue (as per the stable rules!), please check with
> us first.

Um, that is what he was doing with the cc: of you all on the patch
itself that started this whole conversation...

{sigh}

greg k-h


More information about the Intel-gfx mailing list