[PATCH v2] ARM: bcm2835: add device tree for Raspberry Pi model B+

[PATCH v2] ARM: bcm2835: add device tree for Raspberry Pi model B+

[Matthias Klein]

The model B and B+ differ in the GPIO lines for ACT and PWR leds, and the
I2S interface.

Signed-off-by: Matthias Klein <matthias.klein@linux.com>
---
Changes in v2:
- move the common parts between the B and B+ model into the new bcm2835-rpi.dtsi file

- add the I2S signals to the B+ file which fix the problem that USB is not working
  with the current bcm2835-rpi-b.dts file on the B+.
---
 arch/arm/boot/dts/Makefile               |  1 +
 arch/arm/boot/dts/bcm2835-rpi-b-plus.dts | 30 +++++++++++++++++++
 arch/arm/boot/dts/bcm2835-rpi-b.dts      | 46 ++--------------------------
 arch/arm/boot/dts/bcm2835-rpi.dtsi       | 51 ++++++++++++++++++++++++++++++++
 4 files changed, 85 insertions(+), 43 deletions(-)
 create mode 100644 arch/arm/boot/dts/bcm2835-rpi-b-plus.dts
 create mode 100644 arch/arm/boot/dts/bcm2835-rpi.dtsi

diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index aaae0d6..29e18ee 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -54,6 +54,7 @@ dtb-$(CONFIG_ARCH_AT91)	+= at91-sama5d4ek.dtb
 dtb-$(CONFIG_ARCH_ATLAS6) += atlas6-evb.dtb
 dtb-$(CONFIG_ARCH_AXXIA) += axm5516-amarillo.dtb
 dtb-$(CONFIG_ARCH_BCM2835) += bcm2835-rpi-b.dtb
+dtb-$(CONFIG_ARCH_BCM2835) += bcm2835-rpi-b-plus.dtb
 dtb-$(CONFIG_ARCH_BCM_5301X) += bcm4708-netgear-r6250.dtb
 dtb-$(CONFIG_ARCH_BCM_63XX) += bcm963138dvt.dtb
 dtb-$(CONFIG_ARCH_BCM_MOBILE) += bcm28155-ap.dtb \
diff --git a/arch/arm/boot/dts/bcm2835-rpi-b-plus.dts b/arch/arm/boot/dts/bcm2835-rpi-b-plus.dts
new file mode 100644
index 0000000..e479515
--- /dev/null
+++ b/arch/arm/boot/dts/bcm2835-rpi-b-plus.dts
@@ -0,0 +1,30 @@
+/dts-v1/;
+/include/ "bcm2835-rpi.dtsi"
+
+/ {
+	compatible = "raspberrypi,model-b-plus", "brcm,bcm2835";
+	model = "Raspberry Pi Model B+";
+
+	leds {
+		act {
+			gpios = <&gpio 47 0>;
+		};
+
+		pwr {
+			label = "PWR";
+			gpios = <&gpio 35 0>;
+			default-state = "keep";
+			linux,default-trigger = "default-on";
+		};
+	};
+};
+
+&gpio {
+	pinctrl-0 = <&gpioout &alt0 &i2s_alt0 &alt3>;
+
+	/* I2S interface */
+	i2s_alt0: i2s_alt0 {
+		brcm,pins = <18 19 20 21>;
+		brcm,function = <4>; /* alt0 */
+	};
+};
diff --git a/arch/arm/boot/dts/bcm2835-rpi-b.dts b/arch/arm/boot/dts/bcm2835-rpi-b.dts
index 58a0d60..bafa46f 100644
--- a/arch/arm/boot/dts/bcm2835-rpi-b.dts
+++ b/arch/arm/boot/dts/bcm2835-rpi-b.dts
@@ -1,63 +1,23 @@
 /dts-v1/;
