[RFC 1/1] ARM: imx6q: move clock register map to machine_desc.map_io

Russell King - ARM Linux linux at arm.linux.org.uk
Thu Nov 17 06:44:04 EST 2011


On Thu, Nov 17, 2011 at 07:22:51PM +0800, Eric Miao wrote:
> On Thu, Nov 17, 2011 at 5:28 PM, Shawn Guo <shawn.guo at freescale.com> wrote:
> > I do not see any more possible static IO mapping in the future. On the
> > contrary, the static mapping for clocks could possibly be removed when
> > we migrate to common clock framework and create clocks dynamically from
> > device tree.
> 
> Fair enough and it would be ideal if static IO mapping is not necessary.
> 
> And I don't have a strong preference of having a single array for all these
> mappings or having separate function for each of them. It just looks a bit
> redundant to have a one-line function here.

You have to do static IO mapping if you need the mapping before the
memory allocators are up and running - because until that's the case,
ioremap won't work.

Your choices for setting up device mappings are:

1. iotable_init() or create_mapping() in the map_io callback (and no
   other callback.)

2. ioremap() after the memory allocators are up and running, which (in
   the sequence of functions in the machine description - they've always
   been ordered according to their called sequence) is at the point where
   init_irq is called.

.init_early can then access anything which the static mappings have
setup, but it can't in any way setup any further mappings.  If you're
registering your clocks at init_early() time, and you need to access
the devices, then you must have created those mappings at map_io time.

.init_irq, the timer init, and .init_machine can all use ioremap() to
setup further mappings but must not use iotable_init() nor create_mapping()
to do so.



More information about the linux-arm-kernel mailing list