From: arnd@arndb.de (Arnd Bergmann)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 0/3] ARM: mvebu: disable I/O coherency on !SMP
Date: Thu, 17 Jul 2014 14:39:42 +0200 [thread overview]
Message-ID: <6510599.Qoc205T3v7@wuerfel> (raw)
In-Reply-To: <20140717083342.GS21766@n2100.arm.linux.org.uk>
On Thursday 17 July 2014 09:33:42 Russell King - ARM Linux wrote:
> On Thu, Jul 17, 2014 at 10:24:25AM +0200, Thomas Petazzoni wrote:
> > If I understand correctly, we are already changing the page tables
> > anyway, to switch certain pages to be mapped uncached, to do DMA
> > coherent allocations, no?
>
> I've no idea, I never looked at that code. I hope that Marek has
> considered the requirements of the architecture when creating that
> code...
>
> > 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.
>
> 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.
Is this different from what we do in the LPAE version of
early_paging_init()? That code already adjusts all the page
table entries on a per-platform setting and should be very
easy to extend for a modified procinfo->__cpu_mm_mmu_flags,
and possibly able to extend for traditional (non-LPAE)
page tables without a lot of duplication.
At the moment it only handles a platform-specific undetectable
PHYS_OFFSET for mach-keystone, which to me sounds equally
hacky as the platform-specific undetectable pmdprot value
for mvebu.
Is there anything I'm missing why one works and the other doesn't?
Arnd
next prev parent reply other threads:[~2014-07-17 12:39 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-07-02 16:21 [PATCH 0/3] ARM: mvebu: disable I/O coherency on !SMP Thomas Petazzoni
2014-07-02 16:21 ` [PATCH 1/3] ARM: mvebu: make the coherency_ll.S functions work with no coherency fabric Thomas Petazzoni
2014-07-02 16:21 ` [PATCH 2/3] ARM: mvebu: disable I/O coherency on non-SMP situations on Armada 370/XP Thomas Petazzoni
2014-07-02 16:21 ` [PATCH 3/3] ARM: mvebu: add missing of_node_put() call in coherency.c Thomas Petazzoni
2014-07-02 16:27 ` [PATCH 0/3] ARM: mvebu: disable I/O coherency on !SMP Andrew Lunn
2014-07-02 16:41 ` Russell King - ARM Linux
2014-07-02 17:18 ` Thomas Petazzoni
2014-07-02 17:58 ` Russell King - ARM Linux
2014-07-02 20:28 ` Thomas Petazzoni
2014-07-02 21:33 ` Russell King - ARM Linux
2014-07-02 21:50 ` Thomas Petazzoni
2014-07-17 8:24 ` Thomas Petazzoni
2014-07-17 8:33 ` Russell King - ARM Linux
2014-07-17 8:45 ` Thomas Petazzoni
2014-07-17 10:27 ` Russell King - ARM Linux
2014-07-17 10:16 ` Russell King - ARM Linux
2014-07-17 12:39 ` Arnd Bergmann [this message]
2014-07-17 13:12 ` Russell King - ARM Linux
2014-07-17 14:27 ` Will Deacon
2014-07-17 14:40 ` Arnd Bergmann
2014-07-17 15:34 ` Russell King - ARM Linux
2014-07-17 15:53 ` Arnd Bergmann
2014-07-17 16:04 ` Santosh Shilimkar
2014-07-17 16:10 ` Russell King - ARM Linux
2014-07-17 16:18 ` Santosh Shilimkar
2014-07-28 17:46 ` Will Deacon
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=6510599.Qoc205T3v7@wuerfel \
--to=arnd@arndb.de \
--cc=linux-arm-kernel@lists.infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox