[lkml]   [2011]   [Nov]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: pinctrl discussions @ Linaro Connect, and also requesting GPIOs
On 12 November 2011 19:47, Linus Walleij <> wrote:
> On Sat, Nov 12, 2011 at 12:22 PM, Thomas Abraham
> <> wrote:
>> Samsung SoC's use two pin functions out of 4/8/16 pin functions to
>> represent that a pin is used as a gpio. For instance, function 0 means
>> pin is used as a gpio input, and function 1 means pin is used as gpio
>> output. A pin cannot support both input and output mode at the same
>> time.
>> The existing pinmux_[request|free]_gpio() functions can specify that a
>> pin has to be set in gpio function mode, but lack the provision to
>> select input or output mode for the gpio.
> OK then this needs fixing if this API is to persist.
>> The alternative approach of
>> using pin functions to select gpio-input or gpio-output will be used
>> for samsung pinmux drivers.
>> This means the gpio_direction_[input|output] api's would remain unused
>> on samsung platforms. And existing platforms already using this api
>> will have to be modified to use the pinmux api to select the direction
>> of the gpio pin. And the role of gpio_request will seem redundant when
>> used along with pinmux_get().
> This does not seem right. Why should it not use
> gpio_direction_[input|output] to select whether the pin is used
> for input or output like everyone else?

The gpio_direction_[input|output]() internally sets the pin function
(by writing to pin function register) to either gpio input|output.
Since the gpio calls should stop writing to the pin function registers
(since we have pinmux driver now), there should be way for
gpio_direction_[input|output]() to inform pinmux driver to set gpio in
input|output mode.

But this cannot be achieved with existing pinctrl/pinmux api and so
gpio_direction_[input|output]() will not be used and separate pin
function for gpio input/output setup and used in the pinmux driver.

> This will just lead to trouble with shared HW blocks where
> one use gpio_direction_[input|output] to select the direction
> while another one will use some pinctrl API.

Yes, that is true. So gpio_direction_[input|output]() would not be
used to setup the gpio direction anymore.

> We need one of two things:
> 1. pinmux_[request|free]_gpio() to pass direction to the
>  core and driver, or

This approach seems to be better.

> 2. A use pattern like this:
>  pmx = pinmux_get(dev, "gpio-1-in");
>  /* Use as input */
>  pinmux_put(pmx);
>  pmx = pinmux_get(dev, "gpio-1-out");
>  /* Use as output */
>  etc
> The latter seems hopeless to maintain. So the external call
> pinmux_[request|free]_gpio() needs to be kept around,
> and it needs to be called *internally* by GPIO drivers to set
> up pins, so as to avoid hazzle.
> In my opinion atleast...

Yes. I agree with that.

> Linus Walleij

Thank you LinusW.

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2011-11-12 15:45    [W:0.043 / U:2.236 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site