Hi Daniel, On Wed, 2016-06-08 at 16:30 +0200, Daniel Vetter wrote: > On Wed, Jun 08, 2016 at 04:14:38PM +0200, Maarten Lankhorst wrote: > > > > Op 08-06-16 om 14:18 schreef Daniel Vetter: > > > > > > The drm core has a nice ready-made helper for exactly the simple case > > > where it should fire on the next vblank. > > > > > > Note that arming the vblank event in _begin is probably too early, and > > > might easily result in the vblank firing too early, before the new set > > > of planes are actually disabled. But that's kinda a minor issue > > > compared to just outright hanging userspace. > > > > > > v2: Be more robust and either arm, when the CRTC is on, or just send > > > the event out right away. > > > > > > Cc: Carlos Palminha <palminha@xxxxxxxxxxxx> > > > Cc: Alexey Brodkin <abrodkin@xxxxxxxxxxxx> > > > Cc: linux-snps-arc@xxxxxxxxxxxxxxxxxxx > > > Signed-off-by: Daniel Vetter <daniel.vetter@xxxxxxxxx> > > Wouldn't it be better to do this in atomic_flush then? > I'm not going to fix up other people's drivers completely, just enough to > hopefully not break them. If arc also blocks vblank interrupts with the go > bit, then doing this in _begin is correct. Either way it needs hw-specific > knowledge to asses whether it's correct, since doing the vblank event > stuff in _flush is also racy without some prevention. Actually in ARC PGU driver that was one of many other copy-pastes from other drivers. I.e. for me this is another boilerplate and if that's the same for other drivers as well probably that's a good candidate for generalization into something like drm_helper_crtc_atomic_check(). -Alexey _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel