From: James Hogan <james.hogan@imgtec.com>
To: Linus Walleij <linus.walleij@linaro.org>
Cc: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"Grant Likely" <grant.likely@secretlab.ca>,
Rob Herring <rob.herring@calxeda.com>,
"devicetree-discuss@lists.ozlabs.org"
<devicetree-discuss@lists.ozlabs.org>,
Rob Landley <rob@landley.net>,
"linux-doc@vger.kernel.org" <linux-doc@vger.kernel.org>
Subject: Re: [PATCH 5/8] pinctrl-tz1090: add TZ1090 pinctrl driver
Date: Fri, 3 May 2013 16:06:10 +0100 [thread overview]
Message-ID: <5183D262.7000107@imgtec.com> (raw)
In-Reply-To: <CACRpkdYYhsY-2vQnxpM-rB9_6yXiY4XBNhb4eyNvK=eD=dxK5w@mail.gmail.com>
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
next prev parent reply other threads:[~2013-05-03 15:06 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-04-23 14:33 [PATCH 0/8] Add some TZ1090 SoC infrastructure James Hogan
2013-04-23 14:33 ` [PATCH 1/8] metag: of_platform_populate from arch generic code James Hogan
2013-04-23 14:33 ` [PATCH 2/8] metag: minimal TZ1090 (Comet) SoC infrastructure James Hogan
2013-04-23 15:25 ` Arnd Bergmann
2013-04-23 16:06 ` James Hogan
2013-04-24 13:26 ` Catalin Marinas
2013-04-24 14:51 ` James Hogan
2013-04-25 15:21 ` James Hogan
2013-04-23 14:33 ` [PATCH 3/8] irq-imgpdc: add ImgTec PDC irqchip driver James Hogan
2013-04-23 15:09 ` Thomas Gleixner
2013-04-24 9:14 ` James Hogan
2013-04-24 9:32 ` Thomas Gleixner
2013-04-25 11:25 ` James Hogan
2013-04-23 14:33 ` [PATCH 4/8] metag: tz1090: add <asm/soc-tz1090/gpio.h> James Hogan
2013-04-25 21:52 ` Linus Walleij
2013-04-23 14:33 ` [PATCH 5/8] pinctrl-tz1090: add TZ1090 pinctrl driver James Hogan
2013-04-25 22:39 ` Linus Walleij
2013-04-26 11:54 ` James Hogan
2013-05-03 9:13 ` Linus Walleij
2013-05-03 12:23 ` James Hogan
2013-05-03 13:03 ` Linus Walleij
2013-05-03 15:06 ` James Hogan [this message]
2013-05-14 11:52 ` Linus Walleij
2013-05-14 12:22 ` James Hogan
2013-05-15 19:07 ` Linus Walleij
2013-05-16 9:12 ` James Hogan
2013-05-17 6:47 ` Linus Walleij
2013-04-23 14:33 ` [PATCH 6/8] gpio-tz1090: add TZ1090 gpio driver James Hogan
2013-04-25 23:01 ` Linus Walleij
2013-04-26 9:22 ` James Hogan
2013-05-03 8:49 ` Linus Walleij
2013-05-03 9:09 ` James Hogan
2013-05-15 19:09 ` Linus Walleij
2013-04-23 14:33 ` [PATCH 7/8] pinctrl-tz1090-pdc: add TZ1090 PDC pinctrl driver James Hogan
2013-04-23 14:33 ` [PATCH 8/8] gpio-tz1090pdc: add TZ1090 PDC gpio driver James Hogan
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5183D262.7000107@imgtec.com \
--to=james.hogan@imgtec.com \
--cc=devicetree-discuss@lists.ozlabs.org \
--cc=grant.likely@secretlab.ca \
--cc=linus.walleij@linaro.org \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=rob.herring@calxeda.com \
--cc=rob@landley.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox