From: Mark Brown <broonie@kernel.org>
To: kernel@martin.sperl.org
Cc: Jon Hunter <jonathanh@nvidia.com>,
linux-tegra <linux-tegra@vger.kernel.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
linux-spi@vger.kernel.org
Subject: Re: Regression: spi: core: avoid waking pump thread from spi_sync instead run teardown delayed
Date: Fri, 18 Jan 2019 19:12:03 +0000 [thread overview]
Message-ID: <20190118191202.GG6260@sirena.org.uk> (raw)
In-Reply-To: <EA757B47-A264-4B4D-9E5F-16611ABA0278@martin.sperl.org>
[-- Attachment #1: Type: text/plain, Size: 1211 bytes --]
On Fri, Jan 18, 2019 at 06:11:31PM +0100, kernel@martin.sperl.org wrote:
> Does something like this looks acceptable?
> diff --git a/include/linux/spi/spi.h b/include/linux/spi/spi.h
> index ec210286567c..677fc5025033 100644
> --- a/include/linux/spi/spi.h
> +++ b/include/linux/spi/spi.h
> @@ -288,6 +288,21 @@ static inline void spi_unregister_driver(struct spi_driver *sdrv)
> module_driver(__spi_driver, spi_register_driver, \
> spi_unregister_driver)
>
> +/* define SPI Controller states in the state machine */
> +enum spi_controller_state {
> + SPI_CONTROLLER_STATE_SHUTDOWN = 0,
> + SPI_CONTROLLER_STATE_IDLE = 1,
> + SPI_CONTROLLER_STATE_IN_PROCESS = 2,
> + SPI_CONTROLLER_STATE_IN_TRANSFER = 3,
> +};
Yes, it does!
> SPI_CONTROLLER_MODE_EXCLUSIVE could replace the bus_lock_flag.
> I am also not sure of the “convention” of memory mode (i.e
> using mem_ops). Is it maybe implicitly spi_bus_locked - i.e
> typically only a single device?
Yes, it does - we're basically handing over the entire SPI bus to
another bit of hardware that will do memory mapped flash access so we
can't really have anything else trying to do SPI operations at the same
time.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
next prev parent reply other threads:[~2019-01-18 19:12 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-01-14 15:35 Regression: spi: core: avoid waking pump thread from spi_sync instead run teardown delayed Jon Hunter
[not found] ` <7C4A5EFC-8235-40C8-96E1-E6020529DF72@martin.sperl.org>
2019-01-15 14:26 ` Jon Hunter
2019-01-15 15:10 ` Mark Brown
2019-01-15 16:09 ` Jon Hunter
2019-01-15 19:27 ` Mark Brown
2019-01-15 17:39 ` kernel
2019-01-15 19:26 ` Mark Brown
2019-01-15 20:58 ` Martin Sperl
2019-01-15 21:25 ` Mark Brown
2019-01-16 11:01 ` Jon Hunter
2019-01-18 17:11 ` kernel
2019-01-18 19:12 ` Mark Brown [this message]
2019-01-20 11:24 ` kernel
2019-01-23 17:56 ` Mark Brown
2019-05-09 19:47 ` Martin Sperl
2019-05-12 8:54 ` Mark Brown
2019-01-16 10:58 ` Jon Hunter
2019-01-22 9:36 ` Geert Uytterhoeven
2019-01-23 8:26 ` Marek Szyprowski
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=20190118191202.GG6260@sirena.org.uk \
--to=broonie@kernel.org \
--cc=jonathanh@nvidia.com \
--cc=kernel@martin.sperl.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-spi@vger.kernel.org \
--cc=linux-tegra@vger.kernel.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox