From: arnd@arndb.de (Arnd Bergmann)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 0/2] arm: add early_ioremap() support
Date: Wed, 26 Jun 2013 20:52:09 +0200 [thread overview]
Message-ID: <201306262052.09640.arnd@arndb.de> (raw)
In-Reply-To: <1372182401-11029-1-git-send-email-leif.lindholm@linaro.org>
On Tuesday 25 June 2013, Leif Lindholm wrote:
> x86 and ia64 have the early_ioremap()/early_iounmap() functions, which are
> useful for supporting things like UEFI, ACPI and SMBIOS, where configuration
> tables need to be parsed before proper memory management is available,
> regardless of highmem status.
>
> This patchset implements a restricted form of early_ioremap(), available
> before paging_init() only. Like the x86 code on which it is based, it
> (p)re-uses the fixmap regions for its virtual mapping range. Up to 7
> simultaneous mappings of up to 128KB can be accommodated in the available
> fixmap space.
+rmk
I made a similar suggestion to extending the use of fixmap recently, see
"Re: SCU registers mapping for CA9/CA5 cores". Russell pointed out that
fixmap is intentionally limited to just kmap_atomic uses at the moment
and changing that would potentially have a significant impact when we
run out of pages in the fixmap area.
The method we use on ARM normally is the iotable_init() function, which
requires hardcoding a virtual address at the moment.
It might be nicer to change that code than to put early_ioremap into
fixmap. Note that early_ioremap in fixmap is a bit of a kludge on x86
as well because it is very much /not/ a fixed mapping like the rest
of fixmap, they just use it because it's convenient.
Extending the iotable mechanism on ARM would be the convenient
solution for us I think.
Arnd
WARNING: multiple messages have this Message-ID (diff)
From: Arnd Bergmann <arnd@arndb.de>
To: linux-arm-kernel@lists.infradead.org
Cc: Leif Lindholm <leif.lindholm@linaro.org>,
nico@linaro.org, patches@linaro.org,
linux-kernel@vger.kernel.org, linux-doc@vger.kernel.org,
"Russell King - ARM Linux" <linux@arm.linux.org.uk>
Subject: Re: [PATCH 0/2] arm: add early_ioremap() support
Date: Wed, 26 Jun 2013 20:52:09 +0200 [thread overview]
Message-ID: <201306262052.09640.arnd@arndb.de> (raw)
In-Reply-To: <1372182401-11029-1-git-send-email-leif.lindholm@linaro.org>
On Tuesday 25 June 2013, Leif Lindholm wrote:
> x86 and ia64 have the early_ioremap()/early_iounmap() functions, which are
> useful for supporting things like UEFI, ACPI and SMBIOS, where configuration
> tables need to be parsed before proper memory management is available,
> regardless of highmem status.
>
> This patchset implements a restricted form of early_ioremap(), available
> before paging_init() only. Like the x86 code on which it is based, it
> (p)re-uses the fixmap regions for its virtual mapping range. Up to 7
> simultaneous mappings of up to 128KB can be accommodated in the available
> fixmap space.
+rmk
I made a similar suggestion to extending the use of fixmap recently, see
"Re: SCU registers mapping for CA9/CA5 cores". Russell pointed out that
fixmap is intentionally limited to just kmap_atomic uses at the moment
and changing that would potentially have a significant impact when we
run out of pages in the fixmap area.
The method we use on ARM normally is the iotable_init() function, which
requires hardcoding a virtual address at the moment.
It might be nicer to change that code than to put early_ioremap into
fixmap. Note that early_ioremap in fixmap is a bit of a kludge on x86
as well because it is very much /not/ a fixed mapping like the rest
of fixmap, they just use it because it's convenient.
Extending the iotable mechanism on ARM would be the convenient
solution for us I think.
Arnd
next prev parent reply other threads:[~2013-06-26 18:52 UTC|newest]
Thread overview: 31+ 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 ` Leif Lindholm
2013-06-25 17:46 ` [PATCH 1/2] Documentation: arm: early_ioremap Leif Lindholm
2013-06-25 17:46 ` Leif Lindholm
2013-06-30 3:14 ` Rob Landley
2013-06-30 3:14 ` Rob Landley
2013-06-25 17:46 ` [PATCH 2/2] arm: add early_ioremap support Leif Lindholm
2013-06-25 17:46 ` Leif Lindholm
2013-06-26 18:52 ` Arnd Bergmann [this message]
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 19:23 ` Leif Lindholm
2013-06-26 21:23 ` Arnd Bergmann
2013-06-26 21:23 ` Arnd Bergmann
2013-06-26 21:34 ` Leif Lindholm
2013-06-26 21:34 ` Leif Lindholm
2013-06-26 22:13 ` Arnd Bergmann
2013-06-26 22:13 ` Arnd Bergmann
2013-06-26 23:25 ` Leif Lindholm
2013-06-26 23:25 ` Leif Lindholm
2013-06-27 8:47 ` Arnd Bergmann
2013-06-27 8:47 ` Arnd Bergmann
2013-06-27 9:29 ` Leif Lindholm
2013-06-27 9:29 ` Leif Lindholm
2013-06-27 11:55 ` Arnd Bergmann
2013-06-27 11:55 ` Arnd Bergmann
-- strict thread matches above, loose matches on Subject: below --
2014-07-09 9:39 [PATCH 0/2] arm: add early_ioremap support Leif Lindholm
2014-07-09 9:42 ` Russell King - ARM Linux
2014-07-09 9:58 ` Leif Lindholm
2014-07-09 9:47 ` Will Deacon
2014-07-09 10:02 ` Leif Lindholm
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=201306262052.09640.arnd@arndb.de \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.