ARM: shmobile: Move gpio ranges from C code to DT

On platforms where the PFC/GPIO controller is instantiated from DT, the mapping between GPIOs and pins is set up using the "gpio-ranges" property in DT.

Hence stop setting up the mapping from C code on DT platforms. This code is still used for SH or ARM-legacy platforms.

Signed-off-by Geert Uytterhoeven <[email protected]>

Acked-by Linus Walleij <[email protected]>

---
v2:
- Add Acked-by,
- Add check for CONFIG_OF and pfc->dev->of_node.

---
 drivers/pinctrl/sh-pfc/gpio.c | 37 ++++++++++++++++++++++---------------
 1 file changed, 22 insertions(+), 15 deletions(-)

drivers/pinctrl/sh-pfc/gpio.c +22 -15

index ba353735ecf2be9a..b380e3f17b121bbb 100644
@@ -379,22 +379,29 @@ int sh_pfc_register_gpiochip(struct sh_pfc *pfc)
 
 	pfc->gpio = chip;
 
-	/* Register the GPIO to pin mappings. As pins with GPIO ports must come
-	 * first in the ranges, skip the pins without GPIO ports by stopping at
-	 * the first range that contains such a pin.
-	 */
-	for (i = 0; i < pfc->nr_ranges; ++i) {
-		const struct sh_pfc_pin_range *range = &pfc->ranges[i];
-
-		if (range->start >= pfc->nr_gpio_pins)
-			break;
+	if (IS_ENABLED(CONFIG_OF) && pfc->dev->of_node)
+		return 0;
 
-		ret = gpiochip_add_pin_range(&chip->gpio_chip,
-					     dev_name(pfc->dev),
-					     range->start, range->start,
-					     range->end - range->start + 1);
-		if (ret < 0)
-			return ret;
+	if (IS_ENABLED(CONFIG_SUPERH) ||
+	    IS_ENABLED(CONFIG_ARCH_SHMOBILE_LEGACY)) {
+		/*
+		 * Register the GPIO to pin mappings. As pins with GPIO ports
+		 * must come first in the ranges, skip the pins without GPIO
+		 * ports by stopping at the first range that contains such a
+		 * pin.
+		 */
+		for (i = 0; i < pfc->nr_ranges; ++i) {
+			const struct sh_pfc_pin_range *range = &pfc->ranges[i];
+
+			if (range->start >= pfc->nr_gpio_pins)
+				break;
+
+			ret = gpiochip_add_pin_range(&chip->gpio_chip,
+				dev_name(pfc->dev), range->start, range->start,
+				range->end - range->start + 1);
+			if (ret < 0)
+				return ret;
+		}
 	}
 
 	/* Register the function GPIOs chip. */

Legacy function GPIOs are no longer used on ARM since commit a27c5cd1a08cc95c ("sh-pfc: sh73a0: Remove function GPIOs"). Extract its setup code into a separate function, and make all function GPIO related code and data depend on CONFIG_SUPERH.

Signed-off-by Geert Uytterhoeven <[email protected]>

Acked-by Linus Walleij <[email protected]>

---
Compile-tested on sh using se7724_defconfig.

v2:
- Add Acked-by,
- #ifdef out the code instead of introducing helper and dummy functions.

---
 drivers/pinctrl/sh-pfc/core.h   | 2 ++
 drivers/pinctrl/sh-pfc/gpio.c   | 7 ++++++-
 drivers/pinctrl/sh-pfc/sh_pfc.h | 2 ++
 3 files changed, 10 insertions(+), 1 deletion(-)

drivers/pinctrl/sh-pfc/core.h +2 -0

index 4c3c37bf7161804d..c38ace46d7111b0d 100644
@@ -46,7 +46,9 @@ struct sh_pfc {
 	unsigned int nr_gpio_pins;
 
 	struct sh_pfc_chip *gpio;
+#ifdef CONFIG_SUPERH
 	struct sh_pfc_chip *func;
+#endif
 
 	struct sh_pfc_pinctrl *pinctrl;
 };

drivers/pinctrl/sh-pfc/gpio.c +6 -3

index e46439030914ad13..685b3c24627daf03 100644
@@ -261,6 +261,7 @@ static int gpio_pin_setup(struct sh_pfc_chip *chip)
  * Function GPIOs
  */
 
+#ifdef CONFIG_SUPERH
 static int gpio_function_request(struct gpio_chip *gc, unsigned offset)
 {
 	static bool __print_once;

@@ -300,6 +301,7 @@ static int gpio_function_setup(struct sh_pfc_chip *chip)
 
 	return 0;
 }
+#endif
 
 /*
---------------------------------------------------------------------------
-- * Register/unregister

@@ -399,6 +401,7 @@ int sh_pfc_register_gpiochip(struct sh_pfc *pfc)
 		}
 	}
 
+#ifdef CONFIG_SUPERH
 	/* Register the function GPIOs chip. */
 	if (pfc->info->nr_func_gpios == 0)
 		return 0;

@@ -408,6 +411,7 @@ int sh_pfc_register_gpiochip(struct sh_pfc *pfc)
 		return PTR_ERR(chip);
 
 	pfc->func = chip;
+#endif /* CONFIG_SUPERH */
 
 	return 0;
 }

