| Message ID | 1378833022-31046-1-git-send-email-ben.l.gardiner@gmail.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
Hi Trent, Thanks for the quick review. On Tue, Sep 10, 2013 at 10:44 PM, Trent Piepho <tpiepho@gmail.com> 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?
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)
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 <ben.l.gardiner@gmail.com> --- drivers/spi/spi-davinci.c | 1 + 1 file changed, 1 insertion(+)