Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1522465 > unrolled thread

Re: [PATCH 1/1] gpio: lib: Add gpio_is_enabled() to get pin mode

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [PATCH 1/1] gpio: lib: Add gpio_is_enabled() to get pin mode Linus Walleij <linus.walleij@linaro.org> - 2016-11-15 10:10 +0100
    Re: [PATCH 1/1] gpio: lib: Add gpio_is_enabled() to get pin mode Laxman Dewangan <ldewangan@nvidia.com> - 2016-11-15 13:00 +0100
      Re: [PATCH 1/1] gpio: lib: Add gpio_is_enabled() to get pin mode Linus Walleij <linus.walleij@linaro.org> - 2016-11-16 20:50 +0100

#1522465 — Re: [PATCH 1/1] gpio: lib: Add gpio_is_enabled() to get pin mode

On Fri, Nov 11, 2016 at 1:17 PM, Laxman Dewangan <ldewangan@nvidia.com> wrote:

>> Yeah but since pinctrl and pinmux has its own debugfs files why is this
>> necessary? I understand it is convenient but only for debugging
>> right? They the inconvenience of using pinctrls debugfs files should
>> be bearable.
>
> Yes, it is debugging and capturing all the info at single place. Currently,
> gpio debugFs shows the gpio related stuff and the pinctrl on pinconfig but
> there is not any dump which shows the complete pin mapping.
> The effort is to compile all the data in single place with proper message to
> avoid any manual work for decoding multiple outputs.

I don't know if this is a good idea. I don't want to clutter the
gpiolib ABI for no good reason.

For certain this should only be available for drivers using pin
control as a back-end for their GPIOs.

For that purpose we have (in <linux/pinctrl/consumer.h>:

/* External interface to pin control */
extern int pinctrl_request_gpio(unsigned gpio);
extern void pinctrl_free_gpio(unsigned gpio);
extern int pinctrl_gpio_direction_input(unsigned gpio);
extern int pinctrl_gpio_direction_output(unsigned gpio);

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.

Yours,
Linus Walleij

[toc] | [next] | [standalone]

#1522608

On Tuesday 15 November 2016 02:33 PM, Linus Walleij wrote:
> On Fri, Nov 11, 2016 at 1:17 PM, Laxman Dewangan <ldewangan@nvidia.com> wrote:
>
>>> Yeah but since pinctrl and pinmux has its own debugfs files why is this
>>> necessary? I understand it is convenient but only for debugging
>>> right? They the inconvenience of using pinctrls debugfs files should
>>> be bearable.
>> Yes, it is debugging and capturing all the info at single place. Currently,
>> gpio debugFs shows the gpio related stuff and the pinctrl on pinconfig but
>> there is not any dump which shows the complete pin mapping.
>> The effort is to compile all the data in single place with proper message to
>> avoid any manual work for decoding multiple outputs.
> I don't know if this is a good idea. I don't want to clutter the
> gpiolib ABI for no good reason.
>
> For certain this should only be available for drivers using pin
> control as a back-end for their GPIOs.
>
> For that purpose we have (in <linux/pinctrl/consumer.h>:
>
> /* External interface to pin control */
> extern int pinctrl_request_gpio(unsigned gpio);
> extern void pinctrl_free_gpio(unsigned gpio);
> extern int pinctrl_gpio_direction_input(unsigned gpio);
> extern int pinctrl_gpio_direction_output(unsigned gpio);
>
> 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.


For T210 SoC, the configuration is done in gpio controller and we need 
to have debug utility outside of driver and hence the requirements was.

[toc] | [prev] | [next] | [standalone]

#1523781

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

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web