-/include/ "bcm2835.dtsi"
+/include/ "bcm2835-rpi.dtsi"
 
 / {
 	compatible = "raspberrypi,model-b", "brcm,bcm2835";
 	model = "Raspberry Pi Model B";
 
-	memory {
-		reg = <0 0x10000000>;
-	};
-
 	leds {
-		compatible = "gpio-leds";
-
 		act {
-			label = "ACT";
 			gpios = <&gpio 16 1>;
-			default-state = "keep";
-			linux,default-trigger = "heartbeat";
 		};
 	};
 };
 
 &gpio {
-	pinctrl-names = "default";
-	pinctrl-0 = <&gpioout &alt0 &alt2 &alt3>;
-
-	gpioout: gpioout {
-		brcm,pins = <6>;
-		brcm,function = <1>; /* GPIO out */
-	};
-
-	alt0: alt0 {
-		brcm,pins = <0 1 2 3 4 5 7 8 9 10 11 14 15 40 45>;
-		brcm,function = <4>; /* alt0 */
-	};
-
-	alt3: alt3 {
-		brcm,pins = <48 49 50 51 52 53>;
-		brcm,function = <7>; /* alt3 */
-	};
+	pinctrl-0 = <&gpioout &alt0 &i2s_alt2 &alt3>;
 
 	/* I2S interface */
-	alt2: alt2 {
+	i2s_alt2: i2s_alt2 {
 		brcm,pins = <28 29 30 31>;
 		brcm,function = <6>; /* alt2 */
 	};
 };
-
-&i2c0 {
-	status = "okay";
-	clock-frequency = <100000>;
-};
-
-&i2c1 {
-	status = "okay";
-	clock-frequency = <100000>;
-};
-
-&sdhci {
-	status = "okay";
-	bus-width = <4>;
-};
diff --git a/arch/arm/boot/dts/bcm2835-rpi.dtsi b/arch/arm/boot/dts/bcm2835-rpi.dtsi
new file mode 100644
index 0000000..c706448
--- /dev/null
+++ b/arch/arm/boot/dts/bcm2835-rpi.dtsi
@@ -0,0 +1,51 @@
+/include/ "bcm2835.dtsi"
+
+/ {
+	memory {
+		reg = <0 0x10000000>;
+	};
+
+	leds {
+		compatible = "gpio-leds";
+
+		act {
+			label = "ACT";
+			default-state = "keep";
+			linux,default-trigger = "heartbeat";
+		};
+	};
+};
+
+&gpio {
+	pinctrl-names = "default";
+
+	gpioout: gpioout {
+		brcm,pins = <6>;
+		brcm,function = <1>; /* GPIO out */
+	};
+
+	alt0: alt0 {
+		brcm,pins = <0 1 2 3 4 5 7 8 9 10 11 14 15 40 45>;
+		brcm,function = <4>; /* alt0 */
+	};
+
+	alt3: alt3 {
+		brcm,pins = <48 49 50 51 52 53>;
+		brcm,function = <7>; /* alt3 */
+	};
+};
+
+&i2c0 {
+	status = "okay";
+	clock-frequency = <100000>;
+};
+
+&i2c1 {
+	status = "okay";
+	clock-frequency = <100000>;
+};
+
+&sdhci {
+	status = "okay";
+	bus-width = <4>;
+};
-- 
2.1.3

Re: [PATCH v2] ARM: bcm2835: add device tree for Raspberry Pi model B+

[Stephen Warren]

On 11/05/2014 04:45 PM, Matthias Klein wrote:
> The model B and B+ differ in the GPIO lines for ACT and PWR leds, and the
> I2S interface.

Tested-by: Stephen Warren <swarren@nvidia.com>

(On a model B rev 2, UART, SD card, and enumeration of built-in USB
devices works fine)

Lee, how do you want to handle patches - will you apply them to the git
repo?

Matthias, BTW, you should CC linux-arm-kernel@lists.infradead.org too;
possibly you can use that to replace the main
linux-kernel@vger.kernel.org mailing list.

Re: [PATCH v2] ARM: bcm2835: add device tree for Raspberry Pi model B+

[Stephen Warren]

On 11/05/2014 04:45 PM, Matthias Klein wrote:
> The model B and B+ differ in the GPIO lines for ACT and PWR leds, and the
> I2S interface.

BTW, according to:

http://raspberryalphaomega.org.uk/2013/02/06/automatic-raspberry-pi-board-revision-detection-model-a-b1-and-b2/

... there are actually 2 different HW configurations we care about for
the pre-plus Pis:

B rev 1
A, or B rev 2

I guess we should have separate device trees for those, since there are
some differences in the GPIO and I2C channel usage. That'd leave us with:

bcm2835-rpi-b.dts (Pin3=GPIO0, Pin5=GPIO1, Pin13=GPIO21, I2C-0)
bcm2835-rpi-b-rev2.dts (Pin3=GPIO1, Pin5=GPIO2, Pin13=GPIO27, 12C-1)
bcm2835-rpi-b-plus.dts (TBD pending schematic or equivalent info)
... and probably another for the compute board.

We can ignore RAM size differences, since these are automatically filled
into the /memory node in DT. I'm not sure if A-vs-B-rev-1 is
interesting. Perhaps we should have separate DTs just in case, since we
may need to represent the LAN_RUN GPIO in DT at some point, and that
only applies to the B.

Presumably, the boot loader would automatically query the VC firmware
for the board revision data, and dynamically load the appropriate DT
filename.

Any thoughts or objections?

Re: [PATCH v2] ARM: bcm2835: add device tree for Raspberry Pi model B+

[Matthias Klein]

Am 06.11.2014 um 06:29 schrieb Stephen Warren:
> I guess we should have separate device trees for those, since there are
> some differences in the GPIO and I2C channel usage. That'd leave us with:
>
> bcm2835-rpi-b.dts (Pin3=GPIO0, Pin5=GPIO1, Pin13=GPIO21, I2C-0)
> bcm2835-rpi-b-rev2.dts (Pin3=GPIO1, Pin5=GPIO2, Pin13=GPIO27, 12C-1)
I think for these differences separate device trees are not needed.
These pins are all at the moment configured as ALT0. Both I2C buses are 
configured for I2C,
therefore I doesn't matter which one is wired to the gpio header.

But for clarity it would be better to have a separate device tree for 
each model.


When a gpio signal (which is configured in device tree as ALT0) is used 
as e.g. plain gpio output, does the kernel the reconfiguration from ALT0 
to gpio output?
Or must the gpio signal be configured as output in the device tree?

Is is possible to set at the brcm,function/brcm,pins gpio definition 
also the voltage level of an gpio output for e.g. the LAN_RUN signal?


How do we want to continue?
Is my patch OK, or should I try to write a device tree for every model 
where every gpio signal is defined?


Best regards,
Matthias

Re: [PATCH v2] ARM: bcm2835: add device tree for Raspberry Pi model B+

[Stephen Warren]

On 11/06/2014 11:15 AM, Matthias Klein wrote:
>
> Am 06.11.2014 um 06:29 schrieb Stephen Warren:
>> I guess we should have separate device trees for those, since there are
>> some differences in the GPIO and I2C channel usage. That'd leave us with:
>>
>> bcm2835-rpi-b.dts (Pin3=GPIO0, Pin5=GPIO1, Pin13=GPIO21, I2C-0)
>> bcm2835-rpi-b-rev2.dts (Pin3=GPIO1, Pin5=GPIO2, Pin13=GPIO27, 12C-1)
 >
> I think for these differences separate device trees are not needed.
> These pins are all at the moment configured as ALT0.Both I2C buses are
> configured for I2C,
> therefore I doesn't matter which one is wired to the gpio header.

At the moment perhaps there's not a lot of difference between the board. 
However, e.g. the board ID pins on the early boards are connected to 
pull-up/down resistors, and hence could be represented in DT as specific 
named GPIOs or not, depending on whether the board has board ID pins. 
Similarly, we should only enable the I2C controllers on a particular 
board if there's any possibility of a user connecting something, which 
is only true if that particular I2C controller is routed to an IO 
connector (or on-board device).

> But for clarity it would be better to have a separate device tree for
> each model.

So yes, I think we should move to separate DTs for each incompatible 
model, so that if/when we actually want to make the DT content different 
between them, we already have separate DTs in place to do that. That 
will allow use to update any bootloaders to choose the right DT now, 
rather than right when we really need it done already:-)

