On 5/19/23 18:07, John David Anglin wrote:
On 2023-05-16 2:00 p.m., Helge Deller wrote:
* John David Anglin <dave.anglin@xxxxxxxx>:
On 2023-05-16 3:09 a.m., Helge Deller wrote:
On 5/16/23 00:28, John David Anglin wrote:
On 2023-05-15 2:39 p.m., Helge Deller wrote:
+ case DMA_BIDIRECTIONAL:
+ flush_kernel_dcache_range(addr, size);
+ purge_kernel_dcache_range_asm(addr, addr + size);
I don't think flush and purge are both needed.
I'm not sure...
Just to fully understand it. Is this short summary correct: ?
- flush_kernel_dcache_range: flush cache back to memory, but keep data in cache.
No. If present, fdc writes addressed cache line to memory if and only if line is dirty. It
then invalidates line. It does not keep data in cache.
Next read loads from memory.
Next read fetches the data which is still in the cache, thus the next
read doesn't checks if data in memory has been modified in the meantime (e.g. via DMA).
- purge_kernel_dcache_range_asm: ignore currently cached data & drop any cached data in that range.
Even if cache has dirty memory which hasn't been written back yet, drop it and don't write back.
if present, pdc invalidates line. At privilege level zero, an implementation may optionally write
back a dirty line to memory. At non-zero privilege levels, fdc and pdc are effectively the same.
I don't know how to determine whether pdc does write back or not. It would be specified in processor
ERS.
Thanks for the explanation!
With that, I've attached an updated (untested) patch below.
Seems to work okay on c8000. Don't know if it helps performance.
Probably no performance change for c8000.
I noticed that pci-dma.c is only compiled on 32-bit kernels (for PCX-T machines) :-)
Helge
