ioremap to a specific virtual address

ioremap to a specific virtual address

[jonsmirl at gmail.com]

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.  Is there some
way to ioremap to a specific address on ARM? Or is there another way
to build the mapping in the driver?

-- 
Jon Smirl
jonsmirl at gmail.com

ioremap to a specific virtual address

[Nicolas Pitre]

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

ioremap to a specific virtual address

[jonsmirl at gmail.com]

On Fri, Mar 23, 2012 at 12:00 AM, Nicolas Pitre <nico@fluxnic.net> wrote:
> 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.

I'm ok with global static mappings. What I'd like to do is build the
static iotable from the device tree instead of repeating every device
in the map_desc array. I suppose I could dynamically allocate it, fill
it in from the device tree and call iotable_init().

What is the right way to make the initial static mappings?

>
> 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.

CPU is arm926ejs. Peripherals are small blocks spread out on 16MB
boundaries. There are eleven groups.

>
> But drivers should really be using:

This is the style I'm used too. I'll assess how much work it is to
convert everything.

>
> ? ? ? ?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



-- 
Jon Smirl
jonsmirl at gmail.com

ioremap to a specific virtual address

[Nicolas Pitre]

On Fri, 23 Mar 2012, jonsmirl at gmail.com wrote:

> On Fri, Mar 23, 2012 at 12:00 AM, Nicolas Pitre <nico@fluxnic.net> wrote:
> > 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.
> 
> I'm ok with global static mappings. What I'd like to do is build the
> static iotable from the device tree instead of repeating every device
> in the map_desc array. I suppose I could dynamically allocate it, fill
> it in from the device tree and call iotable_init().

Well, if you have a device tree with that stuff, then you may as well 
just forget about the static mappings.

> What is the right way to make the initial static mappings?

Typically by declaring it in the code.  Otherwise there is some 
infrastructure already in place for drivers to map their hardware 
dynamically from DT information.


Nicolas

ioremap to a specific virtual address

[jonsmirl at gmail.com]

On Fri, Mar 23, 2012 at 12:28 AM, Nicolas Pitre <nico@fluxnic.net> wrote:
> On Fri, 23 Mar 2012, jonsmirl at gmail.com wrote:
>
>> On Fri, Mar 23, 2012 at 12:00 AM, Nicolas Pitre <nico@fluxnic.net> wrote:
>> > 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.
>>
>> I'm ok with global static mappings. What I'd like to do is build the
>> static iotable from the device tree instead of repeating every device
>> in the map_desc array. I suppose I could dynamically allocate it, fill
>> it in from the device tree and call iotable_init().
>
> Well, if you have a device tree with that stuff, then you may as well
> just forget about the static mappings.
>
>> What is the right way to make the initial static mappings?
>
> Typically by declaring it in the code. ?Otherwise there is some
> infrastructure already in place for drivers to map their hardware
> dynamically from DT information.

So there are two ways to build these mappings..

1) At init time. I can extract the 11 regions, dynamically build a
'struct map_desc' and call iotable_init. Doing it at init time via the
device tree will work, but it is complicated by the existence of nodes
in the device tree that have their status set to disabled. The init
time code will need to sort this out which duplicates what the driver
load system does.

2) Driver load time. This is why I asked the initial question about
how to do ioremap to the specific virtual address. I didn't want to
rewrite all of the existing code to use the more normal style of
mapping. So is there some way to create the static mapping at a
specific address when the driver first loads?

Is there any real advantage to doing the mapping at init time other
than being able to control which virtual address you get?

I can start looking at how much code needs to be converted to the base
+ offset model. One advantage to converting is that I'll get an
immediate GPF each time I mess up. Converting the code will let it
work with the random address from ioremap.

This is a NXP BSP for the lpc31xx from about three years ago. I've
forward ported it up to v3.3 and I want to get device tree going in
it. We have products based on this chip and I'd like to be able to
build a single kernel that works in all of the various configurations.






-- 
Jon Smirl
jonsmirl at gmail.com

ioremap to a specific virtual address

[Arnd Bergmann]

On Friday 23 March 2012, jonsmirl at gmail.com wrote:
> So there are two ways to build these mappings..
> 
> 1) At init time. I can extract the 11 regions, dynamically build a
> 'struct map_desc' and call iotable_init. Doing it at init time via the
> device tree will work, but it is complicated by the existence of nodes
> in the device tree that have their status set to disabled. The init
> time code will need to sort this out which duplicates what the driver
> load system does.

There is nothing wrong with setting up the static mappings at boot
time for all devices, you don't need to check whether they are actually
present. I would assume that you have plenty of virtual address space
on lpc31xx, given that those machines tend to come with rather little
physical memory.

> 2) Driver load time. This is why I asked the initial question about
> how to do ioremap to the specific virtual address. I didn't want to
> rewrite all of the existing code to use the more normal style of
> mapping. So is there some way to create the static mapping at a
> specific address when the driver first loads?
> 
> Is there any real advantage to doing the mapping at init time other
> than being able to control which virtual address you get?

The main reason why we do it in a lot of drivers is to allow the
drivers to be used across multiple platforms that have the devices
at a different location. We will soon (for some definition of that
term) have multiplatform kernels that can run e.g. on lpc31xx and
lpc32xx, and those two families can have the same devices at a different
memory location, or could have a different number of devices of
the same kind.

In particular, in order to enable the multiplatform kernel, we have
to restrict access of device drivers to platform specific header file
in all cases where those have conflicting contents.

> I can start looking at how much code needs to be converted to the base
> + offset model. One advantage to converting is that I'll get an
> immediate GPF each time I mess up. Converting the code will let it
> work with the random address from ioremap.
> 
> This is a NXP BSP for the lpc31xx from about three years ago. I've
> forward ported it up to v3.3 and I want to get device tree going in
> it. We have products based on this chip and I'd like to be able to
> build a single kernel that works in all of the various configurations.

I think you should work together with Roland Stigge, who is currently
looking into doing the same for lpc32xx. My guess is that you can save
a lot of work by combining your efforts, while you would get conflicting
DT bindings if you don't. Note that Roland has done a lot of patches
already for nxp device drivers that will be part of v3.4. He has not yet
started on DT patches but wants to work on that for v3.5.

	Arnd

ioremap to a specific virtual address

[jonsmirl at gmail.com]