> When a gpio signal (which is configured in device tree as ALT0) is used
> as e.g. plain gpio output, does the kernel the reconfiguration from ALT0
> to gpio output?

IIRC, the kernel GPIO driver sets the pinmux to GPIOin/GPIOout based on 
gpio_request() calls.

> Or must the gpio signal be configured as output in the device tree?

It doens't have to be. That said, if we *know* that a particular GPIO is 
used as a GPIO rather than a special function, there's probably no harm 
just putting that setting right into the DT.

> Is is possible to set at the brcm,function/brcm,pins gpio definition
> also the voltage level of an gpio output for e.g. the LAN_RUN signal?

No. The value on a GPIO pin can only be selected by code. For pins such 
as LAN_RUN that don't have code controlling them, you can get away with 
setting the pin as input/tri-state with a pull-up/pull-down to get the 
desired state.

> How do we want to continue?
> Is my patch OK, or should I try to write a device tree for every model
> where every gpio signal is defined?

I think the patch is fine for now; my thoughts were more about the need 
to send additional patches to add more DTs later.

Re: [PATCH v2] ARM: bcm2835: add device tree for Raspberry Pi model B+

[Noralf Tronnes]

Den 06.11.2014 00:45, skrev Matthias Klein:
> The model B and B+ differ in the GPIO lines for ACT and PWR leds, and the
> I2S interface.
>
> Signed-off-by: Matthias Klein <matthias.klein@linux.com>
> ---
> Changes in v2:
> - move the common parts between the B and B+ model into the new bcm2835-rpi.dtsi file
>
> - add the I2S signals to the B+ file which fix the problem that USB is not working
>    with the current bcm2835-rpi-b.dts file on the B+.
> ---
<snip>
> +&gpio {
> +	pinctrl-names = "default";
> +
> +	gpioout: gpioout {
> +		brcm,pins = <6>;
> +		brcm,function = <1>; /* GPIO out */
> +	};
> +
> +	alt0: alt0 {
> +		brcm,pins = <0 1 2 3 4 5 7 8 9 10 11 14 15 40 45>;
> +		brcm,function = <4>; /* alt0 */
> +	};
> +
> +	alt3: alt3 {
> +		brcm,pins = <48 49 50 51 52 53>;
> +		brcm,function = <7>; /* alt3 */
> +	};
> +};
AFAIK these pins will always be configured regardless of whether they 
are used by a driver or not.

Could we do something like this for SPI and I2C, configuring only when 
needed?

&gpio {
     spi_pins: spi_pins {
         brcm,pins = <7 8 9 10 11>;
         brcm,function = <4>; /* alt0 */
     };

     i2c0_pins: i2c0_pins {
         brcm,pins = <0 1>;
         brcm,function = <4>;
     };

     i2c1_pins: i2c1_pins {
         brcm,pins = <2 3>;
         brcm,function = <4>;
     };
};

&spi {
     pinctrl-names = "default";
     pinctrl-0 = <&spi_pins>;
};

&i2c0 {
     pinctrl-names = "default";
     pinctrl-0 = <&i2c0_pins>;
     clock-frequency = <100000>;
};

&i2c1 {
     pinctrl-names = "default";
     pinctrl-0 = <&i2c1_pins>;
     clock-frequency = <100000>;
};

> +
> +&i2c0 {
> +	status = "okay";
> +	clock-frequency = <100000>;
> +};
> +
> +&i2c1 {
> +	status = "okay";
> +	clock-frequency = <100000>;
> +};
> +
Should the I2C busses be enabled by default? On Raspian, i2c is disabled 
by blacklisting the module (/etc/modprobe.d/raspi-blacklist.conf).
At least i2c0 should be left disabled due to the HAT EEPROM and camera.
The bus number has also changed with revisions: 
http://www.raspberrypi.org/forums/viewtopic.php?p=603950#p603950

Re: [PATCH v2] ARM: bcm2835: add device tree for Raspberry Pi model B+

[Stephen Warren]

On 11/06/2014 12:36 PM, Noralf Tronnes wrote:
> Den 06.11.2014 00:45, skrev Matthias Klein:
>> The model B and B+ differ in the GPIO lines for ACT and PWR leds, and the
>> I2S interface.
>>
>> Signed-off-by: Matthias Klein <matthias.klein@linux.com>
>> ---
>> Changes in v2:
>> - move the common parts between the B and B+ model into the new
>> bcm2835-rpi.dtsi file
>>
>> - add the I2S signals to the B+ file which fix the problem that USB is
>> not working
>>    with the current bcm2835-rpi-b.dts file on the B+.
>> ---
> <snip>
>> +&gpio {
>> +    pinctrl-names = "default";
>> +
>> +    gpioout: gpioout {
>> +        brcm,pins = <6>;
>> +        brcm,function = <1>; /* GPIO out */
>> +    };
>> +
>> +    alt0: alt0 {
>> +        brcm,pins = <0 1 2 3 4 5 7 8 9 10 11 14 15 40 45>;
>> +        brcm,function = <4>; /* alt0 */
>> +    };
>> +
>> +    alt3: alt3 {
>> +        brcm,pins = <48 49 50 51 52 53>;
>> +        brcm,function = <7>; /* alt3 */
>> +    };
>> +};
>
> AFAIK these pins will always be configured regardless of whether they
> are used by a driver or not.

Yes.

> Could we do something like this for SPI and I2C, configuring only when
> needed?
...
> &spi {
>     pinctrl-names = "default";
>     pinctrl-0 = <&spi_pins>;
> };

It's certainly possible, but I don't really see any advantage. I'd much
rather see the pinmux set up correctly all in one go as early as possible.

>> +&i2c0 {
>> +    status = "okay";
>> +    clock-frequency = <100000>;
>> +};
>> +
>> +&i2c1 {
>> +    status = "okay";
>> +    clock-frequency = <100000>;
>> +};
>> +
>
> Should the I2C busses be enabled by default?

