[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CACRpkdYAbkg34fUsBFTm9Ny5HVz=2HpR18cnORyFNH+4R3nJzg@mail.gmail.com>
Date: Wed, 16 Nov 2016 20:41:01 +0100
From: Linus Walleij <linus.walleij@...aro.org>
To: Laxman Dewangan <ldewangan@...dia.com>
Cc: Alexandre Courbot <gnurou@...il.com>,
Arnd Bergmann <arnd@...db.de>,
"linux-gpio@...r.kernel.org" <linux-gpio@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"linux-arch@...r.kernel.org" <linux-arch@...r.kernel.org>
Subject: Re: [PATCH 1/1] gpio: lib: Add gpio_is_enabled() to get pin mode
On Tue, Nov 15, 2016 at 12:36 PM, Laxman Dewangan <ldewangan@...dia.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
Powered by blists - more mailing lists