Hi Dave,
So updated vblank-rework pull request, now with the polish that Mario requested applied (and reviewed by him). Also with backmerge like you've requested for easier merging.
The neat thing this finally allows is to immediately disable the vblank interrupt on the last drm_vblank_put if the hardware has perfectly accurate vblank counter and timestamp readout support. On i915 that required piles of small adjustements from Ville since depending upon the platform and port the vblank happens at different scanout lines.
Of course this is fully opt-in and per-device (we need that since gen2 doesn't have a hw vblank counter).
Cheers, Daniel
The following changes since commit fdcaa1dbb7c6ed419b10fb8cdb5001ab0a00538f:
Merge tag 'ipu-3.18' of git://git.pengutronix.de/git/pza/linux into drm-next (2014-09-10 19:43:29 +1000)
are available in the git repository at:
git://anongit.freedesktop.org/drm-intel tags/topic/vblank-rework-2014-09-12
for you to fetch changes up to 336879b1da97fffc097f77c6d6f818660f2826f0:
Merge remote-tracking branch 'airlied/drm-next' into topic/vblank-rework (2014-09-11 14:46:53 +0200)
---------------------------------------------------------------- Daniel Vetter (5): drm: Really never disable vblank irqs for offdelay==0 drm: Only update final vblank count when precise ts is available drm: Simplify return value of drm_get_last_vbltimestamp drm: Clarify vblank ts/scanoutpos sampling #defines Merge remote-tracking branch 'airlied/drm-next' into topic/vblank-rework
Mario Kleiner (2): drm: Remove drm_vblank_cleanup from drm_vblank_init error path. drm: Use vblank_disable_and_save in drm_vblank_cleanup()
Ville Syrjälä (16): drm: Always reject drm_vblank_get() after drm_vblank_off() drm/i915: Warn if drm_vblank_get() still works after drm_vblank_off() drm: Don't clear vblank timestamps when vblank interrupt is disabled drm: Move drm_update_vblank_count() drm: Have the vblank counter account for the time between vblank irq disable and drm_vblank_off() drm: Avoid random vblank counter jumps if the hardware counter has been reset drm: Reduce the amount of dev->vblank[crtc] in the code drm: Fix deadlock between event_lock and vbl_lock/vblank_time_lock drm: Fix race between drm_vblank_off() and drm_queue_vblank_event() drm: Disable vblank interrupt immediately when drm_vblank_offdelay<0 drm: Add dev->vblank_disable_immediate flag drm/i915: Opt out of vblank disable timer on >gen2 drm: Kick start vblank interrupts at drm_vblank_on() drm/i915: Update scanline_offset only for active crtcs drm: Fix confusing debug message in drm_update_vblank_count() drm: Store the vblank timestamp when adjusting the counter during disable
Documentation/DocBook/drm.tmpl | 7 + drivers/gpu/drm/drm_drv.c | 4 +- drivers/gpu/drm/drm_irq.c | 379 +++++++++++++++++++----------- drivers/gpu/drm/i915/i915_irq.c | 10 +- drivers/gpu/drm/i915/intel_display.c | 17 +- drivers/gpu/drm/nouveau/nouveau_display.c | 2 +- drivers/gpu/drm/radeon/radeon_display.c | 2 +- drivers/gpu/drm/radeon/radeon_pm.c | 2 +- include/drm/drmP.h | 18 +- 9 files changed, 286 insertions(+), 155 deletions(-)
On Fri, Sep 12, 2014 at 09:48:59AM +0200, Daniel Vetter wrote: [...]
Ville Syrjälä (16): drm: Always reject drm_vblank_get() after drm_vblank_off()
This particular commit seems to be wreaking havoc. Inki already reported this at some point and Andrzej and Joonyoung tried to fix this on Exynos already, but it seems like a couple more drivers would suffer from this. At least those using drm_vblank_off() but not drm_vblank_on() would see the same issue.
A quick grep indicate that Armada, Exynos, GMA500 and STI would all suffer from the same problem. Adding the respective maintainers. I've used the attached patch to fix the issue on Tegra.
Ville, does that conversion look right? Perhaps it would be safer to call drm_crtc_vblank_on() before activating the CRTC to avoid a potential race? It seems like drm_vblank_on() and drm_vblank_off() would replace drm_vblank_{pre,post}_modeset() completely, so I've removed them as part of the patch as well.
I suppose the attached patch and equivalent ones for the other drivers would need to be carried in this series to avoid regressions.
Thierry
dri-devel@lists.freedesktop.org