Benjamin Herrenschmidt wrote:
It should probably be infinite if no hw lock is being held.
Lock should be dropped in case of longer waits so that user is given a chance
to stop the process.
Well, the current behaviour (i.e. return EBUSY after 3 seconds) would
make sense too, the user-space driver could simply redo the ioctl (it
could also drop the lock before it retries). Which probably really is
what was intended, just that it checks for EAGAIN instead of EBUSY
(though the code does not drop and retake the lock) by mistake.
Dropping the lock while the card is busy processing commands ? sounds
pretty dangerous to me..
Why? That's done already anyway, there is no sync or something like that
when context switches happen. When you have the lock, it simply means
you now can submit commands (and do other stuff requiring to have the
lock), but while you do that the chip may still be processing commands
submitted earlier from other contexts. That's at least my understanding
of how that locking stuff works...
Roland
-------------------------------------------------------
All the advantages of Linux Managed Hosting--Without the Cost and Risk!
Fully trained technicians. The highest number of Red Hat certifications in
the hosting industry. Fanatical Support. Click to learn more
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=107521&bid=248729&dat=121642
--
_______________________________________________
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
