From: tony@atomide.com (Tony Lindgren)
To: linux-arm-kernel@lists.infradead.org
Subject: Pinmux bindings proposal V2
Date: Fri, 27 Jan 2012 09:37:32 -0800 [thread overview]
Message-ID: <20120127173732.GJ13504@atomide.com> (raw)
In-Reply-To: <CAPnjgZ2EkvTMsOkWyf4pfwRpvcvYs=WaKy5Gi8fdkAUQmvt=ig@mail.gmail.com>
* Simon Glass <sjg@chromium.org> [120127 07:12]:
>
> On Thu, Jan 26, 2012 at 6:21 PM, Tony Lindgren <tony@atomide.com> wrote:
> >
> > Maybe we need two bindings: A minimal subset of what Stephen is suggesting
> > that can handle 95% of the muxes with minimal overhead, then what you're
> > suggesting for the few muxes that need multiple states?
>
> Perhaps that would work, it certainly deals nicely with making the
> rare cases less ugly if indeed they are rare. Of course a single
> binding that is not too ugly and still reasonably efficient would be
> best.
>
> I will have a think about this a bit more and see if anything leaps
> out. It's quite an interesting problem...
Just to try to recap what has come up so far:
1. We need to avoid bloating things for basic cases to initialize
several hundred pins.
2. Some muxes need to define multiple states.
3. We need to pass a flag for each mux to know whether or
not it can be freed after init.
So how about let's do separate static and dynamic bindings,
something like this:
/*
* Static init time only mux where
* we only specify phandle to driver
* and, offset of the mux, and the value.
* These pins are discarded after init.
*
* Format: mux_ctrl offset value
*/
pinctrl-static = <&pmx_driver1 0x0020 0x1245
&pmx_driver2 0x0022 0x6578>;
/*
* Dynamic mux where the mux is kept around after
* init and multiple states can be defined for
* a mux as a subnode of the pinmux controller.
*
* Format: mux_phandle initial state
*/
pinctrl-dynamic = <&pmx_sdhci PMX_STATE_ENABLED
&pmx_ehci_xcv PMX_STATE_ENABLED>;
This would make pinctrl-static binding follow the same
standard as GPIO binding and can be parsed easily with
of_parse_phandle_with_args.
Then for pinctrl-dynamic we can make a custom parser,
and the binding can follow the more readable format as
Simon posted.
Regards,
Tony
WARNING: multiple messages have this Message-ID (diff)
From: Tony Lindgren <tony-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org>
To: Simon Glass <sjg-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>
Cc: Dong Aisheng <dongas86-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
"devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org"
<devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org>,
"linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
<linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
"rob.herring-bsGFqQB8/DxBDgjK7y7TUQ@public.gmane.org"
<rob.herring-bsGFqQB8/DxBDgjK7y7TUQ@public.gmane.org>,
"kernel-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org"
<kernel-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>,
"cjb-2X9k7bc8m7Mdnm+yROfE0A@public.gmane.org"
<cjb-2X9k7bc8m7Mdnm+yROfE0A@public.gmane.org>,
"Sascha Hauer (s.hauer-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org)"
<s.hauer-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>,
"linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org"
<linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org>
Subject: Re: Pinmux bindings proposal V2
Date: Fri, 27 Jan 2012 09:37:32 -0800 [thread overview]
Message-ID: <20120127173732.GJ13504@atomide.com> (raw)
In-Reply-To: <CAPnjgZ2EkvTMsOkWyf4pfwRpvcvYs=WaKy5Gi8fdkAUQmvt=ig-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
* Simon Glass <sjg-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org> [120127 07:12]:
>
> On Thu, Jan 26, 2012 at 6:21 PM, Tony Lindgren <tony-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org> wrote:
> >
> > Maybe we need two bindings: A minimal subset of what Stephen is suggesting
> > that can handle 95% of the muxes with minimal overhead, then what you're
> > suggesting for the few muxes that need multiple states?
>
> Perhaps that would work, it certainly deals nicely with making the
> rare cases less ugly if indeed they are rare. Of course a single
> binding that is not too ugly and still reasonably efficient would be
> best.
>
> I will have a think about this a bit more and see if anything leaps
> out. It's quite an interesting problem...
Just to try to recap what has come up so far:
1. We need to avoid bloating things for basic cases to initialize
several hundred pins.
2. Some muxes need to define multiple states.
3. We need to pass a flag for each mux to know whether or
not it can be freed after init.
So how about let's do separate static and dynamic bindings,
something like this:
/*
* Static init time only mux where
* we only specify phandle to driver
* and, offset of the mux, and the value.
* These pins are discarded after init.
*
* Format: mux_ctrl offset value
*/
pinctrl-static = <&pmx_driver1 0x0020 0x1245
&pmx_driver2 0x0022 0x6578>;
/*
* Dynamic mux where the mux is kept around after
* init and multiple states can be defined for
* a mux as a subnode of the pinmux controller.
*
* Format: mux_phandle initial state
*/
pinctrl-dynamic = <&pmx_sdhci PMX_STATE_ENABLED
&pmx_ehci_xcv PMX_STATE_ENABLED>;
This would make pinctrl-static binding follow the same
standard as GPIO binding and can be parsed easily with
of_parse_phandle_with_args.
Then for pinctrl-dynamic we can make a custom parser,
and the binding can follow the more readable format as
Simon posted.
Regards,
Tony
WARNING: multiple messages have this Message-ID (diff)
From: Tony Lindgren <tony@atomide.com>
To: Simon Glass <sjg@chromium.org>
Cc: Stephen Warren <swarren@nvidia.com>,
Dong Aisheng-B29396 <B29396@freescale.com>,
"Linus Walleij (linus.walleij@linaro.org)"
<linus.walleij@linaro.org>,
"Sascha Hauer (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>,
Dong Aisheng <dongas86@gmail.com>,
"Shawn Guo (shawn.guo@linaro.org)" <shawn.guo@linaro.org>,
Thomas Abraham <thomas.abraham@linaro.org>,
"Grant Likely (grant.likely@secretlab.ca)"
<grant.likely@secretlab.ca>,
"devicetree-discuss@lists.ozlabs.org"
<devicetree-discuss@lists.ozlabs.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>
Subject: Re: Pinmux bindings proposal V2
Date: Fri, 27 Jan 2012 09:37:32 -0800 [thread overview]
Message-ID: <20120127173732.GJ13504@atomide.com> (raw)
In-Reply-To: <CAPnjgZ2EkvTMsOkWyf4pfwRpvcvYs=WaKy5Gi8fdkAUQmvt=ig@mail.gmail.com>
* Simon Glass <sjg@chromium.org> [120127 07:12]:
>
> On Thu, Jan 26, 2012 at 6:21 PM, Tony Lindgren <tony@atomide.com> wrote:
> >
> > Maybe we need two bindings: A minimal subset of what Stephen is suggesting
> > that can handle 95% of the muxes with minimal overhead, then what you're
> > suggesting for the few muxes that need multiple states?
>
> Perhaps that would work, it certainly deals nicely with making the
> rare cases less ugly if indeed they are rare. Of course a single
> binding that is not too ugly and still reasonably efficient would be
> best.
>
> I will have a think about this a bit more and see if anything leaps
> out. It's quite an interesting problem...
Just to try to recap what has come up so far:
1. We need to avoid bloating things for basic cases to initialize
several hundred pins.
2. Some muxes need to define multiple states.
3. We need to pass a flag for each mux to know whether or
not it can be freed after init.
So how about let's do separate static and dynamic bindings,
something like this:
/*
* Static init time only mux where
* we only specify phandle to driver
* and, offset of the mux, and the value.
* These pins are discarded after init.
*
* Format: mux_ctrl offset value
*/
pinctrl-static = <&pmx_driver1 0x0020 0x1245
&pmx_driver2 0x0022 0x6578>;
/*
* Dynamic mux where the mux is kept around after
* init and multiple states can be defined for
* a mux as a subnode of the pinmux controller.
*
* Format: mux_phandle initial state
*/
pinctrl-dynamic = <&pmx_sdhci PMX_STATE_ENABLED
&pmx_ehci_xcv PMX_STATE_ENABLED>;
This would make pinctrl-static binding follow the same
standard as GPIO binding and can be parsed easily with
of_parse_phandle_with_args.
Then for pinctrl-dynamic we can make a custom parser,
and the binding can follow the more readable format as
Simon posted.
Regards,
Tony
next prev parent reply other threads:[~2012-01-27 17:37 UTC|newest]
Thread overview: 146+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-01-20 22:22 Pinmux bindings proposal V2 Stephen Warren
2012-01-20 22:22 ` Stephen Warren
2012-01-23 21:00 ` Tony Lindgren
2012-01-23 21:00 ` Tony Lindgren
2012-01-23 21:00 ` Tony Lindgren
2012-01-23 23:08 ` Stephen Warren
2012-01-23 23:08 ` Stephen Warren
2012-01-23 23:08 ` Stephen Warren
2012-01-24 1:20 ` Tony Lindgren
2012-01-24 1:20 ` Tony Lindgren
2012-01-24 1:20 ` Tony Lindgren
2012-01-24 22:29 ` Stephen Warren
2012-01-24 22:29 ` Stephen Warren
2012-01-24 22:29 ` Stephen Warren
2012-01-25 0:04 ` Tony Lindgren
2012-01-25 0:04 ` Tony Lindgren
2012-01-26 19:33 ` Stephen Warren
2012-01-26 19:33 ` Stephen Warren
2012-01-26 19:33 ` Stephen Warren
2012-01-27 2:08 ` Tony Lindgren
2012-01-27 2:08 ` Tony Lindgren
2012-01-27 6:57 ` Shawn Guo
2012-01-27 6:57 ` Shawn Guo
2012-01-27 6:57 ` Shawn Guo
2012-01-27 17:05 ` Tony Lindgren
2012-01-27 17:05 ` Tony Lindgren
2012-01-27 17:05 ` Tony Lindgren
2012-01-30 1:56 ` Shawn Guo
2012-01-30 1:56 ` Shawn Guo
2012-01-30 1:56 ` Shawn Guo
2012-01-30 17:20 ` Tony Lindgren
2012-01-30 17:20 ` Tony Lindgren
2012-01-30 17:20 ` Tony Lindgren
2012-01-31 1:32 ` Shawn Guo
2012-01-31 1:32 ` Shawn Guo
2012-01-31 2:29 ` Tony Lindgren
2012-01-31 2:29 ` Tony Lindgren
2012-01-31 2:29 ` Tony Lindgren
2012-01-31 14:35 ` Reg pinmux driver for OMAP based SoC- AM335X Mohammed, Afzal
2012-01-31 17:05 ` Tony Lindgren
2012-01-31 17:05 ` Tony Lindgren
2012-02-01 10:04 ` Hiremath, Vaibhav
2012-02-01 10:04 ` Hiremath, Vaibhav
2012-02-01 18:14 ` Tony Lindgren
2012-02-01 18:14 ` Tony Lindgren
2012-02-03 20:57 ` Tony Lindgren
2012-02-03 20:57 ` Tony Lindgren
2012-02-01 11:00 ` Mohammed, Afzal
2012-02-01 11:00 ` Mohammed, Afzal
2012-02-01 5:36 ` Pinmux bindings proposal V2 Shawn Guo
2012-02-01 5:36 ` Shawn Guo
2012-02-01 5:36 ` Shawn Guo
2012-01-27 17:36 ` Stephen Warren
2012-01-27 17:36 ` Stephen Warren
2012-01-27 17:36 ` Stephen Warren
2012-01-27 17:42 ` Tony Lindgren
2012-01-27 17:42 ` Tony Lindgren
2012-01-27 17:42 ` Tony Lindgren
2012-01-26 9:36 ` Shawn Guo
2012-01-26 9:36 ` Shawn Guo
2012-01-26 9:36 ` Shawn Guo
2012-01-26 17:51 ` Tony Lindgren
2012-01-26 17:51 ` Tony Lindgren
2012-01-26 17:51 ` Tony Lindgren
2012-01-27 7:19 ` Shawn Guo
2012-01-27 7:19 ` Shawn Guo
2012-01-27 7:19 ` Shawn Guo
2012-01-27 17:16 ` Tony Lindgren
2012-01-27 17:16 ` Tony Lindgren
2012-01-27 17:16 ` Tony Lindgren
2012-01-30 2:10 ` Shawn Guo
2012-01-30 2:10 ` Shawn Guo
2012-01-30 2:10 ` Shawn Guo
2012-01-30 17:43 ` Tony Lindgren
2012-01-30 17:43 ` Tony Lindgren
2012-01-30 17:43 ` Tony Lindgren
2012-01-31 1:07 ` Shawn Guo
2012-01-31 1:07 ` Shawn Guo
2012-01-31 1:07 ` Shawn Guo
2012-01-26 9:24 ` Shawn Guo
2012-01-26 9:24 ` Shawn Guo
2012-01-26 17:42 ` Simon Glass
2012-01-26 17:42 ` Simon Glass
2012-01-27 2:21 ` Tony Lindgren
2012-01-27 2:21 ` Tony Lindgren
2012-01-27 2:21 ` Tony Lindgren
2012-01-27 15:43 ` Simon Glass
2012-01-27 15:43 ` Simon Glass
2012-01-27 17:37 ` Tony Lindgren [this message]
2012-01-27 17:37 ` Tony Lindgren
2012-01-27 17:37 ` Tony Lindgren
2012-01-27 17:51 ` Stephen Warren
2012-01-27 17:51 ` Stephen Warren
2012-01-27 17:51 ` Stephen Warren
2012-01-27 18:10 ` Tony Lindgren
2012-01-27 18:10 ` Tony Lindgren
2012-01-27 18:10 ` Tony Lindgren
2012-01-30 3:27 ` Shawn Guo
2012-01-30 3:27 ` Shawn Guo
2012-01-30 3:27 ` Shawn Guo
2012-01-30 3:13 ` Shawn Guo
2012-01-30 3:13 ` Shawn Guo
2012-01-30 17:49 ` Tony Lindgren
2012-01-30 17:49 ` Tony Lindgren
2012-01-30 17:49 ` Tony Lindgren
2012-01-27 17:38 ` Stephen Warren
2012-01-27 17:38 ` Stephen Warren
2012-01-27 17:38 ` Stephen Warren
2012-01-27 17:29 ` Stephen Warren
2012-01-27 17:29 ` Stephen Warren
2012-01-27 17:29 ` Stephen Warren
2012-01-30 2:31 ` Shawn Guo
2012-01-30 2:31 ` Shawn Guo
2012-01-30 2:31 ` Shawn Guo
2012-02-01 14:35 ` Shawn Guo
2012-02-01 14:35 ` Shawn Guo
2012-02-02 18:36 ` Stephen Warren
2012-02-02 18:36 ` Stephen Warren
2012-02-02 18:36 ` Stephen Warren
2012-02-02 20:07 ` Dong Aisheng
2012-02-02 20:07 ` Dong Aisheng
2012-02-02 20:07 ` Dong Aisheng
2012-02-03 14:02 ` Shawn Guo
2012-02-03 14:02 ` Shawn Guo
2012-02-03 14:02 ` Shawn Guo
2012-02-03 17:21 ` Dong Aisheng
2012-02-03 17:21 ` Dong Aisheng
2012-02-03 17:21 ` Dong Aisheng
2012-02-03 17:32 ` Tony Lindgren
2012-02-03 17:32 ` Tony Lindgren
2012-02-03 17:32 ` Tony Lindgren
2012-02-03 18:13 ` Dong Aisheng
2012-02-03 18:13 ` Dong Aisheng
2012-02-03 18:13 ` Dong Aisheng
2012-02-03 21:05 ` Tony Lindgren
2012-02-03 21:05 ` Tony Lindgren
2012-02-04 16:55 ` Dong Aisheng
2012-02-04 16:55 ` Dong Aisheng
2012-02-04 17:15 ` Tony Lindgren
2012-02-04 17:15 ` Tony Lindgren
2012-02-04 17:15 ` Tony Lindgren
2012-02-03 8:46 ` Shawn Guo
2012-02-03 8:46 ` Shawn Guo
2012-02-13 19:58 ` Stephen Warren
2012-02-13 19:58 ` Stephen Warren
2012-02-13 19:58 ` Stephen Warren
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=20120127173732.GJ13504@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.