[PATCH 0/5] BCM2835 pinctrl DT rework (resend)

[PATCH 0/5] BCM2835 pinctrl DT rework (resend)

[Eric Anholt]

Here's a series for cleaning up the pinctrl groups on BCM2835
(Raspberry Pi).  This was partially inspired by Stefan Wahren's
patches for the EMMC SDHCI controller, but really triggered by needing
to switch pinmuxes to enable the SDHOST SD controller (which gives me
a 60% read speed improvement).  Patches for adding that driver will
follow.

I think this is more or less how pinctrl is expected to be used for a
platform like this.  It certainly cleans up the board files.

This is a resend because only 3 came through last time.  My former
SMTP relay decided to start rejecting half my mails this week.  I've
now swapped systems.

Eric Anholt (5):
  ARM: bcm2835: Define standard pinctrl groups in the gpio node.
  ARM: bcm2835: Replace alt0/i2s_alt[02] with standard groups.
  ARM: bcm2835: Move the emmc pin group to bcm283x.dtsi.
  ARM: bcm2835: Add a group for mapping pins 48-53 to sdhost.
  ARM: bcm2835: Move most RPi default pin groups to their devices.

 arch/arm/boot/dts/bcm2835-rpi-a-plus.dts |  11 +-
 arch/arm/boot/dts/bcm2835-rpi-a.dts      |  11 +-
 arch/arm/boot/dts/bcm2835-rpi-b-plus.dts |  11 +-
 arch/arm/boot/dts/bcm2835-rpi-b-rev2.dts |  11 +-
 arch/arm/boot/dts/bcm2835-rpi-b.dts      |   4 -
 arch/arm/boot/dts/bcm2835-rpi.dtsi       |  30 ++++--
 arch/arm/boot/dts/bcm2836-rpi-2-b.dts    |  11 +-
 arch/arm/boot/dts/bcm283x.dtsi           | 178 +++++++++++++++++++++++++++++++
 8 files changed, 213 insertions(+), 54 deletions(-)

-- 
2.7.0

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 0/5] BCM2835 pinctrl DT rework (resend)

[Eric Anholt]

Here's a series for cleaning up the pinctrl groups on BCM2835
(Raspberry Pi).  This was partially inspired by Stefan Wahren's
patches for the EMMC SDHCI controller, but really triggered by needing
to switch pinmuxes to enable the SDHOST SD controller (which gives me
a 60% read speed improvement).  Patches for adding that driver will
follow.

I think this is more or less how pinctrl is expected to be used for a
platform like this.  It certainly cleans up the board files.

This is a resend because only 3 came through last time.  My former
SMTP relay decided to start rejecting half my mails this week.  I've
now swapped systems.

Eric Anholt (5):
  ARM: bcm2835: Define standard pinctrl groups in the gpio node.
  ARM: bcm2835: Replace alt0/i2s_alt[02] with standard groups.
  ARM: bcm2835: Move the emmc pin group to bcm283x.dtsi.
  ARM: bcm2835: Add a group for mapping pins 48-53 to sdhost.
  ARM: bcm2835: Move most RPi default pin groups to their devices.

 arch/arm/boot/dts/bcm2835-rpi-a-plus.dts |  11 +-
 arch/arm/boot/dts/bcm2835-rpi-a.dts      |  11 +-
 arch/arm/boot/dts/bcm2835-rpi-b-plus.dts |  11 +-
 arch/arm/boot/dts/bcm2835-rpi-b-rev2.dts |  11 +-
 arch/arm/boot/dts/bcm2835-rpi-b.dts      |   4 -
 arch/arm/boot/dts/bcm2835-rpi.dtsi       |  30 ++++--
 arch/arm/boot/dts/bcm2836-rpi-2-b.dts    |  11 +-
 arch/arm/boot/dts/bcm283x.dtsi           | 178 +++++++++++++++++++++++++++++++
 8 files changed, 213 insertions(+), 54 deletions(-)

-- 
2.7.0

[PATCH 1/5] ARM: bcm2835: Define standard pinctrl groups in the gpio node.

[Eric Anholt]

The BCM2835-ARM-Peripherals.pdf documentation specifies what the
function selects do for the pins, and there are a bunch of obvious
groupings to be made.  With these created, we'll be able to replace
bcm2835-rpi.dtsi's main "set all of these pins to alt0" with
references to specific groups we want enabled.

Signed-off-by: Eric Anholt <eric@anholt.net>
---
 arch/arm/boot/dts/bcm283x.dtsi | 170 +++++++++++++++++++++++++++++++++++++++++
 1 file changed, 170 insertions(+)

diff --git a/arch/arm/boot/dts/bcm283x.dtsi b/arch/arm/boot/dts/bcm283x.dtsi
index 8aaf193..e91198e 100644
--- a/arch/arm/boot/dts/bcm283x.dtsi
+++ b/arch/arm/boot/dts/bcm283x.dtsi
@@ -110,6 +110,176 @@
 
 			interrupt-controller;
 			#interrupt-cells = <2>;
+
+			/* Defines pin muxing groups according to
+			 * BCM2835-ARM-Peripherals.pdf page 102.
+			 *
+			 * While each pin can have its mux selected
+			 * for various functions individually, some
+			 * groups only make sense to switch to a
+			 * particular function together.
+			 */
+			i2c0_gpio0: i2c0_gpio0 {
+				brcm,pins = <0 1>;
+				brcm,function = <BCM2835_FSEL_ALT0>;
+			};
+			i2c1_gpio2: i2c1_gpio2 {
+				brcm,pins = <2 3>;
+				brcm,function = <BCM2835_FSEL_ALT0>;
+			};
+			gpclk0_gpio4: gpclk0_gpio4 {
+				brcm,pins = <4>;
+				brcm,function = <BCM2835_FSEL_ALT0>;
+			};
+			gpclk1_gpio5: gpclk1_gpio5 {
+				brcm,pins = <5>;
+				brcm,function = <BCM2835_FSEL_ALT0>;
+			};
+			gpclk2_gpio6: gpclk2_gpio6 {
+				brcm,pins = <6>;
+				brcm,function = <BCM2835_FSEL_ALT0>;
+			};
+			spi0_gpio7: spi0_gpio7 {
+				brcm,pins = <7 8 9 10 11>;
+				brcm,function = <BCM2835_FSEL_ALT0>;
+			};
+			pwm0_gpio12: pwm0_gpio12 {
+				brcm,pins = <12>;
+				brcm,function = <BCM2835_FSEL_ALT0>;
+			};
+			pwm1_gpio13: pwm1_gpio13 {
+				brcm,pins = <13>;
+				brcm,function = <BCM2835_FSEL_ALT0>;
+			};
+			uart0_gpio14: uart0_gpio14 {
+				brcm,pins = <14 15>;
+				brcm,function = <BCM2835_FSEL_ALT0>;
+			};
+			pcm_gpio18: pcm_gpio18 {
+				brcm,pins = <18 19 20 21>;
+				brcm,function = <BCM2835_FSEL_ALT0>;
+			};
+			i2c0_gpio32: i2c0_gpio32 {
+				brcm,pins = <32 34>;
+				brcm,function = <BCM2835_FSEL_ALT0>;
+			};
+			spio0_gpio35: spio0_gpio35 {
+				brcm,pins = <35 36 37 38 39>;
+				brcm,function = <BCM2835_FSEL_ALT0>;
+			};
+			pwm0_gpio40: pwm0_gpio40 {
+				brcm,pins = <40>;
+				brcm,function = <BCM2835_FSEL_ALT0>;
+			};
+			pwm1_gpio41: pwm1_gpio41 {
+				brcm,pins = <41>;
+				brcm,function = <BCM2835_FSEL_ALT0>;
+			};
+			gpclk1_gpio42: gpclk1_gpio42 {
+				brcm,pins = <42>;
+				brcm,function = <BCM2835_FSEL_ALT0>;
+			};
+			gpclk2_gpio43: gpclk2_gpio43 {
+				brcm,pins = <43>;
+				brcm,function = <BCM2835_FSEL_ALT0>;
+			};
+			gpclk1_gpio44: gpclk1_gpio44 {
+				brcm,pins = <44>;
+				brcm,function = <BCM2835_FSEL_ALT0>;
+			};
+			pwm1_gpio45: pwm1_gpio45 {
+				brcm,pins = <45>;
+				brcm,function = <BCM2835_FSEL_ALT0>;
+			};
+			i2c0_gpio44: i2c0_gpio44 {
+				brcm,pins = <44 45>;
+				brcm,function = <BCM2835_FSEL_ALT1>;
+			};
+			pcm_gpio28: pcm_gpio28 {
+				brcm,pins = <28 29 30 31>;
+				brcm,function = <BCM2835_FSEL_ALT2>;
+			};
+			uart1_gpio36: uart1_gpio36 {
+				brcm,pins = <36 37 38 39>;
+				brcm,function = <BCM2835_FSEL_ALT2>;
+			};
+			i2c1_gpio44: i2c1_gpio44 {
+				brcm,pins = <44 45>;
+				brcm,function = <BCM2835_FSEL_ALT2>;
+			};
+			/* Separate from the uart0_gpio14 group
+			 * because it conflicts with spi1_gpio16, and
+			 * people often run uart0 on the two pins
+			 * without flow contrl.
+			 */
+			uart0_ctsrts_gpio16: uart0_ctsrts_gpio16 {
+				brcm,pins = <16 17>;
+				brcm,function = <BCM2835_FSEL_ALT3>;
+			};
+			i2c_slave_gpio18: i2c_slave_gpio18 {
+				brcm,pins = <18 19 20 21>;
+				brcm,function = <BCM2835_FSEL_ALT3>;
+			};
+			emmc_gpio22: emmc_gpio22 {
+				brcm,pins = <22 23 24 25 26 27>;
+				brcm,function = <BCM2835_FSEL_ALT3>;
+			};
+			uart0_gpio30: uart0_gpio30 {
+				brcm,pins = <30 31>;
+				brcm,function = <BCM2835_FSEL_ALT3>;
+			};
+			uart0_ctsrts_gpio32: uart0_ctsrts_gpio32 {
+				brcm,pins = <32 33>;
+				brcm,function = <BCM2835_FSEL_ALT3>;
+			};
+			spi1_gpio16: spi1_gpio16 {
+				brcm,pins = <16 17 18 19 20 21>;
+				brcm,function = <BCM2835_FSEL_ALT4>;
+			};
+			jtag_gpio22: jtag_gpio22 {
+				brcm,pins = <22 23 24 25 26 27>;
+				brcm,function = <BCM2835_FSEL_ALT4>;
+			};
+			spi2_gpio40: spi2_gpio40 {
+				brcm,pins = <40 41 42 43 44 45>;
+				brcm,function = <BCM2835_FSEL_ALT4>;
+			};
+			jtag_gpio4: jtag_gpio4 {
+				brcm,pins = <4 5 6 12 13>;
+				brcm,function = <BCM2835_FSEL_ALT4>;
+			};
+			uart1_gpio14: uart1_gpio14 {
+				brcm,pins = <14 15>;
+				brcm,function = <BCM2835_FSEL_ALT5>;
+			};
+			uart1_ctsrts_gpio16: uart1_ctsrts_gpio16 {
+				brcm,pins = <16 17>;
+				brcm,function = <BCM2835_FSEL_ALT5>;
+			};
+			pwm0_gpio18: pwm0_gpio18 {
+				brcm,pins = <18>;
+				brcm,function = <BCM2835_FSEL_ALT5>;
+			};
+			pwm1_gpio19: pwm1_gpio19 {
+				brcm,pins = <19>;
+				brcm,function = <BCM2835_FSEL_ALT5>;
+			};
+			uart1_gpio32: uart1_gpio32 {
+				brcm,pins = <32 33>;
+				brcm,function = <BCM2835_FSEL_ALT5>;
+			};
+			uart1_ctsrts_gpio30: uart1_ctsrts_gpio30 {
+				brcm,pins = <30 31>;
+				brcm,function = <BCM2835_FSEL_ALT5>;
+			};
+			uart1_gpio40: uart1_gpio40 {
+				brcm,pins = <40 41>;
+				brcm,function = <BCM2835_FSEL_ALT5>;
+			};
+			uart1_ctsrts_gpio42: uart1_ctsrts_gpio42 {
+				brcm,pins = <42 43>;
+				brcm,function = <BCM2835_FSEL_ALT5>;
+			};
 		};
 
 		uart0: serial@7e201000 {
-- 
2.7.0

[PATCH 2/5] ARM: bcm2835: Replace alt0/i2s_alt[02] with standard groups.

[Eric Anholt]

Since all of these pins were documented, we can use their names to
explain what's going on.

Signed-off-by: Eric Anholt <eric@anholt.net>
---
 arch/arm/boot/dts/bcm2835-rpi-a-plus.dts | 17 ++++++++++-------
 arch/arm/boot/dts/bcm2835-rpi-a.dts      | 17 ++++++++++-------
 arch/arm/boot/dts/bcm2835-rpi-b-plus.dts | 17 ++++++++++-------
 arch/arm/boot/dts/bcm2835-rpi-b-rev2.dts | 17 ++++++++++-------
 arch/arm/boot/dts/bcm2835-rpi-b.dts      | 10 +++++++++-
 arch/arm/boot/dts/bcm2835-rpi.dtsi       |  5 -----
 arch/arm/boot/dts/bcm2836-rpi-2-b.dts    | 17 ++++++++++-------
 7 files changed, 59 insertions(+), 41 deletions(-)

diff --git a/arch/arm/boot/dts/bcm2835-rpi-a-plus.dts b/arch/arm/boot/dts/bcm2835-rpi-a-plus.dts
index 228614f..0a8b92e 100644
--- a/arch/arm/boot/dts/bcm2835-rpi-a-plus.dts
+++ b/arch/arm/boot/dts/bcm2835-rpi-a-plus.dts
@@ -21,11 +21,14 @@
 };
 
 &gpio {
-	pinctrl-0 = <&gpioout &alt0 &i2s_alt0 &alt3>;
-
-	/* I2S interface */
-	i2s_alt0: i2s_alt0 {
-		brcm,pins = <18 19 20 21>;
-		brcm,function = <BCM2835_FSEL_ALT0>;
-	};
+	pinctrl-0 = <&i2c0_gpio0
+		     &i2c1_gpio2
+		     &gpclk0_gpio4
+		     &gpclk1_gpio5
+		     &spi0_gpio7
+		     &pcm_gpio18
+		     &pwm0_gpio40
+		     &pwm1_gpio45
+		     &gpioout
+		     &alt3>;
 };
