meson-gx: reset RGMII PHYs and configure TX delay
Get series with b4
b4 am [email protected]Versions newest first
- v1 Latest1 of 5 patches 0 repliesNew
1 of 5 patches is in this archive. The cover letter announces 5.
Patches in v1 No applies recorded yet
| # | Subject and files | Size | Replies | Applied |
|---|---|---|---|---|
| 3/5 | ARM64: dts: meson-gxbb-p20x: add reset for the ethernet PHY | +0 | 1 reply |
Reviews trailers per patch
No Reviewed-by, Acked-by or Tested-by trailers for v1 yet.
Cover letter [PATCH 0/5] meson-gx: reset RGMII PHYs and configure TX delay
Quoted 58 lines · Martin Blumenstingl
Quoted 56 lines · Jerome Brunet
Quoted 44 lines · Martin Blumenstingl
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.htmlQuoted 2 lines
Martin Blumenstingl (5):
? ARM64: dts: meson-gx: move the MDIO node to meson-gxSorry for the late reply, I've only been able to test this yesterday.
With "snps,dwmac-mdio" provided in
meson-gx.dtsi, themdio_nodeis defined instmmac_mdio_registerand auto-detection of the PHY is disabled for all meson-gx boards.
Quoted 8 lines
Quoted 4 lines
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.
Quoted 7 lines
Quoted 7 lines
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 ?
Quoted 5 lines
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
Quoted 15 lines
Quoted 15 lines
Quoted 8 lines
? 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 ?
Quoted 7 lines
Quoted 3 lines
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 19 lines
Quoted 16 lines
Quoted 10 lines
?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
+++++++++++++++++Quoted 6 lines
?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