On Fri, 2009-01-30 at 10:43 -0800, Jesse Barnes wrote: > On Friday, January 30, 2009 9:26 am Jesse Barnes wrote: > > But maybe there's an even simpler way to handle this (the wait on disabled > > pipe/irq problem). The DRM_WAIT_ON already checks if irqs are disabled > > before waiting (or at least it's supposed to), and the vblank_get call will > > check to make sure the pipe is enabled before waiting... maybe one of those > > checks is failing in this case, or we're not waking clients up at IRQ > > disable time like we should. I'll do some more testing and see. > > Since in the VT switch case at least, userspace is calling in with a stale > vblank value (one much smaller than the current count), another option would > be something like the below. Needs to be a bit smarter to deal with counter > wraparound though,
I don't think an additional test should be needed; the (drm_vblank_count(dev, crtc) - vblwait->request.sequence) <= (1 << 23) test is supposed to catch insane conditions, if it isn't appropriate, just fix it. > but OTOH wraparound wouldn't happen as often if our > drm_update_vblank_count() wasn't so eager to add ~max_frame_count to > the counter at enable time. Huh? If the counter jumps, that's a bug (most likely due to the display driver not calling the pre/post modesetting ioctl around the CRTC frame counter resetting?) that needs to be fixed. I'm not seeing any such issues with radeon anymore though; maybe you;d like to take a look at how the X radeon driver calls the ioctl in Leave/EnterVT. -- Earthling Michel Dänzer | http://www.vmware.com Libre software enthusiast | Debian, X and DRI developer ------------------------------------------------------------------------------ This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword -- _______________________________________________ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
