RE: [PATCH v2 5/7] powerpc/corenet: Add MDIO bus muxing support to the board device tree(s)
-Original Message-
From: Linuxppc-dev [mailto:linuxppc-dev-
bounces+b21989=freescale@lists.ozlabs.org] On Behalf Of Scott Wood
Sent: Friday, August 01, 2014 2:31 AM
To: Medve Emilian-EMMEDVE1
Cc: linuxppc-...@ozlabs.org
Subject: Re: [PATCH v2 5/7] powerpc/corenet: Add MDIO bus muxing support
to the board device tree(s)
On Thu, 2014-07-31 at 00:48 -0500, Emil Medve wrote:
Hello Scott,
On 07/31/2014 12:28 AM, Scott Wood wrote:
On Wed, 2014-07-30 at 23:35 -0500, Emil Medve wrote:
Hello Scott,
On 07/30/2014 09:30 PM, Scott Wood wrote:
On Wed, 2014-07-30 at 16:52 -0500, Emil Medve wrote:
+ mdio0: mdio at fc000 {
+ };
Why is the empty node needed?
For the label
For mdio-parent-bus, or is there some other dts layer that makes
this node non-empty?
'powerpc/corenet: Create the dts components for the DPAA FMan' -
http://patchwork.ozlabs.org/patch/370872
Why does this patch define the mdio0 label for mdio@e1120, but not
define a label for any other node?
Only MDIO controllers that are pinned out have these labels. Only
pinned out MDIO(s) are capable of controlling external PHY(s) via
these board level MDIO buses
Is there any reason to describe non-pinned-out MDIO controllers at
all?
[S.H] Regarding the pinned-out MDIO controllers and non-pinned-out MDIO
controllers,
How to differentiate them?
Yes. For the internal TBI PHY(s). Each MAC supporting SGMII has a TBI
PHY that is attached to the MDIO controller of the respective MAC
[S.H] there are multiple internal PHYs on Fman-v3 SOCs. Each one is used for
Specific function, for ex. on T4 there are XFI, SGMII, QSGMII.
Will all of them be listed in the DTS?
Thanks!
-Shaohui
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v2 5/7] powerpc/corenet: Add MDIO bus muxing support to the board device tree(s)
On Thu, 2014-07-31 at 00:48 -0500, Emil Medve wrote:
Hello Scott,
On 07/31/2014 12:28 AM, Scott Wood wrote:
On Wed, 2014-07-30 at 23:35 -0500, Emil Medve wrote:
Hello Scott,
On 07/30/2014 09:30 PM, Scott Wood wrote:
On Wed, 2014-07-30 at 16:52 -0500, Emil Medve wrote:
+mdio0: mdio at fc000 {
+};
Why is the empty node needed?
For the label
For mdio-parent-bus, or is there some other dts layer that makes this
node non-empty?
'powerpc/corenet: Create the dts components for the DPAA FMan' -
http://patchwork.ozlabs.org/patch/370872
Why does this patch define the mdio0 label for mdio@e1120, but not
define a label for any other node?
Only MDIO controllers that are pinned out have these labels. Only pinned
out MDIO(s) are capable of controlling external PHY(s) via these board
level MDIO buses
Is there any reason to describe non-pinned-out MDIO controllers at all?
Yes. For the internal TBI PHY(s). Each MAC supporting SGMII has a TBI
PHY that is attached to the MDIO controller of the respective MAC
OK, so similar to eTSEC. I didn't know if you were counting aTBI
connection as being (partially) pinned out.
Is the lack of pinning out inherent to the silicon, or is it board
design/config?
It's a silicon level decision
So why is it the board file that adds the label, if it's always going to
be the same node?
I'm just curious why mdio@e1120 is labelled in a non-board dtsi while
others are labelled elsewhere.
Labels are relevant only in the context of 'powerpc/corenet: Add MDIO
bus muxing support to the board device tree(s)' -
http://patchwork.ozlabs.org/patch/370866. Most labels are created and
used in the board .dts file except b4qds.dtsi which is shared between
b4420qds.dts and b4860qds.dts
I'm talking about qoriq-fman-0-1g-0.dtsi, not b4qds.dtsi. It labels
mdio@e1120 as mdio0.
In other words, why is the decision on where to label made differently
for fman v3 than for previous fman versions?
-Scott
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v2 5/7] powerpc/corenet: Add MDIO bus muxing support to the board device tree(s)
Hello Scott,
On 07/31/2014 01:30 PM, Scott Wood wrote:
On Thu, 2014-07-31 at 00:48 -0500, Emil Medve wrote:
Hello Scott,
On 07/31/2014 12:28 AM, Scott Wood wrote:
On Wed, 2014-07-30 at 23:35 -0500, Emil Medve wrote:
Hello Scott,
On 07/30/2014 09:30 PM, Scott Wood wrote:
On Wed, 2014-07-30 at 16:52 -0500, Emil Medve wrote:
+mdio0: mdio at fc000 {
+};
Why is the empty node needed?
For the label
For mdio-parent-bus, or is there some other dts layer that makes this
node non-empty?
'powerpc/corenet: Create the dts components for the DPAA FMan' -
http://patchwork.ozlabs.org/patch/370872
Why does this patch define the mdio0 label for mdio@e1120, but not
define a label for any other node?
Only MDIO controllers that are pinned out have these labels. Only pinned
out MDIO(s) are capable of controlling external PHY(s) via these board
level MDIO buses
Is there any reason to describe non-pinned-out MDIO controllers at all?
Yes. For the internal TBI PHY(s). Each MAC supporting SGMII has a TBI
PHY that is attached to the MDIO controller of the respective MAC
OK, so similar to eTSEC. I didn't know if you were counting aTBI
connection as being (partially) pinned out.
Is the lack of pinning out inherent to the silicon, or is it board
design/config?
It's a silicon level decision
So why is it the board file that adds the label, if it's always going to
be the same node?
I guess we can move it
I'm just curious why mdio@e1120 is labelled in a non-board dtsi while
others are labelled elsewhere.
Labels are relevant only in the context of 'powerpc/corenet: Add MDIO
bus muxing support to the board device tree(s)' -
http://patchwork.ozlabs.org/patch/370866. Most labels are created and
used in the board .dts file except b4qds.dtsi which is shared between
b4420qds.dts and b4860qds.dts
I'm talking about qoriq-fman-0-1g-0.dtsi, not b4qds.dtsi. It labels
mdio@e1120 as mdio0.
We missed that. Given the above, we'll leave it and remove it from the
board files
Cheers,
In other words, why is the decision on where to label made differently
for fman v3 than for previous fman versions?
-Scott
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v2 5/7] powerpc/corenet: Add MDIO bus muxing support to the board device tree(s)
Hello Scott,
On 07/29/2014 02:58 PM, Scott Wood wrote:
On Mon, 2014-07-28 at 06:51 +, Emil Medve wrote:
Hello Scott,
Scott Wood scottwood at freescale.com writes:
On Wed, 2014-07-16 at 15:17 -0500, Shruti Kanetkar wrote:
+ mdio at fd000 {
+ /* For 10g interfaces */
+ phy_xaui_slot1: xaui-phy at slot1 {
+ status = disabled;
+ compatible =
ethernet-phy-ieee802.3-c45;
+ reg = 0x7; /* default switch setting
on slot1 of AMC2PEX */
+ };
Why xaui-phy and not ethernet-phy?
As for the device_type discussion from v1, there is a generic binding
that says device_type should be ethernet-phy.
I have no strong feelings about this and we can use ethernet-phy, but:
1. The binding is old/stale (?) as it still uses device_type and the kernel
doesn't seem to use anymore the device_type for PHY(s)
Yes.
2. The binding asks ethernet-phy for the device_type property, not for the
name. As such TBI PHY(s) use (upstream) the tbi-phy@ node name
It shows ethernet-phy as the name in the example. ePAPR urges generic
node names (this was also a recommendation for IEEE1275), and has
ethernet-phy on the preferred list. Is a xaui-phy not an ethernet phy?
So you thinking somebody should cleanup all the sgmii-phy and tbi-phy
node names, huh?
It seems that a number of tbi-phy instances slipped by you:
1be62c6 powerpc/mpc85xx: Add BSC9132 QDS Support
bf57aeb powerpc/85xx: add the P1020RDB-PD DTS support
8a6be2b powerpc/85xx: Add TWR-P1025 board support
+ mdio0: mdio at fc000 {
+ };
Why is the empty node needed?
For the label
For mdio-parent-bus, or is there some other dts layer that makes this
node non-empty?
'powerpc/corenet: Create the dts components for the DPAA FMan' -
http://patchwork.ozlabs.org/patch/370872 and 'powerpc/corenet: Add DPAA
FMan support to the SoC device tree(s)' -
http://patchwork.ozlabs.org/patch/370868 add content to said node
Cheers,
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v2 5/7] powerpc/corenet: Add MDIO bus muxing support to the board device tree(s)
On Wed, 2014-07-30 at 16:52 -0500, Emil Medve wrote:
Hello Scott,
On 07/29/2014 02:58 PM, Scott Wood wrote:
On Mon, 2014-07-28 at 06:51 +, Emil Medve wrote:
Hello Scott,
Scott Wood scottwood at freescale.com writes:
On Wed, 2014-07-16 at 15:17 -0500, Shruti Kanetkar wrote:
+mdio at fd000 {
+/* For 10g interfaces */
+phy_xaui_slot1: xaui-phy at slot1 {
+status = disabled;
+compatible =
ethernet-phy-ieee802.3-c45;
+reg = 0x7; /* default switch
setting on slot1 of AMC2PEX */
+};
Why xaui-phy and not ethernet-phy?
As for the device_type discussion from v1, there is a generic binding
that says device_type should be ethernet-phy.
I have no strong feelings about this and we can use ethernet-phy, but:
1. The binding is old/stale (?) as it still uses device_type and the kernel
doesn't seem to use anymore the device_type for PHY(s)
Yes.
2. The binding asks ethernet-phy for the device_type property, not for
the
name. As such TBI PHY(s) use (upstream) the tbi-phy@ node name
It shows ethernet-phy as the name in the example. ePAPR urges generic
node names (this was also a recommendation for IEEE1275), and has
ethernet-phy on the preferred list. Is a xaui-phy not an ethernet phy?
So you thinking somebody should cleanup all the sgmii-phy and tbi-phy
node names, huh?
No, I was just wondering why we're adding yet another name, and whether
there's any value in it.
It seems that a number of tbi-phy instances slipped by you:
1be62c6 powerpc/mpc85xx: Add BSC9132 QDS Support
bf57aeb powerpc/85xx: add the P1020RDB-PD DTS support
8a6be2b powerpc/85xx: Add TWR-P1025 board support
tbi-phy is existing practice. xaui-phy isn't.
+mdio0: mdio at fc000 {
+};
Why is the empty node needed?
For the label
For mdio-parent-bus, or is there some other dts layer that makes this
node non-empty?
'powerpc/corenet: Create the dts components for the DPAA FMan' -
http://patchwork.ozlabs.org/patch/370872
Why does this patch define the mdio0 label for mdio@e1120, but not
define a label for any other node?
and 'powerpc/corenet: Add DPAA
FMan support to the SoC device tree(s)' -
http://patchwork.ozlabs.org/patch/370868 add content to said node
This one adds content to some mdio nodes, none of which are mdio@fc000
or mdio0.
-Scott
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v2 5/7] powerpc/corenet: Add MDIO bus muxing support to the board device tree(s)
Hello Scott,
On 07/30/2014 09:30 PM, Scott Wood wrote:
On Wed, 2014-07-30 at 16:52 -0500, Emil Medve wrote:
Hello Scott,
On 07/29/2014 02:58 PM, Scott Wood wrote:
On Mon, 2014-07-28 at 06:51 +, Emil Medve wrote:
Hello Scott,
Scott Wood scottwood at freescale.com writes:
On Wed, 2014-07-16 at 15:17 -0500, Shruti Kanetkar wrote:
+mdio at fd000 {
+/* For 10g interfaces */
+phy_xaui_slot1: xaui-phy at slot1 {
+status = disabled;
+compatible =
ethernet-phy-ieee802.3-c45;
+reg = 0x7; /* default switch
setting on slot1 of AMC2PEX */
+};
Why xaui-phy and not ethernet-phy?
As for the device_type discussion from v1, there is a generic binding
that says device_type should be ethernet-phy.
I have no strong feelings about this and we can use ethernet-phy, but:
1. The binding is old/stale (?) as it still uses device_type and the kernel
doesn't seem to use anymore the device_type for PHY(s)
Yes.
2. The binding asks ethernet-phy for the device_type property, not for
the
name. As such TBI PHY(s) use (upstream) the tbi-phy@ node name
It shows ethernet-phy as the name in the example. ePAPR urges generic
node names (this was also a recommendation for IEEE1275), and has
ethernet-phy on the preferred list. Is a xaui-phy not an ethernet phy?
So you thinking somebody should cleanup all the sgmii-phy and tbi-phy
node names, huh?
No, I was just wondering why we're adding yet another name, and whether
there's any value in it.
That's fair. We'll just use ethernet-phy
It seems that a number of tbi-phy instances slipped by you:
1be62c6 powerpc/mpc85xx: Add BSC9132 QDS Support
bf57aeb powerpc/85xx: add the P1020RDB-PD DTS support
8a6be2b powerpc/85xx: Add TWR-P1025 board support
tbi-phy is existing practice. xaui-phy isn't.
+mdio0: mdio at fc000 {
+};
Why is the empty node needed?
For the label
For mdio-parent-bus, or is there some other dts layer that makes this
node non-empty?
'powerpc/corenet: Create the dts components for the DPAA FMan' -
http://patchwork.ozlabs.org/patch/370872
Why does this patch define the mdio0 label for mdio@e1120, but not
define a label for any other node?
Only MDIO controllers that are pinned out have these labels. Only pinned
out MDIO(s) are capable of controlling external PHY(s) via these board
level MDIO buses
and 'powerpc/corenet: Add DPAA
FMan support to the SoC device tree(s)' -
http://patchwork.ozlabs.org/patch/370868 add content to said node
This one adds content to some mdio nodes, none of which are mdio@fc000
or mdio0.
This patch adds the SoC level PHY(s), which in this case are just TBI
PHY(s): i.e. no FMan v2 10 Gb/s MDIO or FMan v3 standalone MDIO devices.
Also the labels become relevant only at board level to connect the MDIO
buses to their corresponding MDIO controllers
Cheers,
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v2 5/7] powerpc/corenet: Add MDIO bus muxing support to the board device tree(s)
On Wed, 2014-07-30 at 23:35 -0500, Emil Medve wrote:
Hello Scott,
On 07/30/2014 09:30 PM, Scott Wood wrote:
On Wed, 2014-07-30 at 16:52 -0500, Emil Medve wrote:
+ mdio0: mdio at fc000 {
+ };
Why is the empty node needed?
For the label
For mdio-parent-bus, or is there some other dts layer that makes this
node non-empty?
'powerpc/corenet: Create the dts components for the DPAA FMan' -
http://patchwork.ozlabs.org/patch/370872
Why does this patch define the mdio0 label for mdio@e1120, but not
define a label for any other node?
Only MDIO controllers that are pinned out have these labels. Only pinned
out MDIO(s) are capable of controlling external PHY(s) via these board
level MDIO buses
Is there any reason to describe non-pinned-out MDIO controllers at all?
Is the lack of pinning out inherent to the silicon, or is it board
design/config? Is the answer different for different MDIO controllers?
I'm just curious why mdio@e1120 is labelled in a non-board dtsi while
others are labelled elsewhere.
-Scott
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v2 5/7] powerpc/corenet: Add MDIO bus muxing support to the board device tree(s)
Hello Scott,
On 07/31/2014 12:28 AM, Scott Wood wrote:
On Wed, 2014-07-30 at 23:35 -0500, Emil Medve wrote:
Hello Scott,
On 07/30/2014 09:30 PM, Scott Wood wrote:
On Wed, 2014-07-30 at 16:52 -0500, Emil Medve wrote:
+ mdio0: mdio at fc000 {
+ };
Why is the empty node needed?
For the label
For mdio-parent-bus, or is there some other dts layer that makes this
node non-empty?
'powerpc/corenet: Create the dts components for the DPAA FMan' -
http://patchwork.ozlabs.org/patch/370872
Why does this patch define the mdio0 label for mdio@e1120, but not
define a label for any other node?
Only MDIO controllers that are pinned out have these labels. Only pinned
out MDIO(s) are capable of controlling external PHY(s) via these board
level MDIO buses
Is there any reason to describe non-pinned-out MDIO controllers at all?
Yes. For the internal TBI PHY(s). Each MAC supporting SGMII has a TBI
PHY that is attached to the MDIO controller of the respective MAC
Is the lack of pinning out inherent to the silicon, or is it board
design/config?
It's a silicon level decision
Is the answer different for different MDIO controllers?
You mean non-FSL MDIO controllers? Dunno. All FSL SoC have the same MDIO
pin-out decision
I'm just curious why mdio@e1120 is labelled in a non-board dtsi while
others are labelled elsewhere.
Labels are relevant only in the context of 'powerpc/corenet: Add MDIO
bus muxing support to the board device tree(s)' -
http://patchwork.ozlabs.org/patch/370866. Most labels are created and
used in the board .dts file except b4qds.dtsi which is shared between
b4420qds.dts and b4860qds.dts
Cheers,
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v2 5/7] powerpc/corenet: Add MDIO bus muxing support to the board device tree(s)
On Mon, 2014-07-28 at 06:51 +, Emil Medve wrote:
Hello Scott,
Scott Wood scottwood at freescale.com writes:
On Wed, 2014-07-16 at 15:17 -0500, Shruti Kanetkar wrote:
+ mdio at fd000 {
+ /* For 10g interfaces */
+ phy_xaui_slot1: xaui-phy at slot1 {
+ status = disabled;
+ compatible =
ethernet-phy-ieee802.3-c45;
+ reg = 0x7; /* default switch setting
on slot1 of AMC2PEX */
+ };
Why xaui-phy and not ethernet-phy?
As for the device_type discussion from v1, there is a generic binding
that says device_type should be ethernet-phy.
I have no strong feelings about this and we can use ethernet-phy, but:
1. The binding is old/stale (?) as it still uses device_type and the kernel
doesn't seem to use anymore the device_type for PHY(s)
Yes.
2. The binding asks ethernet-phy for the device_type property, not for the
name. As such TBI PHY(s) use (upstream) the tbi-phy@ node name
It shows ethernet-phy as the name in the example. ePAPR urges generic
node names (this was also a recommendation for IEEE1275), and has
ethernet-phy on the preferred list. Is a xaui-phy not an ethernet phy?
+ mdio0: mdio at fc000 {
+ };
Why is the empty node needed?
For the label
For mdio-parent-bus, or is there some other dts layer that makes this
node non-empty?
-Scott
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v2 5/7] powerpc/corenet: Add MDIO bus muxing support to the board device tree(s)
Hello Scott,
Scott Wood scottwood at freescale.com writes:
On Wed, 2014-07-16 at 15:17 -0500, Shruti Kanetkar wrote:
+ mdio at fd000 {
+ /* For 10g interfaces */
+ phy_xaui_slot1: xaui-phy at slot1 {
+ status = disabled;
+ compatible =
ethernet-phy-ieee802.3-c45;
+ reg = 0x7; /* default switch setting
on slot1 of AMC2PEX */
+ };
Why xaui-phy and not ethernet-phy?
As for the device_type discussion from v1, there is a generic binding
that says device_type should be ethernet-phy.
I have no strong feelings about this and we can use ethernet-phy, but:
1. The binding is old/stale (?) as it still uses device_type and the kernel
doesn't seem to use anymore the device_type for PHY(s)
2. The binding asks ethernet-phy for the device_type property, not for the
name. As such TBI PHY(s) use (upstream) the tbi-phy@ node name
BTW, that binding
(net/phy.txt) could use some cleaning up -- it still has references to
things like linux,phandle.
diff --git a/arch/powerpc/boot/dts/b4qds.dtsi
b/arch/powerpc/boot/dts/b4qds.dtsi
index 8b47edc..6188583 100644
--- a/arch/powerpc/boot/dts/b4qds.dtsi
+++ b/arch/powerpc/boot/dts/b4qds.dtsi
at at -39,6 +39,13 at at
#size-cells = 2;
interrupt-parent = mpic;
+ aliases {
+ phy_sgmii_10 = phy_sgmii_10;
+ phy_sgmii_11 = phy_sgmii_11;
+ phy_sgmii_1c = phy_sgmii_1c;
+ phy_sgmii_1d = phy_sgmii_1d;
+ };
Is the encoding of these alias strings considered ABI (for either the
OS's use or U-Boot's)?
U-Boot uses these aliases
If so, please document it.
Will do
If not, how do you
see this being used? What does the hex number mean from the user's
perspective?
+ mdio0: mdio at fc000 {
+ };
Why is the empty node needed?
For the label
Cheers,
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v2 5/7] powerpc/corenet: Add MDIO bus muxing support to the board device tree(s)
On Wed, 2014-07-16 at 15:17 -0500, Shruti Kanetkar wrote:
Based on prior work by Andy Fleming aflem...@gmail.com
Signed-off-by: Shruti Kanetkar shr...@freescale.com
---
What changed from v2?
+ mdio@fc000 {
+ phy_sgmii_1e: ethernet-phy@1e {
+ status = disabled;
+ reg = 0x1e;
+ };
Whitespace
+ phy_sgmii_1f: ethernet-phy@1f {
+ status = disabled;
+ reg = 0x1f;
+ };
+ };
+
+ mdio@fd000 {
+ /* For 10g interfaces */
+ phy_xaui_slot1: xaui-phy@slot1 {
+ status = disabled;
+ compatible =
ethernet-phy-ieee802.3-c45;
+ reg = 0x7; /* default switch setting
on slot1 of AMC2PEX */
+ };
Why xaui-phy and not ethernet-phy?
As for the device_type discussion from v1, there is a generic binding
that says device_type should be ethernet-phy. BTW, that binding
(net/phy.txt) could use some cleaning up -- it still has references to
things like linux,phandle.
diff --git a/arch/powerpc/boot/dts/b4qds.dtsi
b/arch/powerpc/boot/dts/b4qds.dtsi
index 8b47edc..6188583 100644
--- a/arch/powerpc/boot/dts/b4qds.dtsi
+++ b/arch/powerpc/boot/dts/b4qds.dtsi
@@ -39,6 +39,13 @@
#size-cells = 2;
interrupt-parent = mpic;
+ aliases {
+ phy_sgmii_10 = phy_sgmii_10;
+ phy_sgmii_11 = phy_sgmii_11;
+ phy_sgmii_1c = phy_sgmii_1c;
+ phy_sgmii_1d = phy_sgmii_1d;
+ };
Is the encoding of these alias strings considered ABI (for either the
OS's use or U-Boot's)? If so, please document it. If not, how do you
see this being used? What does the hex number mean from the user's
perspective?
+ mdio0: mdio@fc000 {
+ };
Why is the empty node needed?
-Scott
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
