On Mon, Jan 06, 2025 at 01:28:27PM +0530, Anand Moon wrote:
> Hi Andrew,
>
> On Sun, 5 Jan 2025 at 23:27, Andrew Lunn <andrew@xxxxxxx> wrote:
> >
> > On Sun, Jan 05, 2025 at 11:16:21PM +0530, Anand Moon wrote:
> > > Hi Andrew,
> > >
> > > On Fri, 3 Jan 2025 at 21:34, Andrew Lunn <andrew@xxxxxxx> wrote:
> > > >
> > > > > +&gmac1 {
> > > > > + clock_in_out = "output";
> > > > > + phy-handle = <&rgmii_phy1>;
> > > > > + phy-mode = "rgmii";
> > > >
> > > > rgmii is wrong. Please search the archives about this topic, it comes
> > > > up every month. You need to remove the tx_delay and rx_delay
> > > > properties, and use rgmii-id.
> > > >
> > > According to the RKRK3588 TRM-Part1 (section 25.6.11 Clock
> > > Architecture), in RGMII mode,
> > > the TX clock source is exclusively derived from the CRU (Clock Request Unit).
> > > To dynamically adjust the timing alignment between TX/RX clocks and
> > > data, delay lines are
> > > integrated into both the TX and RX clock paths.
> > >
> > > Register SYS_GRF_SOC_CON7[5:2] enables these delay lines,
> > > while registers SYS_GRF_SOC_CON8[15:0] and SYS_GRF_SOC_CON9[15:0]
> > > are used to configure the delay length for each path respectively.
> > > Each delay line comprises 200 individual delay elements.
> > >
> > > Therefore, it is necessary to configure both TX and RX delay values
> > > appropriately
> > > with phy-mode set as rgmii.
> > >
> > > [1[ https://github.com/torvalds/linux/blob/master/drivers/net/ethernet/stmicro/stmmac/dwmac-rk.c#L1889-L1914
> > >
> > > I have gone through a few of the archives about this topic
> > >
> > > [2] https://lore.kernel.org/linux-rockchip/4fdcb631-16cd-d5f1-e2be-19ecedb436eb@xxxxxxxxxx/T/
> >
> > O.K, let me repeat what i have said a number of times over the last
> > couple of years.
> >
> > phy-mode = "rgmii" means the PCB has extra long clock lines on the
> > PCB, so the 2ns delay is provided by them.
> >
> > phy-mode = "rgmii-id" means the MAC/PHY pair need to arrange to add
> > the 2ns delay. As far as the DT binding is concerned, it does not
> > matter which of the two does the delay. However, there is a convention
> > that the PHY adds the delay, if possible.
> >
> > So, does your PCB have extra long clock lines?
> >
> > Vendors often just hack until it works. But works does not mean
> > correct. I try to review as many .dts files as i can, but some do get
> > passed me, so there are plenty of bad examples in mainline.
> >
> > Andrew
>
> Thanks for this tip, I am no expert in hardware design.
>
> Here is the schematic design of the board, it looks like RTL8125B page 24
> is controlled by a PCIe 2.0 bus
As both me an Manivannan said earlier in this thread,
PCIe endpoint devices should not be described in device tree
(the exception is an FPGA, and when you need to describe devices
within the FPGA).
So I think that adding a "ethernet-phy" device tree node in this case is
wrong (as the Ethernet PHY in this case is integrated in the PCIe connected
NIC, and not a discrete component on the SoC).
Kind regards,
Niklas
>
> [0] https://dl.radxa.com/rock5/5b/docs/hw/radxa_rock5b_v13_sch.pdf
>
> PERSTB ---<< PCIE_PERST_L (GPIO3_B0_u)
> LANWAKER --->> PCIE20_1_2_WAKEn_M1_L (GPIO3_D0_u)
> LAN_CLKREQB --->> PCIE20_1_2_CLKREQn_M1_L( GPIO3_C7_u)
> IOLATEB --->> +V3P3A
>
> PCIE2.0 DATA Impedance 85 R
>
> PCIE_WLAN_TX_C_DP ----->PCIE20_0_TXP
> PCIE_WLAN_TX_C_DN ----->PCIE20_0_TXN
>
> PCIE2.0 CLK Impedance 100 R
>
> PCIE3_WLAN_REFCLK0_DP --> PCIE20_0_REFCLKP
> PCIE3_WLAN_REFCLK0_DN--->PCIE20_0_REFCLKN
>
> I have no idea about the grf clk and data path delay over here.
>
> Thanks
> -Anand
