Hi Linus,
On 03/05/13 14:03, Linus Walleij wrote:
> 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.
Okay, so how would you recommend handling the case of a pin in a muxing
pingroup that shouldn't be put into peripheral mode?
E.g. imagine an 18bit display is wired to the (24bit) tft pins (which
are muxed as a group to "tft" function), and the least significant tft
pins are used as GPIOs to control something like board power supplies.
Without using pinconf I think the muxing pingroups would have to overlap
like below (is that acceptable?):
pingroup "tft_pins"
pins: "red0"..."red7"
functions: "tft", "lcd"
pingroup "red0"
pins: "red0"
functions: "peripheral" (OR "none")
...
pingroup "red7"
pins: "red7"
functions: "peripheral" (OR "none")
and then do something like this?
map {
tft_mux {
pins = "tft_pins";
function = "tft";
/* mux tft pins to tft panel interface */
};
tft_pins {
pins = "red7", "red6", "red5", "red4", "red2";
function = "peripheral";
/* mux pins to peripherals */
};
};
or maybe this:
map {
tft_mux {
pins = "tft_pins";
function = "tft";
/* auto sets individual pins to peripheral */
};
tft_pins {
pins = "red1", "red0";
function = "none";
/* set individual pins to !peripheral */
};
};
Cheers
James
--
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
