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 16 lines · Thomas Petazzoni
Quoted 6 lines · Catalin Marinas
Quoted 6 lines
Quoted 6 lines
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)Quoted 8 lines
Quoted 5 lines
Quoted 2 lines
What about setting this bit in the
firmware/bootloader? It's a sane initialisation firmware should do.I'm sorry, but I don't buy the "fix your bootloader" argument. For various reasons:
Well, for arm64 people should get used to this because I'm not taking code for setting up things like SCU and ACTLR during boot.
Quoted 6 lines
I have no problem about the bootloader doing some initialization, so if that's a requirement for arm64, no problem. But it should be a requirement regardless of the kernel configuration: in the current kernel, some initialization is done when
CONFIG_SMPis enabled. And now that the same initialization is needed in !CONFIG_SMP, I'm asked to do it in the bootloader. That's the thing I don't buy.
And that's a hard thing for me to sell for arm32 ;) because of the current code already doing this.
One of the issues is secure vs non-secure kernel deployment and secure-only registers like ACTLR (and even SCU). I've seen SoCs for which the mainline kernel assumes secure mode but it's deployed as non-secure in the field with out of tree modifications to make it work. I would rather have a single kernel image for both cases.
Quoted 4 lines
Quoted 4 lines
Quoted 4 lines
Unfortunately,
__create_page_tablesis called so early that I don't know if it's possible to access 'structmachine_desc' at this point to know whether the platform needs shareable pages or not.
Quoted 8 lines
Quoted 4 lines
Quoted 1 line
Also, don't we have the same problem with the TTB_FLAGS_{SMP,UP) ?
I don't think we do because we use the ALT_{SMP,UP} for TTB settings and we have the smp-on-up fixup running before
__v7_setup.Ok. For Armada 370, I don't need shareable pages. For Armada 380, I need shareable pages, but even if the processor is single core, I believe it pretends to be SMP in MPIDR.
You'd need to check this.
Quoted 10 lines
Quoted 8 lines
Quoted 5 lines
It's either it's *always* done by the
bootloader and we completely remove the SCU enabling code in the kernel, and add to the ARM boot protocol that enabling the SCU is the responsibility of the bootloader, or the kernel does the SCU enabling in all situations.I'm always for the former (and that's the case for arm64), though for some older boards it's too late to change.
Indeed. So how do we move forward?
As I said previously, it's not my call, just a recommendation. It's up to the arm/arm-soc maintainers to take this. Give the arm32 SMP initialisation precedent, forcing it for an existing platform is a harder sell.
Whether we want to set a policy for new arm32 SoCs is for a different thread.
Signature · 1 line
Catalin