linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Tony Lindgren <tony@atomide.com>
To: Peter Ujfalusi <peter.ujfalusi@ti.com>
Cc: Linus Walleij <linus.walleij@linaro.org>,
	linux-kernel@vger.kernel.org, linux-omap@vger.kernel.org
Subject: Re: [PATCH 2/2] pinctrl: pinctrl-single: Add pinctrl-single,bits type of mux
Date: Mon, 10 Sep 2012 10:10:03 -0700	[thread overview]
Message-ID: <20120910171002.GY1303@atomide.com> (raw)
In-Reply-To: <504DD532.4040400@ti.com>

* Peter Ujfalusi <peter.ujfalusi@ti.com> [120910 04:55]:
> On 09/07/2012 07:55 PM, Tony Lindgren wrote:
> > 
> > I'd like to have something that specifies the controller type so
> > we don't need to mix two types of controllers and test for
> > non-existing properties when parsing the pins.
> > 
> > How about we require something specified for the pinctrl driver
> > in the "one-bit-per-mux" case like pinctrl-single,bit-per-mux?
> > 
> > And then in the pinctrl-single probe we set params = 3 if
> > pinctrl-single,bit-per-mux is specified. And if no
> > pinctrl-single,bit-per-mux is specified then set params = 2.
> > 
> > That way pcs_parse_one_pinctrl_entry() can just test for params.
> > 
> > Sorry I don't have a better name in mind than bit-per-mux..
> 
> I'm not sure if this would make things more prone to error or make the DTS or
> the code more clean in any ways.
> 
> Both pinctrl-single,pins and pinctrl-single,bits works on top of the same
> pinctrl-single area.
> In most cases we are going to use pinctrl-single,pins for the mux
> configuration and only in few places we need to fall back to pinctrl-single,bits.

What about hardware that has tons of one-bit-per-mux type of registers?
Then we end up trying to find the non-existing property potentially
hundreds of times as the pinctrl-single,pins is never specified.
 
> With this patch we will have maximum of two query to find out which type is
> used, while if we add the 'bit-per-mux' property we will always have need to
> have two of_get_property() call to figure out what is used.
> IMHO in this way we could also have copy-paste errors coming at us when adding
> the mux configurations for the pins and at the end we also need to do same
> safety/sanity checks if the user really provided the correct type with
> correlation to the 'bit-per-mux'.

Well I think we should specify the binding for the type of the controller,
not mix different types of bindings for the same controller. So we should
probably have something just like address-cells, gpio-cells and
interrupt-cells, although in this case it would be specific to pinctrl-single
only and not be called cells.

> This would just complicate the code.
> The existence of pinctrl-single,pins or pinctrl-single,bits property alone
> gives enough information for the number of parameters.

Yes but we don't want to allow mixing different kind of registers within
the same controller, they should be specified as separate controllers.

Regards,

Tony

  reply	other threads:[~2012-09-10 17:10 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-09-05  9:01 [PATCH 0/2] pinctrl: pinctrl-single: new type: pinctrl-single,bits Peter Ujfalusi
2012-09-05  9:01 ` [PATCH 1/2] pinctrl: pinctrl-single: Make sure we do not change bits outside of mask Peter Ujfalusi
2012-09-06 18:59   ` Tony Lindgren
2012-09-07 21:13     ` Linus Walleij
2012-09-07 21:39       ` Tony Lindgren
2012-09-10  7:09   ` Linus Walleij
2012-09-05  9:01 ` [PATCH 2/2] pinctrl: pinctrl-single: Add pinctrl-single,bits type of mux Peter Ujfalusi
2012-09-06 19:10   ` Tony Lindgren
2012-09-07 15:13     ` Peter Ujfalusi
2012-09-07 16:55       ` Tony Lindgren
2012-09-10 11:55         ` Peter Ujfalusi
2012-09-10 17:10           ` Tony Lindgren [this message]
2012-09-10  7:10   ` Linus Walleij
2012-09-10 18:49     ` Tony Lindgren
2012-09-05 12:10 ` [PATCH 0/2] pinctrl: pinctrl-single: new type: pinctrl-single,bits Linus Walleij
2012-09-05 18:20   ` Tony Lindgren

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=20120910171002.GY1303@atomide.com \
    --to=tony@atomide.com \
    --cc=linus.walleij@linaro.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-omap@vger.kernel.org \
    --cc=peter.ujfalusi@ti.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).