Re: IBM405GP/GPr OPB bus_space endian (powerpc/ibm4xx/dev/opb.c)

[Shigeyuki Fukushima <shige%netbsd.org@localhost>]

Hi,

> Your LEDs work fine with the new GPIO framework?  If so, that's good!

It works fine.
I could write data 0 to GPIO PIN No.12 by `gpioctl 11 0'.

> However, I don't like the _ in the name of the gpio_opb device.  We
> don't have any other devices on any platform that has an underscore in
> it's name.  Maybe "opbgpio" instead?  It's reasonably normal to use
> "bus-type device-type" as a naming convention rather than the other way
> around.

Ok, I will agree your plan (renaming gpio_opb with opbgpio).

> I wonder if it is possible to just attach the MI gpio directly to the
> opb with something like:
>       gpio* at opb? addr ? irq ?
> and
>       device  gpio: gpiobus
>       attach  gpio at opb with gpio_plb
>       file    arch/powerpc/ibm4xx/dev/gpio_opb.c      gpio
> and drop the intermediate gpio_opb/opbgpio/whatever device?

It seems that this syntax is invalid.
/usr/src/sys/arch/powerpc/conf/files.ibm4xx:33: redifinition of `gpio'
/usr/src/sys/arch/powerpc/conf/files.ibm4xx:34: redifinition of `gpio'
/usr/src/sys/arch/evbppc/conf/OPENBLOCKS266:169: `gpio' cannot attach to
 `opb'.

I think the following:
- `gpio' is GPIO controller independent device.
- `opbgpio' is GPIO controller dependent device.

> Also, in evbppc/conf/files.obs405 we don't need to comment out the old
> obsled entries - just delete them.  We can easily get the old entries
> back from cvs.  Same for the obs266_led_set() call in obs266_machdep.c.

Ok, that's right. I will do so.

>>Why it is Little-Endian in spite of CPU byte-order (Big-Endian) ?
>>Is there any special reason?
> After a little look, I'm not really sure!  If you look at
> powerpc/powerpc/bus_space.c, you'll see that both the little- and
> big-endian setup in bus_space_init() are exactly the same.  You'd
> certainly think for most devices on a PPC cpu would be big-endian :-)
> As I said above, because the setup code is identical, so it
> shouldn't actually make a difference.  We should audit the calls of
> bus_space_init() and fix bus_space_init() itself.

But, the result of bus_space_{read,write}_4 function is *not* the same.
The return value is littel-endian when calling bus_space_init() with
_BUS_SPACE_LITTLE_ENDIAN options.

For exmaple,

u_int32_t data;
data = bus_space_read_4(sc->sc_gpio_iot, sc->sc_gpio_ioh, GPIO_IR);
printf("data is 0x%x\n");

Big-endian output is:
data is 0x00112233

Littel-endian output is:
data is 0x33221100

-- 
Kind Regards,
--- shige
Shigeyuki Fukushima <shige@{FreeBSD,jp.FreeBSD,NetBSD}.org>