Re: New header for GPIO-like definitions

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

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 for things like i2c temp and light sensors that can generate interrupts when thresholds are crossed).

I sent the mail because I wasn't sure about the best way to pass the details
between the MI and MD parts, so getting feedback before definiting a new API
or mechanism is good.

Having the ability to tie separate components together would be useful too.
For an old example, the sparc port hardcodes the logic for powering the
serial ports and for displaying disk/net status on the Sparcbook3:

  https://nxr.netbsd.org/xref/src/sys/arch/sparc/dev/tctrl.c#1477
  https://nxr.netbsd.org/xref/src/sys/arch/sparc/dev/zs.c#991

and having a generic way of specifying this would be a lot better.  On the
hardware I'm looking at now, lighting the PSU fault LED when we receive a
PSU failure indication makes a lot of sense, and that requires connecting
together 2 separate GPIO's as well as envsys.

> 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
> 
> Right now to use that sort of thing in the NetBSD kernel, you need to be an FDT'ized platform, but I have some experimental changes brewing in one of my hacked-up trees that attempts to make it more generic with the concepts being available on more platforms (and possibly backed by device's properties dictionary).

Using the device's properties would work for me.  The existing code already
uses device properties to pass pin information from MD to MI drivers:

  https://nxr.netbsd.org/xref/src/sys/arch/sparc64/sparc64/ofw_patch.c#add_gpio_LED

so having a standard dictionary and using that would be great.

Do you have a proposed dictionary/mapping for the FDT bindings?

Regards,

Julian