public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Leif Lindholm <leif.lindholm@linaro.org>
To: Arnd Bergmann <arnd@arndb.de>
Cc: linux-arm-kernel@lists.infradead.org,
	Russell King - ARM Linux <linux@arm.linux.org.uk>,
	patches@linaro.org, linux-doc@vger.kernel.org,
	linux-kernel@vger.kernel.org, nico@linaro.org
Subject: Re: [PATCH 0/2] arm: add early_ioremap() support
Date: Thu, 27 Jun 2013 11:29:34 +0200	[thread overview]
Message-ID: <20130627092934.GD18151@rocoto.smurfnet.nu> (raw)
In-Reply-To: <3503040.vhYAL5xGgS@wuerfel>

On Thu, Jun 27, 2013 at 10:47:21AM +0200, Arnd Bergmann wrote:
> > No, the purpose is just like for x86 - do early parsing of things like
> > the UEFI system and configuration tables, DMI and ACPI, in order to
> > populate global structs and stuff.
> 
> But are those tables actually in MMIO registers? I thought they
> are just memory, and in that case using any form of ioremap is
> wrong on ARM. Why do you even have to map them? Can't the boot
> loader pass those tables in regular addressable memory?
 
Don't get too stuck on the name - x86 frequently uses *ioremap() in
many places when just accessing memory, and that has carried into EFI,
ACPI and DMI subsystems, which we now want to use on ARM. In fact, they
have early_memremap(), but don't use it for either EFI or ACPI.

The ia64 implementation actually performs a lookup in the EFI memmap
to decide whether early_ioremap() returns cacheable memory or not
(and falls back to noncacheable before memory map is available).

That said, I had somehow managed to get into my mind that the kernel
used -fno-unaligned-access, so thought MT_DEV_NONSHARED was safe.
Clearly it isn't, so that will need to change, making the semantic
match even worse...

As for the need of mapping - some of these descriptors are needed very
early in the boot process. Also, depending on platform, they may reside
at any offset from start of RAM (<2^32 physical address), rendering
__va()/__phys_to_virt()/... unusable.

> > Well, I did have a crazy idea that much/most of the early_ioremap code
> > could be made generic and shared between x86 and arm (and any other
> > 32-bit architecture). Using the fixmap macros would make that possible
> > with a minimum of ifdefs.
> > 
> > If we ever wanted early_ioremap() to work like on x86, beyond kmap_init()
> > (but not beyond the "booting" system state), using the same macros would
> > help there too. I had no need for that for my EFI patches.
> 
> I guess I need to look at the EFI patches first. It sounds to me
> like you shouldn't actually be using early_ioremap here or on another
> architecture.

No, but I had been kind of hoping not having to rework the early memory
initialisation for three subsystems on two other platforms in order to
be able to merge common code between them. And it would have felt silly
to invent a new mechanism just for ARM, preventing that option.

/
    Leif

  reply	other threads:[~2013-06-27  9:29 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-06-25 17:46 [PATCH 0/2] arm: add early_ioremap() support Leif Lindholm
2013-06-25 17:46 ` [PATCH 1/2] Documentation: arm: early_ioremap Leif Lindholm
2013-06-30  3:14   ` Rob Landley
2013-06-25 17:46 ` [PATCH 2/2] arm: add early_ioremap support Leif Lindholm
2013-06-26 18:52 ` [PATCH 0/2] arm: add early_ioremap() support Arnd Bergmann
2013-06-26 19:23   ` Leif Lindholm
2013-06-26 21:23     ` Arnd Bergmann
2013-06-26 21:34       ` Leif Lindholm
2013-06-26 22:13         ` Arnd Bergmann
2013-06-26 23:25           ` Leif Lindholm
2013-06-27  8:47             ` Arnd Bergmann
2013-06-27  9:29               ` Leif Lindholm [this message]
2013-06-27 11:55                 ` Arnd Bergmann

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=20130627092934.GD18151@rocoto.smurfnet.nu \
    --to=leif.lindholm@linaro.org \
    --cc=arnd@arndb.de \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@arm.linux.org.uk \
    --cc=nico@linaro.org \
    --cc=patches@linaro.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