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

[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.

[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>

[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.

[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 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.

[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>

[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.

[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.

[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 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 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 2/5] ARM: bcm2835: Replace alt0/i2s_alt[02] with standard groups.

[Stephen Warren]

On 02/23/2016 03:21 PM, Eric Anholt wrote:
> Since all of these pins were documented, we can use their names to
> explain what's going on.

I only received patch 2/5, and e.g. the spinics.net email archive seems 
to be in the same boat.