stable.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
To: Greg KH <gregkh@linuxfoundation.org>
Cc: Jani Nikula <jani.nikula@linux.intel.com>,
	intel-gfx@lists.freedesktop.org, stable@vger.kernel.org
Subject: Re: [Intel-gfx] [PATCH 4.1,	4.2] drm/i915: Silence DDR DVFS errors on CHV
Date: Mon, 19 Oct 2015 19:40:02 +0300	[thread overview]
Message-ID: <20151019164002.GC26517@intel.com> (raw)
In-Reply-To: <20151019151305.GD20364@kroah.com>

On Mon, Oct 19, 2015 at 08:13:05AM -0700, Greg KH wrote:
> On Mon, Oct 19, 2015 at 11:02:35AM +0300, Jani Nikula wrote:
> > On Sat, 17 Oct 2015, Greg KH <gregkh@linuxfoundation.org> wrote:
> > > On Mon, Sep 28, 2015 at 10:09:11PM +0300, ville.syrjala@linux.intel.com wrote:
> > >> From: Ville Syrj�l� <ville.syrjala@linux.intel.com>
> > >> 
> > >> commit 58590c14d80defc94e900308a9d8fa55284de6f2 upstream.
> > >
> > > This is not the commit id of the patch below at all, I can't take this,
> > > please be more careful in the future.
> > 
> > Greg, the commit message tries (and apparently fails) to explain that we
> > can't really backport all of the commits to fix this properly.
> 
> Yeah, it failed at that, as this isn't the same patch, so please don't
> say that in the first line :(

I remember I had trouble figuring out what exactly I should put in the
commit message. The documentation said I should specify the upsteam
commit, and so that's what I did in the end. There wasn't really much
extra guidance for cases where you can't simply cherry-pick the upstream
commit as is.

> > The referenced upstream commit looks totally different because it
> > prevents us from entering the failing path to begin with. Since we can't
> > do that in stable, Ville was proposing to just the tune down the error
> > message, referencing the commit that gets rid of the error message
> > upstream.
> 
> Why can't we do that in the stable tree?

First we'd probably get to backport most of whatever atomic modeset
work that landed in the meantime (and somehow massage that into a shape
that doesn't break everything), then we'd get to backport at least one
total rewrite of the VLV/CHV watermark code, and finally we might be
able to cherry-pick the patch as is.

So that's a non-trivial amount of work, and the risk of breaking everything
modeset related is very real. Definitely not something I want to put
into stable.

> I _REALLY_ do not like taking
> patches that are different from what is in Linus's tree.  It always
> burns us in the end, no matter how hard we try to prevent it...
> 
> thanks,
> 
> greg k-h

-- 
Ville Syrj�l�
Intel OTC

      parent reply	other threads:[~2015-10-19 16:40 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-09-28 19:09 [PATCH 4.1,4.2] drm/i915: Silence DDR DVFS errors on CHV ville.syrjala
2015-10-17 20:30 ` Greg KH
2015-10-19  8:02   ` [Intel-gfx] [PATCH 4.1, 4.2] " Jani Nikula
2015-10-19 15:13     ` Greg KH
2015-10-19 16:10       ` Daniel Vetter
2015-10-19 16:31         ` Greg KH
2015-10-19 16:40       ` Ville Syrjälä [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20151019164002.GC26517@intel.com \
    --to=ville.syrjala@linux.intel.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=jani.nikula@linux.intel.com \
    --cc=stable@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).