On Tue, Apr 19, 2005 at 12:03:15AM +0100, Dave Airlie wrote:
> 
> >
> > The macro DRM_WAIT_ON changed behaviour.
> > In earlier DRMs it checked every HZ for "condition" in case it was slightly
> > missed.
> >
> > This doesn't happen anymore, which means some applications freezes for 
> > about 3
> > secs, when they
> > just missed an interrupt.
> >
> > This in itself is a little bit strange since, if the following occurs:
> >
> > * Check condition
> > * if false, go to sleep
> >
> > and DRM_WAKEUP is called by the interrupt handler in between those two, the
> > sleep should never occur, which now it seems to do anyway.
> >
> > Could we pls have the old behaviour back?
> 
> This was as a result of a patch from Nishanth who I've cc'ed, I was a bit
> dodgy on this patch and haven't put it in the kernel for that reason, so I
> put it in CVS to see if it would cause problems it looks like it has...

I agree, patch should be reverted. The difference between my change and
the previous code, fundamentally, is that mine slept as long as possible
relative to the passed in timeout until either a signal or wait-queue
event happened; the original code, in contrast, slept for a fixed amount
of time (10 ms or 1 jiffy, whichever is longer) up to a specified total
time.

> You can revert drm_os_linux.h to version 1.30 and see if it still works
> fine..
> 
> Alan, The old code uses schedule_timeout and signal_pending along with a
> waitqueue, I don't think it has been deprecated in anyway.. as in what is
> in the kernel is what I consider the current code and Christoph hasn't
> complained :-)

The old code is fine -- I just was trying to consolidate the users of HZ
in to one place.

Thanks,
Nish


-------------------------------------------------------
This SF.Net email is sponsored by: New Crystal Reports XI.
Version 11 adds new functionality designed to reduce time involved in
creating, integrating, and deploying reporting solutions. Free runtime info,
new features, or free trial, at: http://www.businessobjects.com/devxi/728
--
_______________________________________________
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel

Reply via email to