[meta-xilinx] gpio export from device tree

Jean-Francois Dagenais jeff.dagenais at gmail.com
Mon Feb 27 13:52:00 PST 2017


Hi guys,

In a previous design on x86, in the kernel, I was exporting a bunch of system gpios to sysfs/userspace with direction and names using gpio_request_one() from platform init code.

I’m now trying to achieve something similar on zynq/zynqmp but hopefully without having to write a driver, i.e. all from devicetree.

I am kind of new to the zynq architecture so please bear with me.

I have already integrated our ps[u7]_init_gpl.[ch] into my build of u-boot. These files come from my colleagues who spend their day in Vivado and have correctly configured the project and generated the correct output (fpga.bin and platform init files). So my understanding is that from my vantage point once the kernel is loading, all that needs to be configured is the direction and value (if output). That is, I don’t think I need to mess around the pinctrl part of things in my dts.

Now I know I could have the userspace do the job of exporting specific pins right from sysfs but I think this knowledge should reside in a devicetree. The pins I am trying to export are part of a subsystem composed of various parts which are all declared in the dts. To give you a better idea, the subsystem includes a DAC (iio driver), a ADC (a hwmon driver) and some GPIOs in both input and output. The subsystem is controlled from userspace and uses all of the components.

So my questions are:
* which clause, if any, is proper in dts to export the GPIOs preferably with names (like /sys/class/gpio/my_gpio_name_here). Do I need to declare a new node which doesn’t bind to a diver for example…
* (this one may be quite available in the megabytes of documentation) how does the gpio numbers in the kernel map to MIOxx and EMIOxx numbers. If anyone could point at the right doc that would save me so much grief.

Thanks a bunch to all contributors!
Really looking forward to keep working with all of you! (we should get our ZU+ board soon)

/jfd


More information about the meta-xilinx mailing list