RFC ARM core support for hardware I/O coherency in non-SMP platforms
Get series with b4
b4 am 20140515152553.GA30423@localhostVersions 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 19 lines · Rob Herring
Quoted 10 lines · Catalin Marinas
Quoted 8 lines · Thomas Petazzoni
Quoted 4 lines · Catalin Marinas
Quoted 1 line · Thomas Petazzoni
- The SCU must be enabled
Again, could the firmware do this?
See above. If the kernel does it for SMP cases, why wouldn't it do it also for !SMP I/O coherent cases?
Quoted 6 lines
The I/O coherency is an SoC property rather than an ARM architecture property. I want to separate the two so that the kernel can boot a significant part assuming sane architecture settings. Once you have DT available and start loading device drivers, you are in the SoC realm and you can do whatever initialisation for buses, interconnects, but not going back to change architected settings.
Quoted 2 lines
The SCU has nothing to do with the architecture and really is part of the SOC.
Indeed, it's not part of the architecture but I don't see it any different than other early configuration like SDRAM controller.
Quoted 4 lines
Let's look at this another way. Are there any usecases where you would not enable the SCU? If any cores are coherent or the ACP is coherent, it must be on. So that leaves all core in AMP mode. In this case, does it matter if the SCU is enabled or not?
I don't fully follow the question. You may not enable the SCU if you don't care at all about the SMP mode or other coherency like ACP. Otherwise it should be enabled, the latest before the secondaries start.
Signature · 1 line
Catalin