From: Andrew Lunn <andrew@lunn.ch>
To: Biao Huang <biao.huang@mediatek.com>
Cc: davem@davemloft.net, robh+dt@kernel.org,
honghui.zhang@mediatek.com, yt.shen@mediatek.com,
liguo.zhang@mediatek.com, mark.rutland@arm.com,
nelson.chang@mediatek.com, matthias.bgg@gmail.com,
netdev@vger.kernel.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-mediatek@lists.infradead.org, joabreu@synopsys.com
Subject: Re: [v7, PATCH 1/2] net:stmmac: dwmac-mediatek: add support for mt2712
Date: Thu, 13 Dec 2018 13:33:46 +0100 [thread overview]
Message-ID: <20181213123346.GF1605@lunn.ch> (raw)
In-Reply-To: <1544666173-5121-2-git-send-email-biao.huang@mediatek.com>
Hi Biao
> + case PHY_INTERFACE_MODE_RGMII:
> + /* the PHY is not responsible for inserting any internal
> + * delay by itself in PHY_INTERFACE_MODE_RGMII case,
> + * so Ethernet MAC will insert delays for both transmit
> + * and receive path here.
> + */
What if the PCB designed has decided to do a kink in the clock to add
the delays? I don't think any of these delays should depend on the PHY
interface mode. It is up to the device tree writer to set both the PHY
delay and the MAC delay, based on knowledge of the board, including
any kicks in the tracks. The driver should then do what it is told.
> + if (!of_property_read_u32(plat->np, "mediatek,tx-delay-ps", &tx_delay_ps)) {
> + if (tx_delay_ps < plat->variant->tx_delay_max) {
> + mac_delay->tx_delay = tx_delay_ps;
> + } else {
> + dev_err(plat->dev, "Invalid TX clock delay: %dps\n", tx_delay_ps);
> + return -EINVAL;
> + }
> + }
> +
> + if (!of_property_read_u32(plat->np, "mediatek,rx-delay-ps", &rx_delay_ps)) {
> + if (rx_delay_ps < plat->variant->rx_delay_max) {
> + mac_delay->rx_delay = rx_delay_ps;
> + } else {
> + dev_err(plat->dev, "Invalid RX clock delay: %dps\n", rx_delay_ps);
> + return -EINVAL;
> + }
> + }
> +
> + mac_delay->tx_inv = of_property_read_bool(plat->np, "mediatek,txc-inverse");
> + mac_delay->rx_inv = of_property_read_bool(plat->np, "mediatek,rxc-inverse");
> + mac_delay->fine_tune = of_property_read_bool(plat->np, "mediatek,fine-tune");
Why is fine tune needed? If the requested delay can be done using fine
tune, it should use fine tune. If not, it should use rough tune. The
driver can work this out itself.
Thanks
Andrew
next prev parent reply other threads:[~2018-12-13 12:33 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-12-13 1:56 [v7, PATCH 0/2] add Ethernet driver support for mt2712 Biao Huang
2018-12-13 1:56 ` [v7, PATCH 1/2] net:stmmac: dwmac-mediatek: add " Biao Huang
2018-12-13 12:33 ` Andrew Lunn [this message]
2018-12-14 3:01 ` biao huang
2018-12-14 5:11 ` Florian Fainelli
2018-12-14 6:32 ` biao huang
2018-12-13 1:56 ` [v7, PATCH 2/2] dt-binding: mediatek-dwmac: add binding document for MediaTek MT2712 DWMAC Biao Huang
2018-12-13 12:36 ` Andrew Lunn
2018-12-14 2:24 ` biao huang
2018-12-13 2:48 ` [v7, PATCH 0/2] add Ethernet driver support for mt2712 biao huang
2018-12-13 5:40 ` David Miller
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=20181213123346.GF1605@lunn.ch \
--to=andrew@lunn.ch \
--cc=biao.huang@mediatek.com \
--cc=davem@davemloft.net \
--cc=devicetree@vger.kernel.org \
--cc=honghui.zhang@mediatek.com \
--cc=joabreu@synopsys.com \
--cc=liguo.zhang@mediatek.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mediatek@lists.infradead.org \
--cc=mark.rutland@arm.com \
--cc=matthias.bgg@gmail.com \
--cc=nelson.chang@mediatek.com \
--cc=netdev@vger.kernel.org \
--cc=robh+dt@kernel.org \
--cc=yt.shen@mediatek.com \
/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).