* [PATCH] ARM: dts: imx28: add gpio-ranges for internal gpio controller
@ 2017-05-08 8:59 ` Uwe Kleine-König
0 siblings, 0 replies; 16+ messages in thread
From: Uwe Kleine-König @ 2017-05-08 8:59 UTC (permalink / raw)
To: Shawn Guo, Linus Walleij
Cc: linux-arm-kernel, linux-gpio, kernel, Fabio Estevam
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
---
Hello,
with this patch applied I get the following lines in dmesg which looks
fine:
[ 0.227913] gpio gpiochip0: (80018000.pinctrl:gpio@0): created GPIO range 0->31 ==> 80018000.pinctrl PIN 0->31
[ 0.236100] gpio gpiochip1: (80018000.pinctrl:gpio@1): created GPIO range 0->31 ==> 80018000.pinctrl PIN 32->63
[ 0.244463] gpio gpiochip2: (80018000.pinctrl:gpio@2): created GPIO range 0->31 ==> 80018000.pinctrl PIN 64->95
[ 0.253020] gpio gpiochip3: (80018000.pinctrl:gpio@3): created GPIO range 0->31 ==> 80018000.pinctrl PIN 96->127
[ 0.261639] gpio gpiochip4: (80018000.pinctrl:gpio@4): created GPIO range 0->31 ==> 80018000.pinctrl PIN 128->159
But when looking at a used gpio
# cat /sys/kernel/debug/gpio
gpiochip0: GPIOs 0-31, parent: platform/80018000.pinctrl:gpio@0, 80018000.pinctrl:gpio@0:
...
gpio-20 (LED4 |? ) out hi
...
# grep "pin 20 " /sys/kernel/debug/pinctrl/80018000.pinctrl/pinmux-pins
pin 20 (GPMI_RDY0): leds (GPIO UNCLAIMED) function leds group leds.0
I wonder why there is still "GPIO UNCLAIMED". I would have expected that
this disappears and somehow references the gpio_request issued by the
led-gpio driver after my patch.
What am I missing?
Best regards
Uwe
arch/arm/boot/dts/imx28.dtsi | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/arch/arm/boot/dts/imx28.dtsi b/arch/arm/boot/dts/imx28.dtsi
index 148fcf4d3b98..cfad2295cc46 100644
--- a/arch/arm/boot/dts/imx28.dtsi
+++ b/arch/arm/boot/dts/imx28.dtsi
@@ -182,6 +182,7 @@
#gpio-cells = <2>;
interrupt-controller;
#interrupt-cells = <2>;
+ gpio-ranges = <&pinctrl 0 0 32>;
};
gpio1: gpio@1 {
@@ -192,6 +193,7 @@
#gpio-cells = <2>;
interrupt-controller;
#interrupt-cells = <2>;
+ gpio-ranges = <&pinctrl 0 32 32>;
};
gpio2: gpio@2 {
@@ -202,6 +204,7 @@
#gpio-cells = <2>;
interrupt-controller;
#interrupt-cells = <2>;
+ gpio-ranges = <&pinctrl 0 64 32>;
};
gpio3: gpio@3 {
@@ -212,6 +215,7 @@
#gpio-cells = <2>;
interrupt-controller;
#interrupt-cells = <2>;
+ gpio-ranges = <&pinctrl 0 96 32>;
};
gpio4: gpio@4 {
@@ -222,6 +226,7 @@
#gpio-cells = <2>;
interrupt-controller;
#interrupt-cells = <2>;
+ gpio-ranges = <&pinctrl 0 128 32>;
};
duart_pins_a: duart@0 {
--
2.11.0
^ permalink raw reply related [flat|nested] 16+ messages in thread* [PATCH] ARM: dts: imx28: add gpio-ranges for internal gpio controller
@ 2017-05-08 8:59 ` Uwe Kleine-König
0 siblings, 0 replies; 16+ messages in thread
From: Uwe Kleine-König @ 2017-05-08 8:59 UTC (permalink / raw)
To: linux-arm-kernel
Signed-off-by: Uwe Kleine-K?nig <u.kleine-koenig@pengutronix.de>
---
Hello,
with this patch applied I get the following lines in dmesg which looks
fine:
[ 0.227913] gpio gpiochip0: (80018000.pinctrl:gpio at 0): created GPIO range 0->31 ==> 80018000.pinctrl PIN 0->31
[ 0.236100] gpio gpiochip1: (80018000.pinctrl:gpio at 1): created GPIO range 0->31 ==> 80018000.pinctrl PIN 32->63
[ 0.244463] gpio gpiochip2: (80018000.pinctrl:gpio at 2): created GPIO range 0->31 ==> 80018000.pinctrl PIN 64->95
[ 0.253020] gpio gpiochip3: (80018000.pinctrl:gpio at 3): created GPIO range 0->31 ==> 80018000.pinctrl PIN 96->127
[ 0.261639] gpio gpiochip4: (80018000.pinctrl:gpio at 4): created GPIO range 0->31 ==> 80018000.pinctrl PIN 128->159
But when looking at a used gpio
# cat /sys/kernel/debug/gpio
gpiochip0: GPIOs 0-31, parent: platform/80018000.pinctrl:gpio at 0, 80018000.pinctrl:gpio at 0:
...
gpio-20 (LED4 |? ) out hi
...
# grep "pin 20 " /sys/kernel/debug/pinctrl/80018000.pinctrl/pinmux-pins
pin 20 (GPMI_RDY0): leds (GPIO UNCLAIMED) function leds group leds.0
I wonder why there is still "GPIO UNCLAIMED". I would have expected that
this disappears and somehow references the gpio_request issued by the
led-gpio driver after my patch.
What am I missing?
Best regards
Uwe
arch/arm/boot/dts/imx28.dtsi | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/arch/arm/boot/dts/imx28.dtsi b/arch/arm/boot/dts/imx28.dtsi
index 148fcf4d3b98..cfad2295cc46 100644
--- a/arch/arm/boot/dts/imx28.dtsi
+++ b/arch/arm/boot/dts/imx28.dtsi
@@ -182,6 +182,7 @@
#gpio-cells = <2>;
interrupt-controller;
#interrupt-cells = <2>;
+ gpio-ranges = <&pinctrl 0 0 32>;
};
gpio1: gpio at 1 {
@@ -192,6 +193,7 @@
#gpio-cells = <2>;
interrupt-controller;
#interrupt-cells = <2>;
+ gpio-ranges = <&pinctrl 0 32 32>;
};
gpio2: gpio at 2 {
@@ -202,6 +204,7 @@
#gpio-cells = <2>;
interrupt-controller;
#interrupt-cells = <2>;
+ gpio-ranges = <&pinctrl 0 64 32>;
};
gpio3: gpio at 3 {
@@ -212,6 +215,7 @@
#gpio-cells = <2>;
interrupt-controller;
#interrupt-cells = <2>;
+ gpio-ranges = <&pinctrl 0 96 32>;
};
gpio4: gpio at 4 {
@@ -222,6 +226,7 @@
#gpio-cells = <2>;
interrupt-controller;
#interrupt-cells = <2>;
+ gpio-ranges = <&pinctrl 0 128 32>;
};
duart_pins_a: duart at 0 {
--
2.11.0
^ permalink raw reply related [flat|nested] 16+ messages in thread* Re: [PATCH] ARM: dts: imx28: add gpio-ranges for internal gpio controller
2017-05-08 8:59 ` Uwe Kleine-König
@ 2017-05-11 7:51 ` Shawn Guo
-1 siblings, 0 replies; 16+ messages in thread
From: Shawn Guo @ 2017-05-11 7:51 UTC (permalink / raw)
To: Uwe Kleine-König
Cc: Linus Walleij, linux-arm-kernel, linux-gpio, kernel, Fabio Estevam
On Mon, May 08, 2017 at 10:59:25AM +0200, Uwe Kleine-König wrote:
> Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
> ---
> Hello,
>
> with this patch applied I get the following lines in dmesg which looks
> fine:
>
> [ 0.227913] gpio gpiochip0: (80018000.pinctrl:gpio@0): created GPIO range 0->31 ==> 80018000.pinctrl PIN 0->31
> [ 0.236100] gpio gpiochip1: (80018000.pinctrl:gpio@1): created GPIO range 0->31 ==> 80018000.pinctrl PIN 32->63
> [ 0.244463] gpio gpiochip2: (80018000.pinctrl:gpio@2): created GPIO range 0->31 ==> 80018000.pinctrl PIN 64->95
> [ 0.253020] gpio gpiochip3: (80018000.pinctrl:gpio@3): created GPIO range 0->31 ==> 80018000.pinctrl PIN 96->127
> [ 0.261639] gpio gpiochip4: (80018000.pinctrl:gpio@4): created GPIO range 0->31 ==> 80018000.pinctrl PIN 128->159
>
> But when looking at a used gpio
>
> # cat /sys/kernel/debug/gpio
> gpiochip0: GPIOs 0-31, parent: platform/80018000.pinctrl:gpio@0, 80018000.pinctrl:gpio@0:
> ...
> gpio-20 (LED4 |? ) out hi
> ...
>
> # grep "pin 20 " /sys/kernel/debug/pinctrl/80018000.pinctrl/pinmux-pins
> pin 20 (GPMI_RDY0): leds (GPIO UNCLAIMED) function leds group leds.0
>
> I wonder why there is still "GPIO UNCLAIMED". I would have expected that
> this disappears and somehow references the gpio_request issued by the
> led-gpio driver after my patch.
>
> What am I missing?
It seems that's only the case where @strict of struct pinmux_ops is
true. We should set it true for pinctrl-mxs, I guess?
Shawn
>
> Best regards
> Uwe
>
> arch/arm/boot/dts/imx28.dtsi | 5 +++++
> 1 file changed, 5 insertions(+)
>
> diff --git a/arch/arm/boot/dts/imx28.dtsi b/arch/arm/boot/dts/imx28.dtsi
> index 148fcf4d3b98..cfad2295cc46 100644
> --- a/arch/arm/boot/dts/imx28.dtsi
> +++ b/arch/arm/boot/dts/imx28.dtsi
> @@ -182,6 +182,7 @@
> #gpio-cells = <2>;
> interrupt-controller;
> #interrupt-cells = <2>;
> + gpio-ranges = <&pinctrl 0 0 32>;
> };
>
> gpio1: gpio@1 {
> @@ -192,6 +193,7 @@
> #gpio-cells = <2>;
> interrupt-controller;
> #interrupt-cells = <2>;
> + gpio-ranges = <&pinctrl 0 32 32>;
> };
>
> gpio2: gpio@2 {
> @@ -202,6 +204,7 @@
> #gpio-cells = <2>;
> interrupt-controller;
> #interrupt-cells = <2>;
> + gpio-ranges = <&pinctrl 0 64 32>;
> };
>
> gpio3: gpio@3 {
> @@ -212,6 +215,7 @@
> #gpio-cells = <2>;
> interrupt-controller;
> #interrupt-cells = <2>;
> + gpio-ranges = <&pinctrl 0 96 32>;
> };
>
> gpio4: gpio@4 {
> @@ -222,6 +226,7 @@
> #gpio-cells = <2>;
> interrupt-controller;
> #interrupt-cells = <2>;
> + gpio-ranges = <&pinctrl 0 128 32>;
> };
>
> duart_pins_a: duart@0 {
> --
> 2.11.0
>
^ permalink raw reply [flat|nested] 16+ messages in thread* [PATCH] ARM: dts: imx28: add gpio-ranges for internal gpio controller
@ 2017-05-11 7:51 ` Shawn Guo
0 siblings, 0 replies; 16+ messages in thread
From: Shawn Guo @ 2017-05-11 7:51 UTC (permalink / raw)
To: linux-arm-kernel
On Mon, May 08, 2017 at 10:59:25AM +0200, Uwe Kleine-K?nig wrote:
> Signed-off-by: Uwe Kleine-K?nig <u.kleine-koenig@pengutronix.de>
> ---
> Hello,
>
> with this patch applied I get the following lines in dmesg which looks
> fine:
>
> [ 0.227913] gpio gpiochip0: (80018000.pinctrl:gpio at 0): created GPIO range 0->31 ==> 80018000.pinctrl PIN 0->31
> [ 0.236100] gpio gpiochip1: (80018000.pinctrl:gpio at 1): created GPIO range 0->31 ==> 80018000.pinctrl PIN 32->63
> [ 0.244463] gpio gpiochip2: (80018000.pinctrl:gpio at 2): created GPIO range 0->31 ==> 80018000.pinctrl PIN 64->95
> [ 0.253020] gpio gpiochip3: (80018000.pinctrl:gpio at 3): created GPIO range 0->31 ==> 80018000.pinctrl PIN 96->127
> [ 0.261639] gpio gpiochip4: (80018000.pinctrl:gpio at 4): created GPIO range 0->31 ==> 80018000.pinctrl PIN 128->159
>
> But when looking at a used gpio
>
> # cat /sys/kernel/debug/gpio
> gpiochip0: GPIOs 0-31, parent: platform/80018000.pinctrl:gpio at 0, 80018000.pinctrl:gpio at 0:
> ...
> gpio-20 (LED4 |? ) out hi
> ...
>
> # grep "pin 20 " /sys/kernel/debug/pinctrl/80018000.pinctrl/pinmux-pins
> pin 20 (GPMI_RDY0): leds (GPIO UNCLAIMED) function leds group leds.0
>
> I wonder why there is still "GPIO UNCLAIMED". I would have expected that
> this disappears and somehow references the gpio_request issued by the
> led-gpio driver after my patch.
>
> What am I missing?
It seems that's only the case where @strict of struct pinmux_ops is
true. We should set it true for pinctrl-mxs, I guess?
Shawn
>
> Best regards
> Uwe
>
> arch/arm/boot/dts/imx28.dtsi | 5 +++++
> 1 file changed, 5 insertions(+)
>
> diff --git a/arch/arm/boot/dts/imx28.dtsi b/arch/arm/boot/dts/imx28.dtsi
> index 148fcf4d3b98..cfad2295cc46 100644
> --- a/arch/arm/boot/dts/imx28.dtsi
> +++ b/arch/arm/boot/dts/imx28.dtsi
> @@ -182,6 +182,7 @@
> #gpio-cells = <2>;
> interrupt-controller;
> #interrupt-cells = <2>;
> + gpio-ranges = <&pinctrl 0 0 32>;
> };
>
> gpio1: gpio at 1 {
> @@ -192,6 +193,7 @@
> #gpio-cells = <2>;
> interrupt-controller;
> #interrupt-cells = <2>;
> + gpio-ranges = <&pinctrl 0 32 32>;
> };
>
> gpio2: gpio at 2 {
> @@ -202,6 +204,7 @@
> #gpio-cells = <2>;
> interrupt-controller;
> #interrupt-cells = <2>;
> + gpio-ranges = <&pinctrl 0 64 32>;
> };
>
> gpio3: gpio at 3 {
> @@ -212,6 +215,7 @@
> #gpio-cells = <2>;
> interrupt-controller;
> #interrupt-cells = <2>;
> + gpio-ranges = <&pinctrl 0 96 32>;
> };
>
> gpio4: gpio at 4 {
> @@ -222,6 +226,7 @@
> #gpio-cells = <2>;
> interrupt-controller;
> #interrupt-cells = <2>;
> + gpio-ranges = <&pinctrl 0 128 32>;
> };
>
> duart_pins_a: duart at 0 {
> --
> 2.11.0
>
^ permalink raw reply [flat|nested] 16+ messages in thread* Re: [PATCH] ARM: dts: imx28: add gpio-ranges for internal gpio controller
2017-05-11 7:51 ` Shawn Guo
@ 2017-05-11 8:09 ` Uwe Kleine-König
-1 siblings, 0 replies; 16+ messages in thread
From: Uwe Kleine-König @ 2017-05-11 8:09 UTC (permalink / raw)
To: Shawn Guo
Cc: Fabio Estevam, linux-gpio, Linus Walleij, kernel, linux-arm-kernel
On Thu, May 11, 2017 at 03:51:36PM +0800, Shawn Guo wrote:
> On Mon, May 08, 2017 at 10:59:25AM +0200, Uwe Kleine-König wrote:
> > Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
> > ---
> > Hello,
> >
> > with this patch applied I get the following lines in dmesg which looks
> > fine:
> >
> > [ 0.227913] gpio gpiochip0: (80018000.pinctrl:gpio@0): created GPIO range 0->31 ==> 80018000.pinctrl PIN 0->31
> > [ 0.236100] gpio gpiochip1: (80018000.pinctrl:gpio@1): created GPIO range 0->31 ==> 80018000.pinctrl PIN 32->63
> > [ 0.244463] gpio gpiochip2: (80018000.pinctrl:gpio@2): created GPIO range 0->31 ==> 80018000.pinctrl PIN 64->95
> > [ 0.253020] gpio gpiochip3: (80018000.pinctrl:gpio@3): created GPIO range 0->31 ==> 80018000.pinctrl PIN 96->127
> > [ 0.261639] gpio gpiochip4: (80018000.pinctrl:gpio@4): created GPIO range 0->31 ==> 80018000.pinctrl PIN 128->159
> >
> > But when looking at a used gpio
> >
> > # cat /sys/kernel/debug/gpio
> > gpiochip0: GPIOs 0-31, parent: platform/80018000.pinctrl:gpio@0, 80018000.pinctrl:gpio@0:
> > ...
> > gpio-20 (LED4 |? ) out hi
> > ...
> >
> > # grep "pin 20 " /sys/kernel/debug/pinctrl/80018000.pinctrl/pinmux-pins
> > pin 20 (GPMI_RDY0): leds (GPIO UNCLAIMED) function leds group leds.0
> >
> > I wonder why there is still "GPIO UNCLAIMED". I would have expected that
> > this disappears and somehow references the gpio_request issued by the
> > led-gpio driver after my patch.
> >
> > What am I missing?
>
> It seems that's only the case where @strict of struct pinmux_ops is
> true. We should set it true for pinctrl-mxs, I guess?
The description is:
* @strict: do not allow simultaneous use of the same pin for GPIO and another
* function. Check both gpio_owner and mux_owner strictly before approving
* the pin request.
so if I understand correctly that means that if a device has configured the pin
MX28_PAD_SSP2_SCK as function SSP2_SCK it's impossible to do gpio_request on
<&gpio2 16> (which is the matching GPIO)? I don't like that. My use case for
exactly this is that I want the MX28_PAD_SSP2_SCK pin to be high-Z when the spi
bus is not in use. I do this as follows:
&ssp2 {
pinctrl-names = "default", "idle";
pinctrl-0 = <&spi2_pins_a>;
pinctrl-1 = <&spi2_pins_a_gpio>;
...
};
where spi2_pins_a_gpio includes MX28_PAD_SSP2_SCK__GPIO_2_16, and then
&gpio2 {
ssp2_sck {
gpio-hog;
gpio = <16 0>;
input;
};
...
};
. So I think strict is a bad idea, not only for pinctrl-mxs.
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-König |
Industrial Linux Solutions | http://www.pengutronix.de/ |
^ permalink raw reply [flat|nested] 16+ messages in thread* [PATCH] ARM: dts: imx28: add gpio-ranges for internal gpio controller
@ 2017-05-11 8:09 ` Uwe Kleine-König
0 siblings, 0 replies; 16+ messages in thread
From: Uwe Kleine-König @ 2017-05-11 8:09 UTC (permalink / raw)
To: linux-arm-kernel
On Thu, May 11, 2017 at 03:51:36PM +0800, Shawn Guo wrote:
> On Mon, May 08, 2017 at 10:59:25AM +0200, Uwe Kleine-K?nig wrote:
> > Signed-off-by: Uwe Kleine-K?nig <u.kleine-koenig@pengutronix.de>
> > ---
> > Hello,
> >
> > with this patch applied I get the following lines in dmesg which looks
> > fine:
> >
> > [ 0.227913] gpio gpiochip0: (80018000.pinctrl:gpio at 0): created GPIO range 0->31 ==> 80018000.pinctrl PIN 0->31
> > [ 0.236100] gpio gpiochip1: (80018000.pinctrl:gpio at 1): created GPIO range 0->31 ==> 80018000.pinctrl PIN 32->63
> > [ 0.244463] gpio gpiochip2: (80018000.pinctrl:gpio at 2): created GPIO range 0->31 ==> 80018000.pinctrl PIN 64->95
> > [ 0.253020] gpio gpiochip3: (80018000.pinctrl:gpio at 3): created GPIO range 0->31 ==> 80018000.pinctrl PIN 96->127
> > [ 0.261639] gpio gpiochip4: (80018000.pinctrl:gpio at 4): created GPIO range 0->31 ==> 80018000.pinctrl PIN 128->159
> >
> > But when looking at a used gpio
> >
> > # cat /sys/kernel/debug/gpio
> > gpiochip0: GPIOs 0-31, parent: platform/80018000.pinctrl:gpio at 0, 80018000.pinctrl:gpio at 0:
> > ...
> > gpio-20 (LED4 |? ) out hi
> > ...
> >
> > # grep "pin 20 " /sys/kernel/debug/pinctrl/80018000.pinctrl/pinmux-pins
> > pin 20 (GPMI_RDY0): leds (GPIO UNCLAIMED) function leds group leds.0
> >
> > I wonder why there is still "GPIO UNCLAIMED". I would have expected that
> > this disappears and somehow references the gpio_request issued by the
> > led-gpio driver after my patch.
> >
> > What am I missing?
>
> It seems that's only the case where @strict of struct pinmux_ops is
> true. We should set it true for pinctrl-mxs, I guess?
The description is:
* @strict: do not allow simultaneous use of the same pin for GPIO and another
* function. Check both gpio_owner and mux_owner strictly before approving
* the pin request.
so if I understand correctly that means that if a device has configured the pin
MX28_PAD_SSP2_SCK as function SSP2_SCK it's impossible to do gpio_request on
<&gpio2 16> (which is the matching GPIO)? I don't like that. My use case for
exactly this is that I want the MX28_PAD_SSP2_SCK pin to be high-Z when the spi
bus is not in use. I do this as follows:
&ssp2 {
pinctrl-names = "default", "idle";
pinctrl-0 = <&spi2_pins_a>;
pinctrl-1 = <&spi2_pins_a_gpio>;
...
};
where spi2_pins_a_gpio includes MX28_PAD_SSP2_SCK__GPIO_2_16, and then
&gpio2 {
ssp2_sck {
gpio-hog;
gpio = <16 0>;
input;
};
...
};
. So I think strict is a bad idea, not only for pinctrl-mxs.
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-K?nig |
Industrial Linux Solutions | http://www.pengutronix.de/ |
^ permalink raw reply [flat|nested] 16+ messages in thread* Re: [PATCH] ARM: dts: imx28: add gpio-ranges for internal gpio controller
2017-05-11 8:09 ` Uwe Kleine-König
@ 2017-05-12 3:05 ` Shawn Guo
-1 siblings, 0 replies; 16+ messages in thread
From: Shawn Guo @ 2017-05-12 3:05 UTC (permalink / raw)
To: Uwe Kleine-König
Cc: Fabio Estevam, linux-gpio, Linus Walleij, kernel, linux-arm-kernel
On Thu, May 11, 2017 at 10:09:16AM +0200, Uwe Kleine-König wrote:
> On Thu, May 11, 2017 at 03:51:36PM +0800, Shawn Guo wrote:
> > On Mon, May 08, 2017 at 10:59:25AM +0200, Uwe Kleine-König wrote:
> > > Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
> > > ---
> > > Hello,
> > >
> > > with this patch applied I get the following lines in dmesg which looks
> > > fine:
> > >
> > > [ 0.227913] gpio gpiochip0: (80018000.pinctrl:gpio@0): created GPIO range 0->31 ==> 80018000.pinctrl PIN 0->31
> > > [ 0.236100] gpio gpiochip1: (80018000.pinctrl:gpio@1): created GPIO range 0->31 ==> 80018000.pinctrl PIN 32->63
> > > [ 0.244463] gpio gpiochip2: (80018000.pinctrl:gpio@2): created GPIO range 0->31 ==> 80018000.pinctrl PIN 64->95
> > > [ 0.253020] gpio gpiochip3: (80018000.pinctrl:gpio@3): created GPIO range 0->31 ==> 80018000.pinctrl PIN 96->127
> > > [ 0.261639] gpio gpiochip4: (80018000.pinctrl:gpio@4): created GPIO range 0->31 ==> 80018000.pinctrl PIN 128->159
> > >
> > > But when looking at a used gpio
> > >
> > > # cat /sys/kernel/debug/gpio
> > > gpiochip0: GPIOs 0-31, parent: platform/80018000.pinctrl:gpio@0, 80018000.pinctrl:gpio@0:
> > > ...
> > > gpio-20 (LED4 |? ) out hi
> > > ...
> > >
> > > # grep "pin 20 " /sys/kernel/debug/pinctrl/80018000.pinctrl/pinmux-pins
> > > pin 20 (GPMI_RDY0): leds (GPIO UNCLAIMED) function leds group leds.0
> > >
> > > I wonder why there is still "GPIO UNCLAIMED". I would have expected that
> > > this disappears and somehow references the gpio_request issued by the
> > > led-gpio driver after my patch.
> > >
> > > What am I missing?
> >
> > It seems that's only the case where @strict of struct pinmux_ops is
> > true. We should set it true for pinctrl-mxs, I guess?
>
> The description is:
>
> * @strict: do not allow simultaneous use of the same pin for GPIO and another
> * function. Check both gpio_owner and mux_owner strictly before approving
> * the pin request.
Sorry, I misread the 'strict' code and my comment about it is
completely a noise.
I went through the code around requesting a pin, and found that we need
to call pinctrl_request_gpio() from gpio driver to get the result you
want. In that case, pin_request() will be called with a valid
gpio_range as below.
pinctrl_request_gpio()
pinmux_request_gpio()
pin_request(..., gpio_range)
Right now, pin_request() is being called with a NULL gpio_range from
pinmux_enable_setting(). That gets us the mux_owner rather than
gpio_owner for the pin.
Shawn
^ permalink raw reply [flat|nested] 16+ messages in thread* [PATCH] ARM: dts: imx28: add gpio-ranges for internal gpio controller
@ 2017-05-12 3:05 ` Shawn Guo
0 siblings, 0 replies; 16+ messages in thread
From: Shawn Guo @ 2017-05-12 3:05 UTC (permalink / raw)
To: linux-arm-kernel
On Thu, May 11, 2017 at 10:09:16AM +0200, Uwe Kleine-K?nig wrote:
> On Thu, May 11, 2017 at 03:51:36PM +0800, Shawn Guo wrote:
> > On Mon, May 08, 2017 at 10:59:25AM +0200, Uwe Kleine-K?nig wrote:
> > > Signed-off-by: Uwe Kleine-K?nig <u.kleine-koenig@pengutronix.de>
> > > ---
> > > Hello,
> > >
> > > with this patch applied I get the following lines in dmesg which looks
> > > fine:
> > >
> > > [ 0.227913] gpio gpiochip0: (80018000.pinctrl:gpio at 0): created GPIO range 0->31 ==> 80018000.pinctrl PIN 0->31
> > > [ 0.236100] gpio gpiochip1: (80018000.pinctrl:gpio at 1): created GPIO range 0->31 ==> 80018000.pinctrl PIN 32->63
> > > [ 0.244463] gpio gpiochip2: (80018000.pinctrl:gpio at 2): created GPIO range 0->31 ==> 80018000.pinctrl PIN 64->95
> > > [ 0.253020] gpio gpiochip3: (80018000.pinctrl:gpio at 3): created GPIO range 0->31 ==> 80018000.pinctrl PIN 96->127
> > > [ 0.261639] gpio gpiochip4: (80018000.pinctrl:gpio at 4): created GPIO range 0->31 ==> 80018000.pinctrl PIN 128->159
> > >
> > > But when looking at a used gpio
> > >
> > > # cat /sys/kernel/debug/gpio
> > > gpiochip0: GPIOs 0-31, parent: platform/80018000.pinctrl:gpio at 0, 80018000.pinctrl:gpio at 0:
> > > ...
> > > gpio-20 (LED4 |? ) out hi
> > > ...
> > >
> > > # grep "pin 20 " /sys/kernel/debug/pinctrl/80018000.pinctrl/pinmux-pins
> > > pin 20 (GPMI_RDY0): leds (GPIO UNCLAIMED) function leds group leds.0
> > >
> > > I wonder why there is still "GPIO UNCLAIMED". I would have expected that
> > > this disappears and somehow references the gpio_request issued by the
> > > led-gpio driver after my patch.
> > >
> > > What am I missing?
> >
> > It seems that's only the case where @strict of struct pinmux_ops is
> > true. We should set it true for pinctrl-mxs, I guess?
>
> The description is:
>
> * @strict: do not allow simultaneous use of the same pin for GPIO and another
> * function. Check both gpio_owner and mux_owner strictly before approving
> * the pin request.
Sorry, I misread the 'strict' code and my comment about it is
completely a noise.
I went through the code around requesting a pin, and found that we need
to call pinctrl_request_gpio() from gpio driver to get the result you
want. In that case, pin_request() will be called with a valid
gpio_range as below.
pinctrl_request_gpio()
pinmux_request_gpio()
pin_request(..., gpio_range)
Right now, pin_request() is being called with a NULL gpio_range from
pinmux_enable_setting(). That gets us the mux_owner rather than
gpio_owner for the pin.
Shawn
^ permalink raw reply [flat|nested] 16+ messages in thread* Re: [PATCH] ARM: dts: imx28: add gpio-ranges for internal gpio controller
2017-05-12 3:05 ` Shawn Guo
@ 2017-05-12 8:01 ` Uwe Kleine-König
-1 siblings, 0 replies; 16+ messages in thread
From: Uwe Kleine-König @ 2017-05-12 8:01 UTC (permalink / raw)
To: Shawn Guo
Cc: Fabio Estevam, linux-gpio, Linus Walleij, linux-arm-kernel, kernel
On Fri, May 12, 2017 at 11:05:38AM +0800, Shawn Guo wrote:
> On Thu, May 11, 2017 at 10:09:16AM +0200, Uwe Kleine-König wrote:
> > On Thu, May 11, 2017 at 03:51:36PM +0800, Shawn Guo wrote:
> > > On Mon, May 08, 2017 at 10:59:25AM +0200, Uwe Kleine-König wrote:
> > > > Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
> > > > ---
> > > > Hello,
> > > >
> > > > with this patch applied I get the following lines in dmesg which looks
> > > > fine:
> > > >
> > > > [ 0.227913] gpio gpiochip0: (80018000.pinctrl:gpio@0): created GPIO range 0->31 ==> 80018000.pinctrl PIN 0->31
> > > > [ 0.236100] gpio gpiochip1: (80018000.pinctrl:gpio@1): created GPIO range 0->31 ==> 80018000.pinctrl PIN 32->63
> > > > [ 0.244463] gpio gpiochip2: (80018000.pinctrl:gpio@2): created GPIO range 0->31 ==> 80018000.pinctrl PIN 64->95
> > > > [ 0.253020] gpio gpiochip3: (80018000.pinctrl:gpio@3): created GPIO range 0->31 ==> 80018000.pinctrl PIN 96->127
> > > > [ 0.261639] gpio gpiochip4: (80018000.pinctrl:gpio@4): created GPIO range 0->31 ==> 80018000.pinctrl PIN 128->159
> > > >
> > > > But when looking at a used gpio
> > > >
> > > > # cat /sys/kernel/debug/gpio
> > > > gpiochip0: GPIOs 0-31, parent: platform/80018000.pinctrl:gpio@0, 80018000.pinctrl:gpio@0:
> > > > ...
> > > > gpio-20 (LED4 |? ) out hi
> > > > ...
> > > >
> > > > # grep "pin 20 " /sys/kernel/debug/pinctrl/80018000.pinctrl/pinmux-pins
> > > > pin 20 (GPMI_RDY0): leds (GPIO UNCLAIMED) function leds group leds.0
> > > >
> > > > I wonder why there is still "GPIO UNCLAIMED". I would have expected that
> > > > this disappears and somehow references the gpio_request issued by the
> > > > led-gpio driver after my patch.
> > > >
> > > > What am I missing?
> > >
> > > It seems that's only the case where @strict of struct pinmux_ops is
> > > true. We should set it true for pinctrl-mxs, I guess?
> >
> > The description is:
> >
> > * @strict: do not allow simultaneous use of the same pin for GPIO and another
> > * function. Check both gpio_owner and mux_owner strictly before approving
> > * the pin request.
>
> Sorry, I misread the 'strict' code and my comment about it is
> completely a noise.
>
> I went through the code around requesting a pin, and found that we need
> to call pinctrl_request_gpio() from gpio driver to get the result you
> want. In that case, pin_request() will be called with a valid
> gpio_range as below.
>
> pinctrl_request_gpio()
> pinmux_request_gpio()
> pin_request(..., gpio_range)
>
> Right now, pin_request() is being called with a NULL gpio_range from
> pinmux_enable_setting(). That gets us the mux_owner rather than
> gpio_owner for the pin.
But then again I cannot mux a pin to a different function when the gpio
is requested, right?
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-König |
Industrial Linux Solutions | http://www.pengutronix.de/ |
^ permalink raw reply [flat|nested] 16+ messages in thread
* [PATCH] ARM: dts: imx28: add gpio-ranges for internal gpio controller
@ 2017-05-12 8:01 ` Uwe Kleine-König
0 siblings, 0 replies; 16+ messages in thread
From: Uwe Kleine-König @ 2017-05-12 8:01 UTC (permalink / raw)
To: linux-arm-kernel
On Fri, May 12, 2017 at 11:05:38AM +0800, Shawn Guo wrote:
> On Thu, May 11, 2017 at 10:09:16AM +0200, Uwe Kleine-K?nig wrote:
> > On Thu, May 11, 2017 at 03:51:36PM +0800, Shawn Guo wrote:
> > > On Mon, May 08, 2017 at 10:59:25AM +0200, Uwe Kleine-K?nig wrote:
> > > > Signed-off-by: Uwe Kleine-K?nig <u.kleine-koenig@pengutronix.de>
> > > > ---
> > > > Hello,
> > > >
> > > > with this patch applied I get the following lines in dmesg which looks
> > > > fine:
> > > >
> > > > [ 0.227913] gpio gpiochip0: (80018000.pinctrl:gpio at 0): created GPIO range 0->31 ==> 80018000.pinctrl PIN 0->31
> > > > [ 0.236100] gpio gpiochip1: (80018000.pinctrl:gpio at 1): created GPIO range 0->31 ==> 80018000.pinctrl PIN 32->63
> > > > [ 0.244463] gpio gpiochip2: (80018000.pinctrl:gpio at 2): created GPIO range 0->31 ==> 80018000.pinctrl PIN 64->95
> > > > [ 0.253020] gpio gpiochip3: (80018000.pinctrl:gpio at 3): created GPIO range 0->31 ==> 80018000.pinctrl PIN 96->127
> > > > [ 0.261639] gpio gpiochip4: (80018000.pinctrl:gpio at 4): created GPIO range 0->31 ==> 80018000.pinctrl PIN 128->159
> > > >
> > > > But when looking at a used gpio
> > > >
> > > > # cat /sys/kernel/debug/gpio
> > > > gpiochip0: GPIOs 0-31, parent: platform/80018000.pinctrl:gpio at 0, 80018000.pinctrl:gpio at 0:
> > > > ...
> > > > gpio-20 (LED4 |? ) out hi
> > > > ...
> > > >
> > > > # grep "pin 20 " /sys/kernel/debug/pinctrl/80018000.pinctrl/pinmux-pins
> > > > pin 20 (GPMI_RDY0): leds (GPIO UNCLAIMED) function leds group leds.0
> > > >
> > > > I wonder why there is still "GPIO UNCLAIMED". I would have expected that
> > > > this disappears and somehow references the gpio_request issued by the
> > > > led-gpio driver after my patch.
> > > >
> > > > What am I missing?
> > >
> > > It seems that's only the case where @strict of struct pinmux_ops is
> > > true. We should set it true for pinctrl-mxs, I guess?
> >
> > The description is:
> >
> > * @strict: do not allow simultaneous use of the same pin for GPIO and another
> > * function. Check both gpio_owner and mux_owner strictly before approving
> > * the pin request.
>
> Sorry, I misread the 'strict' code and my comment about it is
> completely a noise.
>
> I went through the code around requesting a pin, and found that we need
> to call pinctrl_request_gpio() from gpio driver to get the result you
> want. In that case, pin_request() will be called with a valid
> gpio_range as below.
>
> pinctrl_request_gpio()
> pinmux_request_gpio()
> pin_request(..., gpio_range)
>
> Right now, pin_request() is being called with a NULL gpio_range from
> pinmux_enable_setting(). That gets us the mux_owner rather than
> gpio_owner for the pin.
But then again I cannot mux a pin to a different function when the gpio
is requested, right?
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-K?nig |
Industrial Linux Solutions | http://www.pengutronix.de/ |
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [PATCH] ARM: dts: imx28: add gpio-ranges for internal gpio controller
2017-05-12 8:01 ` Uwe Kleine-König
@ 2017-05-15 2:21 ` Shawn Guo
-1 siblings, 0 replies; 16+ messages in thread
From: Shawn Guo @ 2017-05-15 2:21 UTC (permalink / raw)
To: Uwe Kleine-König
Cc: Fabio Estevam, linux-gpio, Linus Walleij, kernel, linux-arm-kernel
On Fri, May 12, 2017 at 10:01:50AM +0200, Uwe Kleine-König wrote:
> On Fri, May 12, 2017 at 11:05:38AM +0800, Shawn Guo wrote:
> > I went through the code around requesting a pin, and found that we need
> > to call pinctrl_request_gpio() from gpio driver to get the result you
> > want. In that case, pin_request() will be called with a valid
> > gpio_range as below.
> >
> > pinctrl_request_gpio()
> > pinmux_request_gpio()
> > pin_request(..., gpio_range)
> >
> > Right now, pin_request() is being called with a NULL gpio_range from
> > pinmux_enable_setting(). That gets us the mux_owner rather than
> > gpio_owner for the pin.
>
> But then again I cannot mux a pin to a different function when the gpio
> is requested, right?
You will need to free the GPIO before muxing it to a different function,
I think.
Shawn
^ permalink raw reply [flat|nested] 16+ messages in thread
* [PATCH] ARM: dts: imx28: add gpio-ranges for internal gpio controller
@ 2017-05-15 2:21 ` Shawn Guo
0 siblings, 0 replies; 16+ messages in thread
From: Shawn Guo @ 2017-05-15 2:21 UTC (permalink / raw)
To: linux-arm-kernel
On Fri, May 12, 2017 at 10:01:50AM +0200, Uwe Kleine-K?nig wrote:
> On Fri, May 12, 2017 at 11:05:38AM +0800, Shawn Guo wrote:
> > I went through the code around requesting a pin, and found that we need
> > to call pinctrl_request_gpio() from gpio driver to get the result you
> > want. In that case, pin_request() will be called with a valid
> > gpio_range as below.
> >
> > pinctrl_request_gpio()
> > pinmux_request_gpio()
> > pin_request(..., gpio_range)
> >
> > Right now, pin_request() is being called with a NULL gpio_range from
> > pinmux_enable_setting(). That gets us the mux_owner rather than
> > gpio_owner for the pin.
>
> But then again I cannot mux a pin to a different function when the gpio
> is requested, right?
You will need to free the GPIO before muxing it to a different function,
I think.
Shawn
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [PATCH] ARM: dts: imx28: add gpio-ranges for internal gpio controller
2017-05-15 2:21 ` Shawn Guo
@ 2017-05-15 7:16 ` Uwe Kleine-König
-1 siblings, 0 replies; 16+ messages in thread
From: Uwe Kleine-König @ 2017-05-15 7:16 UTC (permalink / raw)
To: Shawn Guo
Cc: Fabio Estevam, linux-gpio, Linus Walleij, linux-arm-kernel, kernel
Hello Shawn,
On Mon, May 15, 2017 at 10:21:30AM +0800, Shawn Guo wrote:
> On Fri, May 12, 2017 at 10:01:50AM +0200, Uwe Kleine-König wrote:
> > On Fri, May 12, 2017 at 11:05:38AM +0800, Shawn Guo wrote:
> > > I went through the code around requesting a pin, and found that we need
> > > to call pinctrl_request_gpio() from gpio driver to get the result you
> > > want. In that case, pin_request() will be called with a valid
> > > gpio_range as below.
> > >
> > > pinctrl_request_gpio()
> > > pinmux_request_gpio()
> > > pin_request(..., gpio_range)
> > >
> > > Right now, pin_request() is being called with a NULL gpio_range from
> > > pinmux_enable_setting(). That gets us the mux_owner rather than
> > > gpio_owner for the pin.
> >
> > But then again I cannot mux a pin to a different function when the gpio
> > is requested, right?
(Actually I intended to postpone this mail, but sent it instead by
accident.)
> You will need to free the GPIO before muxing it to a different function,
> I think.
IMHO this is a bad concept. This makes GPIOs more special than for
example PWMs or LEDs. And it breaks some configurations (for example the
make-pins-highz-on-idle setup in my previous mails).
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-König |
Industrial Linux Solutions | http://www.pengutronix.de/ |
^ permalink raw reply [flat|nested] 16+ messages in thread
* [PATCH] ARM: dts: imx28: add gpio-ranges for internal gpio controller
@ 2017-05-15 7:16 ` Uwe Kleine-König
0 siblings, 0 replies; 16+ messages in thread
From: Uwe Kleine-König @ 2017-05-15 7:16 UTC (permalink / raw)
To: linux-arm-kernel
Hello Shawn,
On Mon, May 15, 2017 at 10:21:30AM +0800, Shawn Guo wrote:
> On Fri, May 12, 2017 at 10:01:50AM +0200, Uwe Kleine-K?nig wrote:
> > On Fri, May 12, 2017 at 11:05:38AM +0800, Shawn Guo wrote:
> > > I went through the code around requesting a pin, and found that we need
> > > to call pinctrl_request_gpio() from gpio driver to get the result you
> > > want. In that case, pin_request() will be called with a valid
> > > gpio_range as below.
> > >
> > > pinctrl_request_gpio()
> > > pinmux_request_gpio()
> > > pin_request(..., gpio_range)
> > >
> > > Right now, pin_request() is being called with a NULL gpio_range from
> > > pinmux_enable_setting(). That gets us the mux_owner rather than
> > > gpio_owner for the pin.
> >
> > But then again I cannot mux a pin to a different function when the gpio
> > is requested, right?
(Actually I intended to postpone this mail, but sent it instead by
accident.)
> You will need to free the GPIO before muxing it to a different function,
> I think.
IMHO this is a bad concept. This makes GPIOs more special than for
example PWMs or LEDs. And it breaks some configurations (for example the
make-pins-highz-on-idle setup in my previous mails).
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-K?nig |
Industrial Linux Solutions | http://www.pengutronix.de/ |
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [PATCH] ARM: dts: imx28: add gpio-ranges for internal gpio controller
2017-05-15 7:16 ` Uwe Kleine-König
@ 2017-05-22 15:54 ` Linus Walleij
-1 siblings, 0 replies; 16+ messages in thread
From: Linus Walleij @ 2017-05-22 15:54 UTC (permalink / raw)
To: Uwe Kleine-König
Cc: Shawn Guo, Fabio Estevam, linux-gpio, linux-arm-kernel, Sascha Hauer
On Mon, May 15, 2017 at 9:16 AM, Uwe Kleine-König
<u.kleine-koenig@pengutronix.de> wrote:
> On Mon, May 15, 2017 at 10:21:30AM +0800, Shawn Guo wrote:
>> You will need to free the GPIO before muxing it to a different function,
>> I think.
>
> IMHO this is a bad concept. This makes GPIOs more special than for
> example PWMs or LEDs. And it breaks some configurations (for example the
> make-pins-highz-on-idle setup in my previous mails).
So this is the reason why pin controllers can choose to be strict
or not: people disagree on the semantics.
But it's good if the driver maintainers agree for a certain driver :D
Yours,
Linus Walleij
^ permalink raw reply [flat|nested] 16+ messages in thread
* [PATCH] ARM: dts: imx28: add gpio-ranges for internal gpio controller
@ 2017-05-22 15:54 ` Linus Walleij
0 siblings, 0 replies; 16+ messages in thread
From: Linus Walleij @ 2017-05-22 15:54 UTC (permalink / raw)
To: linux-arm-kernel
On Mon, May 15, 2017 at 9:16 AM, Uwe Kleine-K?nig
<u.kleine-koenig@pengutronix.de> wrote:
> On Mon, May 15, 2017 at 10:21:30AM +0800, Shawn Guo wrote:
>> You will need to free the GPIO before muxing it to a different function,
>> I think.
>
> IMHO this is a bad concept. This makes GPIOs more special than for
> example PWMs or LEDs. And it breaks some configurations (for example the
> make-pins-highz-on-idle setup in my previous mails).
So this is the reason why pin controllers can choose to be strict
or not: people disagree on the semantics.
But it's good if the driver maintainers agree for a certain driver :D
Yours,
Linus Walleij
^ permalink raw reply [flat|nested] 16+ messages in thread
end of thread, other threads:[~2017-05-22 15:55 UTC | newest]
Thread overview: 16+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2017-05-08 8:59 [PATCH] ARM: dts: imx28: add gpio-ranges for internal gpio controller Uwe Kleine-König
2017-05-08 8:59 ` Uwe Kleine-König
2017-05-11 7:51 ` Shawn Guo
2017-05-11 7:51 ` Shawn Guo
2017-05-11 8:09 ` Uwe Kleine-König
2017-05-11 8:09 ` Uwe Kleine-König
2017-05-12 3:05 ` Shawn Guo
2017-05-12 3:05 ` Shawn Guo
2017-05-12 8:01 ` Uwe Kleine-König
2017-05-12 8:01 ` Uwe Kleine-König
2017-05-15 2:21 ` Shawn Guo
2017-05-15 2:21 ` Shawn Guo
2017-05-15 7:16 ` Uwe Kleine-König
2017-05-15 7:16 ` Uwe Kleine-König
2017-05-22 15:54 ` Linus Walleij
2017-05-22 15:54 ` Linus Walleij
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.