On Wednesday 22 July 2009, Thomas Gleixner wrote: > 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 Why force this wasteful/undesired "all subdevices must have their own IRQ handling thread" policy? As previously noted, a single thread typically suffices. There's no need to waste a dozen (or so) pages of memory for such purposes ... these events are (as noted most recently by Mark) infrequent/rare and performance isn't a functionality gatekeeper. Plus ... > main thread handler waits for subdevice1/2 handlers to complete ... sharing that thread can eliminate that synchronization problem, and simplify the whole process. > 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 -- To unsubscribe from this list: send the line "unsubscribe linux-i2c" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