diff --git a/arch/arm/boot/dts/bcm2835-rpi-a.dts b/arch/arm/boot/dts/bcm2835-rpi-a.dts
index ddbbbbd..d093407 100644
--- a/arch/arm/boot/dts/bcm2835-rpi-a.dts
+++ b/arch/arm/boot/dts/bcm2835-rpi-a.dts
@@ -14,11 +14,14 @@
 };
 
 &gpio {
-	pinctrl-0 = <&gpioout &alt0 &i2s_alt2 &alt3>;
-
-	/* I2S interface */
-	i2s_alt2: i2s_alt2 {
-		brcm,pins = <28 29 30 31>;
-		brcm,function = <BCM2835_FSEL_ALT2>;
-	};
+	pinctrl-0 = <&i2c0_gpio0
+		     &i2c1_gpio2
+		     &gpclk0_gpio4
+		     &gpclk1_gpio5
+		     &spi0_gpio7
+		     &pcm_gpio28
+		     &pwm0_gpio40
+		     &pwm1_gpio45
+		     &gpioout
+		     &alt3>;
 };
diff --git a/arch/arm/boot/dts/bcm2835-rpi-b-plus.dts b/arch/arm/boot/dts/bcm2835-rpi-b-plus.dts
index ef54050..c26b81d 100644
--- a/arch/arm/boot/dts/bcm2835-rpi-b-plus.dts
+++ b/arch/arm/boot/dts/bcm2835-rpi-b-plus.dts
@@ -21,11 +21,14 @@
 };
 
 &gpio {
-	pinctrl-0 = <&gpioout &alt0 &i2s_alt0 &alt3>;
-
-	/* I2S interface */
-	i2s_alt0: i2s_alt0 {
-		brcm,pins = <18 19 20 21>;
-		brcm,function = <BCM2835_FSEL_ALT0>;
-	};
+	pinctrl-0 = <&i2c0_gpio0
+		     &i2c1_gpio2
+		     &gpclk0_gpio4
+		     &gpclk1_gpio5
+		     &spi0_gpio7
+		     &pcm_gpio18
+		     &pwm0_gpio40
+		     &pwm1_gpio45
+		     &gpioout
+		     &alt3>;
 };
diff --git a/arch/arm/boot/dts/bcm2835-rpi-b-rev2.dts b/arch/arm/boot/dts/bcm2835-rpi-b-rev2.dts
index 86f1f2f..a5b606e 100644
--- a/arch/arm/boot/dts/bcm2835-rpi-b-rev2.dts
+++ b/arch/arm/boot/dts/bcm2835-rpi-b-rev2.dts
@@ -14,11 +14,14 @@
 };
 
 &gpio {
-	pinctrl-0 = <&gpioout &alt0 &i2s_alt2 &alt3>;
-
-	/* I2S interface */
-	i2s_alt2: i2s_alt2 {
-		brcm,pins = <28 29 30 31>;
-		brcm,function = <BCM2835_FSEL_ALT2>;
-	};
+	pinctrl-0 = <&i2c0_gpio0
+		     &i2c1_gpio2
+		     &gpclk0_gpio4
+		     &gpclk1_gpio5
+		     &spi0_gpio7
+		     &pcm_gpio28
+		     &pwm0_gpio40
+		     &pwm1_gpio45
+		     &gpioout
+		     &alt3>;
 };
diff --git a/arch/arm/boot/dts/bcm2835-rpi-b.dts b/arch/arm/boot/dts/bcm2835-rpi-b.dts
index 4859e9d..97e3c2f 100644
--- a/arch/arm/boot/dts/bcm2835-rpi-b.dts
+++ b/arch/arm/boot/dts/bcm2835-rpi-b.dts
@@ -14,5 +14,13 @@
 };
 
 &gpio {
-	pinctrl-0 = <&gpioout &alt0 &alt3>;
+	pinctrl-0 = <&i2c0_gpio0
+		     &i2c1_gpio2
+		     &gpclk0_gpio4
+		     &gpclk1_gpio5
+		     &spi0_gpio7
+		     &pwm0_gpio40
+		     &pwm1_gpio45
+		     &gpioout
+		     &alt3>;
 };
diff --git a/arch/arm/boot/dts/bcm2835-rpi.dtsi b/arch/arm/boot/dts/bcm2835-rpi.dtsi
index 76bdbca..141b18c 100644
--- a/arch/arm/boot/dts/bcm2835-rpi.dtsi
+++ b/arch/arm/boot/dts/bcm2835-rpi.dtsi
@@ -37,11 +37,6 @@
 		brcm,function = <BCM2835_FSEL_GPIO_OUT>;
 	};
 
-	alt0: alt0 {
-		brcm,pins = <0 1 2 3 4 5 7 8 9 10 11 14 15 40 45>;
-		brcm,function = <BCM2835_FSEL_ALT0>;
-	};
-
 	alt3: alt3 {
 		brcm,pins = <48 49 50 51 52 53>;
 		brcm,function = <BCM2835_FSEL_ALT3>;
diff --git a/arch/arm/boot/dts/bcm2836-rpi-2-b.dts b/arch/arm/boot/dts/bcm2836-rpi-2-b.dts
index ff94666..52798ca 100644
--- a/arch/arm/boot/dts/bcm2836-rpi-2-b.dts
+++ b/arch/arm/boot/dts/bcm2836-rpi-2-b.dts
@@ -25,11 +25,14 @@
 };
 
 &gpio {
-	pinctrl-0 = <&gpioout &alt0 &i2s_alt0 &alt3>;
-
-	/* I2S interface */
-	i2s_alt0: i2s_alt0 {
-		brcm,pins = <18 19 20 21>;
-		brcm,function = <BCM2835_FSEL_ALT0>;
-	};
+	pinctrl-0 = <&i2c0_gpio0
+		     &i2c1_gpio2
+		     &gpclk0_gpio4
+		     &gpclk1_gpio5
+		     &spi0_gpio7
+		     &pcm_gpio18
+		     &pwm0_gpio40
+		     &pwm1_gpio45
+		     &gpioout
+		     &alt3>;
 };
-- 
2.7.0

[PATCH 3/5] ARM: bcm2835: Move the emmc pin group to bcm283x.dtsi.

[Eric Anholt]

While it's not documented in the public PDF, it is internally.  This
is a standard pin group for the 283x, not rpi-specific.

Signed-off-by: Eric Anholt <eric@anholt.net>
---
 arch/arm/boot/dts/bcm2835-rpi-a-plus.dts | 4 ++--
 arch/arm/boot/dts/bcm2835-rpi-a.dts      | 4 ++--
 arch/arm/boot/dts/bcm2835-rpi-b-plus.dts | 4 ++--
 arch/arm/boot/dts/bcm2835-rpi-b-rev2.dts | 4 ++--
 arch/arm/boot/dts/bcm2835-rpi-b.dts      | 4 ++--
 arch/arm/boot/dts/bcm2835-rpi.dtsi       | 5 -----
 arch/arm/boot/dts/bcm2836-rpi-2-b.dts    | 4 ++--
 arch/arm/boot/dts/bcm283x.dtsi           | 4 ++++
 8 files changed, 16 insertions(+), 17 deletions(-)

diff --git a/arch/arm/boot/dts/bcm2835-rpi-a-plus.dts b/arch/arm/boot/dts/bcm2835-rpi-a-plus.dts
index 0a8b92e..1db6835 100644
--- a/arch/arm/boot/dts/bcm2835-rpi-a-plus.dts
+++ b/arch/arm/boot/dts/bcm2835-rpi-a-plus.dts
@@ -29,6 +29,6 @@
 		     &pcm_gpio18
 		     &pwm0_gpio40
 		     &pwm1_gpio45
-		     &gpioout
-		     &alt3>;
+		     &emmc_gpio48
+		     &gpioout>;
 };
