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
------------------------------------------------------------------------------
_______________________________________________
spi-devel-general mailing list
spi-devel-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/spi-devel-general
