[U-Boot] spi: cadence_qspi_apb: cache issues on mach-socfpga

Hi,
I ran into the same issue with the cadence qspi driver and dcache as Jason reported (in febuary, I think - I started to monitor U-Boot in july only).
May I ask what's the status here? I do need fixes for this to keep mach-socfpga running with qspi. I currently set dcache off globally and it works, but I still need the trigger-address fix (which is fixed by Jason's patch to use linux DT bindings).
Regarding the bounce buffer change: isn't it wrong to use the generic bounce buffer here? Given the dcache calls in it, it seems like this one is for DMA but we're doing cpu copy in the cadence qspi driver.
Anything I can do to get this pushed?
Thanks, Simon

Goldschmidt Simon wrote:
Hi,
I ran into the same issue with the cadence qspi driver and dcache as Jason reported (in febuary, I think - I started to monitor U-Boot in july only).
May I ask what's the status here? I do need fixes for this to keep mach-socfpga running with qspi. I currently set dcache off globally and it works, but I still need the trigger-address fix (which is fixed by Jason's patch to use linux DT bindings).
I don't believe the patchset I submitted for DT bindings were merged in.
Regarding the bounce buffer change: isn't it wrong to use the generic bounce buffer here? Given the dcache calls in it, it seems like this one is for DMA but we're doing cpu copy in the cadence qspi driver.
I tend to agree for the socfpga architecture; however, I'm not very familiar with the bounce buffer and dcache. From what I recall, it looked like the data is copied from the QSPI by the CPU on the socfpga so the data itself might be in the dcache? Then the call to bounce_buffer_stop invalidates the dcache, so the QSPI data that was there is now invalidated, and whatever random data in higher level memory is copied over the QSPI data.
Anything I can do to get this pushed?
Thanks, Simon
- Jason
participants (2)
-
Goldschmidt Simon
-
Rush, Jason A