[U-Boot] [PATCH] DaVinci: Improve DaVinci SPI speed.

[Nick Thompson <nick.thompson@ge.com>]

On 17/06/10 18:38, Delio Brignoli wrote:
> Hello Nick,
> 
> On 17/06/2010, at 17:02, Nick Thompson wrote:
>> On 01/06/10 12:36, Delio Brignoli wrote:
>>> I have updated this patch based on the comments [1] by Wolfgang Denk and 
>>> removed unused variables.
>>> [1][http://lists.denx.de/pipermail/u-boot/2010-May/071728.html]
> [...]
>> I have an alternative patch that tries to be even quicker, but I
>> don't have the same platform as Delio, so can't compare like with
>> like.
> 
> I will test your patch on my L138 and let you know.

That would be great, thanks - I'm using a SPANSION FLASH, though I
don't think that makes any difference. It your results are consistent
I will be more confident with my L137 platform as a comparison.

> 
>> In essence, it splits up read and write operations to avoid testing
>> pointers in every loop iteration. It also unrolls the last iteration
>> so that it doesn't have to test for loop ending twice each time
>> round. Finally it avoids bit setting/clearing on each iteration when
>> the results would only turn out to be the same anyway.
> 
> I am wondering if it is OK to split reading and writing: when I wrote
> the patch I assumed that spi_xfer() was supposed to be able to read and
> write to two distinct buffers at the same time. As I understand it, your
> patch allows spi_xfer() to be either a read or a write operation but not both 
> and I do not know if this semantic change is acceptable. Maybe Sekhar or 
> Sandeep can clarify this.

I wondered about that too. I don't think it matters for SPI FLASH, but I
guess it could for other SPI devices (Audio?).

I was thinking I could add a third routine 'read_write' that does both,
which only gets called if a bi-direction transfer is requested. This
would make the code even bigger, though it could be conditional on a
CONFIG option so it could be excluded if only FLASH support is required.

(I'm not sure if U-Boot uses SPI for anything else anyway...)

In the mean time, I have reads working at 1.76MiB/s. I need to read the
SPI manual carefully before I let that change into the wild though.
Basically, I've added an assumption that by the time the RX buffer is
ready with the returned bits, the TXer must have completed since they
run to the same clock: so no need to test for TX not full in the loop.

Nick.