[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20191105114227.GB4500@sirena.co.uk>
Date: Tue, 5 Nov 2019 11:42:27 +0000
From: Mark Brown <broonie@...nel.org>
To: Chris Packham <Chris.Packham@...iedtelesis.co.nz>
Cc: "linux-spi@...r.kernel.org" <linux-spi@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: spi-mem and gpio chipselects
On Mon, Nov 04, 2019 at 08:06:42PM +0000, Chris Packham wrote:
> On Mon, 2019-11-04 at 12:44 +0000, Mark Brown wrote:
> > That's only going to work in cases where the controller translates
> > things into a single SPI operation on the flash which I'm not sure is
> > always going to be the case. We'd need a way to guarantee that the
> > controller is going to do that in order to avoid data corruption issues.
> In my particular case (spi-bcm-qspi.c) bcm_qspi_bspi_exec_mem_op() does
> seem to assert the native chip-select then do it's operation. As I
> understand the wait_for_completion_timeout() will schedule so other
The issue is what happens if the hardware translates the operations it's
being asked to do into multiple physical operations on the bus for some
reason. It sounds like yours won't but we can't just unconditionally
push the chip select control out to software even if the normal SPI
modes support it.
> tasks may run but spi_mem_access_start() has taken an io_mutex so
> anything that accesses that spi bus will block.
That's guaranteed.
Download attachment "signature.asc" of type "application/pgp-signature" (489 bytes)
Powered by blists - more mailing lists