diff --git a/arch/arm/boot/dts/bcm2835-rpi-a.dts b/arch/arm/boot/dts/bcm2835-rpi-a.dts
index d093407..25d2114 100644
--- a/arch/arm/boot/dts/bcm2835-rpi-a.dts
+++ b/arch/arm/boot/dts/bcm2835-rpi-a.dts
@@ -22,6 +22,6 @@
 		     &pcm_gpio28
 		     &pwm0_gpio40
 		     &pwm1_gpio45
-		     &gpioout
-		     &alt3>;
+		     &emmc_gpio48
+		     &gpioout>;
 };
diff --git a/arch/arm/boot/dts/bcm2835-rpi-b-plus.dts b/arch/arm/boot/dts/bcm2835-rpi-b-plus.dts
index c26b81d..d8057b8 100644
--- a/arch/arm/boot/dts/bcm2835-rpi-b-plus.dts
+++ b/arch/arm/boot/dts/bcm2835-rpi-b-plus.dts
@@ -29,6 +29,6 @@
 		     &pcm_gpio18
 		     &pwm0_gpio40
 		     &pwm1_gpio45
-		     &gpioout
-		     &alt3>;
+		     &emmc_gpio48
+		     &gpioout>;
 };
diff --git a/arch/arm/boot/dts/bcm2835-rpi-b-rev2.dts b/arch/arm/boot/dts/bcm2835-rpi-b-rev2.dts
index a5b606e..e7dbff4 100644
--- a/arch/arm/boot/dts/bcm2835-rpi-b-rev2.dts
+++ b/arch/arm/boot/dts/bcm2835-rpi-b-rev2.dts
@@ -22,6 +22,6 @@
 		     &pcm_gpio28
 		     &pwm0_gpio40
 		     &pwm1_gpio45
-		     &gpioout
-		     &alt3>;
+		     &emmc_gpio48
+		     &gpioout>;
 };
diff --git a/arch/arm/boot/dts/bcm2835-rpi-b.dts b/arch/arm/boot/dts/bcm2835-rpi-b.dts
index 97e3c2f..d154049 100644
--- a/arch/arm/boot/dts/bcm2835-rpi-b.dts
+++ b/arch/arm/boot/dts/bcm2835-rpi-b.dts
@@ -21,6 +21,6 @@
 		     &spi0_gpio7
 		     &pwm0_gpio40
 		     &pwm1_gpio45
-		     &gpioout
-		     &alt3>;
+		     &emmc_gpio48
+		     &gpioout>;
 };
diff --git a/arch/arm/boot/dts/bcm2835-rpi.dtsi b/arch/arm/boot/dts/bcm2835-rpi.dtsi
index 141b18c..eff27b0 100644
--- a/arch/arm/boot/dts/bcm2835-rpi.dtsi
+++ b/arch/arm/boot/dts/bcm2835-rpi.dtsi
@@ -36,11 +36,6 @@
 		brcm,pins = <6>;
 		brcm,function = <BCM2835_FSEL_GPIO_OUT>;
 	};
-
-	alt3: alt3 {
-		brcm,pins = <48 49 50 51 52 53>;
-		brcm,function = <BCM2835_FSEL_ALT3>;
-	};
 };
 
 &i2c0 {
diff --git a/arch/arm/boot/dts/bcm2836-rpi-2-b.dts b/arch/arm/boot/dts/bcm2836-rpi-2-b.dts
index 52798ca..3e9226f 100644
--- a/arch/arm/boot/dts/bcm2836-rpi-2-b.dts
+++ b/arch/arm/boot/dts/bcm2836-rpi-2-b.dts
@@ -33,6 +33,6 @@
 		     &pcm_gpio18
 		     &pwm0_gpio40
 		     &pwm1_gpio45
-		     &gpioout
-		     &alt3>;
+		     &emmc_gpio48
+		     &gpioout>;
 };
diff --git a/arch/arm/boot/dts/bcm283x.dtsi b/arch/arm/boot/dts/bcm283x.dtsi
index e91198e..70a6814 100644
--- a/arch/arm/boot/dts/bcm283x.dtsi
+++ b/arch/arm/boot/dts/bcm283x.dtsi
@@ -232,6 +232,10 @@
 				brcm,pins = <32 33>;
 				brcm,function = <BCM2835_FSEL_ALT3>;
 			};
+			emmc_gpio48: emmc_gpio48 {
+				brcm,pins = <48 49 50 51 52 53>;
+				brcm,function = <BCM2835_FSEL_ALT3>;
+			};
 			spi1_gpio16: spi1_gpio16 {
 				brcm,pins = <16 17 18 19 20 21>;
 				brcm,function = <BCM2835_FSEL_ALT4>;
-- 
2.7.0

[PATCH 4/5] ARM: bcm2835: Add a group for mapping pins 48-53 to sdhost.

[Eric Anholt]

This pin group definition comes from downstream.  We don't have a
driver for sdhost integrated yet, but they've been experimenting with
it and it sounds useful to bring over.

Signed-off-by: Eric Anholt <eric@anholt.net>
---
 arch/arm/boot/dts/bcm283x.dtsi | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/arch/arm/boot/dts/bcm283x.dtsi b/arch/arm/boot/dts/bcm283x.dtsi
index 70a6814..0bb32cc 100644
--- a/arch/arm/boot/dts/bcm283x.dtsi
+++ b/arch/arm/boot/dts/bcm283x.dtsi
@@ -191,6 +191,10 @@
 				brcm,pins = <45>;
 				brcm,function = <BCM2835_FSEL_ALT0>;
 			};
+			sdhost_gpio48: sdhost_gpio48 {
+				brcm,pins = <48 49 50 51 52 53>;
+				brcm,function = <BCM2835_FSEL_ALT0>;
+			};
 			i2c0_gpio44: i2c0_gpio44 {
 				brcm,pins = <44 45>;
 				brcm,function = <BCM2835_FSEL_ALT1>;
-- 
2.7.0

[PATCH 5/5] ARM: bcm2835: Move most RPi default pin groups to their devices.

[Eric Anholt]

This way we can get the duplicated pin group definitions out of each
RPi board file, and just leave the i2s variations in them.

Signed-off-by: Eric Anholt <eric@anholt.net>
---
 arch/arm/boot/dts/bcm2835-rpi-a-plus.dts | 14 +++-----------
 arch/arm/boot/dts/bcm2835-rpi-a.dts      | 14 +++-----------
 arch/arm/boot/dts/bcm2835-rpi-b-plus.dts | 14 +++-----------
 arch/arm/boot/dts/bcm2835-rpi-b-rev2.dts | 14 +++-----------
 arch/arm/boot/dts/bcm2835-rpi-b.dts      | 12 ------------
 arch/arm/boot/dts/bcm2835-rpi.dtsi       | 20 ++++++++++++++++++++
 arch/arm/boot/dts/bcm2836-rpi-2-b.dts    | 14 +++-----------
 7 files changed, 35 insertions(+), 67 deletions(-)

diff --git a/arch/arm/boot/dts/bcm2835-rpi-a-plus.dts b/arch/arm/boot/dts/bcm2835-rpi-a-plus.dts
index 1db6835..a00cbbe 100644
--- a/arch/arm/boot/dts/bcm2835-rpi-a-plus.dts
+++ b/arch/arm/boot/dts/bcm2835-rpi-a-plus.dts
@@ -20,15 +20,7 @@
 	};
 };
 
-&gpio {
-	pinctrl-0 = <&i2c0_gpio0
-		     &i2c1_gpio2
-		     &gpclk0_gpio4
-		     &gpclk1_gpio5
-		     &spi0_gpio7
-		     &pcm_gpio18
-		     &pwm0_gpio40
-		     &pwm1_gpio45
-		     &emmc_gpio48
-		     &gpioout>;
+&i2s {
+	pinctrl-names = "default";
+	pinctrl-0 = <&pcm_gpio18>;
 };
diff --git a/arch/arm/boot/dts/bcm2835-rpi-a.dts b/arch/arm/boot/dts/bcm2835-rpi-a.dts
index 25d2114..23e6b6f 100644
--- a/arch/arm/boot/dts/bcm2835-rpi-a.dts
+++ b/arch/arm/boot/dts/bcm2835-rpi-a.dts
@@ -13,15 +13,7 @@
 	};
 };
 
-&gpio {
-	pinctrl-0 = <&i2c0_gpio0
-		     &i2c1_gpio2
-		     &gpclk0_gpio4
-		     &gpclk1_gpio5
-		     &spi0_gpio7
-		     &pcm_gpio28
-		     &pwm0_gpio40
-		     &pwm1_gpio45
-		     &emmc_gpio48
-		     &gpioout>;
+&i2s {
+	pinctrl-names = "default";
+	pinctrl-0 = <&pcm_gpio28>;
 };
diff --git a/arch/arm/boot/dts/bcm2835-rpi-b-plus.dts b/arch/arm/boot/dts/bcm2835-rpi-b-plus.dts
index d8057b8..029b589 100644
--- a/arch/arm/boot/dts/bcm2835-rpi-b-plus.dts
+++ b/arch/arm/boot/dts/bcm2835-rpi-b-plus.dts
@@ -20,15 +20,7 @@
 	};
 };
 
-&gpio {
-	pinctrl-0 = <&i2c0_gpio0
-		     &i2c1_gpio2
-		     &gpclk0_gpio4
-		     &gpclk1_gpio5
-		     &spi0_gpio7
-		     &pcm_gpio18
-		     &pwm0_gpio40
-		     &pwm1_gpio45
-		     &emmc_gpio48
-		     &gpioout>;
+&i2s {
+	pinctrl-names = "default";
+	pinctrl-0 = <&pcm_gpio18>;
 };
diff --git a/arch/arm/boot/dts/bcm2835-rpi-b-rev2.dts b/arch/arm/boot/dts/bcm2835-rpi-b-rev2.dts
index e7dbff4..da1bc27 100644
--- a/arch/arm/boot/dts/bcm2835-rpi-b-rev2.dts
+++ b/arch/arm/boot/dts/bcm2835-rpi-b-rev2.dts
@@ -13,15 +13,7 @@
 	};
 };
 
-&gpio {
-	pinctrl-0 = <&i2c0_gpio0
-		     &i2c1_gpio2
-		     &gpclk0_gpio4
-		     &gpclk1_gpio5
-		     &spi0_gpio7
-		     &pcm_gpio28
-		     &pwm0_gpio40
-		     &pwm1_gpio45
-		     &emmc_gpio48
-		     &gpioout>;
+&i2s {
+	pinctrl-names = "default";
+	pinctrl-0 = <&pcm_gpio28>;
 };
diff --git a/arch/arm/boot/dts/bcm2835-rpi-b.dts b/arch/arm/boot/dts/bcm2835-rpi-b.dts
index d154049..df275d4 100644
--- a/arch/arm/boot/dts/bcm2835-rpi-b.dts
+++ b/arch/arm/boot/dts/bcm2835-rpi-b.dts
@@ -12,15 +12,3 @@
 		};
 	};
 };
