Subject: Re: Which is the read interface to GPIO?
To: Garrett D'Amore <garrett_damore@tadpole.com>
From: Garrett D'Amore <garrett_damore@tadpole.com>
List: port-evbmips
Date: 03/20/2006 21:37:00
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.
>>
>>
>> Thanks,
>> --
>> kiyohara
>>   
>>     
>
> 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.
>
>   

Sorry I've not responded earlier, I've been busy with other things.

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.

    -- Garrett

-- 
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