[PATCH 0/3] ARM: mvebu: disable I/O coherency on !SMP
thomas.petazzoni at free-electrons.com
Wed Jul 2 14:50:25 PDT 2014
On Wed, 2 Jul 2014 22:33:40 +0100, Russell King - ARM Linux wrote:
> That's where having a separate processor struct comes in (which we
> already have for the pj4b) and having a separate switch_mm which knows
> to set the TTB flags to write allocate.
> You're assuming that I remember all the details each time... I know
> that you have sent me several times all the details about what each
> Armada device requires, and each time I've briefly read it and thought
> "yes, I must get to that" and then never have done. That's why we're
> not making progress - I haven't had the time to read and digest your
> messages properly. For example, if you asked me right now what
> Armada XP requires, whether it's SMP or not, I really couldn't tell
That's surely something I understand perfectly. It took me a while to
get in my head all the requirements of the various SoCs, so I certainly
understand that someone not working on a daily with only those specific
SoCs can easily lose track of what each SoC requires.
Maybe I should write up a summary document/web-page of the requirements
of each SoC, with their identifier values, all progressively add all
the relevant details as the discussion progresses.
> Right, so you're using pj4b_processor_functions here.
> #ifdef CONFIG_CPU_PJ4B
> globl_equ cpu_pj4b_switch_mm, cpu_v7_switch_mm
> globl_equ cpu_pj4b_set_pte_ext, cpu_v7_set_pte_ext
> globl_equ cpu_pj4b_proc_init, cpu_v7_proc_init
> So we need to delete the first (switch_mm) so we can replace it. I
> think we may need a second set of processor functions to deal with
> the MP version as well. Most of these would need to be aliased
> to the cpu_pj4b versions, except for the switch_mm one too.
> You may wish to consider changing switch_mm to look something like the
> following. I'm assuming that for pj4b you just need WBWA for both
> the inner and the outer, but not the shared bit - you'll need to change
> that if it needs something else:
> orr r0, r0, #TTB_IRGN_WBWA | TTB_RGN_OC_WBWA
> b 1f
> orr r0, r0, #TTB_FLAGS_SMP
> b 1f
> #ifdef CONFIG_MMU
> ALT_SMP(orr r0, r0, #TTB_FLAGS_SMP)
> ALT_UP(orr r0, r0, #TTB_FLAGS_UP)
> 1: mmid r1, r1 @ get mm->context.id
> mov r2, #0
> #ifdef CONFIG_ARM_ERRATA_430973
> mcr p15, 0, r2, c7, c5, 6 @ flush BTAC/BTB
> That gets rid of the one in the switch_mm path. The setup
> function is much more icky.
> I think __v7_setup needs splitting up - especially due to all the
> errata in there. I think we ought to add a whole load of processor
> proc_info's - for ARM Cortex-A8, Cortex-A9, Cortex-A15 etc. Each
> one calls a separate setup function which runs only the appropriate
> errata fixups for that core (which eliminates a load of testing in
> This also means we can split the v7_ttb_setup macro and change it
> to be per CPU. (I'm not entirely convinced right now that TTB1
> isn't initialised with an undefined value - I can't see where r8
> is setup amongst the mess that this has turned into.
> I'm not sure what this means for the 3level v7 code - that's something
> I've never looked at except a brief glance when it went in. The
> v7_ttb_setup there looks rather complicated and might make the changes
> I outlined above much harder. That also isn't something I can play
> around with because I've never been able to get Linux running on the
> Versatile Express with the CPU card that would support that code. We
> may need to enlist Catalin's help to modify that code.
> That's about the best guidance I can give this evening, and I hope
> it helps you.
Wow, thanks a lot for all those details. It'll also take me a little
while to digest these informations, and see what I can implement based
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
More information about the linux-arm-kernel