[PATCH V2 RESEND 2/5] gpiolib: provide provision for gpiolib to register pin range
linus.walleij at linaro.org
Tue Nov 6 03:03:44 EST 2012
On Sat, Oct 27, 2012 at 11:51 AM, Viresh Kumar <viresh.kumar at linaro.org> wrote:
> From: Shiraz Hashim <shiraz.hashim at st.com>
> 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 , it was concluded that may be gpio controller
> reporting the pin range it supports, is a better way than pinctrl subsystem
> directly registering it.
>  http://comments.gmane.org/gmane.linux.ports.arm.kernel/184816
> Cc: Grant Likely <grant.likely at secretlab.ca>
> Signed-off-by: Viresh Kumar <viresh.kumar at linaro.org>
> Signed-off-by: Shiraz Hashim <shiraz.hashim at st.com>
Hey thanks for working out the details of this!!
Patch applied, but I was a bit picky about the English in the
documentation so I patched it around a little, hope you don't
mind (diff below).
I will now try to make the U300 use this new range concep
as guinea pig, and that platform is *not* using DT so we'll
see for sure if it works :-)
-gpio-controller and pinctrl subsystem
+GPIO controllers and the pinctrl subsystem
-gpio-controller on a SOC might be tightly coupled with the pinctrl
+A GPIO controller on a SOC might be tightly coupled with the pinctrl
subsystem, in the sense that the pins can be used by other functions
-together with optional gpio feature.
+together with an optional gpio feature. We have already covered the
+case where e.g. a GPIO controller need to reserve a pin or set the
+direction of a pin by calling any of:
-While the pin allocation is totally managed by the pin ctrl subsystem,
+But how does the pin control subsystem cross-correlate the GPIO
+numbers (which are a global business) to a certain pin on a certain
+This is done by registering "ranges" of pins, which are essentially
+cross-reference tables. These are described in
+While the pin allocation is totally managed by the pinctrl subsystem,
gpio (under gpiolib) is still maintained by gpio drivers. It may happen
that different pin ranges in a SoC is managed by different gpio drivers.
This makes it logical to let gpio drivers announce their pin ranges to
-the pin ctrl subsystem and call 'pinctrl_request_gpio' in order to
-request the corresponding pin before any gpio usage.
+the pin ctrl subsystem before it will call 'pinctrl_request_gpio' in order
+to request the corresponding pin to be prepared by the pinctrl subsystem
+before any gpio usage.
-For this, the gpio controller can register its pin range with pinctrl subsystem
-There are two ways of doing it currently with or without DT.
+For this, the gpio controller can register its pin range with pinctrl
+subsystem. There are two ways of doing it currently: with or without DT.
For with DT support refer to Documentation/devicetree/bindings/gpio/gpio.txt.
For non-DT support, user can call gpiochip_add_pin_range() with appropriate
parameters to register a range of gpio pins with a pinctrl driver. For this
-exact name string of pinctrl device has to be passed as one of the argument to
+exact name string of pinctrl device has to be passed as one of the
+argument to this routine.
What do these conventions omit?
More information about the linux-arm-kernel