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

>> >   #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.
> The definitions of pins are coming from hardware-specific properties.

That's what I missed.  On a device you are dealing with, pin N is
*always* wired to an LED because that's how it comes from the factory.
My head was in maker-land where there is an LED because someone wired
one up.

> In the driver, I'd like to be able to handle requests based on what is
> connected to the pin.  For example, for LED's, attach them to the LED
> framework using led_attach()

That makes sense, then.  But how do you denote that logical high turns
on he light, vs logical low?

>> 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"
> As above, I want to be able to route the pin to the correct internal
> subsystem in the GPIO driver.

I just remember lights before LED, and the fact that they are LED vs
incandescent is not important to how they are used.  I don't know what's

But given there is an led system, there is no incremental harm and it
seems ok.

>> 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.
> Yes, just reading the logic level to display whether the "thing" connected
> is on or off.  A better name would be appreciated.  Maybe "INDICATOR", which
> would match the envsys name "ENVSYS_INDICATOR"?

Or even "GPIO_ENVSYS_INDICATOR" because there might be some binary
inputs later that get hooked up to some other kind of framework.

> Hopefully, the above is enough, but maybe a code snippet would help (this
> snippet is only for LED's, but similar applies for other types).  In the
> hardware-specific driver, I add the pins to proplib:
> 	add_gpio_pin(pins, "disk_fault", GPIO_PIN_LED,
> 	    0, GPIO_PIN_ACT_LOW, -1);
> 	...

So I see the ACT_LOW.

GPIO_PIN_LED is an output, but presumably this means that one can no
longer use it with GPIO and only via led_.  Which seems fine. Is that
what you mean?

> Then, in the MD driver I have:
> 	pin = prop_array_get(pins, i);
> 	prop_dictionary_get_uint32(pin, "type", &type);
> 	switch (type) {
> 		case GPIO_PIN_LED:
> 			...
> 			led_attach(n, l, pcf8574_get, pcf8574_set);

Do you mean MD, or MI?

> and because of the way that this chip works, I also need to know in advance
> which pins are input and which are output, to avoid inadvertently changing
> the input pins to output when writing to the chip.  For that, generic
> GPIO_PIN_IS_INPUT and GPIO_PIN_IS_OUTPUT definitions might be useful too.

I 95% follow, but I am convinced that what you are doing is ok, so to be
clear I have no objections.

Attachment: signature.asc
Description: PGP signature

Home | Main Index | Thread Index | Old Index