[2/2] ARM: dts: add device tree for the RealView EB Rev D

Message ID 1473327043-31903-1-git-send-email-linus.walleij@linaro.org
State New
Headers show

Commit Message

Linus Walleij Sept. 8, 2016, 9:30 a.m.
The RealView EB revision D is a special case as it appears to be
undocumented in ARM official documents, while the Linux kernel
still contains special code for handling it.

commit be4f3c8691492934c8ee03dbecb3a3a865ac6cd6
"Add RealView/EB support for the LAN9118 Ethernet chip"
adds support for the SMSC LAN9118 chip used on the D revision,
but no other traces of hardware deviations for this variant
can be found.

This created a separate top-level .dts file especially for this
board version, so that it gets registered with the right type
of ethernet controller.

Signed-off-by: Linus Walleij <linus.walleij@linaro.org>

---
ARM SoC people: please apply this directly with the first patch.
---
 arch/arm/boot/dts/Makefile                 |  1 +
 arch/arm/boot/dts/arm-realview-eb-revd.dts | 49 ++++++++++++++++++++++++++++++
 2 files changed, 50 insertions(+)
 create mode 100644 arch/arm/boot/dts/arm-realview-eb-revd.dts

-- 
2.7.4


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

Comments

Arnd Bergmann Sept. 8, 2016, 9:44 a.m. | #1
On Thursday, September 8, 2016 11:30:43 AM CEST Linus Walleij wrote:
> @@ -608,6 +608,7 @@ dtb-$(CONFIG_ARCH_REALVIEW) += \

>         arm-realview-pb1176.dtb \

>         arm-realview-pb11mp.dtb \

>         arm-realview-eb.dtb \

> +       arm-realview-eb-revd.dtb \

>         arm-realview-eb-11mp.dtb \

>         arm-realview-eb-11mp-revb.dtb \

>         arm-realview-eb-a9mp.dtb \


Is the ethernet device on the baseboard or the core tile?

My understanding is that you have a baseboard which comes in
different revisions and a set of CPU modules (arm9, arm1136,
arm1176, arm11mp, cortex-a9, ...) that can be freely combined,
so if the ethernet device is on the baseboard, we also need revd
variants for 11mp and a9mp.

The arm-realview-eb-11mp-revb seems to refer to RevB of
the core tile rather than the baseboard (?), so we may need
a better notation for the file names to clarify that difference.

	Arnd

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
Linus Walleij Sept. 8, 2016, 10 a.m. | #2
On Thu, Sep 8, 2016 at 11:44 AM, Arnd Bergmann <arnd@arndb.de> wrote:
> On Thursday, September 8, 2016 11:30:43 AM CEST Linus Walleij wrote:

>> @@ -608,6 +608,7 @@ dtb-$(CONFIG_ARCH_REALVIEW) += \

>>         arm-realview-pb1176.dtb \

>>         arm-realview-pb11mp.dtb \

>>         arm-realview-eb.dtb \

>> +       arm-realview-eb-revd.dtb \

>>         arm-realview-eb-11mp.dtb \

>>         arm-realview-eb-11mp-revb.dtb \

>>         arm-realview-eb-a9mp.dtb \

>

> Is the ethernet device on the baseboard or the core tile?


It's on the baseboard.

> My understanding is that you have a baseboard which comes in

> different revisions and a set of CPU modules (arm9, arm1136,

> arm1176, arm11mp, cortex-a9, ...) that can be freely combined,

> so if the ethernet device is on the baseboard, we also need revd

> variants for 11mp and a9mp.


Yeah... you're right.

> The arm-realview-eb-11mp-revb seems to refer to RevB of

> the core tile rather than the baseboard (?), so we may need

> a better notation for the file names to clarify that difference.


OK will try to come up with some namespace.

Revisiting this mess...

Yours,
Linus Walleij

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
Robin Murphy Sept. 9, 2016, 10:47 a.m. | #3
Hi Linus,

On 08/09/16 11:00, Linus Walleij wrote:
> On Thu, Sep 8, 2016 at 11:44 AM, Arnd Bergmann <arnd@arndb.de> wrote:

>> On Thursday, September 8, 2016 11:30:43 AM CEST Linus Walleij wrote:

>>> @@ -608,6 +608,7 @@ dtb-$(CONFIG_ARCH_REALVIEW) += \

>>>         arm-realview-pb1176.dtb \

>>>         arm-realview-pb11mp.dtb \

>>>         arm-realview-eb.dtb \

>>> +       arm-realview-eb-revd.dtb \

>>>         arm-realview-eb-11mp.dtb \

>>>         arm-realview-eb-11mp-revb.dtb \

>>>         arm-realview-eb-a9mp.dtb \

>>

>> Is the ethernet device on the baseboard or the core tile?

> 

> It's on the baseboard.

> 

>> My understanding is that you have a baseboard which comes in

>> different revisions and a set of CPU modules (arm9, arm1136,

>> arm1176, arm11mp, cortex-a9, ...) that can be freely combined,

>> so if the ethernet device is on the baseboard, we also need revd

>> variants for 11mp and a9mp.

> 

> Yeah... you're right.

> 

>> The arm-realview-eb-11mp-revb seems to refer to RevB of

>> the core tile rather than the baseboard (?), so we may need

