linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* [PATCH 1/1] gpio: lib: Add gpio_is_enabled() to get pin mode
@ 2016-11-02 12:17 Laxman Dewangan
  2016-11-04 22:20 ` Linus Walleij
  0 siblings, 1 reply; 6+ messages in thread
From: Laxman Dewangan @ 2016-11-02 12:17 UTC (permalink / raw)
  To: linus.walleij, gnurou, arnd
  Cc: linux-gpio, linux-kernel, linux-arch, Laxman Dewangan

Many of devices/SoCs supports the GPIO and special IO function
from their pins. On such cases, there is always configuration
bits to select the mode of pin as GPIO or as the special IO mode.
The functional modes are selected by pinmux option.

When device booted and reach to kernel, it is not possible to get
the current configuration of pin whether it is in GPIO mode or
in special IO mode without configurations.

Add APIs to return the current mode of pins without requesting it
as GPIO to find out the current mode.
This helps on dumping the pin configuration from debug/test utility
to get the current mode GPIO or functional mode.

The typical utility looks as:
pin_dump(pin)
{
	if(gpio_is_enabled(pin)) {
		dump direction using get_direction()
	} else {
		dump pinmux option and its configurations.
	}
}

Signed-off-by: Laxman Dewangan <ldewangan@nvidia.com>
---
 drivers/gpio/gpiolib.c        | 22 ++++++++++++++++++++++
 include/asm-generic/gpio.h    |  4 ++++
 include/linux/gpio/consumer.h |  8 ++++++++
 include/linux/gpio/driver.h   |  5 +++++
 4 files changed, 39 insertions(+)

diff --git a/drivers/gpio/gpiolib.c b/drivers/gpio/gpiolib.c
index 93ed0e0..4cba61d 100644
--- a/drivers/gpio/gpiolib.c
+++ b/drivers/gpio/gpiolib.c
@@ -2356,6 +2356,28 @@ int gpiod_is_active_low(const struct gpio_desc *desc)
 }
 EXPORT_SYMBOL_GPL(gpiod_is_active_low);
 
+/**
+ * gpiod_is_enabled - Finds whether pin is in GPIO mode or in functional mode.
+ * @desc: the gpio descriptor to check.
+ *
+ * Returns 1 if the GPIO mode is enabled of pin, 0 if it is in functional mode
+ * or negative error if any failure.
+ */
+int gpiod_is_enabled(const struct gpio_desc *desc)
+{
+	struct gpio_chip *chip;
+
+	VALIDATE_DESC(desc);
+	chip = desc->gdev->chip;
+	if (!chip->is_enabled) {
+		gpiod_dbg(desc, "%s: missing is_enabled() ops\n", __func__);
+		return -ENOTSUPP;
+	}
+
+	return chip->is_enabled(chip, gpio_chip_hwgpio(desc));
+}
+EXPORT_SYMBOL_GPL(gpiod_is_enabled);
+
 /* I/O calls are only valid after configuration completed; the relevant
  * "is this a valid GPIO" error checks should already have been done.
  *
diff --git a/include/asm-generic/gpio.h b/include/asm-generic/gpio.h
index 8ca627d..90d15cb 100644
--- a/include/asm-generic/gpio.h
+++ b/include/asm-generic/gpio.h
@@ -89,6 +89,10 @@ static inline void gpio_set_value_cansleep(unsigned gpio, int value)
 	return gpiod_set_raw_value_cansleep(gpio_to_desc(gpio), value);
 }
 
+static inline int gpio_is_enabled(unsigned gpio)
+{
+	return gpiod_is_enabled(gpio_to_desc(gpio));
+}
 
 /* A platform's <asm/gpio.h> code may want to inline the I/O calls when
  * the GPIO is constant and refers to some always-present controller,
diff --git a/include/linux/gpio/consumer.h b/include/linux/gpio/consumer.h
index fb0fde6..9f9e1d3 100644
--- a/include/linux/gpio/consumer.h
+++ b/include/linux/gpio/consumer.h
@@ -124,6 +124,7 @@ int gpiod_set_debounce(struct gpio_desc *desc, unsigned debounce);
 
 int gpiod_is_active_low(const struct gpio_desc *desc);
 int gpiod_cansleep(const struct gpio_desc *desc);
+int gpiod_is_enabled(const struct gpio_desc *desc);
 
 int gpiod_to_irq(const struct gpio_desc *desc);
 
@@ -389,6 +390,13 @@ static inline int gpiod_cansleep(const struct gpio_desc *desc)
 	return 0;
 }
 
+static inline int gpiod_is_enabled(const struct gpio_desc *desc)
+{
+	/* GPIO can never have been requested */
+	WARN_ON(1);
+	return 0;
+}
+
 static inline int gpiod_to_irq(const struct gpio_desc *desc)
 {
 	/* GPIO can never have been requested */
diff --git a/include/linux/gpio/driver.h b/include/linux/gpio/driver.h
index 2dfcf25..7b67b06 100644
--- a/include/linux/gpio/driver.h
+++ b/include/linux/gpio/driver.h
@@ -60,6 +60,9 @@ enum single_ended_mode {
  *	with LINE_MODE_OPEN_SOURCE as mode argument.
  * @to_irq: optional hook supporting non-static gpio_to_irq() mappings;
  *	implementation may not sleep
+ * @is_enabled: optional hook for finding whether pin is in GPIO mode or in
+ *	functional mode. returns value for pin mode "offset", 0 for functional,
+ *	1 for GPIO mode or negative error.
  * @dbg_show: optional routine to show contents in debugfs; default code
  *	will be used when this is omitted, but custom code can show extra
  *	state (such as pullup/pulldown configuration).
@@ -159,6 +162,8 @@ struct gpio_chip {
 
 	int			(*to_irq)(struct gpio_chip *chip,
 						unsigned offset);
+	int			(*is_enabled)(struct gpio_chip *chip,
+						unsigned offset);
 
 	void			(*dbg_show)(struct seq_file *s,
 						struct gpio_chip *chip);
-- 
2.1.4

^ permalink raw reply related	[flat|nested] 6+ messages in thread

* Re: [PATCH 1/1] gpio: lib: Add gpio_is_enabled() to get pin mode
  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
  0 siblings, 1 reply; 6+ messages in thread
From: Linus Walleij @ 2016-11-04 22:20 UTC (permalink / raw)
  To: Laxman Dewangan
  Cc: Alexandre Courbot, Arnd Bergmann, linux-gpio, linux-kernel, linux-arch

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

> Many of devices/SoCs supports the GPIO and special IO function
> from their pins. On such cases, there is always configuration
> bits to select the mode of pin as GPIO or as the special IO mode.
> The functional modes are selected by pinmux option.
>
> When device booted and reach to kernel, it is not possible to get
> the current configuration of pin whether it is in GPIO mode or
> in special IO mode without configurations.
>
> Add APIs to return the current mode of pins without requesting it
> as GPIO to find out the current mode.
> This helps on dumping the pin configuration from debug/test utility
> to get the current mode GPIO or functional mode.
>
> The typical utility looks as:
> pin_dump(pin)
> {
>         if(gpio_is_enabled(pin)) {
>                 dump direction using get_direction()
>         } else {
>                 dump pinmux option and its configurations.
>         }
> }

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.

Also it is possible for any GPIO chip to implement its own
debug print if they like, check what we do in
->dbg_show in drivers/pinctrl/nomadik/pinctrl-nomadik.c
for example.

If the use is for debug prints, keep it driver-local.

(...)
> +static inline int gpio_is_enabled(unsigned gpio)
> +{
> +       return gpiod_is_enabled(gpio_to_desc(gpio));
> +}

NAK why would be encourage the non-descriptor interface by
adding to it? Better only offer this to the descriptor users.

Yours,
Linus Walleij

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [PATCH 1/1] gpio: lib: Add gpio_is_enabled() to get pin mode
  2016-11-04 22:20 ` Linus Walleij
