* [PATCH 4.1,4.2] drm/i915: Silence DDR DVFS errors on CHV @ 2015-09-28 19:09 ville.syrjala 2015-10-17 20:30 ` Greg KH 0 siblings, 1 reply; 7+ messages in thread From: ville.syrjala @ 2015-09-28 19:09 UTC (permalink / raw) To: intel-gfx; +Cc: stable From: Ville Syrjälä <ville.syrjala@linux.intel.com> commit 58590c14d80defc94e900308a9d8fa55284de6f2 upstream. 58590c1 drm/i915: Don't try to use DDR DVFS on CHV when disabled in the BIOS can't be backported as is because proper DDR DVFS support didn't even exist before 6f9c784 drm/i915: Don't do PM5/DDR DVFS with multiple pipes However we still want to get rid of the error messages. The simplest thing is to just suppress them, so let's do that instead. Cc: <stable@vger.kernel.org> # 4.1, 4.2 Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> --- drivers/gpu/drm/i915/intel_pm.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c index eadc15c..4a904f2 100644 --- a/drivers/gpu/drm/i915/intel_pm.c +++ b/drivers/gpu/drm/i915/intel_pm.c @@ -303,7 +303,7 @@ static void chv_set_memory_dvfs(struct drm_i915_private *dev_priv, bool enable) if (wait_for((vlv_punit_read(dev_priv, PUNIT_REG_DDR_SETUP2) & FORCE_DDR_FREQ_REQ_ACK) == 0, 3)) - DRM_ERROR("timed out waiting for Punit DDR DVFS request\n"); + DRM_DEBUG_DRIVER("timed out waiting for Punit DDR DVFS request\n"); mutex_unlock(&dev_priv->rps.hw_lock); } -- 2.4.6 ^ permalink raw reply related [flat|nested] 7+ messages in thread
* Re: [PATCH 4.1,4.2] drm/i915: Silence DDR DVFS errors on CHV 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 0 siblings, 1 reply; 7+ messages in thread From: Greg KH @ 2015-10-17 20:30 UTC (permalink / raw) To: ville.syrjala; +Cc: intel-gfx, stable 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. thanks, greg k-h > > 58590c1 drm/i915: Don't try to use DDR DVFS on CHV when disabled in the BIOS > can't be backported as is because proper DDR DVFS support didn't even > exist before > 6f9c784 drm/i915: Don't do PM5/DDR DVFS with multiple pipes > > However we still want to get rid of the error messages. The simplest thing > is to just suppress them, so let's do that instead. > > Cc: <stable@vger.kernel.org> # 4.1, 4.2 > Signed-off-by: Ville Syrj�l� <ville.syrjala@linux.intel.com> > --- > drivers/gpu/drm/i915/intel_pm.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c > index eadc15c..4a904f2 100644 > --- a/drivers/gpu/drm/i915/intel_pm.c > +++ b/drivers/gpu/drm/i915/intel_pm.c > @@ -303,7 +303,7 @@ static void chv_set_memory_dvfs(struct drm_i915_private *dev_priv, bool enable) > > if (wait_for((vlv_punit_read(dev_priv, PUNIT_REG_DDR_SETUP2) & > FORCE_DDR_FREQ_REQ_ACK) == 0, 3)) > - DRM_ERROR("timed out waiting for Punit DDR DVFS request\n"); > + DRM_DEBUG_DRIVER("timed out waiting for Punit DDR DVFS request\n"); > > mutex_unlock(&dev_priv->rps.hw_lock); > } > -- > 2.4.6 > > -- > To unsubscribe from this list: send the line "unsubscribe stable" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [Intel-gfx] [PATCH 4.1, 4.2] drm/i915: Silence DDR DVFS errors on CHV 2015-10-17 20:30 ` Greg KH @ 2015-10-19 8:02 ` Jani Nikula 2015-10-19 15:13 ` Greg KH 0 siblings, 1 reply; 7+ messages in thread From: Jani Nikula @ 2015-10-19 8:02 UTC (permalink / raw) To: Greg KH, ville.syrjala; +Cc: intel-gfx, stable 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. 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. Was this just a communication failure, or do you think this is still against the stable kernel rules? BR, Jani. > > thanks, > > greg k-h > >> >> 58590c1 drm/i915: Don't try to use DDR DVFS on CHV when disabled in the BIOS >> can't be backported as is because proper DDR DVFS support didn't even >> exist before >> 6f9c784 drm/i915: Don't do PM5/DDR DVFS with multiple pipes >> >> However we still want to get rid of the error messages. The simplest thing >> is to just suppress them, so let's do that instead. >> >> Cc: <stable@vger.kernel.org> # 4.1, 4.2 >> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> >> --- >> drivers/gpu/drm/i915/intel_pm.c | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c >> index eadc15c..4a904f2 100644 >> --- a/drivers/gpu/drm/i915/intel_pm.c >> +++ b/drivers/gpu/drm/i915/intel_pm.c >> @@ -303,7 +303,7 @@ static void chv_set_memory_dvfs(struct drm_i915_private *dev_priv, bool enable) >> >> if (wait_for((vlv_punit_read(dev_priv, PUNIT_REG_DDR_SETUP2) & >> FORCE_DDR_FREQ_REQ_ACK) == 0, 3)) >> - DRM_ERROR("timed out waiting for Punit DDR DVFS request\n"); >> + DRM_DEBUG_DRIVER("timed out waiting for Punit DDR DVFS request\n"); >> >> mutex_unlock(&dev_priv->rps.hw_lock); >> } >> -- >> 2.4.6 >> >> -- >> To unsubscribe from this list: send the line "unsubscribe stable" in >> the body of a message to majordomo@vger.kernel.org >> More majordomo info at http://vger.kernel.org/majordomo-info.html > _______________________________________________ > Intel-gfx mailing list > Intel-gfx@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/intel-gfx -- Jani Nikula, Intel Open Source Technology Center ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [Intel-gfx] [PATCH 4.1, 4.2] drm/i915: Silence DDR DVFS errors on CHV 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:40 ` Ville Syrjälä 0 siblings, 2 replies; 7+ messages in thread From: Greg KH @ 2015-10-19 15:13 UTC (permalink / raw) To: Jani Nikula; +Cc: ville.syrjala, intel-gfx, stable 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 :( > 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... thanks, greg k-h ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [Intel-gfx] [PATCH 4.1, 4.2] drm/i915: Silence DDR DVFS errors on CHV 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ä 1 sibling, 1 reply; 7+ messages in thread From: Daniel Vetter @ 2015-10-19 16:10 UTC (permalink / raw) To: Greg KH; +Cc: Jani Nikula, intel-gfx, stable 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 :( > > > 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. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [Intel-gfx] [PATCH 4.1, 4.2] drm/i915: Silence DDR DVFS errors on CHV 2015-10-19 16:10 ` Daniel Vetter @ 2015-10-19 16:31 ` Greg KH 0 siblings, 0 replies; 7+ messages in thread From: Greg KH @ 2015-10-19 16:31 UTC (permalink / raw) To: Daniel Vetter; +Cc: Jani Nikula, intel-gfx, stable 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@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 :( > > > > > 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 ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [Intel-gfx] [PATCH 4.1, 4.2] drm/i915: Silence DDR DVFS errors on CHV 2015-10-19 15:13 ` Greg KH 2015-10-19 16:10 ` Daniel Vetter @ 2015-10-19 16:40 ` Ville Syrjälä 1 sibling, 0 replies; 7+ messages in thread From: Ville Syrjälä @ 2015-10-19 16:40 UTC (permalink / raw) To: Greg KH; +Cc: Jani Nikula, intel-gfx, stable 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 ^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2015-10-19 16:40 UTC | newest] Thread overview: 7+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 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 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).