Yes, I think so. Whichever I2C controllers are actually connected to
something (even bare pins on an IO connector) should be enabled by the
DT, so that they're available for use.

> On Raspian, i2c is disabled
> by blacklisting the module (/etc/modprobe.d/raspi-blacklist.conf).
> At least i2c0 should be left disabled due to the HAT EEPROM and camera.
> The bus number has also changed with revisions:
> http://www.raspberrypi.org/forums/viewtopic.php?p=603950#p603950

It sounds like for I2C-0 on the B+ should use the i2c-mux-pinctrl.c to
switch the bus between the two destinations as required, although we'd
have to confirm with Broadcom or the RPi Foundation that that would work
with this SoC.

There's certainly no reason to believe that the kernel wouldn't want to
read the HAT EEPROM. After all, it has to identify what's connected there.

Re: [PATCH v2] ARM: bcm2835: add device tree for Raspberry Pi model B+

[Noralf Tronnes]

Den 07.11.2014 05:22, skrev Stephen Warren:
> On 11/06/2014 12:36 PM, Noralf Tronnes wrote:
>> Den 06.11.2014 00:45, skrev Matthias Klein:
>>> The model B and B+ differ in the GPIO lines for ACT and PWR leds, and the
>>> I2S interface.
>>>
>>> Signed-off-by: Matthias Klein <matthias.klein@linux.com>
>>> ---
>>> Changes in v2:
>>> - move the common parts between the B and B+ model into the new
>>> bcm2835-rpi.dtsi file
>>>
>>> - add the I2S signals to the B+ file which fix the problem that USB is
>>> not working
>>>     with the current bcm2835-rpi-b.dts file on the B+.
>>> ---
>> <snip>
>>> +&gpio {
>>> +    pinctrl-names = "default";
>>> +
>>> +    gpioout: gpioout {
>>> +        brcm,pins = <6>;
>>> +        brcm,function = <1>; /* GPIO out */
>>> +    };
>>> +
>>> +    alt0: alt0 {
>>> +        brcm,pins = <0 1 2 3 4 5 7 8 9 10 11 14 15 40 45>;
>>> +        brcm,function = <4>; /* alt0 */
>>> +    };
>>> +
>>> +    alt3: alt3 {
>>> +        brcm,pins = <48 49 50 51 52 53>;
>>> +        brcm,function = <7>; /* alt3 */
>>> +    };
>>> +};
>> AFAIK these pins will always be configured regardless of whether they
>> are used by a driver or not.
> Yes.
>
>> Could we do something like this for SPI and I2C, configuring only when
>> needed?
> ...
>> &spi {
>>      pinctrl-names = "default";
>>      pinctrl-0 = <&spi_pins>;
>> };
> It's certainly possible, but I don't really see any advantage. I'd much
> rather see the pinmux set up correctly all in one go as early as possible.
>
>>> +&i2c0 {
>>> +    status = "okay";
>>> +    clock-frequency = <100000>;
>>> +};
>>> +
>>> +&i2c1 {
>>> +    status = "okay";
>>> +    clock-frequency = <100000>;
>>> +};
>>> +
>> Should the I2C busses be enabled by default?
> Yes, I think so. Whichever I2C controllers are actually connected to
> something (even bare pins on an IO connector) should be enabled by the
> DT, so that they're available for use.
What makes i2c so special that it should be enabled by default?
SPI is not enabled and not 1wire, i2s, lirc either, they must be explicitly
enabled. The problem I see, is that this is a newbie platform, and having
pins driven increases the chance of shorting something.
And it's quite easy to enable these devices with fdtput.

>> On Raspian, i2c is disabled
>> by blacklisting the module (/etc/modprobe.d/raspi-blacklist.conf).
>> At least i2c0 should be left disabled due to the HAT EEPROM and camera.
>> The bus number has also changed with revisions:
>> http://www.raspberrypi.org/forums/viewtopic.php?p=603950#p603950
> It sounds like for I2C-0 on the B+ should use the i2c-mux-pinctrl.c to
> switch the bus between the two destinations as required, although we'd
> have to confirm with Broadcom or the RPi Foundation that that would work
> with this SoC.
>
> There's certainly no reason to believe that the kernel wouldn't want to
> read the HAT EEPROM. After all, it has to identify what's connected there.
This will happen solely in the firmware. The firmware reads the eeprom,
and if it contains a DT fragment, it is merged with the dtb before handing
it over to the kernel. As far as I know, this hasn't been implemented yet.

I asked if we couldn't use u-boot as the boot loader, but I was turned down.
Personally I'm not happy about putting a lot stuff in a closed firmware,
especially on a platform dedicated to getting kids into programming.

 From the HAT specification:
GPIO pins ID_SC and ID_SD (GPIO0 and GPIO1) are reserved for use solely
for board detection / identification. The only allowed connections to
the ID_ pins are an ID EEPROM plus 3.9K pull up resistors. Do not connect
anything else to these pins!

Ref: 
https://github.com/raspberrypi/hats/blob/master/designguide.md#gpio-requirements

I asked in the forum if I could use an app for writing to the eeprom to
change things like display rotation in the DT fragment, but was told 
that this
was a no-no. i2c0 is also used together with the camera port, which is then
controlled by the firmware.

When talking about firmware, there's also a /boot/dt-blob.bin used for 
configuring pins and clocks.
https://github.com/raspberrypi/documentation/blob/master/configuration/pin-configuration.md
This is the source of that file: 
https://github.com/raspberrypi/documentation/blob/master/configuration/images/dt-blob.dts
I haven't studied this, so I don't know how/if it affects our work here.

Re: [PATCH v2] ARM: bcm2835: add device tree for Raspberry Pi model B+

[Gordon Hollingworth]

Resend: HTML less...

