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 <ben.l.gardi...@gmail.com> 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 <ben.l.gardi...@gmail.com> > --- > 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 > spi-devel-gene...@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/spi-devel-general -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
