spi-mem and gpio chipselects

spi-mem and gpio chipselects

[Chris Packham]

Hi,

I'm working on a platform that has a slightly complicated scheme for
SPI chip-selects using gpios[1]. The spi controller driver in this case
supports the spi-mem operations which appear to bypass the generic
spi_set_cs().

Would there be any harm in adding calls to spi_set_cs() to spi-mem.c?
Naively spi_mem_access_start() and spi_mem_access_end() seem like
convenient places to start.

--
[1] - similar design to 
https://marc.info/?l=linux-spi&m=155504537628635&w=2 but a different
platform.

Re: spi-mem and gpio chipselects

[Mark Brown]

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

On Mon, Nov 04, 2019 at 12:35:24AM +0000, Chris Packham wrote:

> I'm working on a platform that has a slightly complicated scheme for
> SPI chip-selects using gpios[1]. The spi controller driver in this case
> supports the spi-mem operations which appear to bypass the generic
> spi_set_cs().

> Would there be any harm in adding calls to spi_set_cs() to spi-mem.c?
> Naively spi_mem_access_start() and spi_mem_access_end() seem like
> convenient places to start.

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.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: spi-mem and gpio chipselects

[Chris Packham]

On Mon, 2019-11-04 at 12:44 +0000, Mark Brown wrote:
> On Mon, Nov 04, 2019 at 12:35:24AM +0000, Chris Packham wrote:
> 
> > I'm working on a platform that has a slightly complicated scheme for
> > SPI chip-selects using gpios[1]. The spi controller driver in this case
> > supports the spi-mem operations which appear to bypass the generic
> > spi_set_cs().
> > Would there be any harm in adding calls to spi_set_cs() to spi-mem.c?
> > Naively spi_mem_access_start() and spi_mem_access_end() seem like
> > convenient places to start.
> 
> 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
tasks may run but spi_mem_access_start() has taken an io_mutex so
anything that accesses that spi bus will block.

Re: spi-mem and gpio chipselects

[Chris Packham]

On Tue, 2019-11-05 at 09:06 +1300, Chris Packham wrote:
> On Mon, 2019-11-04 at 12:44 +0000, Mark Brown wrote:
> > On Mon, Nov 04, 2019 at 12:35:24AM +0000, Chris Packham wrote:
> > 
> > > I'm working on a platform that has a slightly complicated scheme for
> > > SPI chip-selects using gpios[1]. The spi controller driver in this case
> > > supports the spi-mem operations which appear to bypass the generic
> > > spi_set_cs().
> > > Would there be any harm in adding calls to spi_set_cs() to spi-mem.c?
> > > Naively spi_mem_access_start() and spi_mem_access_end() seem like
> > > convenient places to start.
> > 
> > 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
> tasks may run but spi_mem_access_start() has taken an io_mutex so
> anything that accesses that spi bus will block.

If we do decide that spi-mem ops and cs_gpios are incompatible we could
probably do something that disables the ops so that the spi code falls
back to using spi_transfer.

Re: spi-mem and gpio chipselects

[Mark Brown]

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

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.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]