| Message ID | 20241225-support_10m100m-v1-0-4b52ef48b488@quicinc.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | Support tuning the RX sampling swap of the MAC. | expand |
On Wed, Dec 25, 2024 at 06:04:44PM +0800, Yijie Yang wrote: > The Ethernet MAC requires precise sampling times at Rx, but signals on the > Rx side after transmission on the board may vary due to different hardware > layouts. The RGMII_CONFIG2_RX_PROG_SWAP can be used to switch the sampling > occasion between the rising edge and falling edge of the clock to meet the > sampling requirements. The RGMII specification says that RD[3:0] pins are sampled on the rising edge for bits 3:0 and falling edge for bits 7:4. Given this is part of the standard, why would you want to do anything else? Is this maybe another symptom of having the RGMII delays messed up? Anyway, i don't see a need for this property, unless you are working with a PHY which breaks the RGMII standard, and has its clock reversed? Andrew
On 2024-12-26 01:49, Andrew Lunn wrote: > On Wed, Dec 25, 2024 at 06:04:44PM +0800, Yijie Yang wrote: >> The Ethernet MAC requires precise sampling times at Rx, but signals on the >> Rx side after transmission on the board may vary due to different hardware >> layouts. The RGMII_CONFIG2_RX_PROG_SWAP can be used to switch the sampling >> occasion between the rising edge and falling edge of the clock to meet the >> sampling requirements. > > The RGMII specification says that RD[3:0] pins are sampled on the > rising edge for bits 3:0 and falling edge for bits 7:4. > > Given this is part of the standard, why would you want to do anything > else? > > Is this maybe another symptom of having the RGMII delays messed up? > > Anyway, i don't see a need for this property, unless you are working > with a PHY which breaks the RGMII standard, and has its clock > reversed? Please correct me if there are any errors. As described in the Intel and TI design guidelines, Dual Data Rate (DDR), which samples at both edges of the clock, is primarily used for 1Gbps speeds. For 100Mbps and 10Mbps speeds, Single Data Rate (SDR), which samples at the rising edge of the clock, is typically adopted. This patch set introduces such a flag mainly for 100M/10M speeds, as described in the cover letter. > > Andrew
On Thu, Dec 26, 2024 at 11:06:48AM +0800, Yijie Yang wrote: > > > On 2024-12-26 01:49, Andrew Lunn wrote: > > On Wed, Dec 25, 2024 at 06:04:44PM +0800, Yijie Yang wrote: > > > The Ethernet MAC requires precise sampling times at Rx, but signals on the > > > Rx side after transmission on the board may vary due to different hardware > > > layouts. The RGMII_CONFIG2_RX_PROG_SWAP can be used to switch the sampling > > > occasion between the rising edge and falling edge of the clock to meet the > > > sampling requirements. > > > > The RGMII specification says that RD[3:0] pins are sampled on the > > rising edge for bits 3:0 and falling edge for bits 7:4. > > > > Given this is part of the standard, why would you want to do anything > > else? > > > > Is this maybe another symptom of having the RGMII delays messed up? > > > > Anyway, i don't see a need for this property, unless you are working > > with a PHY which breaks the RGMII standard, and has its clock > > reversed? > > Please correct me if there are any errors. As described in the Intel and TI > design guidelines, Dual Data Rate (DDR), which samples at both edges of the > clock, is primarily used for 1Gbps speeds. For 100Mbps and 10Mbps speeds, > Single Data Rate (SDR), which samples at the rising edge of the clock, is > typically adopted. If it is typically adopted, why do you need to support falling edge? Because we can is not a good reason. Do you have a board with a PHY which requires falling edge for some reason? Andrew
The Ethernet MAC requires precise sampling times at Rx, but signals on the Rx side after transmission on the board may vary due to different hardware layouts. The RGMII_CONFIG2_RX_PROG_SWAP can be used to switch the sampling occasion between the rising edge and falling edge of the clock to meet the sampling requirements. Consequently, the configuration of this bit in the Ethernet MAC can vary between boards, even if they are of the same version. It should be adjustable rather than simply determined by the version. For example, the MAC version is less than 3, but it needs to enable this bit. Therefore, this patch set introduces a new flag for each board to control whether to open it. The dependency patch set detailed below has introduced and enabled an Ethernet node that supports 1G speed on qcs615. The current patch set now allows tuning of the MAC's RX swap, thereby supporting 10M and 100M speeds. Signed-off-by: Yijie Yang <quic_yijiyang@quicinc.com> --- This patch series depends on below patch series: https://lore.kernel.org/all/20241118-dts_qcs615-v2-0-e62b924a3cbd@quicinc.com/ --- Yijie Yang (3): dt-bindings: net: stmmac: Tune rx sampling occasion net: stmmac: qcom-ethqos: Enable RX programmable swap on qcs615 arm64: dts: qcom: qcs615-ride: Enable RX programmable swap on qcs615-ride .../devicetree/bindings/net/qcom,ethqos.yaml | 6 ++++ arch/arm64/boot/dts/qcom/qcs615-ride.dts | 1 + .../ethernet/stmicro/stmmac/dwmac-qcom-ethqos.c | 36 ++++++++++++---------- 3 files changed, 27 insertions(+), 16 deletions(-) --- base-commit: 532900dbb7c1be5c9e6aab322d9af3a583888f25 change-id: 20241217-support_10m100m-16239916fa12 prerequisite-message-id: <20241118-dts_qcs615-v2-0-e62b924a3cbd@quicinc.com> prerequisite-patch-id: ab55582f3bfce00f051fddd75bb66b2ef5e0677d prerequisite-patch-id: 514acd303f0ef816ff6e61e59ecbaaff7f1b06ec Best regards,