From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ville =?iso-8859-1?Q?Syrj=E4l=E4?= 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 Message-ID: <20151019164002.GC26517@intel.com> References: <1443467351-16199-1-git-send-email-ville.syrjala@linux.intel.com> <20151017203037.GA6884@kroah.com> <878u6z1e1w.fsf@intel.com> <20151019151305.GD20364@kroah.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: QUOTED-PRINTABLE Return-path: Content-Disposition: inline In-Reply-To: <20151019151305.GD20364@kroah.com> Sender: stable-owner@vger.kernel.org To: Greg KH Cc: Jani Nikula , intel-gfx@lists.freedesktop.org, stable@vger.kernel.org List-Id: intel-gfx@lists.freedesktop.org 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 wrote: > > > On Mon, Sep 28, 2015 at 10:09:11PM +0300, ville.syrjala@linux.int= el.com wrote: > > >> From: Ville Syrj=E4l=E4 > > >>=20 > > >> 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. > >=20 > > Greg, the commit message tries (and apparently fails) to explain th= at we > > can't really backport all of the commits to fix this properly. >=20 > 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 upstrea= m 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 er= ror > > message, referencing the commit that gets rid of the error message > > upstream. >=20 > Why can't we do that in the stable tree? =46irst 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 everyt= hing 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... >=20 > thanks, >=20 > greg k-h --=20 Ville Syrj=E4l=E4 Intel OTC