Linux-mediatek Archive on lore.kernel.org
 help / color / Atom feed
* [PATCH RFC net-next] net: mtk_eth_soc: use resolved link config for PCS PHY
@ 2020-06-30 10:15 Russell King
  2020-06-30 10:46 ` Russell King - ARM Linux admin
  0 siblings, 1 reply; 4+ messages in thread
From: Russell King @ 2020-06-30 10:15 UTC (permalink / raw)
  To: Andrew Lunn, Florian Fainelli, Heiner Kallweit, René van Dorst
  Cc: netdev, Sean Wang, David S. Miller, linux-mediatek, John Crispin,
	Matthias Brugger, Jakub Kicinski, Mark Lee, linux-arm-kernel,
	Felix Fietkau

The SGMII PCS PHY needs to be updated with the link configuration in
the mac_link_up() call rather than in mac_config().  However,
mtk_sgmii_setup_mode_force() programs the SGMII block during
mac_config() when using 802.3z interface modes with the link
configuration.

Split that functionality from mtk_sgmii_setup_mode_force(), moving it
to a new mtk_sgmii_link_up() function, and call it from mac_link_up().

This does not look correct to me: 802.3z modes operate at a fixed
speed.  The contents of mtk_sgmii_link_up() look more appropriate for
SGMII mode, but the original code definitely did not call
mtk_sgmii_setup_mode_force() for SGMII mode but only 802.3z mode.

Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
---
René, can you assist with this patch please - I really think there are
problems with the existing code.  You call mtk_sgmii_setup_mode_force()
in a block which is conditionalised as:

	if (state->interface == PHY_INTERFACE_MODE_SGMII ||
	    phy_interface_mode_is_8023z(state->interface)) {
...
		if (state->interface != PHY_INTERFACE_MODE_SGMII)
			err = mtk_sgmii_setup_mode_force(eth->sgmii, sid,
							 state);

Hence, mtk_sgmii_setup_mode_force() is only called for 1000BASE-X and
2500BASE-X, which do not support anything but their native speeds.
Yet, mtk_sgmii_setup_mode_force() tries to program the SGMII for 10M
and 100M.

Note that this patch is more about moving uses of state->{speed,duplex}
into mac_link_up(), rather than fixing this problem, but I don't think
the addition in mtk_mac_link_up(), nor mtk_sgmii_link_up() is of any
use.

Thanks.

 drivers/net/ethernet/mediatek/mtk_eth_soc.c |  9 ++++-
 drivers/net/ethernet/mediatek/mtk_eth_soc.h |  3 +-
 drivers/net/ethernet/mediatek/mtk_sgmii.c   | 37 +++++++++++++++------
 3 files changed, 36 insertions(+), 13 deletions(-)

diff --git a/drivers/net/ethernet/mediatek/mtk_eth_soc.c b/drivers/net/ethernet/mediatek/mtk_eth_soc.c
index 20db302d31ce..ef9ec3b6a5c8 100644
--- a/drivers/net/ethernet/mediatek/mtk_eth_soc.c
+++ b/drivers/net/ethernet/mediatek/mtk_eth_soc.c
@@ -326,7 +326,7 @@ static void mtk_mac_config(struct phylink_config *config, unsigned int mode,
 		/* Setup SGMIISYS with the determined property */
 		if (state->interface != PHY_INTERFACE_MODE_SGMII)
 			err = mtk_sgmii_setup_mode_force(eth->sgmii, sid,
-							 state);
+							 state->interface);
 		else if (phylink_autoneg_inband(mode))
 			err = mtk_sgmii_setup_mode_an(eth->sgmii, sid);
 
@@ -423,6 +423,13 @@ static void mtk_mac_link_up(struct phylink_config *config,
 					   phylink_config);
 	u32 mcr = mtk_r32(mac->hw, MTK_MAC_MCR(mac->id));
 
+	if (phy_interface_mode_is_8023z(interface)) {
+		/* Decide how GMAC and SGMIISYS be mapped */
+		int sid = (MTK_HAS_CAPS(eth->soc->caps, MTK_SHARED_SGMII)) ?
+			   0 : mac->id;
+		mtk_sgmii_link_up(eth->sgmii, sid, speed, duplex);
+	}
+
 	mcr &= ~(MAC_MCR_SPEED_100 | MAC_MCR_SPEED_1000 |
 		 MAC_MCR_FORCE_DPX | MAC_MCR_FORCE_TX_FC |
 		 MAC_MCR_FORCE_RX_FC);
diff --git a/drivers/net/ethernet/mediatek/mtk_eth_soc.h b/drivers/net/ethernet/mediatek/mtk_eth_soc.h
index 454cfcd465fd..6f4b99bb7bfb 100644
--- a/drivers/net/ethernet/mediatek/mtk_eth_soc.h
+++ b/drivers/net/ethernet/mediatek/mtk_eth_soc.h
@@ -932,7 +932,8 @@ int mtk_sgmii_init(struct mtk_sgmii *ss, struct device_node *np,
 		   u32 ana_rgc3);
 int mtk_sgmii_setup_mode_an(struct mtk_sgmii *ss, int id);
 int mtk_sgmii_setup_mode_force(struct mtk_sgmii *ss, int id,
-			       const struct phylink_link_state *state);
+			       phy_interface_t interface);
+void mtk_sgmii_link_up(struct mtk_sgmii *ss, int id, int speed, int duplex);
 void mtk_sgmii_restart_an(struct mtk_eth *eth, int mac_id);
 
 int mtk_gmac_sgmii_path_setup(struct mtk_eth *eth, int mac_id);
diff --git a/drivers/net/ethernet/mediatek/mtk_sgmii.c b/drivers/net/ethernet/mediatek/mtk_sgmii.c
index 32d83421226a..372c85c830b5 100644
--- a/drivers/net/ethernet/mediatek/mtk_sgmii.c
+++ b/drivers/net/ethernet/mediatek/mtk_sgmii.c
@@ -60,7 +60,7 @@ int mtk_sgmii_setup_mode_an(struct mtk_sgmii *ss, int id)
 }
 
 int mtk_sgmii_setup_mode_force(struct mtk_sgmii *ss, int id,
-			       const struct phylink_link_state *state)
+			       phy_interface_t interface)
 {
 	unsigned int val;
 
@@ -69,7 +69,7 @@ int mtk_sgmii_setup_mode_force(struct mtk_sgmii *ss, int id,
 
 	regmap_read(ss->regmap[id], ss->ana_rgc3, &val);
 	val &= ~RG_PHY_SPEED_MASK;
-	if (state->interface == PHY_INTERFACE_MODE_2500BASEX)
+	if (interface == PHY_INTERFACE_MODE_2500BASEX)
 		val |= RG_PHY_SPEED_3_125G;
 	regmap_write(ss->regmap[id], ss->ana_rgc3, val);
 
@@ -78,11 +78,33 @@ int mtk_sgmii_setup_mode_force(struct mtk_sgmii *ss, int id,
 	val &= ~SGMII_AN_ENABLE;
 	regmap_write(ss->regmap[id], SGMSYS_PCS_CONTROL_1, val);
 
+	if (interface == PHY_INTERFACE_MODE_1000BASEX ||
+	    interface == PHY_INTERFACE_MODE_2500BASEX) {
+		/* SGMII force mode setting */
+		regmap_read(ss->regmap[id], SGMSYS_SGMII_MODE, &val);
+		val &= ~SGMII_IF_MODE_MASK;
+		val |= SGMII_SPEED_1000;
+		val |= SGMII_DUPLEX_FULL;
+		regmap_write(ss->regmap[id], SGMSYS_SGMII_MODE, val);
+	}
+
+	/* Release PHYA power down state */
+	regmap_read(ss->regmap[id], SGMSYS_QPHY_PWR_STATE_CTRL, &val);
+	val &= ~SGMII_PHYA_PWD;
+	regmap_write(ss->regmap[id], SGMSYS_QPHY_PWR_STATE_CTRL, val);
+
+	return 0;
+}
+
+void mtk_sgmii_link_up(struct mtk_sgmii *ss, int id, int speed, int duplex)
+{
+	unsigned int val;
+
 	/* SGMII force mode setting */
 	regmap_read(ss->regmap[id], SGMSYS_SGMII_MODE, &val);
 	val &= ~SGMII_IF_MODE_MASK;
 
-	switch (state->speed) {
+	switch (speed) {
 	case SPEED_10:
 		val |= SGMII_SPEED_10;
 		break;
@@ -95,17 +117,10 @@ int mtk_sgmii_setup_mode_force(struct mtk_sgmii *ss, int id,
 		break;
 	}
 
-	if (state->duplex == DUPLEX_FULL)
+	if (duplex == DUPLEX_FULL)
 		val |= SGMII_DUPLEX_FULL;
 
 	regmap_write(ss->regmap[id], SGMSYS_SGMII_MODE, val);
-
-	/* Release PHYA power down state */
-	regmap_read(ss->regmap[id], SGMSYS_QPHY_PWR_STATE_CTRL, &val);
-	val &= ~SGMII_PHYA_PWD;
-	regmap_write(ss->regmap[id], SGMSYS_QPHY_PWR_STATE_CTRL, val);
-
-	return 0;
 }
 
 void mtk_sgmii_restart_an(struct mtk_eth *eth, int mac_id)
-- 
2.20.1


_______________________________________________
Linux-mediatek mailing list
Linux-mediatek@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-mediatek

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [PATCH RFC net-next] net: mtk_eth_soc: use resolved link config for PCS PHY
  2020-06-30 10:15 [PATCH RFC net-next] net: mtk_eth_soc: use resolved link config for PCS PHY Russell King
@ 2020-06-30 10:46 ` Russell King - ARM Linux admin
  2020-06-30 22:13   ` René van Dorst
  0 siblings, 1 reply; 4+ messages in thread
From: Russell King - ARM Linux admin @ 2020-06-30 10:46 UTC (permalink / raw)
  To: Andrew Lunn, Florian Fainelli, Heiner Kallweit, René van Dorst
  Cc: netdev, Sean Wang, David S. Miller, linux-mediatek, John Crispin,
	Matthias Brugger, Jakub Kicinski, Mark Lee, linux-arm-kernel,
	Felix Fietkau

On Tue, Jun 30, 2020 at 11:15:42AM +0100, Russell King wrote:
> The SGMII PCS PHY needs to be updated with the link configuration in
> the mac_link_up() call rather than in mac_config().  However,
> mtk_sgmii_setup_mode_force() programs the SGMII block during
> mac_config() when using 802.3z interface modes with the link
> configuration.
> 
> Split that functionality from mtk_sgmii_setup_mode_force(), moving it
> to a new mtk_sgmii_link_up() function, and call it from mac_link_up().
> 
> This does not look correct to me: 802.3z modes operate at a fixed
> speed.  The contents of mtk_sgmii_link_up() look more appropriate for
> SGMII mode, but the original code definitely did not call
> mtk_sgmii_setup_mode_force() for SGMII mode but only 802.3z mode.
> 
> Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
> ---
> René, can you assist with this patch please - I really think there are
> problems with the existing code.  You call mtk_sgmii_setup_mode_force()
> in a block which is conditionalised as:
> 
> 	if (state->interface == PHY_INTERFACE_MODE_SGMII ||
> 	    phy_interface_mode_is_8023z(state->interface)) {
> ...
> 		if (state->interface != PHY_INTERFACE_MODE_SGMII)
> 			err = mtk_sgmii_setup_mode_force(eth->sgmii, sid,
> 							 state);
> 
> Hence, mtk_sgmii_setup_mode_force() is only called for 1000BASE-X and
> 2500BASE-X, which do not support anything but their native speeds.
> Yet, mtk_sgmii_setup_mode_force() tries to program the SGMII for 10M
> and 100M.
> 
> Note that this patch is more about moving uses of state->{speed,duplex}
> into mac_link_up(), rather than fixing this problem, but I don't think
> the addition in mtk_mac_link_up(), nor mtk_sgmii_link_up() is of any
> use.

My Coccinelle script just found this use of state->{speed,duplex} still
remaining:

                        if (MTK_HAS_CAPS(mac->hw->soc->caps,
                                         MTK_TRGMII_MT7621_CLK)) {
...
                        } else {
                                if (state->interface !=
                                    PHY_INTERFACE_MODE_TRGMII)
                                        mtk_gmac0_rgmii_adjust(mac->hw,
                                                               state->speed);

which also needs to be eliminated.  Can that also be moved to
mtk_mac_link_up()?

Thanks.

> 
> Thanks.
> 
>  drivers/net/ethernet/mediatek/mtk_eth_soc.c |  9 ++++-
>  drivers/net/ethernet/mediatek/mtk_eth_soc.h |  3 +-
>  drivers/net/ethernet/mediatek/mtk_sgmii.c   | 37 +++++++++++++++------
>  3 files changed, 36 insertions(+), 13 deletions(-)
> 
> diff --git a/drivers/net/ethernet/mediatek/mtk_eth_soc.c b/drivers/net/ethernet/mediatek/mtk_eth_soc.c
> index 20db302d31ce..ef9ec3b6a5c8 100644
> --- a/drivers/net/ethernet/mediatek/mtk_eth_soc.c
> +++ b/drivers/net/ethernet/mediatek/mtk_eth_soc.c
> @@ -326,7 +326,7 @@ static void mtk_mac_config(struct phylink_config *config, unsigned int mode,
>  		/* Setup SGMIISYS with the determined property */
>  		if (state->interface != PHY_INTERFACE_MODE_SGMII)
>  			err = mtk_sgmii_setup_mode_force(eth->sgmii, sid,
> -							 state);
> +							 state->interface);
>  		else if (phylink_autoneg_inband(mode))
>  			err = mtk_sgmii_setup_mode_an(eth->sgmii, sid);
>  
> @@ -423,6 +423,13 @@ static void mtk_mac_link_up(struct phylink_config *config,
>  					   phylink_config);
>  	u32 mcr = mtk_r32(mac->hw, MTK_MAC_MCR(mac->id));
>  
> +	if (phy_interface_mode_is_8023z(interface)) {
> +		/* Decide how GMAC and SGMIISYS be mapped */
> +		int sid = (MTK_HAS_CAPS(eth->soc->caps, MTK_SHARED_SGMII)) ?
> +			   0 : mac->id;
> +		mtk_sgmii_link_up(eth->sgmii, sid, speed, duplex);
> +	}
> +
>  	mcr &= ~(MAC_MCR_SPEED_100 | MAC_MCR_SPEED_1000 |
>  		 MAC_MCR_FORCE_DPX | MAC_MCR_FORCE_TX_FC |
>  		 MAC_MCR_FORCE_RX_FC);
> diff --git a/drivers/net/ethernet/mediatek/mtk_eth_soc.h b/drivers/net/ethernet/mediatek/mtk_eth_soc.h
> index 454cfcd465fd..6f4b99bb7bfb 100644
> --- a/drivers/net/ethernet/mediatek/mtk_eth_soc.h
> +++ b/drivers/net/ethernet/mediatek/mtk_eth_soc.h
> @@ -932,7 +932,8 @@ int mtk_sgmii_init(struct mtk_sgmii *ss, struct device_node *np,
>  		   u32 ana_rgc3);
>  int mtk_sgmii_setup_mode_an(struct mtk_sgmii *ss, int id);
>  int mtk_sgmii_setup_mode_force(struct mtk_sgmii *ss, int id,
> -			       const struct phylink_link_state *state);
> +			       phy_interface_t interface);
> +void mtk_sgmii_link_up(struct mtk_sgmii *ss, int id, int speed, int duplex);
>  void mtk_sgmii_restart_an(struct mtk_eth *eth, int mac_id);
>  
>  int mtk_gmac_sgmii_path_setup(struct mtk_eth *eth, int mac_id);
> diff --git a/drivers/net/ethernet/mediatek/mtk_sgmii.c b/drivers/net/ethernet/mediatek/mtk_sgmii.c
> index 32d83421226a..372c85c830b5 100644
> --- a/drivers/net/ethernet/mediatek/mtk_sgmii.c
> +++ b/drivers/net/ethernet/mediatek/mtk_sgmii.c
> @@ -60,7 +60,7 @@ int mtk_sgmii_setup_mode_an(struct mtk_sgmii *ss, int id)
>  }
>  
>  int mtk_sgmii_setup_mode_force(struct mtk_sgmii *ss, int id,
> -			       const struct phylink_link_state *state)
> +			       phy_interface_t interface)
>  {
>  	unsigned int val;
>  
> @@ -69,7 +69,7 @@ int mtk_sgmii_setup_mode_force(struct mtk_sgmii *ss, int id,
>  
>  	regmap_read(ss->regmap[id], ss->ana_rgc3, &val);
>  	val &= ~RG_PHY_SPEED_MASK;
> -	if (state->interface == PHY_INTERFACE_MODE_2500BASEX)
> +	if (interface == PHY_INTERFACE_MODE_2500BASEX)
>  		val |= RG_PHY_SPEED_3_125G;
>  	regmap_write(ss->regmap[id], ss->ana_rgc3, val);
>  
> @@ -78,11 +78,33 @@ int mtk_sgmii_setup_mode_force(struct mtk_sgmii *ss, int id,
>  	val &= ~SGMII_AN_ENABLE;
>  	regmap_write(ss->regmap[id], SGMSYS_PCS_CONTROL_1, val);
>  
> +	if (interface == PHY_INTERFACE_MODE_1000BASEX ||
> +	    interface == PHY_INTERFACE_MODE_2500BASEX) {
> +		/* SGMII force mode setting */
> +		regmap_read(ss->regmap[id], SGMSYS_SGMII_MODE, &val);
> +		val &= ~SGMII_IF_MODE_MASK;
> +		val |= SGMII_SPEED_1000;
> +		val |= SGMII_DUPLEX_FULL;
> +		regmap_write(ss->regmap[id], SGMSYS_SGMII_MODE, val);
> +	}
> +
> +	/* Release PHYA power down state */
> +	regmap_read(ss->regmap[id], SGMSYS_QPHY_PWR_STATE_CTRL, &val);
> +	val &= ~SGMII_PHYA_PWD;
> +	regmap_write(ss->regmap[id], SGMSYS_QPHY_PWR_STATE_CTRL, val);
> +
> +	return 0;
> +}
> +
> +void mtk_sgmii_link_up(struct mtk_sgmii *ss, int id, int speed, int duplex)
> +{
> +	unsigned int val;
> +
>  	/* SGMII force mode setting */
>  	regmap_read(ss->regmap[id], SGMSYS_SGMII_MODE, &val);
>  	val &= ~SGMII_IF_MODE_MASK;
>  
> -	switch (state->speed) {
> +	switch (speed) {
>  	case SPEED_10:
>  		val |= SGMII_SPEED_10;
>  		break;
> @@ -95,17 +117,10 @@ int mtk_sgmii_setup_mode_force(struct mtk_sgmii *ss, int id,
>  		break;
>  	}
>  
> -	if (state->duplex == DUPLEX_FULL)
> +	if (duplex == DUPLEX_FULL)
>  		val |= SGMII_DUPLEX_FULL;
>  
>  	regmap_write(ss->regmap[id], SGMSYS_SGMII_MODE, val);
> -
> -	/* Release PHYA power down state */
> -	regmap_read(ss->regmap[id], SGMSYS_QPHY_PWR_STATE_CTRL, &val);
> -	val &= ~SGMII_PHYA_PWD;
> -	regmap_write(ss->regmap[id], SGMSYS_QPHY_PWR_STATE_CTRL, val);
> -
> -	return 0;
>  }
>  
>  void mtk_sgmii_restart_an(struct mtk_eth *eth, int mac_id)
> -- 
> 2.20.1
> 
> 

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!

_______________________________________________
Linux-mediatek mailing list
Linux-mediatek@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-mediatek

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [PATCH RFC net-next] net: mtk_eth_soc: use resolved link config for PCS PHY
  2020-06-30 10:46 ` Russell King - ARM Linux admin
