ARM: shmobile: Move gpio ranges from C code to DT
Subsystems (4)
v2 cover ARM: shmobile: Move gpio ranges from C code to DT
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
arch/arm/boot/dts/r8a73a4.dtsi | 7 ++++++ arch/arm/boot/dts/r8a7740.dtsi | 1 + arch/arm/boot/dts/sh73a0.dtsi | 3 +++ drivers/pinctrl/sh-pfc/core.h | 2 ++ drivers/pinctrl/sh-pfc/gpio.c | 49 +++++++++++++++++++++++------------------ drivers/pinctrl/sh-pfc/sh_pfc.h | 2 ++ 6 files changed, 43 insertions(+), 21 deletions(-)
Signature · 12 lines
1.9.1
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus TorvaldsPATCH v2 1/6 ARM: shmobile: r8a73a4 dtsi: Add missing "gpio-ranges" to gpio node
If a GPIO driver uses gpiochip_add_pin_range() (which is usually the case for GPIO/PFC combos), the GPIO hogging mechanism configured from DT doesn't work:
requesting hog GPIO led1-high (chip r8a73a4_pfc, offset 28) failed
The actual error code is -517 == -EPROBE_DEFER.
The problem is that PFC+GPIO registration is handled in multiple steps:
1. pinctrl_register(),
2. gpiochip_add(),
3. gpiochip_add_pin_range().
Configuration of the hogs is handled in gpiochip_add():
gpiochip_add
of_gpiochip_add
of_gpiochip_scan_hogs
gpiod_hog
gpiochip_request_own_desc
__gpiod_request
chip->request
pinctrl_request_gpio
pinctrl_get_device_gpio_rangeHowever, at this point the GPIO controller hasn't been added to pinctrldev_list yet, so the range can't be found, and the operation fails with -EPROBE_DEFER.
To fix this, add a "gpio-ranges" property to the gpio device node, so the ranges are added by of_gpiochip_add_pin_range(), which is called by of_gpiochip_add() before the call to of_gpiochip_scan_hogs().
---
v2:
- Add Acked-by.
--- arch/arm/boot/dts/r8a73a4.dtsi | 7 +++++++ 1 file changed, 7 insertions(+)
arch/arm/boot/dts/r8a73a4.dtsi +7 -0
@@ -207,6 +207,13 @@ reg = <0 0xe6050000 0 0x9000>; gpio-controller; #gpio-cells = <2>; + gpio-ranges = + <&pfc 0 0 31>, <&pfc 32 32 9>, + <&pfc 64 64 22>, <&pfc 96 96 31>, + <&pfc 128 128 7>, <&pfc 160 160 19>, + <&pfc 192 192 31>, <&pfc 224 224 27>, + <&pfc 256 256 28>, <&pfc 288 288 21>, + <&pfc 320 320 10>; interrupts-extended = <&irqc0 0 0>, <&irqc0 1 0>, <&irqc0 2 0>, <&irqc0 3 0>, <&irqc0 4 0>, <&irqc0 5 0>, <&irqc0 6 0>, <&irqc0 7 0>,
Signature · 1 line
1.9.1
PATCH v2 2/6 ARM: shmobile: r8a7740 dtsi: Add missing "gpio-ranges" to gpio node
In reply to Geert UytterhoevenIf a GPIO driver uses gpiochip_add_pin_range() (which is usually the case for GPIO/PFC combos), the GPIO hogging mechanism configured from DT doesn't work:
requesting hog GPIO lcd0 (chip r8a7740_pfc, offset 176) failed
The actual error code is -517 == -EPROBE_DEFER.
The problem is that PFC+GPIO registration is handled in multiple steps:
1. pinctrl_register(),
2. gpiochip_add(),
3. gpiochip_add_pin_range().
Configuration of the hogs is handled in gpiochip_add():
gpiochip_add
of_gpiochip_add
of_gpiochip_scan_hogs
gpiod_hog
gpiochip_request_own_desc
__gpiod_request
chip->request
pinctrl_request_gpio
pinctrl_get_device_gpio_rangeHowever, at this point the GPIO controller hasn't been added to pinctrldev_list yet, so the range can't be found, and the operation fails with -EPROBE_DEFER.
To fix this, add a "gpio-ranges" property to the gpio device node, so the range is added by of_gpiochip_add_pin_range(), which is called by of_gpiochip_add() before the call to of_gpiochip_scan_hogs().
---
v2:
- Add Acked-by.
--- arch/arm/boot/dts/r8a7740.dtsi | 1 + 1 file changed, 1 insertion(+)
arch/arm/boot/dts/r8a7740.dtsi +1 -0
@@ -291,6 +291,7 @@ <0xe605800c 0x20>; gpio-controller; #gpio-cells = <2>; + gpio-ranges = <&pfc 0 0 212>; interrupts-extended = <&irqpin0 0 0>, <&irqpin0 1 0>, <&irqpin0 2 0>, <&irqpin0 3 0>, <&irqpin0 4 0>, <&irqpin0 5 0>, <&irqpin0 6 0>, <&irqpin0 7 0>,
Signature · 1 line
1.9.1
PATCH v2 3/6 ARM: shmobile: sh73a0 dtsi: Add missing "gpio-ranges" to gpio node
In reply to Geert UytterhoevenIf a GPIO driver uses gpiochip_add_pin_range() (which is usually the case for GPIO/PFC combos), the GPIO hogging mechanism configured from DT doesn't work:
requesting hog GPIO led1-high (chip sh73a0_pfc, offset 20) failed
The actual error code is -517 == -EPROBE_DEFER.
The problem is that PFC+GPIO registration is handled in multiple steps:
1. pinctrl_register(),
2. gpiochip_add(),
3. gpiochip_add_pin_range().
Configuration of the hogs is handled in gpiochip_add():
gpiochip_add
of_gpiochip_add
of_gpiochip_scan_hogs
gpiod_hog
gpiochip_request_own_desc
__gpiod_request
chip->request
pinctrl_request_gpio
pinctrl_get_device_gpio_rangeHowever, at this point the GPIO controller hasn't been added to pinctrldev_list yet, so the range can't be found, and the operation fails with -EPROBE_DEFER.
To fix this, add a "gpio-ranges" property to the gpio device node, so the ranges are added by of_gpiochip_add_pin_range(), which is called by of_gpiochip_add() before the call to of_gpiochip_scan_hogs().
---
v2:
- Add Acked-by.
--- arch/arm/boot/dts/sh73a0.dtsi | 3 +++ 1 file changed, 3 insertions(+)
arch/arm/boot/dts/sh73a0.dtsi +3 -0
@@ -392,6 +392,9 @@ <0xe605801c 0x1c>; gpio-controller; #gpio-cells = <2>; + gpio-ranges = + <&pfc 0 0 119>, <&pfc 128 128 37>, <&pfc 192 192 91>, + <&pfc 288 288 22>; interrupts-extended = <&irqpin0 0 0>, <&irqpin0 1 0>, <&irqpin0 2 0>, <&irqpin0 3 0>, <&irqpin0 4 0>, <&irqpin0 5 0>, <&irqpin0 6 0>, <&irqpin0 7 0>,
Signature · 1 line
1.9.1
PATCH v2 4/6 pinctrl: sh-pfc: Stop calling gpiochip_add_pin_range() on DT platforms
In reply to Geert UytterhoevenOn 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.
---
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
@@ -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@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. */
Signature · 1 line
1.9.1
PATCH v2 4/6 pinctrl: sh-pfc: Stop calling gpiochip_add_pin_range() on DT platforms
Hi Geert,
Thank you for the patch.
Quoted 9 lines · On Tuesday 04 August 2015 15:55:17 Geert Uytterhoeven wrote:
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]>
Quoted 57 lines
---
v2:
- Add Acked-by,
- Add check forCONFIG_OFandpfc->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@@ -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. */
Signature · 3 lines
Regards, Laurent Pinchart
PATCH v2 5/6 pinctrl: sh-pfc: Remove empty gpio_function_free()
In reply to Geert Uytterhoevengpio_chip.free() is optional, and can just be left unimplemented.
---
Untested due to lack of hardware (used on sh only).
v2:
- Add Acked-by.
--- drivers/pinctrl/sh-pfc/gpio.c | 5 ----- 1 file changed, 5 deletions(-)
drivers/pinctrl/sh-pfc/gpio.c +0 -5
@@ -286,17 +286,12 @@ static int gpio_function_request(struct gpio_chip *gc, unsigned offset)return ret; } -static void gpio_function_free (struct gpio_chip *gc,unsigned offset) -{ -} -static int gpio_function_setup (struct sh_pfc_chip *chip) {struct sh_pfc *pfc = chip->pfc;struct gpio_chip *gc = &chip->gpio_chip; gc->request = gpio_function_request; - gc->free = gpio_function_free; gc->label = pfc->info->name; gc->owner =THIS_MODULE ;
Signature · 1 line
1.9.1
PATCH v2 6/6 pinctrl: sh-pfc: Confine legacy function GPIOs to SH
In reply to Geert UytterhoevenLegacy 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.
---
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
@@ -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 -1
@@ -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 ; }
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;
Signature · 1 line
1.9.1
PATCH v2 6/6 pinctrl: sh-pfc: Confine legacy function GPIOs to SH
Hi Geert,
Thank you for the patch.
Quoted 7 lines · On Tuesday 04 August 2015 15:55:19 Geert Uytterhoeven wrote:
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 onCONFIG_SUPERH.Signed-off-by Geert Uytterhoeven <[email protected]>Acked-by Linus Walleij <[email protected]>
We now need a volunteer to port SH to proper pinctrl to remove the function GPIOs completely :-)
Quoted 90 lines
---
Compile-tested on sh usingse7724_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@@ -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@@ -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.hindex0874cfee6889afa1..1f43bae56065e659100644drivers/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;
Signature · 3 lines
Regards, Laurent Pinchart
v2 cover ARM: shmobile: Move gpio ranges from C code to DT
In reply to Geert UytterhoevenHi Geert,
Quoted 40 lines · Geert Uytterhoeven
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 forCONFIG_OFandpfc->dev->of_node,
- #ifdef out the code instead of introducing helper and dummy functions,
- Drop "pinctrl: sh-pfc: Movesh_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 callinggpiochip_add_pin_range()on DT platforms
pinctrl: sh-pfc: Remove emptygpio_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.
v2 cover ARM: shmobile: Move gpio ranges from C code to DT
Hi Simon,
Quoted 47 lines · Simon Horman
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 forCONFIG_OFandpfc->dev->of_node,
- #ifdef out the code instead of introducing helper and dummy functions,
- Drop "pinctrl: sh-pfc: Movesh_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 callinggpiochip_add_pin_range()on DT platforms
pinctrl: sh-pfc: Remove emptygpio_function_free()
pinctrl: sh-pfc: Confine legacy function GPIOs to SH
Quoted 2 lines
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
Ugh, that means I have to put a few more DT patches in my queue on the fast track...
Quoted 9 lines
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.
Thanks, that sounds fine to me!
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
v2 cover ARM: shmobile: Move gpio ranges from C code to DT
In reply to Simon HormanQuoted 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?
Yours,
Linus Walleij
v2 cover ARM: shmobile: Move gpio ranges from C code to DT
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.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
v2 cover ARM: shmobile: Move gpio ranges from C code to DT
Quoted 16 lines · Geert Uytterhoeven
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 8 lines
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.
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.
v2 cover ARM: shmobile: Move gpio ranges from C code to DT
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.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
v2 cover ARM: shmobile: Move gpio ranges from C code to DT
Quoted 29 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.
Quoted 5 lines
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.
Sounds like a plan.
Hit me on the head about this once v4.3-rc1 is out!
Yours,
Linus Walleij
v2 cover ARM: shmobile: Move gpio ranges from C code to DT
Quoted 33 lines · Linus Walleij
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 7 lines
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!
Thanks, I will drop the patches from my tree.