"gpioN" named functions for GPIO pins

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hello Linus,


according to your Documentation/pinctrl.txt:

"Pin control interaction with the GPIO subsystem
===============================================
...
For this reason there are two functions a pin control driver can implement
to enable only GPIO on an individual pin: .gpio_request_enable() and
.gpio_disable_free().
...
Alternatively to using these special functions, it is fully allowed to use
named functions for each GPIO pin, the pinctrl_request_gpio() will attempt to
obtain the function "gpioN" where "N" is the global GPIO pin number if no
special GPIO-handler is registered."

As far as I understand the second paragraph, it should suffice to
define functions named "gpio0", "gpio1", etc. instead of adding a
gpio_request_enable().

But I fail to see in pinctrl_request_gpio() where this happens:

pinctrl_request_gpio() calls pinmux_request_gpio(), which calls
pin_request(); pin_request() then calls ops->gpio_request_enable() if
present and a gpiorange is given, or ops->request() if present.
Nowhere I can see that any "gpio%d" function is even looked for, at
least that was the heuristic I used to find that place where
pinctrl_request_gpio was supposed to obtain the function "gpioN".

Am I just overlooking something, or is this actually not implemented?


Regards
Jonas
--
To unsubscribe from this list: send the line "unsubscribe linux-gpio" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [Linux SPI]     [Linux Kernel]     [Linux ARM (vger)]     [Linux ARM MSM]     [Linux Omap]     [Linux Arm]     [Linux Tegra]     [Fedora ARM]     [Linux for Samsung SOC]     [eCos]     [Linux Fastboot]     [Gcc Help]     [Git]     [DCCP]     [IETF Announce]     [Security]     [Linux MIPS]     [Yosemite Campsites]

  Powered by Linux