On Thu, Oct 08, 2015 at 02:54:50PM +0100, Neil Armstrong wrote: > Hi All, > > I'm in a use case where I use cs_change on McSPI channel 3 on a single > transfer Full-Duplex message, then I transfer a single full duplex message > without cs_change on channel 1. > > Here is a better representation : > -- 1 transfer message cs_change=1 > cs3 : set_cs(0) > cs3 : full-duplex transfer > cs3 : transfer ok > -- 1 transfer message cs_change=1 > cs3 : set_cs(0) > cs3 : full-duplex transfer > cs3 : transfer ok > ... > -- 1 transfer message cs_change=1 > cs3 : set_cs(0) > cs3 : full-duplex transfer > cs3 : transfer ok > -- 1 transfer message cs_change=1 > cs1 : set_cs(0)
Looks like bus contention here. > cs1 : full-duplex transfer > cs1 : RXS timed out > cs1 : set_cs(1) > > Then "RXS timed out" on each non-cs3 transfers. > > The previous behavior of cs_change was : > - between transfers, unassert CS and re-assert-it for the following transfer > - between messages, unassert CS > > The new behaviour inherited from the SPI core spi_transfer_one_message > function : > - between transfers, unassert CS and re-assert-it for the following transfer > - between messages, leave CS asserted > > We tried disabling the DMA, and the FIFO, but the behavior was actually the > same, only reverting back before the "Switch driver to use transfer_one" > fixed the issue. > > Then actually disabling the cs_change corrected the issue. It may be why the > original driver ignored the "leave it on after last xfer" hint. > > The problem is : how can we disable this hint since it is managed in SPI core > spi_transfer_one_message ? It seems the core driver assumes that the driver is smart enough to deselect the previous chip select instead of doing it explicitly. > > A solution will be to track down the current asserted CS and unassert it them > when the active channel changes. > > Neil -- 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/