@ 2016-11-11 12:17   ` Laxman Dewangan
  2016-11-15  9:03     ` Linus Walleij
  0 siblings, 1 reply; 6+ messages in thread
From: Laxman Dewangan @ 2016-11-11 12:17 UTC (permalink / raw)
  To: Linus Walleij
  Cc: Alexandre Courbot, Arnd Bergmann, linux-gpio, linux-kernel, linux-arch


On Saturday 05 November 2016 03:50 AM, Linus Walleij wrote:
> On Wed, Nov 2, 2016 at 1:17 PM, Laxman Dewangan <ldewangan@nvidia.com> wrote:
>
>> Many of devices/SoCs supports the GPIO and special IO function
>> from their pins. On such cases, there is always configuration
>> bits to select the mode of pin as GPIO or as the special IO mode.
>> The functional modes are selected by pinmux option.
>>
>> When device booted and reach to kernel, it is not possible to get
>> the current configuration of pin whether it is in GPIO mode or
>> in special IO mode without configurations.
>>
>> Add APIs to return the current mode of pins without requesting it
>> as GPIO to find out the current mode.
>> This helps on dumping the pin configuration from debug/test utility
>> to get the current mode GPIO or functional mode.
>>
>> The typical utility looks as:
>> pin_dump(pin)
>> {
>>          if(gpio_is_enabled(pin)) {
>>                  dump direction using get_direction()
>>          } else {
>>                  dump pinmux option and its configurations.
>>          }
>> }
> 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.


