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 17:22:44 +0000	[thread overview]
Message-ID: <20171208172244.tbqybyrcubvrnwmm@localhost.localdomain> (raw)
In-Reply-To: <CACRpkdZ_TjC2zoghHpHLXY3tFGkicRGz0pyt=i0828fDs4NjWQ@mail.gmail.com>

On Fri, Dec 08, 2017 at 03:40:49PM +0100, Linus Walleij wrote:
> On Fri, Dec 8, 2017 at 3:29 PM, Charles Keepax
> <ckeepax@opensource.cirrus.com> wrote:
> 
> > (...) 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.
> 
> So then I toss the qcom driver into the game instead :)
> 
> If you look at drivers/pinctrl/qcom/* e.g. pinctrl-ipq4019.c or
> essentially any of the subdrivers, you find exactly this scenario.
> 
> I am concerned that if we add infrastructure for this, it needs
> to have more than one user. Qualcomm does fit your description
> above I think.
> 

Yeah I could certainly have a hunt through for other users that
would make good candidates to update. The QC driver certainly
looks like it would be capable of muxing individual pins,
although it looks like it might not let you mux an individual
GPIO at the moment, need to dig into that more.

I guess maybe a bigger question is do we think this is a problem
worth solving or should really just be adding a group for each
pin I want to be able to mux?

Thanks,
Charles

  reply	other threads:[~2017-12-08 17:22 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
2017-12-08 14:40     ` Linus Walleij
2017-12-08 17:22       ` Charles Keepax [this message]
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=20171208172244.tbqybyrcubvrnwmm@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).