On Tue, 2009-04-14 at 12:13 -0700, Jesse Barnes wrote: > On Mon, 30 Mar 2009 01:10:51 -0500 > Robert Noland <rnol...@2hip.net> wrote: > > > The Intel driver continues to call modeset before installing the irq > > handler. I discussed this issue several months ago, but have only > > recently become painfully aware of the deeper issues. Things seem to > > work ok, when you first start X, due to the fact that nothing is > > actually waiting on vblanks before the handler gets installed. > > During a Vt switch however, what I found was that with gears running > > synced to vblank while switching, pre-modeset says that vblanks are > > on and enables the pipestat registers. post-modeset schedules them > > to be disabled at some point in the future. At this point, > > vblank_enabled = 1. Now, the interrupt handler gets installed, in > > preinstall it wipes out both pipestat registers and again in > > postinstall, clearing status bits this time. That means that > > vblank_enabled is 1 and pipestat is empty. As long as there is a > > consumer asking for vblank, vblank_disable_fn never fires to clean > > all of this mess up. vblank_get won't ever actually turn vblanks > > back on, because it thinks they are already on. So the client just > > hangs there. > > > > I think that all of the libdrm code to deal with clients stalling on > > vblank was probably not needed. What happens now, is that while you > > are switched away or in dpms sleep, the client requesting vblank just > > repeatedly fires the timeout, rather than just stalling until you come > > back and seeing that the vblank counter has jumped way ahead of it and > > going on. As it is now, it continues to render one frame / sec while > > it is offscreen. > > Yeah that does look like a real problem... Can we check whether the > handler has been installed at modeset time instead though? E.g. > (totally untested): > > diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c > index 93e677a..f2e4e1c 100644 > --- a/drivers/gpu/drm/drm_irq.c > +++ b/drivers/gpu/drm/drm_irq.c > @@ -504,7 +504,7 @@ int drm_modeset_ctl(struct drm_device *dev, void > *data, int crtc, ret = 0; > > /* If drm_vblank_init() hasn't been called yet, just no-op */ > - if (!dev->num_crtcs) > + if (!dev->num_crtcs || !dev->irq_enabled) > goto out; > > crtc = modeset->crtc;
I think that means that you won't take a reference of the hardware vblank counter over vt switch. > Unfortunately, the rules keep changing here. When we first pushed this > stuff we were assuming that interrupts & vblanks would be enabled at > load time and stay on forever. But now we have vblank init at load > time, but interrupts going on & off at VT switch and startup time... it > really messes up the logic. This is basically what I am doing now... I have re-worked all the interrupt code to install/uninstall the handler on FreeBSD at load/unload time. The drm_irq_(un)install() ioctls just (un)mask stuff. Fixing the ddx still seems like the right plan though. The radeon driver seems to handle this correctly... It also doesn't try to disable interrupts over vt switch, which seems to work well. robert. -- Robert Noland <rnol...@2hip.net> 2 Hip Networks
signature.asc
Description: This is a digitally signed message part
------------------------------------------------------------------------------ This SF.net email is sponsored by: High Quality Requirements in a Collaborative Environment. Download a free trial of Rational Requirements Composer Now! http://p.sf.net/sfu/www-ibm-com
-- _______________________________________________ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
