Simon Burge wrote:
> "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?
>   

At point I was squirreling them away, but the problem I see is that the
device in question may attach (and need these) before augpio.  The
config system has no way to express device dependencies of this nature
(at least not from what I can tell), so its not clean.

Frankly, its probably easiest to just violate the bus_space abstraction,
since this driver is only ever going to be used on these chips, with
specific address locations, so portability of the driver isn't really of
paramount concern.

    -- Garrett

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


-- 
Garrett D'Amore, Principal Software Engineer
Tadpole Computer / Computing Technologies Division,
General Dynamics C4 Systems
http://www.tadpolecomputer.com/
Phone: 951 325-2134  Fax: 951 325-2191