* [PATCH] drm/i915: fix long-standing SNB regression in power consumption after resume @ 2013-07-14 16:30 Konstantin Khlebnikov 2013-07-14 16:52 ` Daniel Vetter ` (2 more replies) 0 siblings, 3 replies; 23+ messages in thread From: Konstantin Khlebnikov @ 2013-07-14 16:30 UTC (permalink / raw) To: David Airlie, Daniel Vetter, intel-gfx, linux-kernel, dri-devel, Chris Wilson This patch fixes regression in power consumtion of sandy bridge gpu, which exists since v3.6 Sometimes after resuming from s2ram gpu starts thinking that it's extremely busy. After that it never reaches rc6 state. Bug was introduce by commit b4ae3f22d238617ca11610b29fde16cf8c0bc6e0 ("drm/i915: load boot context at driver init time"). Without documentation it's not clear what is happening here, probably this breaks internal state of hardware ring buffers and confuses RPS engine. Fortunately keeping forcewake during whole initialization sequence in gen6_init_clock_gating() fixes this bug. References: https://bugs.freedesktop.org/show_bug.cgi?id=54089 Signed-off-by: Konstantin Khlebnikov <khlebnikov@openvz.org> --- drivers/gpu/drm/i915/intel_pm.c | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c index aa01128..839a43f 100644 --- a/drivers/gpu/drm/i915/intel_pm.c +++ b/drivers/gpu/drm/i915/intel_pm.c @@ -3640,6 +3640,8 @@ static void gen6_init_clock_gating(struct drm_device *dev) int pipe; uint32_t dspclk_gate = ILK_VRHUNIT_CLOCK_GATE_DISABLE; + gen6_gt_force_wake_get(dev_priv); + I915_WRITE(ILK_DSPCLK_GATE_D, dspclk_gate); I915_WRITE(ILK_DISPLAY_CHICKEN2, @@ -3728,6 +3730,8 @@ static void gen6_init_clock_gating(struct drm_device *dev) cpt_init_clock_gating(dev); gen6_check_mch_setup(dev); + + gen6_gt_force_wake_put(dev_priv); } static void gen7_setup_fixed_func_scheduler(struct drm_i915_private *dev_priv) ^ permalink raw reply related [flat|nested] 23+ messages in thread
* Re: [PATCH] drm/i915: fix long-standing SNB regression in power consumption after resume 2013-07-14 16:30 [PATCH] drm/i915: fix long-standing SNB regression in power consumption after resume Konstantin Khlebnikov @ 2013-07-14 16:52 ` Daniel Vetter 2013-07-16 6:32 ` Daniel Vetter 2013-07-17 6:22 ` [PATCH v2] " Konstantin Khlebnikov 2 siblings, 0 replies; 23+ messages in thread From: Daniel Vetter @ 2013-07-14 16:52 UTC (permalink / raw) To: Konstantin Khlebnikov Cc: David Airlie, intel-gfx, Linux Kernel Mailing List, dri-devel, Chris Wilson On Sun, Jul 14, 2013 at 6:30 PM, Konstantin Khlebnikov <khlebnikov@openvz.org> wrote: > This patch fixes regression in power consumtion of sandy bridge gpu, which > exists since v3.6 Sometimes after resuming from s2ram gpu starts thinking that > it's extremely busy. After that it never reaches rc6 state. > > Bug was introduce by commit b4ae3f22d238617ca11610b29fde16cf8c0bc6e0 > ("drm/i915: load boot context at driver init time"). Without documentation > it's not clear what is happening here, probably this breaks internal state of > hardware ring buffers and confuses RPS engine. Fortunately keeping forcewake > during whole initialization sequence in gen6_init_clock_gating() fixes this bug. > > References: https://bugs.freedesktop.org/show_bug.cgi?id=54089 > Signed-off-by: Konstantin Khlebnikov <khlebnikov@openvz.org> We already hold an forcewake reference while setting up the rps stuff, should we maybe hold the forcewake for the entire duration, i.e. grab it here in clock_gating and release it only in gen6/vlv_enable_rps? Can you please test that version, too? In any case the forcewake grabbing here in the clock gating function needs a big comment that otherwise setting the MCTL register might break rc6 entry. -Daniel > --- > drivers/gpu/drm/i915/intel_pm.c | 4 ++++ > 1 file changed, 4 insertions(+) > > diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c > index aa01128..839a43f 100644 > --- a/drivers/gpu/drm/i915/intel_pm.c > +++ b/drivers/gpu/drm/i915/intel_pm.c > @@ -3640,6 +3640,8 @@ static void gen6_init_clock_gating(struct drm_device *dev) > int pipe; > uint32_t dspclk_gate = ILK_VRHUNIT_CLOCK_GATE_DISABLE; > > + gen6_gt_force_wake_get(dev_priv); > + > I915_WRITE(ILK_DSPCLK_GATE_D, dspclk_gate); > > I915_WRITE(ILK_DISPLAY_CHICKEN2, > @@ -3728,6 +3730,8 @@ static void gen6_init_clock_gating(struct drm_device *dev) > cpt_init_clock_gating(dev); > > gen6_check_mch_setup(dev); > + > + gen6_gt_force_wake_put(dev_priv); > } > > static void gen7_setup_fixed_func_scheduler(struct drm_i915_private *dev_priv) > -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [PATCH] drm/i915: fix long-standing SNB regression in power consumption after resume @ 2013-07-14 16:52 ` Daniel Vetter 0 siblings, 0 replies; 23+ messages in thread From: Daniel Vetter @ 2013-07-14 16:52 UTC (permalink / raw) To: Konstantin Khlebnikov; +Cc: intel-gfx, Linux Kernel Mailing List, dri-devel On Sun, Jul 14, 2013 at 6:30 PM, Konstantin Khlebnikov <khlebnikov@openvz.org> wrote: > This patch fixes regression in power consumtion of sandy bridge gpu, which > exists since v3.6 Sometimes after resuming from s2ram gpu starts thinking that > it's extremely busy. After that it never reaches rc6 state. > > Bug was introduce by commit b4ae3f22d238617ca11610b29fde16cf8c0bc6e0 > ("drm/i915: load boot context at driver init time"). Without documentation > it's not clear what is happening here, probably this breaks internal state of > hardware ring buffers and confuses RPS engine. Fortunately keeping forcewake > during whole initialization sequence in gen6_init_clock_gating() fixes this bug. > > References: https://bugs.freedesktop.org/show_bug.cgi?id=54089 > Signed-off-by: Konstantin Khlebnikov <khlebnikov@openvz.org> We already hold an forcewake reference while setting up the rps stuff, should we maybe hold the forcewake for the entire duration, i.e. grab it here in clock_gating and release it only in gen6/vlv_enable_rps? Can you please test that version, too? In any case the forcewake grabbing here in the clock gating function needs a big comment that otherwise setting the MCTL register might break rc6 entry. -Daniel > --- > drivers/gpu/drm/i915/intel_pm.c | 4 ++++ > 1 file changed, 4 insertions(+) > > diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c > index aa01128..839a43f 100644 > --- a/drivers/gpu/drm/i915/intel_pm.c > +++ b/drivers/gpu/drm/i915/intel_pm.c > @@ -3640,6 +3640,8 @@ static void gen6_init_clock_gating(struct drm_device *dev) > int pipe; > uint32_t dspclk_gate = ILK_VRHUNIT_CLOCK_GATE_DISABLE; > > + gen6_gt_force_wake_get(dev_priv); > + > I915_WRITE(ILK_DSPCLK_GATE_D, dspclk_gate); > > I915_WRITE(ILK_DISPLAY_CHICKEN2, > @@ -3728,6 +3730,8 @@ static void gen6_init_clock_gating(struct drm_device *dev) > cpt_init_clock_gating(dev); > > gen6_check_mch_setup(dev); > + > + gen6_gt_force_wake_put(dev_priv); > } > > static void gen7_setup_fixed_func_scheduler(struct drm_i915_private *dev_priv) > -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [PATCH] drm/i915: fix long-standing SNB regression in power consumption after resume 2013-07-14 16:52 ` Daniel Vetter @ 2013-07-14 17:56 ` Konstantin Khlebnikov -1 siblings, 0 replies; 23+ messages in thread From: Konstantin Khlebnikov @ 2013-07-14 17:56 UTC (permalink / raw) To: Daniel Vetter Cc: David Airlie, intel-gfx, Linux Kernel Mailing List, dri-devel, Chris Wilson Daniel Vetter wrote: > On Sun, Jul 14, 2013 at 6:30 PM, Konstantin Khlebnikov > <khlebnikov@openvz.org> wrote: >> This patch fixes regression in power consumtion of sandy bridge gpu, which >> exists since v3.6 Sometimes after resuming from s2ram gpu starts thinking that >> it's extremely busy. After that it never reaches rc6 state. >> >> Bug was introduce by commit b4ae3f22d238617ca11610b29fde16cf8c0bc6e0 >> ("drm/i915: load boot context at driver init time"). Without documentation >> it's not clear what is happening here, probably this breaks internal state of >> hardware ring buffers and confuses RPS engine. Fortunately keeping forcewake >> during whole initialization sequence in gen6_init_clock_gating() fixes this bug. >> >> References: https://bugs.freedesktop.org/show_bug.cgi?id=54089 >> Signed-off-by: Konstantin Khlebnikov<khlebnikov@openvz.org> > > We already hold an forcewake reference while setting up the rps stuff, > should we maybe hold the forcewake for the entire duration, i.e. grab > it here in clock_gating and release it only in gen6/vlv_enable_rps? > Can you please test that version, too? This will be racy because rps stuff is done in separate work which might be canceled if intel_disable_gt_powersave() happens before its completion. > > In any case the forcewake grabbing here in the clock gating function > needs a big comment that otherwise setting the MCTL register might > break rc6 entry. > -Daniel > >> --- >> drivers/gpu/drm/i915/intel_pm.c | 4 ++++ >> 1 file changed, 4 insertions(+) >> >> diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c >> index aa01128..839a43f 100644 >> --- a/drivers/gpu/drm/i915/intel_pm.c >> +++ b/drivers/gpu/drm/i915/intel_pm.c >> @@ -3640,6 +3640,8 @@ static void gen6_init_clock_gating(struct drm_device *dev) >> int pipe; >> uint32_t dspclk_gate = ILK_VRHUNIT_CLOCK_GATE_DISABLE; >> >> + gen6_gt_force_wake_get(dev_priv); >> + >> I915_WRITE(ILK_DSPCLK_GATE_D, dspclk_gate); >> >> I915_WRITE(ILK_DISPLAY_CHICKEN2, >> @@ -3728,6 +3730,8 @@ static void gen6_init_clock_gating(struct drm_device *dev) >> cpt_init_clock_gating(dev); >> >> gen6_check_mch_setup(dev); >> + >> + gen6_gt_force_wake_put(dev_priv); >> } >> >> static void gen7_setup_fixed_func_scheduler(struct drm_i915_private *dev_priv) >> > > > > -- > Daniel Vetter > Software Engineer, Intel Corporation > +41 (0) 79 365 57 48 - http://blog.ffwll.ch ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [PATCH] drm/i915: fix long-standing SNB regression in power consumption after resume @ 2013-07-14 17:56 ` Konstantin Khlebnikov 0 siblings, 0 replies; 23+ messages in thread From: Konstantin Khlebnikov @ 2013-07-14 17:56 UTC (permalink / raw) To: Daniel Vetter; +Cc: intel-gfx, Linux Kernel Mailing List, dri-devel Daniel Vetter wrote: > On Sun, Jul 14, 2013 at 6:30 PM, Konstantin Khlebnikov > <khlebnikov@openvz.org> wrote: >> This patch fixes regression in power consumtion of sandy bridge gpu, which >> exists since v3.6 Sometimes after resuming from s2ram gpu starts thinking that >> it's extremely busy. After that it never reaches rc6 state. >> >> Bug was introduce by commit b4ae3f22d238617ca11610b29fde16cf8c0bc6e0 >> ("drm/i915: load boot context at driver init time"). Without documentation >> it's not clear what is happening here, probably this breaks internal state of >> hardware ring buffers and confuses RPS engine. Fortunately keeping forcewake >> during whole initialization sequence in gen6_init_clock_gating() fixes this bug. >> >> References: https://bugs.freedesktop.org/show_bug.cgi?id=54089 >> Signed-off-by: Konstantin Khlebnikov<khlebnikov@openvz.org> > > We already hold an forcewake reference while setting up the rps stuff, > should we maybe hold the forcewake for the entire duration, i.e. grab > it here in clock_gating and release it only in gen6/vlv_enable_rps? > Can you please test that version, too? This will be racy because rps stuff is done in separate work which might be canceled if intel_disable_gt_powersave() happens before its completion. > > In any case the forcewake grabbing here in the clock gating function > needs a big comment that otherwise setting the MCTL register might > break rc6 entry. > -Daniel > >> --- >> drivers/gpu/drm/i915/intel_pm.c | 4 ++++ >> 1 file changed, 4 insertions(+) >> >> diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c >> index aa01128..839a43f 100644 >> --- a/drivers/gpu/drm/i915/intel_pm.c >> +++ b/drivers/gpu/drm/i915/intel_pm.c >> @@ -3640,6 +3640,8 @@ static void gen6_init_clock_gating(struct drm_device *dev) >> int pipe; >> uint32_t dspclk_gate = ILK_VRHUNIT_CLOCK_GATE_DISABLE; >> >> + gen6_gt_force_wake_get(dev_priv); >> + >> I915_WRITE(ILK_DSPCLK_GATE_D, dspclk_gate); >> >> I915_WRITE(ILK_DISPLAY_CHICKEN2, >> @@ -3728,6 +3730,8 @@ static void gen6_init_clock_gating(struct drm_device *dev) >> cpt_init_clock_gating(dev); >> >> gen6_check_mch_setup(dev); >> + >> + gen6_gt_force_wake_put(dev_priv); >> } >> >> static void gen7_setup_fixed_func_scheduler(struct drm_i915_private *dev_priv) >> > > > > -- > Daniel Vetter > Software Engineer, Intel Corporation > +41 (0) 79 365 57 48 - http://blog.ffwll.ch ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [PATCH] drm/i915: fix long-standing SNB regression in power consumption after resume 2013-07-14 17:56 ` Konstantin Khlebnikov (?) @ 2013-07-16 6:31 ` Daniel Vetter 2013-07-16 7:34 ` Konstantin Khlebnikov -1 siblings, 1 reply; 23+ messages in thread From: Daniel Vetter @ 2013-07-16 6:31 UTC (permalink / raw) To: Konstantin Khlebnikov Cc: Daniel Vetter, David Airlie, intel-gfx, Linux Kernel Mailing List, dri-devel, Chris Wilson On Sun, Jul 14, 2013 at 09:56:45PM +0400, Konstantin Khlebnikov wrote: > Daniel Vetter wrote: > >On Sun, Jul 14, 2013 at 6:30 PM, Konstantin Khlebnikov > ><khlebnikov@openvz.org> wrote: > >>This patch fixes regression in power consumtion of sandy bridge gpu, which > >>exists since v3.6 Sometimes after resuming from s2ram gpu starts thinking that > >>it's extremely busy. After that it never reaches rc6 state. > >> > >>Bug was introduce by commit b4ae3f22d238617ca11610b29fde16cf8c0bc6e0 > >>("drm/i915: load boot context at driver init time"). Without documentation > >>it's not clear what is happening here, probably this breaks internal state of > >>hardware ring buffers and confuses RPS engine. Fortunately keeping forcewake > >>during whole initialization sequence in gen6_init_clock_gating() fixes this bug. > >> > >>References: https://bugs.freedesktop.org/show_bug.cgi?id=54089 > >>Signed-off-by: Konstantin Khlebnikov<khlebnikov@openvz.org> > > > >We already hold an forcewake reference while setting up the rps stuff, > >should we maybe hold the forcewake for the entire duration, i.e. grab > >it here in clock_gating and release it only in gen6/vlv_enable_rps? > >Can you please test that version, too? > > This will be racy because rps stuff is done in separate work which might be canceled > if intel_disable_gt_powersave() happens before its completion. Can be fixed with a flush_delayed_work. And since that has the same requirements wrt locking to prevent deadlocks as cancel_work_sync it would be a drop-in replacement. Can I volunteer you to look into testing that out a bit? Otherwise I could volunteer someone from our team. In any case I think we should apply this trick to all platforms where we've added the MBCTL write (i.e. snb, ivb, hsw & vlv) since rps/rc6 works _very_ similar on all of those. Thanks, Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [PATCH] drm/i915: fix long-standing SNB regression in power consumption after resume 2013-07-16 6:31 ` Daniel Vetter @ 2013-07-16 7:34 ` Konstantin Khlebnikov 2013-07-16 7:44 ` Daniel Vetter 2013-07-16 17:06 ` Jesse Barnes 0 siblings, 2 replies; 23+ messages in thread From: Konstantin Khlebnikov @ 2013-07-16 7:34 UTC (permalink / raw) To: Konstantin Khlebnikov, David Airlie, intel-gfx, Linux Kernel Mailing List, dri-devel, Chris Wilson Cc: Daniel Vetter [-- Attachment #1.1: Type: text/plain, Size: 2341 bytes --] On Tue, Jul 16, 2013 at 10:31 AM, Daniel Vetter <daniel@ffwll.ch> wrote: > On Sun, Jul 14, 2013 at 09:56:45PM +0400, Konstantin Khlebnikov wrote: > > Daniel Vetter wrote: > > >On Sun, Jul 14, 2013 at 6:30 PM, Konstantin Khlebnikov > > ><khlebnikov@openvz.org> wrote: > > >>This patch fixes regression in power consumtion of sandy bridge gpu, > which > > >>exists since v3.6 Sometimes after resuming from s2ram gpu starts > thinking that > > >>it's extremely busy. After that it never reaches rc6 state. > > >> > > >>Bug was introduce by commit b4ae3f22d238617ca11610b29fde16cf8c0bc6e0 > > >>("drm/i915: load boot context at driver init time"). Without > documentation > > >>it's not clear what is happening here, probably this breaks internal > state of > > >>hardware ring buffers and confuses RPS engine. Fortunately keeping > forcewake > > >>during whole initialization sequence in gen6_init_clock_gating() fixes > this bug. > > >> > > >>References: https://bugs.freedesktop.org/show_bug.cgi?id=54089 > > >>Signed-off-by: Konstantin Khlebnikov<khlebnikov@openvz.org> > > > > > >We already hold an forcewake reference while setting up the rps stuff, > > >should we maybe hold the forcewake for the entire duration, i.e. grab > > >it here in clock_gating and release it only in gen6/vlv_enable_rps? > > >Can you please test that version, too? > > > > This will be racy because rps stuff is done in separate work which might > be canceled > > if intel_disable_gt_powersave() happens before its completion. > > Can be fixed with a flush_delayed_work. And since that has the same > requirements wrt locking to prevent deadlocks as cancel_work_sync it would > be a drop-in replacement. Can I volunteer you to look into testing that > out a bit? Otherwise I could volunteer someone from our team. > > In any case I think we should apply this trick to all platforms where > we've added the MBCTL write (i.e. snb, ivb, hsw & vlv) since rps/rc6 works > _very_ similar on all of those. > I've tested that patch and it really works for me. If you want change something for other hardware or extend range where forcewake is held prease do it in a separate patch. This will be good for bisecting new bugs in the future. > > Thanks, Daniel > -- > Daniel Vetter > Software Engineer, Intel Corporation > +41 (0) 79 365 57 48 - http://blog.ffwll.ch > [-- Attachment #1.2: Type: text/html, Size: 3336 bytes --] [-- Attachment #2: Type: text/plain, Size: 159 bytes --] _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [PATCH] drm/i915: fix long-standing SNB regression in power consumption after resume 2013-07-16 7:34 ` Konstantin Khlebnikov @ 2013-07-16 7:44 ` Daniel Vetter 2013-07-16 8:31 ` Chris Wilson 2013-07-16 17:06 ` Jesse Barnes 1 sibling, 1 reply; 23+ messages in thread From: Daniel Vetter @ 2013-07-16 7:44 UTC (permalink / raw) To: Konstantin Khlebnikov Cc: David Airlie, intel-gfx, Linux Kernel Mailing List, dri-devel, Chris Wilson, Daniel Vetter On Tue, Jul 16, 2013 at 11:34:25AM +0400, Konstantin Khlebnikov wrote: > On Tue, Jul 16, 2013 at 10:31 AM, Daniel Vetter <daniel@ffwll.ch> wrote: > > > On Sun, Jul 14, 2013 at 09:56:45PM +0400, Konstantin Khlebnikov wrote: > > > Daniel Vetter wrote: > > > >On Sun, Jul 14, 2013 at 6:30 PM, Konstantin Khlebnikov > > > ><khlebnikov@openvz.org> wrote: > > > >>This patch fixes regression in power consumtion of sandy bridge gpu, > > which > > > >>exists since v3.6 Sometimes after resuming from s2ram gpu starts > > thinking that > > > >>it's extremely busy. After that it never reaches rc6 state. > > > >> > > > >>Bug was introduce by commit b4ae3f22d238617ca11610b29fde16cf8c0bc6e0 > > > >>("drm/i915: load boot context at driver init time"). Without > > documentation > > > >>it's not clear what is happening here, probably this breaks internal > > state of > > > >>hardware ring buffers and confuses RPS engine. Fortunately keeping > > forcewake > > > >>during whole initialization sequence in gen6_init_clock_gating() fixes > > this bug. > > > >> > > > >>References: https://bugs.freedesktop.org/show_bug.cgi?id=54089 > > > >>Signed-off-by: Konstantin Khlebnikov<khlebnikov@openvz.org> > > > > > > > >We already hold an forcewake reference while setting up the rps stuff, > > > >should we maybe hold the forcewake for the entire duration, i.e. grab > > > >it here in clock_gating and release it only in gen6/vlv_enable_rps? > > > >Can you please test that version, too? > > > > > > This will be racy because rps stuff is done in separate work which might > > be canceled > > > if intel_disable_gt_powersave() happens before its completion. > > > > Can be fixed with a flush_delayed_work. And since that has the same > > requirements wrt locking to prevent deadlocks as cancel_work_sync it would > > be a drop-in replacement. Can I volunteer you to look into testing that > > out a bit? Otherwise I could volunteer someone from our team. > > > > In any case I think we should apply this trick to all platforms where > > we've added the MBCTL write (i.e. snb, ivb, hsw & vlv) since rps/rc6 works > > _very_ similar on all of those. > > > > I've tested that patch and it really works for me. If you want change > something for other hardware or > extend range where forcewake is held prease do it in a separate patch. > This will be good for bisecting new bugs in the future. The issue I have with the current patch is that it looks a bit like duct-tape since the point where we drop the forcewake references seems to lack justification. The write to MBCTL itself will temporarily wake up the chip, so just wrapping that up in with forcewake is very likely not good enough. So I fear that we'll only hold forcewake long enough on most systems and still have a bunch of oddball broken systems out there. Holding forcewake otoh until we've fully set up rps/rc6 makes imo tons of sense, hence why I've brought up the idea. Same reasoning applies to extending the w/a to all systems supporting rc6. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [PATCH] drm/i915: fix long-standing SNB regression in power consumption after resume 2013-07-16 7:44 ` Daniel Vetter @ 2013-07-16 8:31 ` Chris Wilson 2013-07-16 11:13 ` Daniel Vetter 0 siblings, 1 reply; 23+ messages in thread From: Chris Wilson @ 2013-07-16 8:31 UTC (permalink / raw) To: Konstantin Khlebnikov, David Airlie, intel-gfx, Linux Kernel Mailing List, dri-devel On Tue, Jul 16, 2013 at 09:44:59AM +0200, Daniel Vetter wrote: > The issue I have with the current patch is that it looks a bit like > duct-tape since the point where we drop the forcewake references seems to > lack justification. The write to MBCTL itself will temporarily wake up the > chip, so just wrapping that up in with forcewake is very likely not good > enough. So I fear that we'll only hold forcewake long enough on most > systems and still have a bunch of oddball broken systems out there. > > Holding forcewake otoh until we've fully set up rps/rc6 makes imo tons of > sense, hence why I've brought up the idea. Same reasoning applies to > extending the w/a to all systems supporting rc6. In which case disable rc6 at the start of init gating and only enable it at the end of the deferred task. That I think will better test your hypothesis and make the transistion steps clearer. -Chris -- Chris Wilson, Intel Open Source Technology Centre ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [PATCH] drm/i915: fix long-standing SNB regression in power consumption after resume 2013-07-16 8:31 ` Chris Wilson @ 2013-07-16 11:13 ` Daniel Vetter 0 siblings, 0 replies; 23+ messages in thread From: Daniel Vetter @ 2013-07-16 11:13 UTC (permalink / raw) To: Chris Wilson, Konstantin Khlebnikov, David Airlie, intel-gfx, Linux Kernel Mailing List, dri-devel On Tue, Jul 16, 2013 at 10:31 AM, Chris Wilson <chris@chris-wilson.co.uk> wrote: > On Tue, Jul 16, 2013 at 09:44:59AM +0200, Daniel Vetter wrote: >> The issue I have with the current patch is that it looks a bit like >> duct-tape since the point where we drop the forcewake references seems to >> lack justification. The write to MBCTL itself will temporarily wake up the >> chip, so just wrapping that up in with forcewake is very likely not good >> enough. So I fear that we'll only hold forcewake long enough on most >> systems and still have a bunch of oddball broken systems out there. >> >> Holding forcewake otoh until we've fully set up rps/rc6 makes imo tons of >> sense, hence why I've brought up the idea. Same reasoning applies to >> extending the w/a to all systems supporting rc6. > > In which case disable rc6 at the start of init gating and only enable it > at the end of the deferred task. That I think will better test your > hypothesis and make the transistion steps clearer. Hm yeah, that would be much clearer instead of risky tricks with a refcount which is only dropped someplace completely else. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [Intel-gfx] [PATCH] drm/i915: fix long-standing SNB regression in power consumption after resume 2013-07-16 7:34 ` Konstantin Khlebnikov @ 2013-07-16 17:06 ` Jesse Barnes 2013-07-16 17:06 ` Jesse Barnes 1 sibling, 0 replies; 23+ messages in thread From: Jesse Barnes @ 2013-07-16 17:06 UTC (permalink / raw) To: Konstantin Khlebnikov Cc: David Airlie, intel-gfx, Linux Kernel Mailing List, dri-devel, Chris Wilson, Daniel Vetter, Alexander Kaltsas, rocko, JohnMB On Tue, 16 Jul 2013 11:34:25 +0400 Konstantin Khlebnikov <khlebnikov@openvz.org> wrote: > I've tested that patch and it really works for me. If you want change > something for other hardware or > extend range where forcewake is held prease do it in a separate patch. > This will be good for bisecting new bugs in the future. Thanks a ton for finding this Konstantin, it puts us on the right track. Can I ask you to test this patch? The theory is that having RC6 enabled messes with the initial programming sequence, so it's probably best to just shut it off at init until we're done, rather than trying to forcewake around everywhere we need it. Thanks, -- Jesse Barnes, Intel Open Source Technology Center diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_d index 12ea1a9..9152cba 100644 --- a/drivers/gpu/drm/i915/intel_display.c +++ b/drivers/gpu/drm/i915/intel_display.c @@ -9648,6 +9648,9 @@ static void i915_disable_vga(struct drm_device *dev) void intel_modeset_init_hw(struct drm_device *dev) { + /* BIOS often leaves RC6 enabled, but disable it for hw init */ + intel_disable_gt_powersave(dev); + intel_init_power_well(dev); intel_prepare_ddi(dev); ^ permalink raw reply related [flat|nested] 23+ messages in thread
* Re: [PATCH] drm/i915: fix long-standing SNB regression in power consumption after resume @ 2013-07-16 17:06 ` Jesse Barnes 0 siblings, 0 replies; 23+ messages in thread From: Jesse Barnes @ 2013-07-16 17:06 UTC (permalink / raw) To: Konstantin Khlebnikov Cc: David Airlie, Daniel Vetter, intel-gfx, Linux Kernel Mailing List, dri-devel, Alexander Kaltsas, rocko On Tue, 16 Jul 2013 11:34:25 +0400 Konstantin Khlebnikov <khlebnikov@openvz.org> wrote: > I've tested that patch and it really works for me. If you want change > something for other hardware or > extend range where forcewake is held prease do it in a separate patch. > This will be good for bisecting new bugs in the future. Thanks a ton for finding this Konstantin, it puts us on the right track. Can I ask you to test this patch? The theory is that having RC6 enabled messes with the initial programming sequence, so it's probably best to just shut it off at init until we're done, rather than trying to forcewake around everywhere we need it. Thanks, -- Jesse Barnes, Intel Open Source Technology Center diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_d index 12ea1a9..9152cba 100644 --- a/drivers/gpu/drm/i915/intel_display.c +++ b/drivers/gpu/drm/i915/intel_display.c @@ -9648,6 +9648,9 @@ static void i915_disable_vga(struct drm_device *dev) void intel_modeset_init_hw(struct drm_device *dev) { + /* BIOS often leaves RC6 enabled, but disable it for hw init */ + intel_disable_gt_powersave(dev); + intel_init_power_well(dev); intel_prepare_ddi(dev); ^ permalink raw reply related [flat|nested] 23+ messages in thread
* Re: [Intel-gfx] [PATCH] drm/i915: fix long-standing SNB regression in power consumption after resume 2013-07-16 17:06 ` Jesse Barnes (?) @ 2013-07-16 20:19 ` Jesse Barnes 2013-07-16 20:43 ` Daniel Vetter -1 siblings, 1 reply; 23+ messages in thread From: Jesse Barnes @ 2013-07-16 20:19 UTC (permalink / raw) To: Jesse Barnes Cc: Konstantin Khlebnikov, David Airlie, Daniel Vetter, intel-gfx, Linux Kernel Mailing List, dri-devel, Alexander Kaltsas, rocko On Tue, 16 Jul 2013 10:06:54 -0700 Jesse Barnes <jbarnes@virtuousgeek.org> wrote: > On Tue, 16 Jul 2013 11:34:25 +0400 > Konstantin Khlebnikov <khlebnikov@openvz.org> wrote: > > I've tested that patch and it really works for me. If you want change > > something for other hardware or > > extend range where forcewake is held prease do it in a separate patch. > > This will be good for bisecting new bugs in the future. > > Thanks a ton for finding this Konstantin, it puts us on the right > track. > > Can I ask you to test this patch? The theory is that having RC6 > enabled messes with the initial programming sequence, so it's probably > best to just shut it off at init until we're done, rather than trying > to forcewake around everywhere we need it. Oops, last one triggers a warn about IRQs. This one doesn't and still works for me. Testing welcome. Thanks, -- Jesse Barnes, Intel Open Source Technology Center diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c index c9d9d20..d962ec0 100644 --- a/drivers/gpu/drm/i915/i915_gem.c +++ b/drivers/gpu/drm/i915/i915_gem.c @@ -4112,6 +4112,9 @@ i915_gem_init_hw(struct drm_device *dev) drm_i915_private_t *dev_priv = dev->dev_private; int ret; + /* BIOS often leaves RC6 enabled, but disable it for hw init */ + intel_disable_gt_powersave(dev); + if (INTEL_INFO(dev)->gen < 6 && !intel_enable_gtt()) return -EIO; ^ permalink raw reply related [flat|nested] 23+ messages in thread
* Re: [Intel-gfx] [PATCH] drm/i915: fix long-standing SNB regression in power consumption after resume 2013-07-16 20:19 ` [Intel-gfx] " Jesse Barnes @ 2013-07-16 20:43 ` Daniel Vetter 2013-07-16 20:52 ` Jesse Barnes 0 siblings, 1 reply; 23+ messages in thread From: Daniel Vetter @ 2013-07-16 20:43 UTC (permalink / raw) To: Jesse Barnes Cc: Daniel Vetter, intel-gfx, Linux Kernel Mailing List, dri-devel, Alexander Kaltsas, Konstantin Khlebnikov, rocko On Tue, Jul 16, 2013 at 01:19:25PM -0700, Jesse Barnes wrote: > On Tue, 16 Jul 2013 10:06:54 -0700 > Jesse Barnes <jbarnes@virtuousgeek.org> wrote: > > > On Tue, 16 Jul 2013 11:34:25 +0400 > > Konstantin Khlebnikov <khlebnikov@openvz.org> wrote: > > > I've tested that patch and it really works for me. If you want change > > > something for other hardware or > > > extend range where forcewake is held prease do it in a separate patch. > > > This will be good for bisecting new bugs in the future. > > > > Thanks a ton for finding this Konstantin, it puts us on the right > > track. > > > > Can I ask you to test this patch? The theory is that having RC6 > > enabled messes with the initial programming sequence, so it's probably > > best to just shut it off at init until we're done, rather than trying > > to forcewake around everywhere we need it. > > Oops, last one triggers a warn about IRQs. This one doesn't and still > works for me. > > Testing welcome. > > Thanks, > -- > Jesse Barnes, Intel Open Source Technology Center > > diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c > index c9d9d20..d962ec0 100644 > --- a/drivers/gpu/drm/i915/i915_gem.c > +++ b/drivers/gpu/drm/i915/i915_gem.c > @@ -4112,6 +4112,9 @@ i915_gem_init_hw(struct drm_device *dev) > drm_i915_private_t *dev_priv = dev->dev_private; > int ret; > > + /* BIOS often leaves RC6 enabled, but disable it for hw init */ > + intel_disable_gt_powersave(dev); I think it'd be better to have an explicit gen >= 6 check here and a disable_rps call. disable_gt_powersave also calls the ironlake version, which restores probably bogus values (since we haven't read them out yet in the enable code) into the hw. -Daniel > + > if (INTEL_INFO(dev)->gen < 6 && !intel_enable_gtt()) > return -EIO; > > _______________________________________________ > dri-devel mailing list > dri-devel@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/dri-devel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [Intel-gfx] [PATCH] drm/i915: fix long-standing SNB regression in power consumption after resume 2013-07-16 20:43 ` Daniel Vetter @ 2013-07-16 20:52 ` Jesse Barnes 0 siblings, 0 replies; 23+ messages in thread From: Jesse Barnes @ 2013-07-16 20:52 UTC (permalink / raw) To: Daniel Vetter Cc: Daniel Vetter, intel-gfx, Linux Kernel Mailing List, dri-devel, Alexander Kaltsas, Konstantin Khlebnikov, rocko On Tue, 16 Jul 2013 22:43:49 +0200 Daniel Vetter <daniel@ffwll.ch> wrote: > On Tue, Jul 16, 2013 at 01:19:25PM -0700, Jesse Barnes wrote: > > On Tue, 16 Jul 2013 10:06:54 -0700 > > Jesse Barnes <jbarnes@virtuousgeek.org> wrote: > > > > > On Tue, 16 Jul 2013 11:34:25 +0400 > > > Konstantin Khlebnikov <khlebnikov@openvz.org> wrote: > > > > I've tested that patch and it really works for me. If you want change > > > > something for other hardware or > > > > extend range where forcewake is held prease do it in a separate patch. > > > > This will be good for bisecting new bugs in the future. > > > > > > Thanks a ton for finding this Konstantin, it puts us on the right > > > track. > > > > > > Can I ask you to test this patch? The theory is that having RC6 > > > enabled messes with the initial programming sequence, so it's probably > > > best to just shut it off at init until we're done, rather than trying > > > to forcewake around everywhere we need it. > > > > Oops, last one triggers a warn about IRQs. This one doesn't and still > > works for me. > > > > Testing welcome. > > > > Thanks, > > -- > > Jesse Barnes, Intel Open Source Technology Center > > > > diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c > > index c9d9d20..d962ec0 100644 > > --- a/drivers/gpu/drm/i915/i915_gem.c > > +++ b/drivers/gpu/drm/i915/i915_gem.c > > @@ -4112,6 +4112,9 @@ i915_gem_init_hw(struct drm_device *dev) > > drm_i915_private_t *dev_priv = dev->dev_private; > > int ret; > > > > + /* BIOS often leaves RC6 enabled, but disable it for hw init */ > > + intel_disable_gt_powersave(dev); > > I think it'd be better to have an explicit gen >= 6 check here and a > disable_rps call. disable_gt_powersave also calls the ironlake version, > which restores probably bogus values (since we haven't read them out yet > in the enable code) into the hw. Yeah the ilk "restore to initial freq" needs fixing, but I thought we wanted this on all gens? It shouldn't hurt anything, and may help with other issues as well. -- Jesse Barnes, Intel Open Source Technology Center ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [PATCH] drm/i915: fix long-standing SNB regression in power consumption after resume 2013-07-14 16:52 ` Daniel Vetter @ 2013-07-14 21:48 ` Chris Wilson -1 siblings, 0 replies; 23+ messages in thread From: Chris Wilson @ 2013-07-14 21:48 UTC (permalink / raw) To: Daniel Vetter Cc: Konstantin Khlebnikov, David Airlie, intel-gfx, Linux Kernel Mailing List, dri-devel On Sun, Jul 14, 2013 at 06:52:39PM +0200, Daniel Vetter wrote: > On Sun, Jul 14, 2013 at 6:30 PM, Konstantin Khlebnikov > <khlebnikov@openvz.org> wrote: > > This patch fixes regression in power consumtion of sandy bridge gpu, which > > exists since v3.6 Sometimes after resuming from s2ram gpu starts thinking that > > it's extremely busy. After that it never reaches rc6 state. > > > > Bug was introduce by commit b4ae3f22d238617ca11610b29fde16cf8c0bc6e0 > > ("drm/i915: load boot context at driver init time"). Without documentation > > it's not clear what is happening here, probably this breaks internal state of > > hardware ring buffers and confuses RPS engine. Fortunately keeping forcewake > > during whole initialization sequence in gen6_init_clock_gating() fixes this bug. > > > > References: https://bugs.freedesktop.org/show_bug.cgi?id=54089 > > Signed-off-by: Konstantin Khlebnikov <khlebnikov@openvz.org> > > We already hold an forcewake reference while setting up the rps stuff, > should we maybe hold the forcewake for the entire duration, i.e. grab > it here in clock_gating and release it only in gen6/vlv_enable_rps? > Can you please test that version, too? > > In any case the forcewake grabbing here in the clock gating function > needs a big comment that otherwise setting the MCTL register might > break rc6 entry. It is not clear why the forcewake works, but is easy to imagine one of the operations in that sequence requires the GPU to be awake at the time of programming for it to succeed. MBCTL:EnableBootFetch does seem the most suspicious from its wording in the bspec. I guess all instances of poking this bit should be protected similary (snb, ivb, vlv, hsw). Based on that reasoning and that waking the GPU up here has no negative consequences, and so long as all paths are fixed, I am happy to give this an Acked-by: Chris Wilson <chris@chris-wilson.co.uk> Also, we need to reapply the w/a after a Function Level Reset, in other words we do need to repeat the init_clock_gating after intel_gpu_reset(). -Chris -- Chris Wilson, Intel Open Source Technology Centre ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [PATCH] drm/i915: fix long-standing SNB regression in power consumption after resume @ 2013-07-14 21:48 ` Chris Wilson 0 siblings, 0 replies; 23+ messages in thread From: Chris Wilson @ 2013-07-14 21:48 UTC (permalink / raw) To: Daniel Vetter Cc: David Airlie, intel-gfx, Konstantin Khlebnikov, Linux Kernel Mailing List, dri-devel On Sun, Jul 14, 2013 at 06:52:39PM +0200, Daniel Vetter wrote: > On Sun, Jul 14, 2013 at 6:30 PM, Konstantin Khlebnikov > <khlebnikov@openvz.org> wrote: > > This patch fixes regression in power consumtion of sandy bridge gpu, which > > exists since v3.6 Sometimes after resuming from s2ram gpu starts thinking that > > it's extremely busy. After that it never reaches rc6 state. > > > > Bug was introduce by commit b4ae3f22d238617ca11610b29fde16cf8c0bc6e0 > > ("drm/i915: load boot context at driver init time"). Without documentation > > it's not clear what is happening here, probably this breaks internal state of > > hardware ring buffers and confuses RPS engine. Fortunately keeping forcewake > > during whole initialization sequence in gen6_init_clock_gating() fixes this bug. > > > > References: https://bugs.freedesktop.org/show_bug.cgi?id=54089 > > Signed-off-by: Konstantin Khlebnikov <khlebnikov@openvz.org> > > We already hold an forcewake reference while setting up the rps stuff, > should we maybe hold the forcewake for the entire duration, i.e. grab > it here in clock_gating and release it only in gen6/vlv_enable_rps? > Can you please test that version, too? > > In any case the forcewake grabbing here in the clock gating function > needs a big comment that otherwise setting the MCTL register might > break rc6 entry. It is not clear why the forcewake works, but is easy to imagine one of the operations in that sequence requires the GPU to be awake at the time of programming for it to succeed. MBCTL:EnableBootFetch does seem the most suspicious from its wording in the bspec. I guess all instances of poking this bit should be protected similary (snb, ivb, vlv, hsw). Based on that reasoning and that waking the GPU up here has no negative consequences, and so long as all paths are fixed, I am happy to give this an Acked-by: Chris Wilson <chris@chris-wilson.co.uk> Also, we need to reapply the w/a after a Function Level Reset, in other words we do need to repeat the init_clock_gating after intel_gpu_reset(). -Chris -- Chris Wilson, Intel Open Source Technology Centre ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [PATCH] drm/i915: fix long-standing SNB regression in power consumption after resume 2013-07-14 16:30 [PATCH] drm/i915: fix long-standing SNB regression in power consumption after resume Konstantin Khlebnikov 2013-07-14 16:52 ` Daniel Vetter @ 2013-07-16 6:32 ` Daniel Vetter 2013-07-16 12:06 ` Daniel Vetter 2013-07-17 6:22 ` [PATCH v2] " Konstantin Khlebnikov 2 siblings, 1 reply; 23+ messages in thread From: Daniel Vetter @ 2013-07-16 6:32 UTC (permalink / raw) To: Konstantin Khlebnikov Cc: David Airlie, Daniel Vetter, intel-gfx, linux-kernel, dri-devel, Chris Wilson On Sun, Jul 14, 2013 at 08:30:09PM +0400, Konstantin Khlebnikov wrote: > This patch fixes regression in power consumtion of sandy bridge gpu, which > exists since v3.6 Sometimes after resuming from s2ram gpu starts thinking that > it's extremely busy. After that it never reaches rc6 state. > > Bug was introduce by commit b4ae3f22d238617ca11610b29fde16cf8c0bc6e0 > ("drm/i915: load boot context at driver init time"). Without documentation > it's not clear what is happening here, probably this breaks internal state of > hardware ring buffers and confuses RPS engine. Fortunately keeping forcewake > during whole initialization sequence in gen6_init_clock_gating() fixes this bug. > > References: https://bugs.freedesktop.org/show_bug.cgi?id=54089 > Signed-off-by: Konstantin Khlebnikov <khlebnikov@openvz.org> Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=58971 Tested-by: Alexander Kaltsas <alexkaltsas@gmail.com> Tested-by: rocko <rockorequin@hotmail.com> > --- > drivers/gpu/drm/i915/intel_pm.c | 4 ++++ > 1 file changed, 4 insertions(+) > > diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c > index aa01128..839a43f 100644 > --- a/drivers/gpu/drm/i915/intel_pm.c > +++ b/drivers/gpu/drm/i915/intel_pm.c > @@ -3640,6 +3640,8 @@ static void gen6_init_clock_gating(struct drm_device *dev) > int pipe; > uint32_t dspclk_gate = ILK_VRHUNIT_CLOCK_GATE_DISABLE; > > + gen6_gt_force_wake_get(dev_priv); > + > I915_WRITE(ILK_DSPCLK_GATE_D, dspclk_gate); > > I915_WRITE(ILK_DISPLAY_CHICKEN2, > @@ -3728,6 +3730,8 @@ static void gen6_init_clock_gating(struct drm_device *dev) > cpt_init_clock_gating(dev); > > gen6_check_mch_setup(dev); > + > + gen6_gt_force_wake_put(dev_priv); > } > > static void gen7_setup_fixed_func_scheduler(struct drm_i915_private *dev_priv) > -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [PATCH] drm/i915: fix long-standing SNB regression in power consumption after resume 2013-07-16 6:32 ` Daniel Vetter @ 2013-07-16 12:06 ` Daniel Vetter 0 siblings, 0 replies; 23+ messages in thread From: Daniel Vetter @ 2013-07-16 12:06 UTC (permalink / raw) To: Konstantin Khlebnikov, David Airlie, intel-gfx, linux-kernel, dri-devel, Chris Wilson On Tue, Jul 16, 2013 at 08:32:40AM +0200, Daniel Vetter wrote: > On Sun, Jul 14, 2013 at 08:30:09PM +0400, Konstantin Khlebnikov wrote: > > This patch fixes regression in power consumtion of sandy bridge gpu, which > > exists since v3.6 Sometimes after resuming from s2ram gpu starts thinking that > > it's extremely busy. After that it never reaches rc6 state. > > > > Bug was introduce by commit b4ae3f22d238617ca11610b29fde16cf8c0bc6e0 > > ("drm/i915: load boot context at driver init time"). Without documentation > > it's not clear what is happening here, probably this breaks internal state of > > hardware ring buffers and confuses RPS engine. Fortunately keeping forcewake > > during whole initialization sequence in gen6_init_clock_gating() fixes this bug. > > > > References: https://bugs.freedesktop.org/show_bug.cgi?id=54089 > > Signed-off-by: Konstantin Khlebnikov <khlebnikov@openvz.org> > > Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=58971 > Tested-by: Alexander Kaltsas <alexkaltsas@gmail.com> > Tested-by: rocko <rockorequin@hotmail.com> Tested-by: JohnMB <johnmbryant@sky.com> > > > --- > > drivers/gpu/drm/i915/intel_pm.c | 4 ++++ > > 1 file changed, 4 insertions(+) > > > > diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c > > index aa01128..839a43f 100644 > > --- a/drivers/gpu/drm/i915/intel_pm.c > > +++ b/drivers/gpu/drm/i915/intel_pm.c > > @@ -3640,6 +3640,8 @@ static void gen6_init_clock_gating(struct drm_device *dev) > > int pipe; > > uint32_t dspclk_gate = ILK_VRHUNIT_CLOCK_GATE_DISABLE; > > > > + gen6_gt_force_wake_get(dev_priv); > > + > > I915_WRITE(ILK_DSPCLK_GATE_D, dspclk_gate); > > > > I915_WRITE(ILK_DISPLAY_CHICKEN2, > > @@ -3728,6 +3730,8 @@ static void gen6_init_clock_gating(struct drm_device *dev) > > cpt_init_clock_gating(dev); > > > > gen6_check_mch_setup(dev); > > + > > + gen6_gt_force_wake_put(dev_priv); > > } > > > > static void gen7_setup_fixed_func_scheduler(struct drm_i915_private *dev_priv) > > > > -- > Daniel Vetter > Software Engineer, Intel Corporation > +41 (0) 79 365 57 48 - http://blog.ffwll.ch -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ^ permalink raw reply [flat|nested] 23+ messages in thread
* [PATCH v2] drm/i915: fix long-standing SNB regression in power consumption after resume 2013-07-14 16:30 [PATCH] drm/i915: fix long-standing SNB regression in power consumption after resume Konstantin Khlebnikov 2013-07-14 16:52 ` Daniel Vetter 2013-07-16 6:32 ` Daniel Vetter @ 2013-07-17 6:22 ` Konstantin Khlebnikov 2013-07-17 6:44 ` Daniel Vetter 2013-07-17 14:47 ` Jesse Barnes 2 siblings, 2 replies; 23+ messages in thread From: Konstantin Khlebnikov @ 2013-07-17 6:22 UTC (permalink / raw) To: intel-gfx, linux-kernel Cc: rockorequin, Daniel Vetter, Jesse Barnes, Chris Wilson, alexkaltsas, dri-devel This patch fixes regression in power consumtion of sandy bridge gpu, which exists since v3.6 Sometimes after resuming from s2ram gpu starts thinking that it's extremely busy. After that it never reaches rc6 state. Bug exists since kernel v3.6, commit b4ae3f22d238617ca11610b29fde16cf8c0bc6e0 ("drm/i915: load boot context at driver init time"). For some reason RC6 is already enabled at the beginning of resuming process. Following initliaztion breaks some internal state and confuses RPS engine. This patch disables RC6 at the beginnig of resume and initialization. I've rearranged initialization sequence, because intel_disable_gt_powersave() needs initialized force_wake_get/put and some locks from the dev_priv. References: https://bugs.freedesktop.org/show_bug.cgi?id=54089 References: https://bugzilla.kernel.org/show_bug.cgi?id=58971 Signed-off-by: Konstantin Khlebnikov <khlebnikov@openvz.org> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Jesse Barnes <jbarnes@virtuousgeek.org> --- drivers/gpu/drm/i915/i915_dma.c | 16 ++++++++-------- drivers/gpu/drm/i915/intel_pm.c | 5 +++-- 2 files changed, 11 insertions(+), 10 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c index 3b315ba..d1ee611 100644 --- a/drivers/gpu/drm/i915/i915_dma.c +++ b/drivers/gpu/drm/i915/i915_dma.c @@ -1511,6 +1511,13 @@ int i915_driver_load(struct drm_device *dev, unsigned long flags) dev_priv->dev = dev; dev_priv->info = info; + spin_lock_init(&dev_priv->irq_lock); + spin_lock_init(&dev_priv->gpu_error.lock); + spin_lock_init(&dev_priv->rps.lock); + mutex_init(&dev_priv->dpio_lock); + mutex_init(&dev_priv->rps.hw_lock); + mutex_init(&dev_priv->modeset_restore_lock); + i915_dump_device_info(dev_priv); if (i915_get_bridge_dev(dev)) { @@ -1602,6 +1609,7 @@ int i915_driver_load(struct drm_device *dev, unsigned long flags) intel_irq_init(dev); intel_gt_init(dev); + intel_gt_reset(dev); /* Try to make sure MCHBAR is enabled before poking at it */ intel_setup_mchbar(dev); @@ -1626,14 +1634,6 @@ int i915_driver_load(struct drm_device *dev, unsigned long flags) if (!IS_I945G(dev) && !IS_I945GM(dev)) pci_enable_msi(dev->pdev); - spin_lock_init(&dev_priv->irq_lock); - spin_lock_init(&dev_priv->gpu_error.lock); - spin_lock_init(&dev_priv->rps.lock); - mutex_init(&dev_priv->dpio_lock); - - mutex_init(&dev_priv->rps.hw_lock); - mutex_init(&dev_priv->modeset_restore_lock); - dev_priv->num_plane = 1; if (IS_VALLEYVIEW(dev)) dev_priv->num_plane = 2; diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c index aa01128..b86db1e 100644 --- a/drivers/gpu/drm/i915/intel_pm.c +++ b/drivers/gpu/drm/i915/intel_pm.c @@ -4497,6 +4497,9 @@ void intel_gt_reset(struct drm_device *dev) if (IS_IVYBRIDGE(dev) || IS_HASWELL(dev)) __gen6_gt_force_wake_mt_reset(dev_priv); } + + /* BIOS often leaves RC6 enabled, but disable it for hw init */ + intel_disable_gt_powersave(dev); } void intel_gt_init(struct drm_device *dev) @@ -4505,8 +4508,6 @@ void intel_gt_init(struct drm_device *dev) spin_lock_init(&dev_priv->gt_lock); - intel_gt_reset(dev); - if (IS_VALLEYVIEW(dev)) { dev_priv->gt.force_wake_get = vlv_force_wake_get; dev_priv->gt.force_wake_put = vlv_force_wake_put; ^ permalink raw reply related [flat|nested] 23+ messages in thread
* Re: [PATCH v2] drm/i915: fix long-standing SNB regression in power consumption after resume 2013-07-17 6:22 ` [PATCH v2] " Konstantin Khlebnikov @ 2013-07-17 6:44 ` Daniel Vetter 2013-07-17 14:47 ` Jesse Barnes 1 sibling, 0 replies; 23+ messages in thread From: Daniel Vetter @ 2013-07-17 6:44 UTC (permalink / raw) To: Konstantin Khlebnikov Cc: intel-gfx, linux-kernel, rockorequin, Daniel Vetter, Jesse Barnes, Chris Wilson, alexkaltsas, dri-devel On Wed, Jul 17, 2013 at 10:22:58AM +0400, Konstantin Khlebnikov wrote: > This patch fixes regression in power consumtion of sandy bridge gpu, which > exists since v3.6 Sometimes after resuming from s2ram gpu starts thinking that > it's extremely busy. After that it never reaches rc6 state. > > Bug exists since kernel v3.6, commit b4ae3f22d238617ca11610b29fde16cf8c0bc6e0 > ("drm/i915: load boot context at driver init time"). > > For some reason RC6 is already enabled at the beginning of resuming process. > Following initliaztion breaks some internal state and confuses RPS engine. > This patch disables RC6 at the beginnig of resume and initialization. > > I've rearranged initialization sequence, because intel_disable_gt_powersave() > needs initialized force_wake_get/put and some locks from the dev_priv. > > References: https://bugs.freedesktop.org/show_bug.cgi?id=54089 > References: https://bugzilla.kernel.org/show_bug.cgi?id=58971 > Signed-off-by: Konstantin Khlebnikov <khlebnikov@openvz.org> > Cc: Daniel Vetter <daniel.vetter@ffwll.ch> > Cc: Chris Wilson <chris@chris-wilson.co.uk> > Cc: Jesse Barnes <jbarnes@virtuousgeek.org> lgtm, thanks a lot for digging through this giant mess and figuring out what's actually broken here. Patch is merged to my -fixes queue with a slightly pimped commit message and cc: stable added. Note that there's a small issue with the drps code on ilk, we now write a bogus fstart value as the requested frequency. I'll follow-up with a patch to fix this, but I've figured that merging this one here first for wider testing is more important. Cheers, Daniel > --- > drivers/gpu/drm/i915/i915_dma.c | 16 ++++++++-------- > drivers/gpu/drm/i915/intel_pm.c | 5 +++-- > 2 files changed, 11 insertions(+), 10 deletions(-) > > diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c > index 3b315ba..d1ee611 100644 > --- a/drivers/gpu/drm/i915/i915_dma.c > +++ b/drivers/gpu/drm/i915/i915_dma.c > @@ -1511,6 +1511,13 @@ int i915_driver_load(struct drm_device *dev, unsigned long flags) > dev_priv->dev = dev; > dev_priv->info = info; > > + spin_lock_init(&dev_priv->irq_lock); > + spin_lock_init(&dev_priv->gpu_error.lock); > + spin_lock_init(&dev_priv->rps.lock); > + mutex_init(&dev_priv->dpio_lock); > + mutex_init(&dev_priv->rps.hw_lock); > + mutex_init(&dev_priv->modeset_restore_lock); > + > i915_dump_device_info(dev_priv); > > if (i915_get_bridge_dev(dev)) { > @@ -1602,6 +1609,7 @@ int i915_driver_load(struct drm_device *dev, unsigned long flags) > > intel_irq_init(dev); > intel_gt_init(dev); > + intel_gt_reset(dev); > > /* Try to make sure MCHBAR is enabled before poking at it */ > intel_setup_mchbar(dev); > @@ -1626,14 +1634,6 @@ int i915_driver_load(struct drm_device *dev, unsigned long flags) > if (!IS_I945G(dev) && !IS_I945GM(dev)) > pci_enable_msi(dev->pdev); > > - spin_lock_init(&dev_priv->irq_lock); > - spin_lock_init(&dev_priv->gpu_error.lock); > - spin_lock_init(&dev_priv->rps.lock); > - mutex_init(&dev_priv->dpio_lock); > - > - mutex_init(&dev_priv->rps.hw_lock); > - mutex_init(&dev_priv->modeset_restore_lock); > - > dev_priv->num_plane = 1; > if (IS_VALLEYVIEW(dev)) > dev_priv->num_plane = 2; > diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c > index aa01128..b86db1e 100644 > --- a/drivers/gpu/drm/i915/intel_pm.c > +++ b/drivers/gpu/drm/i915/intel_pm.c > @@ -4497,6 +4497,9 @@ void intel_gt_reset(struct drm_device *dev) > if (IS_IVYBRIDGE(dev) || IS_HASWELL(dev)) > __gen6_gt_force_wake_mt_reset(dev_priv); > } > + > + /* BIOS often leaves RC6 enabled, but disable it for hw init */ > + intel_disable_gt_powersave(dev); > } > > void intel_gt_init(struct drm_device *dev) > @@ -4505,8 +4508,6 @@ void intel_gt_init(struct drm_device *dev) > > spin_lock_init(&dev_priv->gt_lock); > > - intel_gt_reset(dev); > - > if (IS_VALLEYVIEW(dev)) { > dev_priv->gt.force_wake_get = vlv_force_wake_get; > dev_priv->gt.force_wake_put = vlv_force_wake_put; > -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [PATCH v2] drm/i915: fix long-standing SNB regression in power consumption after resume 2013-07-17 6:22 ` [PATCH v2] " Konstantin Khlebnikov @ 2013-07-17 14:47 ` Jesse Barnes 2013-07-17 14:47 ` Jesse Barnes 1 sibling, 0 replies; 23+ messages in thread From: Jesse Barnes @ 2013-07-17 14:47 UTC (permalink / raw) To: Konstantin Khlebnikov Cc: intel-gfx, linux-kernel, rockorequin, Daniel Vetter, Chris Wilson, alexkaltsas, dri-devel On Wed, 17 Jul 2013 10:22:58 +0400 Konstantin Khlebnikov <khlebnikov@openvz.org> wrote: > This patch fixes regression in power consumtion of sandy bridge gpu, which > exists since v3.6 Sometimes after resuming from s2ram gpu starts thinking that > it's extremely busy. After that it never reaches rc6 state. > > Bug exists since kernel v3.6, commit b4ae3f22d238617ca11610b29fde16cf8c0bc6e0 > ("drm/i915: load boot context at driver init time"). > > For some reason RC6 is already enabled at the beginning of resuming process. > Following initliaztion breaks some internal state and confuses RPS engine. > This patch disables RC6 at the beginnig of resume and initialization. > > I've rearranged initialization sequence, because intel_disable_gt_powersave() > needs initialized force_wake_get/put and some locks from the dev_priv. > > References: https://bugs.freedesktop.org/show_bug.cgi?id=54089 > References: https://bugzilla.kernel.org/show_bug.cgi?id=58971 > Signed-off-by: Konstantin Khlebnikov <khlebnikov@openvz.org> > Cc: Daniel Vetter <daniel.vetter@ffwll.ch> > Cc: Chris Wilson <chris@chris-wilson.co.uk> > Cc: Jesse Barnes <jbarnes@virtuousgeek.org> > --- My hero! So the later init change didn't work? Either way, great to have this fix in the tree... thanks again. -- Jesse Barnes, Intel Open Source Technology Center ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [PATCH v2] drm/i915: fix long-standing SNB regression in power consumption after resume @ 2013-07-17 14:47 ` Jesse Barnes 0 siblings, 0 replies; 23+ messages in thread From: Jesse Barnes @ 2013-07-17 14:47 UTC (permalink / raw) To: Konstantin Khlebnikov Cc: rockorequin, Daniel Vetter, intel-gfx, linux-kernel, dri-devel, alexkaltsas On Wed, 17 Jul 2013 10:22:58 +0400 Konstantin Khlebnikov <khlebnikov@openvz.org> wrote: > This patch fixes regression in power consumtion of sandy bridge gpu, which > exists since v3.6 Sometimes after resuming from s2ram gpu starts thinking that > it's extremely busy. After that it never reaches rc6 state. > > Bug exists since kernel v3.6, commit b4ae3f22d238617ca11610b29fde16cf8c0bc6e0 > ("drm/i915: load boot context at driver init time"). > > For some reason RC6 is already enabled at the beginning of resuming process. > Following initliaztion breaks some internal state and confuses RPS engine. > This patch disables RC6 at the beginnig of resume and initialization. > > I've rearranged initialization sequence, because intel_disable_gt_powersave() > needs initialized force_wake_get/put and some locks from the dev_priv. > > References: https://bugs.freedesktop.org/show_bug.cgi?id=54089 > References: https://bugzilla.kernel.org/show_bug.cgi?id=58971 > Signed-off-by: Konstantin Khlebnikov <khlebnikov@openvz.org> > Cc: Daniel Vetter <daniel.vetter@ffwll.ch> > Cc: Chris Wilson <chris@chris-wilson.co.uk> > Cc: Jesse Barnes <jbarnes@virtuousgeek.org> > --- My hero! So the later init change didn't work? Either way, great to have this fix in the tree... thanks again. -- Jesse Barnes, Intel Open Source Technology Center ^ permalink raw reply [flat|nested] 23+ messages in thread
end of thread, other threads:[~2013-07-17 14:54 UTC | newest] Thread overview: 23+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2013-07-14 16:30 [PATCH] drm/i915: fix long-standing SNB regression in power consumption after resume Konstantin Khlebnikov 2013-07-14 16:52 ` Daniel Vetter 2013-07-14 16:52 ` Daniel Vetter 2013-07-14 17:56 ` Konstantin Khlebnikov 2013-07-14 17:56 ` Konstantin Khlebnikov 2013-07-16 6:31 ` Daniel Vetter 2013-07-16 7:34 ` Konstantin Khlebnikov 2013-07-16 7:44 ` Daniel Vetter 2013-07-16 8:31 ` Chris Wilson 2013-07-16 11:13 ` Daniel Vetter 2013-07-16 17:06 ` [Intel-gfx] " Jesse Barnes 2013-07-16 17:06 ` Jesse Barnes 2013-07-16 20:19 ` [Intel-gfx] " Jesse Barnes 2013-07-16 20:43 ` Daniel Vetter 2013-07-16 20:52 ` Jesse Barnes 2013-07-14 21:48 ` Chris Wilson 2013-07-14 21:48 ` Chris Wilson 2013-07-16 6:32 ` Daniel Vetter 2013-07-16 12:06 ` Daniel Vetter 2013-07-17 6:22 ` [PATCH v2] " Konstantin Khlebnikov 2013-07-17 6:44 ` Daniel Vetter 2013-07-17 14:47 ` Jesse Barnes 2013-07-17 14:47 ` Jesse Barnes
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.