[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <573258a9-b115-ca4a-121c-5174798d5621@gmail.com>
Date: Fri, 4 May 2018 10:45:17 +0200
From: Michal Vokáč <vokac.m@...il.com>
To: Andrew Lunn <andrew@...n.ch>
Cc: netdev@...r.kernel.org,
Vivien Didelot <vivien.didelot@...oirfairelinux.com>,
Florian Fainelli <f.fainelli@...il.com>
Subject: Re: i.MX6S/DL and QCA8334 switch using DSA driver - CPU port not
working
On 30.4.2018 15:20, Andrew Lunn wrote:
>> Using rgmii-id for the port is not valid as the qca8k driver does not support
>> that mode. It only supports rgmii and sgmii. I think this is actually not
>> correct. When phy-mode is set to rgmii for port the qca8k driver configures
>> internal delays in the switch. So it behaves like rgmii-id I think.
>>
>> Should not it be:
>>
>> --- a/drivers/net/dsa/qca8k.c
>> +++ b/drivers/net/dsa/qca8k.c
>> @@ -474,7 +474,7 @@ qca8k_set_pad_ctrl(struct qca8k_priv *priv, int port, int mode)
>> * PHY or MAC.
>> */
>> switch (mode) {
>> - case PHY_INTERFACE_MODE_RGMII:
>> + case PHY_INTERFACE_MODE_RGMII_ID:
>> qca8k_write(priv, reg,
>> QCA8K_PORT_PAD_RGMII_EN |
>> QCA8K_PORT_PAD_RGMII_TX_DELAY(3) |
>
> We have to be careful cleaning this up. It has the potential to break
> existing boards when using an old device tree blob.
Oh, I see. Thanks for pointing this out.
Some news to the problem with the non-working CPU port.
Andrew, thank you very mych for the ideas how to debug the issue.
I tried what you suggested but have no luck. FYI Now I am doing all my tests
with linux-stable.
First of all I tried to make work my old phy driver for the switch with latest
kernel. It works on v4.1.46 but did not on v4.17-rc2 - no IP@ on eth0.
So a very same issue as I have with the DSA. Bisecting the kernel picked:
d5c3d84 ("net: phy: Avoid polling PHY with PHY_IGNORE_INTERRUPTS")
Fixed that by using PHY_POLL in my driver. I was hoping that I may have similar
issue when using DSA but it looks OK. This is with the DSA enabled:
# dmesg | grep PHY
[ 3.452536] Generic PHY 2188000.ethernet-1:01: attached PHY driver [Generic PHY] (mii_bus:phy_addr=2188000.ethernet-1:01, irq=POLL)
[ 3.453437] Generic PHY 2188000.ethernet-1:02: attached PHY driver [Generic PHY] (mii_bus:phy_addr=2188000.ethernet-1:02, irq=POLL)
[ 20.769281] Generic PHY fixed-0:00: attached PHY driver [Generic PHY] (mii_bus:phy_addr=fixed-0:00, irq=POLL)
Anyway, now I am sure that I can use RGMII interface with mainline when I am
not using DSA and phy-mode is set to rgmii and I use QCA8K_PORT_PAD_RGMII_TX_DELAY(2)
and QCA8K_PORT_PAD_RGMII_RX_DELAY(2).
To debug the non-working CPU port with DSA I tried these kernel versions:
- v4.8-rc6-1085-g6b93fb4 - NOT OK
- Can not go lower than this version. qca8k driver was introduced here.
- 4.9.84 - NOT OK
- 4.17-rc2 - NOT OK
Some RGMII delay tunning attempts with v4.17-rc2:
phy-mode (fec) Rx/Tx delay result
--------------------------------------
rgmii 0/0 NOT OK
rgmii 1/1 NOT OK
rgmii 2/2 NOT OK
rgmii 3/3 NOT OK
rgmii-id 0/0 NOT OK
rgmii-id 1/1 NOT OK
rgmii-id 2/2 NOT OK
rgmii-id 3/3 NOT OK
I am out of ideas how to further debug this.
Any additional adivce will be much appreciated.
Thanks, Michal.
Powered by blists - more mailing lists