Commit | Line | Data |
---|---|---|
fd8e198c AC |
1 | GPIO Descriptor Consumer Interface |
2 | ================================== | |
3 | ||
4 | This document describes the consumer interface of the GPIO framework. Note that | |
5 | it describes the new descriptor-based interface. For a description of the | |
6 | deprecated integer-based GPIO interface please refer to gpio-legacy.txt. | |
7 | ||
8 | ||
9 | Guidelines for GPIOs consumers | |
10 | ============================== | |
11 | ||
12 | Drivers that can't work without standard GPIO calls should have Kconfig entries | |
13 | that depend on GPIOLIB. The functions that allow a driver to obtain and use | |
14 | GPIOs are available by including the following file: | |
15 | ||
16 | #include <linux/gpio/consumer.h> | |
17 | ||
18 | All the functions that work with the descriptor-based GPIO interface are | |
19 | prefixed with gpiod_. The gpio_ prefix is used for the legacy interface. No | |
20 | other function in the kernel should use these prefixes. | |
21 | ||
22 | ||
23 | Obtaining and Disposing GPIOs | |
24 | ============================= | |
25 | ||
26 | With the descriptor-based interface, GPIOs are identified with an opaque, | |
27 | non-forgeable handler that must be obtained through a call to one of the | |
28 | gpiod_get() functions. Like many other kernel subsystems, gpiod_get() takes the | |
29 | device that will use the GPIO and the function the requested GPIO is supposed to | |
30 | fulfill: | |
31 | ||
32 | struct gpio_desc *gpiod_get(struct device *dev, const char *con_id) | |
33 | ||
34 | If a function is implemented by using several GPIOs together (e.g. a simple LED | |
35 | device that displays digits), an additional index argument can be specified: | |
36 | ||
37 | struct gpio_desc *gpiod_get_index(struct device *dev, | |
38 | const char *con_id, unsigned int idx) | |
39 | ||
40 | Both functions return either a valid GPIO descriptor, or an error code checkable | |
41 | with IS_ERR(). They will never return a NULL pointer. | |
42 | ||
43 | Device-managed variants of these functions are also defined: | |
44 | ||
45 | struct gpio_desc *devm_gpiod_get(struct device *dev, const char *con_id) | |
46 | ||
47 | struct gpio_desc *devm_gpiod_get_index(struct device *dev, | |
48 | const char *con_id, | |
49 | unsigned int idx) | |
50 | ||
51 | A GPIO descriptor can be disposed of using the gpiod_put() function: | |
52 | ||
53 | void gpiod_put(struct gpio_desc *desc) | |
54 | ||
55 | It is strictly forbidden to use a descriptor after calling this function. The | |
56 | device-managed variant is, unsurprisingly: | |
57 | ||
58 | void devm_gpiod_put(struct device *dev, struct gpio_desc *desc) | |
59 | ||
60 | ||
61 | Using GPIOs | |
62 | =========== | |
63 | ||
64 | Setting Direction | |
65 | ----------------- | |
66 | The first thing a driver must do with a GPIO is setting its direction. This is | |
67 | done by invoking one of the gpiod_direction_*() functions: | |
68 | ||
69 | int gpiod_direction_input(struct gpio_desc *desc) | |
70 | int gpiod_direction_output(struct gpio_desc *desc, int value) | |
71 | ||
72 | The return value is zero for success, else a negative errno. It should be | |
73 | checked, since the get/set calls don't return errors and since misconfiguration | |
74 | is possible. You should normally issue these calls from a task context. However, | |
75 | for spinlock-safe GPIOs it is OK to use them before tasking is enabled, as part | |
76 | of early board setup. | |
77 | ||
78 | For output GPIOs, the value provided becomes the initial output value. This | |
79 | helps avoid signal glitching during system startup. | |
80 | ||
81 | A driver can also query the current direction of a GPIO: | |
82 | ||
83 | int gpiod_get_direction(const struct gpio_desc *desc) | |
84 | ||
85 | This function will return either GPIOF_DIR_IN or GPIOF_DIR_OUT. | |
86 | ||
87 | Be aware that there is no default direction for GPIOs. Therefore, **using a GPIO | |
88 | without setting its direction first is illegal and will result in undefined | |
89 | behavior!** | |
90 | ||
91 | ||
92 | Spinlock-Safe GPIO Access | |
93 | ------------------------- | |
94 | Most GPIO controllers can be accessed with memory read/write instructions. Those | |
95 | don't need to sleep, and can safely be done from inside hard (non-threaded) IRQ | |
96 | handlers and similar contexts. | |
97 | ||
98 | Use the following calls to access GPIOs from an atomic context: | |
99 | ||
100 | int gpiod_get_value(const struct gpio_desc *desc); | |
101 | void gpiod_set_value(struct gpio_desc *desc, int value); | |
102 | ||
103 | The values are boolean, zero for low, nonzero for high. When reading the value | |
104 | of an output pin, the value returned should be what's seen on the pin. That | |
105 | won't always match the specified output value, because of issues including | |
106 | open-drain signaling and output latencies. | |
107 | ||
108 | The get/set calls do not return errors because "invalid GPIO" should have been | |
109 | reported earlier from gpiod_direction_*(). However, note that not all platforms | |
110 | can read the value of output pins; those that can't should always return zero. | |
111 | Also, using these calls for GPIOs that can't safely be accessed without sleeping | |
112 | (see below) is an error. | |
113 | ||
114 | ||
115 | GPIO Access That May Sleep | |
116 | -------------------------- | |
117 | Some GPIO controllers must be accessed using message based buses like I2C or | |
118 | SPI. Commands to read or write those GPIO values require waiting to get to the | |
119 | head of a queue to transmit a command and get its response. This requires | |
120 | sleeping, which can't be done from inside IRQ handlers. | |
121 | ||
122 | Platforms that support this type of GPIO distinguish them from other GPIOs by | |
123 | returning nonzero from this call: | |
124 | ||
125 | int gpiod_cansleep(const struct gpio_desc *desc) | |
126 | ||
127 | To access such GPIOs, a different set of accessors is defined: | |
128 | ||
129 | int gpiod_get_value_cansleep(const struct gpio_desc *desc) | |
130 | void gpiod_set_value_cansleep(struct gpio_desc *desc, int value) | |
131 | ||
132 | Accessing such GPIOs requires a context which may sleep, for example a threaded | |
133 | IRQ handler, and those accessors must be used instead of spinlock-safe | |
134 | accessors without the cansleep() name suffix. | |
135 | ||
136 | Other than the fact that these accessors might sleep, and will work on GPIOs | |
137 | that can't be accessed from hardIRQ handlers, these calls act the same as the | |
138 | spinlock-safe calls. | |
139 | ||
140 | ||
141 | Active-low State and Raw GPIO Values | |
142 | ------------------------------------ | |
143 | Device drivers like to manage the logical state of a GPIO, i.e. the value their | |
144 | device will actually receive, no matter what lies between it and the GPIO line. | |
145 | In some cases, it might make sense to control the actual GPIO line value. The | |
146 | following set of calls ignore the active-low property of a GPIO and work on the | |
147 | raw line value: | |
148 | ||
149 | int gpiod_get_raw_value(const struct gpio_desc *desc) | |
150 | void gpiod_set_raw_value(struct gpio_desc *desc, int value) | |
151 | int gpiod_get_raw_value_cansleep(const struct gpio_desc *desc) | |
152 | void gpiod_set_raw_value_cansleep(struct gpio_desc *desc, int value) | |
153 | ||
154 | The active-low state of a GPIO can also be queried using the following call: | |
155 | ||
156 | int gpiod_is_active_low(const struct gpio_desc *desc) | |
157 | ||
158 | Note that these functions should only be used with great moderation ; a driver | |
159 | should not have to care about the physical line level. | |
160 | ||
161 | GPIOs mapped to IRQs | |
162 | -------------------- | |
163 | GPIO lines can quite often be used as IRQs. You can get the IRQ number | |
164 | corresponding to a given GPIO using the following call: | |
165 | ||
166 | int gpiod_to_irq(const struct gpio_desc *desc) | |
167 | ||
168 | It will return an IRQ number, or an negative errno code if the mapping can't be | |
169 | done (most likely because that particular GPIO cannot be used as IRQ). It is an | |
170 | unchecked error to use a GPIO that wasn't set up as an input using | |
171 | gpiod_direction_input(), or to use an IRQ number that didn't originally come | |
172 | from gpiod_to_irq(). gpiod_to_irq() is not allowed to sleep. | |
173 | ||
174 | Non-error values returned from gpiod_to_irq() can be passed to request_irq() or | |
175 | free_irq(). They will often be stored into IRQ resources for platform devices, | |
176 | by the board-specific initialization code. Note that IRQ trigger options are | |
177 | part of the IRQ interface, e.g. IRQF_TRIGGER_FALLING, as are system wakeup | |
178 | capabilities. | |
179 | ||
180 | ||
181 | Interacting With the Legacy GPIO Subsystem | |
182 | ========================================== | |
183 | Many kernel subsystems still handle GPIOs using the legacy integer-based | |
184 | interface. Although it is strongly encouraged to upgrade them to the safer | |
185 | descriptor-based API, the following two functions allow you to convert a GPIO | |
186 | descriptor into the GPIO integer namespace and vice-versa: | |
187 | ||
188 | int desc_to_gpio(const struct gpio_desc *desc) | |
189 | struct gpio_desc *gpio_to_desc(unsigned gpio) | |
190 | ||
191 | The GPIO number returned by desc_to_gpio() can be safely used as long as the | |
192 | GPIO descriptor has not been freed. All the same, a GPIO number passed to | |
193 | gpio_to_desc() must have been properly acquired, and usage of the returned GPIO | |
194 | descriptor is only possible after the GPIO number has been released. | |
195 | ||
196 | Freeing a GPIO obtained by one API with the other API is forbidden and an | |
197 | unchecked error. |