>> a better notation for the file names to clarify that difference.

> 

> OK will try to come up with some namespace.

> 

> Revisiting this mess...


FWIW, a quick survey of our cupboard reveals a roughly equal number of
rev D baseboards vs. rev C - I have no idea about the distribution out
in the wild, but I'd be inclined to suspect it's more of an oversight in
updating the documentation than rev D being particularly "special".

I wonder if it would be feasible to simply add a disabled LAN91C111 next
to the LAN9118 and have a hook in realview-dt.c to swizzle the status at
runtime based on a read of SYS_ID? (Or is that utterly disgusting?)

Robin.

> 

> Yours,

> Linus Walleij

> 

> _______________________________________________

> linux-arm-kernel mailing list

> linux-arm-kernel@lists.infradead.org

> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

> 



_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
Linus Walleij Sept. 9, 2016, 12:33 p.m. | #4
On Fri, Sep 9, 2016 at 12:47 PM, Robin Murphy <robin.murphy@arm.com> wrote:

> I wonder if it would be feasible to simply add a disabled LAN91C111 next
> to the LAN9118 and have a hook in realview-dt.c to swizzle the status at
> runtime based on a read of SYS_ID? (Or is that utterly disgusting?)

I feel what you feel: runtime detection would be better.

The root cause that it is not happening is that device tree is essentially
static and hates scenarios to have its contents even augmented at
runtime. Especially plug-and-play type scenarios. So something that was
so easy to hack up in boardfiles is a nightmare in device tree.

It is technically feasible and I have even done it, in another context.

That was when I employed a "Schrödinger's cat" approach to the
ARM Versatile display detection:

First I put all possible displays into the device tree, and at runtime
selected which one to connect using the endpoint graph mechanism
in device tree. This was frowned upon.

I then put a pretty standard VGA display in as default, and then added
code to augment that node to whatever display was actually found
by mangling several atributes of the node, rewriting, augmenting,
adding, subtracting. Mostly augmenting. This too, was frowned upon.

This can be done with the ethernet as well: I can just put
both of them in into "disabled" state and switch to "ok" on the one that is
actually there with some code in e.g. mach-realview.

Or I can put in the LAN91C111 and mange that DT node into a
LAN9118 by manipulating the DT node at runtime incl. changing the
compatible string with code.

However upstream developes nixed both approaches before. (After
developing quite a bit of code for each, so I was a bit burnt,
bitter? me? nah. Creative destruction let's say. We learnt something
in the process.)

I was instead told to go work on device tree overlays, or to let
the boot loader (in the RealView case, the abandonware that was
never integrated into upstream U-boot) to do DT augmentation.
One possibility was to let the kernel augment the device tree
before booting and the boot loader just line up a bunch of
overlays it should apply when parsing the DTB(s).

I haven't had time to catch up with what should actually be done
here. I felt a bit like a big piece of design and development was
dropped in my lap to get my boards converted to device tree.
I started looking at it, I might do it one day, but I have lots of other
stuff to do too.

Now it seems that at the finishing line of any Versatile family
device tree conversion I run into this kind of "reinvent DT overlays"
stuff...

Yours,
Linus Walleij

Patch

diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index faacd52370d2..43d2c379d034 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -608,6 +608,7 @@  dtb-$(CONFIG_ARCH_REALVIEW) += \
 	arm-realview-pb1176.dtb \
 	arm-realview-pb11mp.dtb \
 	arm-realview-eb.dtb \
+	arm-realview-eb-revd.dtb \
 	arm-realview-eb-11mp.dtb \
 	arm-realview-eb-11mp-revb.dtb \
 	arm-realview-eb-a9mp.dtb \
diff --git a/arch/arm/boot/dts/arm-realview-eb-revd.dts b/arch/arm/boot/dts/arm-realview-eb-revd.dts
new file mode 100644
index 000000000000..2142deffbe4c
--- /dev/null
+++ b/arch/arm/boot/dts/arm-realview-eb-revd.dts
@@ -0,0 +1,49 @@ 
+/*
+ * Copyright 2016 Linaro Ltd
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a copy
+ * of this software and associated documentation files (the "Software"), to deal
+ * in the Software without restriction, including without limitation the rights
+ * to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+ * copies of the Software, and to permit persons to whom the Software is
+ * furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+ * OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
+ * THE SOFTWARE.
+ */
+
+#include "arm-realview-eb.dts"
+
+/ {
+	model = "ARM RealView Emulation Baseboard Rev D";
+
+	/* Introduce a fixed regulator for the new ethernet controller */
+	veth: fixedregulator@0 {
+		compatible = "regulator-fixed";
+		regulator-name = "veth";
+		regulator-min-microvolt = <3300000>;
+		regulator-max-microvolt = <3300000>;
+		regulator-boot-on;
+	};
+};
+
+/*
+ * The revision D has a different ethernet controller that the elder boards:
+ * the older board uses LAN91C111 but the new one uses LAN9118.
+ */
+&ethernet {
+	compatible = "smsc,lan9118", "smsc,lan9115";
+	phy-mode = "mii";
+	smsc,irq-active-high;
+	smsc,irq-push-pull;
+	vdd33a-supply = <&veth>;
+	vddvario-supply = <&veth>;
+};