what is the rationale for funny "0x100" offset for OMAP4 GPIO addresses?

[Robert P. J. Day]

On Wed, 5 Dec 2012, Sascha Hauer wrote:

> On Wed, Dec 05, 2012 at 07:54:51AM -0500, Robert P. J. Day wrote:
> >
> >   i was going to submit a patch to replace magic constants for OMAP4
> > with more meaningful names but i ran into an oddity.  here's
> > omap4-silicon.h:
> >
> > #define OMAP44XX_L4_WKUP_BASE           0x4A300000
> > #define OMAP44XX_L4_PER_BASE            0x48000000
> >
> > and here's part of an old posting to the linux-omap mailing list:
> >
> > +/* GPIO controller*/
> > +#define OMAP44XX_GPIO1_BASE             (L4_WK_44XX_BASE  + 0x10000)
> > +#define OMAP44XX_GPIO2_BASE             (L4_PER_44XX_BASE + 0x55000)
> > +#define OMAP44XX_GPIO3_BASE             (L4_PER_44XX_BASE + 0x57000)
> > +#define OMAP44XX_GPIO4_BASE             (L4_PER_44XX_BASE + 0x59000)
> > +#define OMAP44XX_GPIO5_BASE             (L4_PER_44XX_BASE + 0x5B000)
> > +#define OMAP44XX_GPIO6_BASE             (L4_PER_44XX_BASE + 0x5D000)
> >
> > but here's the tail end of omap4-generic.c:
> >
> > static int omap4_gpio_init(void)
> > {
> >         add_generic_device("omap-gpio", 0, NULL, 0x4a310100,
> >                                 0xf00, IORESOURCE_MEM, NULL);
> >         add_generic_device("omap-gpio", 1, NULL, 0x48055100,
> >                                 0xf00, IORESOURCE_MEM, NULL);
> >         add_generic_device("omap-gpio", 2, NULL, 0x48057100,
> >                                 0xf00, IORESOURCE_MEM, NULL);
> >         add_generic_device("omap-gpio", 3, NULL, 0x48059100,
> >                                 0xf00, IORESOURCE_MEM, NULL);
> >         add_generic_device("omap-gpio", 4, NULL, 0x4805b100,
> >                                 0xf00, IORESOURCE_MEM, NULL);
> >         add_generic_device("omap-gpio", 5, NULL, 0x4805d100,
> >                                 0xf00, IORESOURCE_MEM, NULL);
> >
> >         return 0;
> > }
> >
> >   as you can see, the numbers don't add up exactly -- the constants in
> > that final file are all 0x100 larger than a simple addition.  anyone
> > know where that comes from?
>
> This comes from the hardware. The GPIO controller is the same as on
> omap3, but the base addresses have an additional 0x100 offset.

  ok, i finally satisfied myself as to how this is being done, and why
it was so hard to find other evidence of this.  i checked what was
happening in u-boot and found this:

$ grep -r GPIO_CLEARDATAOUT *
arch/arm/include/asm/arch-omap5/cpu.h:#define OMAP_GPIO_CLEARDATAOUT		0x0190
arch/arm/include/asm/arch-omap4/cpu.h:#define OMAP_GPIO_CLEARDATAOUT		0x0190
arch/arm/include/asm/arch-omap3/cpu.h:#define OMAP_GPIO_CLEARDATAOUT		0x0090
arch/arm/include/asm/arch-am33xx/cpu.h:#define OMAP_GPIO_CLEARDATAOUT		0x0190
drivers/gpio/omap_gpio.c:			reg += OMAP_GPIO_CLEARDATAOUT;

and suddenly it all makes sense.

  so u-boot defines and uses the *non*-adding-0x100 offset addresses
for GPIO BASE addresses, but makes up for it by adding that necessary
offset into the subsequent macros (as you can see above).

  barebox, on the other hand, has a single definition for stuff like
that:

$ grep -r CLEARDATAOUT *
mach-omap/gpio.c:#define OMAP_GPIO_CLEARDATAOUT	0x0090
mach-omap/gpio.c:		base += OMAP_GPIO_CLEARDATAOUT;
$

so the offset has to be added to the base address to come out the
same.

  sorry for being so confused about this.

rday

-- 

========================================================================
Robert P. J. Day                                 Ottawa, Ontario, CANADA
                        http://crashcourse.ca

Twitter:                                       http://twitter.com/rpjday
LinkedIn:                               http://ca.linkedin.com/in/rpjday
========================================================================