Based on kernel version 4.16.1. Page generated on 2018-04-09 11:53 EST.
1 GPIO Sysfs Interface for Userspace 2 ================================== 3 4 THIS ABI IS DEPRECATED, THE ABI DOCUMENTATION HAS BEEN MOVED TO 5 Documentation/ABI/obsolete/sysfs-gpio AND NEW USERSPACE CONSUMERS 6 ARE SUPPOSED TO USE THE CHARACTER DEVICE ABI. THIS OLD SYSFS ABI WILL 7 NOT BE DEVELOPED (NO NEW FEATURES), IT WILL JUST BE MAINTAINED. 8 9 Refer to the examples in tools/gpio/* for an introduction to the new 10 character device ABI. Also see the userspace header in 11 include/uapi/linux/gpio.h 12 13 The deprecated sysfs ABI 14 ------------------------ 15 Platforms which use the "gpiolib" implementors framework may choose to 16 configure a sysfs user interface to GPIOs. This is different from the 17 debugfs interface, since it provides control over GPIO direction and 18 value instead of just showing a gpio state summary. Plus, it could be 19 present on production systems without debugging support. 20 21 Given appropriate hardware documentation for the system, userspace could 22 know for example that GPIO #23 controls the write protect line used to 23 protect boot loader segments in flash memory. System upgrade procedures 24 may need to temporarily remove that protection, first importing a GPIO, 25 then changing its output state, then updating the code before re-enabling 26 the write protection. In normal use, GPIO #23 would never be touched, 27 and the kernel would have no need to know about it. 28 29 Again depending on appropriate hardware documentation, on some systems 30 userspace GPIO can be used to determine system configuration data that 31 standard kernels won't know about. And for some tasks, simple userspace 32 GPIO drivers could be all that the system really needs. 33 34 DO NOT ABUSE SYSFS TO CONTROL HARDWARE THAT HAS PROPER KERNEL DRIVERS. 35 PLEASE READ THE DOCUMENT NAMED "drivers-on-gpio.txt" IN THIS DOCUMENTATION 36 DIRECTORY TO AVOID REINVENTING KERNEL WHEELS IN USERSPACE. I MEAN IT. 37 REALLY. 38 39 Paths in Sysfs 40 -------------- 41 There are three kinds of entries in /sys/class/gpio: 42 43 - Control interfaces used to get userspace control over GPIOs; 44 45 - GPIOs themselves; and 46 47 - GPIO controllers ("gpio_chip" instances). 48 49 That's in addition to standard files including the "device" symlink. 50 51 The control interfaces are write-only: 52 53 /sys/class/gpio/ 54 55 "export" ... Userspace may ask the kernel to export control of 56 a GPIO to userspace by writing its number to this file. 57 58 Example: "echo 19 > export" will create a "gpio19" node 59 for GPIO #19, if that's not requested by kernel code. 60 61 "unexport" ... Reverses the effect of exporting to userspace. 62 63 Example: "echo 19 > unexport" will remove a "gpio19" 64 node exported using the "export" file. 65 66 GPIO signals have paths like /sys/class/gpio/gpio42/ (for GPIO #42) 67 and have the following read/write attributes: 68 69 /sys/class/gpio/gpioN/ 70 71 "direction" ... reads as either "in" or "out". This value may 72 normally be written. Writing as "out" defaults to 73 initializing the value as low. To ensure glitch free 74 operation, values "low" and "high" may be written to 75 configure the GPIO as an output with that initial value. 76 77 Note that this attribute *will not exist* if the kernel 78 doesn't support changing the direction of a GPIO, or 79 it was exported by kernel code that didn't explicitly 80 allow userspace to reconfigure this GPIO's direction. 81 82 "value" ... reads as either 0 (low) or 1 (high). If the GPIO 83 is configured as an output, this value may be written; 84 any nonzero value is treated as high. 85 86 If the pin can be configured as interrupt-generating interrupt 87 and if it has been configured to generate interrupts (see the 88 description of "edge"), you can poll(2) on that file and 89 poll(2) will return whenever the interrupt was triggered. If 90 you use poll(2), set the events POLLPRI and POLLERR. If you 91 use select(2), set the file descriptor in exceptfds. After 92 poll(2) returns, either lseek(2) to the beginning of the sysfs 93 file and read the new value or close the file and re-open it 94 to read the value. 95 96 "edge" ... reads as either "none", "rising", "falling", or 97 "both". Write these strings to select the signal edge(s) 98 that will make poll(2) on the "value" file return. 99 100 This file exists only if the pin can be configured as an 101 interrupt generating input pin. 102 103 "active_low" ... reads as either 0 (false) or 1 (true). Write 104 any nonzero value to invert the value attribute both 105 for reading and writing. Existing and subsequent 106 poll(2) support configuration via the edge attribute 107 for "rising" and "falling" edges will follow this 108 setting. 109 110 GPIO controllers have paths like /sys/class/gpio/gpiochip42/ (for the 111 controller implementing GPIOs starting at #42) and have the following 112 read-only attributes: 113 114 /sys/class/gpio/gpiochipN/ 115 116 "base" ... same as N, the first GPIO managed by this chip 117 118 "label" ... provided for diagnostics (not always unique) 119 120 "ngpio" ... how many GPIOs this manages (N to N + ngpio - 1) 121 122 Board documentation should in most cases cover what GPIOs are used for 123 what purposes. However, those numbers are not always stable; GPIOs on 124 a daughtercard might be different depending on the base board being used, 125 or other cards in the stack. In such cases, you may need to use the 126 gpiochip nodes (possibly in conjunction with schematics) to determine 127 the correct GPIO number to use for a given signal. 128 129 130 Exporting from Kernel code 131 -------------------------- 132 Kernel code can explicitly manage exports of GPIOs which have already been 133 requested using gpio_request(): 134 135 /* export the GPIO to userspace */ 136 int gpiod_export(struct gpio_desc *desc, bool direction_may_change); 137 138 /* reverse gpio_export() */ 139 void gpiod_unexport(struct gpio_desc *desc); 140 141 /* create a sysfs link to an exported GPIO node */ 142 int gpiod_export_link(struct device *dev, const char *name, 143 struct gpio_desc *desc); 144 145 After a kernel driver requests a GPIO, it may only be made available in 146 the sysfs interface by gpiod_export(). The driver can control whether the 147 signal direction may change. This helps drivers prevent userspace code 148 from accidentally clobbering important system state. 149 150 This explicit exporting can help with debugging (by making some kinds 151 of experiments easier), or can provide an always-there interface that's 152 suitable for documenting as part of a board support package. 153 154 After the GPIO has been exported, gpiod_export_link() allows creating 155 symlinks from elsewhere in sysfs to the GPIO sysfs node. Drivers can 156 use this to provide the interface under their own device in sysfs with 157 a descriptive name.