On Fri, Mar 23, 2012 at 10:07 AM, Arnd Bergmann <arnd@arndb.de> wrote:
> On Friday 23 March 2012, jonsmirl at gmail.com wrote:
>> So there are two ways to build these mappings..
>>
>> 1) At init time. I can extract the 11 regions, dynamically build a
>> 'struct map_desc' and call iotable_init. Doing it at init time via the
>> device tree will work, but it is complicated by the existence of nodes
>> in the device tree that have their status set to disabled. The init
>> time code will need to sort this out which duplicates what the driver
>> load system does.
>
> There is nothing wrong with setting up the static mappings at boot
> time for all devices, you don't need to check whether they are actually
> present. I would assume that you have plenty of virtual address space
> on lpc31xx, given that those machines tend to come with rather little
> physical memory.
>
>> 2) Driver load time. This is why I asked the initial question about
>> how to do ioremap to the specific virtual address. I didn't want to
>> rewrite all of the existing code to use the more normal style of
>> mapping. So is there some way to create the static mapping at a
>> specific address when the driver first loads?
>>
>> Is there any real advantage to doing the mapping at init time other
>> than being able to control which virtual address you get?
>
> The main reason why we do it in a lot of drivers is to allow the
> drivers to be used across multiple platforms that have the devices
> at a different location. We will soon (for some definition of that
> term) have multiplatform kernels that can run e.g. on lpc31xx and
> lpc32xx, and those two families can have the same devices at a different
> memory location, or could have a different number of devices of
> the same kind.
>
> In particular, in order to enable the multiplatform kernel, we have
> to restrict access of device drivers to platform specific header file
> in all cases where those have conflicting contents.

Isn't this a symptom of not having device trees? If the devices are
identical the header files should be identical except for the base
address. The device tree allows you to get that base address out of
the header file.

Assuming that we can clear up the conflicts in the header files, then
wouldn't it make sense to use ioremap in the  driver, let it assign a
random address, and then fix my code to the base+offset model?


>> I can start looking at how much code needs to be converted to the base
>> + offset model. One advantage to converting is that I'll get an
>> immediate GPF each time I mess up. Converting the code will let it
>> work with the random address from ioremap.
>>
>> This is a NXP BSP for the lpc31xx from about three years ago. I've
>> forward ported it up to v3.3 and I want to get device tree going in
>> it. We have products based on this chip and I'd like to be able to
>> build a single kernel that works in all of the various configurations.
>
> I think you should work together with Roland Stigge, who is currently
> looking into doing the same for lpc32xx. My guess is that you can save
> a lot of work by combining your efforts, while you would get conflicting
> DT bindings if you don't. Note that Roland has done a lot of patches
> already for nxp device drivers that will be part of v3.4. He has not yet
> started on DT patches but wants to work on that for v3.5.

I will need to check how similar the chips actually are. NXP did not
use primecells in the lpc31xx family.

I'd be happy to have some help. My trees are here:
https://github.com/jonsmirl

I haven't pushed out my device tree support because it doesn't work
yet. Its about half finished. Roland, check out the SPL support in
u-boot for the lpc31xx.

>
> ? ? ? ?Arnd



-- 
Jon Smirl
jonsmirl at gmail.com

ioremap to a specific virtual address

[Arnd Bergmann]

On Friday 23 March 2012, jonsmirl at gmail.com wrote:
> > In particular, in order to enable the multiplatform kernel, we have
> > to restrict access of device drivers to platform specific header file
> > in all cases where those have conflicting contents.
> 
> Isn't this a symptom of not having device trees? If the devices are
> identical the header files should be identical except for the base
> address. The device tree allows you to get that base address out of
> the header file.

Well, device trees are not the only solution that works for this.
You can also get the base address out of statically declared platform
devices in the platform code. The problem here is not the lack
of device trees, but code that is not written to be run time
configured. Moving to device tree requires the same changes though.

> Assuming that we can clear up the conflicts in the header files, then
> wouldn't it make sense to use ioremap in the  driver, let it assign a
> random address, and then fix my code to the base+offset model?

I think that is the right solution in any case, as it helps with
both the multiplatform kernels and device trees.

	Arnd

ioremap to a specific virtual address

[Roland Stigge]

Hi Jon,

On 23/03/12 15:07, Arnd Bergmann wrote:
> I think you should work together with Roland Stigge, who is currently
> looking into doing the same for lpc32xx. My guess is that you can save
> a lot of work by combining your efforts, while you would get conflicting
> DT bindings if you don't. Note that Roland has done a lot of patches
> already for nxp device drivers that will be part of v3.4. He has not yet
> started on DT patches but wants to work on that for v3.5.

You wrote about NXP's BSP from 3 years ago. At git.lpclinux.com, you can
find lpc31xx's branches, updated only some weeks ago, based on Linux 2.6.33.

Feel free to join my efforts for DT on lpc32xx. Don't know how much
lpc31xx and lpc32xx have in common, and I currently don't have access to
an lpc31xx device. However, I will post patches for DT support on
lpc32xx, based on the patches I already have at git.antcom.de and
antcom.de/lpc32xx/ (some of which already go into v3.4).

Thanks,

Roland

ioremap to a specific virtual address

[jonsmirl at gmail.com]

On Fri, Mar 23, 2012 at 10:52 AM, Roland Stigge <stigge@antcom.de> wrote:
> Hi Jon,
>
> On 23/03/12 15:07, Arnd Bergmann wrote:
>> I think you should work together with Roland Stigge, who is currently
>> looking into doing the same for lpc32xx. My guess is that you can save
>> a lot of work by combining your efforts, while you would get conflicting
>> DT bindings if you don't. Note that Roland has done a lot of patches
>> already for nxp device drivers that will be part of v3.4. He has not yet
>> started on DT patches but wants to work on that for v3.5.
>
> You wrote about NXP's BSP from 3 years ago. At git.lpclinux.com, you can
> find lpc31xx's branches, updated only some weeks ago, based on Linux 2.6.33.

I've taken the 2.6.33 code and forward ported it to v3.3 in my git
tree. I've been incorporating the patches posted to lpclinux.com.

>
> Feel free to join my efforts for DT on lpc32xx. Don't know how much
> lpc31xx and lpc32xx have in common, and I currently don't have access to

Bangaragiri --- which peripherals do the lpc31xx and the lpc32xx
families have in common?

I know I2C is common and the lpc31xx uses the common driver.
LCD is completely different.
No Ethernet on the lpc31xx.