On 7 November 2014 17:07, Gordon Hollingworth <gordon@holliweb.co.uk> wrote:
>
>
> On 7 November 2014 16:20, Noralf Tronnes <notro@tronnes.org> wrote:
>>
>> Den 07.11.2014 05:22, skrev Stephen Warren:
>>>
>>> On 11/06/2014 12:36 PM, Noralf Tronnes wrote:
>>>>
>>>> Den 06.11.2014 00:45, skrev Matthias Klein:
>>>>>
>>>>> The model B and B+ differ in the GPIO lines for ACT and PWR leds, and
>>>>> the
>>>>> I2S interface.
>>>>>
>>>>> Signed-off-by: Matthias Klein <matthias.klein@linux.com>
>>>>> ---
>>>>> Changes in v2:
>>>>> - move the common parts between the B and B+ model into the new
>>>>> bcm2835-rpi.dtsi file
>>>>>
>>>>> - add the I2S signals to the B+ file which fix the problem that USB is
>>>>> not working
>>>>>     with the current bcm2835-rpi-b.dts file on the B+.
>>>>> ---
>>>>
>>>> <snip>
>>>>>
>>>>> +&gpio {
>>>>> +    pinctrl-names = "default";
>>>>> +
>>>>> +    gpioout: gpioout {
>>>>> +        brcm,pins = <6>;
>>>>> +        brcm,function = <1>; /* GPIO out */
>>>>> +    };
>>>>> +
>>>>> +    alt0: alt0 {
>>>>> +        brcm,pins = <0 1 2 3 4 5 7 8 9 10 11 14 15 40 45>;
>>>>> +        brcm,function = <4>; /* alt0 */
>>>>> +    };
>>>>> +
>>>>> +    alt3: alt3 {
>>>>> +        brcm,pins = <48 49 50 51 52 53>;
>>>>> +        brcm,function = <7>; /* alt3 */
>>>>> +    };
>>>>> +};
>>>>
>>>> AFAIK these pins will always be configured regardless of whether they
>>>> are used by a driver or not.
>>>
>>> Yes.
>>>
>>>> Could we do something like this for SPI and I2C, configuring only when
>>>> needed?
>>>
>>> ...
>>>>
>>>> &spi {
>>>>      pinctrl-names = "default";
>>>>      pinctrl-0 = <&spi_pins>;
>>>> };
>>>
>>> It's certainly possible, but I don't really see any advantage. I'd much
>>> rather see the pinmux set up correctly all in one go as early as
>>> possible.
>>>
>>>>> +&i2c0 {
>>>>> +    status = "okay";
>>>>> +    clock-frequency = <100000>;
>>>>> +};
>>>>> +
>>>>> +&i2c1 {
>>>>> +    status = "okay";
>>>>> +    clock-frequency = <100000>;
>>>>> +};
>>>>> +
>>>>
>>>> Should the I2C busses be enabled by default?
>>>
>>> Yes, I think so. Whichever I2C controllers are actually connected to
>>> something (even bare pins on an IO connector) should be enabled by the
>>> DT, so that they're available for use.
>>
>> What makes i2c so special that it should be enabled by default?
>> SPI is not enabled and not 1wire, i2s, lirc either, they must be
>> explicitly
>> enabled. The problem I see, is that this is a newbie platform, and having
>> pins driven increases the chance of shorting something.
>> And it's quite easy to enable these devices with fdtput.
>>
>>>> On Raspian, i2c is disabled
>>>> by blacklisting the module (/etc/modprobe.d/raspi-blacklist.conf).
>>>> At least i2c0 should be left disabled due to the HAT EEPROM and camera.
>>>> The bus number has also changed with revisions:
>>>> http://www.raspberrypi.org/forums/viewtopic.php?p=603950#p603950
>>>
>>> It sounds like for I2C-0 on the B+ should use the i2c-mux-pinctrl.c to
>>> switch the bus between the two destinations as required, although we'd
>>> have to confirm with Broadcom or the RPi Foundation that that would work
>>> with this SoC.
>>>
>>> There's certainly no reason to believe that the kernel wouldn't want to
>>> read the HAT EEPROM. After all, it has to identify what's connected
>>> there.
>>
>> This will happen solely in the firmware. The firmware reads the eeprom,
>> and if it contains a DT fragment, it is merged with the dtb before handing
>> it over to the kernel. As far as I know, this hasn't been implemented yet.
>>
>> I asked if we couldn't use u-boot as the boot loader, but I was turned
>> down.
>> Personally I'm not happy about putting a lot stuff in a closed firmware,
>> especially on a platform dedicated to getting kids into programming.
>>
>> From the HAT specification:
>> GPIO pins ID_SC and ID_SD (GPIO0 and GPIO1) are reserved for use solely
>> for board detection / identification. The only allowed connections to
>> the ID_ pins are an ID EEPROM plus 3.9K pull up resistors. Do not connect
>> anything else to these pins!
>>
>> Ref:
>> https://github.com/raspberrypi/hats/blob/master/designguide.md#gpio-requirements
>>
>> I asked in the forum if I could use an app for writing to the eeprom to
>> change things like display rotation in the DT fragment, but was told that
>> this
>> was a no-no. i2c0 is also used together with the camera port, which is
>> then
>> controlled by the firmware.
>
>
> The idea with the HAT specification is to provide a mechanism for hardware
> developers to add their drivers and configuration in such a way as to avoid
> 'special' kernel builds for particular bits of hardware (this was a problem
> with a number of DAC add on boards for the Pi)
>
> There is software in the Raspberry Pi github to edit the EEPROM if you
> really want to (which would allow you to do that) but this isn't really the
> point for normal users and shouldn't be encouraged (just in case they break
> the information in the EEPROM).
>
>>
>>
>> When talking about firmware, there's also a /boot/dt-blob.bin used for
>> configuring pins and clocks.
>>
>> https://github.com/raspberrypi/documentation/blob/master/configuration/pin-configuration.md
>> This is the source of that file:
>> https://github.com/raspberrypi/documentation/blob/master/configuration/images/dt-blob.dts
>> I haven't studied this, so I don't know how/if it affects our work here.
>>
>
> The dt-blob.bin is a device tree blob that is specifically used to configure
> the binary blob initial gpio settings, if you look at the documentation
> you'll see the standard default dt-blob.bin  In there are a number of
> different nodes specifically for the videocore blob, firstly they set up the
> gpio alternate settings and pin defaults and also assign pin numbers to pin
> functions for the binary blob, such as the HDMI_ATTACHED (hdmi hotplug
> gpio), obviously this pin is fixed on the B, B+, A but are programmable for
> the compute module...  This allows hardware designers a little freedom when
> assigning pins which is very important when developing new hardware.
>
> It does in some way effect you because in the long run, the two files are
> going to contain similar data (i.e. the initial state of the GPIOs and the
> alternate settings) and of course it's just bad design having to reproduce
> the same data in two places!
>
>>
>>
>> _______________________________________________
>> linux-rpi-kernel mailing list
>> linux-rpi-kernel@lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/linux-rpi-kernel
>
>

