From 38ed0187d2da7f219f9f84d8921b5c95b266b34b Mon Sep 17 00:00:00 2001 From: Harini Katakam Date: Tue, 8 Jul 2014 16:32:36 +0530 Subject: devicetree: Add Zynq GPIO devicetree bindings documentation Add gpio-zynq bindings documentation. Signed-off-by: Harini Katakam Signed-off-by: Soren Brinkmann Signed-off-by: Linus Walleij --- .../devicetree/bindings/gpio/gpio-zynq.txt | 26 ++++++++++++++++++++++ 1 file changed, 26 insertions(+) create mode 100644 Documentation/devicetree/bindings/gpio/gpio-zynq.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/gpio/gpio-zynq.txt b/Documentation/devicetree/bindings/gpio/gpio-zynq.txt new file mode 100644 index 000000000000..986371a4be2c --- /dev/null +++ b/Documentation/devicetree/bindings/gpio/gpio-zynq.txt @@ -0,0 +1,26 @@ +Xilinx Zynq GPIO controller Device Tree Bindings +------------------------------------------- + +Required properties: +- #gpio-cells : Should be two + - First cell is the GPIO line number + - Second cell is used to specify optional + parameters (unused) +- compatible : Should be "xlnx,zynq-gpio-1.0" +- clocks : Clock specifier (see clock bindings for details) +- gpio-controller : Marks the device node as a GPIO controller. +- interrupts : Interrupt specifier (see interrupt bindings for + details) +- interrupt-parent : Must be core interrupt controller +- reg : Address and length of the register set for the device + +Example: + gpio@e000a000 { + #gpio-cells = <2>; + compatible = "xlnx,zynq-gpio-1.0"; + clocks = <&clkc 42>; + gpio-controller; + interrupt-parent = <&intc>; + interrupts = <0 20 4>; + reg = <0xe000a000 0x1000>; + }; -- cgit v1.2.3 From d74be6dfea1b96cfb4bd79d9254fa9d21ed5f131 Mon Sep 17 00:00:00 2001 From: Alexandre Courbot Date: Tue, 22 Jul 2014 16:17:42 +0900 Subject: gpio: remove gpiod_lock/unlock_as_irq() gpio_lock/unlock_as_irq() are working with (chip, offset) arguments and are thus not using the old integer namespace. Therefore, there is no reason to have gpiod variants of these functions working with descriptors, especially since the (chip, offset) tuple is more suitable to the users of these functions (GPIO drivers, whereas GPIO descriptors are targeted at GPIO consumers). Signed-off-by: Alexandre Courbot Signed-off-by: Linus Walleij --- Documentation/gpio/driver.txt | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) (limited to 'Documentation') diff --git a/Documentation/gpio/driver.txt b/Documentation/gpio/driver.txt index fa9a0a8b3734..224dbbcd1804 100644 --- a/Documentation/gpio/driver.txt +++ b/Documentation/gpio/driver.txt @@ -157,12 +157,12 @@ Locking IRQ usage Input GPIOs can be used as IRQ signals. When this happens, a driver is requested to mark the GPIO as being used as an IRQ: - int gpiod_lock_as_irq(struct gpio_desc *desc) + int gpio_lock_as_irq(struct gpio_chip *chip, unsigned int offset) This will prevent the use of non-irq related GPIO APIs until the GPIO IRQ lock is released: - void gpiod_unlock_as_irq(struct gpio_desc *desc) + void gpio_unlock_as_irq(struct gpio_chip *chip, unsigned int offset) When implementing an irqchip inside a GPIO driver, these two functions should typically be called in the .startup() and .shutdown() callbacks from the -- cgit v1.2.3 From f7d4ad98fdd08932ffda2354c62e2e2ee059adcc Mon Sep 17 00:00:00 2001 From: Guenter Roeck Date: Tue, 22 Jul 2014 08:01:01 -0700 Subject: gpiolib: Export gpiochip_request_own_desc and gpiochip_free_own_desc Both functions were introduced to let gpio drivers request their own gpio pins. Without exporting the functions, this can however only be used by gpio drivers built into the kernel. Secondary impact is that the functions can not currently be used by platform initialization code associated with the gpio-pca953x driver. This code permits auto-export of gpio pins through platform data, but if this functionality is used, the module can no longer be unloaded due to the problem solved with the introduction of gpiochip_request_own_desc and gpiochip_free_own_desc. Export both function so they can be used from modules and from platform initialization code. Reviewed-by: Alexandre Courbot Reviewed-by: Mika Westerberg Signed-off-by: Guenter Roeck Signed-off-by: Linus Walleij --- Documentation/gpio/driver.txt | 21 +++++++++++++++++++++ 1 file changed, 21 insertions(+) (limited to 'Documentation') diff --git a/Documentation/gpio/driver.txt b/Documentation/gpio/driver.txt index 224dbbcd1804..18790c237977 100644 --- a/Documentation/gpio/driver.txt +++ b/Documentation/gpio/driver.txt @@ -167,3 +167,24 @@ is released: When implementing an irqchip inside a GPIO driver, these two functions should typically be called in the .startup() and .shutdown() callbacks from the irqchip. + + +Requesting self-owned GPIO pins +------------------------------- + +Sometimes it is useful to allow a GPIO chip driver to request its own GPIO +descriptors through the gpiolib API. Using gpio_request() for this purpose +does not help since it pins the module to the kernel forever (it calls +try_module_get()). A GPIO driver can use the following functions instead +to request and free descriptors without being pinned to the kernel forever. + + int gpiochip_request_own_desc(struct gpio_desc *desc, const char *label) + + void gpiochip_free_own_desc(struct gpio_desc *desc) + +Descriptors requested with gpiochip_request_own_desc() must be released with +gpiochip_free_own_desc(). + +These functions must be used with care since they do not affect module use +count. Do not use the functions to request gpio descriptors not owned by the +calling driver. -- cgit v1.2.3 From 0a6d315827eedc733d404ecff3cd4cc0e6437865 Mon Sep 17 00:00:00 2001 From: Linus Walleij Date: Thu, 24 Jul 2014 20:08:55 +0200 Subject: gpio: split gpiod board registration into machine header As per example from the regulator subsystem: put all defines and functions related to registering board info for GPIO descriptors into a separate header. Cc: Andrew Victor Cc: Nicolas Ferre Cc: Jean-Christophe Plagniol-Villard Cc: Ralf Baechle Cc: Thierry Reding Acked-by: Stephen Warren Reviewed-by: Alexandre Courbot Signed-off-by: Linus Walleij --- Documentation/gpio/board.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/gpio/board.txt b/Documentation/gpio/board.txt index ba169faad5c6..4452786225b8 100644 --- a/Documentation/gpio/board.txt +++ b/Documentation/gpio/board.txt @@ -60,7 +60,7 @@ Platform Data Finally, GPIOs can be bound to devices and functions using platform data. Board files that desire to do so need to include the following header: - #include + #include GPIOs are mapped by the means of tables of lookups, containing instances of the gpiod_lookup structure. Two macros are defined to help declaring such mappings: -- cgit v1.2.3 From 39b2bbe3d715cf5013b5c48695ccdd25bd3bf120 Mon Sep 17 00:00:00 2001 From: Alexandre Courbot Date: Fri, 25 Jul 2014 23:38:36 +0900 Subject: gpio: add flags argument to gpiod_get*() functions The huge majority of GPIOs have their direction and initial value set right after being obtained by one of the gpiod_get() functions. The integer GPIO API had gpio_request_one() that took a convenience flags parameter allowing to specify an direction and value applied to the returned GPIO. This feature greatly simplifies client code and ensures errors are always handled properly. A similar feature has been requested for the gpiod API. Since setting the direction of a GPIO is so often the very next action done after obtaining its descriptor, we prefer to extend the existing functions instead of introducing new functions that would raise the number of gpiod getters to 16 (!). The drawback of this approach is that all gpiod clients need to be updated. To limit the pain, temporary macros are introduced that allow gpiod_get*() to be called with or without the extra flags argument. They will be removed once all consumer code has been updated. Signed-off-by: Alexandre Courbot Reviewed-by: Mark Brown Signed-off-by: Linus Walleij --- Documentation/gpio/consumer.txt | 26 ++++++++++++++++++++------ 1 file changed, 20 insertions(+), 6 deletions(-) (limited to 'Documentation') diff --git a/Documentation/gpio/consumer.txt b/Documentation/gpio/consumer.txt index d8abfc31abbe..76546324e968 100644 --- a/Documentation/gpio/consumer.txt +++ b/Documentation/gpio/consumer.txt @@ -29,13 +29,24 @@ gpiod_get() functions. Like many other kernel subsystems, gpiod_get() takes the device that will use the GPIO and the function the requested GPIO is supposed to fulfill: - struct gpio_desc *gpiod_get(struct device *dev, const char *con_id) + struct gpio_desc *gpiod_get(struct device *dev, const char *con_id, + enum gpiod_flags flags) If a function is implemented by using several GPIOs together (e.g. a simple LED device that displays digits), an additional index argument can be specified: struct gpio_desc *gpiod_get_index(struct device *dev, - const char *con_id, unsigned int idx) + const char *con_id, unsigned int idx, + enum gpiod_flags flags) + +The flags parameter is used to optionally specify a direction and initial value +for the GPIO. Values can be: + +* GPIOD_ASIS or 0 to not initialize the GPIO at all. The direction must be set + later with one of the dedicated functions. +* GPIOD_IN to initialize the GPIO as input. +* GPIOD_OUT_LOW to initialize the GPIO as output with a value of 0. +* GPIOD_OUT_HIGH to initialize the GPIO as output with a value of 1. Both functions return either a valid GPIO descriptor, or an error code checkable with IS_ERR() (they will never return a NULL pointer). -ENOENT will be returned @@ -46,11 +57,13 @@ errors and an absence of GPIO for optional GPIO parameters. Device-managed variants of these functions are also defined: - struct gpio_desc *devm_gpiod_get(struct device *dev, const char *con_id) + struct gpio_desc *devm_gpiod_get(struct device *dev, const char *con_id, + enum gpiod_flags flags) struct gpio_desc *devm_gpiod_get_index(struct device *dev, const char *con_id, - unsigned int idx) + unsigned int idx, + enum gpiod_flags flags) A GPIO descriptor can be disposed of using the gpiod_put() function: @@ -67,8 +80,9 @@ Using GPIOs Setting Direction ----------------- -The first thing a driver must do with a GPIO is setting its direction. This is -done by invoking one of the gpiod_direction_*() functions: +The first thing a driver must do with a GPIO is setting its direction. If no +direction-setting flags have been given to gpiod_get*(), this is done by +invoking one of the gpiod_direction_*() functions: int gpiod_direction_input(struct gpio_desc *desc) int gpiod_direction_output(struct gpio_desc *desc, int value) -- cgit v1.2.3