What about USB? There is code for a NXP variation on EHCI in the
lpc31xx port, does the lpc32xx use the same EHCI block?

Does the lpc32xx have the same event router for interrupts?

What about the rest of the peripherals?

> an lpc31xx device. However, I will post patches for DT support on
> lpc32xx, based on the patches I already have at git.antcom.de and
> antcom.de/lpc32xx/ (some of which already go into v3.4).
>
> Thanks,
>
> Roland



-- 
Jon Smirl
jonsmirl at gmail.com

ioremap to a specific virtual address

[Roland Stigge]

On 23/03/12 16:05, jonsmirl at gmail.com wrote:
> I've taken the 2.6.33 code and forward ported it to v3.3 in my git
> tree. I've been incorporating the patches posted to lpclinux.com.

Similar to what I did with lpc32xx. :-) NXP maintains lpc31xx and
lpc32xx at different repos, though.

> What about USB? There is code for a NXP variation on EHCI in the
> lpc31xx port, does the lpc32xx use the same EHCI block?

LPC32xx only has OHCI. For v3.4, I joined ohci-pnx4008 and ohci-lpc32xx
into ohci-nxp since only some transceiver I2C initialization was different.

Roland

ioremap to a specific virtual address

[Arnd Bergmann]

On Friday 23 March 2012, jonsmirl at gmail.com wrote:
> I will need to check how similar the chips actually are. NXP did not
> use primecells in the lpc31xx family.
> 
> I'd be happy to have some help. My trees are here:
> https://github.com/jonsmirl

I've taken a brief look at your tree, some comments:

* Once you're done with the DT conversion, you should be able to
  completely remvoe the three board files. You probably know that already

* We're merging the new common clock framework in v3.4. Once that has
  matured, all new platforms will be required to use it. You should probably
  move to that already.

* The dma driver uses a nonstandard interface and should be moved to
  drivers/dma, using the dmaengine API.

* The __REG needs to be removed. All MMIO register accesses should go
  through readl/writel or readl_relaxed/writel_relaxed, using a pointer
  you get from ioremap.

* gpio*.c should get moved to drivers/gpio/gpio-lpc31xx. If it's similar
  to the 32xx version, merge the two

* i2c.c should no longer be needed with the device tree, but you might
  have to add stuff to i2c-pnx.c. That file is shared with pnx4008 and
  lpc32xx.

* irq.c will eventually go to drivers/irqchip/. We have a plan to create
  that directory, but nobody has started moving drivers there.

* Some of the header files have been removed on other platforms, you
  should do the same.

* Regarding the static mappings, it certainly makes sense to map all of
  ABP01_PHYS and IO_APB2_PHYS using 1MB mappings, for performance reasons,
  and I guess you need INTC_PHYS to be mapped, too, for the interrupt
  controller code to work. However, none of the drivers should be aware
  of this and just call ioremap anyway, which will now return an address
  from the static mapping.

	Arnd

ioremap to a specific virtual address

[jonsmirl at gmail.com]

On Fri, Mar 23, 2012 at 11:20 AM, Arnd Bergmann <arnd@arndb.de> wrote:
> On Friday 23 March 2012, jonsmirl at gmail.com wrote:
>> I will need to check how similar the chips actually are. NXP did not
>> use primecells in the lpc31xx family.
>>
>> I'd be happy to have some help. My trees are here:
>> https://github.com/jonsmirl
>
> I've taken a brief look at your tree, some comments:
>
> * Once you're done with the DT conversion, you should be able to
> ?completely remvoe the three board files. You probably know that already

Thanks for the feedback.

I don't think I can completely remove the board files. Some of the
generic devices have board specific callbacks. DM9000 for example. I
am setting up of_dev_auxdata for the boards so that I can pass these
callbacks in.

# define DM_IO_DELAY()	do { gpio_get_value(GPIO_MNAND_RYBN3);} while(0)

static void dm9000_dumpblk(void __iomem *reg, int count)
{
	int i;
	int tmp;

	count = (count + 1) >> 1;
	for (i = 0; i < count; i++) {
		DM_IO_DELAY();
		tmp = readw(reg);
	}
}

static void dm9000_inblk(void __iomem *reg, void *data, int count)
{
	int i;
	u16* pdata = (u16*)data;
	count = (count + 1) >> 1;
	for (i = 0; i < count; i++) {
		DM_IO_DELAY();
		*pdata++ = readw(reg);
	}
}

static struct dm9000_plat_data dm9000_platdata = {
	.flags		= DM9000_PLATF_16BITONLY | DM9000_PLATF_NO_EEPROM |
DM9000_PLATF_SIMPLE_PHY,
	.dumpblk = dm9000_dumpblk,
	.inblk = dm9000_inblk,
};

>
> * We're merging the new common clock framework in v3.4. Once that has
> ?matured, all new platforms will be required to use it. You should probably
> ?move to that already.
>
> * The dma driver uses a nonstandard interface and should be moved to
> ?drivers/dma, using the dmaengine API.
>
> * The __REG needs to be removed. All MMIO register accesses should go
> ?through readl/writel or readl_relaxed/writel_relaxed, using a pointer
> ?you get from ioremap.
>
> * gpio*.c should get moved to drivers/gpio/gpio-lpc31xx. If it's similar
> ?to the 32xx version, merge the two
>
> * i2c.c should no longer be needed with the device tree, but you might
> ?have to add stuff to i2c-pnx.c. That file is shared with pnx4008 and
> ?lpc32xx.
>
> * irq.c will eventually go to drivers/irqchip/. We have a plan to create
> ?that directory, but nobody has started moving drivers there.
>
> * Some of the header files have been removed on other platforms, you
> ?should do the same.
>
> * Regarding the static mappings, it certainly makes sense to map all of
> ?ABP01_PHYS and IO_APB2_PHYS using 1MB mappings, for performance reasons,
> ?and I guess you need INTC_PHYS to be mapped, too, for the interrupt
> ?controller code to work. However, none of the drivers should be aware
> ?of this and just call ioremap anyway, which will now return an address
> ?from the static mapping.
>
> ? ? ? ?Arnd



-- 
Jon Smirl
jonsmirl at gmail.com

ioremap to a specific virtual address

[Arnd Bergmann]