Re: [PATCH v2] ARM: bcm2835: add device tree for Raspberry Pi model B+

[Stephen Warren]

On 11/07/2014 09:20 AM, Noralf Tronnes wrote:
> Den 07.11.2014 05:22, skrev Stephen Warren:
>> On 11/06/2014 12:36 PM, Noralf Tronnes wrote:
>>> Den 06.11.2014 00:45, skrev Matthias Klein:
>>>> The model B and B+ differ in the GPIO lines for ACT and PWR leds,
>>>> and the
>>>> I2S interface.
...
>>>> +&i2c0 {
>>>> +    status = "okay";
>>>> +    clock-frequency = <100000>;
>>>> +};
>>>> +
>>>> +&i2c1 {
>>>> +    status = "okay";
>>>> +    clock-frequency = <100000>;
>>>> +};
>>>> +
>>>
>>> Should the I2C busses be enabled by default?
>>
>> Yes, I think so. Whichever I2C controllers are actually connected to
>> something (even bare pins on an IO connector) should be enabled by the
>> DT, so that they're available for use.
>
> What makes i2c so special that it should be enabled by default?

I2C itself as a bus requires no configuration. If all you represent in
DT is an enabled controller, it's quite possible for SW to then go and
use the I2C bus in SW. Thus bus can be scanned to detect devices. The
user can instruct SW what address to communicate with and how. Etc.

> SPI is not enabled

SPI devices require extra configuration; the chip-select must be
configured for each device. It doesn't make sense to enable the SPI bus
without actually defining which devices are attached to it.

> and not 1wire, i2s, lirc either, they must be explicitly
> enabled.

I don't think there is a 1-wire controller on the RPi? There's certainly
no pin on the expansion header (at least in A/B/B-rev2) that's labeled
in a way that indicates 1-wire is the "default" purpose.

I2S typically requires other things to be set up to be useful, e.g.
communication with a (typically I2C-based) CODEC to configure it before
it'll accept I2S data.

lirc is more of a SW concept.

> The problem I see, is that this is a newbie platform, and having
> pins driven increases the chance of shorting something.

In the case of I2C at least, the pins are always pulled high by the I2C
pull-ups. Admittedly that's a weak drive. Either way though, you simply
need to take care when hooking things up. There's simply no way for SW
to make it completely fool-proof.

> And it's quite easy to enable these devices with fdtput.

DT include files might be better, or DT overlays.

>>> On Raspian, i2c is disabled
>>> by blacklisting the module (/etc/modprobe.d/raspi-blacklist.conf).
>>> At least i2c0 should be left disabled due to the HAT EEPROM and camera.
>>> The bus number has also changed with revisions:
>>> http://www.raspberrypi.org/forums/viewtopic.php?p=603950#p603950
>>
>> It sounds like for I2C-0 on the B+ should use the i2c-mux-pinctrl.c to
>> switch the bus between the two destinations as required, although we'd
>> have to confirm with Broadcom or the RPi Foundation that that would work
>> with this SoC.
>>
>> There's certainly no reason to believe that the kernel wouldn't want to
>> read the HAT EEPROM. After all, it has to identify what's connected
>> there.
>
> This will happen solely in the firmware.

Oh, given your comments below, does the firmware completely own I2C-0
both when it's used for EEPROM ID *and* when driving the camera module?
I had assumed all control of the camera module would be performed via
drivers in the Linux kernel, and hence I2C-0 would be driven by the
Linux kernel I2C driver. If this isn't the case, we should indeed make
sure that the kernel DTs don't touch the pinmux for the camera I2C port
at all. It'd also be quite disappointing, since it would make it
essentially impossible for anyone outside the RPi Foundation to connect
a different camera module that required different programming over I2C.

> The firmware reads the eeprom,
> and if it contains a DT fragment, it is merged with the dtb before handing
> it over to the kernel. As far as I know, this hasn't been implemented yet.

Hmm. It sounds like it'd be much better if the EEPROM contained a board
ID, and the board ID was passed into the kernel, which then used the
(recently merged upstream) DT overlays feature to load the overlay DT
once that kernel boots. IIUC this would also allow unloading and
reloading the overlay DT during development of the DT overlay.

> I asked if we couldn't use u-boot as the boot loader, but I was turned
> down.

I assume you mean in the official SD card images? Nothing is stopping
anyone from using it; I use it without issue for example.

> Personally I'm not happy about putting a lot stuff in a closed firmware,
> especially on a platform dedicated to getting kids into programming.

Indeed.

> From the HAT specification:
> GPIO pins ID_SC and ID_SD (GPIO0 and GPIO1) are reserved for use solely
> for board detection / identification. The only allowed connections to
> the ID_ pins are an ID EEPROM plus 3.9K pull up resistors. Do not connect
> anything else to these pins!
> 
> Ref:
> https://github.com/raspberrypi/hats/blob/master/designguide.md#gpio-requirements
> 
> I asked in the forum if I could use an app for writing to the eeprom to
> change things like display rotation in the DT fragment, but was told
> that this
> was a no-no. i2c0 is also used together with the camera port, which is then
> controlled by the firmware.

Oh, I see. See what I said about I2C-0 above.

> When talking about firmware, there's also a /boot/dt-blob.bin used for
> configuring pins and clocks.
> https://github.com/raspberrypi/documentation/blob/master/configuration/pin-configuration.md
> 
> This is the source of that file:
> https://github.com/raspberrypi/documentation/blob/master/configuration/images/dt-blob.dts
> 
> I haven't studied this, so I don't know how/if it affects our work here.

