On Fri, May 3, 2013 at 2:23 PM, James Hogan <james.hogan@xxxxxxxxxx> wrote: > [Me] >> If what you need is to set the pin into "GPIO mode" to drive it >> to some default state then from pinconf-generic.h you should use >> one of the existing defines like PIN_CONFIG_OUTPUT >> to actively drive it to high or low as default, or >> PIN_CONFIG_BIAS_HIGH_IMPEDANCE for some default >> GPIO input mode. >> >> Read the new section named "GPIO mode pitfalls" in >> Documentation/pinctrl.txt > > Thanks, that was interesting. I've had a think about this (and done some > experiments with a multimeter), and the problem is these generic > pinconfs already have meanings which don't match what the SELECT > register does. For example, having a pin be tristate and not controlled > by the peripheral, and having it tristate as far as the gpio hardware is > concerned (e.g. no pull-up) but still controlled by the peripheral, are > two very different things that need disambiguation. I don't know if that is necessary. While I do recognize that it is possible that we need to put pins into "GPIO mode", i.e. drive them actively low or high, as PIN_CONFIG_OUTPUT does, I'm not convinced that pin config should handle the case where a signal is passed through from a peripheral. I think that for every pin that is put to use for a peripheral you must anyway at some point call .enable() on the struct pinmux_ops of the pin controller. Thus this part of the problem (poking that "select" bit) should be handled by the pinmux part of the driver. The pinconf part does not need to know about it. The idea is definately not for the pin config to act as a "backend" for pin muxing, rather to partition the problem into two independent parts. Yours, Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
