[U-Boot] [PATCH 2/2] EXYNOS: SPI: Support SPI_PREAMBLE mode

[Simon Glass <sjg@chromium.org>]

Hi Vadim,

On Mon, May 6, 2013 at 10:01 AM, Vadim Bendebury <vbendeb@chromium.org> wrote:
> On Mon, May 6, 2013 at 7:37 AM, Simon Glass <sjg@chromium.org> wrote:
>>
>> HI Vadim,
>>
>> On Thu, May 2, 2013 at 11:12 PM, Vadim Bendebury <vbendeb@chromium.org> wrote:
>> > [the original patch removed, re-sending from a registered address]
>> >
>> > So, I spent some more time debugging a system which requires this
>> > patch: a system, where on a SPI interface a response to a command
>> > could come way later then the command data transmission completes.
>> >
>> > The original patch was trying to address many corner cases, but come
>> > to think of it, in this situation the slave does not care about extra
>> > data sent on the transmit interface, as otherwise there is no clock
>> > and no data could be transferred from the slave.
>> >
>> > Then, for this SPI interface we do not need to set the counter of
>> > clocks, and do not need to keep adding more clocks if the data has not
>> > been received yet, the clocks could be just free running. And then the
>> > patch becomes much simpler, what do you think:
>>
>> Does this deal with the performance problems that the old driver code
>> had? There were a number of other patches sent upstream by Rajeshwari
>> also. I wonder if it might be easier to do your improvement as a
>> separate patch on top of those instead. Then it can be considered on
>> its merits.
>>
>
> Hi Simon,
>
> what performance problems are there? Do you mean that u-boot is not
> fast enough when polling the SPI interface? I thought about this -
> even when clocking at 50MHz (resulting in 6.125 MB/s transfer rate)
> with 64 byte FIFOs there should be no problem when serving the
> interface, especially when receive and transmit flows are split in
> time.
>
> Have there been any evidence of performance problems?  Also, I noticed
> that the driver does not pay any respect to error conditions. I am
> planning to add error monitoring/processing code, as this would be a
> good way to know if there indeed are performance problems.

The issue is not the hardware but the software. Yes the hardware is
well able to keep up, but it does have some oddities. For example
reading the FIFO level registers seems to take a while, as does
reading/writing data to the FIFO.

I did a bit of benchmarking comparing the original upstream driver
with the driver after Rajeshwari's patches are applied. I posted that
to the list earlier today, but roughly speaking it is 100x faster, and
SPI boot time is reduced by about half a second. Unfortunately it is a
bit more complicated, but it is reliable and the code is well tested
with lots of units in the field :-)

Regards,
Simon