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
Catalin,
Quoted 7 lines · Catalin Marinas
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.
Quoted 8 lines
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.
As things are today, I believe the Armada 370/XP/375/38x are always booted in secure mode. Couldn't the kernel detect if it's running secure or non-secure. If it's running secure, it can do all the ACTLR configuration (and other things that require being in secure mode). If it's running non-secure, then it doesn't do this configuration, and assumes the firmware/bootloader did it.
Quoted 6 lines
Quoted 6 lines
Quoted 6 lines
Quoted 5 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.Also, don't we have the same problem with the TTB_FLAGS_{SMP,UP) ?
Quoted 8 lines
Quoted 6 lines
Quoted 2 lines
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.
I got the confirmation. *But* this is only going to affect CONFIG_SMP builds. Armada 380 being single core, we want I/O coherency to work on it in !CONFIG_SMP configurations. And in !CONFIG_SMP configuration, it's always ALT_UP() that is used, regardless of what MPIDR says. And therefore the TTB_FLAGS_UP will be used.
Quoted 9 lines
Quoted 4 lines
Quoted 2 lines
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.
Ok. So I should keep going with the approach proposed in my patch series, obviously after fixing the various other comments that were posted?
Thanks,
Thomas
Signature · 3 lines
Thomas Petazzoni, CTO, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com