cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
liuyz
Adventurer
Adventurer
1,580 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
rfs613
Scholar
Scholar
1,487 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

11 Replies
sulcas.mindaugas
Participant
Participant
1,567 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

rfs613
Scholar
Scholar
1,529 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
liuyz
Adventurer
Adventurer
1,513 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
liuyz
Adventurer
Adventurer
1,511 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
rfs613
Scholar
Scholar
1,488 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

liuyz
Adventurer
Adventurer
1,480 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
liuyz
Adventurer
Adventurer
1,432 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
rfs613
Scholar
Scholar
1,392 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.

liuyz
Adventurer
Adventurer
1,375 Views
Registered: ‎01-13-2019

@rfs613 

Thanks a lot for the details.

0 Kudos
fbalakirev
Contributor
Contributor
911 Views
Registered: ‎03-20-2014

Thank you for pointing out new chardev interface rfs613

Is it supported by the latest RFSoC evaluation bsp by any chance?

I would like to be able to start DAC tiles streaming synchronously and it appears that It is possible to read or write to multiple GPIO lines at once with new interface, which let me try just that.

How would one need to change the example code to use new interface?  e.g.  rfdc-data-write-example

0 Kudos
rfs613
Scholar
Scholar
896 Views
Registered: ‎05-28-2013

@fbalakirev Afraid I can't give you a definitive answer, as I have not used the RFSoC eval BSP. It seems to be based on Petalinux with additional patches on top. Petalinux includes kernel support for the new chardev interface, but userspace tools must be enabled manually. So my guess would be its the same for the RFSoC BSP.

0 Kudos