drm/i915: update last_vblank when disabling the power well
Subsystems (2)
PATCH 1/1 drm/i915: update last_vblank when disabling the power well
From: Paulo Zanoni <[email protected]>
The DRM layer keeps track of our vblanks and it assumes our vblank counters only go back to zero when they overflow. The problem is that when we disable the power well our counters also go to zero, but it doesn't mean they did overflow. So on this patch we grab the lock and update last_vblank so the DRM layer won't think our counters overflowed.
This patch fixes the following intel-gpu-tools test:
./kms_flip --run-subtest blocking-absolute-wf_vblank
Regression introduced by the following commit:
commit bf51d5e2cda5d36d98e4b46ac7fca9461e512c41
Author: Paulo Zanoni <[email protected]> Date: Wed Jul 3 17:12:13 2013 -0300
drm/i915: switch disable_power_well default value to 1
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=66808
--- drivers/gpu/drm/i915/intel_pm.c | 13 +++++++++++++ 1 file changed, 13 insertions(+)
Tested on -nightly, but applies cleanly to -fixes.
I recognize this patch is not really beautiful, I'm open to suggestions.
drivers/gpu/drm/i915/intel_pm.c +13 -0
@@ -5060,8 +5060,21 @@ static void __intel_set_power_well(struct drm_device *dev, bool enable) } }else {if (enable_requested) { +unsigned long irqflags; +enum pipe p; +I915_WRITE (HSW_PWR_WELL_DRIVER ,0 ); +POSTING_READ (HSW_PWR_WELL_DRIVER );DRM_DEBUG_KMS ("Requesting to disable the power well\n" ); + +/* After this, the registers on the pipes that are part +* of the power well will become zero, so we have to +* adjust our counters according to that. */ +spin_lock_irqsave (&dev->vbl_lock, irqflags); +for_each_pipe (p) +if (p !=PIPE_A ) + dev->last_vblank[p] =0 ; +spin_unlock_irqrestore (&dev->vbl_lock, irqflags); } } }
Signature · 1 line
1.8.1.2
Quoted 20 lines · Paulo Zanoni
From: Paulo Zanoni <[email protected]>
The DRM layer keeps track of our vblanks and it assumes our vblank counters only go back to zero when they overflow. The problem is that when we disable the power well our counters also go to zero, but it doesn't mean they did overflow. So on this patch we grab the lock and update
last_vblankso the DRM layer won't think our counters overflowed.This patch fixes the following intel-gpu-tools test:
./kms_flip --run-subtest blocking-absolute-wf_vblankRegression introduced by the following commit:
commit
bf51d5e2cda5d36d98e4b46ac7fca9461e512c41Author: Paulo Zanoni <[email protected]> Date: Wed Jul 3 17:12:13 2013 -0300drm/i915: switch
disable_power_welldefault value to 1Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=66808
Quoted 8 lines
Signed-off-by Paulo Zanoni <[email protected]>--- drivers/gpu/drm/i915/intel_pm.c | 13 +++++++++++++ 1 file changed, 13 insertions(+)Tested on -nightly, but applies cleanly to -fixes.
I recognize this patch is not really beautiful, I'm open to suggestions.
Saving and restoring each enabled pipes' framecounter across the powerwell would look neater than messing around with the drm core structs. -Chris
Signature · 1 line
Chris Wilson, Intel Open Source Technology Centre
2013/7/23 Chris Wilson <[email protected]>:
Quoted 26 lines · Paulo Zanoni
Quoted 25 lines
From: Paulo Zanoni <[email protected]>
The DRM layer keeps track of our vblanks and it assumes our vblank counters only go back to zero when they overflow. The problem is that when we disable the power well our counters also go to zero, but it doesn't mean they did overflow. So on this patch we grab the lock and update
last_vblankso the DRM layer won't think our counters overflowed.This patch fixes the following intel-gpu-tools test:
./kms_flip --run-subtest blocking-absolute-wf_vblankRegression introduced by the following commit:
commit
bf51d5e2cda5d36d98e4b46ac7fca9461e512c41Author: Paulo Zanoni <[email protected]> Date: Wed Jul 3 17:12:13 2013 -0300drm/i915: switch
disable_power_welldefault value to 1Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=66808
Signed-off-by Paulo Zanoni <[email protected]>--- drivers/gpu/drm/i915/intel_pm.c | 13 +++++++++++++ 1 file changed, 13 insertions(+)
Quoted 6 lines
Quoted 3 lines
Tested on -nightly, but applies cleanly to -fixes.
I recognize this patch is not really beautiful, I'm open to suggestions.
Saving and restoring each enabled pipes' framecounter across the powerwell would look neater than messing around with the drm core structs.
The registers are read-only, so we can't save/restore them.
Quoted 4 lines
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
Signature · 1 line
Paulo Zanoni
2013/7/23 Paulo Zanoni <[email protected]>:
Quoted 27 lines
2013/7/23 Chris Wilson <[email protected]>:
Quoted 26 lines · Paulo Zanoni
Quoted 25 lines
From: Paulo Zanoni <[email protected]>
The DRM layer keeps track of our vblanks and it assumes our vblank counters only go back to zero when they overflow. The problem is that when we disable the power well our counters also go to zero, but it doesn't mean they did overflow. So on this patch we grab the lock and update
last_vblankso the DRM layer won't think our counters overflowed.This patch fixes the following intel-gpu-tools test:
./kms_flip --run-subtest blocking-absolute-wf_vblankRegression introduced by the following commit:
commit
bf51d5e2cda5d36d98e4b46ac7fca9461e512c41Author: Paulo Zanoni <[email protected]> Date: Wed Jul 3 17:12:13 2013 -0300drm/i915: switch
disable_power_welldefault value to 1Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=66808
Signed-off-by Paulo Zanoni <[email protected]>--- drivers/gpu/drm/i915/intel_pm.c | 13 +++++++++++++ 1 file changed, 13 insertions(+)
Quoted 8 lines
Quoted 6 lines
Quoted 3 lines
Tested on -nightly, but applies cleanly to -fixes.
I recognize this patch is not really beautiful, I'm open to suggestions.
Saving and restoring each enabled pipes' framecounter across the powerwell would look neater than messing around with the drm core structs.
The registers are read-only, so we can't save/restore them.
Ping? This is for -fixes.
Quoted 11 lines
Quoted 6 lines
-Chris
--
Chris Wilson, Intel Open Source Technology Centre--
Paulo Zanoni
Signature · 1 line
Paulo Zanoni
Quoted 30 lines · Paulo Zanoni
2013/7/23 Paulo Zanoni <[email protected]>:
Quoted 29 lines
2013/7/23 Chris Wilson <[email protected]>:
Quoted 28 lines · Paulo Zanoni
Quoted 27 lines
From: Paulo Zanoni <[email protected]>
The DRM layer keeps track of our vblanks and it assumes our vblank counters only go back to zero when they overflow. The problem is that when we disable the power well our counters also go to zero, but it doesn't mean they did overflow. So on this patch we grab the lock and update
last_vblankso the DRM layer won't think our counters overflowed.This patch fixes the following intel-gpu-tools test:
./kms_flip --run-subtest blocking-absolute-wf_vblankRegression introduced by the following commit:
commit
bf51d5e2cda5d36d98e4b46ac7fca9461e512c41Author: Paulo Zanoni <[email protected]> Date: Wed Jul 3 17:12:13 2013 -0300drm/i915: switch
disable_power_welldefault value to 1Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=66808
Signed-off-by Paulo Zanoni <[email protected]>--- drivers/gpu/drm/i915/intel_pm.c | 13 +++++++++++++ 1 file changed, 13 insertions(+)Tested on -nightly, but applies cleanly to -fixes.
Quoted 8 lines
Quoted 6 lines
Quoted 4 lines
Quoted 1 line
I recognize this patch is not really beautiful, I'm open to suggestions.
Saving and restoring each enabled pipes' framecounter across the powerwell would look neater than messing around with the drm core structs.
The registers are read-only, so we can't save/restore them.
Ping? This is for -fixes.
Oops, I've thought I've dropped my bikeshed on this but seems I've gone on vacation before doing that ;-)
I think we should do this vblank counter resetting in general in the drm vblank core in drm_vblank_post_modeset, instead of frobbing around in the implementation details from our driver code. But for -fixes this much more minimal approach looks better. I've added a FIXME comment and merged the patch, but looking into this for -next might be good.
Cheers, Daniel
Signature · 3 lines
Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch