diff mbox series

[5/5] arm: dts: aspeed: Add power9 CFAM dtsi and use it on OpenPower P9 machines

Message ID 20180724042406.15374-6-benh@kernel.crashing.org
State Accepted, archived
Headers show
Series arm: dts: aspeed DTS updates for OpenPower | expand

Commit Message

Benjamin Herrenschmidt July 24, 2018, 4:24 a.m. UTC
This provides proper chip IDs but also adds the various sub-devices
necessary for the future OCC driver among other. All the added nodes
comply with the existing upstream FSI bindings.

Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
---
 arch/arm/boot/dts/aspeed-bmc-opp-lanyang.dts  |   1 +
 arch/arm/boot/dts/aspeed-bmc-opp-romulus.dts  |   2 +
 .../boot/dts/aspeed-bmc-opp-witherspoon.dts   |   2 +
 arch/arm/boot/dts/aspeed-bmc-opp-zaius.dts    |   2 +
 arch/arm/boot/dts/ibm-power9-cfam.dtsi        | 104 ++++++++++++++++++
 arch/arm/boot/dts/ibm-power9-dual.dtsi        |  58 ++++++++++
 6 files changed, 169 insertions(+)
 create mode 100644 arch/arm/boot/dts/ibm-power9-cfam.dtsi
 create mode 100644 arch/arm/boot/dts/ibm-power9-dual.dtsi

Comments

Olof Johansson July 26, 2018, 7:50 p.m. UTC | #1
Hi,

I came across this patch as part of Joel's pull request, so this is
somewhat high latency review that I guess nobody else cared to do:


On Tue, Jul 24, 2018 at 6:24 AM, Benjamin Herrenschmidt
<benh@kernel.crashing.org> wrote:
> This provides proper chip IDs but also adds the various sub-devices
> necessary for the future OCC driver among other. All the added nodes
> comply with the existing upstream FSI bindings.
>
> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> ---
>  arch/arm/boot/dts/aspeed-bmc-opp-lanyang.dts  |   1 +
>  arch/arm/boot/dts/aspeed-bmc-opp-romulus.dts  |   2 +
>  .../boot/dts/aspeed-bmc-opp-witherspoon.dts   |   2 +
>  arch/arm/boot/dts/aspeed-bmc-opp-zaius.dts    |   2 +
>  arch/arm/boot/dts/ibm-power9-cfam.dtsi        | 104 ++++++++++++++++++
>  arch/arm/boot/dts/ibm-power9-dual.dtsi        |  58 ++++++++++
>  6 files changed, 169 insertions(+)
>  create mode 100644 arch/arm/boot/dts/ibm-power9-cfam.dtsi
>  create mode 100644 arch/arm/boot/dts/ibm-power9-dual.dtsi
>

> diff --git a/arch/arm/boot/dts/ibm-power9-cfam.dtsi b/arch/arm/boot/dts/ibm-power9-cfam.dtsi
> new file mode 100644
> index 000000000000..5bda517f93cc
> --- /dev/null
> +++ b/arch/arm/boot/dts/ibm-power9-cfam.dtsi
> @@ -0,0 +1,104 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +// Copyright 2018 IBM Corp
> +
> +#define __MAKE_LABEL(p,i)      p##i
> +#define _MAKE_LABEL(p,i)       __MAKE_LABEL(p,i)
> +#define HUB_LABEL              _MAKE_LABEL(fsi_hub,CFAM_CHIP_ID)
> +#define I2C_LABEL(n)           _MAKE_LABEL(_MAKE_LABEL(cfam,CFAM_CHIP_ID),_i2c##n)

This is a red flag with respect to obscurity. It's a magic dtsi file
that has to be included at the right spot in the dts file or things
will break horribly -- we really try to avoid those kind of
constructs.

Also, you use it by passing in a predefined CHIP_ID, so you have
#define / #include / #undef. And on top of that you have open-coded
actual stable naming references to nodes that can't be found because
they're created by macros.

I know you want this to instantiate a bunch of boilerplate, so if you
want to do that, maybe you'd be better off having this file just
define a couple of macros, and then instantiate the actual subtrees
with that macro (the macro can then take the chipid). That way you can
still expose the same label-making macros in the locations where you
setup the stable naming. Much less cognitive load on someone trying to
read it and figure out just what's being instantiated where, and what
nodes the i2c<#> aliases are referring to.

Also:

> +/ {
> +       aliases {
> +               i2c100 = &cfam0_i2c0;
> +               i2c101 = &cfam0_i2c1;
> +               i2c102 = &cfam0_i2c2;
> +               i2c103 = &cfam0_i2c3;
> +               i2c104 = &cfam0_i2c4;
> +               i2c105 = &cfam0_i2c5;
> +               i2c106 = &cfam0_i2c6;
> +               i2c107 = &cfam0_i2c7;
> +               i2c108 = &cfam0_i2c8;
> +               i2c109 = &cfam0_i2c9;
> +               i2c110 = &cfam0_i2c10;
> +               i2c111 = &cfam0_i2c11;
> +               i2c112 = &cfam0_i2c12;
> +               i2c113 = &cfam0_i2c13;
> +               i2c114 = &cfam0_i2c14;
> +               i2c200 = &cfam1_i2c0;
> +               i2c201 = &cfam1_i2c1;
> +               i2c202 = &cfam1_i2c2;
> +               i2c203 = &cfam1_i2c3;
> +               i2c204 = &cfam1_i2c4;
> +               i2c205 = &cfam1_i2c5;
> +               i2c206 = &cfam1_i2c6;
> +               i2c207 = &cfam1_i2c7;
> +               i2c208 = &cfam1_i2c8;
> +               i2c209 = &cfam1_i2c9;
> +               i2c210 = &cfam1_i2c10;
> +               i2c211 = &cfam1_i2c11;
> +               i2c212 = &cfam1_i2c12;
> +               i2c213 = &cfam1_i2c13;
> +               i2c214 = &cfam1_i2c14;

This is... unconventional. Fixed mapping but up at a high bus range
such that it won't conflict with other SoC busses?

Just make your tools figure out what bus to use with sysfs or DT
entries instead, much less of a hack. We've done these things to IRQs
and GPIOs in the past, and it's a pain to clean up later.


-Olof
Benjamin Herrenschmidt July 26, 2018, 11:55 p.m. UTC | #2
On Thu, 2018-07-26 at 21:50 +0200, Olof Johansson wrote:
> 
> > +++ b/arch/arm/boot/dts/ibm-power9-cfam.dtsi
> > @@ -0,0 +1,104 @@
> > +// SPDX-License-Identifier: GPL-2.0+
> > +// Copyright 2018 IBM Corp
> > +
> > +#define __MAKE_LABEL(p,i)      p##i
> > +#define _MAKE_LABEL(p,i)       __MAKE_LABEL(p,i)
> > +#define HUB_LABEL              _MAKE_LABEL(fsi_hub,CFAM_CHIP_ID)
> > +#define I2C_LABEL(n)           _MAKE_LABEL(_MAKE_LABEL(cfam,CFAM_CHIP_ID),_i2c##n)
> 
> This is a red flag with respect to obscurity. It's a magic dtsi file
> that has to be included at the right spot in the dts file or things
> will break horribly -- we really try to avoid those kind of
> constructs.

I agree it sucks :-) I couldn't find any other way though. dtc seems to
be extremely limited in its ability to override node content. See
below.
 
> Also, you use it by passing in a predefined CHIP_ID, so you have
> #define / #include / #undef. And on top of that you have open-coded
> actual stable naming references to nodes that can't be found because
> they're created by macros.

Correct, as I said, I couldn't find a different way to do it.

> I know you want this to instantiate a bunch of boilerplate, so if you
> want to do that, maybe you'd be better off having this file just
> define a couple of macros, and then instantiate the actual subtrees
> with that macro (the macro can then take the chipid).

I'm not sure what you mean... the entire subtree being one giant macro
? That sounds scary ... I'll describe what I'm trying to do below.

>  That way you can
> still expose the same label-making macros in the locations where you
> setup the stable naming. Much less cognitive load on someone trying to
> read it and figure out just what's being instantiated where, and what
> nodes the i2c<#> aliases are referring to.

I'm sorry, I don't quite get what you suggest...
> 
> Also:
> 
> > +/ {
> > +       aliases {
> > +               i2c100 = &cfam0_i2c0;
> > +               i2c101 = &cfam0_i2c1;
> > +               i2c102 = &cfam0_i2c2;
> > +               i2c103 = &cfam0_i2c3;
> > +               i2c104 = &cfam0_i2c4;
> > +               i2c105 = &cfam0_i2c5;
> > +               i2c106 = &cfam0_i2c6;
> > +               i2c107 = &cfam0_i2c7;
> > +               i2c108 = &cfam0_i2c8;
> > +               i2c109 = &cfam0_i2c9;
> > +               i2c110 = &cfam0_i2c10;
> > +               i2c111 = &cfam0_i2c11;
> > +               i2c112 = &cfam0_i2c12;
> > +               i2c113 = &cfam0_i2c13;
> > +               i2c114 = &cfam0_i2c14;
> > +               i2c200 = &cfam1_i2c0;
> > +               i2c201 = &cfam1_i2c1;
> > +               i2c202 = &cfam1_i2c2;
> > +               i2c203 = &cfam1_i2c3;
> > +               i2c204 = &cfam1_i2c4;
> > +               i2c205 = &cfam1_i2c5;
> > +               i2c206 = &cfam1_i2c6;
> > +               i2c207 = &cfam1_i2c7;
> > +               i2c208 = &cfam1_i2c8;
> > +               i2c209 = &cfam1_i2c9;
> > +               i2c210 = &cfam1_i2c10;
> > +               i2c211 = &cfam1_i2c11;
> > +               i2c212 = &cfam1_i2c12;
> > +               i2c213 = &cfam1_i2c13;
> > +               i2c214 = &cfam1_i2c14;
> 
> This is... unconventional. Fixed mapping but up at a high bus range
> such that it won't conflict with other SoC busses?

Yes. I'll describe the topology below.

> Just make your tools figure out what bus to use with sysfs or DT
> entries instead, much less of a hack. We've done these things to IRQs
> and GPIOs in the past, and it's a pain to clean up later.

Well, fixing the tools is ... hard and fixing the users of those tools
harder. Chances are people are just going to keep out of tree kernel
hacks rather than fixing their tools if that's what it gets to but we
can hope...

Ideally we could try creating a bunch of udev scripts that create named
symlinks for those i2c busses but that will take time. Anyway, here's
what we are trying to do:

So you may remember from your days at IBM :-) The FSI bus is the
service interface to the POWER chips (a bit like PECI on x86 I think).
It also connect to things like memory buffer chips etc...

This is the view of the system from the perspective of the BMC
management controller (or the FSP, same deal).

The BMC is typically master of one FSI bus to one chip, let's say P9
for now, and can access more chips via cascaded FSI masters (aka FSI
"hubs") in that chip. Those secondary chips can themselves have hubs to
other chips etc...

So we want a dtsi file that represent a "chip". ie, a power9.dtsi, a
power8.dtsi, a centaur.dtsi (centaur is the mem buffer) etc... There's
a while bunch of things in such a chip, the current patch only has a
portion of what will eventually be there. Via FSI we can access the OCC
thermal control processor, the i2c masters, the XSCOM engine, the scan
engine, etc. etc... Each of these will bind with drivers in the BMC
kernel.

And we want the top-level "system" file to instanciate them all in the
right places to represent a given system topology.

In addition, we do need some properties to uniquely identify a
chip/socket in the system in a stable manner. If anything to provide
meaningful data to the user, but also to cross-match with corresponding
fans etc...

Originally, I thought I could just use the DT "override" constructs to
do something like:

&bmc_fsi {
#include "power9.dtsi"
}

But then I couldn't find a way to then add the chip id to power9. dts
can't do things like

&bmc_fsi/cfam@0 {
	chip-id = <...>;
};

It seems.

I tried without using the bmc_fsi label, using a full path but that
failed too, dtc thought I was trying to create a duplicate node rather
than appending to an existing one.

Then I need to add another chip to one of the hub legs. Here too, how ?
I can have power9.dtsi define labels for its hub legs but then it will
clash when I bring in the second one...

So even ignoring the business with the i2c aliases, I'm a bit stuck.

I didn't quite get what you proposed with using the macros differently,
any chance you can throw a small example ? I'm hoping it doesn't
involve having the entire power9 chip content be a giant macro :-)

Cheers,
Ben.
diff mbox series

Patch

diff --git a/arch/arm/boot/dts/aspeed-bmc-opp-lanyang.dts b/arch/arm/boot/dts/aspeed-bmc-opp-lanyang.dts
index d598b6391362..e744d6532cbb 100644
--- a/arch/arm/boot/dts/aspeed-bmc-opp-lanyang.dts
+++ b/arch/arm/boot/dts/aspeed-bmc-opp-lanyang.dts
@@ -323,3 +323,4 @@ 
 	status = "okay";
 };
 
+#include "ibm-power9-dual.dtsi"
diff --git a/arch/arm/boot/dts/aspeed-bmc-opp-romulus.dts b/arch/arm/boot/dts/aspeed-bmc-opp-romulus.dts
index 852f264b9569..ead2a84f16bd 100644
--- a/arch/arm/boot/dts/aspeed-bmc-opp-romulus.dts
+++ b/arch/arm/boot/dts/aspeed-bmc-opp-romulus.dts
@@ -282,3 +282,5 @@ 
 &ibt {
 	status = "okay";
 };
+
+#include "ibm-power9-dual.dtsi"
diff --git a/arch/arm/boot/dts/aspeed-bmc-opp-witherspoon.dts b/arch/arm/boot/dts/aspeed-bmc-opp-witherspoon.dts
index 656036106001..33ea336f0c17 100644
--- a/arch/arm/boot/dts/aspeed-bmc-opp-witherspoon.dts
+++ b/arch/arm/boot/dts/aspeed-bmc-opp-witherspoon.dts
@@ -583,3 +583,5 @@ 
 &ibt {
 	status = "okay";
 };
+
+#include "ibm-power9-dual.dtsi"
diff --git a/arch/arm/boot/dts/aspeed-bmc-opp-zaius.dts b/arch/arm/boot/dts/aspeed-bmc-opp-zaius.dts
index 2c5aa90a546d..05df11cacb21 100644
--- a/arch/arm/boot/dts/aspeed-bmc-opp-zaius.dts
+++ b/arch/arm/boot/dts/aspeed-bmc-opp-zaius.dts
@@ -435,3 +435,5 @@ 
 &ibt {
 	status = "okay";
 };
