Hello Sander,
On 7/18/20 10:40 PM, Sander Vanheule wrote:
> Hi David,
>
> On Sat, 2020-07-18 at 21:45 +0200, David Bauer wrote:
>>> + gmac-config {
>>> + device = <&gmac>;
>>> +
>>> + rgmii-ge0 = <1>;
>>> + ge0-sgmii = <1>;
>>> + rxdv-delay = <3>;
>>> + rxd-delay = <3>;
>>
>> This does not make a lot of sense to me. Enabling both RGMII
>> as well as SGMII for GE0 might work but it is most likely an
>> undefined state.
>>
>> Also the QCA956x does not offer RGMII for the MAC at all. Therefore,
>> setting RGMII
>> delays dhouldn't be necessary.
>>
>> This applies to your GMAC settings export in general. From my
>> perspective, only the
>> ge0-sgmii should matter at all?
>>
>
> I guess j-d-r used TP-Link's code and went from there, since it works.
> And I must admit that my knowledge on xMII and these SoCs is very
> superficial, so none of this code is obvious to me.
> If I only keep the ge0-sgmii as you suggested, things still work, so I
> guess I can trim things down to keep just that.
>
> For reference, TP-Link (Qualcomm?) sets things up as follows:
> void ath_gmac_mii_setup(void)
> {
> unsigned int mgmt_cfg_val;
> ath_reg_wr(SWITCH_CLOCK_SPARE_ADDRESS, 0xc5200);
>
> mgmt_cfg_val = 7;
> ath_reg_wr(ETH_CFG_ADDRESS, ETH_CFG_ETH_RXDV_DELAY_SET(3) |
> ETH_CFG_ETH_RXD_DELAY_SET(3)|
> ETH_CFG_RGMII_GE0_SET(1) |
> ETH_CFG_GE0_SGMII_SET(1) );
> ath_reg_wr(ETH_XMII_ADDRESS, ETH_XMII_TX_INVERT_SET(1) |
> ETH_XMII_RX_DELAY_SET(2) |
> ETH_XMII_TX_DELAY_SET(1) |
> ETH_XMII_GIGE_SET(1));
> udelay(1000);
> ath_reg_wr(ATH_MAC_MII_MGMT_CFG, mgmt_cfg_val | (1 << 31));
> ath_reg_wr(ATH_MAC_MII_MGMT_CFG, mgmt_cfg_val);
> }
>
> ยง8.8.1 ETH_CFG in the datasheet I referred to earlier lists the rgmii-
> ge0/rgmii-enabled bit as reserved, but the delays are listed there.
SGMII does not have TXEn signals and data signals to delay. I also have no idea
about the electrical level of the SoC, but the GE0_SGMII bit controlled a
multiplexer
on the previous generation, where the SGMII path was separated from the (R)GMII
path.
I don't see any value in having these options exposed. The only bit which could
matter
is the GE0_SGMII bit and this one we can hardcode based on the SoC generation
and phy-mode.
Best wishes
David
>
>
> Thanks,
> Sander
>
_______________________________________________
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
