"Garrett D'Amore" wrote:

> Garrett D'Amore wrote:
> > KIYOHARA Takashi wrote:
> >   
> >> Hi! Garrett,
> >>
> >> Our aupcmcia on OMSAL400 wants to read the status of GPIO (AUGPIO_PINSTATERD).
> >> # Perhaps, (GPIO is used) other devices also.
> >>
> >> Are you offering the interface?
> >>   e.g. augpio_read() like.
> >>
> >
> > Sorry, I just saw that you need it for aupcmcia.  I misunderstood. 
> > There is an interface there.  Let me research and get back to you.
>
> There are a couple of options for you:
> 
>     1) if you do an in-kernel open of the "gpioctl" device, then you can
> issue IOCTLs against them to get at the GPIOs.  This is probably the
> most painful to use, but also the most "architecturally correct."
> 
>     2) you could just borrow some of the logic from augpio.c and use it
> to directly read and write GPIO lines.  This is the simplest.
> 
>     3) conceivably we could "modify" the augpio stuff to provide lower
> level functions for direct access.  At one point I had started on this,
> but ditched it.  The problem with this is that the bus-spaces haven't
> been passed in until later (during attach), so we'd either have to do
> some kind of deferral, or just violate the bus space abstraction and
> access the addresses directly.
> 
> I don't have a strong opinion about any of this, though if you're going
> to modify augpio.c, I'd like a chance to review your changes before you
> commit them.

I prefer 3) here.  Using in-kernel gpio ioctl's seems very heavy weight
for what is needed, and duplicating the logic doesn't seem like the
best way.  Perhaps the best way is to squirrel away the softc's of the
primary and secondary GPIO blocks in a few static variables, or maybe
store them in the devprop database?

Simon.
--
Simon Burge                            <simonb@wasabisystems.com>
NetBSD Support and Service:         http://www.wasabisystems.com/