linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Charles Keepax <ckeepax@opensource.cirrus.com>
To: Linus Walleij <linus.walleij@linaro.org>
Cc: ext Tony Lindgren <tony@atomide.com>,
	"linux-gpio@vger.kernel.org" <linux-gpio@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	<patches@opensource.cirrus.com>,
	"Bjorn Andersson" <bjorn.andersson@linaro.org>,
	Stephen Warren <swarren@wwwdotorg.org>
Subject: Re: [PATCH 0/4] Add support for muxing individual pins
Date: Fri, 8 Dec 2017 14:29:23 +0000	[thread overview]
Message-ID: <20171208142923.2exqaateli2qmtzl@localhost.localdomain> (raw)
In-Reply-To: <CACRpkdYMBan5WrEvsQDu0dveq13bW4w=3bOgS71fcFfd4e=UGA@mail.gmail.com>

On Mon, Oct 09, 2017 at 11:10:34PM +0200, Linus Walleij wrote:
> On Fri, Sep 29, 2017 at 12:14 PM, Charles Keepax
> <ckeepax@opensource.cirrus.com> wrote:
> > This series add support for muxing individual pins within
> > pin mux, rather than just whole groups. Mainly, I had two
> > motivations here, one to avoid the need to add loads of groups
> > containing individual pins and hardware that actually has some
> > internal concept of groups of pins, and disambiguating that from
> > individual pin muxing.  I have marked it as RFC to just get
> > peoples opinions at this stage, although it should be pretty well
> > tested. Sorry about the amount of files touched in patch 2 it
> > would be possible to drop it from the chain although it leaves
> > the field rather inaccurately named.
> >
> > Also I have left all the existing code paths parsing all mux
> > options as groups from DT, and added a new helper to unlock the
> > pin based functionality this should ease the transition across.
> There is currently a driver in the pin control subsystem that
> handles individual pins and that is pinctrl-single.c.
> 
> The driver is deployed for single pins muxed by a single
> register, and if this infrastructure is to be deployed it must
> be applied also in pinctrl-single. We cannot have several ways
> of doing the same thing, that way lies madness.
> 
> So you need Tony Lindgren's review and direction on this
> patch series.

Apologies for the delay on this one, I got some what snowed under
with other tasks. Please let me know if you would rather I just
resent the series to refresh everyones memory. But I have finally
managed to get some time to look over the pinctrl-single stuff.

Naively one could convert the pinctrl-single stuff over to use
the patches I proposed creating one large group for the driver
and then mux each pin individually from within that.  However I
am not really sure it would make sense. From the implementation
so far the pinctrl-single stuff appears to target systems where
there isn't really a concept of groups. Each pin is just a
completely separate entry and you can only configure things one
pin at a time. In that case it almost makes more sense to model
each pin as an individual group such that it is clearly distinct
from the others. My thinking had been more along the lines of you
perhaps have a group that represents an I2S port but you can also
individually assign each of those pins as a GPIO when not in use
as the I2S port.

Alternatively one could perhaps look at expanding the pinctrl-single
stuff to have some notion of groups as well. So you could define
sub groups of the pins that can be set as a block. Allowing users
to configure either groups or individual pins.

I guess my main question is what is the intention of the
pinctrl-single code, is this something that should be seeing
expansion to handle groups as well or is it firmly for the
unrelated pins cases?

Thanks,
Charles

  parent reply	other threads:[~2017-12-08 14:29 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-09-29 10:14 [PATCH 0/4] Add support for muxing individual pins Charles Keepax
2017-09-29 10:15 ` [PATCH RFC 1/4] pinctrl: Factor out individual pin handling from pinmux_pins_show Charles Keepax
2017-09-29 10:15 ` [PATCH RFC 2/4] pinctrl: Rename mux group to group_or_pin to prepare for pin support Charles Keepax
2017-10-02 10:10   ` Charles Keepax
2017-09-29 10:15 ` [PATCH RFC 3/4] pinctrl: Add support for muxing individual pins Charles Keepax
2017-09-29 10:15 ` [PATCH RFC 4/4] pinctrl: Add support for parsing individual pinmux from DT Charles Keepax
2017-10-09 21:10 ` [PATCH 0/4] Add support for muxing individual pins Linus Walleij
2017-10-10  8:45   ` Charles Keepax
2017-12-08 14:29   ` Charles Keepax [this message]
2017-12-08 14:40     ` Linus Walleij
2017-12-08 17:22       ` Charles Keepax
2017-12-09  4:15         ` Bjorn Andersson
2017-12-08 16:28     ` Tony Lindgren
2017-12-08 17:16       ` Charles Keepax
2017-12-08 19:41         ` 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=20171208142923.2exqaateli2qmtzl@localhost.localdomain \
    --to=ckeepax@opensource.cirrus.com \
    --cc=bjorn.andersson@linaro.org \
    --cc=linus.walleij@linaro.org \
    --cc=linux-gpio@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=patches@opensource.cirrus.com \
    --cc=swarren@wwwdotorg.org \
    --cc=tony@atomide.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).