From: Dong Aisheng <dongas86@gmail.com>
To: Shawn Guo <shawn.guo@freescale.com>
Cc: Dong Aisheng-B29396 <B29396@freescale.com>,
Stephen Warren <swarren@nvidia.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"linus.walleij@stericsson.com" <linus.walleij@stericsson.com>,
"s.hauer@pengutronix.de" <s.hauer@pengutronix.de>,
"rob.herring@calxeda.com" <rob.herring@calxeda.com>,
"kernel@pengutronix.de" <kernel@pengutronix.de>,
"cjb@laptop.org" <cjb@laptop.org>,
"devicetree-discuss@lists.ozlabs.org"
<devicetree-discuss@lists.ozlabs.org>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>
Subject: Re: [RFC PATCH v3 2/5] pinctrl: add dt binding support for pinmux mappings
Date: Thu, 5 Jan 2012 21:14:13 +0800 [thread overview]
Message-ID: <CAA+hA=Tx0==PLFSN-vqOkRKmKZ-5FvzTNZqRwCLov+FcQxiNNQ@mail.gmail.com> (raw)
In-Reply-To: <20111229024647.GA11309@S2100-06.ap.freescale.net>
On Thu, Dec 29, 2011 at 10:46 AM, Shawn Guo <shawn.guo@freescale.com> wrote:
> On Tue, Dec 27, 2011 at 02:41:25PM +0000, Dong Aisheng-B29396 wrote:
> [...]
>> > You could have nested sub-nodes, say something like:
>> >
>> > iomuxc@020e0000 {
>> > compatible = "fsl,imx6q-iomuxc";
>> > reg = <0x020e0000 0x4000>;
>> > fsl,pins {
>> > ... // fsl-specific pin properties
>> > };
>> > fsl,groups {
>> > ... // fsl-specific group properties
>> > };
>> > fsl,functions {
>> > ... // fsl-specific mux function properties
>> > };
>> > pinmux-usage {
>> > // standardized pinmux "table" properties
>> > sd4 { // pin group name
>> > function = "sdio4"; // this function active on it
>> > ...
>> > };
>> > ...
>> > }
>> > ...
>> > }
>> >
>> Yes, I could do that.
>> The extra effort is that we have to manually exclude one pinmux-usage
>> node in pinmux driver since originally i take the child node count of
>> iomuxc as the function count since all child nodes are functions,
>> that why I firstly took the mapping node out of iomuxc, in addition
>> the old way i used seems to be more brief and clear.
>>
> Stephen suggested you put all the function nodes under node
> 'fsl,functions' (not sure prefix fsl is necessary). In that case,
> of_get_child_count() on 'fsl,functions' still get you the function
> count you want, right?
>
> But we do not bother with it, if we do not have pinmux-usage at all.
> See below ...
>
>> I tried adding pinmux-usage as a sub node of iomuxc and got two issues:
>> Taking imx6q as an example:
>> iomuxc@020e0000 {
>> uart4 {
>> func-name = "uart4";
>> grp-name = "uart4grp";
>> grp-pins = <107 108>;
>> num-pins = <2>;
>> grp-mux = <4 4>;
>> num-mux = <2>;
>> };
>>
>> sd4 {
>> func-name = "sd4";
>> grp-name = "sd4grp";
>> grp-pins = <170 171 180 181 182 183 184 185 186 187>;
>> num-pins = <10>;
>> grp-mux = <0 0 1 1 1 1 1 1 1 1>;
>> num-mux = <10>;
>> };
>>
>> pinmux-mapping {
>> uart4 {
>> function = "uart4";
>> dev = <&uart4>;
>> };
>>
>> usdhc4 {
>> /* ctrl-dev-name = "20e0000.iomuxc"; */
>> function = "sd4";
>> dev = <&usdhc4>;
>> };
>> };
>> };
>>
>> If we remove ctrl-dev-name and get it from its parent node in drivers as
>> you suggested,
>> first, since this work will be done in the common API (pinmux_of_register_mappings
>> Requires pass the pinmux mapping node to it for construct the mapping table)
>> It will introduce a restriction that all platforms should define this node
>> under their pinctrl device node.
>> Second, it seems we cannot get its parent node device or device name in driver
>> (can only get node Name which is not sufficient for construct the pin map table
>> required by pinctrl core) and current device tree subsystem seems do not support
>> get its associated device from a device node.
>> We may not be able to construct ctrl-dev-name or ctrl-dev for struct pinmux_map.
>> I'm not sure if I missed something, if missed please let me know.
>> To support it, we may need to add support for converting device node
>> to device. Not sure it's applicable since I still have not tried it.
>>
>> The same issue applies to dev using a phandle.
>>
> We do not bother with it, if we do not have pinmux-usage at all.
> See below ...
>
> [...]
>
>> I was ever thought putting a phandle of pinmux function in each device,
>> Then pinmux mapping table seems not need anymore. Like:
>>
>> usdhc4: usdhc@0219c000 { /* uSDHC4 */
>> compatible = "fsl,imx6q-usdhc";
>> ....
>> pinmux = <&pinmux-sd4>;
>> };
>>
>> iomuxc@020e0000 {
>> pinmux-sd4 : sd4 {
>> func-name = "sd4";
>> grp-name = "sd4grp";
>> grp-pins = <170 171 180 181 182 183 184 185 186 187>;
>> num-pins = <10>;
>> grp-mux = <0 0 1 1 1 1 1 1 1 1>;
>> num-mux = <10>;
>> };
>>
>> It is a pure hw point of view to define node.
>
> That's the way we should go for. This is exactly the same thing that
> clk and regulator DT support is doing. And right, in that way, we do
> not need pinmux mapping for DT at all.
>
I tried this way and basically it works but has a few limitations due to
via dt.
I will send out patch in this thread for discussion.
>> And it may need to implement a of_pinmux_get.
>
> To make the pinmux api generic for both dt and non-dt users, the pinmux
> client driver should still see/call pinmux_get, something like
> of_pinmux_get should be sorted out behind pinmux_get.
>
>> But what about the pin maps without device associated?
>>
> Do we have such cases?
>
It's hog_on_boot function.
Regards
Dong Aisheng
next prev parent reply other threads:[~2012-01-05 13:14 UTC|newest]
Thread overview: 98+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-12-20 17:40 [RFC PATCH v3 0/5] pinctrl: imx: add pinnmux support Dong Aisheng
2011-12-20 17:40 ` [RFC PATCH v3 1/5] dt: add of_get_child_count helper function Dong Aisheng
2011-12-20 18:35 ` Rob Herring
2011-12-21 2:56 ` Dong Aisheng-B29396
2012-01-01 13:58 ` Linus Walleij
2011-12-20 19:47 ` Marek Vasut
2011-12-21 3:27 ` Dong Aisheng-B29396
2011-12-21 6:05 ` Lothar Waßmann
2011-12-20 23:58 ` Stephen Warren
2011-12-21 3:18 ` Dong Aisheng-B29396
2011-12-20 17:40 ` [RFC PATCH v3 2/5] pinctrl: add dt binding support for pinmux mappings Dong Aisheng
2011-12-20 19:48 ` Marek Vasut
2011-12-21 0:39 ` Stephen Warren
2011-12-22 8:18 ` Dong Aisheng-B29396
2011-12-25 3:37 ` Stephen Warren
2011-12-27 14:41 ` Dong Aisheng-B29396
2011-12-29 2:46 ` Shawn Guo
2012-01-05 13:14 ` Dong Aisheng [this message]
2012-01-05 23:45 ` Stephen Warren
2012-01-06 6:21 ` Shawn Guo
2012-01-05 23:38 ` Stephen Warren
2012-01-06 10:51 ` Dong Aisheng-B29396
2012-01-06 17:23 ` Stephen Warren
2012-01-10 7:02 ` Dong Aisheng-B29396
2012-01-05 13:47 ` Dong Aisheng
2012-01-06 1:05 ` Stephen Warren
2012-01-06 5:27 ` Shawn Guo
2012-01-06 11:33 ` Dong Aisheng-B29396
2012-01-06 13:14 ` Shawn Guo
2012-01-06 18:03 ` Stephen Warren
2012-01-07 13:54 ` Shawn Guo
2012-01-08 12:51 ` Richard Zhao
2012-01-09 1:56 ` Shawn Guo
2012-01-09 6:18 ` Simon Glass
2012-01-10 11:30 ` Dong Aisheng-B29396
2012-01-11 19:19 ` Stephen Warren
2012-01-11 18:37 ` Stephen Warren
2012-01-11 23:56 ` Shawn Guo
2012-01-11 23:59 ` Stephen Warren
2012-01-12 4:03 ` Shawn Guo
2012-01-12 7:45 ` Dong Aisheng-B29396
2012-01-11 18:28 ` Stephen Warren
2012-01-11 18:17 ` Stephen Warren
2012-01-12 3:39 ` Shawn Guo
2012-01-12 7:40 ` Dong Aisheng-B29396
2012-01-12 20:46 ` Stephen Warren
2012-01-12 21:10 ` Stephen Warren
2012-01-13 3:46 ` Shawn Guo
2012-01-13 18:16 ` Stephen Warren
2012-01-14 1:22 ` Shawn Guo
2012-01-14 18:21 ` Dong Aisheng
2012-01-16 16:08 ` Linus Walleij
2012-01-17 2:32 ` Shawn Guo
2012-01-17 19:50 ` Stephen Warren
2012-01-18 2:30 ` Shawn Guo
2012-01-19 16:55 ` Linus Walleij
2012-01-19 19:30 ` Stephen Warren
2012-01-20 17:51 ` Linus Walleij
2012-01-10 8:21 ` Dong Aisheng-B29396
2012-01-10 13:05 ` Shawn Guo
2012-01-11 19:41 ` Stephen Warren
2012-01-11 23:01 ` Shawn Guo
2012-01-11 22:58 ` Stephen Warren
2012-01-11 20:17 ` Stephen Warren
2012-01-11 23:21 ` Shawn Guo
2012-01-12 8:36 ` Dong Aisheng-B29396
2012-01-12 20:56 ` Stephen Warren
2012-01-13 3:55 ` Shawn Guo
2012-01-13 8:07 ` Dong Aisheng-B29396
2012-01-13 13:35 ` Shawn Guo
2012-01-13 13:48 ` Linus Walleij
2012-01-13 14:23 ` Shawn Guo
2012-01-13 17:11 ` Dong Aisheng
2012-01-13 18:33 ` Stephen Warren
2012-01-14 1:10 ` Shawn Guo
2012-01-17 19:35 ` Stephen Warren
2012-01-17 19:48 ` Rob Herring
2012-01-14 17:58 ` Dong Aisheng
2012-01-17 19:44 ` Stephen Warren
2012-01-01 14:07 ` Linus Walleij
2012-01-01 15:22 ` Rob Herring
2012-01-05 13:59 ` Dong Aisheng
2011-12-20 17:40 ` [RFC PATCH v3 3/5] pinctrl: imx: add pinctrl imx driver Dong Aisheng
2011-12-20 19:50 ` Marek Vasut
2011-12-21 3:09 ` Dong Aisheng-B29396
2012-01-01 14:02 ` Linus Walleij
2012-01-08 13:05 ` Richard Zhao
2012-01-09 2:08 ` Shawn Guo
2012-01-09 2:17 ` Richard Zhao
2012-01-09 6:32 ` Shawn Guo
2012-01-10 8:38 ` Richard Zhao
2012-01-10 10:43 ` Linus Walleij
2012-01-10 10:55 ` Dong Aisheng-B29396
2012-01-10 13:51 ` Shawn Guo
2012-01-11 9:28 ` Linus Walleij
2011-12-20 17:40 ` [RFC PATCH v3 4/5] ARM: imx6q: using pinmux subsystem Dong Aisheng
2011-12-20 17:40 ` [RFC PATCH v3 5/5] mmc: sdhci-esdhc-imx: " Dong Aisheng
2012-01-01 13:54 ` Linus Walleij
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='CAA+hA=Tx0==PLFSN-vqOkRKmKZ-5FvzTNZqRwCLov+FcQxiNNQ@mail.gmail.com' \
--to=dongas86@gmail.com \
--cc=B29396@freescale.com \
--cc=cjb@laptop.org \
--cc=devicetree-discuss@lists.ozlabs.org \
--cc=kernel@pengutronix.de \
--cc=linus.walleij@stericsson.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=rob.herring@calxeda.com \
--cc=s.hauer@pengutronix.de \
--cc=shawn.guo@freescale.com \
--cc=swarren@nvidia.com \
/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;
as well as URLs for NNTP newsgroup(s).