diff options
author | Linus Torvalds <torvalds@linux-foundation.org> | 2017-02-23 19:46:04 +0300 |
---|---|---|
committer | Linus Torvalds <torvalds@linux-foundation.org> | 2017-02-23 19:46:04 +0300 |
commit | 1ec5c1867af085897bb9e0f67bef3713334dbe7f (patch) | |
tree | 6d4fa09006a3a4a163fd357bc10da047207341cf /Documentation | |
parent | d5dee39b27201f9f5460eca55efcc91a663b738c (diff) | |
parent | 3498d8694d41af701c51289e7caf3ffefc7bfb6b (diff) | |
download | linux-1ec5c1867af085897bb9e0f67bef3713334dbe7f.tar.xz |
Merge tag 'gpio-v4.11-1' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio
Pull GPIO updates from Linus Walleij:
"This is the bulk of GPIO changes for the v4.11 cycle
Core changes:
- Augment fwnode_get_named_gpiod() to configure the GPIO pin
immediately after requesting it like all other APIs do. This is a
treewide change also updating all users.
- Pass a GPIO label down to gpiod_request() from
fwnode_get_named_gpiod(). This makes debugfs and the userspace ABI
correctly reflect the current in-kernel consumer of a pin taken
using this abstraction. This is a treewide change also updating all
users.
- Rename devm_get_gpiod_from_child() to
devm_fwnode_get_gpiod_from_child() to reflect the fact that this
function is operating on a fwnode object. This is a treewide change
also updating all users.
- Make it possible to take multiple GPIOs in a single hog of device
tree hogs.
- The refactorings switching GPIO chips to use the .set_config()
callback using standard pin control properties and providing a
backend into the pin control subsystem that were also merged into
the pin control tree naturally appear here too.
Testing instrumentation:
- A whole slew of cleanups and improvements to the mockup GPIO
driver. We now have an extended userspace test exercising the
subsystem, and we can inject interrupts etc from userspace to fully
test the core GPIO functionality.
New drivers:
- New driver for the Cortina Systems Gemini GPIO controller.
- New driver for the Exar XR17V352/354/358 chips.
- New driver for the ACCES PCI-IDIO-16 PCI GPIO card.
Driver changes:
- RCAR: set the irqchip parent device, add fine-grained runtime PM
support.
- pca953x: support optional RESET control line on the chip.
- DaVinci: cleanups and simplifications. Add support for multiple
instances.
- .set_multiple() and naming of lines on more or less all of the
ISA/PCI GPIO controllers.
- mcp23s08: refactored to use regmap as a first step to further
rewrites and modernizations"
* tag 'gpio-v4.11-1' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio: (61 commits)
gpio: reintroduce devm_get_gpiod_from_child()
gpio: pci-idio-16: Fix PCI BAR index
gpio: pci-idio-16: Fix PCI device ID code
gpio: mockup: implement event injecting over debugfs
gpio: mockup: add a dummy irqchip
gpio: mockup: implement naming the lines
gpio: mockup: code shrink
gpio: mockup: readability tweaks
gpio: Add GPIO support for the ACCES PCI-IDIO-16
gpio: Add the devm_fwnode_get_index_gpiod_from_child() helper
gpio: Rename devm_get_gpiod_from_child()
gpio: mcp23s08: Select REGMAP/REGMAP_I2C to fix build error
gpio: ws16c48: Add support for GPIO names
gpio: gpio-mm: Add support for GPIO names
gpio: 104-idio-16: Add support for GPIO names
gpio: 104-idi-48: Add support for GPIO names
gpio: 104-dio-48e: Add support for GPIO names
gpio: ws16c48: Remove unnecessary driver_data set
gpio: gpio-mm: Remove unnecessary driver_data set
gpio: 104-idio-16: Remove unnecessary driver_data set
...
Diffstat (limited to 'Documentation')
-rw-r--r-- | Documentation/devicetree/bindings/gpio/cortina,gemini-gpio.txt | 24 | ||||
-rw-r--r-- | Documentation/devicetree/bindings/gpio/gpio-pca953x.txt | 4 | ||||
-rw-r--r-- | Documentation/devicetree/bindings/gpio/gpio.txt | 8 | ||||
-rw-r--r-- | Documentation/gpio/driver.txt | 55 |
4 files changed, 78 insertions, 13 deletions
diff --git a/Documentation/devicetree/bindings/gpio/cortina,gemini-gpio.txt b/Documentation/devicetree/bindings/gpio/cortina,gemini-gpio.txt new file mode 100644 index 000000000000..5c9246c054e5 --- /dev/null +++ b/Documentation/devicetree/bindings/gpio/cortina,gemini-gpio.txt @@ -0,0 +1,24 @@ +Cortina Systems Gemini GPIO Controller + +Required properties: + +- compatible : Must be "cortina,gemini-gpio" +- reg : Should contain registers location and length +- interrupts : Should contain the interrupt line for the GPIO block +- gpio-controller : marks this as a GPIO controller +- #gpio-cells : Should be 2, see gpio/gpio.txt +- interrupt-controller : marks this as an interrupt controller +- #interrupt-cells : a standard two-cell interrupt flag, see + interrupt-controller/interrupts.txt + +Example: + +gpio@4d000000 { + compatible = "cortina,gemini-gpio"; + reg = <0x4d000000 0x100>; + interrupts = <22 IRQ_TYPE_LEVEL_HIGH>; + gpio-controller; + #gpio-cells = <2>; + interrupt-controller; + #interrupt-cells = <2>; +}; diff --git a/Documentation/devicetree/bindings/gpio/gpio-pca953x.txt b/Documentation/devicetree/bindings/gpio/gpio-pca953x.txt index 08dd15f89ba9..e63935710011 100644 --- a/Documentation/devicetree/bindings/gpio/gpio-pca953x.txt +++ b/Documentation/devicetree/bindings/gpio/gpio-pca953x.txt @@ -29,6 +29,10 @@ Required properties: onsemi,pca9654 exar,xra1202 +Optional properties: + - reset-gpios: GPIO specification for the RESET input. This is an + active low signal to the PCA953x. + Example: diff --git a/Documentation/devicetree/bindings/gpio/gpio.txt b/Documentation/devicetree/bindings/gpio/gpio.txt index 68d28f62a6f4..84ede036f73d 100644 --- a/Documentation/devicetree/bindings/gpio/gpio.txt +++ b/Documentation/devicetree/bindings/gpio/gpio.txt @@ -187,10 +187,10 @@ gpio-controller's driver probe function. Each GPIO hog definition is represented as a child node of the GPIO controller. Required properties: -- gpio-hog: A property specifying that this child node represent a GPIO hog. -- gpios: Store the GPIO information (id, flags, ...). Shall contain the - number of cells specified in its parent node (GPIO controller - node). +- gpio-hog: A property specifying that this child node represents a GPIO hog. +- gpios: Store the GPIO information (id, flags, ...) for each GPIO to + affect. Shall contain an integer multiple of the number of cells + specified in its parent node (GPIO controller node). Only one of the following properties scanned in the order shown below. This means that when multiple properties are present they will be searched in the order presented below and the first match is taken as the intended diff --git a/Documentation/gpio/driver.txt b/Documentation/gpio/driver.txt index ad8f0c0cd13f..fc1d2f83564d 100644 --- a/Documentation/gpio/driver.txt +++ b/Documentation/gpio/driver.txt @@ -41,34 +41,71 @@ In the gpiolib framework each GPIO controller is packaged as a "struct gpio_chip" (see linux/gpio/driver.h for its complete definition) with members common to each controller of that type: - - methods to establish GPIO direction - - methods used to access GPIO values - - method to return the IRQ number associated to a given GPIO + - methods to establish GPIO line direction + - methods used to access GPIO line values + - method to set electrical configuration to a a given GPIO line + - method to return the IRQ number associated to a given GPIO line - flag saying whether calls to its methods may sleep + - optional line names array to identify lines - optional debugfs dump method (showing extra state like pullup config) - optional base number (will be automatically assigned if omitted) - - label for diagnostics and GPIOs mapping using platform data + - optional label for diagnostics and GPIO chip mapping using platform data The code implementing a gpio_chip should support multiple instances of the controller, possibly using the driver model. That code will configure each -gpio_chip and issue gpiochip_add(). Removing a GPIO controller should be rare; -use gpiochip_remove() when it is unavoidable. +gpio_chip and issue gpiochip_add[_data]() or devm_gpiochip_add_data(). +Removing a GPIO controller should be rare; use [devm_]gpiochip_remove() when +it is unavoidable. -Most often a gpio_chip is part of an instance-specific structure with state not +Often a gpio_chip is part of an instance-specific structure with states not exposed by the GPIO interfaces, such as addressing, power management, and more. -Chips such as codecs will have complex non-GPIO state. +Chips such as audio codecs will have complex non-GPIO states. Any debugfs dump method should normally ignore signals which haven't been requested as GPIOs. They can use gpiochip_is_requested(), which returns either NULL or the label associated with that GPIO when it was requested. -RT_FULL: GPIO driver should not use spinlock_t or any sleepable APIs +RT_FULL: the GPIO driver should not use spinlock_t or any sleepable APIs (like PM runtime) in its gpio_chip implementation (.get/.set and direction control callbacks) if it is expected to call GPIO APIs from atomic context on -RT (inside hard IRQ handlers and similar contexts). Normally this should not be required. +GPIO electrical configuration +----------------------------- + +GPIOs can be configured for several electrical modes of operation by using the +.set_config() callback. Currently this API supports setting debouncing and +single-ended modes (open drain/open source). These settings are described +below. + +The .set_config() callback uses the same enumerators and configuration +semantics as the generic pin control drivers. This is not a coincidence: it is +possible to assign the .set_config() to the function gpiochip_generic_config() +which will result in pinctrl_gpio_set_config() being called and eventually +ending up in the pin control back-end "behind" the GPIO controller, usually +closer to the actual pins. This way the pin controller can manage the below +listed GPIO configurations. + + +GPIOs with debounce support +--------------------------- + +Debouncing is a configuration set to a pin indicating that it is connected to +a mechanical switch or button, or similar that may bounce. Bouncing means the +line is pulled high/low quickly at very short intervals for mechanical +reasons. This can result in the value being unstable or irqs fireing repeatedly +unless the line is debounced. + +Debouncing in practice involves setting up a timer when something happens on +the line, wait a little while and then sample the line again, so see if it +still has the same value (low or high). This could also be repeated by a clever +state machine, waiting for a line to become stable. In either case, it sets +a certain number of milliseconds for debouncing, or just "on/off" if that time +is not configurable. + + GPIOs with open drain/source support ------------------------------------ |