summaryrefslogtreecommitdiff
path: root/drivers/gpio/gpiolib-of.c
AgeCommit message (Collapse)Author
2013-02-20Merge tag 'dt-for-linus' of git://git.secretlab.ca/git/linuxLinus Torvalds
Pull device tree changes from Grant Likely: "All around device tree changes destined for v3.8. Aside from the documentation updates the highlights in this branch include: - Kbuild changes for using CPP with .dts files - locking fix from preempt_rt patchset - include DT alias names in device uevent - Selftest bugfixes and improvements - New function for counting phandles stanzas in a property - constify argument to of_node_full_name() - Various bug fixes This tree did also contain a commit to use platform_device_add instead of open-coding the device add code, but it caused problems with amba devices and needed to be reverted." * tag 'dt-for-linus' of git://git.secretlab.ca/git/linux: (23 commits) Revert "of: use platform_device_add" kbuild: limit dtc+cpp include path gpio: Make of_count_named_gpios() use new of_count_phandle_with_args() of: Create function for counting number of phandles in a property of/base: Clean up exit paths for of_parse_phandle_with_args() of/selftest: Use selftest() macro throughout of/selftest: Fix GPIOs selftest to cover the 7th case of: fix recursive locking in of_get_next_available_child() documentation/devicetree: Fix a typo in exynos-dw-mshc.txt OF: convert devtree lock from rw_lock to raw spinlock of/exynos_g2d: Add Bindings for exynos G2D driver kbuild: create a rule to run the pre-processor on *.dts files input: Extend matrix-keypad device tree binding devicetree: Move NS2 LEDs binding into LEDs directory of: use platform_device_add powerpc/5200: Fix size to request_mem_region() call documentation/devicetree: Fix typos of: add 'const' to of_node_full_name parameter of: Output devicetree alias names in uevent DT: add vendor prefixes for Renesas and Toshiba ...
2013-02-13gpio: Make of_count_named_gpios() use new of_count_phandle_with_args()Grant Likely
This patch replaces the horribly coded of_count_named_gpios() with a call to of_count_phandle_with_args() which is far more efficient. This also changes the return value of of_gpio_count() & of_gpio_named_count() from 'unsigned int' to 'int' so that it can return an error code. All the users of that function are fixed up to correctly handle a negative return value. v2: Split GPIO portion into a separate patch Tested-by: Andreas Larsson <andreas@gaisler.com> Signed-off-by: Grant Likely <grant.likely@secretlab.ca> Cc: Linus Walleij <linus.walleij@linaro.org> Cc: Rob Herring <rob.herring@calxeda.com>
2013-01-21gpio: use pinctrl device name for add rangeHaojian Zhuang
gpiochip_add_pin_range() needs pinctrl device name as parameter. Currently the parameter is pinctrl description name. So fix it. Signed-off-by: Haojian Zhuang <haojian.zhuang@linaro.org> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2012-11-21gpiolib: let gpiochip_add_pin_range() specify offsetLinus Walleij
Like with commit 3c739ad0df5eb41cd7adad879eda6aa09879eb76 it is not always enough to specify all the pins of a gpio_chip from offset zero to be added to a pin map range, since the mapping from GPIO to pin controller may not be linear at all, but need to be broken into a few consecutive sub-ranges or 1-pin entries for complicated cases. The ranges may also be sparse. This alters the signature of the function to accept offsets into both the GPIO-chip local pinspace and the pin controller local pinspace. Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2012-11-11gpiolib: separation of pin concernsLinus Walleij
The fact that of_gpiochip_add_pin_range() and gpiochip_add_pin_range() share too much code is fragile and will invariably mean that bugs need to be fixed in two places instead of one. So separate the concerns of gpiolib.c and gpiolib-of.c and have the latter call the former as back-end. This is necessary also when going forward with other device descriptions such as ACPI. This is done by: - Adding a return code to gpiochip_add_pin_range() so we can reliably check whether this succeeds. - Get rid of the custom of_pinctrl_add_gpio_range() from pinctrl. Instead create of_pinctrl_get() to just retrive the pin controller per se from an OF node. This composite function was just begging to be deleted, it was way to purpose-specific. - Use pinctrl_dev_get_name() to get the name of the retrieved pin controller and use that to call back into the generic gpiochip_add_pin_range(). Now the pin range is only allocated and tied to a pin controller from the core implementation in gpiolib.c. Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2012-11-11gpiolib: remove duplicate pin range codeLinus Walleij
Commit 69e1601bca88809dc118abd1becb02c15a02ec71 "gpiolib: provide provision to register pin ranges" Introduced both of_gpiochip_remove_pin_range() and gpiochip_remove_pin_ranges(). But the contents are exactly the same so remove the OF one and rely on the range deletion in the core. Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2012-11-11gpiolib-of: staticize the pin range callsLinus Walleij
Commit 69e1601bca88809dc118abd1becb02c15a02ec71 "gpiolib: provide provision to register pin ranges" Declared the of_gpiochip_[add|remove]_pin_range() global while they should be static as they are only ever used in this file. Let's convert them to static. Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-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>
2012-08-17gpio: Fix debug message in of_get_named_gpio_flags()Thierry Reding
This was probably missed in the conversion done in commit 3d0f7cf ("gpio: Adjust of_xlate API to support multiple GPIO chips"). Signed-off-by: Thierry Reding <thierry.reding@avionic-design.de> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2012-07-17gpio: of_get_named_gpio_flags() return -EPROBE_DEFER if GPIO not yet availableRoland Stigge
of_get_named_gpio_flags() and of_get_named_gpio() return -EPROBE_DEFER if the respective GPIO is not (yet) available. This is useful if driver's probe() functions try to get a GPIO whose controller isn't probed yet. Thus, the driver can be probed again later on. The function still returns -EINVAL on other errors (parse error or node doesn't exist). This way, the case of an optional/intentionally missing GPIO is handled appropriately. Signed-off-by: Roland Stigge <stigge@antcom.de> Acked-by: Alexandre Pereira da Silva <aletes.xgr@gmail.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2012-07-17gpio: propagate of_parse_phandle_with_args errorsAlexandre Courbot
Make of_get_named_gpio_flags propagate any error it receives from of_parse_phandle_with_args instead of inconditionally returning -EINVAL. Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2012-05-25gpio/of: fix a typo of comment messageDong Aisheng
Signed-off-by: Dong Aisheng <dong.aisheng@linaro.org> Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
2012-05-18gpio: Adjust of_xlate API to support multiple GPIO chipsGrant Likely
This patch changes the of_xlate API to make it possible for multiple gpio_chips to refer to the same device tree node. This is useful for banked GPIO controllers that use multiple gpio_chips for a single device. With this change the core code will try calling of_xlate on each gpio_chip that references the device_node and will return the gpio number for the first one to return 'true'. Tested-by: Roland Stigge <stigge@antcom.de> Acked-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
2012-05-08Merge tag 'v3.4-rc6' into gpio/nextGrant Likely
Linux 3.4-rc6
2012-04-07gpio: Move DT support code into drivers/gpioGrant Likely
The code in drivers/of/gpio.c isn't shared by any other subsystem since it is all gpiolib specific. drivers/gpio is a better place to maintain these functions. Signed-off-by: Grant Likely <grant.likely@secretlab.ca> Cc: Rob Herring <rob.herring@calxeda.com> Cc: Linus Walleij <linus.walleij@stericsson.com>