On 01/21/2016 04:43 AM, Michel Dänzer wrote:
On 21.01.2016 05:32, Mario Kleiner wrote:
So the problem is that AMDs hardware frame counters reset to
zero during a modeset. The old DRM code dealt with drivers doing that by
keeping vblank irqs enabled during modesets and incrementing vblank
count by one during each vblank irq, i think that's what
drm_vblank_pre_modeset() and drm_vblank_post_modeset() were meant for.
Right, looks like there's been a regression breaking this. I suspect the
problem is that vblank->last isn't getting updated from
drm_vblank_post_modeset. Not sure which change broke that though, or how
to fix it. Ville?
The whole logic has changed and the software counter updates are now
driven all the time by the hw counter.
BTW, I'm seeing a similar issue with drm_vblank_on/off as well, which
exposed the bug fixed by 209e4dbc ("drm/vblank: Use u32 consistently for
vblank counters"). I've been meaning to track that down since then; one
of these days hopefully, but if anybody has any ideas offhand...
I spent the last few hours reading through the drm and radeon code and i
think what should probably work is to replace the
drm_vblank_pre/post_modeset calls in radeon/amdgpu by drm_vblank_off/on
calls. These are apparently meant for drivers whose hw counters reset
during modeset, and seem to reinitialize stuff properly and release
clients queued vblank events to avoid blocking - not tested so far, just
looked at the code.
Once drm_vblank_off is called, drm_vblank_get will no-op and return an
error, so clients can't enable vblank irqs during the modeset - pageflip
ioctl and waitvblank ioctl would fail while a modeset happens -
hopefully userspace handles this correctly everywhere.
It would also cause radeons power management to not sync its actions to
vblank if it would get invoked during a modeset, but that seems to be
handled by a 200 msec timeout and hopefully only cause visual glitches -
or invisible glitches while the crtc is blanked during modeset?
There could be another tiny race with the new "vblank counter bumping"
logic from commit 5b5561b ("drm/radeon: Fixup hw vblank counters/ts
...") if drm_update_vblank_counter() would be called multiple times in
quick succession within the "radeon_crtc->lb_vblank_lead_lines"
scanlines before start of real vblank iff at the same time a modeset
would happen and set radeon_crtc->lb_vblank_lead_lines to a smaller
value due to a change in horizontal mode resolution. That needs a
modeset to happen to a higher horizontal resolution just exactly when
the scanout is in exactly the right 5 or so scanlines and some client is
calling drm_vblank_get() to enable vblank irqs at the same time, but it
would cause the same hang if it happened - not that likely to happen
often, but still not nice, also Murphy's law... If we could switch to
drm_vblank_off/on instead of drm_vblank_pre/post_modeset we could remove
those race as well by forbidding any vblank irq related activity during
a modeset.
I'll hack up a patch for demonstration now.
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/dri-devel
