lkml.org 
[lkml]   [2020]   [Nov]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [RFC PATCH] spi: Take the SPI IO-mutex in the spi_setup() method
On Tue, Nov 17, 2020 at 12:45:17PM +0300, Serge Semin wrote:

> method being called at the same time. In particular in calling the
> spi_set_cs(false) while there is an SPI-transfer being executed. In my
> case due to the commit cited above all CSs get to be switched off by
> calling the spi_setup() for /dev/spidev0.1 while there is an concurrent
> SPI-transfer execution performed on /dev/spidev0.0. Of course a situation
> of the spi_setup() being called while there is an SPI-transfer being
> executed for two different SPI peripheral devices of the same controller
> may happen not only for the spidev driver, but for instance for MMC SPI +
> some another device, or spi_setup() being called from an SPI-peripheral
> probe method while some other device has already been probed and is being
> used by a corresponding driver...

It's documented that a driver's spi_setup() operation is supposed to
support being able to be called concurrently with other transfers, see
spi-summary.rst.

> Of course I could have provided a fix affecting the DW APB SSI driver
> only, for instance, by creating a mutual exclusive access to the set_cs
> callback and setting/clearing only the bit responsible for the
> corresponding chip-select. But after a short research I've discovered that
> the problem most likely affects a lot of the other drivers:

Yeah, problems with it are very common as the documentation has noted
since forever. IIRC there was some problem triggered by trying to force
it to be serialised but I can't remember what it was.
[unhandled content-type:application/pgp-signature]
\
 
 \ /
  Last update: 2020-11-18 14:17    [W:0.111 / U:0.724 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site