[meta-xilinx] gpio export from device tree
Alan Levy
alan.levy at plextek.com
Wed Mar 1 02:16:26 PST 2017
In order to give userspace GPIOs sane names I use devicetree aliases which application code can access from /proc/device-tree/aliases. Each GPIO has an alias with a sensible name and the string I assign to it supplies the GPIO pin number and any other relevant info such as whether it's an input or an output and whether it's active high or active low.
This technique can also be used to tell application the base pin numbers for MIO/EMIO if you wish.
-----Original Message-----
From: Mike Looijmans [mailto:mike.looijmans at topic.nl]
Sent: 28 February 2017 11:07
To: meta-xilinx at yoctoproject.org
Subject: Re: [meta-xilinx] gpio export from device tree
On 27-02-17 22:52, Jean-Francois Dagenais wrote:
...
> 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…
There have been a number of proposals for this in the kernel, but they've all been rejected. The consensus seems to be that you should write a driver if you want to do this kind of thing in a portable way.
> * (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.
They map really weird yeah. Maybe it's on purpose to discourage using gpio from userspace...
Best solution I found was to open /sys/class/gpiochip*/name files and look for the zynq gpio controller, and then use that offset. On my current board the zynq GPIO starts at "906". With 54 MIO GPIO pins, the EMIO GPIO pins thus start at 960.
--
Mike Looijmans
Kind regards,
Mike Looijmans
System Expert
TOPIC Products
Materiaalweg 4, NL-5681 RJ Best
Postbus 440, NL-5680 AK Best
Telefoon: +31 (0) 499 33 69 79
E-mail: mike.looijmans at topicproducts.com
Website: www.topicproducts.com
Please consider the environment before printing this e-mail
More information about the meta-xilinx
mailing list