Driver porting: sleeping and waking up [LWN.net]

Driver porting: sleeping and waking up

Posted Feb 28, 2003 13:49 UTC (Fri) by ortalo (subscriber, #4654)
Parent article: Driver porting: sleeping and waking up

As I understand it (possibly with several misunderstanding), these wait and wake up functions primarily address userspace waits.
What about kernel-internal waiting? (aka: Is it reasonable to call wake_up() from an interrupt handler?)

A practical example (the one I'm concerned with): sending out graphical display lists via DMA to a modern graphics hardware accelerator.
In this context, one process sends memory buffers to the kernel and occasionally waits when too many buffers are already submitted for execution: in this case I have to use the wait functions you describe, that's okay.
Now, later on, the displays lists get executed by the graphic hardware and the end of each display list generates an IRQ. The IRQ handler needs to acknowledge the interrupt, but also to submit the next display list for execution (if any, remember that userspace may submit display lists faster than the hardware executes them and some of them may be in queue inside the kernel).
It can work like this. But it is not very clean to directly submit the next display list to the hardware *from the interrupt handler*. For example, one would like to do a time-consuming checking step on the display list before submission; worse, if AGP is involved (sooner or later) one will want to mess up with the AGP translation tables. Doing this from an interrupt handler does not seem very reasonable (time consuming and possibly disruptive work).
In an ideal world (ie: when I'm knowledgeable enough), a sort of kernel thread (one per graphic processor) would exist for submitting work to the hardware and the interrupt handler would only signal to that kernel thread the end of execution. Would it be possible to use the wait queues you describe for synchronization between the kernel thread and the interrupt handler? How would you recommend to adress such an issue?

Rodolphe

(Log in to post comments)

Driver porting: sleeping and waking up

Posted Feb 28, 2003 15:04 UTC (Fri) by corbet (editor, #1) [Link]

The best option, of course, would be to check the display lists at the time they are submitted by the user space process. That way you can return an immediate error if something is wrong.

If you have other stuff that needs doing, a kernel thread could certainly do it. I would recommend a look at the workqueue interface, however, as a relatively easy way to do this sort of deferred processing. You can feed a task into a workqueue from an interrupt handler and it can execute at leisure, in process context, later on.