The mmc_spi driver's mmc_cs_off() function states that "chipselect will always
be inactive after setup()"; however, the spi-davinci driver's setup() leaves CS
state unchanged.
Add a call to davinci_spi_chipselect(spi, BITBANG_CS_INACTIVE) to the spi-
davinci drivers' setup() function.
Signed-off-by: Ben Gardiner <[email protected]>
---
drivers/spi/spi-davinci.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/spi/spi-davinci.c b/drivers/spi/spi-davinci.c
index 707966b..f0f4dbd 100644
--- a/drivers/spi/spi-davinci.c
+++ b/drivers/spi/spi-davinci.c
@@ -404,6 +404,7 @@ static int davinci_spi_setup(struct spi_device *spi)
(pdata->chip_sel[spi->chip_select] == SPI_INTERN_CS))
set_io_bits(dspi->base + SPIPC0, 1 << spi->chip_select);
+ davinci_spi_chipselect(spi, BITBANG_CS_INACTIVE);
}
if (spi->mode & SPI_READY)
--
1.8.1.2
It is supposed to be possible to call setup() on one slave while
transfers on another slave attached to the same master are in
progress.
A cursory look at the code makes it seem that all the CS control bits
share SPIDAT1? Will writing to SPIDAT1 in davinci_spi_chipselect()
cause a race if another chipselect is being used?
On Tue, Sep 10, 2013 at 10:10 AM, Ben Gardiner <[email protected]> wrote:
> The mmc_spi driver's mmc_cs_off() function states that "chipselect will always
> be inactive after setup()"; however, the spi-davinci driver's setup() leaves CS
> state unchanged.
>
> Add a call to davinci_spi_chipselect(spi, BITBANG_CS_INACTIVE) to the spi-
> davinci drivers' setup() function.
>
> Signed-off-by: Ben Gardiner <[email protected]>
> ---
> drivers/spi/spi-davinci.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/spi/spi-davinci.c b/drivers/spi/spi-davinci.c
> index 707966b..f0f4dbd 100644
> --- a/drivers/spi/spi-davinci.c
> +++ b/drivers/spi/spi-davinci.c
> @@ -404,6 +404,7 @@ static int davinci_spi_setup(struct spi_device *spi)
> (pdata->chip_sel[spi->chip_select] == SPI_INTERN_CS))
> set_io_bits(dspi->base + SPIPC0, 1 << spi->chip_select);
>
> + davinci_spi_chipselect(spi, BITBANG_CS_INACTIVE);
> }
>
> if (spi->mode & SPI_READY)
> --
> 1.8.1.2
>
>
> ------------------------------------------------------------------------------
> How ServiceNow helps IT people transform IT departments:
> 1. Consolidate legacy IT systems to a single system of record for IT
> 2. Standardize and globalize service processes across IT
> 3. Implement zero-touch automation to replace manual, redundant tasks
> http://pubads.g.doubleclick.net/gampad/clk?id=51271111&iu=/4140/ostg.clktrk
> _______________________________________________
> spi-devel-general mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/spi-devel-general
Hi Trent,
Thanks for the quick review.
On Tue, Sep 10, 2013 at 10:44 PM, Trent Piepho <[email protected]> wrote:
>
> It is supposed to be possible to call setup() on one slave while
> transfers on another slave attached to the same master are in
> progress.
>
> A cursory look at the code makes it seem that all the CS control bits
> share SPIDAT1? Will writing to SPIDAT1 in davinci_spi_chipselect()
> cause a race if another chipselect is being used?
Good point. I think you're right there could be a race.
I tested with multiple slaves and hammered the bus with concurrent
accesses; but that doesn't mean that there _isn't_ still a race.
Can you recommend an existing implementation in-tree upon which I can
base a new patch to add concurrency protection to SPIDAT1 accesses?