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>
Subject: Re: [RFC] [PATCH 3/3] drivers: spi: spi.c: Don't use the message queue if possible in spi_sync
Date: Wed, 8 Jun 2022 12:29:16 +0100 [thread overview]
Message-ID: <YqCIDNHjFP4p9xxs@sirena.org.uk> (raw)
In-Reply-To: <20220608095409.2d8c46fb@erd992>
[-- Attachment #1: Type: text/plain, Size: 1026 bytes --]
On Wed, Jun 08, 2022 at 09:54:09AM +0200, David Jander wrote:
> Mark Brown <broonie@kernel.org> wrote:
> > Moving idling (and all the was_busy stuff) within the io_mutex would
> > definitely resolve the issue, the async submission context is the only one
> > that really needs the spinlock and it doesn't care about idling. I can't
> > think what you could do with the io_mutex when idling so it seems to
> > fit.
> Ok, so we could agree on a way to fix this particular issue: put the idling
> transition into the io_mutex. Thanks.
> Looking forward to read comments on the rest of the code, and the general idea
> of what I am trying to accomplish.
I think the rest of it is fine or at least I'm finding it difficult to
see anything beyond the concurrency issues. I think we need to do an
audit to find any users that are doing a spi_sync() to complete a
sequence of spi_async() operations but I'm not aware of any and if it
delivers the performance benefits it's probably worth changing that
aspect of the driver API.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
next prev parent reply other threads:[~2022-06-08 11:29 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-05-25 14:29 [RFC] [PATCH 0/3] Optimize spi_sync path David Jander
2022-05-25 14:29 ` [RFC] [PATCH 1/3] drivers: spi: API: spi_finalize_current_message -> spi_finalize_message David Jander
2022-05-25 14:29 ` [RFC] [PATCH 2/3] drivers: spi: spi.c: Move ctlr->cur_msg_prepared to struct spi_message David Jander
2022-05-25 14:29 ` [RFC] [PATCH 3/3] drivers: spi: spi.c: Don't use the message queue if possible in spi_sync David Jander
2022-05-25 14:46 ` David Jander
2022-06-07 18:30 ` Mark Brown
2022-06-08 7:54 ` David Jander
2022-06-08 11:29 ` Mark Brown [this message]
2022-06-09 15:34 ` David Jander
2022-06-09 16:31 ` Mark Brown
2022-06-10 7:27 ` David Jander
2022-06-10 13:41 ` Mark Brown
2022-06-10 18:17 ` Mark Brown
2022-06-13 9:05 ` David Jander
2022-06-13 11:56 ` Mark Brown
2022-07-15 7:47 ` Thomas Kopp
2022-07-15 9:02 ` Thomas Kopp
2022-06-08 13:43 ` Andy Shevchenko
2022-06-08 14:55 ` David Jander
2022-05-30 12:06 ` [RFC] [PATCH 0/3] Optimize spi_sync path Mark Brown
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=YqCIDNHjFP4p9xxs@sirena.org.uk \
--to=broonie@kernel.org \
--cc=andrew@lunn.ch \
--cc=david@protonic.nl \
--cc=linux-spi@vger.kernel.org \
--cc=mkl@pengutronix.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.