gpiolib locking simplified
Subsystems (2)
PATCH 1/1 gpiolib locking simplified
Simplify the hot-path (gpio value get/set) locking by taking advantage of the fact that gpio_request() effectively locks that GPIO in memory. This also helps avoid the belated complaints about whether this locking is one of the places raw spinlocks are OK to use; it's now back to using regular spinlocks.
Also update docs to clarify some issues that came up. We'd like to eventually have direction-setting stop implicitly requesting GPIOs, so discourage that usage. Also document the "locking" implication of gpio_request().
This is a code shrink relative to the previous code, most of it by removing explicit locking calls from those hot paths.
Signed-off-by David Brownell <[email protected]>
--- Documentation/gpio.txt | 14 ++++- lib/gpiolib.c | 116 +++++++++++++------------------------------------ 2 files changed, 42 insertions(+), 88 deletions(-)
Documentation/gpio.txt +11 -3
@@ -123,6 +123,10 @@ before tasking is enabled, as part of ea For output GPIOs, the value provided becomes the initial output value. This helps avoid signal glitching during system startup. +For compatibility with legacy interfaces to GPIOs, setting the direction +of a GPIO implicitly requests that GPIO (see below). That compatibility +may be removed in the future; explicitly requesting GPIOs is preferred. + Setting the direction can fail if the GPIO number is invalid, or when that particular GPIO can't be used in that mode. It's generally a bad idea to rely on boot firmware to have set the direction correctly, since
@@ -173,7 +177,8 @@ get to the head of a queue to transmit a This requires sleeping, which can't be done from inside IRQ handlers. Platforms that support this type of GPIO distinguish them from other GPIOs -by returning nonzero from this call: +by returning nonzero from this call (which requires a valid GPIO number, +either explicitly or implicitly requested): int gpio_cansleep(unsigned gpio);
@@ -212,8 +217,11 @@ before tasking is enabled, as part of ea These calls serve two basic purposes. One is marking the signals which are actually in use as GPIOs, for better diagnostics; systems may have several hundred potential GPIOs, but often only a dozen are used on any -given board. Another is to catch conflicts between drivers, reporting -errors when drivers wrongly think they have exclusive use of that signal. +given board. Another is to catch conflicts, identifying errors when +(a) two or more drivers wrongly think they have exclusive use of that +signal, or (b) something wrongly believes it's safe to remove drivers +needed to manage a signal that's in active use. That is, requesting a +GPIO can serve as a kind of lock. These two calls are optional because not not all current Linux platforms offer such functionality in their GPIO support; a valid implementation
lib/gpiolib.c +31 -85
268 lines not on this page · raw message