From: Linus Walleij <linus.walleij@linaro.org>
To: Rajendra Nayak <rnayak@codeaurora.org>
Cc: Bjorn Andersson <bjorn.andersson@linaro.org>,
Andy Gross <agross@kernel.org>,
MSM <linux-arm-msm@vger.kernel.org>,
"open list:GPIO SUBSYSTEM" <linux-gpio@vger.kernel.org>,
linux-kernel <linux-kernel@vger.kernel.org>,
Prasad Sodagudi <psodagud@codeaurora.org>
Subject: Re: [PATCH] pinctrl: qcom: Add egpio feature support
Date: Tue, 21 Sep 2021 17:56:04 +0200 [thread overview]
Message-ID: <CACRpkdaJm_UbJu=kXGOFs76MiAiTkqToEpOnf1Pk-by4FsCcgQ@mail.gmail.com> (raw)
In-Reply-To: <d2f28d34-99b3-30f8-8504-bc819946876f@codeaurora.org>
On Tue, Sep 21, 2021 at 12:39 PM Rajendra Nayak <rnayak@codeaurora.org> wrote:
> On 9/20/2021 6:14 AM, Bjorn Andersson wrote:
> > It seems reasonable that this would be another pinmux state for these
> > pins, rather than just flipping them all in one or the other direction.
>
> hmm, I don't understand. This is not a pinmux state, its a switch to decide
> the ownership.
> These egpio pins have regulator mux functions, some for apps, some for the
> island processor, they might not always be used as gpios.
The pinmux API is for muliplexing a pin between owners, and that
is what is going on is it not?
If the bit(s) select different processors that is changing the owner
and creating a usage matrix, e.g.
TLMM_GPIO
ISLAND_GPIO
TLMM_I2C
ISLAND_I2C
etc etc
They become different muxing states nevertheless. How to encode them,
such as (a) bitfields in the enums, (b) more cells in the device tree or
(c) ... that is another question.
Shoehorning it into pinconf is not the answer IMO.
Yours,
Linus Walleij
next prev parent reply other threads:[~2021-09-21 15:56 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-09-17 6:37 [PATCH] pinctrl: qcom: Add egpio feature support Rajendra Nayak
2021-09-17 16:00 ` Doug Anderson
2021-09-20 0:44 ` Bjorn Andersson
2021-09-21 10:39 ` Rajendra Nayak
2021-09-21 15:56 ` Linus Walleij [this message]
2021-09-21 16:26 ` Bjorn Andersson
2021-09-30 9:46 ` Rajendra Nayak
2021-09-30 14:55 ` Bjorn Andersson
2021-10-01 5:34 ` Rajendra Nayak
2021-10-04 20:43 ` Bjorn Andersson
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='CACRpkdaJm_UbJu=kXGOFs76MiAiTkqToEpOnf1Pk-by4FsCcgQ@mail.gmail.com' \
--to=linus.walleij@linaro.org \
--cc=agross@kernel.org \
--cc=bjorn.andersson@linaro.org \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-gpio@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=psodagud@codeaurora.org \
--cc=rnayak@codeaurora.org \
/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).