Julian Coleman writes:
> name="LED activity"
> name="LED disk5_fault"
>
> name="INDICATOR key_diag"
> name="INDICATOR disk5_present"
>
> and similar, then parse that in MI code.
Another approach would be to extend the fdt schema in the way they would
if solving this problem and use
Hi,
> > Might I suggest before we go to deep down the rabbit hole that you take a
> > look at the GPIO FDT bindings?
> >
> >
> > https://github.com/devicetree-org/devicetree-source/blob/master/Bindings/gpio/gpio.txt
Looking at the bindings, there are definitions of polarity, which I need
Hi,
> Sorry guys for chiming in a little late, but I have a keen interest in this
> area, and there are lots of ways this needs to be harmonized across the
> system, including the ability to have a generic way to specify that an
> interrupt source, for example, is tied to a GPIO pin (useful
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
>
> On Oct 26, 2020, at 8:58 AM, Julian Coleman wrote:
>
> Hi,
>
> Thanks for the comments!
>
>>> #define GPIO_PIN_LED0x01
>>> #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
Julian Coleman writes:
>> > #define GPIO_PIN_LED0x01
>> > #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
Hi,
Thanks for the comments!
> > #define GPIO_PIN_LED0x01
> > #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
Julian Coleman 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
Hi all,
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
