Skip to contentSkip to conversation

gpio: em: Add pinctrl support

PATCH In review Magnus Damm 4 participants 6 messages Jul 3, 2013 – Jul 21, 2013

Subsystems (2)
lore
Share & tools
lore
#0 lore raw

PATCH 1/1 gpio: em: Add pinctrl support

From: Magnus Damm <[email protected]>

Register the GPIO pin range, and request and free GPIO pins using the pinctrl API. The pctl_name platform data member should be used by platform devices to point out which pinctrl device to use.

Follows same style as "dc3465a gpio-rcar: Add pinctrl support", by Laurent Pinchart, thanks to him.

---

 drivers/gpio/gpio-em.c                |   25 +++++++++++++++++++++++++
 include/linux/platform_data/gpio-em.h |    1 +
 2 files changed, 26 insertions(+)
drivers/gpio/gpio-em.c +25 -0
@@ -30,6 +30,7 @@
 #include <linux/gpio.h>
 #include <linux/slab.h>
 #include <linux/module.h>
+#include <linux/pinctrl/consumer.h>
 #include <linux/platform_data/gpio-em.h>
 
 struct em_gio_priv {
@@ -216,6 +217,21 @@ static int em_gio_to_irq(struct gpio_chi
 	return irq_create_mapping(gpio_to_priv(chip)->irq_domain, offset);
 }
 
+static int em_gio_request(struct gpio_chip *chip, unsigned offset)
+{
+	return pinctrl_request_gpio(chip->base + offset);
+}
+
+static void em_gio_free(struct gpio_chip *chip, unsigned offset)
+{
+	pinctrl_free_gpio(chip->base + offset);
+
+	/* Set the GPIO as an input to ensure that the next GPIO request won't
+	* drive the GPIO pin as an output.
+	*/
+	em_gio_direction_input(chip, offset);
+}
+
 static int em_gio_irq_domain_map(struct irq_domain *h, unsigned int virq,
 				 irq_hw_number_t hw)
 {
@@ -308,6 +324,8 @@ static int em_gio_probe(struct platform_
 	gpio_chip->direction_output = em_gio_direction_output;
 	gpio_chip->set = em_gio_set;
 	gpio_chip->to_irq = em_gio_to_irq;
+	gpio_chip->request = em_gio_request;
+	gpio_chip->free = em_gio_free;
 	gpio_chip->label = name;
 	gpio_chip->owner = THIS_MODULE;
 	gpio_chip->base = pdata->gpio_base;
@@ -351,6 +369,13 @@ static int em_gio_probe(struct platform_
 		dev_err(&pdev->dev, "failed to add GPIO controller\n");
 		goto err1;
 	}
+
+	if (pdata->pctl_name) {
+		ret = gpiochip_add_pin_range(gpio_chip, pdata->pctl_name, 0,
+					     gpio_chip->base, gpio_chip->ngpio);
+		if (ret < 0)
+			dev_warn(&pdev->dev, "failed to add pin range\n");
+	}
 	return 0;
 
 err1:
include/linux/platform_data/gpio-em.h +1 -0
@@ -5,6 +5,7 @@ struct gpio_em_config {
 	unsigned int gpio_base;
 	unsigned int irq_base;
 	unsigned int number_of_pins;
+	const char *pctl_name;
 };
 
 #endif /* __GPIO_EM_H__ */
Acked-by on v1 1/1
#1 lore raw

Hi Magnus,

Thank you for the patch.

Quoted 10 lines · On Wednesday 03 July 2013 13:14:32 Magnus Damm wrote:

From: Magnus Damm <[email protected]>

Register the GPIO pin range, and request and free GPIO pins using the pinctrl API. The pctl_name platform data member should be used by platform devices to point out which pinctrl device to use.

Follows same style as "dc3465a gpio-rcar: Add pinctrl support", by Laurent Pinchart, thanks to him.

Linus, now that the v3.12 development cycle will begin, would you like to take the patch through your tree ? If so, how should we handle cross-dependencies between the pinctrl/gpio tree and the Renesas ARM tree ?

include/linux/platform_data/gpio-em.h

Quoted 63 lines

---

 drivers/gpio/gpio-em.c                |   25 +++++++++++++++++++++++++
 include/linux/platform_data/gpio-em.h |    1 +
 2 files changed, 26 insertions(+)
drivers/gpio/gpio-em.c +25 -0
@@ -30,6 +30,7 @@
 #include <linux/gpio.h>
 #include <linux/slab.h>
 #include <linux/module.h>
+#include <linux/pinctrl/consumer.h>
 #include <linux/platform_data/gpio-em.h>
 
 struct em_gio_priv {
@@ -216,6 +217,21 @@ static int em_gio_to_irq(struct gpio_chi
 	return irq_create_mapping(gpio_to_priv(chip)->irq_domain, offset);
 }
 
+static int em_gio_request(struct gpio_chip *chip, unsigned offset)
+{
+	return pinctrl_request_gpio(chip->base + offset);
+}
+
+static void em_gio_free(struct gpio_chip *chip, unsigned offset)
+{
+	pinctrl_free_gpio(chip->base + offset);
+
+	/* Set the GPIO as an input to ensure that the next GPIO request won't
+	* drive the GPIO pin as an output.
+	*/
+	em_gio_direction_input(chip, offset);
+}
+
 static int em_gio_irq_domain_map(struct irq_domain *h, unsigned int virq,
 				 irq_hw_number_t hw)
 {
@@ -308,6 +324,8 @@ static int em_gio_probe(struct platform_
 	gpio_chip->direction_output = em_gio_direction_output;
 	gpio_chip->set = em_gio_set;
 	gpio_chip->to_irq = em_gio_to_irq;
+	gpio_chip->request = em_gio_request;
+	gpio_chip->free = em_gio_free;
 	gpio_chip->label = name;
 	gpio_chip->owner = THIS_MODULE;
 	gpio_chip->base = pdata->gpio_base;
@@ -351,6 +369,13 @@ static int em_gio_probe(struct platform_
 		dev_err(&pdev->dev, "failed to add GPIO controller\n");
 		goto err1;
 	}
+
+	if (pdata->pctl_name) {
+		ret = gpiochip_add_pin_range(gpio_chip, pdata->pctl_name, 0,
+					     gpio_chip->base, gpio_chip->ngpio);
+		if (ret < 0)
+			dev_warn(&pdev->dev, "failed to add pin range\n");
+	}
 	return 0;
 
 err1:
include/linux/platform_data/gpio-em.h +0 -0

12:45:27.000000000

Quoted 8 lines

+0900 @@ -5,6 +5,7 @@ struct gpio_em_config {

include/linux/platform_data/gpio-em.h +1 -0
 	unsigned int gpio_base;
 	unsigned int irq_base;
 	unsigned int number_of_pins;
+	const char *pctl_name;
 };
 
 #endif /* __GPIO_EM_H__ */
Signature · 3 lines
Regards,

Laurent Pinchart
#2 lore raw
Quoted 14 lines · Laurent Pinchart

Hi Magnus,

Thank you for the patch.

Quoted 9 lines · On Wednesday 03 July 2013 13:14:32 Magnus Damm wrote:

From: Magnus Damm <[email protected]>

Register the GPIO pin range, and request and free GPIO pins using the pinctrl API. The pctl_name platform data member should be used by platform devices to point out which pinctrl device to use.

Follows same style as "dc3465a gpio-rcar: Add pinctrl support", by Laurent Pinchart, thanks to him.

Quoted 7 lines
Quoted 1 line

Linus, now that the v3.12 development cycle will begin, would you like to take the patch through your tree ? If so, how should we handle cross-dependencies between the pinctrl/gpio tree and the Renesas ARM tree ?

In the case of this patch I believe that any dependencies that are present in the renesas tree have been merged into the arm-soc tree and thus should appear in v3.11-rcX, where X most likely equals 2 or 3.

That being so v3.11-rcX could be used as a base.

Alternatively its likely that one the renesas-*-for-v3.11 tags in my renesas tree, all of which have been merged into arm-soc and should appear in v3.11-rcX, could be used as a base.

I'm unsure which one as I'm unsure what the dependencies are but I strongly suspect that renesas-gpio-rcar2-for-v3.11 would be a good choice.

Quoted 78 lines

include/linux/platform_data/gpio-em.h

Quoted 64 lines

---

 drivers/gpio/gpio-em.c                |   25 +++++++++++++++++++++++++
 include/linux/platform_data/gpio-em.h |    1 +
 2 files changed, 26 insertions(+)
drivers/gpio/gpio-em.c +25 -0
@@ -30,6 +30,7 @@
 #include <linux/gpio.h>
 #include <linux/slab.h>
 #include <linux/module.h>
+#include <linux/pinctrl/consumer.h>
 #include <linux/platform_data/gpio-em.h>
 
 struct em_gio_priv {
@@ -216,6 +217,21 @@ static int em_gio_to_irq(struct gpio_chi
 	return irq_create_mapping(gpio_to_priv(chip)->irq_domain, offset);
 }
 
+static int em_gio_request(struct gpio_chip *chip, unsigned offset)
+{
+	return pinctrl_request_gpio(chip->base + offset);
+}
+
+static void em_gio_free(struct gpio_chip *chip, unsigned offset)
+{
+	pinctrl_free_gpio(chip->base + offset);
+
+	/* Set the GPIO as an input to ensure that the next GPIO request won't
+	* drive the GPIO pin as an output.
+	*/
+	em_gio_direction_input(chip, offset);
+}
+
 static int em_gio_irq_domain_map(struct irq_domain *h, unsigned int virq,
 				 irq_hw_number_t hw)
 {
@@ -308,6 +324,8 @@ static int em_gio_probe(struct platform_
 	gpio_chip->direction_output = em_gio_direction_output;
 	gpio_chip->set = em_gio_set;
 	gpio_chip->to_irq = em_gio_to_irq;
+	gpio_chip->request = em_gio_request;
+	gpio_chip->free = em_gio_free;
 	gpio_chip->label = name;
 	gpio_chip->owner = THIS_MODULE;
 	gpio_chip->base = pdata->gpio_base;
@@ -351,6 +369,13 @@ static int em_gio_probe(struct platform_
 		dev_err(&pdev->dev, "failed to add GPIO controller\n");
 		goto err1;
 	}
+
+	if (pdata->pctl_name) {
+		ret = gpiochip_add_pin_range(gpio_chip, pdata->pctl_name, 0,
+					     gpio_chip->base, gpio_chip->ngpio);
+		if (ret < 0)
+			dev_warn(&pdev->dev, "failed to add pin range\n");
+	}
 	return 0;
 
 err1:
include/linux/platform_data/gpio-em.h +0 -0

12:45:27.000000000

Quoted 8 lines

+0900 @@ -5,6 +5,7 @@ struct gpio_em_config {

include/linux/platform_data/gpio-em.h +1 -0
 	unsigned int gpio_base;
 	unsigned int irq_base;
 	unsigned int number_of_pins;
+	const char *pctl_name;
 };
 
 #endif /* __GPIO_EM_H__ */
Signature · 3 lines
Regards,

Laurent Pinchart
#3 lore raw

Hi Simon,

Quoted 24 lines · On Thursday 04 July 2013 10:16:02 Simon Horman wrote:
Quoted 10 lines · Laurent Pinchart
Quoted 9 lines · On Wednesday 03 July 2013 13:14:32 Magnus Damm wrote:

From: Magnus Damm <[email protected]>

Register the GPIO pin range, and request and free GPIO pins using the pinctrl API. The pctl_name platform data member should be used by platform devices to point out which pinctrl device to use.

Follows same style as "dc3465a gpio-rcar: Add pinctrl support", by Laurent Pinchart, thanks to him.

Quoted 8 lines
Quoted 1 line

Linus, now that the v3.12 development cycle will begin, would you like to take the patch through your tree ? If so, how should we handle cross-dependencies between the pinctrl/gpio tree and the Renesas ARM tree ?

In the case of this patch I believe that any dependencies that are present in the renesas tree have been merged into the arm-soc tree and thus should appear in v3.11-rcX, where X most likely equals 2 or 3.

Quoted 8 lines

That being so v3.11-rcX could be used as a base.

Alternatively its likely that one the renesas-*-for-v3.11 tags in my renesas tree, all of which have been merged into arm-soc and should appear in v3.11- rcX, could be used as a base.

I'm unsure which one as I'm unsure what the dependencies are but I strongly suspect that renesas-gpio-rcar2-for-v3.11 would be a good choice.

I haven't expressed myself clearly, sorry about that. This particular patch is fine. My point was that it adds a new field to the gpio-em platform data structure. We will thus pretty soon see patches for board code to use that field, so you will need to merge a stable pinctrl branch that includes this patch into your tree.

We may also encounter similar situations in the reverse direction (pinctrl patches that depend on ARM patches) in the future, we should be prepared for that as well.

Quoted 26 lines
Quoted 26 lines
Quoted 26 lines

---

 drivers/gpio/gpio-em.c                |   25 +++++++++++++++++++++++++
 include/linux/platform_data/gpio-em.h |    1 +
 2 files changed, 26 insertions(+)
drivers/gpio/gpio-em.c +1 -0
@@ -30,6 +30,7 @@
 
 #include <linux/gpio.h>
 #include <linux/slab.h>
 #include <linux/module.h>
 
+#include <linux/pinctrl/consumer.h>
 

#include <linux/platform_data/gpio-em.h>

struct em_gio_priv {

drivers/gpio/gpio-em.c +0 -0
@@ -216,6 +217,21 @@ static int em_gio_to_irq(struct gpio_chi
 
 	return irq_create_mapping(gpio_to_priv(chip)->irq_domain, offset);
 
 }
 
Quoted 10 lines
Quoted 10 lines

drivers/gpio/gpio-em.c static int em_gio_to_irq(struct gpio_chi

Quoted 10 lines
drivers/gpio/gpio-em.c +10 -0
+static int em_gio_request(struct gpio_chip *chip, unsigned offset)
+{
+	return pinctrl_request_gpio(chip->base + offset);
+}
+
+static void em_gio_free(struct gpio_chip *chip, unsigned offset)
+{
+	pinctrl_free_gpio(chip->base + offset);
+
+	/* Set the GPIO as an input to ensure that the next GPIO request 

won't

Quoted 60 lines
Quoted 60 lines

include/linux/platform_data/gpio-em.h

Quoted 46 lines
drivers/gpio/gpio-em.c +5 -0
+	* drive the GPIO pin as an output.
+	*/
+	em_gio_direction_input(chip, offset);
+}
+
 

static int em_gio_irq_domain_map(struct irq_domain *h, unsigned int virq,

drivers/gpio/gpio-em.c +2 -0
 				 irq_hw_number_t hw)
 
 {
@@ -308,6 +324,8 @@ static int em_gio_probe(struct platform_
 
 	gpio_chip->direction_output = em_gio_direction_output;
 	gpio_chip->set = em_gio_set;
 	gpio_chip->to_irq = em_gio_to_irq;
 
+	gpio_chip->request = em_gio_request;
+	gpio_chip->free = em_gio_free;
 
drivers/gpio/gpio-em.c +7 -0
 	gpio_chip->label = name;
 	gpio_chip->owner = THIS_MODULE;
 	gpio_chip->base = pdata->gpio_base;
@@ -351,6 +369,13 @@ static int em_gio_probe(struct platform_
 
 		dev_err(&pdev->dev, "failed to add GPIO controller\n");
 		goto err1;
 
 	}
 
+
+	if (pdata->pctl_name) {
+		ret = gpiochip_add_pin_range(gpio_chip, pdata->pctl_name, 0,
+					     gpio_chip->base, gpio_chip->ngpio);
+		if (ret < 0)
+			dev_warn(&pdev->dev, "failed to add pin range\n");
+	}
drivers/gpio/gpio-em.c +0 -0
 	return 0;
 
 err1:
include/linux/platform_data/gpio-em.h +0 -0

12:45:27.000000000

Quoted 11 lines

+0900 @@ -5,6 +5,7 @@ struct gpio_em_config {

include/linux/platform_data/gpio-em.h +1 -0
 	unsigned int gpio_base;
 	unsigned int irq_base;
 	unsigned int number_of_pins;
 
+	const char *pctl_name;
 
 };
 
 #endif /* __GPIO_EM_H__ */
Signature · 3 lines
Regards,

Laurent Pinchart
#4 lore raw
Quoted 42 lines · Laurent Pinchart

Hi Simon,

Quoted 24 lines · On Thursday 04 July 2013 10:16:02 Simon Horman wrote:
Quoted 10 lines · Laurent Pinchart
Quoted 9 lines · On Wednesday 03 July 2013 13:14:32 Magnus Damm wrote:

From: Magnus Damm <[email protected]>

Register the GPIO pin range, and request and free GPIO pins using the pinctrl API. The pctl_name platform data member should be used by platform devices to point out which pinctrl device to use.

Follows same style as "dc3465a gpio-rcar: Add pinctrl support", by Laurent Pinchart, thanks to him.

Quoted 8 lines
Quoted 1 line

Linus, now that the v3.12 development cycle will begin, would you like to take the patch through your tree ? If so, how should we handle cross-dependencies between the pinctrl/gpio tree and the Renesas ARM tree ?

In the case of this patch I believe that any dependencies that are present in the renesas tree have been merged into the arm-soc tree and thus should appear in v3.11-rcX, where X most likely equals 2 or 3.

Quoted 8 lines

That being so v3.11-rcX could be used as a base.

Alternatively its likely that one the renesas-*-for-v3.11 tags in my renesas tree, all of which have been merged into arm-soc and should appear in v3.11- rcX, could be used as a base.

I'm unsure which one as I'm unsure what the dependencies are but I strongly suspect that renesas-gpio-rcar2-for-v3.11 would be a good choice.

I haven't expressed myself clearly, sorry about that. This particular patch is fine. My point was that it adds a new field to the gpio-em platform data structure. We will thus pretty soon see patches for board code to use that field, so you will need to merge a stable pinctrl branch that includes this patch into your tree.

Quoted 3 lines

We may also encounter similar situations in the reverse direction (pinctrl patches that depend on ARM patches) in the future, we should be prepared for that as well.

Thanks, I now understand.

I think that in general there are two approaches that I am comfortable.

1. For Linus to provide a stable branch or tag for me to use as a base.

2. For me to provide Acks and for Linus to take board patches through his tree.

In the reverse case I am happy with the reverse of either of the two options above, though for one of my branches or tags to be stable ideally it would need to have been pulled into arm-soc.

#5 lore raw
In reply to Magnus Damm
Quoted 10 lines · Magnus Damm

From: Magnus Damm <[email protected]>

Register the GPIO pin range, and request and free GPIO pins using the pinctrl API. The pctl_name platform data member should be used by platform devices to point out which pinctrl device to use.

Follows same style as "dc3465a gpio-rcar: Add pinctrl support", by Laurent Pinchart, thanks to him.

Patch applied.

As mentioned, Simon anyway will have a ton of deps on the pinctrl tree so we'll need to stabilize it there and then base subsequent work on shmobile on it.

(Allow some time before I say that anything on devel is stable though.)

Yours,
Linus Walleij