From: Florian Fainelli <f.fainelli@gmail.com>
To: Niklas Cassel <niklas.cassel@linaro.org>,
Peter Ujfalusi <peter.ujfalusi@ti.com>
Cc: Marc Gonzalez <marc.w.gonzalez@free.fr>,
Andrew Lunn <andrew@lunn.ch>, Vinod Koul <vkoul@kernel.org>,
David S Miller <davem@davemloft.net>,
linux-arm-msm@vger.kernel.org,
Bjorn Andersson <bjorn.andersson@linaro.org>,
netdev@vger.kernel.org, "Nori, Sekhar" <nsekhar@ti.com>
Subject: Re: [PATCH] net: phy: at803x: disable delay only for RGMII mode
Date: Thu, 14 Feb 2019 16:14:47 -0800 [thread overview]
Message-ID: <af63c844-876a-b8b2-15c5-e8dcda0a7897@gmail.com> (raw)
In-Reply-To: <20190214150649.GA29957@centauri.lan>
On 2/14/19 7:06 AM, Niklas Cassel wrote:
> On Thu, Feb 14, 2019 at 03:22:28PM +0200, Peter Ujfalusi wrote:
>> Hi Niklas,
>>
>> On 14/02/2019 14.39, Niklas Cassel wrote:
>>>>> So, I've rebased your old patch, see attachment.
>>>>> I suggest that Peter test it on am335x-evm.
>>>>
>>>> with the patch + s/rgmii-txid/rgmii-id in the am335x-evmsk.dts ethernet
>>>> is working.
>>>> I don't have am335x-evm to test, but it has the same PHY as evmsk.
>>>>
>>>
>>> Florian's concern was that this PHY driver looked at "phy-mode" from the
>>> perspective of the MAC rather than the PHY.
>>> However, if s/rgmii-txid/rgmii-id is the correct fix for am335x-evm,
>>> then this means that this PHY driver was just broken.
>>>
>>> If the driver had misinterpreted the perspective, then the correct
>>> fix for am335x-evm would have been s/rgmii-txid/rgmii-rxid.
>>
>> Not sure if I got this right, but:
>> rgmii-id/txid/rxid is the delay mode between PHY and MAC, right?
>> on the PHY node it is from the PHY perspective, right?
>
> Yes, from the PHY perspective.
>
> (According to Florian, IIUC, some old PHY drivers were implemented before
> it was decided that it is from PHY perspective, rather than from MAC
> perspective.)
>
>>
>> The errata I have mentioned for am335x say:
>> "The reset state of RGMII1_IDMODE (bit 4) and RGMII2_IDMODE (bit 5) in
>> the GMII_SEL register enables internal delay mode on the transmit clock
>> of the respective RGMII port. The AM335x device does not support
>> internal delay mode, so RGMII1_IDMODE and RGMII2_IDMODE must be set to 1b."
>>
>> If the delay mode on the transmit clock is not working on the am335x,
>> then this translate that the rxid needs to be enabled on the PHY side?
>
> IIUC what Florian explained, then either MAC or PHY needs to add delays,
> so if the PHY only adds delay on e.g. TX, then the MAC needs to add delay
> on RX.
>
> However, in your case, the errata says that your MAC is not capable of
> adding a delay on TX, therefore the PHY needs to add a delay on TX.
So that mandates specifying either 'rgmii-id' or 'rgmii-txid'.
>
>>
>> But then why it worked when only the txid was enabled and rxid was not
>> on the PHY side, and why it works if both txid and rxid is enabled?
>
> Because the PHY driver was broken, so the PHY driver always enabled
> delays on both TX and RX.
>
> This is how the driver looked before Vinod's change:
>
> if (phydev->interface == PHY_INTERFACE_MODE_RGMII_RXID ||
> phydev->interface == PHY_INTERFACE_MODE_RGMII_ID) {
> ret = at803x_enable_rx_delay(phydev);
> if (ret < 0)
> return ret;
> }
>
> if (phydev->interface == PHY_INTERFACE_MODE_RGMII_TXID ||
> phydev->interface == PHY_INTERFACE_MODE_RGMII_ID) {
> ret = at803x_enable_tx_delay(phydev);
> if (ret < 0)
> return ret;
> }
>
>
> Yet, the initial value for this PHY is that both TX and RX delay is
> enabled, and since this driver never disabled TX/RX delays,
> the TX and RX delays were always enabled, no matter what phy-mode
> you specified.
Fixing all PHY drivers is probably too much, but since we seem to have
traction and people assigned to QCOM working on this at803x PHY driver,
then let's fix it correctly, I agree with that. So that means:
- disable both RX and TX delay by default
- if RGMII_RXID or RGMII_ID is specified: turn on RX delay
- if RGMII_TXID or RGMII_ID is specified: turn on TX delay
so basically the patch above, with an initial delay disabling for both
RX and TX. Then we fix all DTSes to be correct, at least those in tree
and we provide appropriate Fixes: tag so things get backported
automatically.
How does that sound?
--
Florian
next prev parent reply other threads:[~2019-02-15 0:15 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-02-12 14:19 [PATCH] net: phy: at803x: disable delay only for RGMII mode Vinod Koul
2019-02-13 7:02 ` Peter Ujfalusi
2019-02-15 10:16 ` Vinod Koul
2019-02-13 13:12 ` Niklas Cassel
2019-02-13 13:29 ` Andrew Lunn
2019-02-13 13:40 ` Marc Gonzalez
2019-02-13 17:40 ` Niklas Cassel
2019-02-13 17:59 ` Florian Fainelli
2019-02-13 20:07 ` Niklas Cassel
2019-02-13 21:38 ` Florian Fainelli
2019-02-14 10:49 ` Peter Ujfalusi
2019-02-14 12:39 ` Niklas Cassel
2019-02-14 13:22 ` Peter Ujfalusi
2019-02-14 15:06 ` Niklas Cassel
2019-02-15 0:14 ` Florian Fainelli [this message]
2019-02-14 16:38 ` David Miller
2019-02-14 16:46 ` Marc Gonzalez
2019-02-14 17:33 ` David Miller
2019-02-15 9:58 ` Vinod Koul
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=af63c844-876a-b8b2-15c5-e8dcda0a7897@gmail.com \
--to=f.fainelli@gmail.com \
--cc=andrew@lunn.ch \
--cc=bjorn.andersson@linaro.org \
--cc=davem@davemloft.net \
--cc=linux-arm-msm@vger.kernel.org \
--cc=marc.w.gonzalez@free.fr \
--cc=netdev@vger.kernel.org \
--cc=niklas.cassel@linaro.org \
--cc=nsekhar@ti.com \
--cc=peter.ujfalusi@ti.com \
--cc=vkoul@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).