-
-&gpio {
-	pinctrl-0 = <&i2c0_gpio0
-		     &i2c1_gpio2
-		     &gpclk0_gpio4
-		     &gpclk1_gpio5
-		     &spi0_gpio7
-		     &pwm0_gpio40
-		     &pwm1_gpio45
-		     &emmc_gpio48
-		     &gpioout>;
-};
diff --git a/arch/arm/boot/dts/bcm2835-rpi.dtsi b/arch/arm/boot/dts/bcm2835-rpi.dtsi
index eff27b0..b8efd41 100644
--- a/arch/arm/boot/dts/bcm2835-rpi.dtsi
+++ b/arch/arm/boot/dts/bcm2835-rpi.dtsi
@@ -31,6 +31,9 @@
 
 &gpio {
 	pinctrl-names = "default";
+	pinctrl-0 = <&gpclk0_gpio4
+		     &gpclk1_gpio5
+		     &gpioout>;
 
 	gpioout: gpioout {
 		brcm,pins = <6>;
@@ -39,11 +42,17 @@
 };
 
 &i2c0 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&i2c0_gpio0>;
+
 	status = "okay";
 	clock-frequency = <100000>;
 };
 
 &i2c1 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&i2c1_gpio2>;
+
 	status = "okay";
 	clock-frequency = <100000>;
 };
@@ -53,14 +62,25 @@
 };
 
 &sdhci {
+	pinctrl-names = "default";
+	pinctrl-0 = <&emmc_gpio48>;
+
 	status = "okay";
 	bus-width = <4>;
 };
 
 &pwm {
+	pinctrl-names = "default";
+	pinctrl-0 = <&pwm0_gpio40 &pwm1_gpio45>;
+
 	status = "okay";
 };
 
 &usb {
 	power-domains = <&power RPI_POWER_DOMAIN_USB>;
 };
+
+&spi {
+	pinctrl-names = "default";
+	pinctrl-0 = <&spi0_gpio7>;
+};
diff --git a/arch/arm/boot/dts/bcm2836-rpi-2-b.dts b/arch/arm/boot/dts/bcm2836-rpi-2-b.dts
index 3e9226f..ae2bc91 100644
--- a/arch/arm/boot/dts/bcm2836-rpi-2-b.dts
+++ b/arch/arm/boot/dts/bcm2836-rpi-2-b.dts
@@ -24,15 +24,7 @@
 	};
 };
 
