On Tue Feb 1 13:29:12 2005 Michael Opdenacker wrote:
> Hi Aric,
>
> > . . .
> >So GPIOC starts at address 0x0c000100.
>
> Thank you very much for these details! This is consistent with the
> specifications from Jamey (LEDs being on GPIOC) and with ASIC3 GPIO
> settings on the Sharp Zaurus SL-A300 (see
> http://free-electrons.com/pub/pda/hx4700/misc/discovery_asic3.h.txt).
>
> However, I don't understand how GPIOC can be at offset 0x000c on hx4700
> SL-A300 and at offset 0x0200 on h4000 (as defined on
> include/asm-arm/hardware/ipaq-asic3.h)!?
It's actually at 0x100 on the hx4700, but I don't know either.
Frankly, the preprocessor spaghetti in ipaq-asic3.h is difficult to
follow. It is a maintainer's nightmare!
The crux of the problem may be that the IPAQ_ASIC3_GPIO_OFFSET macro
expands to something like this for GPIO C:
(*((volatile u16 *) (_b + _IPAQ_ASIC3_GPIO_C_Base + _IPAQ_ASIC3_GPIO_Mask)))
Everything except _b (a pointer) is a constant, so you cannot tell from
the macro itself what the type of _b is. So you will get different
results if _b is an int * versus a char *, for example. But you'll
never guess what _b is! It's a void * in asic3_base.c! So what in the
world does ((void *)_b + 0x100) evaluate to? I frankly don't know what
the C standard would say, because a void pointer means it points to no
particular type. Maybe it implicitly casts to a char *.
Because of this, I hard coded it for now. Either way, maybe we should be
casting _b to some known pointer type before adding the offsets to it.
> If its the same ASIC3 chip on all these devices, then its memory
> mapping offsets should be the same on all devices, shouldn't they?
>
> If it's a mistake in ipaq-asic3.h, how could h4000 drivers using GPIOC
> and GPIOD (such as h4000_lcd) work properly? I check that
> H4000_ASIC3_PHYS is correct in h4000 code.
>
> How do you understand these facts?
I don't really know, but it is possible that they hooked the address
lines up differently in the hx4700. If they shift the address left one
bit at ASIC3 then a 0x100 is really 0x200.
Received on Tue Feb 01 2005 - 15:13:43 EST
This archive was generated by hypermail 2.2.0 : Mon Jul 25 2005 - 17:21:03 EDT