On Sat, Nov 12, 2011 at 12:22 PM, Thomas Abraham <thomas.abraham@xxxxxxxxxx> 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? 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. We need one of two things: 1. pinmux_[request|free]_gpio() to pass direction to the core and driver, or 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... Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
 |