On Sunday, April 25, 2010 2:39 AM, Martin Guy wrote:
>
> Sorry about the incomplete message. Finger trouble.
>
> On 4/25/10, Martin Guy <martinw...@gmail.com> wrote:
> ...
>> SFRMOUT will have gone high:
>
>> if (espi->tx >0 && espi->tx < t->len
>> && !(ep93xx_spi_read_u16(espi, SSPSR) & SSPSR_BSY)) {
>> /* More to transmit but device has gone idle means that
>> * SFRMOUT will have gone high */
>> printk("ep93xx-spi: Underrun\n");
>> }
>
> I've also done a version that doesn't printk() in the middle of it,
> which affects timing, but counts the underruns and reports at end of
> transfer. The result is that every 512-byte block underruns at least
> once, sometimes twice.
I haven't actually looked for the underrun by checking the SSPSR_BSY
bit but my guess is actually underruns a lot more than that. Depends
on where you are doing the check above on if you actually see it.
During the 512+2+1 message that is sent when the mmc_spi driver is
doing a block read, the 512 byte transfer goes like this:
1) 8 writes, prime the tx fifo
SFRMOUT asserts when the first bit of the first byte starts
transmitting
2) Interrupt
3) 8 reads, we must have emptied the tx fifo and filled the rx fifo
SFRMOUT de-asserts after the the last bit of the last byte is
received
4) 8 writes, fifo's are empty so we re-fill them
SFRMOUT asserts when the first bit of the first byte starts
transmitting
5) end of interupt
6) go back to 2
Basically, anytime the espi->fifo_level == 8 and we can do an 8 byte
read you have to assume that the SFRMOUT signal has already been de-
asserted.
This matches what I am seeing with the logic analyzer.
I have modifed my board so that I now have an external GPIO for the chip
select. That chip select goes low then shortly after, the SFRMOUT signal
goes low and 8 bytes are pumped out then SFRMOUT goes back high. A bit
later the interrupt happens, indicated by another GPIO I toggle in the
interrupt routine. Right before the interrupt ends I again see SFRMOUT
go low and 8 more bytes are pumped out. The interrupt actually completes
before the data is all pumped out. But again SFRMOUT gets de-asserted
before the next interrupt occurs. This keeps happening until all the
data in the message is finally transferred, at which point the external
GPIO chip select is finally de-asserted.
> I'll run a few more tests, e.g. dropping the clock rate, but at this
> point I'd be inclined to declare it impossible to keep SFRMOUT low
> during a transfer, and just use the simple non-continuous code with a
> comment at the top of the file that explains why you can't use SFRMOUT
> as a chip select for devices that require CS to remain asserted for
> the duration of a transfer.
With a slow enough clock you can probably get to a point where SFRMOUT
will stay deasserted during the entire 512 byte transfer. But it would
still de-assert during the switch to the next transfer in the message.
Regardless, I tend to agree with you. Because of the chip design, it's
impossible (or at least you can't guarantee) to keep the SFRMOUT low
during a transfer. Some devices can live with this others can't. Oh well.
A Documentation/spi/ep93xx_spi.txt really should be created to note this
limitation as well as showing an example of the platform support needed to
use this driver.
Regards,
Hartley
------------------------------------------------------------------------------
_______________________________________________
spi-devel-general mailing list
spi-devel-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/spi-devel-general
