devicetree.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Stephen Warren <swarren@wwwdotorg.org>
To: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
Cc: Tomasz Figa <tomasz.figa@gmail.com>,
	linux-samsung-soc <linux-samsung-soc@vger.kernel.org>,
	"devicetree-discuss@lists.ozlabs.org"
	<devicetree-discuss@lists.ozlabs.org>,
	Doug Anderson <dianders@google.com>,
	Kukjin Kim <kgene.kim@gmail.com>
Subject: Re: Pulls and drive strengths in the pinctrl world
Date: Thu, 23 May 2013 15:39:55 -0600	[thread overview]
Message-ID: <519E8CAB.7000807@wwwdotorg.org> (raw)
In-Reply-To: <20130518163001.GE1952@game.jcrosoft.org>

On 05/18/2013 10:30 AM, Jean-Christophe PLAGNIOL-VILLARD wrote:
> On 16:57 Sat 18 May     , Tomasz Figa wrote:
...
>> Personally I'd prefer a solution with separate property for each 
>> parameter, because it's much more flexible and allows shorter lines, 
>> making device tree sources more readable.
>
> we already discuss this on the ML the one property perline will endup with
> 100s of node if not 1000s so we all do agree we do not want this in the DT

If you introduce s second level of nodes into the DT like the Tegra
bindings do, that's really not an issue.

For Tegra, each pinctrl state is a node.

Within this, there are a bunch of child nodes, each of which applies to
n pins, and sets up an arbitrary set of parameters; some nodes can set
up mux functions, some can set up e.g. pull-up, etc. The same pin can be
affected by multiple of these nodes.

This all allows you to group together common settings and avoid
duplication and having too many nodes.

Then, client drivers' pincrl-0 properties just reference a single
top-level "state" node, not each of the 10/100/... child nodes.

Take a look at something like nodes state_i2xmux_* in
arch/arm/boot/dts/tegra20-seaboard.dts.

  parent reply	other threads:[~2013-05-23 21:39 UTC|newest]

Thread overview: 41+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-05-15 16:44 Pulls and drive strengths in the pinctrl world Doug Anderson
2013-05-15 17:26 ` Tomasz Figa
2013-05-15 18:15   ` Olof Johansson
2013-05-15 21:19   ` Doug Anderson
2013-05-15 21:36     ` Tomasz Figa
2013-05-15 21:57       ` Doug Anderson
2013-05-15 18:29 ` Linus Walleij
2013-05-15 21:31   ` Doug Anderson
2013-05-15 21:41     ` Tomasz Figa
2013-05-15 21:43       ` Tomasz Figa
2013-05-15 22:01       ` Doug Anderson
2013-05-15 22:06         ` Tomasz Figa
2013-05-15 23:55           ` Doug Anderson
2013-05-16  0:13             ` Tomasz Figa
2013-05-16  0:22               ` Stephen Warren
     [not found]                 ` <519426A8.8090908-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org>
2013-05-17 12:26                   ` Jean-Christophe PLAGNIOL-VILLARD
2013-05-17 21:17                     ` Tomasz Figa
2013-05-18  8:18                       ` Jean-Christophe PLAGNIOL-VILLARD
2013-05-18 14:57                         ` Tomasz Figa
2013-05-18 16:30                           ` Jean-Christophe PLAGNIOL-VILLARD
2013-05-18 17:13                             ` Tomasz Figa
2013-05-19  9:17                               ` Jean-Christophe PLAGNIOL-VILLARD
2013-05-19  9:46                                 ` Tomasz Figa
2013-05-19 10:39                                   ` Jean-Christophe PLAGNIOL-VILLARD
2013-05-19 10:56                                     ` Tomasz Figa
2013-05-23 21:42                                 ` Stephen Warren
     [not found]                                   ` <519E8D41.9040508-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org>
2013-05-24  9:10                                     ` Jean-Christophe PLAGNIOL-VILLARD
2013-05-23 21:39                             ` Stephen Warren [this message]
2013-05-21 18:28                     ` Tomasz Figa
2013-05-21 19:09                       ` Jean-Christophe PLAGNIOL-VILLARD
2013-05-16  0:55               ` Doug Anderson
2013-05-16 18:00                 ` Doug Anderson
2013-05-15 23:51   ` Stephen Warren
2013-05-16  0:03     ` Doug Anderson
2013-05-16  0:19       ` Tomasz Figa
2013-05-16  0:58         ` Doug Anderson
2013-05-17  8:38       ` Linus Walleij
2013-05-17  9:09         ` Tomasz Figa
2013-05-17 11:59           ` Linus Walleij
2013-05-17 12:38             ` Tomasz Figa
2013-05-17 14:56               ` Doug Anderson

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=519E8CAB.7000807@wwwdotorg.org \
    --to=swarren@wwwdotorg.org \
    --cc=devicetree-discuss@lists.ozlabs.org \
    --cc=dianders@google.com \
    --cc=kgene.kim@gmail.com \
    --cc=linux-samsung-soc@vger.kernel.org \
    --cc=plagnioj@jcrosoft.com \
    --cc=tomasz.figa@gmail.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).