On Mon, Jun 13, 2022 at 11:05:50AM +0200, David Jander wrote: > Thinking out loud here, so correct me if I am wrong. > Basically what is happening in that scenario, if we had several async > messages queued up, is this: > 1. __pump_messages() gets first message off queue, stores in cur_msg. > 2. __pump_messages() calls ->transfer_one_message(). > 3. transfer_one_message() triggers an IRQ or other context *A*. > 4. transfer_one_message() returns before message is finished. > 5. work queue idles. If someone calls spi_async() now, it will not queue > work, since ctlr->busy is still true. > 6. *A*: IRQ or other context calls spi_finalize_current_message() > 7. spi_finalize_current_message() schedules new work. > 8. Goto 1. > Total ctx switches message->message: 2 (at steps 3->6 and 7->8). Yes, plus also any transition to the context that submitted the message from completing the message. > In this scenario, the io_mutex is taken at step 1 and released at step 9, > inside the same function. The io_mutex is released either after > transfer_one_message() returns, or after spi_finalize_current_message() is > called, whatever comes _LAST_. I think I like this. Any potential problems > I am missing? I think that about covers it, I'm not seeing any issues right now.
Attachment:
signature.asc
Description: PGP signature
