Hi, On Fri, Apr 16, 2010 at 1:22 AM, Thomas Gleixner <tglx@xxxxxxxxxxxxx> wrote: > >> raise_threaded_irq schedules the execution of an interrupt thread > > I really have a hard time to understand _WHY_ we want to have that > function. > ..... > > Can you please explain, what you are trying to achieve and why it > can't be done with the existing interfaces ? > The idea was that by using this function we just need one kind of deferred work (interrupt threads) instead of two (for example interrupt threads and workqueues) in some situations. This is very handy with devices that do transmission and reception at the same time, for example many SPI devices. The user case is the max3100 UART on SPI driver. The same SPI instruction both receives and sends chars. So when we need to send a char we just start the interrupt thread instead of having another kind of deferred work doing the job. This greatly simplifies locking and avoids duplication of functionality (otherwise we must have an interrupt thread that does reception and a workqueue that does sending and receiving for example) because everything is done in just one point. The move from worqueues to interrupt threads was motivated by the much smaller latency under load of the latter because they are scheduled as RT processes. I hope this doesn't sound like a terrible abuse of threaded interrupts. Let me know before I try to fix other problems you mentioned. Thanks -- Christian Pellegrin, see http://www.evolware.org/chri/ "Real Programmers don't play tennis, or any other sport which requires you to change clothes. Mountain climbing is OK, and Real Programmers wear their climbing boots to work in case a mountain should suddenly spring up in the middle of the computer room." -- To unsubscribe from this list: send the line "unsubscribe linux-serial" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
