RFC ARM core support for hardware I/O coherency in non-SMP platforms
Get series with b4
b4 am [email protected]Versions newest first
- v1 RFC Latest0 of 7 patches 0 repliesNew
Patches in v1 No applies recorded yet
None of the 7 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 [RFC PATCHv1 0/7] ARM core support for hardware I/O coherency in non-SMP platforms
Quoted 6 lines · Thomas Petazzoni
This hardware I/O coherency mechanism needs a set of ARM core requirements to operate properly:
* On Armada 370 (a single core processor)
- The cache policy of pages must be set to "write allocate".
Arguably, I would make this the default for ARMv6+ CPUs even if UP. It's a hint that the CPU may or may not ignore but it shouldn't break anything (well, maybe some artificial benchmarks designed to show that write-allocate caches are bad).
[...]
Quoted 5 lines
* On Armada 375/38x (which have single core and dual core variants)
- The cache policy of pages must be set to "write allocate".
- The SMP and TLB broadcast bits must be set in the Auxiliary Control Register (the core is a Cortex-A9)
What about setting this bit in the firmware/bootloader? It's a sane initialisation firmware should do.
Quoted 1 line
- The pages must be set as shareable.
Here you may have some conflict between the initial page tables set in __create_page_tables as non-shareable (that's unless MPIDR shows it as SMP but I guess not since smp-on-up kicks in). I have to think a bit more about the implications (the ARM ARM has a chapter on mismatched memory attributes and I think it talks about shareable vs non-shareable).
Quoted 1 line
- The SCU must be enabled
Again, could the firmware do this?
Signature · 1 line
Catalin