ipq806x: fix MAC_POWER_SEL switch configuration

[bendavid]

Fixes instability/corruption on the ethernet interface connected to port0 on the switch.

Original source of this problem is a possible typo/inconsistency in Qualcomm sources.

Looking at the TP-Link C2600 GPL tarball, there is an inconsistent definition of bits 18 and 19 of the MAC_POWER_SEL register.

In openwrt/qca/src/qca-ssdk-shell/include/init/ssdk_plat.h there is one definition

#define AR8327_REG_PAD_MAC_PWR_SEL                      0x0e4
#define   AR8327_PAD_MAC_PWR_RGMII0_1_8V                BIT(19)
#define   AR8327_PAD_MAC_PWR_RGMII1_1_8V                BIT(18)

And what is currently in the device trees is consistent with this definition.

In openwrt/qca/src/qca-ssdk/include/init/ssdk_plat.h there is instead what I suspect is the correct definition with those two bits flipped.

#define AR8327_REG_PAD_MAC_PWR_SEL                      0x0e4
#define   AR8327_PAD_MAC_PWR_RGMII0_1_8V                BIT(18)
#define   AR8327_PAD_MAC_PWR_RGMII1_1_8V                BIT(19)

Modifying the device tree to be consistent with this definition (enabling bit 18 and disabling bit 19) solves the instability and corruption issues I was having with eth0 on the Archer 2600 at high load. Probably the same problem affects all IPQ806x devices with switch port0 connected to the cpu with rgmii.

[blogic]

:-) how many hours/days did it take to figure out ?

[bendavid]

More than a few hours, not that many days :)

[ianchi]

We discussed this a while back on PR #6.
This is going back to the original config I had on EA8500 (and the same used in dd-wrt).
For me both confs worked the same. Neither one solved the eth1 problem in EA8500.

What is strange, is that at that moment I searched the AR8337 datasheet to check the registers/bits meanings. I've found a datasheet for AR8327 and QCA8337N, and they document all the registers, but nothing is said about register 0x000E4. It is not even mentioned.

QCA8337N Seven-port Gigabit Ethernet Switch Datasheet Register Descriptions
Global control register 0x0000–0x00E0
EEE control register 0x0100–0x0168
Parser control register 0x0200–0x0270
ACL control register 0x0400–0x0454
Lookup control register 0x0600–0x0718
QM control register 0x0800–0x0B70
PKT edit control register 0x0C00–0x0C80
Layer 3 control register 0x0E00-0x0E98

This is what I found at that time on the Linksys GPL board files, and the reason I changed the dts. 8337 is configured with this definition, from drivers/net/phy/ar8216.h:

#define AR8327_REG_MAC_PWR_SEL          0x0e4
#define   AR8327_MAC_PWR_RGMII1_1_8V        BIT(18)
#define   AR8327_MAC_PWR_RGMII0_1_8V        BIT(19)

and thus setting bit 19 to on and 18 off.

[bendavid]

Hah, I had completely forgot about that when debugging this.

For EA8500 I think you will actually need both bits 18 and 19 set to 1, since I suspect you need rgmii working properly on both port0 and port5 (or at least the PHY which is normally used for port5). As you say this is not the cause of the eth1 problems on ea8500 given that the consequences of setting it wrong is an unstable link rather than one which doesn't work at all.

[dtaht]

Is this pulled (or is the right thing the dts change, and that pulled?)

reason: was just about to flash one of these beasties from the buildbot... and it looks like I should hold off.

[blogic]

merged into my staging tree

[ianchi]

@bendavid I can confirm that the original Linksys firmware also uses this mac_power_sel:

dev0@qca>debug reg get 0x0E4 4
[Data]:0x6a545                                            
operate done.

I also checked the rest of the initvals and they all coincide.

So, I still have to find out what is causing trouble with eth1

[bendavid]

The tool to read the registers is included in the stock linksys firmware?

[ianchi]

yes, its called ssdk_sh, it is also used to configure the switch.
I found it after digging arround a little.
It is not included in the GPL source they provide.

[bendavid]

Alright that is indeed very useful. Are you sure the stock firmware is using gmac1 and gmac2 and not one of gmac0/3 for some reason?

[ianchi]

According to Lynksys' GPL source, in the board definition, gmac1 & 2 are used.
I'm not sure if it can be tested somehow from the running fw.