From: tony@atomide.com (Tony Lindgren)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] [RFC] pinctrl: add a driver for Energy Micro's efm32 SoCs
Date: Sun, 11 Dec 2011 11:34:01 -0800 [thread overview]
Message-ID: <20111211193400.GD31337@atomide.com> (raw)
In-Reply-To: <74CDBE0F657A3D45AFBB94109FB122FF175186060C@HQMAIL01.nvidia.com>
* Stephen Warren <swarren@nvidia.com> [111209 15:42]:
> Tony Lindgren wrote at Friday, December 09, 2011 10:53 AM:
> > * Tony Lindgren <tony@atomide.com> [111209 08:53]:
> ...
> > > For letting a device do it's pingroup in DT, I've played with the
> > > following:
> > >
> > > /* mux func phandle mux func name hw initial flags */
> > > pins = <&uart3_rx_irrx>, "uart3_rx_irrx", <0xdeadbeef>,
> > > <&uart3_tx_irtx>, "uart3_tx_irtx", <0xdeadbeef>;
> > >
> > > But it seems that doing mixed-property arrays gets nasty as any
> ...
> > > So I've pretty much come to the conclusion that we would have to
> > > use something like this instead:
> > >
> > > /* phandle f hw specific initial flags */
> > > pins = <&uart3_rx_irrx 0 0xdeadbeef
> > > &uart3_tx_irtx 0 0xdeadbeef>;
> > >
> > > This however has a problem for cases where we may not have a phandle
> > > in DT for the mux function. For example, let's assume that we'll have
> > > tens of thousands of lines of mux data for omaps (we already have
> > > over 6k LOC) and just want to load that from /lib/firmware to avoid
> > > bloating the kernel. In that case we won't have the phandle for the
> > > mux function in DT.
> ...
> > Oh forgot to mention of course what Benoit came up which is reg-names.
> > That of course is doable with both phandles and pin names:
> >
> > So optionally either
> >
> > pins = <&uart3_rx_irrx &uart3_tx_irtx>;
> > or
> >
> > pin-names = "uart3_rx_irrx", "uart3_tx_irtx";
>
> Tony,
>
> It sounds like you've already started working on some DT bindings for
> pin muxing. Are you just at the thinking stage as above, or do you have
> any concrete code? I'd obviously be interested in looking at any early
> bindings to see if I can port the Tegra pinctrl driver to use them.
Yeah I have some code but it still needs a bit more work.. The DT bindings
part I have only briefly played with so far. Mostly to verify that trying
to use the mixed-property arrays will get messy.
For parsing the pins as phandles, drivers/of/gpio.c is a nice example.
After still thinking more about it, I think the cleanest and most flexible
option is using both the pins phandle array or pin-names string array,
combined with a separate pin-flags initial value array. That way we can
use the DT generated maps also for non-dt pinmux drivers where we don't
have phandles around.
Regards,
Tony
WARNING: multiple messages have this Message-ID (diff)
From: Tony Lindgren <tony@atomide.com>
To: Stephen Warren <swarren@nvidia.com>
Cc: "Dong Aisheng" <dongas86@gmail.com>,
"Shawn Guo" <shawn.guo@freescale.com>,
"Uwe Kleine-König" <u.kleine-koenig@pengutronix.de>,
"Linus Walleij" <linus.walleij@linaro.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>,
"kernel@pengutronix.de" <kernel@pengutronix.de>
Subject: Re: [PATCH] [RFC] pinctrl: add a driver for Energy Micro's efm32 SoCs
Date: Sun, 11 Dec 2011 11:34:01 -0800 [thread overview]
Message-ID: <20111211193400.GD31337@atomide.com> (raw)
In-Reply-To: <74CDBE0F657A3D45AFBB94109FB122FF175186060C@HQMAIL01.nvidia.com>
* Stephen Warren <swarren@nvidia.com> [111209 15:42]:
> Tony Lindgren wrote at Friday, December 09, 2011 10:53 AM:
> > * Tony Lindgren <tony@atomide.com> [111209 08:53]:
> ...
> > > For letting a device do it's pingroup in DT, I've played with the
> > > following:
> > >
> > > /* mux func phandle mux func name hw initial flags */
> > > pins = <&uart3_rx_irrx>, "uart3_rx_irrx", <0xdeadbeef>,
> > > <&uart3_tx_irtx>, "uart3_tx_irtx", <0xdeadbeef>;
> > >
> > > But it seems that doing mixed-property arrays gets nasty as any
> ...
> > > So I've pretty much come to the conclusion that we would have to
> > > use something like this instead:
> > >
> > > /* phandle f hw specific initial flags */
> > > pins = <&uart3_rx_irrx 0 0xdeadbeef
> > > &uart3_tx_irtx 0 0xdeadbeef>;
> > >
> > > This however has a problem for cases where we may not have a phandle
> > > in DT for the mux function. For example, let's assume that we'll have
> > > tens of thousands of lines of mux data for omaps (we already have
> > > over 6k LOC) and just want to load that from /lib/firmware to avoid
> > > bloating the kernel. In that case we won't have the phandle for the
> > > mux function in DT.
> ...
> > Oh forgot to mention of course what Benoit came up which is reg-names.
> > That of course is doable with both phandles and pin names:
> >
> > So optionally either
> >
> > pins = <&uart3_rx_irrx &uart3_tx_irtx>;
> > or
> >
> > pin-names = "uart3_rx_irrx", "uart3_tx_irtx";
>
> Tony,
>
> It sounds like you've already started working on some DT bindings for
> pin muxing. Are you just at the thinking stage as above, or do you have
> any concrete code? I'd obviously be interested in looking at any early
> bindings to see if I can port the Tegra pinctrl driver to use them.
Yeah I have some code but it still needs a bit more work.. The DT bindings
part I have only briefly played with so far. Mostly to verify that trying
to use the mixed-property arrays will get messy.
For parsing the pins as phandles, drivers/of/gpio.c is a nice example.
After still thinking more about it, I think the cleanest and most flexible
option is using both the pins phandle array or pin-names string array,
combined with a separate pin-flags initial value array. That way we can
use the DT generated maps also for non-dt pinmux drivers where we don't
have phandles around.
Regards,
Tony
next prev parent reply other threads:[~2011-12-11 19:34 UTC|newest]
Thread overview: 52+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-12-08 22:40 [PATCH] [RFC] pinctrl: add a driver for Energy Micro's efm32 SoCs Uwe Kleine-König
2011-12-08 22:40 ` Uwe Kleine-König
2011-12-08 22:55 ` Arnd Bergmann
2011-12-08 22:55 ` Arnd Bergmann
2011-12-09 9:23 ` Uwe Kleine-König
2011-12-09 9:23 ` Uwe Kleine-König
2011-12-09 13:55 ` Arnd Bergmann
2011-12-09 13:55 ` Arnd Bergmann
2011-12-09 14:15 ` Uwe Kleine-König
2011-12-09 14:15 ` Uwe Kleine-König
2011-12-08 23:14 ` Stephen Warren
2011-12-08 23:14 ` Stephen Warren
2011-12-09 1:01 ` Shawn Guo
2011-12-09 1:01 ` Shawn Guo
2011-12-09 3:44 ` Stephen Warren
2011-12-09 3:44 ` Stephen Warren
2011-12-09 4:32 ` Shawn Guo
2011-12-09 4:32 ` Shawn Guo
2011-12-09 4:47 ` Stephen Warren
2011-12-09 4:47 ` Stephen Warren
2011-12-09 5:14 ` Shawn Guo
2011-12-09 5:14 ` Shawn Guo
2011-12-09 11:08 ` Sascha Hauer
2011-12-09 11:08 ` Sascha Hauer
2011-12-09 13:01 ` Uwe Kleine-König
2011-12-09 13:01 ` Uwe Kleine-König
2011-12-10 0:18 ` Linus Walleij
2011-12-10 0:18 ` Linus Walleij
2011-12-12 14:37 ` Sascha Hauer
2011-12-12 14:37 ` Sascha Hauer
2011-12-12 15:29 ` Uwe Kleine-König
2011-12-12 15:29 ` Uwe Kleine-König
2011-12-13 0:41 ` Linus Walleij
2011-12-13 0:41 ` Linus Walleij
2011-12-09 16:53 ` Stephen Warren
2011-12-09 16:53 ` Stephen Warren
2011-12-09 15:03 ` Dong Aisheng
2011-12-09 15:03 ` Dong Aisheng
2011-12-09 16:49 ` Stephen Warren
2011-12-09 16:49 ` Stephen Warren
2011-12-09 17:24 ` Tony Lindgren
2011-12-09 17:24 ` Tony Lindgren
2011-12-09 17:53 ` Tony Lindgren
2011-12-09 17:53 ` Tony Lindgren
2011-12-10 0:14 ` Stephen Warren
2011-12-10 0:14 ` Stephen Warren
2011-12-11 19:34 ` Tony Lindgren [this message]
2011-12-11 19:34 ` Tony Lindgren
2011-12-09 9:31 ` Uwe Kleine-König
2011-12-09 9:31 ` Uwe Kleine-König
2011-12-10 0:04 ` Linus Walleij
2011-12-10 0:04 ` 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=20111211193400.GD31337@atomide.com \
--to=tony@atomide.com \
--cc=linux-arm-kernel@lists.infradead.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.