public inbox for linux-arm-kernel@lists.infradead.org
 help / color / mirror / Atom feed
From: arnd@arndb.de (Arnd Bergmann)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCHv3 2/5] ARM: mvebu: disable I/O coherency on non-SMP situations on Armada 370/375/38x/XP
Date: Thu, 13 Nov 2014 11:53:19 +0100	[thread overview]
Message-ID: <1582668.V5SXEARn2a@wuerfel> (raw)
In-Reply-To: <20141113111730.705f9ca1@free-electrons.com>

On Thursday 13 November 2014 11:17:30 Thomas Petazzoni wrote:
> On Thu, 13 Nov 2014 11:10:07 +0100, Arnd Bergmann wrote:
> 
> > Seems fine to me. I was hoping to solve this with the introduction
> > of the CONFIG_ARCH_MULTIPLATFORM_STRICT or CONFIG_BROKEN_MULTIPLATFORM
> > setting that would allow us to have a compile-time setting to make it
> > work on UP (while possibly breaking or slowing down other machines
> > in a multiplatform kernel), but Russell didn't like the idea.
> 
> Right. Unfortunately, I don't currently see a good way of handling such
> a case, other than having the C code at some point in the
> initialization re-create all the page tables that were set up by the
> assembly code. The basic problem here is that I need access to an
> information located in the Device Tree at a moment where the DT isn't
> available. So there are two options: 1/ make the DT available earlier,
> but it really seems impractical to manipulate the DT in the
> early assembly code, or 2/ make sure that the initialization done in
> the assembly code can be overridden later.
> 
> What do you think?

IIRC there is still an unsolved problem on mach-keystone that is somewhat
related, they also have to change the page tables and the current method
appears to be racy. Once that is solved, you might be able to do 2.

The approach I had in mind was much simpler, introducing a compile-time
option that hardcodes the behavior you need for Armada-370 when set,
knowing that you should not set that on any kernel that is supposed to
run on other platforms.

	Arnd

  reply	other threads:[~2014-11-13 10:53 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-11-13  9:38 [PATCHv3 0/5] ARM: mvebu: no I/O coherency on non-SMP and related updates Thomas Petazzoni
2014-11-13  9:38 ` [PATCHv3 1/5] ARM: mvebu: make the coherency_ll.S functions work with no coherency fabric Thomas Petazzoni
2014-11-13  9:38 ` [PATCHv3 2/5] ARM: mvebu: disable I/O coherency on non-SMP situations on Armada 370/375/38x/XP Thomas Petazzoni
2014-11-13 10:10   ` Arnd Bergmann
2014-11-13 10:17     ` Thomas Petazzoni
2014-11-13 10:53       ` Arnd Bergmann [this message]
2014-11-13 10:58         ` Thomas Petazzoni
2014-11-13  9:38 ` [PATCHv3 3/5] ARM: mvebu: remove unused register offset definition Thomas Petazzoni
2014-11-13  9:38 ` [PATCHv3 4/5] ARM: mvebu: remove Armada 375 Z1 workaround for I/O coherency Thomas Petazzoni
2014-11-13  9:39 ` [PATCHv3 5/5] ARM: mvebu: update comments in coherency.c Thomas Petazzoni
2014-11-13  9:48 ` [PATCHv3 0/5] ARM: mvebu: no I/O coherency on non-SMP and related updates Thomas Petazzoni
2014-11-22  1:56 ` Jason Cooper

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=1582668.V5SXEARn2a@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