Re: [RFC PATCH] spi: Take the SPI IO-mutex in the spi_setup() method

2020-11-20 Thread Mark Brown
On Tue, 17 Nov 2020 12:45:17 +0300, Serge Semin wrote: > I've discovered that due to the recent commit 49d7d695ca4b ("spi: dw: > Explicitly de-assert CS on SPI transfer completion") a concurrent usage of > the spidev devices with different chip-selects causes the "SPI transfer > timed out" error. T

Re: [RFC PATCH] spi: Take the SPI IO-mutex in the spi_setup() method

2020-11-20 Thread Serge Semin
On Fri, Nov 20, 2020 at 05:17:48PM +, Mark Brown wrote: > On Tue, Nov 17, 2020 at 12:45:17PM +0300, Serge Semin wrote: > > > 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 settin

Re: [RFC PATCH] spi: Take the SPI IO-mutex in the spi_setup() method

2020-11-20 Thread Mark Brown
On Tue, Nov 17, 2020 at 12:45:17PM +0300, Serge Semin wrote: > 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-selec

Re: [RFC PATCH] spi: Take the SPI IO-mutex in the spi_setup() method

2020-11-19 Thread Geert Uytterhoeven
Hi Mark, On Thu, Nov 19, 2020 at 7:45 PM Mark Brown wrote: > On Wed, Nov 18, 2020 at 07:29:31PM +0300, Serge Semin wrote: > > On Wed, Nov 18, 2020 at 01:16:04PM +, Mark Brown wrote: > > > Yeah, problems with it are very common as the documentation has noted > > > since forever. IIRC there wa

Re: [RFC PATCH] spi: Take the SPI IO-mutex in the spi_setup() method

2020-11-19 Thread Mark Brown
On Wed, Nov 18, 2020 at 07:29:31PM +0300, Serge Semin wrote: > On Wed, Nov 18, 2020 at 01:16:04PM +, Mark Brown wrote: > > 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

Re: [RFC PATCH] spi: Take the SPI IO-mutex in the spi_setup() method

2020-11-18 Thread Serge Semin
On Wed, Nov 18, 2020 at 01:16:04PM +, Mark Brown wrote: > 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

Re: [RFC PATCH] spi: Take the SPI IO-mutex in the spi_setup() method

2020-11-18 Thread Mark Brown
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(

Re: [RFC PATCH] spi: Take the SPI IO-mutex in the spi_setup() method

2020-11-17 Thread Serge Semin
On Tue, Nov 17, 2020 at 12:56:44PM +0200, Andy Shevchenko wrote: > On Tue, Nov 17, 2020 at 11:45 AM Serge Semin > wrote: > > > > I've discovered that due to the recent commit 49d7d695ca4b ("spi: dw: > > Explicitly de-assert CS on SPI transfer completion") a concurrent usage of > > the spidev devic

Re: [RFC PATCH] spi: Take the SPI IO-mutex in the spi_setup() method

2020-11-17 Thread Andy Shevchenko
On Tue, Nov 17, 2020 at 11:45 AM Serge Semin wrote: > > I've discovered that due to the recent commit 49d7d695ca4b ("spi: dw: > Explicitly de-assert CS on SPI transfer completion") a concurrent usage of > the spidev devices with different chip-selects causes the "SPI transfer > timed out" error.

[RFC PATCH] spi: Take the SPI IO-mutex in the spi_setup() method

2020-11-17 Thread Serge Semin
I've discovered that due to the recent commit 49d7d695ca4b ("spi: dw: Explicitly de-assert CS on SPI transfer completion") a concurrent usage of the spidev devices with different chip-selects causes the "SPI transfer timed out" error. The root cause of the problem has turned to be in a race conditi