public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: "Heiko Stübner" <heiko@sntech.de>
To: Linus Walleij <linus.walleij@linaro.org>
Cc: Patrice Chotard <patrice.chotard.st@gmail.com>,
	"linux-arm-kernel@lists.infradead.org" 
	<linux-arm-kernel@lists.infradead.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"Jean-Christophe PLAGNIOL-VILLARD" <plagnioj@jcrosoft.com>,
	Tomasz Figa <tomasz.figa@gmail.com>
Subject: Re: [PATCH 0/2] pinctrl: common handling of generic pinconfig props in dt
Date: Mon, 10 Jun 2013 15:54:21 +0200	[thread overview]
Message-ID: <201306101554.21671.heiko@sntech.de> (raw)
In-Reply-To: <CACRpkdbnf2MJtnYrwGMVWyz4S=7tuDKv84p7eNgveSNCeLv15g@mail.gmail.com>

Am Montag, 10. Juni 2013, 15:39:26 schrieb Linus Walleij:
> On Mon, Jun 10, 2013 at 3:06 PM, Heiko Stübner <heiko@sntech.de> wrote:
> > Am Montag, 10. Juni 2013, 14:52:13 schrieb Linus Walleij:
> >> On Sun, Jun 9, 2013 at 1:59 AM, Heiko Stübner <heiko@sntech.de> wrote:
> >> > following your suggestions for a common handling of things like pulls
> >> > in dt, I've come up with the following solution - hopefully I've
> >> > gotten the correct meaning of your explanaitions.
> >> > 
> >> > It handles all the pinconfigs that either ignore the argument, or have
> >> > very simple one, like PIN_CONFIG_OUTPUT does.
> >> 
> >> OK patches applied. It needs some rough fixes like NULL check
> >> on kmalloc() but it'll do for a starter.
> > 
> > gah, sorry ... I have urge to crawl under a rock now for forgetting
> > something this obvious ;-) .
> > 
> > Apart from the NULL check what more did I mess up? Should I send a fixup
> > patch or do you want to do it?
> 
> I can fix this.
> 
> But now I just wondered about one thing:
> 
> Does this design imply that we will never be able to support any
> more than 32 bits (well, the number of bits in unsigned long)
> i.e. 32 different generic pin configurations?
> 
> In that case I suspect this might not be so wise. :-(

hmm, yes this would be the limit ... so back to the drawing board


> What about instead of using bitstuffed numbers using some
> representation similar to what can be found in
> Documentation/devicetree/bindings/pinctrl/ste,nomadik.txt
> 
> So instead of using <dt-bindings/pinctrl/pinconfig.h> and
> enumerators it would be more like using node properties
> like this:
> 
> my_config: my_config {
>         bias-disable;
>         drive-push-pull = <6>;
>         output-high;
> };
> 
> It will make the device trees bigger for sure, but maybe more
> readable as well?

There was a discussion about each of the merits of the two approaches 
(bitstuffed vs. individual properties) between Tomasz Figa and Jean-Christophe 
PLAGNIOL-VILLARD a bit back if I remember correctly.


Also I don't think having the configs central like Nomadik does would bloat 
the dt to much, as most of the time most pins share one config or another.

And it still would be possible to write short pin statements as

	pins = <bank pin mux &config_node>;

if I'm not mistaken.

  reply	other threads:[~2013-06-10 13:54 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-06-08 23:59 [PATCH 0/2] pinctrl: common handling of generic pinconfig props in dt Heiko Stübner
2013-06-08 23:59 ` [PATCH 1/2] pinctrl: add devicetree constants for simple generic pnconfig options Heiko Stübner
2013-06-09  0:00 ` [PATCH 2/2] pinctrl: add function to separate combined pinconfig values Heiko Stübner
2013-06-09  0:01 ` [EXAMPLE PATCH] pinctrl: add pinctrl driver for Rockchip SoCs Heiko Stübner
2013-06-10 12:55   ` Linus Walleij
2013-06-10 13:00   ` Linus Walleij
2013-06-10 13:10     ` Heiko Stübner
2013-06-10 13:35       ` [PATCH v2] " Heiko Stübner
2013-06-10 13:40       ` [EXAMPLE PATCH] " Linus Walleij
2013-06-10 18:23     ` Stephen Warren
2013-06-10 19:53       ` Rob Herring
2013-06-11  8:50       ` Linus Walleij
2013-06-10 12:52 ` [PATCH 0/2] pinctrl: common handling of generic pinconfig props in dt Linus Walleij
2013-06-10 13:06   ` Heiko Stübner
2013-06-10 13:39     ` Linus Walleij
2013-06-10 13:54       ` Heiko Stübner [this message]
2013-06-10 14:08         ` 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=201306101554.21671.heiko@sntech.de \
    --to=heiko@sntech.de \
    --cc=linus.walleij@linaro.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=patrice.chotard.st@gmail.com \
    --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