[RFC] ARM: dts: Add i2cmux-pinctrl config to Raspberry Pi i2c-0

Discussion:

Dave Stevenson

2017-11-20 14:09:20 UTC

The first i2c controller on the Raspberry Pi family can
be pinmuxed to either GPIOs 0&1, 28&29, or 44&45.
The default has always been 0&1 as those are exposed on
the 40 pin GPIO header of the more recent models.
GPIOs 28&29 on Pi 0/1/2/3 and GPIOs 44&45 on Pi3 are
used for i2c to the DSI display and the camera module.

The i2c-mux-pinctrl driver allows pinctrl setup to be used
to expose the GPIO sets as alternate i2c adapters. This
patch configures that driver to expose two adapters -
i2c0 on GPIOs 0&1, and i2c_csi_dsi on the correct GPIOs for
the camera and display.
(This could be extended to expose all 3 options on the CM
and CM3, but there isn't a pressing case for that at present).

The one quirk with the i2cmux-pinctrl driver is that the
parent controller still exists as an i2c adapter which
will be connnected to whichever pins were last requested
(or an optional idle setting). That adapter appears first so
is numbered as adapter 0, whilst the child ports end up as
adapters 3&4. These can be renumbered through using DT aliases
if we wish to retain the ordering of adapters (this will be
required downstream).

Signed-off-by: Dave Stevenson <***@raspberrypi.org>
---

Hi All.

Thoughts from people?
Do others care about access to the alternate pin muxing options for BSC0?
Is the location of these changes acceptable?
Objections on naming of nodes?

To get back to the current adapter numbering, an aliases section
such as
/ {
aliases {
i2c10 = &i2c0_parent;
i2c0 = &i2c0;
i2c1 = &i2c1;
i2c2 = &i2c2;
i2c4 = &i2c_csi_dsi;
};
};
is needed somewhere. Yes i2c1 and i2c2 are needed otherwise they
become i2c11 and i2c12 as dynamically numbered adapters come after
all statically defined ones.

Thanks
Dave

arch/arm/boot/dts/bcm2835-rpi-a-plus.dts | 1 +
arch/arm/boot/dts/bcm2835-rpi-a.dts | 1 +
arch/arm/boot/dts/bcm2835-rpi-b-plus.dts | 1 +
arch/arm/boot/dts/bcm2835-rpi-b-rev2.dts | 1 +
arch/arm/boot/dts/bcm2835-rpi-b.dts | 1 +
arch/arm/boot/dts/bcm2835-rpi-zero-w.dts | 1 +
arch/arm/boot/dts/bcm2835-rpi-zero.dts | 1 +
arch/arm/boot/dts/bcm2835-rpi.dtsi | 4 +---
arch/arm/boot/dts/bcm2836-rpi-2-b.dts | 1 +
arch/arm/boot/dts/bcm2837-rpi-3-b.dts | 1 +
arch/arm/boot/dts/bcm283x-rpi-i2c0mux_0_28.dtsi | 4 ++++
arch/arm/boot/dts/bcm283x-rpi-i2c0mux_0_44.dtsi | 4 ++++
arch/arm/boot/dts/bcm283x.dtsi | 24 +++++++++++++++++++++++-
13 files changed, 41 insertions(+), 4 deletions(-)
create mode 100644 arch/arm/boot/dts/bcm283x-rpi-i2c0mux_0_28.dtsi
create mode 100644 arch/arm/boot/dts/bcm283x-rpi-i2c0mux_0_44.dtsi

diff --git a/arch/arm/boot/dts/bcm2835-rpi-a-plus.dts b/arch/arm/boot/dts/bcm2835-rpi-a-plus.dts
index 9f86649..7308928 100644
--- a/arch/arm/boot/dts/bcm2835-rpi-a-plus.dts
+++ b/arch/arm/boot/dts/bcm2835-rpi-a-plus.dts
@@ -2,6 +2,7 @@
#include "bcm2835.dtsi"
#include "bcm2835-rpi.dtsi"
#include "bcm283x-rpi-usb-host.dtsi"
+#include "bcm283x-rpi-i2c0mux_0_28.dtsi"

/ {
compatible = "raspberrypi,model-a-plus", "brcm,bcm2835";
diff --git a/arch/arm/boot/dts/bcm2835-rpi-a.dts b/arch/arm/boot/dts/bcm2835-rpi-a.dts
index 4b1af06..5b075e8 100644
--- a/arch/arm/boot/dts/bcm2835-rpi-a.dts
+++ b/arch/arm/boot/dts/bcm2835-rpi-a.dts
@@ -2,6 +2,7 @@
#include "bcm2835.dtsi"
#include "bcm2835-rpi.dtsi"
#include "bcm283x-rpi-usb-host.dtsi"
+#include "bcm283x-rpi-i2c0mux_0_28.dtsi"

/ {
compatible = "raspberrypi,model-a", "brcm,bcm2835";
diff --git a/arch/arm/boot/dts/bcm2835-rpi-b-plus.dts b/arch/arm/boot/dts/bcm2835-rpi-b-plus.dts
index a846f1e..81c8927 100644
--- a/arch/arm/boot/dts/bcm2835-rpi-b-plus.dts
+++ b/arch/arm/boot/dts/bcm2835-rpi-b-plus.dts
@@ -3,6 +3,7 @@
#include "bcm2835-rpi.dtsi"
#include "bcm283x-rpi-smsc9514.dtsi"
#include "bcm283x-rpi-usb-host.dtsi"
+#include "bcm283x-rpi-i2c0mux_0_28.dtsi"

/ {
compatible = "raspberrypi,model-b-plus", "brcm,bcm2835";
diff --git a/arch/arm/boot/dts/bcm2835-rpi-b-rev2.dts b/arch/arm/boot/dts/bcm2835-rpi-b-rev2.dts
index e860964..8d9d102 100644
--- a/arch/arm/boot/dts/bcm2835-rpi-b-rev2.dts
+++ b/arch/arm/boot/dts/bcm2835-rpi-b-rev2.dts
@@ -3,6 +3,7 @@
#include "bcm2835-rpi.dtsi"
#include "bcm283x-rpi-smsc9512.dtsi"
#include "bcm283x-rpi-usb-host.dtsi"
+#include "bcm283x-rpi-i2c0mux_0_28.dtsi"

/ {
compatible = "raspberrypi,model-b-rev2", "brcm,bcm2835";
diff --git a/arch/arm/boot/dts/bcm2835-rpi-b.dts b/arch/arm/boot/dts/bcm2835-rpi-b.dts
index 5d77f3f..a25159d 100644
--- a/arch/arm/boot/dts/bcm2835-rpi-b.dts
+++ b/arch/arm/boot/dts/bcm2835-rpi-b.dts
@@ -3,6 +3,7 @@
#include "bcm2835-rpi.dtsi"
#include "bcm283x-rpi-smsc9512.dtsi"
#include "bcm283x-rpi-usb-host.dtsi"
+#include "bcm283x-rpi-i2c0mux_0_28.dtsi"

/ {
compatible = "raspberrypi,model-b", "brcm,bcm2835";
diff --git a/arch/arm/boot/dts/bcm2835-rpi-zero-w.dts b/arch/arm/boot/dts/bcm2835-rpi-zero-w.dts
index 82651c3..a52917f 100644
--- a/arch/arm/boot/dts/bcm2835-rpi-zero-w.dts
+++ b/arch/arm/boot/dts/bcm2835-rpi-zero-w.dts
@@ -13,6 +13,7 @@
#include "bcm2835.dtsi"
#include "bcm2835-rpi.dtsi"
#include "bcm283x-rpi-usb-host.dtsi"
+#include "bcm283x-rpi-i2c0mux_0_28.dtsi"

/ {
compatible = "raspberrypi,model-zero-w", "brcm,bcm2835";
diff --git a/arch/arm/boot/dts/bcm2835-rpi-zero.dts b/arch/arm/boot/dts/bcm2835-rpi-zero.dts
index 7036240..63ed0ce 100644
--- a/arch/arm/boot/dts/bcm2835-rpi-zero.dts
+++ b/arch/arm/boot/dts/bcm2835-rpi-zero.dts
@@ -13,6 +13,7 @@
#include "bcm2835.dtsi"
#include "bcm2835-rpi.dtsi"
#include "bcm283x-rpi-usb-otg.dtsi"
+#include "bcm283x-rpi-i2c0mux_0_28.dtsi"

/ {
compatible = "raspberrypi,model-zero", "brcm,bcm2835";
diff --git a/arch/arm/boot/dts/bcm2835-rpi.dtsi b/arch/arm/boot/dts/bcm2835-rpi.dtsi
index e36c392..46a76ec 100644
--- a/arch/arm/boot/dts/bcm2835-rpi.dtsi
+++ b/arch/arm/boot/dts/bcm2835-rpi.dtsi
@@ -44,9 +44,7 @@
};
};

-&i2c0 {
- pinctrl-names = "default";
- pinctrl-0 = <&i2c0_gpio0>;
+&i2c0_parent {
status = "okay";
clock-frequency = <100000>;
};
diff --git a/arch/arm/boot/dts/bcm2836-rpi-2-b.dts b/arch/arm/boot/dts/bcm2836-rpi-2-b.dts
index e8de414..6cea032 100644
--- a/arch/arm/boot/dts/bcm2836-rpi-2-b.dts
+++ b/arch/arm/boot/dts/bcm2836-rpi-2-b.dts
@@ -3,6 +3,7 @@
#include "bcm2835-rpi.dtsi"
#include "bcm283x-rpi-smsc9514.dtsi"
#include "bcm283x-rpi-usb-host.dtsi"
+#include "bcm283x-rpi-i2c0mux_0_28.dtsi"

/ {
compatible = "raspberrypi,2-model-b", "brcm,bcm2836";
diff --git a/arch/arm/boot/dts/bcm2837-rpi-3-b.dts b/arch/arm/boot/dts/bcm2837-rpi-3-b.dts
index 20725ca..09a4b43 100644
--- a/arch/arm/boot/dts/bcm2837-rpi-3-b.dts
+++ b/arch/arm/boot/dts/bcm2837-rpi-3-b.dts
@@ -3,6 +3,7 @@
#include "bcm2835-rpi.dtsi"
#include "bcm283x-rpi-smsc9514.dtsi"
#include "bcm283x-rpi-usb-host.dtsi"
+#include "bcm283x-rpi-i2c0mux_0_44.dtsi"

/ {
compatible = "raspberrypi,3-model-b", "brcm,bcm2837";
diff --git a/arch/arm/boot/dts/bcm283x-rpi-i2c0mux_0_28.dtsi b/arch/arm/boot/dts/bcm283x-rpi-i2c0mux_0_28.dtsi
new file mode 100644
index 0000000..d2915a1
--- /dev/null
+++ b/arch/arm/boot/dts/bcm283x-rpi-i2c0mux_0_28.dtsi
@@ -0,0 +1,4 @@
+&i2c0_mux {
+ pinctrl-0 = <&i2c0_gpio0>;
+ pinctrl-1 = <&i2c0_gpio28>;
+};
diff --git a/arch/arm/boot/dts/bcm283x-rpi-i2c0mux_0_44.dtsi b/arch/arm/boot/dts/bcm283x-rpi-i2c0mux_0_44.dtsi
new file mode 100644
index 0000000..15a7989
--- /dev/null
+++ b/arch/arm/boot/dts/bcm283x-rpi-i2c0mux_0_44.dtsi
@@ -0,0 +1,4 @@
+&i2c0_mux {
+ pinctrl-0 = <&i2c0_gpio0>;
+ pinctrl-1 = <&i2c0_gpio44>;
+};
diff --git a/arch/arm/boot/dts/bcm283x.dtsi b/arch/arm/boot/dts/bcm283x.dtsi
index 431dcfc..2bf24f0 100644
--- a/arch/arm/boot/dts/bcm283x.dtsi
+++ b/arch/arm/boot/dts/bcm283x.dtsi
@@ -410,7 +410,7 @@
status = "disabled";
};

- i2c0: ***@7e205000 {
+ i2c0_parent: ***@7e205000 {
compatible = "brcm,bcm2835-i2c";
reg = <0x7e205000 0x1000>;
interrupts = <2 21>;
@@ -420,6 +420,28 @@
status = "disabled";
};

+ i2c0_mux: i2c0_mux {
+ compatible = "i2c-mux-pinctrl";
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ i2c-parent = <&i2c0_parent>;
+
+ pinctrl-names = "i2c0", "i2c_csi_dsi";
+
+ i2c0: ***@0 {
+ reg = <0>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
+
+ i2c_csi_dsi: ***@1 {
+ reg = <1>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
+ };
+
***@7e206000 {
compatible = "brcm,bcm2835-pixelvalve0";
reg = <0x7e206000 0x100>;

--
2.7.4

Stephen Warren

2017-11-20 17:05:01 UTC

Permalink

On the model A and B at least, pins 28/29/44/45 are used for other
purposes, and cannot be used as I2C. It's hard/impossible to tell on the
more recent Pis since the schematics are obscured:-( This change appears
to add the I2C pinctrl mux to the original A/B, so at the very least
needs to be modified not to do that. More investigation is needed to
tell whether it's appropriate for the later models or not.

Post by Dave Stevenson
The i2c-mux-pinctrl driver allows pinctrl setup to be used
to expose the GPIO sets as alternate i2c adapters.

Yes, i2c-mux-pinctrl does exist. However, the intent is not to expose
I2C buses for every possible pinmux configuration, but rather to allow
exposing multiple mux'd I2C buses /if/ there's a specific need; if it
makes sense to do so. As far as I know, the Pi HW is designed to have a
specific static pinmux configuration for each of the I2C controllers.

Put another way: What user benefit does making this change create?

If a user has modified their HW and changed what the pins are connected
to, that's something user-specific. They should modify the DT themselves
to match that HW change. However, the default/standard DT shouldn't be
modified, since not all users will have made that HW change.

Post by Dave Stevenson
This
patch configures that driver to expose two adapters -
i2c0 on GPIOs 0&1, and i2c_csi_dsi on the correct GPIOs for
the camera and display.

Looking at the schematics for the original A/B Pi, the camera should be
controlled by the second I2C controller on GPIO pins 2/3, and the DSI
port has no I2C. On the B+ schematics, both CSI and DSI use the same I2C
controller, which must use some GPIOs in the second GPIO bank (and I
believe the second I2C controller) since they aren't shown on the
schematic. The 2nd I2C controller is typically under firmware not Linux
control.

Dave Stevenson

2017-11-20 18:17:07 UTC

Permalink

Hi Stephen

On the model A and B at least, pins 28/29/44/45 are used for other purposes,
and cannot be used as I2C. It's hard/impossible to tell on the more recent
Pis since the schematics are obscured:-( This change appears to add the I2C
pinctrl mux to the original A/B, so at the very least needs to be modified
not to do that. More investigation is needed to tell whether it's
appropriate for the later models or not.

The best reference is the pin config that the firmware uses -
https://github.com/raspberrypi/firmware/blob/master/extra/dt-blob.dts

On the very original model A (128MB) and B (256MB), yes the camera is
on BSC1 and GPIOs 2&3 so needs to be fixed.

Post by Dave Stevenson
The i2c-mux-pinctrl driver allows pinctrl setup to be used
to expose the GPIO sets as alternate i2c adapters.

Specific case is kernel drivers for the DSI display and camera whilst
retaining the ability to use i2c0 via the main GPIO header (GPIOs
0&1).

Eric had been bitbashing I2C on 28&29 to talk to the DSI display
controller - https://github.com/anholt/linux/commit/e80d09ef0d05490296e30e33c7494f56407d7573
I have a kernel driver for talking to the CSI2 receiver block (Unicam)
that needs I2C comms to the sensor/source board. (I need to sort out
the next revision for the mailing list).

If a user has modified their HW and changed what the pins are connected to,
that's something user-specific. They should modify the DT themselves to
match that HW change. However, the default/standard DT shouldn't be
modified, since not all users will have made that HW change.

Post by Dave Stevenson
This
patch configures that driver to expose two adapters -
i2c0 on GPIOs 0&1, and i2c_csi_dsi on the correct GPIOs for
the camera and display.

Looking at the schematics for the original A/B Pi, the camera should be
controlled by the second I2C controller on GPIO pins 2/3, and the DSI port
has no I2C. On the B+ schematics, both CSI and DSI use the same I2C
controller, which must use some GPIOs in the second GPIO bank (and I believe
the second I2C controller) since they aren't shown on the schematic. The 2nd
I2C controller is typically under firmware not Linux control.

The original A/B are the exception in using BSC1 / GPIOs 2&3. All
other variants are using BSC0 on either 28&29 or 44&45 (Pi3 only). For
the original A&B we need to revert to a simple mapping of i2c0 to 0&1,
and i2c1 to 2&3.

All three I2C controllers are defined as enabled in Linux by the
default upstream DT -
http://elixir.free-electrons.com/linux/v4.14/source/arch/arm/boot/dts/bcm2835-rpi.dtsi#L47.
The firmware uses BSC0 / i2c0 for talking to the camera, display, and
HAT EEPROM (boot time only). If there is any desire for upstream to
support the camera or display then it needs to be able to communicate
with them.
The default muxing for i2c0 (the one the firmware normally uses) is to
GPIOs 0&1. If that is to remain a supported option and talk to the
display/camera then either you bit bash one of the interfaces (please
no), or need i2c-mux-pinctrl.

Dave

Stefan Wahren

2017-11-20 19:43:10 UTC

Permalink

Hi Dave,

Post by Dave Stevenson
The first i2c controller on the Raspberry Pi family can
be pinmuxed to either GPIOs 0&1, 28&29, or 44&45.
The default has always been 0&1 as those are exposed on
the 40 pin GPIO header of the more recent models.
GPIOs 28&29 on Pi 0/1/2/3 and GPIOs 44&45 on Pi3 are
used for i2c to the DSI display and the camera module.
The i2c-mux-pinctrl driver allows pinctrl setup to be used
to expose the GPIO sets as alternate i2c adapters. This
patch configures that driver to expose two adapters -
i2c0 on GPIOs 0&1, and i2c_csi_dsi on the correct GPIOs for
the camera and display.
(This could be extended to expose all 3 options on the CM
and CM3, but there isn't a pressing case for that at present).
The one quirk with the i2cmux-pinctrl driver is that the
parent controller still exists as an i2c adapter which
will be connnected to whichever pins were last requested
(or an optional idle setting). That adapter appears first so
is numbered as adapter 0, whilst the child ports end up as
adapters 3&4. These can be renumbered through using DT aliases
if we wish to retain the ordering of adapters (this will be
required downstream).
---
Hi All.
Thoughts from people?
Do others care about access to the alternate pin muxing options for BSC0?
Is the location of these changes acceptable?
Objections on naming of nodes?

i'm not sure that i understood complete issue. This seems to be a RPi specific problem.
So you want to add a new driver for a "virtual" muxing in order to use csi/dsi?

Do you think the issue could be fixed with the following DT part (example)

&i2c0 {
pinctrl-names = "default", "dsi_csi";
pinctrl-0 = <&i2c0_gpio0>;
pinctrl-1 = <&i2c0_gpio44>;
compatible = "raspberrypi,bcm2835-i2c0";
status = "okay";
clock-frequency = <100000>;
};

and extending the i2c driver with the necessary pinctrl handling instead?

Stephen Warren

2017-11-20 20:52:21 UTC

Permalink

Post by Stefan Wahren
Hi Dave,

i'm not sure that i understood complete issue. This seems to be a RPi specific problem.
So you want to add a new driver for a "virtual" muxing in order to use csi/dsi?
Do you think the issue could be fixed with the following DT part (example)
&i2c0 {
pinctrl-names = "default", "dsi_csi";
pinctrl-0 = <&i2c0_gpio0>;
pinctrl-1 = <&i2c0_gpio44>;
compatible = "raspberrypi,bcm2835-i2c0";
status = "okay";
clock-frequency = <100000>;
};
and extending the i2c driver with the necessary pinctrl handling instead?

i2c-mux-pinctrl was explicitly developed to avoid the need for
individual I2C drivers having to do this themselves. I haven't read and
understood Dave's response to mine to see if we really do need I2C
muxing, but if we do, then i2c-mux-pinctrl is certainly the correct
approach to implement it.

Eric Anholt

2017-11-21 19:18:46 UTC

Permalink

Post by Stefan Wahren
Hi Dave,

i'm not sure that i understood complete issue. This seems to be a RPi specific problem.
So you want to add a new driver for a "virtual" muxing in order to use csi/dsi?

It's a general problem for hardware where a pinmux controls which pins
an I2C controller connects to, of which BCM2835 is an instance.

Post by Stefan Wahren
Do you think the issue could be fixed with the following DT part (example)
&i2c0 {
pinctrl-names = "default", "dsi_csi";
pinctrl-0 = <&i2c0_gpio0>;
pinctrl-1 = <&i2c0_gpio44>;
compatible = "raspberrypi,bcm2835-i2c0";
status = "okay";
clock-frequency = <100000>;
};
and extending the i2c driver with the necessary pinctrl handling instead?

i2cmux_pinctrl is the thing that already exists to do this, complete
with DT bindings. Why should we duplicate their work?

Eric Anholt

2017-12-08 21:16:14 UTC

Permalink

I'm interested in landing this patch, so that we can use it for the
camera and DSI support. Do we have objections or other feedback at this
point? Should we include the aliases node in our DT?

Dave Stevenson

2017-12-11 13:55:50 UTC

Permalink

Post by Eric Anholt

I'm interested in landing this patch, so that we can use it for the
camera and DSI support. Do we have objections or other feedback at this
point? Should we include the aliases node in our DT?

I was holding off on fully reworking it for the original model A and
B's awaiting Stephen's followup from

Post by Eric Anholt
I haven't read and understood Dave's response to mine to see if we really do need I2C muxing, but if we do, then i2c-mux-pinctrl is certainly the correct approach to implement it.

I did about 70% of the work for it sorting the A&B, so I'll finish
that off and aim to get a v2 out tomorrow.

Dave

Stephen Warren

2017-12-11 16:33:26 UTC

Permalink

Post by Dave Stevenson

Post by Eric Anholt

I'm interested in landing this patch, so that we can use it for the
camera and DSI support. Do we have objections or other feedback at this
point? Should we include the aliases node in our DT?

I was holding off on fully reworking it for the original model A and
B's awaiting Stephen's followup from

Oh. I was at least partially awaiting v2 since you said there were
errors that needed to be fixed, so I could try and correlate it with the
schematics. And partially being lazy.

Post by Dave Stevenson
The best reference is the pin config that the firmware uses -
https://github.com/raspberrypi/firmware/blob/master/extra/dt-blob.dts
On the very original model A (128MB) and B (256MB), yes the camera is
on BSC1 and GPIOs 2&3 so needs to be fixed.

On that note, can you please make sure that the schematics that the Pi
Foundation publishes are complete and fully consistent with that DT
blob? If there are errors or omissions in the schematics, that would be
bad, since all GPIO/pinmux/xxx work I've done, and probably many other
people too, has been purely based off those schematics.

Dave Stevenson

2017-12-12 15:33:12 UTC

Permalink

Post by Dave Stevenson

Post by Eric Anholt

I'm interested in landing this patch, so that we can use it for the
camera and DSI support. Do we have objections or other feedback at this
point? Should we include the aliases node in our DT?

I was holding off on fully reworking it for the original model A and
B's awaiting Stephen's followup from

Oh. I was at least partially awaiting v2 since you said there were errors
that needed to be fixed, so I could try and correlate it with the
schematics. And partially being lazy.

Ah, both waiting on each other :-/
I was wanting some guidance as to whether anyone cared before
investing time. It sounds like at least Eric is interested in the
possibilities, so v2 is done.

On that note, can you please make sure that the schematics that the Pi
Foundation publishes are complete and fully consistent with that DT blob? If
there are errors or omissions in the schematics, that would be bad, since
all GPIO/pinmux/xxx work I've done, and probably many other people too, has
been purely based off those schematics.

Sorry, what goes into those schematics isn't my domain. They are taken
directly from the master schematics used for manufacture, so what is
present will be correct.
I will ask that future schematics do include the wiring back to the
SoC for all GPIO connections that are exposed to the user via an
external connector. That would clarify things like where SDA0 and SCL0
on the camera and display connectors actually connect back to.

The dt-blob is maintained to be consistent with the hardware,
otherwise the firmware won't work. Any errors that have crept in have
generally been picked up and corrected quickly. (The only one I can
really think of was that the two camera GPIOs got swapped over in the
config).

Dave

Stephen Warren

2017-12-12 16:56:24 UTC

Permalink

Post by Dave Stevenson

Post by Eric Anholt

I'm interested in landing this patch, so that we can use it for the
camera and DSI support. Do we have objections or other feedback at this
point? Should we include the aliases node in our DT?

I was holding off on fully reworking it for the original model A and
B's awaiting Stephen's followup from

Oh. I was at least partially awaiting v2 since you said there were errors
that needed to be fixed, so I could try and correlate it with the
schematics. And partially being lazy.

Ah, both waiting on each other :-/
I was wanting some guidance as to whether anyone cared before
investing time. It sounds like at least Eric is interested in the
possibilities, so v2 is done.

On that note, can you please make sure that the schematics that the Pi
Foundation publishes are complete and fully consistent with that DT blob? If
there are errors or omissions in the schematics, that would be bad, since
all GPIO/pinmux/xxx work I've done, and probably many other people too, has
been purely based off those schematics.

Sorry, what goes into those schematics isn't my domain. They are taken
directly from the master schematics used for manufacture, so what is
present will be correct.

Well, I mentioned that because since you work for the Pi Foundation, you
know who to ask to make sure the schematics can be made complete/correct.

Post by Dave Stevenson
I will ask that future schematics do include the wiring back to the
SoC for all GPIO connections that are exposed to the user via an
external connector. That would clarify things like where SDA0 and SCL0
on the camera and display connectors actually connect back to.

Great, thanks.