On Mon, 24 Mar 2014, Felipe Balbi wrote: > Hi, > > On Mon, Mar 24, 2014 at 09:21:40AM -0600, David Mosberger wrote: > > Felipe, > > > > On Mon, Mar 24, 2014 at 7:31 AM, Felipe Balbi <balbi@xxxxxx> wrote: > > > > > Why do you need to run your IRQ handler when an URQ gets enqueued ? That > > > doesn't make much sense :-s > > > > Please see the comments at the start of the file: spi_sync() is > > blocking and must not be called while holding spinlocks or with > > interrupts disabled. The purpose of max3421_spi_thread() is to handle > > sure, but this is why we have threaded IRQ support. > > > all SPI transactions (implicitly serializing them). An interrupt is > > just one of the reasons to wake up the SPI thread. Adding URBs, > > removing them, or performing a bus reset are other reasons. > > you didn't tell me why. Why do you need to run that inside the same > thread ? Why can't you do that from inside ->urb_enqueue() itself ? > > > You can think of max3421_spi_thread() as implementing the state > > machine that would normally be implemented in silicon with a "smart" > > controller such as OHCI or similar. > > yada, yada, yada... still didn't answer my original question. It sounds like David is saying that he needs a process context to communicate with the host controller over SPI, and this communication has to take place whenever an URB is enqueued or dequeued as well as whenever an interrupt occurs. If that's correct, it seems a kernel thread would be a better solution than a threaded IRQ handler. Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