Hmm. DT blobs for firmware:-(

Re: [PATCH v2] ARM: bcm2835: add device tree for Raspberry Pi model B+

[Stephen Warren]

On 11/07/2014 10:12 AM, Gordon Hollingworth wrote:
> Resend: HTML less...
> On 7 November 2014 17:07, Gordon Hollingworth <gordon@holliweb.co.uk> wrote:
>> On 7 November 2014 16:20, Noralf Tronnes <notro@tronnes.org> wrote:
...
>>> From the HAT specification:
>>> GPIO pins ID_SC and ID_SD (GPIO0 and GPIO1) are reserved for use solely
>>> for board detection / identification. The only allowed connections to
>>> the ID_ pins are an ID EEPROM plus 3.9K pull up resistors. Do not connect
>>> anything else to these pins!
>>>
>>> Ref:
>>> https://github.com/raspberrypi/hats/blob/master/designguide.md#gpio-requirements
>>>
>>> I asked in the forum if I could use an app for writing to the eeprom to
>>> change things like display rotation in the DT fragment, but was told that this
>>> was a no-no. i2c0 is also used together with the camera port, which is then
>>> controlled by the firmware.
>>
>> The idea with the HAT specification is to provide a mechanism for hardware
>> developers to add their drivers and configuration in such a way as to avoid
>> 'special' kernel builds for particular bits of hardware (this was a problem
>> with a number of DAC add on boards for the Pi)

Have you considered using the (recently merged upstream) DT overlay
mechanism instead? In this case, the board EEPROM would simply provide a
unique ID for the board. Linux would obtain this ID somehow (perhaps
directly reading the EEPROM on boot, or perhaps having some special DT
node indicating which device was present if only the VC firmware can
access the EEPROM). The ID then gets used to look up a DT overlay file
that the kernel loads and merges into its DT at run-time. The benefit
here is that the DT overlay is a file in the filesystem, and can be
easily modified or replaced to fix issues, especially when first
developing that DT for a new HAT. This is all based on the way the
BeagleBone Black handles its capes. Having RPi work in a standard way
that's also used on other boards leverages people's knowledge/experience
across different HW stacks. Standards are good!

If I want to use U-Boot as a bootloader on the Pi, is there a VC
firmware mailbox message that the firmware can use to read the content
of the EEPROM (or the VC firmware's cached copy of it?) Or, must U-Boot
be modified to accept a DT, extract information from it, and then modify
the DT it subsequently passes to the kernel based on the DT it was passed?

Re: [PATCH v2] ARM: bcm2835: add device tree for Raspberry Pi model B+

[Gordon Hollingworth]

On 8 November 2014 06:17, Stephen Warren <swarren@wwwdotorg.org> wrote:
> On 11/07/2014 10:12 AM, Gordon Hollingworth wrote:
>> Resend: HTML less...
>> On 7 November 2014 17:07, Gordon Hollingworth <gordon@holliweb.co.uk> wrote:
>>> On 7 November 2014 16:20, Noralf Tronnes <notro@tronnes.org> wrote:
> ...
>>>> From the HAT specification:
>>>> GPIO pins ID_SC and ID_SD (GPIO0 and GPIO1) are reserved for use solely
>>>> for board detection / identification. The only allowed connections to
>>>> the ID_ pins are an ID EEPROM plus 3.9K pull up resistors. Do not connect
>>>> anything else to these pins!
>>>>
>>>> Ref:
>>>> https://github.com/raspberrypi/hats/blob/master/designguide.md#gpio-requirements
>>>>
>>>> I asked in the forum if I could use an app for writing to the eeprom to
>>>> change things like display rotation in the DT fragment, but was told that this
>>>> was a no-no. i2c0 is also used together with the camera port, which is then
>>>> controlled by the firmware.
>>>
>>> The idea with the HAT specification is to provide a mechanism for hardware
>>> developers to add their drivers and configuration in such a way as to avoid
>>> 'special' kernel builds for particular bits of hardware (this was a problem
>>> with a number of DAC add on boards for the Pi)
>
> Have you considered using the (recently merged upstream) DT overlay
> mechanism instead? In this case, the board EEPROM would simply provide a
> unique ID for the board. Linux would obtain this ID somehow (perhaps
> directly reading the EEPROM on boot, or perhaps having some special DT
> node indicating which device was present if only the VC firmware can
> access the EEPROM). The ID then gets used to look up a DT overlay file
> that the kernel loads and merges into its DT at run-time. The benefit
> here is that the DT overlay is a file in the filesystem, and can be
> easily modified or replaced to fix issues, especially when first
> developing that DT for a new HAT. This is all based on the way the
> BeagleBone Black handles its capes. Having RPi work in a standard way
> that's also used on other boards leverages people's knowledge/experience
> across different HW stacks. Standards are good!

Sounds good, I like the idea of implementing both capabilities, since
it is possible
for the HAT EEPROM to contain different atoms containing different information
it seems the HAT could contain a value overlay file to integrate and
an ID.  Then
the bootloader could check to see which one it will use based on whether a valid
overlay file exists.  The overlay file can then override the EEPROM, the reason
this is useful is because often the time delay between releasing some
new hardware
and getting it's software into the kernel and then getting the kernel
into a Raspbian
release is quite long (mostly due to all the steps + testing + lead times on SD
card images etc).

>
> If I want to use U-Boot as a bootloader on the Pi, is there a VC
> firmware mailbox message that the firmware can use to read the content
> of the EEPROM (or the VC firmware's cached copy of it?) Or, must U-Boot
> be modified to accept a DT, extract information from it, and then modify
> the DT it subsequently passes to the kernel based on the DT it was passed?

Currently there is no interface to achieve this, but I'm having to
implement something
similar for accessing the touchscreen on the new Raspberry Pi DSI
screen so it seems
like it'd be a good addition.

Re: [PATCH v2] ARM: bcm2835: add device tree for Raspberry Pi model B+

[Lee Jones]

> The model B and B+ differ in the GPIO lines for ACT and PWR leds, and the
> I2S interface.
> 
> Signed-off-by: Matthias Klein <matthias.klein@linux.com>
> ---
> Changes in v2:
> - move the common parts between the B and B+ model into the new bcm2835-rpi.dtsi file
> 
> - add the I2S signals to the B+ file which fix the problem that USB is not working
>   with the current bcm2835-rpi-b.dts file on the B+.
> ---
>  arch/arm/boot/dts/Makefile               |  1 +
>  arch/arm/boot/dts/bcm2835-rpi-b-plus.dts | 30 +++++++++++++++++++
>  arch/arm/boot/dts/bcm2835-rpi-b.dts      | 46 ++--------------------------
>  arch/arm/boot/dts/bcm2835-rpi.dtsi       | 51 ++++++++++++++++++++++++++++++++
>  4 files changed, 85 insertions(+), 43 deletions(-)
>  create mode 100644 arch/arm/boot/dts/bcm2835-rpi-b-plus.dts
>  create mode 100644 arch/arm/boot/dts/bcm2835-rpi.dtsi

Sorry for the delay.  I thought RPi world was exceptionally quiet, but
in fact I had issues with my newly setup mailbox and filters.  All
rectified now in any case.

It might be worth noting that this will not likely land in v3.19, as
we are one step removed from Linus (i.e. via ARM SoC) and they usually
like to have pull-requests in by -rc5.  Unless anyone stamps their
feet, I'll be sending this no sooner than v3.20.

Patch applied, thanks.

[...]

Re: [PATCH v2] ARM: bcm2835: add device tree for Raspberry Pi model B+

[Stephen Warren]

On 11/19/2014 08:29 AM, Lee Jones wrote:
>> The model B and B+ differ in the GPIO lines for ACT and PWR leds, and the
>> I2S interface.
>>
>> Signed-off-by: Matthias Klein <matthias.klein@linux.com>
>> ---
>> Changes in v2:
>> - move the common parts between the B and B+ model into the new bcm2835-rpi.dtsi file
>>
>> - add the I2S signals to the B+ file which fix the problem that USB is not working
>>    with the current bcm2835-rpi-b.dts file on the B+.
>> ---
>>   arch/arm/boot/dts/Makefile               |  1 +
>>   arch/arm/boot/dts/bcm2835-rpi-b-plus.dts | 30 +++++++++++++++++++
>>   arch/arm/boot/dts/bcm2835-rpi-b.dts      | 46 ++--------------------------
>>   arch/arm/boot/dts/bcm2835-rpi.dtsi       | 51 ++++++++++++++++++++++++++++++++
>>   4 files changed, 85 insertions(+), 43 deletions(-)
>>   create mode 100644 arch/arm/boot/dts/bcm2835-rpi-b-plus.dts
>>   create mode 100644 arch/arm/boot/dts/bcm2835-rpi.dtsi
>
> Sorry for the delay.  I thought RPi world was exceptionally quiet, but
> in fact I had issues with my newly setup mailbox and filters.  All
> rectified now in any case.
>
> It might be worth noting that this will not likely land in v3.19, as
> we are one step removed from Linus (i.e. via ARM SoC) and they usually
> like to have pull-requests in by -rc5.  Unless anyone stamps their
> feet, I'll be sending this no sooner than v3.20.

-rc6 is the usual cut-off, and the arm-soc maintainers have said that's 
not always a very strict cut-off; it depends on how invasive the patch 
is (which this isn't) and whether the patch has been in linux-next 
already before getting into arm-soc (and linux-rpi.git's for-next branch 
is in linux-next).

Re: [PATCH v2] ARM: bcm2835: add device tree for Raspberry Pi model B+

[Lee Jones]

On Wed, 19 Nov 2014, Stephen Warren wrote:

> On 11/19/2014 08:29 AM, Lee Jones wrote:
> >>The model B and B+ differ in the GPIO lines for ACT and PWR leds, and the
> >>I2S interface.
> >>
> >>Signed-off-by: Matthias Klein <matthias.klein@linux.com>
> >>---
> >>Changes in v2:
> >>- move the common parts between the B and B+ model into the new bcm2835-rpi.dtsi file
> >>
> >>- add the I2S signals to the B+ file which fix the problem that USB is not working
> >>   with the current bcm2835-rpi-b.dts file on the B+.
> >>---
> >>  arch/arm/boot/dts/Makefile               |  1 +
> >>  arch/arm/boot/dts/bcm2835-rpi-b-plus.dts | 30 +++++++++++++++++++
> >>  arch/arm/boot/dts/bcm2835-rpi-b.dts      | 46 ++--------------------------
> >>  arch/arm/boot/dts/bcm2835-rpi.dtsi       | 51 ++++++++++++++++++++++++++++++++
> >>  4 files changed, 85 insertions(+), 43 deletions(-)
> >>  create mode 100644 arch/arm/boot/dts/bcm2835-rpi-b-plus.dts
> >>  create mode 100644 arch/arm/boot/dts/bcm2835-rpi.dtsi
> >
> >Sorry for the delay.  I thought RPi world was exceptionally quiet, but
> >in fact I had issues with my newly setup mailbox and filters.  All
> >rectified now in any case.
> >
> >It might be worth noting that this will not likely land in v3.19, as
> >we are one step removed from Linus (i.e. via ARM SoC) and they usually
> >like to have pull-requests in by -rc5.  Unless anyone stamps their
> >feet, I'll be sending this no sooner than v3.20.
> 
> -rc6 is the usual cut-off, and the arm-soc maintainers have said
> that's not always a very strict cut-off; it depends on how invasive
> the patch is (which this isn't) and whether the patch has been in
> linux-next already before getting into arm-soc (and linux-rpi.git's
> for-next branch is in linux-next).

Okay, looks like I'm off-by-one -- I ways thought the cut-off was
-rc5.  Nevertheless, I'll have the patch in -next by tonight (tomorrow
at the latest, as it's getting late and I need to wait for a previous
test-build to finish before I can run this patch), let it stew there
for a couple of weeks and fire them a pull-request around -rc6 and see
what happens.