Re: [RFC] [PATCH 3/3] drivers: spi: spi.c: Don't use the message queue if possible in spi_sync

From: Mark Brown <broonie@kernel.org>
To: David Jander <david@protonic.nl>
Cc: linux-spi@vger.kernel.org, Andrew Lunn <andrew@lunn.ch>,
	Marc Kleine-Budde <mkl@pengutronix.de>,
	Oleksij Rempel <o.rempel@pengutronix.de>
Subject: Re: [RFC] [PATCH 3/3] drivers: spi: spi.c: Don't use the message queue if possible in spi_sync
Date: Mon, 13 Jun 2022 12:56:48 +0100	[thread overview]
Message-ID: <YqcmANJXrsLXI6LB@sirena.org.uk> (raw)
In-Reply-To: <20220613110550.772c5023@erd992>

[-- Attachment #1: Type: text/plain, Size: 1320 bytes --]

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 #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]