On 11 November 2011 19:39, Linus Walleij <linus.walleij@xxxxxxxxxx> wrote: > On Thu, Nov 10, 2011 at 5:33 PM, Stephen Warren <swarren@xxxxxxxxxx> wrote: >> Linus Walleij wrote at Thursday, November 10, 2011 1:40 AM: >>> Stephen Warren <swarren@xxxxxxxxxx> wrote: >>> > Many drivers currently call gpio_request(). This is defined /not/ to >>> > perform any pinmux manipulation. >>> >>> Is it? >>> >>> I always though that the GPIO driver could call out to the pinctrl >>> counterpart. >> >> I'd originally thought that too, but when I tried to "fix" gpio_request() >> on Tegra to perform any necessary pinmux actions, it was pointed out that >> Documentation/gpio.txt says: >> >> " Note that requesting a GPIO does NOT cause it to be configured in any >> " way; it just marks that GPIO as in use. Separate code must handle any >> " pin setup (e.g. controlling which pin the GPIO uses, pullup/pulldown). >> ^^^^^^^^^^^^^^^^^^^^^^^ > > Hm, yeah I see. :-/ You're right of course. > > And it is perfectly possible to say, drive a GPIO pin even though it is > not connected anywhere at all, even though it seem strange, > there may be cases where a GPIO is used internally on a chip OR > routed to an external pin, and then this is fully logic. > > And it makes the two subsystems mostly orthogonal. > >> Given that, it appears that the pinctrl/pinmux API is the way to perform >> that setup, including muxing the GPIO controller onto the pin if required. >> Given the similarity of that mux setup with more general non-GPIO mux >> setup is why I suggested including GPIO muxing in the regular mapping >> table. >> >> (as I think I mentioned) and alternative to a custom GPIO mapping table >> entry would be to remove the GPIO-specific APIs from pinctrl, and have >> all pinctrl drivers only expose GPIO as an additional function available >> on a pin (group). Systems that support N different GPIOs on a pin would >> need to expose GPIO this way anyway. > > Yes. It is already possible to use the mapping table like that if > all GPIOs are represented as indvidual functions from the > *driver* (i.e. not using the pinmux_request_gpio() function) > so currently it's a matter of choice. > > We already have a goal to do as much as possible of set-up from > platform code, including mapping table, or, even better, by direct > bindings from the device tree (whenever we get that). > > The idea with the single GPIO request functions was to make > things simpler and quicker but maybe it's just cluttering the view :-/ > > What do others think? Shall we just kill > pinmux_[request|free]_gpio() and its driver hooks? 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. 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(). Another question, not related to the above. The gpio and pinctrl drivers would operate on the same physical memory space (pinmux and gpio is just a single controller). Both gpio and pinctrl driver would do a ioremap of this physical address space. I remember reading that ioremap of the same physical memory area twice is not correct. So any suggestions on how to handle this. Thanks, Thomas. > > I guess I have to convert a driver with mixed GPIO myself > before I fully understand how to do this the right way... > > Yours, > Linus Walleij > -- > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majordomo@xxxxxxxxxxxxxxx > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ > -- 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
 |