All of lore.kernel.org
 help / color / mirror / Atom feed
* [RFC PATCH] drm/vblanks: Deal with HW vblank counter resets.
@ 2017-11-07  6:26 Dhinakaran Pandiyan
  2017-11-07  9:07 ` ✗ Fi.CI.BAT: failure for " Patchwork
                   ` (2 more replies)
  0 siblings, 3 replies; 9+ messages in thread
From: Dhinakaran Pandiyan @ 2017-11-07  6:26 UTC (permalink / raw)
  To: intel-gfx; +Cc: Daniel Vetter, Rodrigo Vivi, dri-devel, Dhinakaran Pandiyan

Some HW vblank counters reset due to power management events, which messes
up the vblank counting logic. This leads to screen freezes with user space
waiting on vblank events that may not occur if the counter keeps resetting.

For e.g., After the HW vblank counter resets
[    9.007359] [drm:drm_update_vblank_count [drm]] updating vblank count
on crtc 0: current=297, diff=4294965389, hw=5 hw_last=1912

So, fall back to the SW counter, computed using  vblank timestamps
and frame duration, when the HW counter value deviates by 50% of the SW
computed value.

I have tested this patch on my SKL laptop with i915.enable_psr=1 and it
*seems* to solve the screen freeze issue seen with PSR when DMC is loaded.

Known issues:
1) The 50% deviation margin is arbitrary.
2) "Redundant vblirq ignored" messages are more frequent.

I am sending this as an RFC to get feedback on whether the fall back
approach is sane and if it should be implemented in the core.

Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
---
 drivers/gpu/drm/drm_vblank.c | 26 ++++++++++++++++----------
 1 file changed, 16 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/drm_vblank.c b/drivers/gpu/drm/drm_vblank.c
