ioremap to a specific virtual address
Nicolas Pitre
nico at fluxnic.net
Fri Mar 23 00:00:51 EDT 2012
On Thu, 22 Mar 2012, jonsmirl at gmail.com wrote:
> When iotable is used to initially map memory you can specify the
> mapping address. In this case IO_SDMMC_PHYS is 0x18000000 and it gets
> mapped to 0xf1800000
>
> NXP has supplied this handly macro
> #define io_p2v(x) (0xf0000000 | (((x) & 0xff000000) >> 4) | ((x) & 0x000fffff))
>
> iotable_init(lpc313x_io_desc, ARRAY_SIZE(lpc313x_io_desc));
>
> {
> .virtual = io_p2v(IO_SDMMC_PHYS),
> .pfn = __phys_to_pfn(IO_SDMMC_PHYS),
> .length = IO_SDMMC_SIZE,
> .type = MT_DEVICE
> },
>
> The supplied kernel is full of code that uses this type of addressing.
> It has macros for register definition that all depend on the registers
> being mapped to a well know location - io_p2v(x).
>
> I'd like to move the map out of the core code and into the SDMMC
> device driver and then only do it if the driver loads.
Why would you do that? Those static mappings are meant to be global and
remain there. The handy macro is in fact not handy at all as it forces
virtual addresses on you.
It is OK to keep the static mappings as you can use 1MB regions and the
mapping code will use first level mappings which are better with TLB
usage.
But drivers should really be using:
iobase = ioremap(IO_SDMMC_PHYS);
and the various registers should be defined as offsets from that base.
Then you would use:
val = readl(iobase + SDMMC_FOO_REG);
where you could have:
#define SDMMC_FOO_REG 0x10
With a recent kernel, the ioremap code will reuse any static mappings
that matches the physical address you give it, or create a new mapping
otherwise. But in either cases the actual virtual address used
shouldn't matter anymore.
Nicolas
More information about the linux-arm-kernel
mailing list