Thread (1 message) 1 message, 1 author, 2017-01-17

[PATCH 0/5] meson-gx: reset RGMII PHYs and configure TX delay

From: martin.blumenstingl@googlemail.com (Martin Blumenstingl)
Date: 2017-01-17 22:44:24
Also in: linux-amlogic, linux-devicetree

On Tue, Jan 17, 2017 at 11:26 PM, Jerome Brunet [off-list ref] wrote:
On Tue, 2017-01-17 at 22:09 +0100, Martin Blumenstingl wrote:
quoted
On Tue, Jan 17, 2017 at 8:23 PM, Jerome Brunet [off-list ref]
wrote:
quoted
On Sat, 2016-12-03 at 00:47 +0100, Martin Blumenstingl wrote:
quoted
This partially fixes the 1000Mbit/s ethernet TX throughput issues
(on
networks which are not affected by the EEE problem, as reported
here:
[1]).
The actual problem for the TX throughput issues was that the TX
delay
was applied twice:
- once "accidentally" by the PHY (this was fixed with [2])
- once by the MAC because there was a hardcoded TX delay (of
2ns),
  this will be configurable with the changes from [0]

These are the dts changes which belong to my other series (in v2
these patches were part of the other series, upon request of the
net maintainers I have split the .dts changes into their own
series
so
we are able to take both through different trees):
"[PATCH net-next v3 0/2] stmmac: dwmac-meson8b: configurable
RGMII TX delay": [0].
Thus this series depends on the ACK for the binding changes in
the
other series!

I based these changes on my other series "[PATCH v2 0/2] GXL and
GXM
SCPI improvements": [3]


[0] http://lists.infradead.org/pipermail/linux-amlogic/2016-Decem
ber/
001834.html
[1] http://lists.infradead.org/pipermail/linux-amlogic/2016-Novem
ber/
001607.html
[2] http://lists.infradead.org/pipermail/linux-amlogic/2016-Novem
ber/
001707.html
[3] http://lists.infradead.org/pipermail/linux-amlogic/2016-Decem
ber/
001831.html

Martin Blumenstingl (5):
  ARM64: dts: meson-gx: move the MDIO node to meson-gx
Sorry for the late reply, I've only been able to test this
yesterday.

With "snps,dwmac-mdio" provided in meson-gx.dtsi, the mdio_node is
defined in stmmac_mdio_register and auto-detection of the PHY is
disabled for all meson-gx boards.

I wonder if this is desirable ? or maybe this something we could
fix in
stmmac ? (perform auto-detect the mdio bus is provided without a
PHY)
actually it's only a "problem" when introducing support for new
devices. can you please forward this question to the stmmac
maintainers, as I think your idea of enabling auto-detection when
there are no children in the MDIO-bus makes sense
That's one way to address the issue, sure. I just wonder if we should
keep the declaration of the mdio bus with "snps,dwmac-mdio" in the dts
using it, with the phy explicitly declared ...

Otherwise, we have to make clear that you must always explicitly
declare your PHY in amlogic's dts so there is no surprise.

As you mentioned, we missed the gxbb-nexbox-a95. No phy declared in
that dts, but it still get the mdio bus from meson-gx.dtsi. So as of
"ARM64: dts: meson-gx: move the MDIO node to meson-gx" the PHY is not
detected on this board.
indeed, however I'd like to point out that this was already a
restriction for GXL and GXM based boards before.
I'm open to any solution though as breaking things is always bad
quoted
quoted
Also, I think bisect is broken between patch 1 and patch 4: The PHY
of
some boards won't be detected between these patches. Should we
squash
them ?
what do you mean exactly? currently the TX-delay is hardcoded in
dwmac-meson8b. patch 4 moves the hardcoded value from the
dwmac-meson8b to the .dts-files.
unfortunately the corresponding dwmac-meson8b patch was not accepted
yet, so at the moment patch 4 should be a no-op.
Nothing related to the tx-delay ... I'm all for it ;) Thx for your work
by the way

What I meant is that as of "ARM64: dts: meson-gx: move the MDIO node to
meson-gx" all boards not declaring the PHY explicitly can't detect it
anymore. that's more or less all gxbb boards

With "ARM64: dts: meson-gxbb-odroidc2: add reset for the ethernet PHY"
the odroid gets fixed ... but the p200 and vega-s95 are still broken

With the next patch, the p200 is/should have been fixed, then the vega-
s95 is fixed

In the end the gxbb-nexbox is still broken. To be honest I did not
verify if there any other board in that case.

My point is that I think the declaration of the mdio bus in meson-
gx.dtsi and the declaration of each PHY in the board dtss should be
done in single commit to avoid having a (very) short part of the
history with regressions
now I see the dependency, thanks for pointing this out!
Depending on the decision for above problem (MDIO-bus in meson-gx.dtsi
or not) I can provide a v2 with all issues addressed.

quoted
quoted
quoted
  ARM64: dts: meson-gxbb-odroidc2: add reset for the ethernet PHY
  ARM64: dts: meson-gxbb-p20x: add reset for the ethernet PHY
  ARM64: dts: meson-gxbb-vega-s95: add reset for the ethernet PHY
  ARM64: dts: amlogic: add the ethernet TX delay configuration
Last remark, about the use of ethernet-phy-idXXXX.XXXX in the
odroid
and the vega: Isn't it better to let phylib do the autodetection of
the
phy id ?

If we want to specify the id in DT, we should probably add it for
the
Micrel PHY of the p200 as well, for consistency.
this seems to be a "best practice" when the PHY ID is known, see [0]
If you know the PHY ID of the Micrel PHY then please let me know,
then
we can include this in the fix for the p20x boards
OK
quoted
quoted
quoted
 arch/arm64/boot/dts/amlogic/meson-gx.dtsi            |  6 ++++++
 arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts  | 17
+++++++++++++++++
 arch/arm64/boot/dts/amlogic/meson-gxbb-p20x.dtsi     | 17
+++++++++++++++++
 arch/arm64/boot/dts/amlogic/meson-gxbb-vega-s95.dtsi | 17
+++++++++++++++++
 arch/arm64/boot/dts/amlogic/meson-gxl-s905d-p230.dts |  2 ++
 arch/arm64/boot/dts/amlogic/meson-gxl.dtsi           |  6 ------
 arch/arm64/boot/dts/amlogic/meson-gxm-nexbox-a1.dts  |  2 ++
 arch/arm64/boot/dts/amlogic/meson-gxm-s912-q200.dts  |  2 ++
 8 files changed, 63 insertions(+), 6 deletions(-)
[0] http://lxr.free-electrons.com/source/Documentation/devicetree/bin
dings/net/phy.txt#L22
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help