On Friday 23 March 2012, jonsmirl at gmail.com wrote:
> On Fri, Mar 23, 2012 at 11:20 AM, Arnd Bergmann <arnd@arndb.de> wrote:
> > On Friday 23 March 2012, jonsmirl at gmail.com wrote:
> >> I will need to check how similar the chips actually are. NXP did not
> >> use primecells in the lpc31xx family.
> >>
> >> I'd be happy to have some help. My trees are here:
> >> https://github.com/jonsmirl
> >
> > I've taken a brief look at your tree, some comments:
> >
> > * Once you're done with the DT conversion, you should be able to
> >  completely remvoe the three board files. You probably know that already
> 
> Thanks for the feedback.
> 
> I don't think I can completely remove the board files. Some of the
> generic devices have board specific callbacks. DM9000 for example. I
> am setting up of_dev_auxdata for the boards so that I can pass these
> callbacks in.

There are some cases where it's not possible to avoid platform_data,
but in most cases there is another better solution.

If you end up having to use platform_data, the auxdata mechanism
is the way to go.

> # define DM_IO_DELAY()	do { gpio_get_value(GPIO_MNAND_RYBN3);} while(0)
> 
> static void dm9000_dumpblk(void __iomem *reg, int count)
> {
> 	int i;
> 	int tmp;
> 
> 	count = (count + 1) >> 1;
> 	for (i = 0; i < count; i++) {
> 		DM_IO_DELAY();
> 		tmp = readw(reg);
> 	}
> }
> 
> static void dm9000_inblk(void __iomem *reg, void *data, int count)
> {
> 	int i;
> 	u16* pdata = (u16*)data;
> 	count = (count + 1) >> 1;
> 	for (i = 0; i < count; i++) {
> 		DM_IO_DELAY();
> 		*pdata++ = readw(reg);
> 	}
> }
> 
> static struct dm9000_plat_data dm9000_platdata = {
> 	.flags		= DM9000_PLATF_16BITONLY | DM9000_PLATF_NO_EEPROM |
> DM9000_PLATF_SIMPLE_PHY,

The flags can become simple empty properties if necessary, so there is no
need to keep these.

> 	.dumpblk = dm9000_dumpblk,
> 	.inblk = dm9000_inblk,
> };

I can see two possible ways besides platform_data for the register access:

1. generalize the driver's accessors. Since your platform wants to read
a gpio pin before every access, you can provide a gpio line as the
property in the dm9000 device node and access that in the same place
in the common code if the gpio line is set, but skip the access otherwise.
No other platform in mainline actually needs to overrid the functions,
so there are hardly any disadvantages to this. 

2. convert the entire driver to use the "regmap" infrastructure to abstract
the registers, and implement a driver that implements the slow I/O. This
would be a rather complex solution and probably not worth it, compared
with the overhead of the first one or just staying with auxdata.

If any problem turns out to be really hard to convert over from
platform_data to device tree properties, auxdata is usually an acceptable
solution, or you could submit the port with more of those hacks when
there is reason to believe that you will fix them up later.

	Arnd

ioremap to a specific virtual address

[jonsmirl at gmail.com]

On Fri, Mar 23, 2012 at 3:31 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> On Friday 23 March 2012, jonsmirl at gmail.com wrote:
>> On Fri, Mar 23, 2012 at 11:20 AM, Arnd Bergmann <arnd@arndb.de> wrote:
>> > On Friday 23 March 2012, jonsmirl at gmail.com wrote:
>> >> I will need to check how similar the chips actually are. NXP did not
>> >> use primecells in the lpc31xx family.
>> >>
>> >> I'd be happy to have some help. My trees are here:
>> >> https://github.com/jonsmirl
>> >
>> > I've taken a brief look at your tree, some comments:
>> >
>> > * Once you're done with the DT conversion, you should be able to
>> > ?completely remvoe the three board files. You probably know that already
>>
>> Thanks for the feedback.
>>
>> I don't think I can completely remove the board files. Some of the
>> generic devices have board specific callbacks. DM9000 for example. I
>> am setting up of_dev_auxdata for the boards so that I can pass these
>> callbacks in.
>
> There are some cases where it's not possible to avoid platform_data,
> but in most cases there is another better solution.
>
> If you end up having to use platform_data, the auxdata mechanism
> is the way to go.
>
>> # define DM_IO_DELAY() ? ? ? ?do { gpio_get_value(GPIO_MNAND_RYBN3);} while(0)
>>
>> static void dm9000_dumpblk(void __iomem *reg, int count)
>> {
>> ? ? ? int i;
>> ? ? ? int tmp;
>>
>> ? ? ? count = (count + 1) >> 1;
>> ? ? ? for (i = 0; i < count; i++) {
>> ? ? ? ? ? ? ? DM_IO_DELAY();
>> ? ? ? ? ? ? ? tmp = readw(reg);
>> ? ? ? }
>> }
>>
>> static void dm9000_inblk(void __iomem *reg, void *data, int count)
>> {
>> ? ? ? int i;
>> ? ? ? u16* pdata = (u16*)data;
>> ? ? ? count = (count + 1) >> 1;
>> ? ? ? for (i = 0; i < count; i++) {
>> ? ? ? ? ? ? ? DM_IO_DELAY();
>> ? ? ? ? ? ? ? *pdata++ = readw(reg);
>> ? ? ? }
>> }
>>
>> static struct dm9000_plat_data dm9000_platdata = {
>> ? ? ? .flags ? ? ? ? ?= DM9000_PLATF_16BITONLY | DM9000_PLATF_NO_EEPROM |
>> DM9000_PLATF_SIMPLE_PHY,
>
> The flags can become simple empty properties if necessary, so there is no
> need to keep these.
>
>> ? ? ? .dumpblk = dm9000_dumpblk,
>> ? ? ? .inblk = dm9000_inblk,
>> };
>
> I can see two possible ways besides platform_data for the register access:

The dm9000 is on the LPC3131 reference design board. It is not our
hardware so I'm not sure what it is doing with the GPIO pin. I'm
porting the reference board code in the hopes that someone will help
out in this effort.

Another piece of board specific glue is this bit that needs to be
executed before accessing the dm9000. It puts the bus in the board's
range in 8/16/32b mode, timings, etc.