>
> Also it is possible for any GPIO chip to implement its own
> debug print if they like, check what we do in
> ->dbg_show in drivers/pinctrl/nomadik/pinctrl-nomadik.c
> for example.
>
> If the use is for debug prints, keep it driver-local.
>
> (...)

This callback can print the stuff for GPIO related stuff as there is not 
much info about the pinmux related configuration to gpio driver. For 
GPIO or functional mode, it can only display gpio or functional mode.

Is there something we can link from gpio driver to pinctrl driver like 
pinctrl_debug_show()?
Like in gpio_request(), we say that pinctrl_request(), similary on the 
GPIO dbg_show(), we can say pinctrl_dbg_show() and get all the info for 
prints.
This will also serve the purpose.

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [PATCH 1/1] gpio: lib: Add gpio_is_enabled() to get pin mode
  2016-11-11 12:17   ` Laxman Dewangan
@ 2016-11-15  9:03     ` Linus Walleij
  2016-11-15 11:36       ` Laxman Dewangan
  0 siblings, 1 reply; 6+ messages in thread
From: Linus Walleij @ 2016-11-15  9:03 UTC (permalink / raw)
  To: Laxman Dewangan
  Cc: Alexandre Courbot, Arnd Bergmann, linux-gpio, linux-kernel, linux-arch

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

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [PATCH 1/1] gpio: lib: Add gpio_is_enabled() to get pin mode
  2016-11-15  9:03     ` Linus Walleij
@ 2016-11-15 11:36       ` Laxman Dewangan
  2016-11-16 19:41         ` Linus Walleij
  0 siblings, 1 reply; 6+ messages in thread
From: Laxman Dewangan @ 2016-11-15 11:36 UTC (permalink / raw)
  To: Linus Walleij
  Cc: Alexandre Courbot, Arnd Bergmann, linux-gpio, linux-kernel, linux-arch


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.

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [PATCH 1/1] gpio: lib: Add gpio_is_enabled() to get pin mode
  2016-11-15 11:36       ` Laxman Dewangan
@ 2016-11-16 19:41         ` Linus Walleij
  0 siblings, 0 replies; 6+ messages in thread
From: Linus Walleij @ 2016-11-16 19:41 UTC (permalink / raw)
  To: Laxman Dewangan
  Cc: Alexandre Courbot, Arnd Bergmann, linux-gpio, linux-kernel, linux-arch

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

^ permalink raw reply	[flat|nested] 6+ messages in thread

end of thread, other threads:[~2016-11-16 19:41 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
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 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).