From: Linus Walleij <linus.walleij@linaro.org>
To: Laxman Dewangan <ldewangan@nvidia.com>
Cc: Alexandre Courbot <gnurou@gmail.com>,
Arnd Bergmann <arnd@arndb.de>,
"linux-gpio@vger.kernel.org" <linux-gpio@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"linux-arch@vger.kernel.org" <linux-arch@vger.kernel.org>
Subject: Re: [PATCH 1/1] gpio: lib: Add gpio_is_enabled() to get pin mode
Date: Wed, 16 Nov 2016 20:41:01 +0100 [thread overview]
Message-ID: <CACRpkdYAbkg34fUsBFTm9Ny5HVz=2HpR18cnORyFNH+4R3nJzg@mail.gmail.com> (raw)
In-Reply-To: <582AF350.1000007@nvidia.com>
On Tue, Nov 15, 2016 at 12:36 PM, Laxman Dewangan <ldewangan@nvidia.com> wrote:
> [Me]
>> It would be more natural to add a function pinctrl_is_gpio(unsigned gpio)
>> to call back to the pin controller, then that can be called from
>> the generic or driver-specific debug print callback.
>
>
> We have two type of IPs, GPIO mode is configured in the register which is
> part of GPIO controller and in other IP, it is configured in register which
> is in pincontroller registers.
>
> Your suggested API pinctrl_is_gpio() will definitely help on second case and
> I will work on this once we will have the new IP driver in mainline. This
> will be in coming T186 patches.
I don't really understand this. In both cases we are dealing with pin muxing
and that belongs in the pin control subsystem. What register range the stuff
is in and whether it is called "GPIO block" in the datasheet does not concern
me, it is a pin controller from the point of the view of the kernel subsystems,
if it can multiplex pads/pins.
Yours,
Linus Walleij
prev parent reply other threads:[~2016-11-16 19:41 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-11-02 12:17 [PATCH 1/1] gpio: lib: Add gpio_is_enabled() to get pin mode Laxman Dewangan
2016-11-04 22:20 ` Linus Walleij
2016-11-11 12:17 ` Laxman Dewangan
2016-11-15 9:03 ` Linus Walleij
2016-11-15 11:36 ` Laxman Dewangan
2016-11-16 19:41 ` Linus Walleij [this message]
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='CACRpkdYAbkg34fUsBFTm9Ny5HVz=2HpR18cnORyFNH+4R3nJzg@mail.gmail.com' \
--to=linus.walleij@linaro.org \
--cc=arnd@arndb.de \
--cc=gnurou@gmail.com \
--cc=ldewangan@nvidia.com \
--cc=linux-arch@vger.kernel.org \
--cc=linux-gpio@vger.kernel.org \
--cc=linux-kernel@vger.kernel.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).