+
+#include "ibm-power9-dual.dtsi"
diff --git a/arch/arm/boot/dts/ibm-power9-cfam.dtsi b/arch/arm/boot/dts/ibm-power9-cfam.dtsi
new file mode 100644
index 000000000000..5bda517f93cc
--- /dev/null
+++ b/arch/arm/boot/dts/ibm-power9-cfam.dtsi
@@ -0,0 +1,104 @@ 
+// SPDX-License-Identifier: GPL-2.0+
+// Copyright 2018 IBM Corp
+
+#define __MAKE_LABEL(p,i)	p##i
+#define _MAKE_LABEL(p,i)	__MAKE_LABEL(p,i)
+#define HUB_LABEL		_MAKE_LABEL(fsi_hub,CFAM_CHIP_ID)
+#define I2C_LABEL(n)		_MAKE_LABEL(_MAKE_LABEL(cfam,CFAM_CHIP_ID),_i2c##n)
+
+#address-cells = <1>;
+#size-cells = <1>;
+chip-id = <CFAM_CHIP_ID>;
+
+scom@1000 {
+	compatible = "ibm,fsi2pib";
+	reg = <0x1000 0x400>;
+};
+
+i2c@1800 {
+	compatible = "ibm,fsi-i2c-master";
+	reg = <0x1800 0x400>;
+	#address-cells = <1>;
+	#size-cells = <0>;
+
+	I2C_LABEL(0): i2c-bus@0 {
+		reg = <0>;
+	};
+
+	I2C_LABEL(1): i2c-bus@1 {
+		reg = <1>;
+	};
+
+	I2C_LABEL(2): i2c-bus@2 {
+		reg = <2>;
+	};
+
+	I2C_LABEL(3): i2c-bus@3 {
+		reg = <3>;
+	};
+
+	I2C_LABEL(4): i2c-bus@4 {
+		reg = <4>;
+	};
+
+	I2C_LABEL(5): i2c-bus@5 {
+		reg = <5>;
+	};
+
+	I2C_LABEL(6): i2c-bus@6 {
+		reg = <6>;
+	};
+
+	I2C_LABEL(7): i2c-bus@7 {
+		reg = <7>;
+	};
+
+	I2C_LABEL(8): i2c-bus@8 {
+		reg = <8>;
+	};
+
+	I2C_LABEL(9): i2c-bus@9 {
+		reg = <9>;
+	};
+
+	I2C_LABEL(10): i2c-bus@10 {
+		reg = <10>;
+	};
+
+	I2C_LABEL(11): i2c-bus@11 {
+		reg = <11>;
+	};
+
+	I2C_LABEL(12): i2c-bus@12 {
+		reg = <12>;
+	};
+
+	I2C_LABEL(13): i2c-bus@13 {
+		reg = <13>;
+	};
+
+	I2C_LABEL(14): i2c-bus@14 {
+		reg = <14>;
+	};
+};
+
+sbefifo@2400 {
+	compatible = "ibm,p9-sbefifo";
+	reg = <0x2400 0x400>;
+	#address-cells = <1>;
+	#size-cells = <0>;
+};
+
+HUB_LABEL: hub@3400 {
+	compatible = "fsi-master-hub";
+	reg = <0x3400 0x400>;
+	#address-cells = <2>;
+	#size-cells = <0>;
+
+	no-scan-on-init;
+};
+
+#undef __MAKE_LABEL
+#undef _MAKE_LABEL
+#undef HUB_LABEL
+#undef I2C_LABEL
diff --git a/arch/arm/boot/dts/ibm-power9-dual.dtsi b/arch/arm/boot/dts/ibm-power9-dual.dtsi
new file mode 100644
index 000000000000..f6a82ad43ff8
--- /dev/null
+++ b/arch/arm/boot/dts/ibm-power9-dual.dtsi
@@ -0,0 +1,58 @@ 
+// SPDX-License-Identifier: GPL-2.0+
+// Copyright 2018 IBM Corp
+
+/* Instantiate chip 0 */
+#define CFAM_CHIP_ID 0
+&fsi {
+	cfam@0,0 {
+		reg = <0 0>;
+		#include "ibm-power9-cfam.dtsi"
+	};
+};
+#undef CFAM_CHIP_ID
+
+/* Instantiate chip 1 */
+#define CFAM_CHIP_ID 1
+&fsi_hub0 {
+	cfam@1,0 {
+		reg = <1 0>;
+		#include "ibm-power9-cfam.dtsi"
+	};
+};
+#undef CFAM_CHIP_ID
+
+/ {
+	aliases {
+		i2c100 = &cfam0_i2c0;
+		i2c101 = &cfam0_i2c1;
+		i2c102 = &cfam0_i2c2;
+		i2c103 = &cfam0_i2c3;
+		i2c104 = &cfam0_i2c4;
+		i2c105 = &cfam0_i2c5;
+		i2c106 = &cfam0_i2c6;
+		i2c107 = &cfam0_i2c7;
+		i2c108 = &cfam0_i2c8;
+		i2c109 = &cfam0_i2c9;
+		i2c110 = &cfam0_i2c10;
+		i2c111 = &cfam0_i2c11;
+		i2c112 = &cfam0_i2c12;
+		i2c113 = &cfam0_i2c13;
+		i2c114 = &cfam0_i2c14;
+		i2c200 = &cfam1_i2c0;
+		i2c201 = &cfam1_i2c1;
+		i2c202 = &cfam1_i2c2;
+		i2c203 = &cfam1_i2c3;
+		i2c204 = &cfam1_i2c4;
+		i2c205 = &cfam1_i2c5;
+		i2c206 = &cfam1_i2c6;
+		i2c207 = &cfam1_i2c7;
+		i2c208 = &cfam1_i2c8;
+		i2c209 = &cfam1_i2c9;
+		i2c210 = &cfam1_i2c10;
+		i2c211 = &cfam1_i2c11;
+		i2c212 = &cfam1_i2c12;
+		i2c213 = &cfam1_i2c13;
+		i2c214 = &cfam1_i2c14;
+	};
+};
+