-&gpio {
-	pinctrl-0 = <&i2c0_gpio0
-		     &i2c1_gpio2
-		     &gpclk0_gpio4
-		     &gpclk1_gpio5
-		     &spi0_gpio7
-		     &pcm_gpio18
-		     &pwm0_gpio40
-		     &pwm1_gpio45
-		     &emmc_gpio48
-		     &gpioout>;
+&i2s {
+	pinctrl-names = "default";
+	pinctrl-0 = <&pcm_gpio18>;
 };
-- 
2.7.0

Re: [PATCH 1/5] ARM: bcm2835: Define standard pinctrl groups in the gpio node.

[Stephen Warren]

On 02/26/2016 11:19 AM, Eric Anholt wrote:
> The BCM2835-ARM-Peripherals.pdf documentation specifies what the
> function selects do for the pins, and there are a bunch of obvious
> groupings to be made.  With these created, we'll be able to replace
> bcm2835-rpi.dtsi's main "set all of these pins to alt0" with
> references to specific groups we want enabled.

> diff --git a/arch/arm/boot/dts/bcm283x.dtsi b/arch/arm/boot/dts/bcm283x.dtsi

> +			spi0_gpio7: spi0_gpio7 {
> +				brcm,pins = <7 8 9 10 11>;
> +				brcm,function = <BCM2835_FSEL_ALT0>;
> +			};

This is too many pins.

- It includes both MOSI and MISO, although a particular use-case may 
only use 1 of those.

- It includes both chip-select signals, whereas a particular use-case 
may use 0, 1, or 2 of those. This is especially true since IIRC the 
mainline bcm283x SPI driver wants to only use GPIOs for chip-selects, 
not SPI-controller-generated chip-select signals, to avoid some issues 
with the HW generation of these signals.

I believe a similar comment applies to other SPI nodes too.

> +			pcm_gpio18: pcm_gpio18 {
> +				brcm,pins = <18 19 20 21>;
> +				brcm,function = <BCM2835_FSEL_ALT0>;
> +			};

Here too, I wonder if some people might want only one of DIN/DOUT and 
not both?

> +			uart1_gpio36: uart1_gpio36 {
> +				brcm,pins = <36 37 38 39>;
> +				brcm,function = <BCM2835_FSEL_ALT2>;
> +			};

Similarly, I think for UARTS, TX/RX and RTS/CTS should always be in 
different nodes so people can choose 2- or 4-wire mode. Most of the UART 
nodes are already split like this, but this one isn't.

> +			emmc_gpio22: emmc_gpio22 {
> +				brcm,pins = <22 23 24 25 26 27>;
> +				brcm,function = <BCM2835_FSEL_ALT3>;
> +			};

1-wire (1 data wire, plus CLK/CMD) eMMC is possible in theory, although 
I don't know whether it makes sense to support this?

[PATCH 1/5] ARM: bcm2835: Define standard pinctrl groups in the gpio node.

[Stephen Warren]

On 02/26/2016 11:19 AM, Eric Anholt wrote:
> The BCM2835-ARM-Peripherals.pdf documentation specifies what the
> function selects do for the pins, and there are a bunch of obvious
> groupings to be made.  With these created, we'll be able to replace
> bcm2835-rpi.dtsi's main "set all of these pins to alt0" with
> references to specific groups we want enabled.

> diff --git a/arch/arm/boot/dts/bcm283x.dtsi b/arch/arm/boot/dts/bcm283x.dtsi

> +			spi0_gpio7: spi0_gpio7 {
> +				brcm,pins = <7 8 9 10 11>;
> +				brcm,function = <BCM2835_FSEL_ALT0>;
> +			};

This is too many pins.

- It includes both MOSI and MISO, although a particular use-case may 
only use 1 of those.

- It includes both chip-select signals, whereas a particular use-case 
may use 0, 1, or 2 of those. This is especially true since IIRC the 
mainline bcm283x SPI driver wants to only use GPIOs for chip-selects, 
not SPI-controller-generated chip-select signals, to avoid some issues 
with the HW generation of these signals.

I believe a similar comment applies to other SPI nodes too.

> +			pcm_gpio18: pcm_gpio18 {
> +				brcm,pins = <18 19 20 21>;
> +				brcm,function = <BCM2835_FSEL_ALT0>;
> +			};

Here too, I wonder if some people might want only one of DIN/DOUT and 
not both?

> +			uart1_gpio36: uart1_gpio36 {
> +				brcm,pins = <36 37 38 39>;
> +				brcm,function = <BCM2835_FSEL_ALT2>;
> +			};

Similarly, I think for UARTS, TX/RX and RTS/CTS should always be in 
different nodes so people can choose 2- or 4-wire mode. Most of the UART 
nodes are already split like this, but this one isn't.

> +			emmc_gpio22: emmc_gpio22 {
> +				brcm,pins = <22 23 24 25 26 27>;
> +				brcm,function = <BCM2835_FSEL_ALT3>;
> +			};

1-wire (1 data wire, plus CLK/CMD) eMMC is possible in theory, although 
I don't know whether it makes sense to support this?

Re: [PATCH 2/5] ARM: bcm2835: Replace alt0/i2s_alt[02] with standard groups.

[Stephen Warren]

On 02/26/2016 11:19 AM, Eric Anholt wrote:
> Since all of these pins were documented, we can use their names to
> explain what's going on.

> diff --git a/arch/arm/boot/dts/bcm2835-rpi-a-plus.dts b/arch/arm/boot/dts/bcm2835-rpi-a-plus.dts

>   &gpio {
> +	pinctrl-0 = <&i2c0_gpio0
> +		     &i2c1_gpio2
> +		     &gpclk0_gpio4
> +		     &gpclk1_gpio5
> +		     &spi0_gpio7
> +		     &pcm_gpio18
> +		     &pwm0_gpio40
> +		     &pwm1_gpio45
> +		     &gpioout
> +		     &alt3>;
>   };

Why not convert alt3 to the new scheme too?

I think this configures too many pins, which in turn makes assumptions 
about what those pins are used for that may not be valid.

Recent RPi firmware configures almost all expansion connector GPIOs as 
GPIO-in. This ensures that no matter what is connected to the expansion 
connector, there can be no signal conflicts due to both the bcm283x and 
some external device both attempting to drive the same pin. I believe 
the default Linux pinmux should adopt the same approach, by simply not 
configuring any expansion connector pins except those known to have a 
100% hard-coded usage. For example, the HAT I2C pins must only be used 
for that purpose on the RPi, so even if the HW supported using them as 
arbitrary GPIO or PWM or ..., we know they're actually I2C.

So, I think this list should only include configuration for pins 
connected to on-board devices, or expansion pins that have a 100% known 
purpose.

(I can't quite remember how many pins are being configured in the 
upstream kernel's DT files at present; it's possible the complying with 
this rule may involve removing some pinctrl settings that are currently 
present to avoid conflicts. User-specific additions should come from DT 
overlays or manual DT edits.)

[PATCH 2/5] ARM: bcm2835: Replace alt0/i2s_alt[02] with standard groups.

[Stephen Warren]

On 02/26/2016 11:19 AM, Eric Anholt wrote:
> Since all of these pins were documented, we can use their names to
> explain what's going on.

> diff --git a/arch/arm/boot/dts/bcm2835-rpi-a-plus.dts b/arch/arm/boot/dts/bcm2835-rpi-a-plus.dts

>   &gpio {
> +	pinctrl-0 = <&i2c0_gpio0
> +		     &i2c1_gpio2
> +		     &gpclk0_gpio4
> +		     &gpclk1_gpio5
> +		     &spi0_gpio7
> +		     &pcm_gpio18
> +		     &pwm0_gpio40
> +		     &pwm1_gpio45
> +		     &gpioout
> +		     &alt3>;
>   };

Why not convert alt3 to the new scheme too?

I think this configures too many pins, which in turn makes assumptions 
about what those pins are used for that may not be valid.

Recent RPi firmware configures almost all expansion connector GPIOs as 
GPIO-in. This ensures that no matter what is connected to the expansion 
connector, there can be no signal conflicts due to both the bcm283x and 
some external device both attempting to drive the same pin. I believe 
the default Linux pinmux should adopt the same approach, by simply not 
configuring any expansion connector pins except those known to have a 
100% hard-coded usage. For example, the HAT I2C pins must only be used 
for that purpose on the RPi, so even if the HW supported using them as 
arbitrary GPIO or PWM or ..., we know they're actually I2C.

So, I think this list should only include configuration for pins 
connected to on-board devices, or expansion pins that have a 100% known 
purpose.

(I can't quite remember how many pins are being configured in the 
upstream kernel's DT files at present; it's possible the complying with 
this rule may involve removing some pinctrl settings that are currently 
present to avoid conflicts. User-specific additions should come from DT 
overlays or manual DT edits.)

Re: [PATCH 1/5] ARM: bcm2835: Define standard pinctrl groups in the gpio node.

[Eric Anholt]

[-- Attachment #1: Type: text/plain, Size: 2557 bytes --]

Stephen Warren <swarren-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org> writes:

> On 02/26/2016 11:19 AM, Eric Anholt wrote:
>> The BCM2835-ARM-Peripherals.pdf documentation specifies what the
>> function selects do for the pins, and there are a bunch of obvious
>> groupings to be made.  With these created, we'll be able to replace
>> bcm2835-rpi.dtsi's main "set all of these pins to alt0" with
>> references to specific groups we want enabled.
>
>> diff --git a/arch/arm/boot/dts/bcm283x.dtsi b/arch/arm/boot/dts/bcm283x.dtsi
>
>> +			spi0_gpio7: spi0_gpio7 {
>> +				brcm,pins = <7 8 9 10 11>;
>> +				brcm,function = <BCM2835_FSEL_ALT0>;
>> +			};
>
> This is too many pins.
>
> - It includes both MOSI and MISO, although a particular use-case may 
> only use 1 of those.
>
> - It includes both chip-select signals, whereas a particular use-case 
> may use 0, 1, or 2 of those. This is especially true since IIRC the 
> mainline bcm283x SPI driver wants to only use GPIOs for chip-selects, 
> not SPI-controller-generated chip-select signals, to avoid some issues 
> with the HW generation of these signals.
>
>
> I believe a similar comment applies to other SPI nodes too.
>
>> +			pcm_gpio18: pcm_gpio18 {
>> +				brcm,pins = <18 19 20 21>;
>> +				brcm,function = <BCM2835_FSEL_ALT0>;
>> +			};
>
> Here too, I wonder if some people might want only one of DIN/DOUT and 
> not both?
>
>> +			uart1_gpio36: uart1_gpio36 {
>> +				brcm,pins = <36 37 38 39>;
>> +				brcm,function = <BCM2835_FSEL_ALT2>;
>> +			};
>
> Similarly, I think for UARTS, TX/RX and RTS/CTS should always be in 
> different nodes so people can choose 2- or 4-wire mode. Most of the UART 
> nodes are already split like this, but this one isn't.
>
>> +			emmc_gpio22: emmc_gpio22 {
>> +				brcm,pins = <22 23 24 25 26 27>;
>> +				brcm,function = <BCM2835_FSEL_ALT3>;
>> +			};
>
> 1-wire (1 data wire, plus CLK/CMD) eMMC is possible in theory, although 
> I don't know whether it makes sense to support this?

Nothing here precludes making alternative pin groups for special
situations like you're bringing up here.  I'm just trying to bring
sanity to the giant lists of pins we have currently, that happen to
correspond to these.

Of your suggestions, making uart1_gpio36 split out cts/rts like the rest
makes a lot of sense to me.  Of the others, they seem like speculation
more than "we should fix this because it's not what people want."  Can
you provide specific feedback of what you'd like changed to get an Ack?

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 818 bytes --]

Re: [PATCH 1/5] ARM: bcm2835: Define standard pinctrl groups in the gpio node.

[Eric Anholt]

[-- Attachment #1: Type: text/plain, Size: 2531 bytes --]

Stephen Warren <swarren@wwwdotorg.org> writes:

> On 02/26/2016 11:19 AM, Eric Anholt wrote:
>> The BCM2835-ARM-Peripherals.pdf documentation specifies what the
>> function selects do for the pins, and there are a bunch of obvious
>> groupings to be made.  With these created, we'll be able to replace
>> bcm2835-rpi.dtsi's main "set all of these pins to alt0" with
>> references to specific groups we want enabled.
>
>> diff --git a/arch/arm/boot/dts/bcm283x.dtsi b/arch/arm/boot/dts/bcm283x.dtsi
>
>> +			spi0_gpio7: spi0_gpio7 {
>> +				brcm,pins = <7 8 9 10 11>;
>> +				brcm,function = <BCM2835_FSEL_ALT0>;
>> +			};
>
> This is too many pins.
>
> - It includes both MOSI and MISO, although a particular use-case may 
> only use 1 of those.
>
> - It includes both chip-select signals, whereas a particular use-case 
> may use 0, 1, or 2 of those. This is especially true since IIRC the 
> mainline bcm283x SPI driver wants to only use GPIOs for chip-selects, 
> not SPI-controller-generated chip-select signals, to avoid some issues 
> with the HW generation of these signals.
>
>
> I believe a similar comment applies to other SPI nodes too.
>
>> +			pcm_gpio18: pcm_gpio18 {
>> +				brcm,pins = <18 19 20 21>;
>> +				brcm,function = <BCM2835_FSEL_ALT0>;
>> +			};
>
> Here too, I wonder if some people might want only one of DIN/DOUT and 
> not both?
>
>> +			uart1_gpio36: uart1_gpio36 {
>> +				brcm,pins = <36 37 38 39>;
>> +				brcm,function = <BCM2835_FSEL_ALT2>;
>> +			};
>
> Similarly, I think for UARTS, TX/RX and RTS/CTS should always be in 
> different nodes so people can choose 2- or 4-wire mode. Most of the UART 
> nodes are already split like this, but this one isn't.
>
>> +			emmc_gpio22: emmc_gpio22 {
>> +				brcm,pins = <22 23 24 25 26 27>;
>> +				brcm,function = <BCM2835_FSEL_ALT3>;
>> +			};
>
> 1-wire (1 data wire, plus CLK/CMD) eMMC is possible in theory, although 
> I don't know whether it makes sense to support this?

Nothing here precludes making alternative pin groups for special
situations like you're bringing up here.  I'm just trying to bring
sanity to the giant lists of pins we have currently, that happen to
correspond to these.

Of your suggestions, making uart1_gpio36 split out cts/rts like the rest
makes a lot of sense to me.  Of the others, they seem like speculation
more than "we should fix this because it's not what people want."  Can
you provide specific feedback of what you'd like changed to get an Ack?

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 818 bytes --]

[PATCH 1/5] ARM: bcm2835: Define standard pinctrl groups in the gpio node.

[Eric Anholt]

Stephen Warren <swarren@wwwdotorg.org> writes:

> On 02/26/2016 11:19 AM, Eric Anholt wrote:
>> The BCM2835-ARM-Peripherals.pdf documentation specifies what the
>> function selects do for the pins, and there are a bunch of obvious
>> groupings to be made.  With these created, we'll be able to replace
>> bcm2835-rpi.dtsi's main "set all of these pins to alt0" with
>> references to specific groups we want enabled.
>
>> diff --git a/arch/arm/boot/dts/bcm283x.dtsi b/arch/arm/boot/dts/bcm283x.dtsi
>
>> +			spi0_gpio7: spi0_gpio7 {
>> +				brcm,pins = <7 8 9 10 11>;
>> +				brcm,function = <BCM2835_FSEL_ALT0>;
>> +			};
>
> This is too many pins.
>
> - It includes both MOSI and MISO, although a particular use-case may 
> only use 1 of those.
>
> - It includes both chip-select signals, whereas a particular use-case 
> may use 0, 1, or 2 of those. This is especially true since IIRC the 
> mainline bcm283x SPI driver wants to only use GPIOs for chip-selects, 
> not SPI-controller-generated chip-select signals, to avoid some issues 
> with the HW generation of these signals.
>
>
> I believe a similar comment applies to other SPI nodes too.
>
>> +			pcm_gpio18: pcm_gpio18 {
>> +				brcm,pins = <18 19 20 21>;
>> +				brcm,function = <BCM2835_FSEL_ALT0>;
>> +			};
>
> Here too, I wonder if some people might want only one of DIN/DOUT and 
> not both?
>
>> +			uart1_gpio36: uart1_gpio36 {
>> +				brcm,pins = <36 37 38 39>;
>> +				brcm,function = <BCM2835_FSEL_ALT2>;
>> +			};
>
> Similarly, I think for UARTS, TX/RX and RTS/CTS should always be in 
> different nodes so people can choose 2- or 4-wire mode. Most of the UART 
> nodes are already split like this, but this one isn't.
>
>> +			emmc_gpio22: emmc_gpio22 {
>> +				brcm,pins = <22 23 24 25 26 27>;
>> +				brcm,function = <BCM2835_FSEL_ALT3>;
>> +			};
>
> 1-wire (1 data wire, plus CLK/CMD) eMMC is possible in theory, although 
> I don't know whether it makes sense to support this?

Nothing here precludes making alternative pin groups for special
situations like you're bringing up here.  I'm just trying to bring
sanity to the giant lists of pins we have currently, that happen to
correspond to these.

Of your suggestions, making uart1_gpio36 split out cts/rts like the rest
makes a lot of sense to me.  Of the others, they seem like speculation
more than "we should fix this because it's not what people want."  Can
you provide specific feedback of what you'd like changed to get an Ack?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 818 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160303/1d73cc33/attachment.sig>

Re: [PATCH 2/5] ARM: bcm2835: Replace alt0/i2s_alt[02] with standard groups.

[Eric Anholt]

[-- Attachment #1.1: Type: text/plain, Size: 2299 bytes --]

Stephen Warren <swarren@wwwdotorg.org> writes:

> On 02/26/2016 11:19 AM, Eric Anholt wrote:
>> Since all of these pins were documented, we can use their names to
>> explain what's going on.
>
>> diff --git a/arch/arm/boot/dts/bcm2835-rpi-a-plus.dts b/arch/arm/boot/dts/bcm2835-rpi-a-plus.dts
>
>>   &gpio {
>> +	pinctrl-0 = <&i2c0_gpio0
>> +		     &i2c1_gpio2
>> +		     &gpclk0_gpio4
>> +		     &gpclk1_gpio5
>> +		     &spi0_gpio7
>> +		     &pcm_gpio18
>> +		     &pwm0_gpio40
>> +		     &pwm1_gpio45
>> +		     &gpioout
>> +		     &alt3>;
>>   };
>
> Why not convert alt3 to the new scheme too?

(covered in the next patch)

> I think this configures too many pins, which in turn makes assumptions 
> about what those pins are used for that may not be valid.
>
> Recent RPi firmware configures almost all expansion connector GPIOs as 
> GPIO-in. This ensures that no matter what is connected to the expansion 
> connector, there can be no signal conflicts due to both the bcm283x and 
> some external device both attempting to drive the same pin. I believe 
> the default Linux pinmux should adopt the same approach, by simply not 
> configuring any expansion connector pins except those known to have a 
> 100% hard-coded usage. For example, the HAT I2C pins must only be used 
> for that purpose on the RPi, so even if the HW supported using them as 
> arbitrary GPIO or PWM or ..., we know they're actually I2C.
>
> So, I think this list should only include configuration for pins 
> connected to on-board devices, or expansion pins that have a 100% known 
> purpose.
>
> (I can't quite remember how many pins are being configured in the 
> upstream kernel's DT files at present; it's possible the complying with 
> this rule may involve removing some pinctrl settings that are currently 
> present to avoid conflicts. User-specific additions should come from DT 
> overlays or manual DT edits.)

If we want to improve on our default pin configurations, I'm into that,
but I think the first step is to get groups split up so it's clear what
we're doing with pins in the first place.  This patch is just a no-op
change to get the board files to use smaller groups for
enabling/disabling, and we should stack functional changes after that.

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 818 bytes --]

[-- Attachment #2: Type: text/plain, Size: 176 bytes --]

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH 2/5] ARM: bcm2835: Replace alt0/i2s_alt[02] with standard groups.

[Eric Anholt]

[-- Attachment #1: Type: text/plain, Size: 2299 bytes --]

Stephen Warren <swarren@wwwdotorg.org> writes:

> On 02/26/2016 11:19 AM, Eric Anholt wrote:
>> Since all of these pins were documented, we can use their names to
>> explain what's going on.
>
>> diff --git a/arch/arm/boot/dts/bcm2835-rpi-a-plus.dts b/arch/arm/boot/dts/bcm2835-rpi-a-plus.dts
>
>>   &gpio {
>> +	pinctrl-0 = <&i2c0_gpio0
>> +		     &i2c1_gpio2
>> +		     &gpclk0_gpio4
>> +		     &gpclk1_gpio5
>> +		     &spi0_gpio7
>> +		     &pcm_gpio18
>> +		     &pwm0_gpio40
>> +		     &pwm1_gpio45
>> +		     &gpioout
>> +		     &alt3>;
>>   };
>
> Why not convert alt3 to the new scheme too?

(covered in the next patch)

> I think this configures too many pins, which in turn makes assumptions 
> about what those pins are used for that may not be valid.
>
> Recent RPi firmware configures almost all expansion connector GPIOs as 
> GPIO-in. This ensures that no matter what is connected to the expansion 
> connector, there can be no signal conflicts due to both the bcm283x and 
> some external device both attempting to drive the same pin. I believe 
> the default Linux pinmux should adopt the same approach, by simply not 
> configuring any expansion connector pins except those known to have a 
> 100% hard-coded usage. For example, the HAT I2C pins must only be used 
> for that purpose on the RPi, so even if the HW supported using them as 
> arbitrary GPIO or PWM or ..., we know they're actually I2C.
>
> So, I think this list should only include configuration for pins 
> connected to on-board devices, or expansion pins that have a 100% known 
> purpose.
>
> (I can't quite remember how many pins are being configured in the 
> upstream kernel's DT files at present; it's possible the complying with 
> this rule may involve removing some pinctrl settings that are currently 
> present to avoid conflicts. User-specific additions should come from DT 
> overlays or manual DT edits.)

If we want to improve on our default pin configurations, I'm into that,
but I think the first step is to get groups split up so it's clear what
we're doing with pins in the first place.  This patch is just a no-op
change to get the board files to use smaller groups for
enabling/disabling, and we should stack functional changes after that.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 818 bytes --]

[PATCH 2/5] ARM: bcm2835: Replace alt0/i2s_alt[02] with standard groups.

[Eric Anholt]

Stephen Warren <swarren@wwwdotorg.org> writes:

> On 02/26/2016 11:19 AM, Eric Anholt wrote:
>> Since all of these pins were documented, we can use their names to
>> explain what's going on.
>
>> diff --git a/arch/arm/boot/dts/bcm2835-rpi-a-plus.dts b/arch/arm/boot/dts/bcm2835-rpi-a-plus.dts
>
>>   &gpio {
>> +	pinctrl-0 = <&i2c0_gpio0
>> +		     &i2c1_gpio2
>> +		     &gpclk0_gpio4
>> +		     &gpclk1_gpio5
>> +		     &spi0_gpio7
>> +		     &pcm_gpio18
>> +		     &pwm0_gpio40
>> +		     &pwm1_gpio45
>> +		     &gpioout
>> +		     &alt3>;
>>   };
>
> Why not convert alt3 to the new scheme too?

(covered in the next patch)

> I think this configures too many pins, which in turn makes assumptions 
> about what those pins are used for that may not be valid.
>
> Recent RPi firmware configures almost all expansion connector GPIOs as 
> GPIO-in. This ensures that no matter what is connected to the expansion 
> connector, there can be no signal conflicts due to both the bcm283x and 
> some external device both attempting to drive the same pin. I believe 
> the default Linux pinmux should adopt the same approach, by simply not 
> configuring any expansion connector pins except those known to have a 
> 100% hard-coded usage. For example, the HAT I2C pins must only be used 
> for that purpose on the RPi, so even if the HW supported using them as 
> arbitrary GPIO or PWM or ..., we know they're actually I2C.
>
> So, I think this list should only include configuration for pins 
> connected to on-board devices, or expansion pins that have a 100% known 
> purpose.
>
> (I can't quite remember how many pins are being configured in the 
> upstream kernel's DT files at present; it's possible the complying with 
> this rule may involve removing some pinctrl settings that are currently 
> present to avoid conflicts. User-specific additions should come from DT 
> overlays or manual DT edits.)

If we want to improve on our default pin configurations, I'm into that,
but I think the first step is to get groups split up so it's clear what
we're doing with pins in the first place.  This patch is just a no-op
change to get the board files to use smaller groups for
enabling/disabling, and we should stack functional changes after that.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 818 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160303/b44fa64d/attachment.sig>

Re: [PATCH 1/5] ARM: bcm2835: Define standard pinctrl groups in the gpio node.

[Stephen Warren]

On 03/03/2016 03:23 PM, Eric Anholt wrote:
> Stephen Warren <swarren@wwwdotorg.org> writes:
>
>> On 02/26/2016 11:19 AM, Eric Anholt wrote:
>>> The BCM2835-ARM-Peripherals.pdf documentation specifies what the
>>> function selects do for the pins, and there are a bunch of obvious
>>> groupings to be made.  With these created, we'll be able to replace
>>> bcm2835-rpi.dtsi's main "set all of these pins to alt0" with
>>> references to specific groups we want enabled.
>>
>>> diff --git a/arch/arm/boot/dts/bcm283x.dtsi b/arch/arm/boot/dts/bcm283x.dtsi
>>
>>> +			spi0_gpio7: spi0_gpio7 {
>>> +				brcm,pins = <7 8 9 10 11>;
>>> +				brcm,function = <BCM2835_FSEL_ALT0>;
>>> +			};
>>
>> This is too many pins.
>>
>> - It includes both MOSI and MISO, although a particular use-case may
>> only use 1 of those.
>>
>> - It includes both chip-select signals, whereas a particular use-case
>> may use 0, 1, or 2 of those. This is especially true since IIRC the
>> mainline bcm283x SPI driver wants to only use GPIOs for chip-selects,
>> not SPI-controller-generated chip-select signals, to avoid some issues
>> with the HW generation of these signals.
>>
>>
>> I believe a similar comment applies to other SPI nodes too.
>>
>>> +			pcm_gpio18: pcm_gpio18 {
>>> +				brcm,pins = <18 19 20 21>;
>>> +				brcm,function = <BCM2835_FSEL_ALT0>;
>>> +			};
>>
>> Here too, I wonder if some people might want only one of DIN/DOUT and
>> not both?
>>
>>> +			uart1_gpio36: uart1_gpio36 {
>>> +				brcm,pins = <36 37 38 39>;
>>> +				brcm,function = <BCM2835_FSEL_ALT2>;
>>> +			};
>>
>> Similarly, I think for UARTS, TX/RX and RTS/CTS should always be in
>> different nodes so people can choose 2- or 4-wire mode. Most of the UART
>> nodes are already split like this, but this one isn't.
>>
>>> +			emmc_gpio22: emmc_gpio22 {
>>> +				brcm,pins = <22 23 24 25 26 27>;
>>> +				brcm,function = <BCM2835_FSEL_ALT3>;
>>> +			};
>>
>> 1-wire (1 data wire, plus CLK/CMD) eMMC is possible in theory, although
>> I don't know whether it makes sense to support this?
>
> Nothing here precludes making alternative pin groups for special
> situations like you're bringing up here.  I'm just trying to bring
> sanity to the giant lists of pins we have currently, that happen to
> correspond to these.
>
> Of your suggestions, making uart1_gpio36 split out cts/rts like the rest
> makes a lot of sense to me.  Of the others, they seem like speculation
> more than "we should fix this because it's not what people want."  Can
> you provide specific feedback of what you'd like changed to get an Ack?

All of the points I raised should be fixed. I don't believe any of the 
groups that affect more than minimal sets of pins are useful. Indeed, 
using groups at all is rather tenuous; it'd be far better to list the 
precise sets of pins only as and when they're used.

[PATCH 1/5] ARM: bcm2835: Define standard pinctrl groups in the gpio node.

[Stephen Warren]

On 03/03/2016 03:23 PM, Eric Anholt wrote:
> Stephen Warren <swarren@wwwdotorg.org> writes:
>
>> On 02/26/2016 11:19 AM, Eric Anholt wrote:
>>> The BCM2835-ARM-Peripherals.pdf documentation specifies what the
>>> function selects do for the pins, and there are a bunch of obvious
>>> groupings to be made.  With these created, we'll be able to replace
>>> bcm2835-rpi.dtsi's main "set all of these pins to alt0" with
>>> references to specific groups we want enabled.
>>
>>> diff --git a/arch/arm/boot/dts/bcm283x.dtsi b/arch/arm/boot/dts/bcm283x.dtsi
>>
>>> +			spi0_gpio7: spi0_gpio7 {
>>> +				brcm,pins = <7 8 9 10 11>;
>>> +				brcm,function = <BCM2835_FSEL_ALT0>;
>>> +			};
>>
>> This is too many pins.
>>
>> - It includes both MOSI and MISO, although a particular use-case may
>> only use 1 of those.
>>
>> - It includes both chip-select signals, whereas a particular use-case
>> may use 0, 1, or 2 of those. This is especially true since IIRC the
>> mainline bcm283x SPI driver wants to only use GPIOs for chip-selects,
>> not SPI-controller-generated chip-select signals, to avoid some issues
>> with the HW generation of these signals.
>>
>>
>> I believe a similar comment applies to other SPI nodes too.
>>
>>> +			pcm_gpio18: pcm_gpio18 {
>>> +				brcm,pins = <18 19 20 21>;
>>> +				brcm,function = <BCM2835_FSEL_ALT0>;
>>> +			};
>>
>> Here too, I wonder if some people might want only one of DIN/DOUT and
>> not both?
>>
>>> +			uart1_gpio36: uart1_gpio36 {
>>> +				brcm,pins = <36 37 38 39>;
>>> +				brcm,function = <BCM2835_FSEL_ALT2>;
>>> +			};
>>
>> Similarly, I think for UARTS, TX/RX and RTS/CTS should always be in
>> different nodes so people can choose 2- or 4-wire mode. Most of the UART
>> nodes are already split like this, but this one isn't.
>>
>>> +			emmc_gpio22: emmc_gpio22 {
>>> +				brcm,pins = <22 23 24 25 26 27>;
>>> +				brcm,function = <BCM2835_FSEL_ALT3>;
>>> +			};
>>
>> 1-wire (1 data wire, plus CLK/CMD) eMMC is possible in theory, although
>> I don't know whether it makes sense to support this?
>
> Nothing here precludes making alternative pin groups for special
> situations like you're bringing up here.  I'm just trying to bring
> sanity to the giant lists of pins we have currently, that happen to
> correspond to these.
>
> Of your suggestions, making uart1_gpio36 split out cts/rts like the rest
> makes a lot of sense to me.  Of the others, they seem like speculation
> more than "we should fix this because it's not what people want."  Can
> you provide specific feedback of what you'd like changed to get an Ack?

All of the points I raised should be fixed. I don't believe any of the 
groups that affect more than minimal sets of pins are useful. Indeed, 
using groups at all is rather tenuous; it'd be far better to list the 
precise sets of pins only as and when they're used.

Re: [PATCH 2/5] ARM: bcm2835: Replace alt0/i2s_alt[02] with standard groups.

[Stephen Warren]

On 03/03/2016 03:28 PM, Eric Anholt wrote:
> Stephen Warren <swarren@wwwdotorg.org> writes:
>
>> On 02/26/2016 11:19 AM, Eric Anholt wrote:
>>> Since all of these pins were documented, we can use their names to
>>> explain what's going on.
>>
>>> diff --git a/arch/arm/boot/dts/bcm2835-rpi-a-plus.dts b/arch/arm/boot/dts/bcm2835-rpi-a-plus.dts
>>
>>>    &gpio {
>>> +	pinctrl-0 = <&i2c0_gpio0
>>> +		     &i2c1_gpio2
>>> +		     &gpclk0_gpio4
>>> +		     &gpclk1_gpio5
>>> +		     &spi0_gpio7
>>> +		     &pcm_gpio18
>>> +		     &pwm0_gpio40
>>> +		     &pwm1_gpio45
>>> +		     &gpioout
>>> +		     &alt3>;
>>>    };
>>
>> Why not convert alt3 to the new scheme too?
>
> (covered in the next patch)
>
>> I think this configures too many pins, which in turn makes assumptions
>> about what those pins are used for that may not be valid.
>>
>> Recent RPi firmware configures almost all expansion connector GPIOs as
>> GPIO-in. This ensures that no matter what is connected to the expansion
>> connector, there can be no signal conflicts due to both the bcm283x and
>> some external device both attempting to drive the same pin. I believe
>> the default Linux pinmux should adopt the same approach, by simply not
>> configuring any expansion connector pins except those known to have a
>> 100% hard-coded usage. For example, the HAT I2C pins must only be used
>> for that purpose on the RPi, so even if the HW supported using them as
>> arbitrary GPIO or PWM or ..., we know they're actually I2C.
>>
>> So, I think this list should only include configuration for pins
>> connected to on-board devices, or expansion pins that have a 100% known
>> purpose.
>>
>> (I can't quite remember how many pins are being configured in the
>> upstream kernel's DT files at present; it's possible the complying with
>> this rule may involve removing some pinctrl settings that are currently
>> present to avoid conflicts. User-specific additions should come from DT
>> overlays or manual DT edits.)
>
> If we want to improve on our default pin configurations, I'm into that,
> but I think the first step is to get groups split up so it's clear what
> we're doing with pins in the first place.  This patch is just a no-op
> change to get the board files to use smaller groups for
> enabling/disabling, and we should stack functional changes after that.

I don't think it's worth making patches that change things around when 
they're immediately going to be thrown away. It is needless churn. If 
you take the approach of removing settings that shouldn't be applied, 
you'll vastly reduce (and possibly even completely eliminate) the work 
to more optimally represent what's left.

[PATCH 2/5] ARM: bcm2835: Replace alt0/i2s_alt[02] with standard groups.

[Stephen Warren]

On 03/03/2016 03:28 PM, Eric Anholt wrote:
> Stephen Warren <swarren@wwwdotorg.org> writes:
>
>> On 02/26/2016 11:19 AM, Eric Anholt wrote:
>>> Since all of these pins were documented, we can use their names to
>>> explain what's going on.
>>
>>> diff --git a/arch/arm/boot/dts/bcm2835-rpi-a-plus.dts b/arch/arm/boot/dts/bcm2835-rpi-a-plus.dts
>>
>>>    &gpio {
>>> +	pinctrl-0 = <&i2c0_gpio0
>>> +		     &i2c1_gpio2
>>> +		     &gpclk0_gpio4
>>> +		     &gpclk1_gpio5
>>> +		     &spi0_gpio7
>>> +		     &pcm_gpio18
>>> +		     &pwm0_gpio40
>>> +		     &pwm1_gpio45
>>> +		     &gpioout
>>> +		     &alt3>;
>>>    };
>>
>> Why not convert alt3 to the new scheme too?
>
> (covered in the next patch)
>
>> I think this configures too many pins, which in turn makes assumptions
>> about what those pins are used for that may not be valid.
>>
>> Recent RPi firmware configures almost all expansion connector GPIOs as
>> GPIO-in. This ensures that no matter what is connected to the expansion
>> connector, there can be no signal conflicts due to both the bcm283x and
>> some external device both attempting to drive the same pin. I believe
>> the default Linux pinmux should adopt the same approach, by simply not
>> configuring any expansion connector pins except those known to have a
>> 100% hard-coded usage. For example, the HAT I2C pins must only be used
>> for that purpose on the RPi, so even if the HW supported using them as
>> arbitrary GPIO or PWM or ..., we know they're actually I2C.
>>
>> So, I think this list should only include configuration for pins
>> connected to on-board devices, or expansion pins that have a 100% known
>> purpose.
>>
>> (I can't quite remember how many pins are being configured in the
>> upstream kernel's DT files at present; it's possible the complying with
>> this rule may involve removing some pinctrl settings that are currently
>> present to avoid conflicts. User-specific additions should come from DT
>> overlays or manual DT edits.)
>
> If we want to improve on our default pin configurations, I'm into that,
> but I think the first step is to get groups split up so it's clear what
> we're doing with pins in the first place.  This patch is just a no-op
> change to get the board files to use smaller groups for
> enabling/disabling, and we should stack functional changes after that.

I don't think it's worth making patches that change things around when 
they're immediately going to be thrown away. It is needless churn. If 
you take the approach of removing settings that shouldn't be applied, 
you'll vastly reduce (and possibly even completely eliminate) the work 
to more optimally represent what's left.

Re: [PATCH 1/5] ARM: bcm2835: Define standard pinctrl groups in the gpio node.

[Martin Sperl]

> On 03.03.2016, at 22:20, Stephen Warren <swarren@wwwdotorg.org> wrote:
> 
> On 02/26/2016 11:19 AM, Eric Anholt wrote:
>> The BCM2835-ARM-Peripherals.pdf documentation specifies what the
>> function selects do for the pins, and there are a bunch of obvious
>> groupings to be made.  With these created, we'll be able to replace
>> bcm2835-rpi.dtsi's main "set all of these pins to alt0" with
>> references to specific groups we want enabled.
> 
>> diff --git a/arch/arm/boot/dts/bcm283x.dtsi b/arch/arm/boot/dts/bcm283x.dtsi
> 
>> +			spi0_gpio7: spi0_gpio7 {
>> +				brcm,pins = <7 8 9 10 11>;
>> +				brcm,function = <BCM2835_FSEL_ALT0>;
>> +			};
> 
> This is too many pins.
> 
> - It includes both MOSI and MISO, although a particular use-case may only use 1 of those.
> 
> - It includes both chip-select signals, whereas a particular use-case may use 0, 1, or 2 of those. This is especially true since IIRC the mainline bcm283x SPI driver wants to only use GPIOs for chip-selects, not SPI-controller-generated chip-select signals, to avoid some issues with the HW generation of these signals.
That is true: the spi-bcm2835 driver requires GPIO usage for chip-select
to make all those latency optimizations work (but also to avoid some
spi-dma issues).
The reason behind it is that there are observed short term “glitches”
on native CS whenever the SPI control register is touched - even with 
identical values.
And GPIO controlled CS solves this issue (and Mark Brown said that
the GPIO-cs interface is now preferred anyway - hence the auxiliary
spi only implement gpio-cs and requires the CS set as OUTPUT, but
unlike the main spi this does not have “remapping” support for
legacy device-trees (as there never was a driver-version that supported
native-cs).

Maybe split the SPI-portion into 2 sections:
* the SCK, MOSI, MISO (pin 9 to 11) with ALT_0
* the CS GPIOs (standard pins are 7 and 8) with OUTPUT.

That way it is easy to override only this section (plus the gpio-cs property inside the spi node) to extend the number of chip selects or use different mappings.

> 
> I believe a similar comment applies to other SPI nodes too.
I guess the same “splitting” approach should be taken here as well...
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH 1/5] ARM: bcm2835: Define standard pinctrl groups in the gpio node.

[Martin Sperl]

> On 03.03.2016, at 22:20, Stephen Warren <swarren@wwwdotorg.org> wrote:
> 
> On 02/26/2016 11:19 AM, Eric Anholt wrote:
>> The BCM2835-ARM-Peripherals.pdf documentation specifies what the
>> function selects do for the pins, and there are a bunch of obvious
>> groupings to be made.  With these created, we'll be able to replace
>> bcm2835-rpi.dtsi's main "set all of these pins to alt0" with
>> references to specific groups we want enabled.
> 
>> diff --git a/arch/arm/boot/dts/bcm283x.dtsi b/arch/arm/boot/dts/bcm283x.dtsi
> 
>> +			spi0_gpio7: spi0_gpio7 {
>> +				brcm,pins = <7 8 9 10 11>;
>> +				brcm,function = <BCM2835_FSEL_ALT0>;
>> +			};
> 
> This is too many pins.
> 
> - It includes both MOSI and MISO, although a particular use-case may only use 1 of those.
> 
> - It includes both chip-select signals, whereas a particular use-case may use 0, 1, or 2 of those. This is especially true since IIRC the mainline bcm283x SPI driver wants to only use GPIOs for chip-selects, not SPI-controller-generated chip-select signals, to avoid some issues with the HW generation of these signals.
That is true: the spi-bcm2835 driver requires GPIO usage for chip-select
to make all those latency optimizations work (but also to avoid some
spi-dma issues).
The reason behind it is that there are observed short term “glitches”
on native CS whenever the SPI control register is touched - even with 
identical values.
And GPIO controlled CS solves this issue (and Mark Brown said that
the GPIO-cs interface is now preferred anyway - hence the auxiliary
spi only implement gpio-cs and requires the CS set as OUTPUT, but
unlike the main spi this does not have “remapping” support for
legacy device-trees (as there never was a driver-version that supported
native-cs).

Maybe split the SPI-portion into 2 sections:
* the SCK, MOSI, MISO (pin 9 to 11) with ALT_0
* the CS GPIOs (standard pins are 7 and 8) with OUTPUT.

That way it is easy to override only this section (plus the gpio-cs property inside the spi node) to extend the number of chip selects or use different mappings.

> 
> I believe a similar comment applies to other SPI nodes too.
I guess the same “splitting” approach should be taken here as well...

[PATCH 1/5] ARM: bcm2835: Define standard pinctrl groups in the gpio node.

[Martin Sperl]

> On 03.03.2016, at 22:20, Stephen Warren <swarren@wwwdotorg.org> wrote:
> 
> On 02/26/2016 11:19 AM, Eric Anholt wrote:
>> The BCM2835-ARM-Peripherals.pdf documentation specifies what the
>> function selects do for the pins, and there are a bunch of obvious
>> groupings to be made.  With these created, we'll be able to replace
>> bcm2835-rpi.dtsi's main "set all of these pins to alt0" with
>> references to specific groups we want enabled.
> 
>> diff --git a/arch/arm/boot/dts/bcm283x.dtsi b/arch/arm/boot/dts/bcm283x.dtsi
> 
>> +			spi0_gpio7: spi0_gpio7 {
>> +				brcm,pins = <7 8 9 10 11>;
>> +				brcm,function = <BCM2835_FSEL_ALT0>;
>> +			};
> 
> This is too many pins.
> 
> - It includes both MOSI and MISO, although a particular use-case may only use 1 of those.
> 
> - It includes both chip-select signals, whereas a particular use-case may use 0, 1, or 2 of those. This is especially true since IIRC the mainline bcm283x SPI driver wants to only use GPIOs for chip-selects, not SPI-controller-generated chip-select signals, to avoid some issues with the HW generation of these signals.
That is true: the spi-bcm2835 driver requires GPIO usage for chip-select
to make all those latency optimizations work (but also to avoid some
spi-dma issues).
The reason behind it is that there are observed short term ?glitches?
on native CS whenever the SPI control register is touched - even with 
identical values.
And GPIO controlled CS solves this issue (and Mark Brown said that
the GPIO-cs interface is now preferred anyway - hence the auxiliary
spi only implement gpio-cs and requires the CS set as OUTPUT, but
unlike the main spi this does not have ?remapping? support for
legacy device-trees (as there never was a driver-version that supported
native-cs).

Maybe split the SPI-portion into 2 sections:
* the SCK, MOSI, MISO (pin 9 to 11) with ALT_0
* the CS GPIOs (standard pins are 7 and 8) with OUTPUT.

That way it is easy to override only this section (plus the gpio-cs property inside the spi node) to extend the number of chip selects or use different mappings.

> 
> I believe a similar comment applies to other SPI nodes too.
I guess the same ?splitting? approach should be taken here as well...

Re: [PATCH 2/5] ARM: bcm2835: Replace alt0/i2s_alt[02] with standard groups.

[Linus Walleij]

On Sat, Feb 27, 2016 at 1:19 AM, Eric Anholt <eric@anholt.net> wrote:

> Since all of these pins were documented, we can use their names to
> explain what's going on.
>
> Signed-off-by: Eric Anholt <eric@anholt.net>

> +       pinctrl-0 = <&i2c0_gpio0
> +                    &i2c1_gpio2
> +                    &gpclk0_gpio4
> +                    &gpclk1_gpio5
> +                    &spi0_gpio7
> +                    &pcm_gpio18
> +                    &pwm0_gpio40
> +                    &pwm1_gpio45
> +                    &gpioout
> +                    &alt3>;

Why are all of these done as hogs instead of being in pinctrl-0
"default" for the device that is using them? i2c1, gpclk0,
etc?

The only reason I see would be if they are unused or something.

Yours,
Linus Walleij

Re: [PATCH 2/5] ARM: bcm2835: Replace alt0/i2s_alt[02] with standard groups.

[Linus Walleij]

On Sat, Feb 27, 2016 at 1:19 AM, Eric Anholt <eric@anholt.net> wrote:

> Since all of these pins were documented, we can use their names to
> explain what's going on.
>
> Signed-off-by: Eric Anholt <eric@anholt.net>

> +       pinctrl-0 = <&i2c0_gpio0
> +                    &i2c1_gpio2
> +                    &gpclk0_gpio4
> +                    &gpclk1_gpio5
> +                    &spi0_gpio7
> +                    &pcm_gpio18
> +                    &pwm0_gpio40
> +                    &pwm1_gpio45
> +                    &gpioout
> +                    &alt3>;

Why are all of these done as hogs instead of being in pinctrl-0
"default" for the device that is using them? i2c1, gpclk0,
etc?

The only reason I see would be if they are unused or something.

Yours,
Linus Walleij

[PATCH 2/5] ARM: bcm2835: Replace alt0/i2s_alt[02] with standard groups.

[Linus Walleij]

On Sat, Feb 27, 2016 at 1:19 AM, Eric Anholt <eric@anholt.net> wrote:

> Since all of these pins were documented, we can use their names to
> explain what's going on.
>
> Signed-off-by: Eric Anholt <eric@anholt.net>

> +       pinctrl-0 = <&i2c0_gpio0
> +                    &i2c1_gpio2
> +                    &gpclk0_gpio4
> +                    &gpclk1_gpio5
> +                    &spi0_gpio7
> +                    &pcm_gpio18
> +                    &pwm0_gpio40
> +                    &pwm1_gpio45
> +                    &gpioout
> +                    &alt3>;

Why are all of these done as hogs instead of being in pinctrl-0
"default" for the device that is using them? i2c1, gpclk0,
etc?

The only reason I see would be if they are unused or something.

Yours,
Linus Walleij

Re: [PATCH 5/5] ARM: bcm2835: Move most RPi default pin groups to their devices.

[Linus Walleij]

On Sat, Feb 27, 2016 at 1:19 AM, Eric Anholt <eric@anholt.net> wrote:

> This way we can get the duplicated pin group definitions out of each
> RPi board file, and just leave the i2s variations in them.
>
> Signed-off-by: Eric Anholt <eric@anholt.net>

Aha I speak too soon I see. This set of patches look fine to
me but you need to address Stephens comments and obtain his
ACK.

Yours,
Linus Walleij

Re: [PATCH 5/5] ARM: bcm2835: Move most RPi default pin groups to their devices.

[Linus Walleij]

On Sat, Feb 27, 2016 at 1:19 AM, Eric Anholt <eric@anholt.net> wrote:

> This way we can get the duplicated pin group definitions out of each
> RPi board file, and just leave the i2s variations in them.
>
> Signed-off-by: Eric Anholt <eric@anholt.net>

Aha I speak too soon I see. This set of patches look fine to
me but you need to address Stephens comments and obtain his
ACK.

Yours,
Linus Walleij

[PATCH 5/5] ARM: bcm2835: Move most RPi default pin groups to their devices.

[Linus Walleij]

On Sat, Feb 27, 2016 at 1:19 AM, Eric Anholt <eric@anholt.net> wrote:

> This way we can get the duplicated pin group definitions out of each
> RPi board file, and just leave the i2s variations in them.
>
> Signed-off-by: Eric Anholt <eric@anholt.net>

Aha I speak too soon I see. This set of patches look fine to
me but you need to address Stephens comments and obtain his
ACK.

Yours,
Linus Walleij

Re: [PATCH 2/5] ARM: bcm2835: Replace alt0/i2s_alt[02] with standard groups.

[Stephen Warren]

On 03/08/2016 01:24 AM, Linus Walleij wrote:
> On Sat, Feb 27, 2016 at 1:19 AM, Eric Anholt <eric@anholt.net> wrote:
>
>> Since all of these pins were documented, we can use their names to
>> explain what's going on.
>>
>> Signed-off-by: Eric Anholt <eric@anholt.net>
>
>> +       pinctrl-0 = <&i2c0_gpio0
>> +                    &i2c1_gpio2
>> +                    &gpclk0_gpio4
>> +                    &gpclk1_gpio5
>> +                    &spi0_gpio7
>> +                    &pcm_gpio18
>> +                    &pwm0_gpio40
>> +                    &pwm1_gpio45
>> +                    &gpioout
>> +                    &alt3>;
>
> Why are all of these done as hogs instead of being in pinctrl-0
> "default" for the device that is using them? i2c1, gpclk0,
> etc?
>
> The only reason I see would be if they are unused or something.

I think it makes sense to have the pinctrl driver (or even FW before the 
kernel boots) set up everything at once where possible. That's the 
easiest way to ensure there are never any conflicts in the pinmux table 
(i.e. that two different pins don't end up being both muxed to SPI1's 
MISO signal at the same time for a while before all the drivers probe). 
Putting pinctrl entries into individual devices only makes sense to me 
when one of:

a) That device needs to dynamically change the pinmux at run-time, e.g. 
to switch between different states, so needs definitions of those 
different states.

or:

b) The initial pinmux is guaranteed set up to a safe non-conflicting 
state that enables very little, and we need to defer enabling various 
peripherals until a later time when we know the peripheral is in use, 
e.g. when loading a DT overlay from user-space.

On the RPi there are certain peripherals that fall into each category, 
e.g. SD card is always used, I2S only optionally used.

Re: [PATCH 2/5] ARM: bcm2835: Replace alt0/i2s_alt[02] with standard groups.

[Stephen Warren]

On 03/08/2016 01:24 AM, Linus Walleij wrote:
> On Sat, Feb 27, 2016 at 1:19 AM, Eric Anholt <eric@anholt.net> wrote:
>
>> Since all of these pins were documented, we can use their names to
>> explain what's going on.
>>
>> Signed-off-by: Eric Anholt <eric@anholt.net>
>
>> +       pinctrl-0 = <&i2c0_gpio0
>> +                    &i2c1_gpio2
>> +                    &gpclk0_gpio4
>> +                    &gpclk1_gpio5
>> +                    &spi0_gpio7
>> +                    &pcm_gpio18
>> +                    &pwm0_gpio40
>> +                    &pwm1_gpio45
>> +                    &gpioout
>> +                    &alt3>;
>
> Why are all of these done as hogs instead of being in pinctrl-0
> "default" for the device that is using them? i2c1, gpclk0,
> etc?
>
> The only reason I see would be if they are unused or something.

I think it makes sense to have the pinctrl driver (or even FW before the 
kernel boots) set up everything at once where possible. That's the 
easiest way to ensure there are never any conflicts in the pinmux table 
(i.e. that two different pins don't end up being both muxed to SPI1's 
MISO signal at the same time for a while before all the drivers probe). 
Putting pinctrl entries into individual devices only makes sense to me 
when one of:

a) That device needs to dynamically change the pinmux at run-time, e.g. 
to switch between different states, so needs definitions of those 
different states.

