lkml.org 
[lkml]   [2013]   [May]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH 5/8] pinctrl-tz1090: add TZ1090 pinctrl driver
Hi Linus,

On 03/05/13 14:03, Linus Walleij wrote:
> On Fri, May 3, 2013 at 2:23 PM, James Hogan <james.hogan@imgtec.com> 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



\
 
 \ /
  Last update: 2013-05-03 17:41    [W:2.047 / U:0.684 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site