| Message ID | 20231029042712.520010-12-cristian.ciocaltea@collabora.com (mailing list archive) |
|---|---|
| State | Changes Requested |
| Headers | show |
| Series | Enable networking support for StarFive JH7100 SoC | expand |
| Context | Check | Description |
|---|---|---|
| netdev/tree_selection | success | Guessing tree name failed - patch did not apply |
On Sun, Oct 29, 2023 at 06:27:11AM +0200, Cristian Ciocaltea wrote: > The StarFive VisionFive V1 SBC has a Motorcomm YT8521 PHY supporting > RGMII-ID, but requires manual adjustment of the RX internal delay to > work properly. > > The default RX delay provided by the driver is 1.95 ns, which proves to > be too high. Applying a 50% reduction seems to mitigate the issue. I'm not so happy this cannot be explained. You are potentially heading into horrible backwards compatibility problems with old DT blobs and new kernels once this is explained and fixed. Andrew
On 10/29/23 20:45, Andrew Lunn wrote: > On Sun, Oct 29, 2023 at 06:27:11AM +0200, Cristian Ciocaltea wrote: >> The StarFive VisionFive V1 SBC has a Motorcomm YT8521 PHY supporting >> RGMII-ID, but requires manual adjustment of the RX internal delay to >> work properly. >> >> The default RX delay provided by the driver is 1.95 ns, which proves to >> be too high. Applying a 50% reduction seems to mitigate the issue. > > I'm not so happy this cannot be explained. You are potentially heading > into horrible backwards compatibility problems with old DT blobs and > new kernels once this is explained and fixed. It seems the visionfive-v2 board also required setting some delays, but unfortunately no details were provided: 0104340a67b1 ("riscv: dts: starfive: visionfive 2: Add configuration of mac and phy") Thanks, Cristian
On Mon, Oct 30, 2023 at 12:41:23AM +0200, Cristian Ciocaltea wrote: > On 10/29/23 20:45, Andrew Lunn wrote: > > On Sun, Oct 29, 2023 at 06:27:11AM +0200, Cristian Ciocaltea wrote: > >> The StarFive VisionFive V1 SBC has a Motorcomm YT8521 PHY supporting > >> RGMII-ID, but requires manual adjustment of the RX internal delay to > >> work properly. > >> > >> The default RX delay provided by the driver is 1.95 ns, which proves to > >> be too high. Applying a 50% reduction seems to mitigate the issue. > > > > I'm not so happy this cannot be explained. You are potentially heading > > into horrible backwards compatibility problems with old DT blobs and > > new kernels once this is explained and fixed. > > It seems the visionfive-v2 board also required setting some delays, but > unfortunately no details were provided: > > 0104340a67b1 ("riscv: dts: starfive: visionfive 2: Add configuration of > mac and phy") That board also uses a YT8531 PHY. Its possible this is somehow to do with the PHY. Which is why testing with the Microchip PHY is important. That should answer the question is it a SoC or a PHY problem. Andrew
On 10/30/23 00:50, Andrew Lunn wrote: > On Mon, Oct 30, 2023 at 12:41:23AM +0200, Cristian Ciocaltea wrote: >> On 10/29/23 20:45, Andrew Lunn wrote: >>> On Sun, Oct 29, 2023 at 06:27:11AM +0200, Cristian Ciocaltea wrote: >>>> The StarFive VisionFive V1 SBC has a Motorcomm YT8521 PHY supporting >>>> RGMII-ID, but requires manual adjustment of the RX internal delay to >>>> work properly. >>>> >>>> The default RX delay provided by the driver is 1.95 ns, which proves to >>>> be too high. Applying a 50% reduction seems to mitigate the issue. >>> >>> I'm not so happy this cannot be explained. You are potentially heading >>> into horrible backwards compatibility problems with old DT blobs and >>> new kernels once this is explained and fixed. >> >> It seems the visionfive-v2 board also required setting some delays, but >> unfortunately no details were provided: >> >> 0104340a67b1 ("riscv: dts: starfive: visionfive 2: Add configuration of >> mac and phy") > > That board also uses a YT8531 PHY. Its possible this is somehow to do > with the PHY. Which is why testing with the Microchip PHY is > important. That should answer the question is it a SoC or a PHY > problem. There is also YT8531S, which looks compatible with YT8521, but YT8531 seems to be a bit different. Regardless of what VisionFive v2 is using, it would be indeed interesting to find out how the Microchip PHY behaves in this context. Regards, Cristian
diff --git a/arch/riscv/boot/dts/starfive/jh7100-starfive-visionfive-v1.dts b/arch/riscv/boot/dts/starfive/jh7100-starfive-visionfive-v1.dts index e82af72f1aaf..e043a27f7612 100644 --- a/arch/riscv/boot/dts/starfive/jh7100-starfive-visionfive-v1.dts +++ b/arch/riscv/boot/dts/starfive/jh7100-starfive-visionfive-v1.dts @@ -18,3 +18,20 @@ gpio-restart { priority = <224>; }; }; + +&gmac { + phy-handle = <&phy>; + phy-mode = "rgmii-id"; + status = "okay"; + + mdio { + #address-cells = <1>; + #size-cells = <0>; + compatible = "snps,dwmac-mdio"; + + phy: ethernet-phy@0 { + reg = <0>; + rx-internal-delay-ps = <900>; + }; + }; +};
The StarFive VisionFive V1 SBC has a Motorcomm YT8521 PHY supporting RGMII-ID, but requires manual adjustment of the RX internal delay to work properly. The default RX delay provided by the driver is 1.95 ns, which proves to be too high. Applying a 50% reduction seems to mitigate the issue. Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com> --- .../starfive/jh7100-starfive-visionfive-v1.dts | 17 +++++++++++++++++ 1 file changed, 17 insertions(+)