[U-Boot] [PATCH RESEND 0/7] spi: cadence_qspi: optimize & fix indirect rd-writes

[Stefan Roese]

Hi Vikas,

On 19.06.2015 23:38, Vikas MANOCHA wrote:
>>> - git bisect or cherry-pick to find out which patch is breaking the
>>>    read functionality.
>>
>> This one is the first introducing this breakage:
>>
>> spi: cadence_qspi: fix base trigger address & transfer start address
>>
>
> Ok, can you confirm applying patches upto (& including)
> "spi: cadence_qspi: fix indirect read/write start address" , read/write
>   to flash are working fine.

Please note that with this patch the code does not compile:

drivers/spi/cadence_qspi_apb.c: In function 'qpsi_write_sram_fifo_push':
drivers/spi/cadence_qspi_apb.c:227:32: error: 'struct 
cadence_spi_platdata' has no member named 'trigger_base'
   unsigned int *dest_addr = plat->trigger_base;

I've manually fixed this trivial change (trigger_base -> ahbbase) and 
tests with these patches applied show some problems with "sf" stability 
(bit-flips):

=> sf update 400000 100000 100000
1048576 bytes written, 0 bytes skipped in 34.196s, speed 31395 B/s
=> sf read 500000 100000 100000
SF: 1048576 bytes @ 0x100000 Read: OK
=> cmp.b 400000 500000 100000
byte at 0x0040001e (0x9f) != byte at 0x0050001e (0x8f)
Total of 30 byte(s) were the same

This is new - removing all your patches seems to solve this issue again. 
So there seems to be something wrong with the previous patches as well. 
here the output with the patches reverted:

=> sf probe
SF: Detected N25Q256 with page size 256 Bytes, erase size 4 KiB, total 
32 MiB
SF: Warning - Only lower 16MiB accessible, Full access #define 
CONFIG_SPI_FLASH_BAR
=> sf update 400000 100000 100000
1048576 bytes written, 0 bytes skipped in 35.872s, speed 29929 B/s
=> sf read 500000 100000 100000
SF: 1048576 bytes @ 0x100000 Read: OK
=> cmp.b 400000 500000 100000
Total of 1048576 byte(s) were the same

> The point is if after applying above mentioned patch (...: fix indirect read/write start address),
> Read/write are working fine, then trigger_base value of 0xFFA00_0000 should
> also work fine.
> Can you please modify the trigger_base value from 0x0 to 0xFFA0_0000 in
> Socfpga.dtsi & check.
> If it works, it would mean both (socfpga & stv0991) are behaving same.

No. With this change, the "sf read" command crashes / hangs on the 
SoCFPGA board.

Thanks,
Stefan