tech-kern archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: New header for GPIO-like definitions



Julian Coleman <jdc%coris.org.uk@localhost> writes:

> I'm adding a driver and hardware-specific properties for GPIO's (which pins
> control LED's, which control sensors, etc).  I need to be able to pass the
> pin information from the arch-specific configuration to the MI driver.  I'd
> like to add a new dev/gpio/gpiotypes.h, so that I can share the defintions
> between the MI and MD code, e.g.:
>
>   #define GPIO_PIN_LED    0x01
>   #define GPIO_PIN_SENSOR 0x02
>
> Does this seem reasonable, or is there a better way to do this?

I don't really understand how this is different from in/out.
Presumably this is coming from some request from userspace originally,
where someone, perhaps in a config file, has told the system how a pin
is hooked up.

LED seems overly specific.  Presumably you care that the output does
something like "makes a light".  But I don't understand why your API
cares about light vs noise.  And I don't see an active high/low in your
proposal.   So I don't understand how this is different from just
"controllable binary output"

I am also not following SENSOR.    DO you just mean "reads if the logic
level at the pin is high or low".

I don't think you mean using i2c bitbang for a temp sensor.

Perhaps you could step back and explain  the bigger picture and what's
awkward currently.  I don't doubt you that more is needed, but I am not
able to understand enough to discuss.


Attachment: signature.asc
Description: PGP signature



Home | Main Index | Thread Index | Old Index