On Wed, 2009-07-22 at 14:58 +0200, Thomas Gleixner wrote: > One > thing which I definitely want to change is the thread_eoi function. We > probably want to have it customizable for the following reason: > > main interrupt > hardirq handler wakes main thread handler > > main thread handler > bus magic > subdevice1 "hardirq" handler wakes subdevice1 irq thread > subdevice2 "hardirq" handler wakes subdevice2 irq thread > main thread handler waits for subdevice1/2 handlers to complete > > subdevice1 thread handler > bus magic > .... > thread_fn returns > signal main thread handler via completion > > subdevice2 thread handler > bus magic > .... > thread_fn returns > signal main thread handler via completion > > main thread handler resumes > bus magic > main thread handler returns from thread_fn > unmask main interrupt > > So the thread_eoi function is useful for both the main and the > subdevice handlers. The main handler probably just issues the unmask > while the subdevice handlers probably want to call a completion to > notify the main thread handler that they are done. That would be a > fairly proper design I think and would encourage driver writers to > follow the common scheme instead of doing their own black magic. > > Thinking further we should even provide some infrastructure for that > in the common code which would handle the completion and attach it to > the interrupts in question, so the driver authors would not have to > deal with that at all. They just would return from thread_fn and let > the generic code deal with the notification. The notification has to > be set up by the interrupt controller code. That way you can use the > same device driver code w/o knowledge of the interrupt controller > implementation it is attached to. Wouldn't it be better if we could express the nesting property from within genirq, so that we can do things like: register_chip_nested(parent_chip, parent_irq, slave_chip); And let genirq set-up the needed magic to make the nesting work. Also, how important is it that subhandler1..n run in their own thread? That is, can't we let them run from the thread that is otherwise waiting for the completino anyway? -- To unsubscribe from this list: send the line "unsubscribe linux-input" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
