Add compatible string for RV1126 gmac, and constrain it to
be compatible with Synopsys dwmac 4.20a.
Signed-off-by: Jagan Teki <[email protected]>
Signed-off-by: Anand Moon <[email protected]>
---
Documentation/devicetree/bindings/net/rockchip-dwmac.yaml | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/net/rockchip-dwmac.yaml b/Documentation/devicetree/bindings/net/rockchip-dwmac.yaml
index 083623c8d718..346e248a6ba5 100644
--- a/Documentation/devicetree/bindings/net/rockchip-dwmac.yaml
+++ b/Documentation/devicetree/bindings/net/rockchip-dwmac.yaml
@@ -26,6 +26,7 @@ select:
- rockchip,rk3399-gmac
- rockchip,rk3568-gmac
- rockchip,rv1108-gmac
+ - rockchip,rv1126-gmac
required:
- compatible
--
2.37.2
Rockchip RV1126 has GMAC 10/100/1000M ethernet controller
via RGMII and RMII interfaces are configured via M0 and M1 pinmux.
This patch adds rv1126 support by adding delay lines of M0 and M1
simultaneously.
Signed-off-by: Sugar Zhang <[email protected]>
Signed-off-by: David Wu <[email protected]>
Signed-off-by: Anand Moon <[email protected]>
Signed-off-by: Jagan Teki <[email protected]>
---
.../net/ethernet/stmicro/stmmac/dwmac-rk.c | 125 ++++++++++++++++++
1 file changed, 125 insertions(+)
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-rk.c b/drivers/net/ethernet/stmicro/stmmac/dwmac-rk.c
index c469abc91fa1..93be3efb5fff 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac-rk.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-rk.c
@@ -1153,6 +1153,130 @@ static const struct rk_gmac_ops rv1108_ops = {
.set_rmii_speed = rv1108_set_rmii_speed,
};
+#define RV1126_GRF_GMAC_CON0 0X0070
+#define RV1126_GRF_GMAC_CON1 0X0074
+#define RV1126_GRF_GMAC_CON2 0X0078
+
+/* RV1126_GRF_GMAC_CON0 */
+#define RV1126_GMAC_PHY_INTF_SEL_RGMII \
+ (GRF_BIT(4) | GRF_CLR_BIT(5) | GRF_CLR_BIT(6))
+#define RV1126_GMAC_PHY_INTF_SEL_RMII \
+ (GRF_CLR_BIT(4) | GRF_CLR_BIT(5) | GRF_BIT(6))
+#define RV1126_GMAC_FLOW_CTRL GRF_BIT(7)
+#define RV1126_GMAC_FLOW_CTRL_CLR GRF_CLR_BIT(7)
+#define RV1126_GMAC_M0_RXCLK_DLY_ENABLE GRF_BIT(1)
+#define RV1126_GMAC_M0_RXCLK_DLY_DISABLE GRF_CLR_BIT(1)
+#define RV1126_GMAC_M0_TXCLK_DLY_ENABLE GRF_BIT(0)
+#define RV1126_GMAC_M0_TXCLK_DLY_DISABLE GRF_CLR_BIT(0)
+#define RV1126_GMAC_M1_RXCLK_DLY_ENABLE GRF_BIT(3)
+#define RV1126_GMAC_M1_RXCLK_DLY_DISABLE GRF_CLR_BIT(3)
+#define RV1126_GMAC_M1_TXCLK_DLY_ENABLE GRF_BIT(2)
+#define RV1126_GMAC_M1_TXCLK_DLY_DISABLE GRF_CLR_BIT(2)
+
+/* RV1126_GRF_GMAC_CON1 */
+#define RV1126_GMAC_M0_CLK_RX_DL_CFG(val) HIWORD_UPDATE(val, 0x7F, 8)
+#define RV1126_GMAC_M0_CLK_TX_DL_CFG(val) HIWORD_UPDATE(val, 0x7F, 0)
+/* RV1126_GRF_GMAC_CON2 */
+#define RV1126_GMAC_M1_CLK_RX_DL_CFG(val) HIWORD_UPDATE(val, 0x7F, 8)
+#define RV1126_GMAC_M1_CLK_TX_DL_CFG(val) HIWORD_UPDATE(val, 0x7F, 0)
+
+static void rv1126_set_to_rgmii(struct rk_priv_data *bsp_priv,
+ int tx_delay, int rx_delay)
+{
+ struct device *dev = &bsp_priv->pdev->dev;
+
+ if (IS_ERR(bsp_priv->grf)) {
+ dev_err(dev, "Missing rockchip,grf property\n");
+ return;
+ }
+
+ regmap_write(bsp_priv->grf, RV1126_GRF_GMAC_CON0,
+ RV1126_GMAC_PHY_INTF_SEL_RGMII |
+ RV1126_GMAC_M0_RXCLK_DLY_ENABLE |
+ RV1126_GMAC_M0_TXCLK_DLY_ENABLE |
+ RV1126_GMAC_M1_RXCLK_DLY_ENABLE |
+ RV1126_GMAC_M1_TXCLK_DLY_ENABLE);
+
+ regmap_write(bsp_priv->grf, RV1126_GRF_GMAC_CON1,
+ RV1126_GMAC_M0_CLK_RX_DL_CFG(rx_delay) |
+ RV1126_GMAC_M0_CLK_TX_DL_CFG(tx_delay));
+
+ regmap_write(bsp_priv->grf, RV1126_GRF_GMAC_CON2,
+ RV1126_GMAC_M1_CLK_RX_DL_CFG(rx_delay) |
+ RV1126_GMAC_M1_CLK_TX_DL_CFG(tx_delay));
+}
+
+static void rv1126_set_to_rmii(struct rk_priv_data *bsp_priv)
+{
+ struct device *dev = &bsp_priv->pdev->dev;
+
+ if (IS_ERR(bsp_priv->grf)) {
+ dev_err(dev, "%s: Missing rockchip,grf property\n", __func__);
+ return;
+ }
+
+ regmap_write(bsp_priv->grf, RV1126_GRF_GMAC_CON0,
+ RV1126_GMAC_PHY_INTF_SEL_RMII);
+}
+
+static void rv1126_set_rgmii_speed(struct rk_priv_data *bsp_priv, int speed)
+{
+ struct device *dev = &bsp_priv->pdev->dev;
+ unsigned long rate;
+ int ret;
+
+ switch (speed) {
+ case 10:
+ rate = 2500000;
+ break;
+ case 100:
+ rate = 25000000;
+ break;
+ case 1000:
+ rate = 125000000;
+ break;
+ default:
+ dev_err(dev, "unknown speed value for RGMII speed=%d", speed);
+ return;
+ }
+
+ ret = clk_set_rate(bsp_priv->clk_mac_speed, rate);
+ if (ret)
+ dev_err(dev, "%s: set clk_mac_speed rate %ld failed %d\n",
+ __func__, rate, ret);
+}
+
+static void rv1126_set_rmii_speed(struct rk_priv_data *bsp_priv, int speed)
+{
+ struct device *dev = &bsp_priv->pdev->dev;
+ unsigned long rate;
+ int ret;
+
+ switch (speed) {
+ case 10:
+ rate = 2500000;
+ break;
+ case 100:
+ rate = 25000000;
+ break;
+ default:
+ dev_err(dev, "unknown speed value for RGMII speed=%d", speed);
+ return;
+ }
+
+ ret = clk_set_rate(bsp_priv->clk_mac_speed, rate);
+ if (ret)
+ dev_err(dev, "%s: set clk_mac_speed rate %ld failed %d\n",
+ __func__, rate, ret);
+}
+
+static const struct rk_gmac_ops rv1126_ops = {
+ .set_to_rgmii = rv1126_set_to_rgmii,
+ .set_to_rmii = rv1126_set_to_rmii,
+ .set_rgmii_speed = rv1126_set_rgmii_speed,
+ .set_rmii_speed = rv1126_set_rmii_speed,
+};
+
#define RK_GRF_MACPHY_CON0 0xb00
#define RK_GRF_MACPHY_CON1 0xb04
#define RK_GRF_MACPHY_CON2 0xb08
@@ -1681,6 +1805,7 @@ static const struct of_device_id rk_gmac_dwmac_match[] = {
{ .compatible = "rockchip,rk3399-gmac", .data = &rk3399_ops },
{ .compatible = "rockchip,rk3568-gmac", .data = &rk3568_ops },
{ .compatible = "rockchip,rv1108-gmac", .data = &rv1108_ops },
+ { .compatible = "rockchip,rv1126-gmac", .data = &rv1126_ops },
{ }
};
MODULE_DEVICE_TABLE(of, rk_gmac_dwmac_match);
--
2.37.2
Am Montag, 29. August 2022, 08:50:41 CEST schrieb Anand Moon:
> Add compatible string for RV1126 gmac, and constrain it to
> be compatible with Synopsys dwmac 4.20a.
>
> Signed-off-by: Jagan Teki <[email protected]>
> Signed-off-by: Anand Moon <[email protected]>
> ---
> Documentation/devicetree/bindings/net/rockchip-dwmac.yaml | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/Documentation/devicetree/bindings/net/rockchip-dwmac.yaml b/Documentation/devicetree/bindings/net/rockchip-dwmac.yaml
> index 083623c8d718..346e248a6ba5 100644
> --- a/Documentation/devicetree/bindings/net/rockchip-dwmac.yaml
> +++ b/Documentation/devicetree/bindings/net/rockchip-dwmac.yaml
> @@ -26,6 +26,7 @@ select:
> - rockchip,rk3399-gmac
> - rockchip,rk3568-gmac
> - rockchip,rv1108-gmac
> + - rockchip,rv1126-gmac
> required:
> - compatible
Reviewed-by: Heiko Stuebner <[email protected]>
On Mon, Aug 29, 2022 at 06:50:42AM +0000, Anand Moon wrote:
> Rockchip RV1126 has GMAC 10/100/1000M ethernet controller
> via RGMII and RMII interfaces are configured via M0 and M1 pinmux.
>
> This patch adds rv1126 support by adding delay lines of M0 and M1
> simultaneously.
What does 'delay lines' mean with respect to RGMII?
The RGMII signals need a 2ns delay between the clock and the data
lines. There are three places this can happen:
1) In the PHY
2) Extra long lines on the PCB
3) In the MAC
Generally, 1) is used, and controlled via phy-mode. A value of
PHY_INTERFACE_MODE_RGMII_ID passed to the PHY driver means it will add
these delays.
You don't want both the MAC and the PHY adding delays.
Andrew
On 29/08/2022 09:50, Anand Moon wrote:
> Add compatible string for RV1126 gmac, and constrain it to
> be compatible with Synopsys dwmac 4.20a.
>
> Signed-off-by: Jagan Teki <[email protected]>
> Signed-off-by: Anand Moon <[email protected]>
> ---
> Documentation/devicetree/bindings/net/rockchip-dwmac.yaml | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/Documentation/devicetree/bindings/net/rockchip-dwmac.yaml b/Documentation/devicetree/bindings/net/rockchip-dwmac.yaml
> index 083623c8d718..346e248a6ba5 100644
> --- a/Documentation/devicetree/bindings/net/rockchip-dwmac.yaml
> +++ b/Documentation/devicetree/bindings/net/rockchip-dwmac.yaml
> @@ -26,6 +26,7 @@ select:
> - rockchip,rk3399-gmac
> - rockchip,rk3568-gmac
> - rockchip,rv1108-gmac
> + - rockchip,rv1126-gmac
That's not a complete change. What about the other place listing
compatibles? Did you test the bindings on your DTS?
Best regards,
Krzysztof
On Mon, 29 Aug 2022 at 12:23, Anand Moon <[email protected]> wrote:
>
> Add compatible string for RV1126 gmac, and constrain it to
> be compatible with Synopsys dwmac 4.20a.
>
> Signed-off-by: Jagan Teki <[email protected]>
> Signed-off-by: Anand Moon <[email protected]>
> ---
> Documentation/devicetree/bindings/net/rockchip-dwmac.yaml | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/Documentation/devicetree/bindings/net/rockchip-dwmac.yaml b/Documentation/devicetree/bindings/net/rockchip-dwmac.yaml
> index 083623c8d718..346e248a6ba5 100644
> --- a/Documentation/devicetree/bindings/net/rockchip-dwmac.yaml
> +++ b/Documentation/devicetree/bindings/net/rockchip-dwmac.yaml
> @@ -26,6 +26,7 @@ select:
> - rockchip,rk3399-gmac
> - rockchip,rk3568-gmac
> - rockchip,rv1108-gmac
> + - rockchip,rv1126-gmac
it needs to be in the properties menu as well.
Hi Andrew,
On Mon, 29 Aug 2022 at 18:40, Andrew Lunn <[email protected]> wrote:
>
> On Mon, Aug 29, 2022 at 06:50:42AM +0000, Anand Moon wrote:
> > Rockchip RV1126 has GMAC 10/100/1000M ethernet controller
> > via RGMII and RMII interfaces are configured via M0 and M1 pinmux.
> >
> > This patch adds rv1126 support by adding delay lines of M0 and M1
> > simultaneously.
>
> What does 'delay lines' mean with respect to RGMII?
>
> The RGMII signals need a 2ns delay between the clock and the data
> lines. There are three places this can happen:
>
> 1) In the PHY
> 2) Extra long lines on the PCB
> 3) In the MAC
>
> Generally, 1) is used, and controlled via phy-mode. A value of
> PHY_INTERFACE_MODE_RGMII_ID passed to the PHY driver means it will add
> these delays.
>
> You don't want both the MAC and the PHY adding delays.
>
These are set to enable MAC transmit clock delay set for Tx and Rx for
iomux group.
>
> Andrew
Thanks
-Anand
Hi Krzysztof,
On Tue, 30 Aug 2022 at 15:21, Krzysztof Kozlowski
<[email protected]> wrote:
>
> On 29/08/2022 09:50, Anand Moon wrote:
> > Add compatible string for RV1126 gmac, and constrain it to
> > be compatible with Synopsys dwmac 4.20a.
> >
> > Signed-off-by: Jagan Teki <[email protected]>
> > Signed-off-by: Anand Moon <[email protected]>
> > ---
> > Documentation/devicetree/bindings/net/rockchip-dwmac.yaml | 1 +
> > 1 file changed, 1 insertion(+)
> >
> > diff --git a/Documentation/devicetree/bindings/net/rockchip-dwmac.yaml b/Documentation/devicetree/bindings/net/rockchip-dwmac.yaml
> > index 083623c8d718..346e248a6ba5 100644
> > --- a/Documentation/devicetree/bindings/net/rockchip-dwmac.yaml
> > +++ b/Documentation/devicetree/bindings/net/rockchip-dwmac.yaml
> > @@ -26,6 +26,7 @@ select:
> > - rockchip,rk3399-gmac
> > - rockchip,rk3568-gmac
> > - rockchip,rv1108-gmac
> > + - rockchip,rv1126-gmac
>
> That's not a complete change. What about the other place listing
> compatibles? Did you test the bindings on your DTS?
>
Yes, I missed the properties menu, will update it in the next version.
>
> Best regards,
> Krzysztof
Thanks
-Anand
On Mon, 29 Aug 2022 at 18:40, Andrew Lunn <[email protected]> wrote:
>
> On Mon, Aug 29, 2022 at 06:50:42AM +0000, Anand Moon wrote:
> > Rockchip RV1126 has GMAC 10/100/1000M ethernet controller
> > via RGMII and RMII interfaces are configured via M0 and M1 pinmux.
> >
> > This patch adds rv1126 support by adding delay lines of M0 and M1
> > simultaneously.
>
> What does 'delay lines' mean with respect to RGMII?
These are MAC receive clock delay lengths.
>
> The RGMII signals need a 2ns delay between the clock and the data
> lines. There are three places this can happen:
>
> 1) In the PHY
> 2) Extra long lines on the PCB
> 3) In the MAC
>
> Generally, 1) is used, and controlled via phy-mode. A value of
> PHY_INTERFACE_MODE_RGMII_ID passed to the PHY driver means it will add
> these delays.
>
> You don't want both the MAC and the PHY adding delays.
Yes, but these are specific to MAC, not related to PHY delays. Similar
to what is there in other Rockchip SoC families like RK3366, 3368,
3399, 3128, but these MAC clock delay lengths are grouped based on the
iomux group in RV1126. We have iomux group 0 (M0) and group 1 (M1), so
the rgmii has to set these lengths irrespective of whether PHY add's
or not.
Thanks,
Jagan.
On Thu, Sep 01, 2022 at 12:56:09PM +0530, Jagan Teki wrote:
> On Mon, 29 Aug 2022 at 18:40, Andrew Lunn <[email protected]> wrote:
> >
> > On Mon, Aug 29, 2022 at 06:50:42AM +0000, Anand Moon wrote:
> > > Rockchip RV1126 has GMAC 10/100/1000M ethernet controller
> > > via RGMII and RMII interfaces are configured via M0 and M1 pinmux.
> > >
> > > This patch adds rv1126 support by adding delay lines of M0 and M1
> > > simultaneously.
> >
> > What does 'delay lines' mean with respect to RGMII?
>
> These are MAC receive clock delay lengths.
>
> >
> > The RGMII signals need a 2ns delay between the clock and the data
> > lines. There are three places this can happen:
> >
> > 1) In the PHY
> > 2) Extra long lines on the PCB
> > 3) In the MAC
> >
> > Generally, 1) is used, and controlled via phy-mode. A value of
> > PHY_INTERFACE_MODE_RGMII_ID passed to the PHY driver means it will add
> > these delays.
> >
> > You don't want both the MAC and the PHY adding delays.
>
> Yes, but these are specific to MAC, not related to PHY delays. Similar
> to what is there in other Rockchip SoC families like RK3366, 3368,
> 3399, 3128, but these MAC clock delay lengths are grouped based on the
> iomux group in RV1126. We have iomux group 0 (M0) and group 1 (M1), so
> the rgmii has to set these lengths irrespective of whether PHY add's
> or not.
So this is just fine tuning, in the order of pico seconds?
If that is all it is, then this is fine. It becomes a problem when it
is 2ns.
Andrew
> > On Mon, Aug 29, 2022 at 06:50:42AM +0000, Anand Moon wrote:
> > > Rockchip RV1126 has GMAC 10/100/1000M ethernet controller
> > > via RGMII and RMII interfaces are configured via M0 and M1 pinmux.
> > >
> > > This patch adds rv1126 support by adding delay lines of M0 and M1
> > > simultaneously.
> >
> > What does 'delay lines' mean with respect to RGMII?
> >
> > The RGMII signals need a 2ns delay between the clock and the data
> > lines. There are three places this can happen:
> >
> > 1) In the PHY
> > 2) Extra long lines on the PCB
> > 3) In the MAC
> >
> > Generally, 1) is used, and controlled via phy-mode. A value of
> > PHY_INTERFACE_MODE_RGMII_ID passed to the PHY driver means it will add
> > these delays.
> >
> > You don't want both the MAC and the PHY adding delays.
> >
> These are set to enable MAC transmit clock delay set for Tx and Rx for
> iomux group.
Which does not answer my question. Is this the same as, or different
to, the 2ns delay required by RGMII?
Andrew
On Thu, 1 Sept 2022 at 17:42, Andrew Lunn <[email protected]> wrote:
>
> On Thu, Sep 01, 2022 at 12:56:09PM +0530, Jagan Teki wrote:
> > On Mon, 29 Aug 2022 at 18:40, Andrew Lunn <[email protected]> wrote:
> > >
> > > On Mon, Aug 29, 2022 at 06:50:42AM +0000, Anand Moon wrote:
> > > > Rockchip RV1126 has GMAC 10/100/1000M ethernet controller
> > > > via RGMII and RMII interfaces are configured via M0 and M1 pinmux.
> > > >
> > > > This patch adds rv1126 support by adding delay lines of M0 and M1
> > > > simultaneously.
> > >
> > > What does 'delay lines' mean with respect to RGMII?
> >
> > These are MAC receive clock delay lengths.
> >
> > >
> > > The RGMII signals need a 2ns delay between the clock and the data
> > > lines. There are three places this can happen:
> > >
> > > 1) In the PHY
> > > 2) Extra long lines on the PCB
> > > 3) In the MAC
> > >
> > > Generally, 1) is used, and controlled via phy-mode. A value of
> > > PHY_INTERFACE_MODE_RGMII_ID passed to the PHY driver means it will add
> > > these delays.
> > >
> > > You don't want both the MAC and the PHY adding delays.
> >
> > Yes, but these are specific to MAC, not related to PHY delays. Similar
> > to what is there in other Rockchip SoC families like RK3366, 3368,
> > 3399, 3128, but these MAC clock delay lengths are grouped based on the
> > iomux group in RV1126. We have iomux group 0 (M0) and group 1 (M1), so
> > the rgmii has to set these lengths irrespective of whether PHY add's
> > or not.
>
> So this is just fine tuning, in the order of pico seconds?
>
> If that is all it is, then this is fine. It becomes a problem when it
> is 2ns.
Yes, it is fine I think. We have tested the delay mentioned as per the
documentation.
tx_delay: Range value is 0~0x7F
rx_delay: Range value is 0~0x7F
Thanks,
Jagan.