or:

b) The initial pinmux is guaranteed set up to a safe non-conflicting 
state that enables very little, and we need to defer enabling various 
peripherals until a later time when we know the peripheral is in use, 
e.g. when loading a DT overlay from user-space.

On the RPi there are certain peripherals that fall into each category, 
e.g. SD card is always used, I2S only optionally used.

[PATCH 2/5] ARM: bcm2835: Replace alt0/i2s_alt[02] with standard groups.

[Stephen Warren]

On 03/08/2016 01:24 AM, Linus Walleij wrote:
> On Sat, Feb 27, 2016 at 1:19 AM, Eric Anholt <eric@anholt.net> wrote:
>
>> Since all of these pins were documented, we can use their names to
>> explain what's going on.
>>
>> Signed-off-by: Eric Anholt <eric@anholt.net>
>
>> +       pinctrl-0 = <&i2c0_gpio0
>> +                    &i2c1_gpio2
>> +                    &gpclk0_gpio4
>> +                    &gpclk1_gpio5
>> +                    &spi0_gpio7
>> +                    &pcm_gpio18
>> +                    &pwm0_gpio40
>> +                    &pwm1_gpio45
>> +                    &gpioout
>> +                    &alt3>;
>
> Why are all of these done as hogs instead of being in pinctrl-0
> "default" for the device that is using them? i2c1, gpclk0,
> etc?
>
> The only reason I see would be if they are unused or something.

I think it makes sense to have the pinctrl driver (or even FW before the 
kernel boots) set up everything at once where possible. That's the 
easiest way to ensure there are never any conflicts in the pinmux table 
(i.e. that two different pins don't end up being both muxed to SPI1's 
MISO signal at the same time for a while before all the drivers probe). 
Putting pinctrl entries into individual devices only makes sense to me 
when one of:

a) That device needs to dynamically change the pinmux at run-time, e.g. 
to switch between different states, so needs definitions of those 
different states.

or:

b) The initial pinmux is guaranteed set up to a safe non-conflicting 
state that enables very little, and we need to defer enabling various 
peripherals until a later time when we know the peripheral is in use, 
e.g. when loading a DT overlay from user-space.

On the RPi there are certain peripherals that fall into each category, 
e.g. SD card is always used, I2S only optionally used.