ARM: mvebu: disable I/O coherency on !SMP
Get series with b4
b4 am [email protected]Versions newest first
- v1 Latest0 of 3 patches 0 repliesNew
Patches in v1 No applies recorded yet
None of the 3 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 [PATCH 0/3] ARM: mvebu: disable I/O coherency on !SMP
Russell,
Quoted 10 lines · Russell King - ARM Linux
Quoted 5 lines
So wouldn't it be possible to keep the early
assembly code as it is today, and then later, in C code, once we have identified the platform on which we're running, modify the page tables to switch to the appropriate page attributes (write allocate cache policy, shareable attribute, etc.) ?No - the problem is that we're running from the page table in question with global mappings, and we need to switch all these mappings, including the ones we're currently using to execute from.
Quoted 7 lines
We can't even create a new page table and switch to it because the mappings in question are global mappings.
The only way to do that safely from an architectural point of view would be to turn the MMU off, and drop back to assembly code to change the page tables, and re-enable the MMU. For something as obscure as Marvell's coherency stuff, that's not something I want to see in core code.
That's indeed tricky. But then, if we don't find solutions to support in mainline the features of those SoCs, why are we asking all those SoC vendors to push their code mainline?
As far as I can see, the conclusion of this discussion seems to be that there is no solution that looks acceptable to you to support the hardware I/O coherency functionality in mainline. I am trying hard to get Marvell to stop using their evil vendor tree as much as possible, but the message we're sending here is basically exactly the opposite:
we're telling them that there's no way to properly support hardware I/O coherency in mainline and that the only solution for them is to keep their evil vendor tree. Is this really what we want?
Best regards,
Thomas
Signature · 3 lines
Thomas Petazzoni, CTO, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com