linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: grant.likely@secretlab.ca (Grant Likely)
To: linux-arm-kernel@lists.infradead.org
Subject: Pinmux bindings proposal
Date: Wed, 18 Jan 2012 13:22:19 -0700	[thread overview]
Message-ID: <20120118202219.GI4223@ponder.secretlab.ca> (raw)
In-Reply-To: <20120118162943.GC22818@atomide.com>

On Wed, Jan 18, 2012 at 08:29:43AM -0800, Tony Lindgren wrote:
> * Tony Lindgren <tony@atomide.com> [120118 07:00]:
> > * Shawn Guo <shawn.guo@linaro.org> [120118 05:57]:
> > > On 18 January 2012 22:13, Tony Lindgren <tony@atomide.com> wrote:
> > > > Hi,
> > > >
> > > > * Grant Likely <grant.likely@secretlab.ca> [120116 09:55]:
> > > >> On Fri, Jan 13, 2012 at 12:39:42PM -0800, Stephen Warren wrote:
> > > >> > ? ? ? ? ? ? ? ? pinmux =
> > > >> > ? ? ? ? ? ? ? ? ? ? ? ? <"default" &pmx_sdhci_active>
> > > >> > ? ? ? ? ? ? ? ? ? ? ? ? <"suspend" &pmx_sdhci_suspend>;
> > > >> >
> > > >> > ? ? ? ? ? ? ? ? /* 1:n example: */
> > > >> > ? ? ? ? ? ? ? ? pinmux =
> > > >> > ? ? ? ? ? ? ? ? ? ? ? ? <"default" &pmx_sdhci_mux_a>
> > > >> > ? ? ? ? ? ? ? ? ? ? ? ? <"default" &pmx_sdhci_pincfg_a>
> > > >> > ? ? ? ? ? ? ? ? ? ? ? ? <"suspend" &pmx_sdhci_mux_a>
> > > >> > ? ? ? ? ? ? ? ? ? ? ? ? <"suspend" &pmx_sdhci_pincfg_a_suspend>;
> > > >>
> > > >>
> > > >> Yeah, don't do this. ?Mixing phandle, string and cell values in a
> > > >> property gets messy and could become troublesome to parse. ?I've
> > > >> backed away from it in the clk binding.
> > > >
> > > > Yup, that's because the string is embedded directly into the mixed
> > > > mode array and will likely make the following data unaligned. That
> > > > means it's extremely flakey to parse, and will lead into horrible
> > > > errors if you have typos in the .dts file.. Tried that and gave up
> > > > on it.
> > > >
> > > > I think I've found a way to avoid using names at all, assuming we set
> > > > each pin as a phandle for the drivers to use :)
> > > >
> > > The problem with doing that is we will have to represent each pin as a
> > > node in device tree.  For imx6q case, we have 197 pins.  Doing so will
> > > bloat the device tree.
> > 
> > Sure there's some overhead. I've got it working with 220 pins, it's
> > not too bad as threre's not much string parsing involved.
> > 
> > I don't have all the devices mapping the pins though. The .dtb for
> > omap4 is about 25k now.
> > 
> > If we wanted to avoid adding phandles for each pin, then we could do:
> > 
> > serial at 0x48020000 {
> > 	compatible = "ti,8250";
> > 	reg = <0x48020000 0x100>;
> > 	reg-shift = <2>;
> > 	interrupts = <106>;
> > 
> > 	/* controller, offset, value */
> > 	pins = <&mux1 0xabcd 0x10
> >                 &mux1 0xabcf 0x0>;
> > };
> > 
> > But then the .dts file becomes an unreadable matrix unless we have
> > a preprocessor..
> 
> Forgot to mention that as long as we all standardize to use something
> common for #pin-args and of_parse_phandle_with_args(), the pin mapping
> could depend on the pinmux driver for selecting whether or not to use
> a phandle for each pin.

Yes, the actual layout parsing should remain in the control of the
pinmux controller like it does for irqs, gpios, etc.

g.

  reply	other threads:[~2012-01-18 20:22 UTC|newest]

Thread overview: 54+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-01-13 20:39 Pinmux bindings proposal Stephen Warren
2012-01-14  7:09 ` Shawn Guo
2012-01-17 18:47   ` Stephen Warren
2012-01-18  3:32     ` Shawn Guo
2012-01-18 19:00       ` Stephen Warren
2012-01-16 12:50 ` Dong Aisheng-B29396
2012-01-17  8:23   ` Shawn Guo
2012-01-17  9:46     ` Dong Aisheng-B29396
2012-01-17 14:13       ` Shawn Guo
2012-01-17 19:32         ` Stephen Warren
2012-01-18  3:44         ` Dong Aisheng-B29396
2012-01-18  4:47           ` Shawn Guo
2012-01-18 19:24           ` Stephen Warren
2012-01-17 19:28       ` Stephen Warren
2012-01-18 11:06         ` Dong Aisheng-B29396
2012-01-20 20:28           ` Stephen Warren
2012-01-27 12:00             ` Linus Walleij
2012-01-27 16:58               ` Stephen Warren
2012-01-17 19:21     ` Stephen Warren
2012-01-18  4:01       ` Shawn Guo
2012-01-18  9:32       ` Dong Aisheng-B29396
2012-01-17 19:09   ` Stephen Warren
2012-01-18  7:24     ` Dong Aisheng-B29396
2012-01-18 19:42       ` Stephen Warren
2012-01-16 18:28 ` Grant Likely
2012-01-18 14:13   ` Tony Lindgren
2012-01-18 14:30     ` Shawn Guo
2012-01-18 15:32       ` Tony Lindgren
2012-01-18 16:29         ` Tony Lindgren
2012-01-18 20:22           ` Grant Likely [this message]
2012-01-18 20:20         ` Grant Likely
2012-01-19 10:31           ` Tony Lindgren
2012-01-18 20:02     ` Stephen Warren
2012-01-19 10:57       ` Tony Lindgren
2012-01-20 20:50         ` Stephen Warren
2012-01-23 20:13           ` Tony Lindgren
2012-01-23 22:54             ` Stephen Warren
2012-01-27 13:11           ` Linus Walleij
2012-01-18 12:16 ` Thomas Abraham
2012-01-18 19:52   ` Stephen Warren
2012-01-19 17:01     ` Tony Lindgren
2012-01-19 13:10 ` Thomas Abraham
2012-01-19 16:56   ` Tony Lindgren
2012-01-19 17:38     ` Thomas Abraham
2012-01-19 18:20       ` Tony Lindgren
2012-01-19 18:38         ` Thomas Abraham
2012-01-20 10:05           ` Tony Lindgren
2012-01-20 16:17             ` Thomas Abraham
2012-01-20 17:53               ` Tony Lindgren
2012-01-21  1:38                 ` Thomas Abraham
2012-01-20 21:15     ` Stephen Warren
2012-01-20 21:11   ` Stephen Warren
2012-01-21  1:27     ` Thomas Abraham
2012-01-23 22:43       ` 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=20120118202219.GI4223@ponder.secretlab.ca \
    --to=grant.likely@secretlab.ca \
    --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 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).