index 57cc6e37c810..8000aae5f1f7 100644
--- a/drivers/gpu/drm/drm_vblank.c
+++ b/drivers/gpu/drm/drm_vblank.c
@@ -190,11 +190,12 @@ static void drm_update_vblank_count(struct drm_device *dev, unsigned int pipe,
 				    bool in_vblank_irq)
 {
 	struct drm_vblank_crtc *vblank = &dev->vblank[pipe];
-	u32 cur_vblank, diff;
+	u32 cur_vblank;
 	bool rc;
 	ktime_t t_vblank;
 	int count = DRM_TIMESTAMP_MAXRETRIES;
 	int framedur_ns = vblank->framedur_ns;
+	u32 diff = in_vblank_irq ? 1 : 0;
 
 	/*
 	 * Interrupts were disabled prior to this call, so deal with counter
@@ -213,26 +214,31 @@ static void drm_update_vblank_count(struct drm_device *dev, unsigned int pipe,
 		rc = drm_get_last_vbltimestamp(dev, pipe, &t_vblank, in_vblank_irq);
 	} while (cur_vblank != __get_vblank_counter(dev, pipe) && --count > 0);
 
-	if (dev->max_vblank_count != 0) {
-		/* trust the hw counter when it's around */
+	if (dev->max_vblank_count)
 		diff = (cur_vblank - vblank->last) & dev->max_vblank_count;
-	} else if (rc && framedur_ns) {
+
+	if (rc && framedur_ns) {
 		u64 diff_ns = ktime_to_ns(ktime_sub(t_vblank, vblank->time));
+		u32 sw_diff;
 
 		/*
 		 * Figure out how many vblanks we've missed based
 		 * on the difference in the timestamps and the
 		 * frame/field duration.
 		 */
-		diff = DIV_ROUND_CLOSEST_ULL(diff_ns, framedur_ns);
-
-		if (diff == 0 && in_vblank_irq)
+		sw_diff = DIV_ROUND_CLOSEST_ULL(diff_ns, framedur_ns);
+		if (sw_diff == 0 && in_vblank_irq)
 			DRM_DEBUG_VBL("crtc %u: Redundant vblirq ignored."
 				      " diff_ns = %lld, framedur_ns = %d)\n",
 				      pipe, (long long) diff_ns, framedur_ns);
-	} else {
-		/* some kind of default for drivers w/o accurate vbl timestamping */
-		diff = in_vblank_irq ? 1 : 0;
+
+		if (!dev->max_vblank_count)
+			diff = sw_diff;
+		else if (sw_diff && abs(diff - sw_diff) > DIV_ROUND_CLOSEST(sw_diff, 2)) {
+			DRM_DEBUG_VBL("hw vblank counter(%u) deviates from sw (%u)\n",
+				      diff, sw_diff);
+			diff = sw_diff;
+		}
 	}
 
 	/*
-- 
2.11.0

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

^ permalink raw reply related	[flat|nested] 9+ messages in thread

* ✗ Fi.CI.BAT: failure for drm/vblanks: Deal with HW vblank counter resets.
  2017-11-07  6:26 [RFC PATCH] drm/vblanks: Deal with HW vblank counter resets Dhinakaran Pandiyan
@ 2017-11-07  9:07 ` Patchwork
  2017-11-07  9:47 ` [RFC PATCH] " Michel Dänzer
  2017-11-08 12:29 ` ✓ Fi.CI.BAT: success for " Patchwork
  2 siblings, 0 replies; 9+ messages in thread
From: Patchwork @ 2017-11-07  9:07 UTC (permalink / raw)
  To: Dhinakaran Pandiyan; +Cc: intel-gfx

== Series Details ==

Series: drm/vblanks: Deal with HW vblank counter resets.
URL   : https://patchwork.freedesktop.org/series/33316/
State : failure

== Summary ==

Series 33316v1 drm/vblanks: Deal with HW vblank counter resets.
https://patchwork.freedesktop.org/api/1.0/series/33316/revisions/1/mbox/

Test debugfs_test:
        Subgroup read_all_entries:
                pass       -> DMESG-WARN (fi-cfl-s) fdo#103186 +3
Test gem_basic:
        Subgroup bad-close:
                pass       -> DMESG-WARN (fi-cfl-s)
Test gem_exec_fence:
        Subgroup basic-await-default:
                pass       -> FAIL       (fi-glk-dsi)
Test kms_cursor_legacy:
        Subgroup basic-busy-flip-before-cursor-legacy:
                fail       -> PASS       (fi-gdg-551) fdo#102618

fdo#103186 https://bugs.freedesktop.org/show_bug.cgi?id=103186
fdo#102618 https://bugs.freedesktop.org/show_bug.cgi?id=102618

fi-bdw-5557u     total:289  pass:268  dwarn:0   dfail:0   fail:0   skip:21  time:444s
fi-bdw-gvtdvm    total:289  pass:265  dwarn:0   dfail:0   fail:0   skip:24  time:450s
fi-blb-e6850     total:289  pass:223  dwarn:1   dfail:0   fail:0   skip:65  time:381s
fi-bsw-n3050     total:289  pass:243  dwarn:0   dfail:0   fail:0   skip:46  time:544s
fi-bwr-2160      total:289  pass:183  dwarn:0   dfail:0   fail:0   skip:106 time:275s
fi-bxt-dsi       total:289  pass:259  dwarn:0   dfail:0   fail:0   skip:30  time:510s
fi-bxt-j4205     total:289  pass:260  dwarn:0   dfail:0   fail:0   skip:29  time:505s
fi-byt-j1900     total:289  pass:253  dwarn:1   dfail:0   fail:0   skip:35  time:506s
fi-byt-n2820     total:289  pass:249  dwarn:1   dfail:0   fail:0   skip:39  time:484s
fi-cfl-s         total:289  pass:249  dwarn:8   dfail:0   fail:0   skip:32  time:565s
fi-cnl-y         total:289  pass:262  dwarn:0   dfail:0   fail:0   skip:27  time:610s
fi-elk-e7500     total:289  pass:229  dwarn:0   dfail:0   fail:0   skip:60  time:429s
fi-gdg-551       total:289  pass:178  dwarn:1   dfail:0   fail:1   skip:109 time:263s
fi-glk-1         total:289  pass:261  dwarn:0   dfail:0   fail:0   skip:28  time:579s
fi-glk-dsi       total:289  pass:257  dwarn:0   dfail:0   fail:2   skip:30  time:502s
fi-hsw-4770      total:289  pass:262  dwarn:0   dfail:0   fail:0   skip:27  time:431s
fi-hsw-4770r     total:289  pass:262  dwarn:0   dfail:0   fail:0   skip:27  time:434s
fi-ilk-650       total:289  pass:228  dwarn:0   dfail:0   fail:0   skip:61  time:425s
fi-ivb-3520m     total:289  pass:260  dwarn:0   dfail:0   fail:0   skip:29  time:498s
fi-ivb-3770      total:289  pass:260  dwarn:0   dfail:0   fail:0   skip:29  time:464s
fi-kbl-7560u     total:289  pass:270  dwarn:0   dfail:0   fail:0   skip:19  time:576s
fi-kbl-7567u     total:289  pass:269  dwarn:0   dfail:0   fail:0   skip:20  time:484s
fi-kbl-r         total:289  pass:262  dwarn:0   dfail:0   fail:0   skip:27  time:584s
fi-pnv-d510      total:289  pass:222  dwarn:1   dfail:0   fail:0   skip:66  time:560s
fi-skl-6260u     total:289  pass:269  dwarn:0   dfail:0   fail:0   skip:20  time:461s
fi-skl-6600u     total:289  pass:262  dwarn:0   dfail:0   fail:0   skip:27  time:593s
fi-skl-6700hq    total:289  pass:263  dwarn:0   dfail:0   fail:0   skip:26  time:656s
fi-skl-6700k     total:289  pass:265  dwarn:0   dfail:0   fail:0   skip:24  time:528s
fi-skl-6770hq    total:289  pass:269  dwarn:0   dfail:0   fail:0   skip:20  time:500s
fi-skl-gvtdvm    total:289  pass:266  dwarn:0   dfail:0   fail:0   skip:23  time:459s
fi-snb-2520m     total:289  pass:250  dwarn:0   dfail:0   fail:0   skip:39  time:571s
fi-snb-2600      total:289  pass:249  dwarn:0   dfail:0   fail:0   skip:40  time:424s

4295e1469b2127d79d2d02ef34d065509bdded97 drm-tip: 2017y-11m-06d-15h-35m-57s UTC integration manifest
d25a7d02cb8e drm/vblanks: Deal with HW vblank counter resets.

== Logs ==

For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_6980/
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [RFC PATCH] drm/vblanks: Deal with HW vblank counter resets.
  2017-11-07  6:26 [RFC PATCH] drm/vblanks: Deal with HW vblank counter resets Dhinakaran Pandiyan
  2017-11-07  9:07 ` ✗ Fi.CI.BAT: failure for " Patchwork
@ 2017-11-07  9:47 ` Michel Dänzer
  2017-11-07 10:50   ` Ville Syrjälä
  2017-11-07 12:39   ` Daniel Vetter
  2017-11-08 12:29 ` ✓ Fi.CI.BAT: success for " Patchwork
  2 siblings, 2 replies; 9+ messages in thread
From: Michel Dänzer @ 2017-11-07  9:47 UTC (permalink / raw)
  To: Dhinakaran Pandiyan; +Cc: Daniel Vetter, intel-gfx, dri-devel, Rodrigo Vivi

On 07/11/17 07:26 AM, Dhinakaran Pandiyan wrote:
> Some HW vblank counters reset due to power management events, which messes
> up the vblank counting logic. This leads to screen freezes with user space
> waiting on vblank events that may not occur if the counter keeps resetting.
> 
> For e.g., After the HW vblank counter resets
> [    9.007359] [drm:drm_update_vblank_count [drm]] updating vblank count
> on crtc 0: current=297, diff=4294965389, hw=5 hw_last=1912
> 
> So, fall back to the SW counter, computed using  vblank timestamps
> and frame duration, when the HW counter value deviates by 50% of the SW
> computed value.
> 
> I have tested this patch on my SKL laptop with i915.enable_psr=1 and it
> *seems* to solve the screen freeze issue seen with PSR when DMC is loaded.
> 
> Known issues:
> 1) The 50% deviation margin is arbitrary.
> 2) "Redundant vblirq ignored" messages are more frequent.
> 
> I am sending this as an RFC to get feedback on whether the fall back
> approach is sane and if it should be implemented in the core.

Is there no way for the driver to know under which circumstances the
reset to 0 might happen? If there is, maybe it could be solved by
calling drm_crtc_vblank_off() before it might happen and
drm_crtc_vblank_on() after it might have happened.

Otherwise, might it be better not to use the HW counter at all when it's
known not to be reliable?


-- 
Earthling Michel Dänzer               |               http://www.amd.com
Libre software enthusiast             |             Mesa and X developer
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [RFC PATCH] drm/vblanks: Deal with HW vblank counter resets.
  2017-11-07  9:47 ` [RFC PATCH] " Michel Dänzer
@ 2017-11-07 10:50   ` Ville Syrjälä
  2017-11-07 10:55     ` Michel Dänzer
  2017-11-07 12:39   ` Daniel Vetter
  1 sibling, 1 reply; 9+ messages in thread
From: Ville Syrjälä @ 2017-11-07 10:50 UTC (permalink / raw)
  To: Michel Dänzer
  Cc: Daniel Vetter, intel-gfx, Dhinakaran Pandiyan, dri-devel, Rodrigo Vivi

On Tue, Nov 07, 2017 at 10:47:00AM +0100, Michel Dänzer wrote:
> On 07/11/17 07:26 AM, Dhinakaran Pandiyan wrote:
> > Some HW vblank counters reset due to power management events, which messes
> > up the vblank counting logic. This leads to screen freezes with user space
> > waiting on vblank events that may not occur if the counter keeps resetting.
> > 
> > For e.g., After the HW vblank counter resets
> > [    9.007359] [drm:drm_update_vblank_count [drm]] updating vblank count
> > on crtc 0: current=297, diff=4294965389, hw=5 hw_last=1912
> > 
> > So, fall back to the SW counter, computed using  vblank timestamps
> > and frame duration, when the HW counter value deviates by 50% of the SW
> > computed value.
> > 
> > I have tested this patch on my SKL laptop with i915.enable_psr=1 and it
> > *seems* to solve the screen freeze issue seen with PSR when DMC is loaded.
> > 
> > Known issues:
> > 1) The 50% deviation margin is arbitrary.
> > 2) "Redundant vblirq ignored" messages are more frequent.
> > 
> > I am sending this as an RFC to get feedback on whether the fall back
> > approach is sane and if it should be implemented in the core.
> 
> Is there no way for the driver to know under which circumstances the
> reset to 0 might happen? If there is, maybe it could be solved by
> calling drm_crtc_vblank_off() before it might happen and
> drm_crtc_vblank_on() after it might have happened.
> 
> Otherwise, might it be better not to use the HW counter at all when it's
> known not to be reliable?

Yeah, I think we could just avoid using the HW counter whenever there's
a possibility of PSR being used on the crtc.

Assuming we still want to use the HW counter on crtcs that can't do PSR,
we're going to need some kind of per-crtc mechanism to tell drm_vblank.c
which method to use. hwmode.private_flags is one option. We already use
it for choosing between the scanline counter and hardware timestamps when
calculating the scanout position. But in this case the flag wouldn't be
exactly private since drm_vblank.c would have to know about it as well.
If that is deemed to be a problem, then we might just need to add a bool
to struct drm_vblank_crtc to indicate that the hw counter is good, or
maybe even move the dev->max_vblank_count to live inside
struct drm_vblank_crtc.

-- 
Ville Syrjälä
Intel OTC
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [RFC PATCH] drm/vblanks: Deal with HW vblank counter resets.
  2017-11-07 10:50   ` Ville Syrjälä
@ 2017-11-07 10:55     ` Michel Dänzer
  2017-11-07 11:26       ` Ville Syrjälä
  0 siblings, 1 reply; 9+ messages in thread
From: Michel Dänzer @ 2017-11-07 10:55 UTC (permalink / raw)
  To: Ville Syrjälä
  Cc: Daniel Vetter, intel-gfx, Dhinakaran Pandiyan, dri-devel, Rodrigo Vivi

On 07/11/17 11:50 AM, Ville Syrjälä wrote:
> On Tue, Nov 07, 2017 at 10:47:00AM +0100, Michel Dänzer wrote:
>> On 07/11/17 07:26 AM, Dhinakaran Pandiyan wrote:
>>> Some HW vblank counters reset due to power management events, which messes
>>> up the vblank counting logic. This leads to screen freezes with user space
>>> waiting on vblank events that may not occur if the counter keeps resetting.
>>>
>>> For e.g., After the HW vblank counter resets
>>> [    9.007359] [drm:drm_update_vblank_count [drm]] updating vblank count
>>> on crtc 0: current=297, diff=4294965389, hw=5 hw_last=1912
>>>
>>> So, fall back to the SW counter, computed using  vblank timestamps
>>> and frame duration, when the HW counter value deviates by 50% of the SW
>>> computed value.
>>>
>>> I have tested this patch on my SKL laptop with i915.enable_psr=1 and it
>>> *seems* to solve the screen freeze issue seen with PSR when DMC is loaded.
>>>
>>> Known issues:
>>> 1) The 50% deviation margin is arbitrary.
>>> 2) "Redundant vblirq ignored" messages are more frequent.
>>>
>>> I am sending this as an RFC to get feedback on whether the fall back
>>> approach is sane and if it should be implemented in the core.
>>
>> Is there no way for the driver to know under which circumstances the
>> reset to 0 might happen? If there is, maybe it could be solved by
>> calling drm_crtc_vblank_off() before it might happen and
>> drm_crtc_vblank_on() after it might have happened.
>>
>> Otherwise, might it be better not to use the HW counter at all when it's
>> known not to be reliable?
> 
> Yeah, I think we could just avoid using the HW counter whenever there's
> a possibility of PSR being used on the crtc.
> 
> Assuming we still want to use the HW counter on crtcs that can't do PSR,
> we're going to need some kind of per-crtc mechanism to tell drm_vblank.c
> which method to use. hwmode.private_flags is one option. We already use
> it for choosing between the scanline counter and hardware timestamps when
> calculating the scanout position. But in this case the flag wouldn't be
> exactly private since drm_vblank.c would have to know about it as well.
> If that is deemed to be a problem, then we might just need to add a bool
> to struct drm_vblank_crtc to indicate that the hw counter is good, or
> maybe even move the dev->max_vblank_count to live inside
> struct drm_vblank_crtc.

Or just allow setting struct drm_vblank_crtc's get_vblank_counter member
to NULL?


-- 
Earthling Michel Dänzer               |               http://www.amd.com
Libre software enthusiast             |             Mesa and X developer
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [RFC PATCH] drm/vblanks: Deal with HW vblank counter resets.
  2017-11-07 10:55     ` Michel Dänzer
@ 2017-11-07 11:26       ` Ville Syrjälä
  0 siblings, 0 replies; 9+ messages in thread
From: Ville Syrjälä @ 2017-11-07 11:26 UTC (permalink / raw)
  To: Michel Dänzer
  Cc: Daniel Vetter, intel-gfx, Dhinakaran Pandiyan, dri-devel, Rodrigo Vivi

On Tue, Nov 07, 2017 at 11:55:44AM +0100, Michel Dänzer wrote:
> On 07/11/17 11:50 AM, Ville Syrjälä wrote:
> > On Tue, Nov 07, 2017 at 10:47:00AM +0100, Michel Dänzer wrote:
> >> On 07/11/17 07:26 AM, Dhinakaran Pandiyan wrote:
> >>> Some HW vblank counters reset due to power management events, which messes
> >>> up the vblank counting logic. This leads to screen freezes with user space
> >>> waiting on vblank events that may not occur if the counter keeps resetting.
> >>>
> >>> For e.g., After the HW vblank counter resets
> >>> [    9.007359] [drm:drm_update_vblank_count [drm]] updating vblank count
> >>> on crtc 0: current=297, diff=4294965389, hw=5 hw_last=1912
> >>>
> >>> So, fall back to the SW counter, computed using  vblank timestamps
> >>> and frame duration, when the HW counter value deviates by 50% of the SW
> >>> computed value.
> >>>
> >>> I have tested this patch on my SKL laptop with i915.enable_psr=1 and it
> >>> *seems* to solve the screen freeze issue seen with PSR when DMC is loaded.
> >>>
> >>> Known issues:
> >>> 1) The 50% deviation margin is arbitrary.
> >>> 2) "Redundant vblirq ignored" messages are more frequent.
> >>>
> >>> I am sending this as an RFC to get feedback on whether the fall back
> >>> approach is sane and if it should be implemented in the core.
> >>
> >> Is there no way for the driver to know under which circumstances the
> >> reset to 0 might happen? If there is, maybe it could be solved by
> >> calling drm_crtc_vblank_off() before it might happen and
> >> drm_crtc_vblank_on() after it might have happened.
> >>
> >> Otherwise, might it be better not to use the HW counter at all when it's
> >> known not to be reliable?
> > 
> > Yeah, I think we could just avoid using the HW counter whenever there's
> > a possibility of PSR being used on the crtc.
> > 
> > Assuming we still want to use the HW counter on crtcs that can't do PSR,
> > we're going to need some kind of per-crtc mechanism to tell drm_vblank.c
> > which method to use. hwmode.private_flags is one option. We already use
> > it for choosing between the scanline counter and hardware timestamps when
> > calculating the scanout position. But in this case the flag wouldn't be
> > exactly private since drm_vblank.c would have to know about it as well.
> > If that is deemed to be a problem, then we might just need to add a bool
> > to struct drm_vblank_crtc to indicate that the hw counter is good, or
> > maybe even move the dev->max_vblank_count to live inside
> > struct drm_vblank_crtc.
> 
> Or just allow setting struct drm_vblank_crtc's get_vblank_counter member
> to NULL?

Looks like that's actually under drm_crtc_funcs. I'm thinking we want
to keep that as const. Not sure we want to add a third way for drivers
to provide a .get_vblank_counter() hook (the second one being the
old drm_driver.get_vblank_counter() hook, which i915 is still using
actually).

-- 
Ville Syrjälä
Intel OTC
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [RFC PATCH] drm/vblanks: Deal with HW vblank counter resets.
  2017-11-07  9:47 ` [RFC PATCH] " Michel Dänzer
  2017-11-07 10:50   ` Ville Syrjälä
@ 2017-11-07 12:39   ` Daniel Vetter
  2017-11-07 19:14     ` Pandiyan, Dhinakaran
  1 sibling, 1 reply; 9+ messages in thread
From: Daniel Vetter @ 2017-11-07 12:39 UTC (permalink / raw)
  To: Michel Dänzer
  Cc: Daniel Vetter, intel-gfx, Dhinakaran Pandiyan, dri-devel, Rodrigo Vivi

On Tue, Nov 07, 2017 at 10:47:00AM +0100, Michel Dänzer wrote:
> On 07/11/17 07:26 AM, Dhinakaran Pandiyan wrote:
> > Some HW vblank counters reset due to power management events, which messes
> > up the vblank counting logic. This leads to screen freezes with user space
> > waiting on vblank events that may not occur if the counter keeps resetting.
> > 
> > For e.g., After the HW vblank counter resets
> > [    9.007359] [drm:drm_update_vblank_count [drm]] updating vblank count
> > on crtc 0: current=297, diff=4294965389, hw=5 hw_last=1912
> > 
> > So, fall back to the SW counter, computed using  vblank timestamps
> > and frame duration, when the HW counter value deviates by 50% of the SW
> > computed value.
> > 
> > I have tested this patch on my SKL laptop with i915.enable_psr=1 and it
> > *seems* to solve the screen freeze issue seen with PSR when DMC is loaded.
> > 
> > Known issues:
> > 1) The 50% deviation margin is arbitrary.
> > 2) "Redundant vblirq ignored" messages are more frequent.
> > 
> > I am sending this as an RFC to get feedback on whether the fall back
> > approach is sane and if it should be implemented in the core.
> 
> Is there no way for the driver to know under which circumstances the
> reset to 0 might happen? If there is, maybe it could be solved by
> calling drm_crtc_vblank_off() before it might happen and
> drm_crtc_vblank_on() after it might have happened.
> 
> Otherwise, might it be better not to use the HW counter at all when it's
> known not to be reliable?

We know when it happens, so agreed this isn't a good/workable solution
really. I thought the plan to fix that was to fix up our runtime pm to
make sure the vblank counter doesn't get reset while we need it (pending
flip or vblank). And in-between (when the vblank counter is totally off)
we'd fix any mismatch by adjusting the sw vblank counter with an explicit
call (where we can use the elapsed time to estimate the elapsed vblank
counts well enough). Adding a magic hack like this doesn't sound like a
good plan to me indeed.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [RFC PATCH] drm/vblanks: Deal with HW vblank counter resets.
  2017-11-07 12:39   ` Daniel Vetter
@ 2017-11-07 19:14     ` Pandiyan, Dhinakaran
  0 siblings, 0 replies; 9+ messages in thread
From: Pandiyan, Dhinakaran @ 2017-11-07 19:14 UTC (permalink / raw)
  To: daniel; +Cc: daniel.vetter, michel, dri-devel, Vivi, Rodrigo, intel-gfx

On Tue, 2017-11-07 at 13:39 +0100, Daniel Vetter wrote:
> On Tue, Nov 07, 2017 at 10:47:00AM +0100, Michel Dänzer wrote:
> > On 07/11/17 07:26 AM, Dhinakaran Pandiyan wrote:
> > > Some HW vblank counters reset due to power management events, which messes
> > > up the vblank counting logic. This leads to screen freezes with user space
> > > waiting on vblank events that may not occur if the counter keeps resetting.
> > > 
> > > For e.g., After the HW vblank counter resets
> > > [    9.007359] [drm:drm_update_vblank_count [drm]] updating vblank count
> > > on crtc 0: current=297, diff=4294965389, hw=5 hw_last=1912
> > > 
> > > So, fall back to the SW counter, computed using  vblank timestamps
> > > and frame duration, when the HW counter value deviates by 50% of the SW
> > > computed value.
> > > 
> > > I have tested this patch on my SKL laptop with i915.enable_psr=1 and it
> > > *seems* to solve the screen freeze issue seen with PSR when DMC is loaded.
> > > 
> > > Known issues:
> > > 1) The 50% deviation margin is arbitrary.
> > > 2) "Redundant vblirq ignored" messages are more frequent.
> > > 
> > > I am sending this as an RFC to get feedback on whether the fall back
> > > approach is sane and if it should be implemented in the core.
> > 
> > Is there no way for the driver to know under which circumstances the
> > reset to 0 might happen? 

Not precisely, but the driver does need to allow the firmware to go into
lower power states.

> If there is, maybe it could be solved by
> > calling drm_crtc_vblank_off() before it might happen and
> > drm_crtc_vblank_on() after it might have happened.
> > 
> > Otherwise, might it be better not to use the HW counter at all when it's
> > known not to be reliable?
> 
> We know when it happens, so agreed this isn't a good/workable solution
> really. I thought the plan to fix that was to fix up our runtime pm to
> make sure the vblank counter doesn't get reset while we need it (pending
> flip or vblank). And in-between (when the vblank counter is totally off)
> we'd fix any mismatch by adjusting the sw vblank counter with an explicit
> call (where we can use the elapsed time to estimate the elapsed vblank
> counts well enough). Adding a magic hack like this doesn't sound like a
> good plan to me indeed.
> -Daniel

Thanks for the feedback, I wasn't aware of an agreed plan. I just went
through patchwork history now and realized that the full-time SW counter
approach was tried earlier, but not much information on why it was
abandoned.

Allowing runtime PM (PSR + DMC) to do it's job while letting the SW
estimate vblanks if the hardware counter is unreliable didn't seem like
a terrible plan. It could save more power fwiw. But, I understand your
concerns, will see what I can do.

-DK
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

^ permalink raw reply	[flat|nested] 9+ messages in thread

* ✓ Fi.CI.BAT: success for drm/vblanks: Deal with HW vblank counter resets.
  2017-11-07  6:26 [RFC PATCH] drm/vblanks: Deal with HW vblank counter resets Dhinakaran Pandiyan
  2017-11-07  9:07 ` ✗ Fi.CI.BAT: failure for " Patchwork
  2017-11-07  9:47 ` [RFC PATCH] " Michel Dänzer
@ 2017-11-08 12:29 ` Patchwork
  2 siblings, 0 replies; 9+ messages in thread
From: Patchwork @ 2017-11-08 12:29 UTC (permalink / raw)
  To: Pandiyan, Dhinakaran; +Cc: intel-gfx

== Series Details ==

Series: drm/vblanks: Deal with HW vblank counter resets.
URL   : https://patchwork.freedesktop.org/series/33316/
State : success

== Summary ==

Series 33316v1 drm/vblanks: Deal with HW vblank counter resets.
https://patchwork.freedesktop.org/api/1.0/series/33316/revisions/1/mbox/

Test debugfs_test:
        Subgroup read_all_entries:
                pass       -> DMESG-WARN (fi-cfl-s) fdo#103186 +4
Test kms_cursor_legacy:
        Subgroup basic-busy-flip-before-cursor-legacy:
                fail       -> PASS       (fi-gdg-551) fdo#102618

fdo#103186 https://bugs.freedesktop.org/show_bug.cgi?id=103186
fdo#102618 https://bugs.freedesktop.org/show_bug.cgi?id=102618

fi-bdw-5557u     total:289  pass:268  dwarn:0   dfail:0   fail:0   skip:21  time:444s
fi-bdw-gvtdvm    total:289  pass:265  dwarn:0   dfail:0   fail:0   skip:24  time:450s
fi-blb-e6850     total:289  pass:223  dwarn:1   dfail:0   fail:0   skip:65  time:381s
fi-bsw-n3050     total:289  pass:243  dwarn:0   dfail:0   fail:0   skip:46  time:544s
fi-bwr-2160      total:289  pass:183  dwarn:0   dfail:0   fail:0   skip:106 time:275s
fi-bxt-dsi       total:289  pass:259  dwarn:0   dfail:0   fail:0   skip:30  time:510s
fi-bxt-j4205     total:289  pass:260  dwarn:0   dfail:0   fail:0   skip:29  time:505s
fi-byt-j1900     total:289  pass:253  dwarn:1   dfail:0   fail:0   skip:35  time:506s
fi-byt-n2820     total:289  pass:249  dwarn:1   dfail:0   fail:0   skip:39  time:484s
fi-cfl-s         total:289  pass:249  dwarn:8   dfail:0   fail:0   skip:32  time:565s
fi-elk-e7500     total:289  pass:229  dwarn:0   dfail:0   fail:0   skip:60  time:429s
fi-gdg-551       total:289  pass:178  dwarn:1   dfail:0   fail:1   skip:109 time:263s
fi-glk-1         total:289  pass:261  dwarn:0   dfail:0   fail:0   skip:28  time:579s
fi-hsw-4770      total:289  pass:262  dwarn:0   dfail:0   fail:0   skip:27  time:431s
fi-hsw-4770r     total:289  pass:262  dwarn:0   dfail:0   fail:0   skip:27  time:434s
fi-ilk-650       total:289  pass:228  dwarn:0   dfail:0   fail:0   skip:61  time:425s
fi-ivb-3520m     total:289  pass:260  dwarn:0   dfail:0   fail:0   skip:29  time:498s
fi-ivb-3770      total:289  pass:260  dwarn:0   dfail:0   fail:0   skip:29  time:464s
fi-kbl-7560u     total:289  pass:270  dwarn:0   dfail:0   fail:0   skip:19  time:576s
fi-kbl-7567u     total:289  pass:269  dwarn:0   dfail:0   fail:0   skip:20  time:484s
fi-kbl-r         total:289  pass:262  dwarn:0   dfail:0   fail:0   skip:27  time:584s
fi-pnv-d510      total:289  pass:222  dwarn:1   dfail:0   fail:0   skip:66  time:560s
fi-skl-6260u     total:289  pass:269  dwarn:0   dfail:0   fail:0   skip:20  time:461s
fi-skl-6600u     total:289  pass:262  dwarn:0   dfail:0   fail:0   skip:27  time:593s
fi-skl-6700hq    total:289  pass:263  dwarn:0   dfail:0   fail:0   skip:26  time:656s
fi-skl-6700k     total:289  pass:265  dwarn:0   dfail:0   fail:0   skip:24  time:528s
fi-skl-6770hq    total:289  pass:269  dwarn:0   dfail:0   fail:0   skip:20  time:500s
fi-skl-gvtdvm    total:289  pass:266  dwarn:0   dfail:0   fail:0   skip:23  time:459s
fi-snb-2520m     total:289  pass:250  dwarn:0   dfail:0   fail:0   skip:39  time:571s
fi-snb-2600      total:289  pass:249  dwarn:0   dfail:0   fail:0   skip:40  time:424s
Blacklisted hosts:
fi-cnl-y         total:289  pass:262  dwarn:0   dfail:0   fail:0   skip:27  time:610s
fi-glk-dsi       total:289  pass:257  dwarn:0   dfail:0   fail:2   skip:30  time:502s

4295e1469b2127d79d2d02ef34d065509bdded97 drm-tip: 2017y-11m-06d-15h-35m-57s UTC integration manifest
d25a7d02cb8e drm/vblanks: Deal with HW vblank counter resets.

== Logs ==

For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_6980/
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

^ permalink raw reply	[flat|nested] 9+ messages in thread

end of thread, other threads:[~2017-11-08 12:29 UTC | newest]

Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2017-11-07  6:26 [RFC PATCH] drm/vblanks: Deal with HW vblank counter resets Dhinakaran Pandiyan
2017-11-07  9:07 ` ✗ Fi.CI.BAT: failure for " Patchwork
2017-11-07  9:47 ` [RFC PATCH] " Michel Dänzer
2017-11-07 10:50   ` Ville Syrjälä
2017-11-07 10:55     ` Michel Dänzer
2017-11-07 11:26       ` Ville Syrjälä
2017-11-07 12:39   ` Daniel Vetter
2017-11-07 19:14     ` Pandiyan, Dhinakaran
2017-11-08 12:29 ` ✓ Fi.CI.BAT: success for " Patchwork

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.