From: arnd@arndb.de (Arnd Bergmann)
To: linux-arm-kernel@lists.infradead.org
Subject: Virtual addresses, ioremap, vmalloc, etc
Date: Tue, 01 Dec 2015 14:15:44 +0100 [thread overview]
Message-ID: <2755513.X6tENxzvXm@wuerfel> (raw)
In-Reply-To: <565D8DA9.8040700@free.fr>
On Tuesday 01 December 2015 13:08:09 Mason wrote:
> Hello everyone,
>
> I was wondering if someone could help clear my confusion.
>
> In my company's legacy port (based on 3.4, dating back to 2.6) someone
> chose to map the first 16 MB of physical addresses using:
>
> static struct map_desc tango_map_desc[] __initdata = {
> {
> .virtual = 0xf0000000,
> .pfn =__phys_to_pfn(0),
> .length = SZ_16M,
> .type = MT_DEVICE,
> },
> };
>
> static void __init tango_map_io(void)
> {
> iotable_init(tango_map_desc, ARRAY_SIZE(tango_map_desc));
> }
>
> Is the virtual address 0xf0000000 chosen arbitrary?
> Could I pick 0xf04200000 for example?
It is arbitrary, but normally should be naturally aligned.
> The same kernel, with no such boot-time mapping prints:
>
> [ 0.000000] Memory: 641720K/655360K available (3135K kernel code, 109K rwdata, 1056K rodata, 3044K init, 218K bss, 13640K reserved, 0K cma-reserve)
> [ 0.000000] Virtual kernel memory layout:
> [ 0.000000] vector : 0xffff0000 - 0xffff1000 ( 4 kB)
> [ 0.000000] fixmap : 0xffc00000 - 0xfff00000 (3072 kB)
> [ 0.000000] vmalloc : 0xe8800000 - 0xff000000 ( 360 MB)
> [ 0.000000] lowmem : 0xc0000000 - 0xe8000000 ( 640 MB)
>
> It looks like 0xf0000000 is in the middle of the vmalloc space.
> Is it a good idea to "statically" map something there?
We deal with that on a lof of platforms that still use a static
mapping. I normally advocate not using that kind of mapping unless
you can show a measurable performance difference on your platform.
> If I were to call ioremap(0, SZ_16M); at run-time, I would imagine
> the virtual address could be anywhere in the vmalloc space?
> There's no reason it would be 0xf0000000, right?
>
> In short, is virtual address 0xf0000000 special in any way?
> (Other than being in the vmalloc space perhaps.)
>
> For my own reference:
> https://www.kernel.org/doc/Documentation/arm/memory.txt
I think 0xf0000000 is a common choice because that made an easy
computation back in the days when most platforms used an
io_p2v() to get a hardcoded virtual address, rather than calling
ioremap as we do today.
Arnd
next prev parent reply other threads:[~2015-12-01 13:15 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-12-01 12:08 Virtual addresses, ioremap, vmalloc, etc Mason
2015-12-01 13:15 ` Arnd Bergmann [this message]
2015-12-01 14:35 ` Mason
2015-12-01 14:45 ` Arnd Bergmann
2015-12-01 14:50 ` Sebastian Frias
2015-12-01 16:30 ` Nicolas Pitre
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=2755513.X6tENxzvXm@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