[PATCH v4 1/2] spi: implemented driver for Cirrus EP93xx SPI controller

Mika Westerberg mika.westerberg at iki.fi
Thu Apr 22 01:45:19 EDT 2010


On Wed, Apr 21, 2010 at 01:00:56PM -0500, H Hartley Sweeten wrote:
> Same results are your v4 driver.  But, I think your on the right track.

Thanks for testing.

> I think the problem is in the ep93xx_spi_read_write routine.  That function
> returns 0 as long as there is still data left in the current transfer.  The
> only time it doesn't return 0, which will cause the can_continue, is when:
> 
> 	if (espi->rx == t->len) {
> 		msg->actual_length += t->len;
> 		return t->len;
> 	}
> 
> At this point the tx and rx fifos will both be empty, which causes the SSP
> peripheral to raise the SFRM signal.

True.

> A picture is worth a thousand words... Attached is a logic analyzer capture
> of the Read-ID command and response from the SPI Flash.  EGPIO7 is my chip
> select to the flash.  The first 4 SPI MOSI (Tx) blocks are the 0x90, 0x00,
> 0x00, 0x00 command to the flash.  You will notice that the SFRM line is
> asserted for those bytes.  A bit later are the 2 SPI MISO (Rx) responses
> from the flash with the ManID/DevID, again with the SFRM line asserted.

Yeah, it clearly shows that SFRMOUT is deasserted between transfers :(

I will try to work out some sort of hack which will keep the FIFOs from
emptying.

MW



More information about the linux-arm-kernel mailing list