tatic void __init ea_add_device_dm9000(void)
{
	/*
	 * Configure Chip-Select 2 on SMC for the DM9000.
	 * Note: These timings were calculated for MASTER_CLOCK = 90000000
	 *  according to the DM9000 timings.
	 */
	MPMC_STCONFIG1 = 0x81;
	MPMC_STWTWEN1 = 1;
	MPMC_STWTOEN1 = 1;
	MPMC_STWTRD1 = 4;
	MPMC_STWTPG1 = 1;
	MPMC_STWTWR1 = 1;
	MPMC_STWTTURN1 = 2;
	/* enable oe toggle between consec reads */
	SYS_MPMC_WTD_DEL1 = _BIT(5) | 4;

An external  LCD controller on CS1 needs a different setup.

static void __init ea_add_device_ssd1289(void)
{
	MPMC_STCONFIG0 = 0x81;
	MPMC_STWTWEN0  = 0;
	MPMC_STWTOEN0  = 0;
	MPMC_STWTRD0   = 31;
	MPMC_STWTPG0   = 0;
	MPMC_STWTWR0   = 3;
	MPMC_STWTTURN0 = 0;

>
> 1. generalize the driver's accessors. Since your platform wants to read
> a gpio pin before every access, you can provide a gpio line as the
> property in the dm9000 device node and access that in the same place
> in the common code if the gpio line is set, but skip the access otherwise.
> No other platform in mainline actually needs to override the functions,
> so there are hardly any disadvantages to this.
>
> 2. convert the entire driver to use the "regmap" infrastructure to abstract
> the registers, and implement a driver that implements the slow I/O. This
> would be a rather complex solution and probably not worth it, compared
> with the overhead of the first one or just staying with auxdata.
>
> If any problem turns out to be really hard to convert over from
> platform_data to device tree properties, auxdata is usually an acceptable
> solution, or you could submit the port with more of those hacks when
> there is reason to believe that you will fix them up later.
>
> ? ? ? ?Arnd



-- 
Jon Smirl
jonsmirl at gmail.com

ioremap to a specific virtual address

[Arnd Bergmann]

On Saturday 24 March 2012, jonsmirl at gmail.com wrote:
> The dm9000 is on the LPC3131 reference design board. It is not our
> hardware so I'm not sure what it is doing with the GPIO pin. I'm
> porting the reference board code in the hopes that someone will help
> out in this effort.

Ok, so it's possible that nobody knows why the gpio read was put
in then and it might be completely bogus?

> Another piece of board specific glue is this bit that needs to be
> executed before accessing the dm9000. It puts the bus in the board's
> range in 8/16/32b mode, timings, etc.
> 
> static void __init ea_add_device_dm9000(void)
> {
>         /*
>          * Configure Chip-Select 2 on SMC for the DM9000.
>          * Note: These timings were calculated for MASTER_CLOCK = 90000000
>          *  according to the DM9000 timings.
>          */
>         MPMC_STCONFIG1 = 0x81;
>         MPMC_STWTWEN1 = 1;
>         MPMC_STWTOEN1 = 1;
>         MPMC_STWTRD1 = 4;
>         MPMC_STWTPG1 = 1;
>         MPMC_STWTWR1 = 1;
>         MPMC_STWTTURN1 = 2;
>         /* enable oe toggle between consec reads */
>         SYS_MPMC_WTD_DEL1 = _BIT(5) | 4;
> 

I would try to describe the MPMC static memory configuration using a device
node containing these, if you can't reliably move the configuration into the
boot loader itself.

In the device tree, this can look like:

/ {

	ahb {
		compatible = "simple-bus";
		#address-cells = <1>;
		#size-cells = <1>;
		ranges;

		mpmc at 17008200 {
			compatible = "nxp,lpc31xx-mpmc";
			#address-cells = <1>;
			#size-cells = <1>;
			ranges = <0 0x20000000 0x20000>; /* map to sram0 */
			reg = <0x17008200 0x20>;
			status = "disabled"; /* unused here */
		};

		mpmc at 17008220 {
			compatible = "nxp,lpc31xx-mpmc";
			#address-cells = <1>;
			#size-cells = <1>;
			ranges = <0 0x20020000 0x20000>; /* map to sram1 */
			reg = <0x17008220 0x20>;

			/* mpmc configuration */
			mpmc-static-config     = <0x81>;
			mpmc-static-wait-wen   = <1>;
			mpmc-static-wait-oen   = <1>;
			mpmc-static-wait-rd    = <4>;
			mpmc-static-wait-page  = <1>;
			mpmc-static-wait-write = <1>;
			mpmc-static-wait-turn  = <2>;

			ethernet at 20020000 {
				compatible = "davicom,dm9000";
				reg = <0 100  10000 100>; /* local address */
				interrupts = <0x1>; /* ??? */
				gpios = <&gpio-i2stx 0>;
			}
		};
	};
};

This means you will need a driver for mpmc, but since all its code is only
run at boot time, it can live entirely in the init section.

	Arnd

ioremap to a specific virtual address

[Arnd Bergmann]

On Sunday 25 March 2012, Arnd Bergmann wrote:
>                         /* mpmc configuration */
>                         mpmc-static-config     = <0x81>;
>                         mpmc-static-wait-wen   = <1>;
>                         mpmc-static-wait-oen   = <1>;
>                         mpmc-static-wait-rd    = <4>;
>                         mpmc-static-wait-page  = <1>;
>                         mpmc-static-wait-write = <1>;
>                         mpmc-static-wait-turn  = <2>;

On second though, I guess you can turn these into a single
property named "mpmc-timings" or such and then just copy
them to the registers.

I also wonder whether the timings are actually correct for your
dm9000 device. Maybe the additional gpio read in there was
just an indication that someone worked around incorrect timings?

	Arnd

ioremap to a specific virtual address

[jonsmirl at gmail.com]

On Fri, Mar 23, 2012 at 3:31 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> On Friday 23 March 2012, jonsmirl at gmail.com wrote:
>> On Fri, Mar 23, 2012 at 11:20 AM, Arnd Bergmann <arnd@arndb.de> wrote:
>> > On Friday 23 March 2012, jonsmirl at gmail.com wrote:
>> >> I will need to check how similar the chips actually are. NXP did not
>> >> use primecells in the lpc31xx family.
>> >>
>> >> I'd be happy to have some help. My trees are here:
>> >> https://github.com/jonsmirl
>> >
>> > I've taken a brief look at your tree, some comments:
>> >
>> > * Once you're done with the DT conversion, you should be able to
>> > ?completely remvoe the three board files. You probably know that already
>>
>> Thanks for the feedback.
>>
>> I don't think I can completely remove the board files. Some of the
>> generic devices have board specific callbacks. DM9000 for example. I
>> am setting up of_dev_auxdata for the boards so that I can pass these
>> callbacks in.
>
> There are some cases where it's not possible to avoid platform_data,
> but in most cases there is another better solution.
>
> If you end up having to use platform_data, the auxdata mechanism
> is the way to go.

Here's the answer from the owners of the hardware...


---------- Forwarded message ----------
From: Support@EmbeddedArtists.com <support@embeddedartists.com>
Date: Mon, Mar 26, 2012 at 2:31 AM
Subject: Re: [Ticket#10005612] DM9000 on EA3131 board
To: "jonsmirl at gmail.com" <jonsmirl@gmail.com>


Hi Jon,
This driver was created a long time ago and it was not done by us.
If I remember correctly the delay is needed because the LPC31xx memory
controller does some strange things when you change memory regions. It
can for example happen if an interrupt happen in the middle of some
other operation in external memory. We have actually forgot about the
exact details but you can probably find it in the LPC31xx user's
manual from NXP or by asking NXP directly.

Kind Regards,
Anders Rosvall
Embedded Artists AB





>
>> # define DM_IO_DELAY() ? ? ? ?do { gpio_get_value(GPIO_MNAND_RYBN3);} while(0)
>>
>> static void dm9000_dumpblk(void __iomem *reg, int count)
>> {
>> ? ? ? int i;
>> ? ? ? int tmp;
>>
>> ? ? ? count = (count + 1) >> 1;
>> ? ? ? for (i = 0; i < count; i++) {
>> ? ? ? ? ? ? ? DM_IO_DELAY();
>> ? ? ? ? ? ? ? tmp = readw(reg);
>> ? ? ? }
>> }
>>
>> static void dm9000_inblk(void __iomem *reg, void *data, int count)
>> {
>> ? ? ? int i;
>> ? ? ? u16* pdata = (u16*)data;
>> ? ? ? count = (count + 1) >> 1;
>> ? ? ? for (i = 0; i < count; i++) {
>> ? ? ? ? ? ? ? DM_IO_DELAY();
>> ? ? ? ? ? ? ? *pdata++ = readw(reg);
>> ? ? ? }
>> }
>>
>> static struct dm9000_plat_data dm9000_platdata = {
>> ? ? ? .flags ? ? ? ? ?= DM9000_PLATF_16BITONLY | DM9000_PLATF_NO_EEPROM |
>> DM9000_PLATF_SIMPLE_PHY,
>
> The flags can become simple empty properties if necessary, so there is no
> need to keep these.
>
>> ? ? ? .dumpblk = dm9000_dumpblk,
>> ? ? ? .inblk = dm9000_inblk,
>> };
>
> I can see two possible ways besides platform_data for the register access:
>
> 1. generalize the driver's accessors. Since your platform wants to read
> a gpio pin before every access, you can provide a gpio line as the
> property in the dm9000 device node and access that in the same place
> in the common code if the gpio line is set, but skip the access otherwise.
> No other platform in mainline actually needs to overrid the functions,
> so there are hardly any disadvantages to this.
>
> 2. convert the entire driver to use the "regmap" infrastructure to abstract
> the registers, and implement a driver that implements the slow I/O. This
> would be a rather complex solution and probably not worth it, compared
> with the overhead of the first one or just staying with auxdata.
>
> If any problem turns out to be really hard to convert over from
> platform_data to device tree properties, auxdata is usually an acceptable
> solution, or you could submit the port with more of those hacks when
> there is reason to believe that you will fix them up later.
>
> ? ? ? ?Arnd



-- 
Jon Smirl
jonsmirl at gmail.com

ioremap to a specific virtual address

[jonsmirl at gmail.com]

On Mon, Mar 26, 2012 at 4:47 AM, Arnd Bergmann <arnd@arndb.de> wrote:
> On Sunday 25 March 2012, Arnd Bergmann wrote:
>> ? ? ? ? ? ? ? ? ? ? ? ? /* mpmc configuration */
>> ? ? ? ? ? ? ? ? ? ? ? ? mpmc-static-config ? ? = <0x81>;
>> ? ? ? ? ? ? ? ? ? ? ? ? mpmc-static-wait-wen ? = <1>;
>> ? ? ? ? ? ? ? ? ? ? ? ? mpmc-static-wait-oen ? = <1>;
>> ? ? ? ? ? ? ? ? ? ? ? ? mpmc-static-wait-rd ? ?= <4>;
>> ? ? ? ? ? ? ? ? ? ? ? ? mpmc-static-wait-page ?= <1>;
>> ? ? ? ? ? ? ? ? ? ? ? ? mpmc-static-wait-write = <1>;
>> ? ? ? ? ? ? ? ? ? ? ? ? mpmc-static-wait-turn ?= <2>;
>
> On second though, I guess you can turn these into a single
> property named "mpmc-timings" or such and then just copy
> them to the registers.
>
> I also wonder whether the timings are actually correct for your
> dm9000 device. Maybe the additional gpio read in there was
> just an indication that someone worked around incorrect timings?

Maybe the GPIO read is bogus? Looks like they needed a 70ns delay and
the GPIO read was a way of getting that.

How do MPNC delays work? Shouldn't the CPU enforce this delay in hardware?

/* ARM MPMC contoller as part of low power design doesn't de-assert
nCS and nOE for consecutive reads but just changes address. But DM9000
requires nCS and nOE change between address. So access other chip
select area (nCS0) to force de-assertion of nCS1 and nOE1. Or else
wait for long time such as 80 usecs.
LPC313x has external logic outside of MPMC IP to toggle nOE to split
consecutive reads.

The latest Apex bootloader patch makes use of this feature. For this
to work SYS_MPMC_WTD_DEL0 & SYS_MPMC_WTD_DEL1 should be programmed
with MPMC_STWTRD0 & MPMC_STWTRD1 values. The logic only deactivates
the nOE for one clock cycle which is 11nsec but DM9000 needs 80nsec
between nOEs. So lets add some dummy instructions such as reading a
GPIO register to compensate for extra 70nsec.
*/

WTD_DEL1
This following register is used for the static device0 of the MPMC. It
provides that the output enable signal for the static device0 (OE) is
split up into two equal portions, with one inactive cycle in the
middle. This is needed because some memories do no detect consecutive
reads within one OE period

MPMCStaticExtendedWait is set to 4 which should be a 2us delay.



-- 
Jon Smirl
jonsmirl at gmail.com

ioremap to a specific virtual address

[jonsmirl at gmail.com]

On Fri, Mar 23, 2012 at 12:00 AM, Nicolas Pitre <nico@fluxnic.net> wrote:
> 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.

I switched over to 1MB mappings. 1MB map regions are implemented on
ARM9, right? Is there some way to see if I got the huge maps?

-- 
Jon Smirl
jonsmirl at gmail.com

ioremap to a specific virtual address

[Nicolas Pitre]

On Sat, 31 Mar 2012, jonsmirl at gmail.com wrote:

> On Fri, Mar 23, 2012 at 12:00 AM, Nicolas Pitre <nico@fluxnic.net> wrote:
> > 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.
> 
> I switched over to 1MB mappings. 1MB map regions are implemented on
> ARM9, right? Is there some way to see if I got the huge maps?

Once booted, you can look in /proc/vmallocinfo for the mappings in use.

There is no way to know for sure if the first level pagetable mappings 
are actually used, unless you instrument the kernel code.  But yes, all 
ARM architectures with a MMU support 1MB regions.


Nicolas

ioremap to a specific virtual address

[jonsmirl at gmail.com]

On Sat, Mar 31, 2012 at 7:52 PM, Nicolas Pitre <nico@fluxnic.net> wrote:
> On Sat, 31 Mar 2012, jonsmirl at gmail.com wrote:
>
>> On Fri, Mar 23, 2012 at 12:00 AM, Nicolas Pitre <nico@fluxnic.net> wrote:
>> > 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.
>>
>> I switched over to 1MB mappings. 1MB map regions are implemented on
>> ARM9, right? Is there some way to see if I got the huge maps?
>
> Once booted, you can look in /proc/vmallocinfo for the mappings in use.
>
> There is no way to know for sure if the first level pagetable mappings
> are actually used, unless you instrument the kernel code. ?But yes, all
> ARM architectures with a MMU support 1MB regions.

Looks good, way cleaner than my x86 desktop which is full of 8KB
mappings. On my ARM I had about 50 regions before since I was mapping
each device individually.

root at OpenWrt:/proc# cat vmallocinfo
0xc4804000-0xc4810000   49152 cramfs_uncompress_init+0x24/0x60 pages=11 vmalloc
0xc4810000-0xc4853000  274432 jffs2_zlib_init+0x14/0xa4 pages=66 vmalloc
0xc4853000-0xc485f000   49152 jffs2_zlib_init+0x48/0xa4 pages=11 vmalloc
0xc485f000-0xc4886000  159744 ssd1289_probe+0x250/0x85c pages=38 vmalloc
0xf1300000-0xf1400000 1048576 iotable_init+0x0/0xb0 phys=13000000 ioremap
0xf1500000-0xf1600000 1048576 iotable_init+0x0/0xb0 phys=15000000 ioremap
0xf1600000-0xf1700000 1048576 iotable_init+0x0/0xb0 phys=16000000 ioremap
0xf1700000-0xf1800000 1048576 iotable_init+0x0/0xb0 phys=17000000 ioremap
0xf1800000-0xf1900000 1048576 iotable_init+0x0/0xb0 phys=18000000 ioremap
0xf1900000-0xf1a00000 1048576 iotable_init+0x0/0xb0 phys=19000000 ioremap
0xf2000000-0xf2100000 1048576 iotable_init+0x0/0xb0 phys=20000000 ioremap
0xf6000000-0xf6100000 1048576 iotable_init+0x0/0xb0 phys=60000000 ioremap
0xf7000000-0xf7100000 1048576 iotable_init+0x0/0xb0 phys=70000000 ioremap
root at OpenWrt:/proc#

-- 
Jon Smirl
jonsmirl at gmail.com

ioremap to a specific virtual address

[Arnd Bergmann]

On Sunday 01 April 2012, jonsmirl at gmail.com wrote:
> Looks good, way cleaner than my x86 desktop which is full of 8KB
> mappings. On my ARM I had about 50 regions before since I was mapping
> each device individually.
> 
> root at OpenWrt:/proc# cat vmallocinfo
> 0xc4804000-0xc4810000   49152 cramfs_uncompress_init+0x24/0x60 pages=11 vmalloc
> 0xc4810000-0xc4853000  274432 jffs2_zlib_init+0x14/0xa4 pages=66 vmalloc
> 0xc4853000-0xc485f000   49152 jffs2_zlib_init+0x48/0xa4 pages=11 vmalloc
> 0xc485f000-0xc4886000  159744 ssd1289_probe+0x250/0x85c pages=38 vmalloc
> 0xf1300000-0xf1400000 1048576 iotable_init+0x0/0xb0 phys=13000000 ioremap
> 0xf1500000-0xf1600000 1048576 iotable_init+0x0/0xb0 phys=15000000 ioremap
> 0xf1600000-0xf1700000 1048576 iotable_init+0x0/0xb0 phys=16000000 ioremap
> 0xf1700000-0xf1800000 1048576 iotable_init+0x0/0xb0 phys=17000000 ioremap
> 0xf1800000-0xf1900000 1048576 iotable_init+0x0/0xb0 phys=18000000 ioremap
> 0xf1900000-0xf1a00000 1048576 iotable_init+0x0/0xb0 phys=19000000 ioremap
> 0xf2000000-0xf2100000 1048576 iotable_init+0x0/0xb0 phys=20000000 ioremap
> 0xf6000000-0xf6100000 1048576 iotable_init+0x0/0xb0 phys=60000000 ioremap
> 0xf7000000-0xf7100000 1048576 iotable_init+0x0/0xb0 phys=70000000 ioremap
> root at OpenWrt:/proc#

Well, you loose the information about which devices specifically do the ioremap,
but that wasn't very reliable to start with. How about combining those that
are already consecutive areas, e.g. 0xf1300000-0xf1a00000? I don't see
any downsides of doing that, and it would save a few bytes here and there.

	Arnd

ioremap to a specific virtual address

[jonsmirl at gmail.com]

On Sun, Apr 1, 2012 at 3:46 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> On Sunday 01 April 2012, jonsmirl at gmail.com wrote:
>> Looks good, way cleaner than my x86 desktop which is full of 8KB
>> mappings. On my ARM I had about 50 regions before since I was mapping
>> each device individually.
>>
>> root at OpenWrt:/proc# cat vmallocinfo
>> 0xc4804000-0xc4810000 ? 49152 cramfs_uncompress_init+0x24/0x60 pages=11 vmalloc
>> 0xc4810000-0xc4853000 ?274432 jffs2_zlib_init+0x14/0xa4 pages=66 vmalloc
>> 0xc4853000-0xc485f000 ? 49152 jffs2_zlib_init+0x48/0xa4 pages=11 vmalloc
>> 0xc485f000-0xc4886000 ?159744 ssd1289_probe+0x250/0x85c pages=38 vmalloc
>> 0xf1300000-0xf1400000 1048576 iotable_init+0x0/0xb0 phys=13000000 ioremap
>> 0xf1500000-0xf1600000 1048576 iotable_init+0x0/0xb0 phys=15000000 ioremap
>> 0xf1600000-0xf1700000 1048576 iotable_init+0x0/0xb0 phys=16000000 ioremap
>> 0xf1700000-0xf1800000 1048576 iotable_init+0x0/0xb0 phys=17000000 ioremap
>> 0xf1800000-0xf1900000 1048576 iotable_init+0x0/0xb0 phys=18000000 ioremap
>> 0xf1900000-0xf1a00000 1048576 iotable_init+0x0/0xb0 phys=19000000 ioremap
>> 0xf2000000-0xf2100000 1048576 iotable_init+0x0/0xb0 phys=20000000 ioremap
>> 0xf6000000-0xf6100000 1048576 iotable_init+0x0/0xb0 phys=60000000 ioremap
>> 0xf7000000-0xf7100000 1048576 iotable_init+0x0/0xb0 phys=70000000 ioremap
>> root at OpenWrt:/proc#
>
> Well, you loose the information about which devices specifically do the ioremap,
> but that wasn't very reliable to start with. How about combining those that
> are already consecutive areas, e.g. 0xf1300000-0xf1a00000? I don't see
> any downsides of doing that, and it would save a few bytes here and there.

 0xf1300000-0xf1a00000 is the virtual address.  0x13000000-0x21000000
is the physical address.  That's a span of 224MB.  How do the page
table entries work on ARM? I thought we only got 1MB per entry.  So I
need seven entries to span the range with the individual maps. I'd
need 224 entries to cover the entire region. Or can we make make the
page table entries any size we want?

There is only about 64KB in use at each of the 16MB boundaries.


>
> ? ? ? ?Arnd



-- 
Jon Smirl
jonsmirl at gmail.com

ioremap to a specific virtual address

[Nicolas Pitre]

On Sun, 1 Apr 2012, jonsmirl at gmail.com wrote:

> On Sun, Apr 1, 2012 at 3:46 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> > On Sunday 01 April 2012, jonsmirl at gmail.com wrote:
> >> Looks good, way cleaner than my x86 desktop which is full of 8KB
> >> mappings. On my ARM I had about 50 regions before since I was mapping
> >> each device individually.
> >>
> >> root at OpenWrt:/proc# cat vmallocinfo
> >> 0xc4804000-0xc4810000 ? 49152 cramfs_uncompress_init+0x24/0x60 pages=11 vmalloc
> >> 0xc4810000-0xc4853000 ?274432 jffs2_zlib_init+0x14/0xa4 pages=66 vmalloc
> >> 0xc4853000-0xc485f000 ? 49152 jffs2_zlib_init+0x48/0xa4 pages=11 vmalloc
> >> 0xc485f000-0xc4886000 ?159744 ssd1289_probe+0x250/0x85c pages=38 vmalloc
> >> 0xf1300000-0xf1400000 1048576 iotable_init+0x0/0xb0 phys=13000000 ioremap
> >> 0xf1500000-0xf1600000 1048576 iotable_init+0x0/0xb0 phys=15000000 ioremap
> >> 0xf1600000-0xf1700000 1048576 iotable_init+0x0/0xb0 phys=16000000 ioremap
> >> 0xf1700000-0xf1800000 1048576 iotable_init+0x0/0xb0 phys=17000000 ioremap
> >> 0xf1800000-0xf1900000 1048576 iotable_init+0x0/0xb0 phys=18000000 ioremap
> >> 0xf1900000-0xf1a00000 1048576 iotable_init+0x0/0xb0 phys=19000000 ioremap
> >> 0xf2000000-0xf2100000 1048576 iotable_init+0x0/0xb0 phys=20000000 ioremap
> >> 0xf6000000-0xf6100000 1048576 iotable_init+0x0/0xb0 phys=60000000 ioremap
> >> 0xf7000000-0xf7100000 1048576 iotable_init+0x0/0xb0 phys=70000000 ioremap
> >> root at OpenWrt:/proc#
> >
> > Well, you loose the information about which devices specifically do the ioremap,
> > but that wasn't very reliable to start with. How about combining those that
> > are already consecutive areas, e.g. 0xf1300000-0xf1a00000? I don't see
> > any downsides of doing that, and it would save a few bytes here and there.
> 
>  0xf1300000-0xf1a00000 is the virtual address.  0x13000000-0x21000000
> is the physical address.  That's a span of 224MB.  How do the page
> table entries work on ARM? I thought we only got 1MB per entry.  So I
> need seven entries to span the range with the individual maps. I'd
> need 224 entries to cover the entire region. Or can we make make the
> page table entries any size we want?

You can't.  Arnd probably didn't notice that the physical range is not 
contiguous.  What you have is pretty optimal.

Of course you could avoid fragmenting the virtual space by packing all 
those mappings together, but I suspect there is a macro providing a 
correspondence between the virtual and physical addresses still in use.  
OTOH this is not worth bothering with unless you run out of vmalloc 
space.


Nicolas

ioremap to a specific virtual address

[Arnd Bergmann]

On Monday 02 April 2012, Nicolas Pitre wrote:
> >  0xf1300000-0xf1a00000 is the virtual address.  0x13000000-0x21000000
> > is the physical address.  That's a span of 224MB.  How do the page
> > table entries work on ARM? I thought we only got 1MB per entry.  So I
> > need seven entries to span the range with the individual maps. I'd
> > need 224 entries to cover the entire region. Or can we make make the
> > page table entries any size we want?
> 
> You can't.  Arnd probably didn't notice that the physical range is not 
> contiguous.  What you have is pretty optimal.

Right, I didn't realize they were laid out like this in the physical space.

	Arnd