@ 2020-06-30 22:13   ` René van Dorst
  2020-07-01  0:05     ` Russell King - ARM Linux admin
  0 siblings, 1 reply; 4+ messages in thread
From: René van Dorst @ 2020-06-30 22:13 UTC (permalink / raw)
  To: Russell King - ARM Linux admin, Sean Wang
  Cc: Andrew Lunn, Florian Fainelli, netdev, Mark Lee, linux-mediatek,
	John Crispin, Matthias Brugger, Jakub Kicinski, Heiner Kallweit,
	David S. Miller, linux-arm-kernel, Felix Fietkau

Hi Russel and Sean,

Quoting Russell King - ARM Linux admin <linux@armlinux.org.uk>:

> On Tue, Jun 30, 2020 at 11:15:42AM +0100, Russell King wrote:
>> The SGMII PCS PHY needs to be updated with the link configuration in
>> the mac_link_up() call rather than in mac_config().  However,
>> mtk_sgmii_setup_mode_force() programs the SGMII block during
>> mac_config() when using 802.3z interface modes with the link
>> configuration.
>>
>> Split that functionality from mtk_sgmii_setup_mode_force(), moving it
>> to a new mtk_sgmii_link_up() function, and call it from mac_link_up().
>>
>> This does not look correct to me: 802.3z modes operate at a fixed
>> speed.  The contents of mtk_sgmii_link_up() look more appropriate for
>> SGMII mode, but the original code definitely did not call
>> mtk_sgmii_setup_mode_force() for SGMII mode but only 802.3z mode.
>>
>> Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
>> ---
>> René, can you assist with this patch please - I really think there are
>> problems with the existing code.  You call mtk_sgmii_setup_mode_force()
>> in a block which is conditionalised as:
>>
>> 	if (state->interface == PHY_INTERFACE_MODE_SGMII ||
>> 	    phy_interface_mode_is_8023z(state->interface)) {
>> ...
>> 		if (state->interface != PHY_INTERFACE_MODE_SGMII)
>> 			err = mtk_sgmii_setup_mode_force(eth->sgmii, sid,
>> 							 state);
>>
>> Hence, mtk_sgmii_setup_mode_force() is only called for 1000BASE-X and
>> 2500BASE-X, which do not support anything but their native speeds.
>> Yet, mtk_sgmii_setup_mode_force() tries to program the SGMII for 10M
>> and 100M.
>>
>> Note that this patch is more about moving uses of state->{speed,duplex}
>> into mac_link_up(), rather than fixing this problem, but I don't think
>> the addition in mtk_mac_link_up(), nor mtk_sgmii_link_up() is of any
>> use.
>
> My Coccinelle script just found this use of state->{speed,duplex} still
> remaining:
>
>                         if (MTK_HAS_CAPS(mac->hw->soc->caps,
>                                          MTK_TRGMII_MT7621_CLK)) {
> ...
>                         } else {
>                                 if (state->interface !=
>                                     PHY_INTERFACE_MODE_TRGMII)
>                                         mtk_gmac0_rgmii_adjust(mac->hw,
>                                                                state->speed);
>
> which also needs to be eliminated.  Can that also be moved to
> mtk_mac_link_up()?

I know, you have pointed that out before. But I don't know how to fix
mtk_gmac0_rgmii_adjust(). This function changes the PLL of the MAC.  
But without
documentation I am not sure what all the bits are used for.

Begin April I had a conversation with Sean about this. I also  
explained what the
issue was. AFAIK he was going to take care of this issue.

Sean did you had time to resolve this issue?

Greats,

René

>
> Thanks.
>
>>
>> Thanks.
>>
>>  drivers/net/ethernet/mediatek/mtk_eth_soc.c |  9 ++++-
>>  drivers/net/ethernet/mediatek/mtk_eth_soc.h |  3 +-
>>  drivers/net/ethernet/mediatek/mtk_sgmii.c   | 37 +++++++++++++++------
>>  3 files changed, 36 insertions(+), 13 deletions(-)
>>
>> diff --git a/drivers/net/ethernet/mediatek/mtk_eth_soc.c  
>> b/drivers/net/ethernet/mediatek/mtk_eth_soc.c
>> index 20db302d31ce..ef9ec3b6a5c8 100644
>> --- a/drivers/net/ethernet/mediatek/mtk_eth_soc.c
>> +++ b/drivers/net/ethernet/mediatek/mtk_eth_soc.c
>> @@ -326,7 +326,7 @@ static void mtk_mac_config(struct  
>> phylink_config *config, unsigned int mode,
>>  		/* Setup SGMIISYS with the determined property */
>>  		if (state->interface != PHY_INTERFACE_MODE_SGMII)
>>  			err = mtk_sgmii_setup_mode_force(eth->sgmii, sid,
>> -							 state);
>> +							 state->interface);
>>  		else if (phylink_autoneg_inband(mode))
>>  			err = mtk_sgmii_setup_mode_an(eth->sgmii, sid);
>>
>> @@ -423,6 +423,13 @@ static void mtk_mac_link_up(struct  
>> phylink_config *config,
>>  					   phylink_config);
>>  	u32 mcr = mtk_r32(mac->hw, MTK_MAC_MCR(mac->id));
>>
>> +	if (phy_interface_mode_is_8023z(interface)) {
>> +		/* Decide how GMAC and SGMIISYS be mapped */
>> +		int sid = (MTK_HAS_CAPS(eth->soc->caps, MTK_SHARED_SGMII)) ?
>> +			   0 : mac->id;
>> +		mtk_sgmii_link_up(eth->sgmii, sid, speed, duplex);
>> +	}
>> +
>>  	mcr &= ~(MAC_MCR_SPEED_100 | MAC_MCR_SPEED_1000 |
>>  		 MAC_MCR_FORCE_DPX | MAC_MCR_FORCE_TX_FC |
>>  		 MAC_MCR_FORCE_RX_FC);
>> diff --git a/drivers/net/ethernet/mediatek/mtk_eth_soc.h  
>> b/drivers/net/ethernet/mediatek/mtk_eth_soc.h
>> index 454cfcd465fd..6f4b99bb7bfb 100644
>> --- a/drivers/net/ethernet/mediatek/mtk_eth_soc.h
>> +++ b/drivers/net/ethernet/mediatek/mtk_eth_soc.h
>> @@ -932,7 +932,8 @@ int mtk_sgmii_init(struct mtk_sgmii *ss, struct  
>> device_node *np,
>>  		   u32 ana_rgc3);
>>  int mtk_sgmii_setup_mode_an(struct mtk_sgmii *ss, int id);
>>  int mtk_sgmii_setup_mode_force(struct mtk_sgmii *ss, int id,
>> -			       const struct phylink_link_state *state);
>> +			       phy_interface_t interface);
>> +void mtk_sgmii_link_up(struct mtk_sgmii *ss, int id, int speed,  
>> int duplex);
>>  void mtk_sgmii_restart_an(struct mtk_eth *eth, int mac_id);
>>
>>  int mtk_gmac_sgmii_path_setup(struct mtk_eth *eth, int mac_id);
>> diff --git a/drivers/net/ethernet/mediatek/mtk_sgmii.c  
>> b/drivers/net/ethernet/mediatek/mtk_sgmii.c
>> index 32d83421226a..372c85c830b5 100644
>> --- a/drivers/net/ethernet/mediatek/mtk_sgmii.c
>> +++ b/drivers/net/ethernet/mediatek/mtk_sgmii.c
>> @@ -60,7 +60,7 @@ int mtk_sgmii_setup_mode_an(struct mtk_sgmii *ss, int id)
>>  }
>>
>>  int mtk_sgmii_setup_mode_force(struct mtk_sgmii *ss, int id,
>> -			       const struct phylink_link_state *state)
>> +			       phy_interface_t interface)
>>  {
>>  	unsigned int val;
>>
>> @@ -69,7 +69,7 @@ int mtk_sgmii_setup_mode_force(struct mtk_sgmii  
>> *ss, int id,
>>
>>  	regmap_read(ss->regmap[id], ss->ana_rgc3, &val);
>>  	val &= ~RG_PHY_SPEED_MASK;
>> -	if (state->interface == PHY_INTERFACE_MODE_2500BASEX)
>> +	if (interface == PHY_INTERFACE_MODE_2500BASEX)
>>  		val |= RG_PHY_SPEED_3_125G;
>>  	regmap_write(ss->regmap[id], ss->ana_rgc3, val);
>>
>> @@ -78,11 +78,33 @@ int mtk_sgmii_setup_mode_force(struct mtk_sgmii  
>> *ss, int id,
>>  	val &= ~SGMII_AN_ENABLE;
>>  	regmap_write(ss->regmap[id], SGMSYS_PCS_CONTROL_1, val);
>>
>> +	if (interface == PHY_INTERFACE_MODE_1000BASEX ||
>> +	    interface == PHY_INTERFACE_MODE_2500BASEX) {
>> +		/* SGMII force mode setting */
>> +		regmap_read(ss->regmap[id], SGMSYS_SGMII_MODE, &val);
>> +		val &= ~SGMII_IF_MODE_MASK;
>> +		val |= SGMII_SPEED_1000;
>> +		val |= SGMII_DUPLEX_FULL;
>> +		regmap_write(ss->regmap[id], SGMSYS_SGMII_MODE, val);
>> +	}
>> +
>> +	/* Release PHYA power down state */
>> +	regmap_read(ss->regmap[id], SGMSYS_QPHY_PWR_STATE_CTRL, &val);
>> +	val &= ~SGMII_PHYA_PWD;
>> +	regmap_write(ss->regmap[id], SGMSYS_QPHY_PWR_STATE_CTRL, val);
>> +
>> +	return 0;
>> +}
>> +
>> +void mtk_sgmii_link_up(struct mtk_sgmii *ss, int id, int speed, int duplex)
>> +{
>> +	unsigned int val;
>> +
>>  	/* SGMII force mode setting */
>>  	regmap_read(ss->regmap[id], SGMSYS_SGMII_MODE, &val);
>>  	val &= ~SGMII_IF_MODE_MASK;
>>
>> -	switch (state->speed) {
>> +	switch (speed) {
>>  	case SPEED_10:
>>  		val |= SGMII_SPEED_10;
>>  		break;
>> @@ -95,17 +117,10 @@ int mtk_sgmii_setup_mode_force(struct  
>> mtk_sgmii *ss, int id,
>>  		break;
>>  	}
>>
>> -	if (state->duplex == DUPLEX_FULL)
>> +	if (duplex == DUPLEX_FULL)
>>  		val |= SGMII_DUPLEX_FULL;
>>
>>  	regmap_write(ss->regmap[id], SGMSYS_SGMII_MODE, val);
>> -
>> -	/* Release PHYA power down state */
>> -	regmap_read(ss->regmap[id], SGMSYS_QPHY_PWR_STATE_CTRL, &val);
>> -	val &= ~SGMII_PHYA_PWD;
>> -	regmap_write(ss->regmap[id], SGMSYS_QPHY_PWR_STATE_CTRL, val);
>> -
>> -	return 0;
>>  }
>>
>>  void mtk_sgmii_restart_an(struct mtk_eth *eth, int mac_id)
>> --
>> 2.20.1
>>
>>
>
> --
> RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
> FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!




_______________________________________________
Linux-mediatek mailing list
Linux-mediatek@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-mediatek

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [PATCH RFC net-next] net: mtk_eth_soc: use resolved link config for PCS PHY
  2020-06-30 22:13   ` René van Dorst
@ 2020-07-01  0:05     ` Russell King - ARM Linux admin
  0 siblings, 0 replies; 4+ messages in thread
From: Russell King - ARM Linux admin @ 2020-07-01  0:05 UTC (permalink / raw)
  To: René van Dorst
  Cc: Andrew Lunn, Florian Fainelli, netdev, Sean Wang, Mark Lee,
	linux-mediatek, John Crispin, Matthias Brugger, Jakub Kicinski,
	Felix Fietkau, David S. Miller, linux-arm-kernel,
	Heiner Kallweit

On Tue, Jun 30, 2020 at 10:13:08PM +0000, René van Dorst wrote:
> Hi Russel and Sean,
> 
> Quoting Russell King - ARM Linux admin <linux@armlinux.org.uk>:
> 
> > On Tue, Jun 30, 2020 at 11:15:42AM +0100, Russell King wrote:
> > > The SGMII PCS PHY needs to be updated with the link configuration in
> > > the mac_link_up() call rather than in mac_config().  However,
> > > mtk_sgmii_setup_mode_force() programs the SGMII block during
> > > mac_config() when using 802.3z interface modes with the link
> > > configuration.
> > > 
> > > Split that functionality from mtk_sgmii_setup_mode_force(), moving it
> > > to a new mtk_sgmii_link_up() function, and call it from mac_link_up().
> > > 
> > > This does not look correct to me: 802.3z modes operate at a fixed
> > > speed.  The contents of mtk_sgmii_link_up() look more appropriate for
> > > SGMII mode, but the original code definitely did not call
> > > mtk_sgmii_setup_mode_force() for SGMII mode but only 802.3z mode.
> > > 
> > > Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
> > > ---
> > > René, can you assist with this patch please - I really think there are
> > > problems with the existing code.  You call mtk_sgmii_setup_mode_force()
> > > in a block which is conditionalised as:
> > > 
> > > 	if (state->interface == PHY_INTERFACE_MODE_SGMII ||
> > > 	    phy_interface_mode_is_8023z(state->interface)) {
> > > ...
> > > 		if (state->interface != PHY_INTERFACE_MODE_SGMII)
> > > 			err = mtk_sgmii_setup_mode_force(eth->sgmii, sid,
> > > 							 state);
> > > 
> > > Hence, mtk_sgmii_setup_mode_force() is only called for 1000BASE-X and
> > > 2500BASE-X, which do not support anything but their native speeds.
> > > Yet, mtk_sgmii_setup_mode_force() tries to program the SGMII for 10M
> > > and 100M.
> > > 
> > > Note that this patch is more about moving uses of state->{speed,duplex}
> > > into mac_link_up(), rather than fixing this problem, but I don't think
> > > the addition in mtk_mac_link_up(), nor mtk_sgmii_link_up() is of any
> > > use.
> > 
> > My Coccinelle script just found this use of state->{speed,duplex} still
> > remaining:
> > 
> >                         if (MTK_HAS_CAPS(mac->hw->soc->caps,
> >                                          MTK_TRGMII_MT7621_CLK)) {
> > ...
> >                         } else {
> >                                 if (state->interface !=
> >                                     PHY_INTERFACE_MODE_TRGMII)
> >                                         mtk_gmac0_rgmii_adjust(mac->hw,
> >                                                                state->speed);
> > 
> > which also needs to be eliminated.  Can that also be moved to
> > mtk_mac_link_up()?
> 
> I know, you have pointed that out before. But I don't know how to fix
> mtk_gmac0_rgmii_adjust(). This function changes the PLL of the MAC. But
> without documentation I am not sure what all the bits are used for.

I'd forgotten...

> Begin April I had a conversation with Sean about this. I also explained what
> the issue was. AFAIK he was going to take care of this issue.
> 
> Sean did you had time to resolve this issue?

Well, I think the code as it stands is quite broken.

If we start a bit earlier in mtk_mac_config(), we have this:

        if (!MTK_HAS_CAPS(eth->soc->caps, MTK_SOC_MT7628) &&
            mac->interface != state->interface) {

which prevents us entering this block unless the interface mode has
changed and we are not MT7628.  This block of code includes the two
calls to mtk_gmac0_rgmii_adjust(), which are dependent on
state->speed.

Since mac->interface starts off as PHY_INTERFACE_MODE_NA, the first
time we head into mtk_mac_config(), the interface mode will be
different, and we will enter this block of code, maybe calling down
into mtk_gmac0_rgmii_adjust() if appropriate.

The first call will be via phylink_start(), which will call it with
the initial configuration - the link will be down, and state->speed
will be SPEED_UNKNOWN.  So, the various tests inside
mtk_gmac0_rgmii_adjust() for speed == SPEED_1000 will all be false,
meaning it'll program it as if for 10M or 100M speeds.

When the link comes up, yes, mtk_mac_config() will be called again
with the link parameters, but state->interface will now match
mac->interface - so the block of code containing the call to
mtk_gmac0_rgmii_adjust() will not be entered, and so none of that
code gets executed when the link comes up/down.

Now, if I dig out object 8ddbb8dcf032 from the git repository, which
was the state of the file immedately prior to the phylink conversion,
I find:

static void mtk_phy_link_adjust(struct net_device *dev)
{

This is the function that phylib would call when the link comes up
or down.  It tests for MTK_RESETTING, starts preparing a value for
mcr, and then:

        if (MTK_HAS_CAPS(mac->hw->soc->caps, MTK_GMAC1_TRGMII) && !mac->id) {
                if (MTK_HAS_CAPS(mac->hw->soc->caps, MTK_TRGMII_MT7621_CLK)) {
                        if (mt7621_gmac0_rgmii_adjust(mac->hw,
                                                      dev->phydev->interface))
                                return;
                } else {
                        if (!mac->trgmii)
                                mtk_gmac0_rgmii_adjust(mac->hw,
                                                       dev->phydev->speed);
                }
        }

It then finishes creating a value for mcr, before writing it to the
register, and printing the link status to the kernel log.

Hence, mtk_gmac0_rgmii_adjust() would've been called every time there's
a change of link state, and is expected to be passed the current speed.

There seems to be a difference in behaviour between the pre-phylink and
post-phylink drivers, and I think moving mtk_gmac0_rgmii_adjust() into
mtk_mac_link_up() would be a definite improvement, possibly even a
regression fix.

However, it would be reasonable to assume that there should be reports
that mtk_eth_soc doesn't work if this were the case.  So... odd.

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!

_______________________________________________
Linux-mediatek mailing list
Linux-mediatek@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-mediatek

^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, back to index

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-06-30 10:15 [PATCH RFC net-next] net: mtk_eth_soc: use resolved link config for PCS PHY Russell King
2020-06-30 10:46 ` Russell King - ARM Linux admin
2020-06-30 22:13   ` René van Dorst
2020-07-01  0:05     ` Russell King - ARM Linux admin

Linux-mediatek Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/linux-mediatek/0 linux-mediatek/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 linux-mediatek linux-mediatek/ https://lore.kernel.org/linux-mediatek \
		linux-mediatek@lists.infradead.org
	public-inbox-index linux-mediatek

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.infradead.lists.linux-mediatek


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git