* [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.