Re: New header for GPIO-like definitions

[Julian Coleman <jdc%coris.org.uk@localhost>]

Hi,

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

Exactly.  In this case, it's the front panel and other LED's that show
status or faults, plus indicators connected to sensors to detect if disks
or PSU's are present, failed, etc.  For a particular machine model, they
are known (or observed and become known :-).

> 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
> next.
> 
> But given there is an led system, there is no incremental harm and it
> seems ok.

I think that we'll probably not find a GPIO that's wired to a non-LED
light.  If it becomes important, we can always add another definition for
it.

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

That makes sense.  Maybe GPIO_PIN_ENVSYS_INDICATOR although that's getting
a bit long.  I wonder if the naming is clear enough without "PIN" in the
name but I thought that it made sense to be more specific.

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

Yes, exactly.  Also, I'm not sure that it makes sense to expose this type
of GPIO to userspace apart from through the LED or envsys frameworks or
similar.  However, I don't want to discount that in future so grouping pins
into input or output could make sense.

> > Then, in the MD driver I have:
 
> Do you mean MD, or MI?

Thanks - MI.

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

Thank you!  I'll upload a patch with all the changes - that might make the
whole picture easier to see.

Regards,

Julian