* Re: what is the rationale for funny "0x100" offset for OMAP4 GPIO addresses?
2012-12-05 12:58 ` Sascha Hauer
@ 2012-12-05 13:01 ` Robert P. J. Day
2012-12-05 13:29 ` Robert P. J. Day
2012-12-05 14:11 ` Robert P. J. Day
2 siblings, 0 replies; 5+ messages in thread
From: Robert P. J. Day @ 2012-12-05 13:01 UTC (permalink / raw)
To: Sascha Hauer; +Cc: U-Boot Version 2 (barebox)
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.
ah, gotcha. so i'll throw together a patch that changes those
numbers to appropriate macro names as i did for omap3, just for
readability.
rday
--
========================================================================
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca
Twitter: http://twitter.com/rpjday
LinkedIn: http://ca.linkedin.com/in/rpjday
========================================================================
_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox
^ permalink raw reply [flat|nested] 5+ messages in thread* Re: what is the rationale for funny "0x100" offset for OMAP4 GPIO addresses?
2012-12-05 12:58 ` Sascha Hauer
2012-12-05 13:01 ` Robert P. J. Day
@ 2012-12-05 13:29 ` Robert P. J. Day
2012-12-05 14:11 ` Robert P. J. Day
2 siblings, 0 replies; 5+ messages in thread
From: Robert P. J. Day @ 2012-12-05 13:29 UTC (permalink / raw)
To: Sascha Hauer; +Cc: U-Boot Version 2 (barebox)
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.
can you point me at a link that mentions that? i'd like to add that
info to the patch so readers have confirmation as to where that extra
offset comes from as a quick google shows pages that don't mention it,
like this one:
https://code.google.com/p/omapboot/source/browse/arch/omap4/gpio.c?spec=svnffa661ab10b10f9d1a20b8542ba1354e1f8ec8e1&r=ffa661ab10b10f9d1a20b8542ba1354e1f8ec8e1
i have no doubt it's true, but a lot of pages just don't say anything
about it.
rday
--
========================================================================
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca
Twitter: http://twitter.com/rpjday
LinkedIn: http://ca.linkedin.com/in/rpjday
========================================================================
_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox
^ permalink raw reply [flat|nested] 5+ messages in thread* Re: what is the rationale for funny "0x100" offset for OMAP4 GPIO addresses?
2012-12-05 12:58 ` Sascha Hauer
2012-12-05 13:01 ` Robert P. J. Day
2012-12-05 13:29 ` Robert P. J. Day
@ 2012-12-05 14:11 ` Robert P. J. Day
2 siblings, 0 replies; 5+ messages in thread
From: Robert P. J. Day @ 2012-12-05 14:11 UTC (permalink / raw)
To: Sascha Hauer; +Cc: U-Boot Version 2 (barebox)
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
========================================================================
_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox
^ permalink raw reply [flat|nested] 5+ messages in thread