RFC ARM core support for hardware I/O coherency in non-SMP platforms

Quoted 31 lines · Catalin Marinas

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?

Quoted 3 lines

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.

My question is should the kernel unconditionally enable the SCU regardless of CONFIG_SMP or any other condition? Is there harm in enabling the SCU when in AMP mode?