ARM: mvebu: mvebu-mbus and I/O coherency fixes
Get series with b4
b4 am [email protected]Versions newest first
- v1 Latest0 of 6 patches 0 repliesNew
Patches in v1 No applies recorded yet
None of the 6 patches the cover letter announces are in this archive.
Reviews trailers per patch
No Reviewed-by, Acked-by or Tested-by trailers for v1 yet.
Cover letter [PATCH 0/6] ARM: mvebu: mvebu-mbus and I/O coherency fixes
Dear Andrew Lunn,
Quoted 2 lines · Andrew Lunn
[PATCH 1/6] dt: bindings: update mvebu-mbus DT binding with new branch dt for next merge window, since it is not strictly a fix.
Right.
Quoted 2 lines
[PATCH 2/6] bus: mvebu-mbus: fix support of MBus window 13 branch fixes for next -rc
Correct.
Quoted 2 lines
[PATCH 3/6] ARM: mvebu: fix compatible strings of MBus on Armada 375 and Armada 38x branch fixes for next -rc
Correct, since this is needed for PATCH 2/6 to work properly.
Quoted 3 lines
[PATCH 4/6] bus: mvebu-mbus: make sure SDRAM CS for DMA don't overlap the MBus bridge window branch drivers for next merge window. I assume it is only a run time dependency for the
mv_cesapatches?
Indeed, next merge window is good enough for this one: the mv_cesa patches have not even been posted yet. I'm not sure whether the mv_cesa stuff will be ready for 3.20, or 3.21 anyway. But having for sure this mvebu-mbus improvement already scheduled for 3.20 means one less dependency to handle when we'll submit the mv_cesa patches.
Quoted 2 lines
[PATCH 5/6] bus: mvebu-mbus: use automatic I/O synchronization barriers branch fixes for next -rc
Right.
Quoted 2 lines
[PATCH 6/6] ARM: mvebu: use
arm_coherent_dma_ops
Here i'm unsure. Is this a fix, or a cleanup?
It's a fix, because it is what brings this part of the cover letter:
* It allows to switch to use the existing arm_coherent_dma_ops instead of mvebu specific DMA operations. arm_coherent_dma_ops make sure that DMA coherent mappings are mapped cacheable (which is possible in a cache-coherent platform), which is a necessary to make sure that both CPU-side and device-side accesses are done in a cacheable way. Without this, CPU-side accesses to DMA coherent mappings were made uncached, while device-side accesses were made in a cacheable way, leading to potentially unpredictable behavior.
Which is really a fix. So it should go in 3.19-rc.
Thanks!
Thomas
Signature · 3 lines
Thomas Petazzoni, CTO, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com