Re: Which is the read interface to GPIO?

"Garrett D'Amore" <[email protected]>
Newsgroups gmane.os.netbsd.ports.evbmips
Message-ID <[email protected]>
KIYOHARA Takashi wrote:
> Hi! Simon,
>
>
> From: Simon Burge <[email protected]>
> Date: Tue, 21 Mar 2006 19:36:16 +1100
>
>   
>> 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?
>>     
>
> The devprop_[sg]et() use sc_dev of softc the first arg.  However, it is
> softc that we want.  ;-<
> Is softc of the dummy passed to devprop_[sg]et()?  Or, is prop_[sg]et()
> called?
>   

I think it is better to just break the bus_space abstraction.  (By that
I mean, don't bother passing in a softc at all, and just access the
memory addresses directly, as they are known to be fixed on the
processors under consideration.)

The reason for this is that there are "ordering constraints" otherwise
-- how do you augpio has attached before aupcmcia?   This is something
that I think autoconf lacks support for expressing (at least where the
dependency is not implied as a result of child-parent relationship.)

I'd rather not stick softc's in property databases, if we can avoid it.

    -- Garrett


> --
> kiyohara
>   


-- 
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
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.