cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Highlighted
Participant
Participant
418 Views
Registered: ‎01-13-2019

please explain usage of /sys/class/gpio/

Jump to solution

when following ug1209, I came to the following codes in ps_pl_linux_app.c file.

system("echo 347 > /sys/class/gpio/export");	//SW19 - PS switch
system("echo in > /sys/class/gpio/gpio347/direction");

 

What is the value 347? And why use it for SW19?

 

I got the following information:

- From ZCU111 board user guide, the PS-side SW19 is connected to MIO22.

- in zcu111-reva.dtsi file:

gpio-keys {
	compatible = "gpio-keys";
	autorepeat;
	sw19 {
		label = "sw19";
		gpios = <&gpio 22 GPIO_ACTIVE_HIGH>;
		linux,code = <KEY_DOWN>; /* down */
		wakeup-source;
		autorepeat;
	};
};

 However, with these information, I couldn't understand where is the 347 in the code comes from.

Thanks for help.

Tags (1)
0 Kudos
1 Solution

Accepted Solutions
Highlighted
Scholar
Scholar
325 Views
Registered: ‎05-28-2013

But on my ZCU111, when cat the ngpio value for chip338, it only shows a 174 value, not the details bank and offset values.

Is this expected? Or I need to check in a different way?


This is expected. As far as Linux is concerned, the ZynqMP is a single "gpio controller" which has 174 pins (the first 78 being the MIO, followed by 96 EMIO pins). The linux GPIO subsystem has no concept of "Banks". So to access SW19 connected to MIO22, the value to use would be 338+22=360. If it was connected to EMIO22 instead, then it would be 338+78+22=438.

There may be other "gpio controller" devices present in your system - maybe I2C or SPI devices, or even PL pins with associated logic. If you add/remove/enable/disable any of these (for example with status="okay" in devicetree) then the base value for all gpio controllers can shift. What was previously at base 338 may now be shifted to a different value. This is because gpio controllers are probed in a particular order, and allocate their numbers using a particular algorithm.

To avoid these problems, since kernel 4.8, the /sys/class/gpio API has been deprecated in favour of a better one. See  https://embeddedbits.org/new-linux-kernel-gpio-user-space-interface/ for a nice overview.

View solution in original post

9 Replies
Highlighted
405 Views
Registered: ‎05-17-2018

Please look at this post https://forums.xilinx.com/t5/Embedded-Linux/GPIO-control-in-Linux-sysfs/td-p/833075 where stephenm explains how to use /sys/class/gpio. I hope it will help you

Highlighted
Scholar
Scholar
367 Views
Registered: ‎05-28-2013

You can also refer to https://www.linuxsecrets.com/xilinx/Linux%20GPIO%20Driver.html (seems to be a copy of the Xilinx wiki), which states:


It may also be calculated ahead of time based on compile-time options for Linux. The basic formula (for Zynq) is base_gpio=ARCH_NR_GPIOS - ZYNQ_GPIO_NR_GPIOS. Then, allocated_gpios=ARCH_NR_GPIOS - base_gpio. Next, other_gpio=allocated_gpios - ZYNQ_GPIO_NR_GPIOS. Finally, gpio_offset=base_gpio + other_gpio. So, to calculate a specific GPIO number, it is base_gpio + other_gpios. This method may not be reliable permanently if ARCH_NR_GPIOS or ZYNQ_GPIO_NR_GPIOS changes without warning in the Linux kernel source code.

Note however that the /sys/class/gpio method is deprecated, in part due to the difficulty of determining the correct numbering. The replacement method is libgpiod (https://git.kernel.org/pub/scm/libs/libgpiod/libgpiod.git/tree/README) which uses hierarchical addressing.

0 Kudos
Highlighted
Participant
Participant
351 Views
Registered: ‎01-13-2019

Thanks for the link, I came to that info from Linux wiki page, but the calculation is not that straightforward.

The chip base address + the MIO number from the user guide might be easier.

0 Kudos
Highlighted
Participant
Participant
349 Views
Registered: ‎01-13-2019

@sulcas.mindaugas 

Thanks for the link, the info is helpful.

But on my ZCU111, when cat the ngpio value for chip338, it only shows a 174 value, not the details bank and offset values.

Is this expected? Or I need to check in a different way?

0 Kudos
Highlighted
Scholar
Scholar
326 Views
Registered: ‎05-28-2013

But on my ZCU111, when cat the ngpio value for chip338, it only shows a 174 value, not the details bank and offset values.

Is this expected? Or I need to check in a different way?


This is expected. As far as Linux is concerned, the ZynqMP is a single "gpio controller" which has 174 pins (the first 78 being the MIO, followed by 96 EMIO pins). The linux GPIO subsystem has no concept of "Banks". So to access SW19 connected to MIO22, the value to use would be 338+22=360. If it was connected to EMIO22 instead, then it would be 338+78+22=438.

There may be other "gpio controller" devices present in your system - maybe I2C or SPI devices, or even PL pins with associated logic. If you add/remove/enable/disable any of these (for example with status="okay" in devicetree) then the base value for all gpio controllers can shift. What was previously at base 338 may now be shifted to a different value. This is because gpio controllers are probed in a particular order, and allocate their numbers using a particular algorithm.

To avoid these problems, since kernel 4.8, the /sys/class/gpio API has been deprecated in favour of a better one. See  https://embeddedbits.org/new-linux-kernel-gpio-user-space-interface/ for a nice overview.

View solution in original post

Highlighted
Participant
Participant
318 Views
Registered: ‎01-13-2019

@rfs613 

Thanks for the explanations. It is quite helpful.

I have PL SWes and LEDs connected to GPIO controller, so my base is 325 and with SW19 (MIO22), I got 347 to use in user space.

I will check the link provided.

Thanks a gain.

0 Kudos
Highlighted
Participant
Participant
270 Views
Registered: ‎01-13-2019
When you referencing the new GPIO API, do you mean Xilinx/PetaLinux can support this?
Do I need to do anything to make the new APIs/CMDs available (say, enable it somewhere in petalinux-config???)?

I can see there are /dev/gpiochip[0123] on my linux image, but those CMD commands (e.g. gpiodetect, gpioinfo ...) are not available.

Thanks a lot.
0 Kudos
Highlighted
Scholar
Scholar
230 Views
Registered: ‎05-28-2013

@liuyz wrote:
When you referencing the new GPIO API, do you mean Xilinx/PetaLinux can support this?
Do I need to do anything to make the new APIs/CMDs available (say, enable it somewhere in petalinux-config???)?

You can enable the userspace commands (gpiodetect etc) by running petalinux-config -c rootfs, then select Filesystem Packages --> libs --> libgpiod.

Highlighted
Participant
Participant
213 Views
Registered: ‎01-13-2019

@rfs613 

Thanks a lot for the details.

0 Kudos