[RFC PATCH 4/7] ath79: prepare for 1-port TP-Link EAP2x5 devices

[David Bauer]

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
>