Erik Gilling wrote: > from Documentation/gpio.txt: > > "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)." Hmm. That seems slightly unhelpful; the default case seems like you'd want everything do "just work". But anyway... > tegra_gpio_enable would normally belong in pinmuxing. However because > pinmuxing is done per pin group and GPIOs are done per pin, I can't > think of a good way to do that. Perhaps doing this inside direction_{input,output} would make sense then? Those functions are explicitly to set up a GPIO for input/output, and one could argue that enabling GPIO functionality on the pin (which is a register within the GPIO module not the pinmux module) is part of that. Thanks. > On Wed, Jan 19, 2011 at 3:28 PM, Stephen Warren <swarren@xxxxxxxxxx> wrote: > > Erik et. al., > > > > On Tegra (both in linux-tegra-2.6.37 and for-next), one needs to manually > > call tegra_gpio_enable to flip some bits within Tegra's GPIO controller to > > enable the GPIO function on a pin, vs. its "special function". > > > > Shouldn't this be automatic when gpio_request is called; i.e. shouldn't > > tegra_gpio_chip have a .request member that does what tegra_gpio_enable does > > right now? I'm not sure whether .free should undo that though. I guess so. > > > > Certainly the one other example I've looked at, sound/soc/codecs/wm8962.c, > > does a similar thing in its request method. > > -- nvpublic -- To unsubscribe from this list: send the line "unsubscribe linux-tegra" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html