[Intel-gfx] [PATCH 4.1, 4.2] drm/i915: Silence DDR DVFS errors on CHV

Greg KH gregkh at linuxfoundation.org
Mon Oct 19 09:31:49 PDT 2015


On Mon, Oct 19, 2015 at 06:10:39PM +0200, Daniel Vetter wrote:
> 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 at linuxfoundation.org> wrote:
> > > > On Mon, Sep 28, 2015 at 10:09:11PM +0300, ville.syrjala at linux.intel.com wrote:
> > > >> From: Ville Syrjälä <ville.syrjala at 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 :(
> > 
> > > 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?  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...
> 
> It shuts up a spurious error in dmesg about a feature which isn't even
> implemented and took about 20+ patches to get right in Linus tree. Option
> B is to waste reporters time if we leave that DRM_ERROR in there with
> filing bugs that we'll close right away. There's no way we can backport
> DVFS support without breaking the world.

Ok, then document the heck out of this, as it is, the changelog text
didn't match what was going on at all.

greg k-h


More information about the Intel-gfx mailing list