@@ -415,7 +419,8 @@ int sh_pfc_register_gpiochip(struct sh_pfc *pfc)
 int sh_pfc_unregister_gpiochip(struct sh_pfc *pfc)
 {
 	gpiochip_remove(&pfc->gpio->gpio_chip);
+#ifdef CONFIG_SUPERH
 	gpiochip_remove(&pfc->func->gpio_chip);
-
+#endif
 	return 0;
 }

(quoted diff) +0 -0

b/drivers/pinctrl/sh-pfc/sh_pfc.h index 0874cfee6889afa1..1f43bae56065e659 100644

drivers/pinctrl/sh-pfc/sh_pfc.h +2 -0

@@ -138,8 +138,10 @@ struct sh_pfc_soc_info {
 	const struct sh_pfc_function *functions;
 	unsigned int nr_functions;
 
+#ifdef CONFIG_SUPERH
 	const struct pinmux_func *func_gpios;
 	unsigned int nr_func_gpios;
+#endif
 
 	const struct pinmux_cfg_reg *cfg_regs;
 	const struct pinmux_data_reg *data_regs;

Hi Simon, Magnus,

This patch series moves the setup of the GPIO-PFC pin mapping for Renesas PFC/GPIO combos from C code to DT, and does some cleanups. The move to DT is needed to make the GPIO hogging mechanism work, cfr. the discussion following "[PATCH] [RFC] gpio: Retry deferred GPIO hogging on pin range change" (https://lkml.org/lkml/2015/6/16/455).

The series consists of 3 parts:
a. Patches 1-3 add the missing "gpio-ranges" properties to the dtsi
files for all affected SoCs,
b. Patch 4 disables the C code to set up the mapping on DT platforms
(it's still needed on SH or ARM-legacy),
c. Patches 5-6 do a few more cleanups in the sh-pfc gpio code.

Changes compared to v1 ("[PATCH 0/7] ARM: shmobile: Move gpio ranges from C code to DT",
http://lists.infradead.org/pipermail/linux-arm-kernel/2015-June/353124.html):
- Add check for CONFIG_OF and pfc->dev->of_node,
- #ifdef out the code instead of introducing helper and dummy functions,
- Drop "pinctrl: sh-pfc: Move sh_pfc_add_gpiochip() up", as it's no longer needed due to the #ifdefs,
- Add Acked-by.

Dependencies:
- This series applies against renesas-devel-20150803-v4.2-rc5,
- Part a must go in first, to avoid regressions,
- While I didn't notice any bad behavior by having part a only, part b should go in immediately after part a. Hence I think it's best if Simon can take this one, too.
- Part c is independent (it doesn't touch the same code), so it can go in before or after the other parts, or in parallel.

Given this fixes the LCD on r8a7740/armadillo, which is a regression introduced by the removal of armadillo-legacy support, I think at least patch 2 should be queued for v4.3.

Thanks for applying!

Geert Uytterhoeven (6):
ARM: shmobile: r8a73a4 dtsi: Add missing "gpio-ranges" to gpio node
ARM: shmobile: r8a7740 dtsi: Add missing "gpio-ranges" to gpio node
ARM: shmobile: sh73a0 dtsi: Add missing "gpio-ranges" to gpio node
pinctrl: sh-pfc: Stop calling gpiochip_add_pin_range() on DT platforms
pinctrl: sh-pfc: Remove empty gpio_function_free()
pinctrl: sh-pfc: Confine legacy function GPIOs to SH

Quoted 38 lines · Geert Uytterhoeven

This patch series moves the setup of the GPIO-PFC pin mapping for Renesas PFC/GPIO combos from C code to DT, and does some cleanups. The move to DT is needed to make the GPIO hogging mechanism work, cfr. the discussion following "[PATCH] [RFC] gpio: Retry deferred GPIO hogging on pin range change" (https://lkml.org/lkml/2015/6/16/455).

The series consists of 3 parts:
a. Patches 1-3 add the missing "gpio-ranges" properties to the dtsi
files for all affected SoCs,
b. Patch 4 disables the C code to set up the mapping on DT platforms
(it's still needed on SH or ARM-legacy),
c. Patches 5-6 do a few more cleanups in the sh-pfc gpio code.

Changes compared to v1 ("[PATCH 0/7] ARM: shmobile: Move gpio ranges from C code to DT",
http://lists.infradead.org/pipermail/linux-arm-kernel/2015-June/353124.html):
- Add check for CONFIG_OF and pfc->dev->of_node,
- #ifdef out the code instead of introducing helper and dummy functions,
- Drop "pinctrl: sh-pfc: Move sh_pfc_add_gpiochip() up", as it's no longer needed due to the #ifdefs,
- Add Acked-by.

Dependencies:
- This series applies against renesas-devel-20150803-v4.2-rc5,
- Part a must go in first, to avoid regressions,
- While I didn't notice any bad behavior by having part a only, part b should go in immediately after part a. Hence I think it's best if Simon can take this one, too.
- Part c is independent (it doesn't touch the same code), so it can go in before or after the other parts, or in parallel.

Given this fixes the LCD on r8a7740/armadillo, which is a regression introduced by the removal of armadillo-legacy support, I think at least patch 2 should be queued for v4.3.

Thanks for applying!

Quoted 7 lines

Geert Uytterhoeven (6):
ARM: shmobile: r8a73a4 dtsi: Add missing "gpio-ranges" to gpio node
ARM: shmobile: r8a7740 dtsi: Add missing "gpio-ranges" to gpio node
ARM: shmobile: sh73a0 dtsi: Add missing "gpio-ranges" to gpio node
pinctrl: sh-pfc: Stop calling gpiochip_add_pin_range() on DT platforms
pinctrl: sh-pfc: Remove empty gpio_function_free()
pinctrl: sh-pfc: Confine legacy function GPIOs to SH

Where possible I prefer not to apply non-DTS/DTSI patches on top of DTS/DTSI patches, I believe this is in keeping with how the ARM SoC

maintainers like things handled. With this in mind I have done the following:

1. Queued up the DTSI patches (patches 1 - 3) for v4.3 in my dt branch. I intend for this to turn up in next soon.
2. Queued up for pinctrl patches (patches 4 - 6) for v4.4 in a pinctrl patch. I intend for these to be present in the renesas devel branch but not in next until after the release of v4.3-rc1. I would also be happy to drop them and let Linus Walleij take these patches for v4.4, assuming patches 1 - 3 are accepted for v4.3.

Where possible I prefer not to apply non-DTS/DTSI patches on top of DTS/DTSI patches, I believe this is in keeping with how the ARM SoC maintainers like things handled. With this in mind I have done the following:

1. Queued up the DTSI patches (patches 1 - 3) for v4.3 in my dt branch. I intend for this to turn up in next soon.
2. Queued up for pinctrl patches (patches 4 - 6) for v4.4 in a pinctrl patch. I intend for these to be present in the renesas devel branch but not in next until after the release of v4.3-rc1. I would also be happy to drop them and let Linus Walleij take these patches for v4.4, assuming patches 1 - 3 are accepted for v4.3.

Quoted 11 lines · Simon Horman

Where possible I prefer not to apply non-DTS/DTSI patches on top of DTS/DTSI patches, I believe this is in keeping with how the ARM SoC maintainers like things handled. With this in mind I have done the following:

1. Queued up the DTSI patches (patches 1 - 3) for v4.3 in my dt branch. I intend for this to turn up in next soon.
2. Queued up for pinctrl patches (patches 4 - 6) for v4.4 in a pinctrl patch. I intend for these to be present in the renesas devel branch but not in next until after the release of v4.3-rc1. I would also be happy to drop them and let Linus Walleij take these patches for v4.4, assuming patches 1 - 3 are accepted for v4.3.

OK.

Will the world explode if I try to queue the pinctrl patches 4-6 in my tree now for v4.3? Then I prefer to defer to v4.4. Else I can merge it in parallel?

Hi Linus,

Quoted 13 lines · Linus Walleij

Quoted 11 lines · Simon Horman

Where possible I prefer not to apply non-DTS/DTSI patches on top of DTS/DTSI patches, I believe this is in keeping with how the ARM SoC maintainers like things handled. With this in mind I have done the following:

1. Queued up the DTSI patches (patches 1 - 3) for v4.3 in my dt branch. I intend for this to turn up in next soon.
2. Queued up for pinctrl patches (patches 4 - 6) for v4.4 in a pinctrl patch. I intend for these to be present in the renesas devel branch but not in next until after the release of v4.3-rc1. I would also be happy to drop them and let Linus Walleij take these patches for v4.4, assuming patches 1 - 3 are accepted for v4.3.

Quoted 5 lines

OK.

Will the world explode if I try to queue the pinctrl patches 4-6 in my tree now for v4.3? Then I prefer to defer to v4.4. Else I can merge it in parallel?

There won't be a mapping between gpio and pins in any branch having the pinctrl changes but not the dtsi changes.

Quoted 20 lines · Geert Uytterhoeven

Quoted 18 lines · Linus Walleij

Quoted 11 lines · Simon Horman

Where possible I prefer not to apply non-DTS/DTSI patches on top of DTS/DTSI patches, I believe this is in keeping with how the ARM SoC maintainers like things handled. With this in mind I have done the following:

1. Queued up the DTSI patches (patches 1 - 3) for v4.3 in my dt branch. I intend for this to turn up in next soon.
2. Queued up for pinctrl patches (patches 4 - 6) for v4.4 in a pinctrl patch. I intend for these to be present in the renesas devel branch but not in next until after the release of v4.3-rc1. I would also be happy to drop them and let Linus Walleij take these patches for v4.4, assuming patches 1 - 3 are accepted for v4.3.

OK.

Will the world explode if I try to queue the pinctrl patches 4-6 in my tree now for v4.3? Then I prefer to defer to v4.4. Else I can merge it in parallel?

Quoted 2 lines

There won't be a mapping between gpio and pins in any branch having the pinctrl changes but not the dtsi changes.

It sounds to me that Linus should take his option 2; defer to v4.4. In which case I should drop the changes from my tree (they are not in next anyway). Please let me know if thats the way we will move this forwards.

Quoted 21 lines · Simon Horman

Quoted 20 lines · Geert Uytterhoeven

Quoted 18 lines · Linus Walleij

Quoted 11 lines · Simon Horman

Where possible I prefer not to apply non-DTS/DTSI patches on top of DTS/DTSI patches, I believe this is in keeping with how the ARM SoC maintainers like things handled. With this in mind I have done the following:

1. Queued up the DTSI patches (patches 1 - 3) for v4.3 in my dt branch. I intend for this to turn up in next soon.
2. Queued up for pinctrl patches (patches 4 - 6) for v4.4 in a pinctrl patch. I intend for these to be present in the renesas devel branch but not in next until after the release of v4.3-rc1. I would also be happy to drop them and let Linus Walleij take these patches for v4.4, assuming patches 1 - 3 are accepted for v4.3.

OK.

Will the world explode if I try to queue the pinctrl patches 4-6 in my tree now for v4.3? Then I prefer to defer to v4.4. Else I can merge it in parallel?

Quoted 6 lines

Quoted 2 lines

There won't be a mapping between gpio and pins in any branch having the pinctrl changes but not the dtsi changes.

It sounds to me that Linus should take his option 2; defer to v4.4. In which case I should drop the changes from my tree (they are not in next anyway). Please let me know if thats the way we will move this forwards.

Sounds fine to me.

And in the unlikely event we discover regressions in v4.3-rc1 due to having the dtsi changes without the pinctrl changes, we can still fast-track them into v4.3-rc2.

Quoted 31 lines · Geert Uytterhoeven

Quoted 21 lines · Simon Horman

Quoted 20 lines · Geert Uytterhoeven

Quoted 18 lines · Linus Walleij

Quoted 11 lines · Simon Horman

Where possible I prefer not to apply non-DTS/DTSI patches on top of DTS/DTSI patches, I believe this is in keeping with how the ARM SoC maintainers like things handled. With this in mind I have done the following:

1. Queued up the DTSI patches (patches 1 - 3) for v4.3 in my dt branch. I intend for this to turn up in next soon.
2. Queued up for pinctrl patches (patches 4 - 6) for v4.4 in a pinctrl patch. I intend for these to be present in the renesas devel branch but not in next until after the release of v4.3-rc1. I would also be happy to drop them and let Linus Walleij take these patches for v4.4, assuming patches 1 - 3 are accepted for v4.3.

OK.

Will the world explode if I try to queue the pinctrl patches 4-6 in my tree now for v4.3? Then I prefer to defer to v4.4. Else I can merge it in parallel?

Quoted 6 lines

Quoted 2 lines

There won't be a mapping between gpio and pins in any branch having the pinctrl changes but not the dtsi changes.

It sounds to me that Linus should take his option 2; defer to v4.4. In which case I should drop the changes from my tree (they are not in next anyway). Please let me know if thats the way we will move this forwards.

Sounds fine to me.

Quoted 3 lines

And in the unlikely event we discover regressions in v4.3-rc1 due to having the dtsi changes without the pinctrl changes, we can still fast-track them into v4.3-rc2.

Sounds like a plan.

Hit me on the head about this once v4.3-rc1 is out!