summaryrefslogtreecommitdiff
path: root/Documentation/devicetree/bindings/gpio/gpio.txt
AgeCommit message (Collapse)Author
2015-11-02Merge tag 'gpio-v4.4-1' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio Pull GPIO updates from Linus Walleij: "Here is the bulk of GPIO changes for the v4.4 development cycle. The only changes hitting outside drivers/gpio are in the pin control subsystem and these seem to have settled nicely in linux-next. Development mistakes and catfights are nicely documented in the reverts as you can see. The outcome of the ABI fight is that we're working on a chardev ABI for GPIO now, where hope to show results for the v4.5 kernel. Summary of changes: GPIO core: - Define and handle flags for open drain/open collector and open source/open emitter, also know as "single-ended" configurations. - Generic request/free operations that handle calling out to the (optional) pin control backend. - Some refactoring related to an ABI change that did not happen, yet provide useful. - Added a real-time compliance checklist. Many GPIO chips have irqchips, and need to think this over with the RT patches going upstream. - Restructure, fix and clean up Kconfig menus a bit. New drivers: - New driver for AMD Promony. - New driver for ACCES 104-IDIO-16, a port-mapped I/O card, ISA-style. Very retro. Subdriver changes: - OMAP changes to handle real time requirements. - Handle trigger types for edge and level IRQs on PL061 properly. As this hardware is very common it needs to set a proper example for others to follow. - Some container_of() cleanups. - Delete the unused MSM driver in favor of the driver that is embedded inside the pin control driver. - Cleanup of the ath79 GPIO driver used by many, many OpenWRT router targets. - A consolidated IT87xx driver replacing the earlier very specific IT8761e driver. - Handle the TI TCA9539 in the PCA953x driver. Also handle ACPI devices in this subdriver. - Drop xilinx arch dependencies as these FPGAs seem to profilate over a few different architectures. MIPS and ARM come to mind" * tag 'gpio-v4.4-1' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio: (57 commits) gpio: fix up SPI submenu gpio: drop surplus I2C dependencies gpio: drop surplus X86 dependencies gpio: dt-bindings: document the official use of "ngpios" gpio: MAINTAINERS: Add an entry for the ATH79 GPIO driver gpio / ACPI: Allow shared GPIO event to be read via operation region gpio: group port-mapped I/O drivers in a menu gpio: Add ACCES 104-IDIO-16 driver maintainer entry gpio: zynq: Document interrupt-controller DT binding gpio: xilinx: Drop architecture dependencies gpio: generic: Revert to old error handling in bgpio_map gpio: add a real time compliance notes Revert "gpio: add a real time compliance checklist" gpio: Add GPIO support for the ACCES 104-IDIO-16 gpio: driver for AMD Promontory gpio: xlp: Convert to use gpiolib irqchip helpers gpio: add a real time compliance checklist gpio/xilinx: enable for MIPS gpiolib: Add and use OF_GPIO_SINGLE_ENDED flag gpiolib: Split GPIO flags parsing and GPIO configuration ...
2015-10-31gpio: dt-bindings: document the official use of "ngpios"Linus Walleij
There are a bunch of drivers that utilize the "ngpios" DT property without any vendor prefix. Try to start cleaning up the mess by defining what we mean by this property. Cc: devicetree@vger.kernel.org Cc: Pramod Kumar <pramodku@broadcom.com> Cc: Jonas Gorski <jogo@openwrt.org> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2015-10-02gpio: add DT bindings for existing consumer flagsLinus Walleij
It is customary for GPIO controllers to support open drain/collector and open source/emitter configurations. Add standard GPIO line flags to account for this and augment the documentation to say that these are the most generic bindings. Several people approached me to add new flags to the lines, and this makes sense, but let's first bind up the most common cases before we start to add exotic stuff. Thanks to H. Nikolaus Schaller for ideas on how to encode single-ended wiring such as open drain/source and open collector/emitter. Cc: Tony Lindgren <tony@atomide.com> Cc: Grygorii Strashko <grygorii.strashko@ti.com> Cc: H. Nikolaus Schaller <hns@goldelico.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2015-09-24gpio: mention in DT binding doc that <name>-gpio is deprecatedJavier Martinez Canillas
The gpiolib supports parsing DT properties of the form <name>-gpio but it was only added for compatibility with older DT bindings that got it wrong and should not be used in newer bindings. The commit that added support for this was: dd34c37aa3e8 ("gpio: of: Allow -gpio suffix for property names") but didn't update the documentation to explain this so it's been a source of confusion. So let's make this clear in the GPIO DT binding doc. Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com> Signed-off-by: Rob Herring <robh@kernel.org>
2015-03-04gpio: Document GPIO hogging mechanismBenoit Parrot
Add GPIO hogging documentation to gpio.txt Signed-off-by: Benoit Parrot <bparrot@ti.com> Reviewed-by: Alexandre Courbot <acourbot@nvidia.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2015-01-19Documentation: gpio: fix bindings documentMasahiro Yamada
Signed-off-by: Masahiro Yamada <yamada.m@jp.panasonic.com> Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2014-10-30Documentation: gpio: guidelines for bindingsAlexandre Courbot
Now that ACPI supports named GPIO properties, either through ACPI 5.1 or the per-driver ACPI GPIO mappings, we can be more narrow about the way GPIOs should be specified in Device Tree bindings. This patch updates the GPIO DT bindings documentation to highlight the following rules for new GPIO bindings: - All new bindings must have a meaningful name (e.g. the "gpios" property must not be used) - The only suffix allowed is "-gpios", no matter the number of descriptors in the property - GPIOs can only be grouped under the same property when they serve the same purpose, a case that should remain exceptional (e.g. bit-banged data lines). Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Cc: Rafael J. Wysocki <rjw@rjwysocki.net> Acked-by: Arnd Bergmann <arnd@arndb.de> Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2014-02-27gpio: document polarity flag best practicesStephen Warren
Document what we (Laurent and I, following a mailing list dicussion) believe are best practices for the polarity flag in a GPIO specifier. While touching the doc, I made a few minor editing changes to other areas. Suggested-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Stephen Warren <swarren@nvidia.com> Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2013-10-16pinctrl/gpio: non-linear GPIO ranges accesible from gpiolibChristian Ruppert
This patch adds the infrastructure required to register non-linear gpio ranges through gpiolib and the standard GPIO device tree bindings. Signed-off-by: Christian Ruppert <christian.ruppert@abilis.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2013-08-15gpio: clean up gpio-ranges documentationStephen Warren
This change makes documentation of the the gpio-ranges property shorter and more succinct, more consistent with the style of the rest of the document, and not mention Linux-specifics such as the API pinctrl_request_gpio(); DT binding documents should be OS independant where at all possible. As part of this, the gpio-ranges property's format is described in BNF form, in order to match the rest of the document. This change also deprecates the #gpio-range-cells property. Such properties are useful when one node references a second node, and that second node dictates the format of the reference. However, that is not the case here; the definition of gpio-ranges itself always dictates its format entirely, and hence the value #gpio-range-cells must always be 3, and hence there is no point requiring any referenced node to include this property. The only remaining need for this property is to ensure compatibility of DTs with older SW that was written to support the previous version of the binding. v4: * Mention #gpio-range-cells as being deprecated, rather than removing all documentation of that property. This allows DTs to be written in a backwards-compatible way if desired, and also allows older DTs to be interpreted fully using the latest documentation. v3: * Mention BNF in commit description. * Fixed typo. * Dropped patch that removed the deprecated property from *.dts, since it's required to boot older kernels. Signed-off-by: Stephen Warren <swarren@nvidia.com> Acked-by: Mark Rutland <mark.rutland@arm.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2013-03-07gpio: add gpio offset in gpio range cells propertyHaojian Zhuang
Add gpio offset into "gpio-range-cells" property. It's used to support sparse pinctrl range in gpio chip. Signed-off-by: Haojian Zhuang <haojian.zhuang@linaro.org> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2012-11-11gpiolib: provide provision to register pin rangesShiraz Hashim
pinctrl subsystem needs gpio chip base to prepare set of gpio pin ranges, which a given pinctrl driver can handle. This is important to handle pinctrl gpio request calls in order to program a given pin properly for gpio operation. As gpio base is allocated dynamically during gpiochip registration, presently there exists no clean way to pass this information to the pinctrl subsystem. After few discussions from [1], it was concluded that may be gpio controller reporting the pin range it supports, is a better way than pinctrl subsystem directly registering it. [1] http://comments.gmane.org/gmane.linux.ports.arm.kernel/184816 Cc: Grant Likely <grant.likely@secretlab.ca> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Shiraz Hashim <shiraz.hashim@st.com> [Edited documentation a bit] Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2011-06-28gpio/dt: Refine GPIO device tree bindingGrant Likely
Allow for multiple named gpio properties Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
2011-01-31dt: Move device tree documentation out of powerpc directoryGrant Likely
The device tree is used by more than just PowerPC. Make the documentation directory available to all. v2: reorganized files while moving to create arch and driver specific directories. Signed-off-by: Grant Likely <grant.likely@secretlab.ca> Acked-by: Josh Boyer <jwboyer@linux.vnet.ibm.com>