All of lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH 0/6] add support for sama7g5 ethernet interfaces
@ 2020-12-03  9:25 Claudiu Beznea
  2020-12-03  9:25 ` [PATCH 1/6] net: macb: use dummy descriptor for RBQP Claudiu Beznea
                   ` (5 more replies)
  0 siblings, 6 replies; 16+ messages in thread
From: Claudiu Beznea @ 2020-12-03  9:25 UTC (permalink / raw)
  To: u-boot

Hi,

This series add support for SAMA7G5 ethernet interfaces: one
gigabit interface and one 10/100Mbps interface.

Thank you,
Claudiu Beznea

Claudiu Beznea (6):
  net: macb: use dummy descriptor for RBQP
  net: macb: add user io config data structure
  net: macb: check clk_set_rate return value to be negative
  net: macb: add support for sama7g5 gmac
  net: macb: add support for sama7g5 emac
  net: macb: take into account all RGMII interface types

 drivers/net/macb.c | 103 +++++++++++++++++++++++++++++++++++++++++++++--------
 drivers/net/macb.h |   2 ++
 2 files changed, 90 insertions(+), 15 deletions(-)

-- 
2.7.4

^ permalink raw reply	[flat|nested] 16+ messages in thread
* [PATCH 1/6] net: macb: use dummy descriptor for RBQP
  2020-12-03  9:25 [PATCH 0/6] add support for sama7g5 ethernet interfaces Claudiu Beznea
@ 2020-12-03  9:25 ` Claudiu Beznea
  2020-12-16  6:54   ` Eugen.Hristev at microchip.com
  2020-12-03  9:25 ` [PATCH 2/6] net: macb: add user io config data structure Claudiu Beznea
                   ` (4 subsequent siblings)
  5 siblings, 1 reply; 16+ messages in thread
From: Claudiu Beznea @ 2020-12-03  9:25 UTC (permalink / raw)
  To: u-boot

In case of multiple queues on RX side the queue scheduler
will try to use all the available configured queues (with
descriptors having TX_USED bit cleared). If at least one RBQP
points to a descriptor with a valid used bit configuration then
the reception may block as this may point to any memory. To avoid
this scenario all the queues (except queue zero) were disabled by
setting DMA descriptors with used bit set on proper RBQP. The driver
anyway uses only queue 0 for TX/RX.

Signed-off-by: Claudiu Beznea <claudiu.beznea@microchip.com>
---
 drivers/net/macb.c | 4 +++-
 drivers/net/macb.h | 2 ++
 2 files changed, 5 insertions(+), 1 deletion(-)

diff --git a/drivers/net/macb.c b/drivers/net/macb.c
index b80a259ff757..836eb85ec96a 100644
--- a/drivers/net/macb.c
+++ b/drivers/net/macb.c
@@ -732,8 +732,10 @@ static int gmac_init_multi_queues(struct macb_device *macb)
 	flush_dcache_range(macb->dummy_desc_dma, macb->dummy_desc_dma +
 			ALIGN(MACB_TX_DUMMY_DMA_DESC_SIZE, PKTALIGN));
 
-	for (i = 1; i < num_queues; i++)
+	for (i = 1; i < num_queues; i++) {
 		gem_writel_queue_TBQP(macb, macb->dummy_desc_dma, i - 1);
+		gem_writel_queue_RBQP(macb, macb->dummy_desc_dma, i - 1);
+	}
 
 	return 0;
 }
diff --git a/drivers/net/macb.h b/drivers/net/macb.h
index 9b16383eba46..28c7fe306883 100644
--- a/drivers/net/macb.h
+++ b/drivers/net/macb.h
@@ -768,5 +768,7 @@
 #define GEM_RX_CSUM_CHECKED_MASK		2
 #define gem_writel_queue_TBQP(port, value, queue_num)	\
 	writel((value), (port)->regs + GEM_TBQP(queue_num))
+#define gem_writel_queue_RBQP(port, value, queue_num)	\
+	writel((value), (port)->regs + GEM_RBQP(queue_num))
 
 #endif /* __DRIVERS_MACB_H__ */
-- 
2.7.4

^ permalink raw reply related	[flat|nested] 16+ messages in thread
* [PATCH 2/6] net: macb: add user io config data structure
  2020-12-03  9:25 [PATCH 0/6] add support for sama7g5 ethernet interfaces Claudiu Beznea
  2020-12-03  9:25 ` [PATCH 1/6] net: macb: use dummy descriptor for RBQP Claudiu Beznea
@ 2020-12-03  9:25 ` Claudiu Beznea
  2020-12-03  9:25 ` [PATCH 3/6] net: macb: check clk_set_rate return value to be negative Claudiu Beznea
                   ` (3 subsequent siblings)
  5 siblings, 0 replies; 16+ messages in thread
From: Claudiu Beznea @ 2020-12-03  9:25 UTC (permalink / raw)
  To: u-boot

Different implementation of USER IO register needs different
mapping for bit fields of this register. Add implementation
for this and, since clken is part of USER IO and it needs to
be activated based on per SoC capabilities, add caps in
macb_config where clken specific information needs to be filled.

Signed-off-by: Claudiu Beznea <claudiu.beznea@microchip.com>
---
 drivers/net/macb.c | 52 ++++++++++++++++++++++++++++++++++++++++------------
 1 file changed, 40 insertions(+), 12 deletions(-)

diff --git a/drivers/net/macb.c b/drivers/net/macb.c
index 836eb85ec96a..585d126a17f9 100644
--- a/drivers/net/macb.c
+++ b/drivers/net/macb.c
@@ -135,10 +135,19 @@ struct macb_device {
 #endif
 };
 
+struct macb_usrio_cfg {
+	unsigned int		mii;
+	unsigned int		rmii;
+	unsigned int		rgmii;
+	unsigned int		clken;
+};
+
 struct macb_config {
 	unsigned int		dma_burst_length;
+	unsigned int		caps;
 
 	int			(*clk_init)(struct udevice *dev, ulong rate);
+	const struct macb_usrio_cfg	*usrio;
 };
 
 #ifndef CONFIG_DM_ETH
@@ -818,6 +827,7 @@ static int _macb_init(struct macb_device *macb, const char *name)
 	macb_writel(macb, TBQP, macb->tx_ring_dma);
 
 	if (macb_is_gem(macb)) {
+		unsigned int val = 0;
 		/* Initialize DMA properties */
 		gmac_configure_dma(macb);
 		/* Check the multi queue and initialize the queue for tx */
@@ -830,11 +840,17 @@ static int _macb_init(struct macb_device *macb, const char *name)
 		 * to select interface between RMII and MII.
 		 */
 #ifdef CONFIG_DM_ETH
-		if ((macb->phy_interface == PHY_INTERFACE_MODE_RMII) ||
-		    (macb->phy_interface == PHY_INTERFACE_MODE_RGMII))
-			gem_writel(macb, USRIO, GEM_BIT(RGMII));
-		else
-			gem_writel(macb, USRIO, 0);
+		if (macb->phy_interface == PHY_INTERFACE_MODE_RGMII)
+			val = macb->config->usrio->rgmii;
+		else if (macb->phy_interface == PHY_INTERFACE_MODE_RMII)
+			val = macb->config->usrio->rmii;
+		else if (macb->phy_interface == PHY_INTERFACE_MODE_MII)
+			val = macb->config->usrio->mii;
+
+		if (macb->config->caps & MACB_CAPS_USRIO_HAS_CLKEN)
+			val |= macb->config->usrio->clken;
+
+		gem_writel(macb, USRIO, val);
 
 		if (macb->phy_interface == PHY_INTERFACE_MODE_SGMII) {
 			unsigned int ncfgr = macb_readl(macb, NCFGR);
@@ -844,7 +860,7 @@ static int _macb_init(struct macb_device *macb, const char *name)
 		}
 #else
 #if defined(CONFIG_RGMII) || defined(CONFIG_RMII)
-		gem_writel(macb, USRIO, GEM_BIT(RGMII));
+		gem_writel(macb, USRIO, macb->config->usrio->rgmii);
 #else
 		gem_writel(macb, USRIO, 0);
 #endif
@@ -855,28 +871,30 @@ static int _macb_init(struct macb_device *macb, const char *name)
 #ifdef CONFIG_AT91FAMILY
 		if (macb->phy_interface == PHY_INTERFACE_MODE_RMII) {
 			macb_writel(macb, USRIO,
-				    MACB_BIT(RMII) | MACB_BIT(CLKEN));
+				    macb->config->usrio->rmii |
+				    macb->config->usrio->clken);
 		} else {
-			macb_writel(macb, USRIO, MACB_BIT(CLKEN));
+			macb_writel(macb, USRIO, macb->config->usrio->clken);
 		}
 #else
 		if (macb->phy_interface == PHY_INTERFACE_MODE_RMII)
 			macb_writel(macb, USRIO, 0);
 		else
-			macb_writel(macb, USRIO, MACB_BIT(MII));
+			macb_writel(macb, USRIO, macb->config->usrio->mii);
 #endif
 #else
 #ifdef CONFIG_RMII
 #ifdef CONFIG_AT91FAMILY
-	macb_writel(macb, USRIO, MACB_BIT(RMII) | MACB_BIT(CLKEN));
+	macb_writel(macb, USRIO, macb->config->usrio->rmii |
+		    macb->config->usrio->clken);
 #else
 	macb_writel(macb, USRIO, 0);
 #endif
 #else
 #ifdef CONFIG_AT91FAMILY
-	macb_writel(macb, USRIO, MACB_BIT(CLKEN));
+	macb_writel(macb, USRIO, macb->config->usrio->clken);
 #else
-	macb_writel(macb, USRIO, MACB_BIT(MII));
+	macb_writel(macb, USRIO, macb->config->usrio->mii);
 #endif
 #endif /* CONFIG_RMII */
 #endif
@@ -1217,9 +1235,17 @@ static int macb_enable_clk(struct udevice *dev)
 }
 #endif
 
+static const struct macb_usrio_cfg macb_default_usrio = {
+	.mii = MACB_BIT(MII),
+	.rmii = MACB_BIT(RMII),
+	.rgmii = GEM_BIT(RGMII),
+	.clken = MACB_BIT(CLKEN),
+};
+
 static const struct macb_config default_gem_config = {
 	.dma_burst_length = 16,
 	.clk_init = NULL,
+	.usrio = &macb_default_usrio,
 };
 
 static int macb_eth_probe(struct udevice *dev)
@@ -1309,11 +1335,13 @@ static int macb_eth_ofdata_to_platdata(struct udevice *dev)
 static const struct macb_config sama5d4_config = {
 	.dma_burst_length = 4,
 	.clk_init = NULL,
+	.usrio = &macb_default_usrio,
 };
 
 static const struct macb_config sifive_config = {
 	.dma_burst_length = 16,
 	.clk_init = macb_sifive_clk_init,
+	.usrio = &macb_default_usrio,
 };
 
 static const struct udevice_id macb_eth_ids[] = {
-- 
2.7.4

^ permalink raw reply related	[flat|nested] 16+ messages in thread
* [PATCH 3/6] net: macb: check clk_set_rate return value to be negative
  2020-12-03  9:25 [PATCH 0/6] add support for sama7g5 ethernet interfaces Claudiu Beznea
  2020-12-03  9:25 ` [PATCH 1/6] net: macb: use dummy descriptor for RBQP Claudiu Beznea
  2020-12-03  9:25 ` [PATCH 2/6] net: macb: add user io config data structure Claudiu Beznea
@ 2020-12-03  9:25 ` Claudiu Beznea
  2020-12-03  9:25 ` [PATCH 4/6] net: macb: add support for sama7g5 gmac Claudiu Beznea
                   ` (2 subsequent siblings)
  5 siblings, 0 replies; 16+ messages in thread
From: Claudiu Beznea @ 2020-12-03  9:25 UTC (permalink / raw)
  To: u-boot

clk_set_rate() returns the set rate in case of success and a
negative number in case of failure. Consider failure only the
negative numbers.

Fixes: 3ef64444de157 ("dm: net: macb: Implement link speed change callback")
Signed-off-by: Claudiu Beznea <claudiu.beznea@microchip.com>
---
 drivers/net/macb.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/macb.c b/drivers/net/macb.c
index 585d126a17f9..439d1706485c 100644
--- a/drivers/net/macb.c
+++ b/drivers/net/macb.c
@@ -564,7 +564,7 @@ int __weak macb_linkspd_cb(struct udevice *dev, unsigned int speed)
 
 	if (tx_clk.dev) {
 		ret = clk_set_rate(&tx_clk, rate);
-		if (ret)
+		if (ret < 0)
 			return ret;
 	}
 #endif
-- 
2.7.4

^ permalink raw reply related	[flat|nested] 16+ messages in thread
* [PATCH 4/6] net: macb: add support for sama7g5 gmac
  2020-12-03  9:25 [PATCH 0/6] add support for sama7g5 ethernet interfaces Claudiu Beznea
                   ` (2 preceding siblings ...)
  2020-12-03  9:25 ` [PATCH 3/6] net: macb: check clk_set_rate return value to be negative Claudiu Beznea
@ 2020-12-03  9:25 ` Claudiu Beznea
  2020-12-03  9:25 ` [PATCH 5/6] net: macb: add support for sama7g5 emac Claudiu Beznea
  2020-12-03  9:25 ` [PATCH 6/6] net: macb: take into account all RGMII interface types Claudiu Beznea
  5 siblings, 0 replies; 16+ messages in thread
From: Claudiu Beznea @ 2020-12-03  9:25 UTC (permalink / raw)
  To: u-boot

Add support for SAMA7G5 GMAC.

Signed-off-by: Claudiu Beznea <claudiu.beznea@microchip.com>
---
 drivers/net/macb.c | 32 ++++++++++++++++++++++++++++++++
 1 file changed, 32 insertions(+)

diff --git a/drivers/net/macb.c b/drivers/net/macb.c
index 439d1706485c..8039a53d4f4c 100644
--- a/drivers/net/macb.c
+++ b/drivers/net/macb.c
@@ -528,6 +528,23 @@ static int macb_sifive_clk_init(struct udevice *dev, ulong rate)
 	return 0;
 }
 
+static int macb_sama7g5_clk_init(struct udevice *dev, ulong rate)
+{
+	struct clk clk;
+	int ret;
+
+	ret = clk_get_by_name(dev, "tx_clk", &clk);
+	if (ret)
+		return ret;
+
+	/*
+	 * This is for using GCK. Clock rate is addressed via assigned-clock
+	 * property, so only clock enable is needed here. The switching to
+	 * proper clock rate depending on link speed is managed by IP logic.
+	 */
+	return clk_enable(&clk);
+}
+
 int __weak macb_linkspd_cb(struct udevice *dev, unsigned int speed)
 {
 #ifdef CONFIG_CLK
@@ -1332,6 +1349,13 @@ static int macb_eth_ofdata_to_platdata(struct udevice *dev)
 	return macb_late_eth_ofdata_to_platdata(dev);
 }
 
+static const struct macb_usrio_cfg sama7g5_usrio = {
+	.mii = 0,
+	.rmii = 1,
+	.rgmii = 2,
+	.clken = BIT(2),
+};
+
 static const struct macb_config sama5d4_config = {
 	.dma_burst_length = 4,
 	.clk_init = NULL,
@@ -1344,10 +1368,18 @@ static const struct macb_config sifive_config = {
 	.usrio = &macb_default_usrio,
 };
 
+static const struct macb_config sama7g5_gmac_config = {
+	.dma_burst_length = 16,
+	.clk_init = macb_sama7g5_clk_init,
+	.usrio = &sama7g5_usrio,
+};
+
 static const struct udevice_id macb_eth_ids[] = {
 	{ .compatible = "cdns,macb" },
 	{ .compatible = "cdns,at91sam9260-macb" },
 	{ .compatible = "cdns,sam9x60-macb" },
+	{ .compatible = "cdns,sama7g5-gem",
+	  .data = (ulong)&sama7g5_gmac_config },
 	{ .compatible = "atmel,sama5d2-gem" },
 	{ .compatible = "atmel,sama5d3-gem" },
 	{ .compatible = "atmel,sama5d4-gem", .data = (ulong)&sama5d4_config },
-- 
2.7.4

^ permalink raw reply related	[flat|nested] 16+ messages in thread
* [PATCH 5/6] net: macb: add support for sama7g5 emac
  2020-12-03  9:25 [PATCH 0/6] add support for sama7g5 ethernet interfaces Claudiu Beznea
                   ` (3 preceding siblings ...)
  2020-12-03  9:25 ` [PATCH 4/6] net: macb: add support for sama7g5 gmac Claudiu Beznea
@ 2020-12-03  9:25 ` Claudiu Beznea
  2020-12-03  9:25 ` [PATCH 6/6] net: macb: take into account all RGMII interface types Claudiu Beznea
  5 siblings, 0 replies; 16+ messages in thread
From: Claudiu Beznea @ 2020-12-03  9:25 UTC (permalink / raw)
  To: u-boot

Add support for SAMA7G5 EMAC.

Signed-off-by: Claudiu Beznea <claudiu.beznea@microchip.com>
---
 drivers/net/macb.c | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/drivers/net/macb.c b/drivers/net/macb.c
index 8039a53d4f4c..e3003cb4a619 100644
--- a/drivers/net/macb.c
+++ b/drivers/net/macb.c
@@ -1374,12 +1374,20 @@ static const struct macb_config sama7g5_gmac_config = {
 	.usrio = &sama7g5_usrio,
 };
 
+static const struct macb_config sama7g5_emac_config = {
+	.caps = MACB_CAPS_USRIO_HAS_CLKEN,
+	.dma_burst_length = 16,
+	.usrio = &sama7g5_usrio,
+};
+
 static const struct udevice_id macb_eth_ids[] = {
 	{ .compatible = "cdns,macb" },
 	{ .compatible = "cdns,at91sam9260-macb" },
 	{ .compatible = "cdns,sam9x60-macb" },
 	{ .compatible = "cdns,sama7g5-gem",
 	  .data = (ulong)&sama7g5_gmac_config },
+	{ .compatible = "cdns,sama7g5-emac",
+	  .data = (ulong)&sama7g5_emac_config },
 	{ .compatible = "atmel,sama5d2-gem" },
 	{ .compatible = "atmel,sama5d3-gem" },
 	{ .compatible = "atmel,sama5d4-gem", .data = (ulong)&sama5d4_config },
-- 
2.7.4

^ permalink raw reply related	[flat|nested] 16+ messages in thread
* [PATCH 6/6] net: macb: take into account all RGMII interface types
  2020-12-03  9:25 [PATCH 0/6] add support for sama7g5 ethernet interfaces Claudiu Beznea
                   ` (4 preceding siblings ...)
  2020-12-03  9:25 ` [PATCH 5/6] net: macb: add support for sama7g5 emac Claudiu Beznea
@ 2020-12-03  9:25 ` Claudiu Beznea
  5 siblings, 0 replies; 16+ messages in thread
From: Claudiu Beznea @ 2020-12-03  9:25 UTC (permalink / raw)
  To: u-boot

Take into account all RGMII interface types. Depending on it
the RGMII PHY's timings are setup.

Signed-off-by: Claudiu Beznea <claudiu.beznea@microchip.com>
---
 drivers/net/macb.c | 7 +++++--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/drivers/net/macb.c b/drivers/net/macb.c
index e3003cb4a619..127d6e899bad 100644
--- a/drivers/net/macb.c
+++ b/drivers/net/macb.c
@@ -630,7 +630,7 @@ static int macb_phy_init(struct macb_device *macb, const char *name)
 #else
 	/* need to consider other phy interface mode */
 	macb->phydev = phy_connect(macb->bus, macb->phy_addr, &macb->netdev,
-			     PHY_INTERFACE_MODE_RGMII);
+				   macb->phy_interface);
 #endif
 	if (!macb->phydev) {
 		printf("phy_connect failed\n");
@@ -857,7 +857,10 @@ static int _macb_init(struct macb_device *macb, const char *name)
 		 * to select interface between RMII and MII.
 		 */
 #ifdef CONFIG_DM_ETH
-		if (macb->phy_interface == PHY_INTERFACE_MODE_RGMII)
+		if (macb->phy_interface == PHY_INTERFACE_MODE_RGMII ||
+		    macb->phy_interface == PHY_INTERFACE_MODE_RGMII_ID ||
+		    macb->phy_interface == PHY_INTERFACE_MODE_RGMII_RXID ||
+		    macb->phy_interface == PHY_INTERFACE_MODE_RGMII_TXID)
 			val = macb->config->usrio->rgmii;
 		else if (macb->phy_interface == PHY_INTERFACE_MODE_RMII)
 			val = macb->config->usrio->rmii;
-- 
2.7.4

^ permalink raw reply related	[flat|nested] 16+ messages in thread
* [PATCH 1/6] net: macb: use dummy descriptor for RBQP
  2020-12-03  9:25 ` [PATCH 1/6] net: macb: use dummy descriptor for RBQP Claudiu Beznea
@ 2020-12-16  6:54   ` Eugen.Hristev at microchip.com
  2020-12-16  7:17     ` Bin Meng
  2020-12-17  5:22     ` Padmarao.Begari at microchip.com
  0 siblings, 2 replies; 16+ messages in thread
From: Eugen.Hristev at microchip.com @ 2020-12-16  6:54 UTC (permalink / raw)
  To: u-boot

On 03.12.2020 11:25, Claudiu Beznea wrote:
> In case of multiple queues on RX side the queue scheduler
> will try to use all the available configured queues (with
> descriptors having TX_USED bit cleared). If at least one RBQP
> points to a descriptor with a valid used bit configuration then
> the reception may block as this may point to any memory. To avoid
> this scenario all the queues (except queue zero) were disabled by
> setting DMA descriptors with used bit set on proper RBQP. The driver
> anyway uses only queue 0 for TX/RX.
> 
> Signed-off-by: Claudiu Beznea <claudiu.beznea@microchip.com>
> ---

Hi Anup, Bin, Padmarao,

I noticed on the mailing list that you have been actively working and 
testing the Macb driver on various platforms, we have this series 
outstanding and I want to make sure that it does not break anything on 
your side, so it would be appreciated if you could have a look or test 
it before it goes into master branch.

Thanks !
Eugen


>   drivers/net/macb.c | 4 +++-
>   drivers/net/macb.h | 2 ++
>   2 files changed, 5 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/net/macb.c b/drivers/net/macb.c
> index b80a259ff757..836eb85ec96a 100644
> --- a/drivers/net/macb.c
> +++ b/drivers/net/macb.c
> @@ -732,8 +732,10 @@ static int gmac_init_multi_queues(struct macb_device *macb)
>   	flush_dcache_range(macb->dummy_desc_dma, macb->dummy_desc_dma +
>   			ALIGN(MACB_TX_DUMMY_DMA_DESC_SIZE, PKTALIGN));
>   
> -	for (i = 1; i < num_queues; i++)
> +	for (i = 1; i < num_queues; i++) {
>   		gem_writel_queue_TBQP(macb, macb->dummy_desc_dma, i - 1);
> +		gem_writel_queue_RBQP(macb, macb->dummy_desc_dma, i - 1);
> +	}
>   
>   	return 0;
>   }
> diff --git a/drivers/net/macb.h b/drivers/net/macb.h
> index 9b16383eba46..28c7fe306883 100644
> --- a/drivers/net/macb.h
> +++ b/drivers/net/macb.h
> @@ -768,5 +768,7 @@
>   #define GEM_RX_CSUM_CHECKED_MASK		2
>   #define gem_writel_queue_TBQP(port, value, queue_num)	\
>   	writel((value), (port)->regs + GEM_TBQP(queue_num))
> +#define gem_writel_queue_RBQP(port, value, queue_num)	\
> +	writel((value), (port)->regs + GEM_RBQP(queue_num))
>   
>   #endif /* __DRIVERS_MACB_H__ */
> 

^ permalink raw reply	[flat|nested] 16+ messages in thread
* [PATCH 1/6] net: macb: use dummy descriptor for RBQP
  2020-12-16  6:54   ` Eugen.Hristev at microchip.com
@ 2020-12-16  7:17     ` Bin Meng
  2020-12-16  8:29       ` Eugen.Hristev at microchip.com
  2020-12-17  5:22     ` Padmarao.Begari at microchip.com
  1 sibling, 1 reply; 16+ messages in thread
From: Bin Meng @ 2020-12-16  7:17 UTC (permalink / raw)
  To: u-boot

Hi Eugen,

On Wed, Dec 16, 2020 at 2:55 PM <Eugen.Hristev@microchip.com> wrote:
>
> On 03.12.2020 11:25, Claudiu Beznea wrote:
> > In case of multiple queues on RX side the queue scheduler
> > will try to use all the available configured queues (with
> > descriptors having TX_USED bit cleared). If at least one RBQP
> > points to a descriptor with a valid used bit configuration then
> > the reception may block as this may point to any memory. To avoid
> > this scenario all the queues (except queue zero) were disabled by
> > setting DMA descriptors with used bit set on proper RBQP. The driver
> > anyway uses only queue 0 for TX/RX.
> >
> > Signed-off-by: Claudiu Beznea <claudiu.beznea@microchip.com>
> > ---
>
> Hi Anup, Bin, Padmarao,
>
> I noticed on the mailing list that you have been actively working and
> testing the Macb driver on various platforms, we have this series
> outstanding and I want to make sure that it does not break anything on
> your side, so it would be appreciated if you could have a look or test
> it before it goes into master branch.
>

Is this series for Microchip PolarFire SoC?

Regards,
Bin

^ permalink raw reply	[flat|nested] 16+ messages in thread
* [PATCH 1/6] net: macb: use dummy descriptor for RBQP
  2020-12-16  7:17     ` Bin Meng
@ 2020-12-16  8:29       ` Eugen.Hristev at microchip.com
  0 siblings, 0 replies; 16+ messages in thread
From: Eugen.Hristev at microchip.com @ 2020-12-16  8:29 UTC (permalink / raw)
  To: u-boot

On 16.12.2020 09:17, Bin Meng wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
> 
> Hi Eugen,
> 
> On Wed, Dec 16, 2020 at 2:55 PM <Eugen.Hristev@microchip.com> wrote:
>>
>> On 03.12.2020 11:25, Claudiu Beznea wrote:
>>> In case of multiple queues on RX side the queue scheduler
>>> will try to use all the available configured queues (with
>>> descriptors having TX_USED bit cleared). If at least one RBQP
>>> points to a descriptor with a valid used bit configuration then
>>> the reception may block as this may point to any memory. To avoid
>>> this scenario all the queues (except queue zero) were disabled by
>>> setting DMA descriptors with used bit set on proper RBQP. The driver
>>> anyway uses only queue 0 for TX/RX.
>>>
>>> Signed-off-by: Claudiu Beznea <claudiu.beznea@microchip.com>
>>> ---
>>
>> Hi Anup, Bin, Padmarao,
>>
>> I noticed on the mailing list that you have been actively working and
>> testing the Macb driver on various platforms, we have this series
>> outstanding and I want to make sure that it does not break anything on
>> your side, so it would be appreciated if you could have a look or test
>> it before it goes into master branch.
>>
> 
> Is this series for Microchip PolarFire SoC?

No, but this series affects the macb driver, and because other platforms 
use it, I do not wish to have a chance to break them.
> 
> Regards,
> Bin
> 

^ permalink raw reply	[flat|nested] 16+ messages in thread
* [PATCH 1/6] net: macb: use dummy descriptor for RBQP
  2020-12-16  6:54   ` Eugen.Hristev at microchip.com
  2020-12-16  7:17     ` Bin Meng
@ 2020-12-17  5:22     ` Padmarao.Begari at microchip.com
  2021-01-14 11:19       ` Eugen.Hristev at microchip.com
  1 sibling, 1 reply; 16+ messages in thread
From: Padmarao.Begari at microchip.com @ 2020-12-17  5:22 UTC (permalink / raw)
  To: u-boot

Hi Eugen,

This series of patches break my side of work(patches) so you need to create patches after my patches are going into master branch because my patches are already reviewed and tested.

Regards
Padmarao
________________________________
From: Eugen Hristev - M18282 <Eugen.Hristev@microchip.com>
Sent: Wednesday, December 16, 2020 12:24 PM
To: anup.patel at wdc.com <anup.patel@wdc.com>; bin.meng at windriver.com <bin.meng@windriver.com>; Padmarao Begari - I30397 <Padmarao.Begari@microchip.com>
Cc: Claudiu Beznea - M18063 <Claudiu.Beznea@microchip.com>; joe.hershberger at ni.com <joe.hershberger@ni.com>; u-boot at lists.denx.de <u-boot@lists.denx.de>
Subject: Re: [PATCH 1/6] net: macb: use dummy descriptor for RBQP

On 03.12.2020 11:25, Claudiu Beznea wrote:
> In case of multiple queues on RX side the queue scheduler
> will try to use all the available configured queues (with
> descriptors having TX_USED bit cleared). If at least one RBQP
> points to a descriptor with a valid used bit configuration then
> the reception may block as this may point to any memory. To avoid
> this scenario all the queues (except queue zero) were disabled by
> setting DMA descriptors with used bit set on proper RBQP. The driver
> anyway uses only queue 0 for TX/RX.
>
> Signed-off-by: Claudiu Beznea <claudiu.beznea@microchip.com>
> ---

Hi Anup, Bin, Padmarao,

I noticed on the mailing list that you have been actively working and
testing the Macb driver on various platforms, we have this series
outstanding and I want to make sure that it does not break anything on
your side, so it would be appreciated if you could have a look or test
it before it goes into master branch.

Thanks !
Eugen


>   drivers/net/macb.c | 4 +++-
>   drivers/net/macb.h | 2 ++
>   2 files changed, 5 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/net/macb.c b/drivers/net/macb.c
> index b80a259ff757..836eb85ec96a 100644
> --- a/drivers/net/macb.c
> +++ b/drivers/net/macb.c
> @@ -732,8 +732,10 @@ static int gmac_init_multi_queues(struct macb_device *macb)
>        flush_dcache_range(macb->dummy_desc_dma, macb->dummy_desc_dma +
>                        ALIGN(MACB_TX_DUMMY_DMA_DESC_SIZE, PKTALIGN));
>
> -     for (i = 1; i < num_queues; i++)
> +     for (i = 1; i < num_queues; i++) {
>                gem_writel_queue_TBQP(macb, macb->dummy_desc_dma, i - 1);
> +             gem_writel_queue_RBQP(macb, macb->dummy_desc_dma, i - 1);
> +     }
>
>        return 0;
>   }
> diff --git a/drivers/net/macb.h b/drivers/net/macb.h
> index 9b16383eba46..28c7fe306883 100644
> --- a/drivers/net/macb.h
> +++ b/drivers/net/macb.h
> @@ -768,5 +768,7 @@
>   #define GEM_RX_CSUM_CHECKED_MASK            2
>   #define gem_writel_queue_TBQP(port, value, queue_num)       \
>        writel((value), (port)->regs + GEM_TBQP(queue_num))
> +#define gem_writel_queue_RBQP(port, value, queue_num)        \
> +     writel((value), (port)->regs + GEM_RBQP(queue_num))
>
>   #endif /* __DRIVERS_MACB_H__ */
>

^ permalink raw reply	[flat|nested] 16+ messages in thread
* [PATCH 1/6] net: macb: use dummy descriptor for RBQP
  2020-12-17  5:22     ` Padmarao.Begari at microchip.com
@ 2021-01-14 11:19       ` Eugen.Hristev at microchip.com
  2021-01-15  4:02         ` Padmarao Begari
  0 siblings, 1 reply; 16+ messages in thread
From: Eugen.Hristev at microchip.com @ 2021-01-14 11:19 UTC (permalink / raw)
  To: u-boot

On 17.12.2020 07:22, Padmarao Begari - I30397 wrote:
> Hi Eugen,
> 
> This series of patches break my side of work(patches) so you need to 
> create patches after my patches are going into master branch because my 
> patches are already reviewed and tested.

Hi,

Could you please detail the breakage ?
I saw a pull request with your patches that was NAK-ed, if your two macb 
patches are tested and reviewed I could apply them to the atmel tree as 
well and send them, if your PR is delayed. But we are interested to have 
our sama7g5 series pushed as well, so we need to know if it's ok on your 
side, and what is wrong with the sama7g5 series.

Thanks!
Eugen
> 
> Regards
> Padmarao
> ------------------------------------------------------------------------
> *From:* Eugen Hristev - M18282 <Eugen.Hristev@microchip.com>
> *Sent:* Wednesday, December 16, 2020 12:24 PM
> *To:* anup.patel at wdc.com <anup.patel@wdc.com>; bin.meng at windriver.com 
> <bin.meng@windriver.com>; Padmarao Begari - I30397 
> <Padmarao.Begari@microchip.com>
> *Cc:* Claudiu Beznea - M18063 <Claudiu.Beznea@microchip.com>; 
> joe.hershberger at ni.com <joe.hershberger@ni.com>; u-boot at lists.denx.de 
> <u-boot@lists.denx.de>
> *Subject:* Re: [PATCH 1/6] net: macb: use dummy descriptor for RBQP
> On 03.12.2020 11:25, Claudiu Beznea wrote:
>> In case of multiple queues on RX side the queue scheduler
>> will try to use all the available configured queues (with
>> descriptors having TX_USED bit cleared). If at least one RBQP
>> points to a descriptor with a valid used bit configuration then
>> the reception may block as this may point to any memory. To avoid
>> this scenario all the queues (except queue zero) were disabled by
>> setting DMA descriptors with used bit set on proper RBQP. The driver
>> anyway uses only queue 0 for TX/RX.
>> 
>> Signed-off-by: Claudiu Beznea <claudiu.beznea@microchip.com>
>> ---
> 
> Hi Anup, Bin, Padmarao,
> 
> I noticed on the mailing list that you have been actively working and
> testing the Macb driver on various platforms, we have this series
> outstanding and I want to make sure that it does not break anything on
> your side, so it would be appreciated if you could have a look or test
> it before it goes into master branch.
> 
> Thanks !
> Eugen
> 
> 
>>?? drivers/net/macb.c | 4 +++-
>>?? drivers/net/macb.h | 2 ++
>>?? 2 files changed, 5 insertions(+), 1 deletion(-)
>> 
>> diff --git a/drivers/net/macb.c b/drivers/net/macb.c
>> index b80a259ff757..836eb85ec96a 100644
>> --- a/drivers/net/macb.c
>> +++ b/drivers/net/macb.c
>> @@ -732,8 +732,10 @@ static int gmac_init_multi_queues(struct macb_device *macb)
>>??????? flush_dcache_range(macb->dummy_desc_dma, macb->dummy_desc_dma +
>>??????????????????????? ALIGN(MACB_TX_DUMMY_DMA_DESC_SIZE, PKTALIGN));
>>   
>> -???? for (i = 1; i < num_queues; i++)
>> +???? for (i = 1; i < num_queues; i++) {
>>??????????????? gem_writel_queue_TBQP(macb, macb->dummy_desc_dma, i - 1);
>> +???????????? gem_writel_queue_RBQP(macb, macb->dummy_desc_dma, i - 1);
>> +???? }
>>   
>>??????? return 0;
>>?? }
>> diff --git a/drivers/net/macb.h b/drivers/net/macb.h
>> index 9b16383eba46..28c7fe306883 100644
>> --- a/drivers/net/macb.h
>> +++ b/drivers/net/macb.h
>> @@ -768,5 +768,7 @@
>>?? #define GEM_RX_CSUM_CHECKED_MASK??????????? 2
>>?? #define gem_writel_queue_TBQP(port, value, queue_num)?????? \
>>??????? writel((value), (port)->regs + GEM_TBQP(queue_num))
>> +#define gem_writel_queue_RBQP(port, value, queue_num)??????? \
>> +???? writel((value), (port)->regs + GEM_RBQP(queue_num))
>>   
>>?? #endif /* __DRIVERS_MACB_H__ */
>> 
> 

^ permalink raw reply	[flat|nested] 16+ messages in thread
* [PATCH 1/6] net: macb: use dummy descriptor for RBQP
  2021-01-14 11:19       ` Eugen.Hristev at microchip.com
@ 2021-01-15  4:02         ` Padmarao Begari
  2021-01-15  8:04           ` Eugen.Hristev at microchip.com
  0 siblings, 1 reply; 16+ messages in thread
From: Padmarao Begari @ 2021-01-15  4:02 UTC (permalink / raw)
  To: u-boot

Hi Eugen,

On Thu, Jan 14, 2021 at 4:50 PM <Eugen.Hristev@microchip.com> wrote:

> On 17.12.2020 07:22, Padmarao Begari - I30397 wrote:
> > Hi Eugen,
> >
> > This series of patches break my side of work(patches) so you need to
> > create patches after my patches are going into master branch because my
> > patches are already reviewed and tested.
>
> Hi,
>
> Could you please detail the breakage ?
>

The breakage is the fdt relocation disabled in the board environment
variables so I have removed it and enabled fdt relocation in PATCH v9.

Regards
Padmarao


> I saw a pull request with your patches that was NAK-ed, if your two macb
> patches are tested and reviewed I could apply them to the atmel tree as
> well and send them, if your PR is delayed. But we are interested to have
> our sama7g5 series pushed as well, so we need to know if it's ok on your
> side, and what is wrong with the sama7g5 series.
>
> Thanks!
> Eugen
> >
> > Regards
> > Padmarao
> > ------------------------------------------------------------------------
> > *From:* Eugen Hristev - M18282 <Eugen.Hristev@microchip.com>
> > *Sent:* Wednesday, December 16, 2020 12:24 PM
> > *To:* anup.patel at wdc.com <anup.patel@wdc.com>; bin.meng at windriver.com
> > <bin.meng@windriver.com>; Padmarao Begari - I30397
> > <Padmarao.Begari@microchip.com>
> > *Cc:* Claudiu Beznea - M18063 <Claudiu.Beznea@microchip.com>;
> > joe.hershberger at ni.com <joe.hershberger@ni.com>; u-boot at lists.denx.de
> > <u-boot@lists.denx.de>
> > *Subject:* Re: [PATCH 1/6] net: macb: use dummy descriptor for RBQP
> > On 03.12.2020 11:25, Claudiu Beznea wrote:
> >> In case of multiple queues on RX side the queue scheduler
> >> will try to use all the available configured queues (with
> >> descriptors having TX_USED bit cleared). If at least one RBQP
> >> points to a descriptor with a valid used bit configuration then
> >> the reception may block as this may point to any memory. To avoid
> >> this scenario all the queues (except queue zero) were disabled by
> >> setting DMA descriptors with used bit set on proper RBQP. The driver
> >> anyway uses only queue 0 for TX/RX.
> >>
> >> Signed-off-by: Claudiu Beznea <claudiu.beznea@microchip.com>
> >> ---
> >
> > Hi Anup, Bin, Padmarao,
> >
> > I noticed on the mailing list that you have been actively working and
> > testing the Macb driver on various platforms, we have this series
> > outstanding and I want to make sure that it does not break anything on
> > your side, so it would be appreciated if you could have a look or test
> > it before it goes into master branch.
> >
> > Thanks !
> > Eugen
> >
> >
> >>   drivers/net/macb.c | 4 +++-
> >>   drivers/net/macb.h | 2 ++
> >>   2 files changed, 5 insertions(+), 1 deletion(-)
> >>
> >> diff --git a/drivers/net/macb.c b/drivers/net/macb.c
> >> index b80a259ff757..836eb85ec96a 100644
> >> --- a/drivers/net/macb.c
> >> +++ b/drivers/net/macb.c
> >> @@ -732,8 +732,10 @@ static int gmac_init_multi_queues(struct
> macb_device *macb)
> >>        flush_dcache_range(macb->dummy_desc_dma, macb->dummy_desc_dma +
> >>                        ALIGN(MACB_TX_DUMMY_DMA_DESC_SIZE, PKTALIGN));
> >>
> >> -     for (i = 1; i < num_queues; i++)
> >> +     for (i = 1; i < num_queues; i++) {
> >>                gem_writel_queue_TBQP(macb, macb->dummy_desc_dma, i - 1);
> >> +             gem_writel_queue_RBQP(macb, macb->dummy_desc_dma, i - 1);
> >> +     }
> >>
> >>        return 0;
> >>   }
> >> diff --git a/drivers/net/macb.h b/drivers/net/macb.h
> >> index 9b16383eba46..28c7fe306883 100644
> >> --- a/drivers/net/macb.h
> >> +++ b/drivers/net/macb.h
> >> @@ -768,5 +768,7 @@
> >>   #define GEM_RX_CSUM_CHECKED_MASK            2
> >>   #define gem_writel_queue_TBQP(port, value, queue_num)       \
> >>        writel((value), (port)->regs + GEM_TBQP(queue_num))
> >> +#define gem_writel_queue_RBQP(port, value, queue_num)        \
> >> +     writel((value), (port)->regs + GEM_RBQP(queue_num))
> >>
> >>   #endif /* __DRIVERS_MACB_H__ */
> >>
> >
>
>

^ permalink raw reply	[flat|nested] 16+ messages in thread
* [PATCH 1/6] net: macb: use dummy descriptor for RBQP
  2021-01-15  4:02         ` Padmarao Begari
@ 2021-01-15  8:04           ` Eugen.Hristev at microchip.com
  2021-01-15 12:26             ` Padmarao Begari
  0 siblings, 1 reply; 16+ messages in thread
From: Eugen.Hristev at microchip.com @ 2021-01-15  8:04 UTC (permalink / raw)
  To: u-boot

On 15.01.2021 06:02, Padmarao Begari wrote:
> Hi Eugen,
> 
> On Thu, Jan 14, 2021 at 4:50 PM <Eugen.Hristev@microchip.com 
> <mailto:Eugen.Hristev@microchip.com>> wrote:
> 
>     On 17.12.2020 07:22, Padmarao Begari - I30397 wrote:
>      > Hi Eugen,
>      >
>      > This series of patches break my side of work(patches) so you need to
>      > create patches after my patches are going into master branch
>     because my
>      > patches are already reviewed and tested.
> 
>     Hi,
> 
>     Could you please detail the breakage ?
> 
> 
> The breakage is the fdt relocation disabled in the board environment 
> variables so I have removed it and enabled fdt relocation in PATCH v9.

Maybe you misunderstand my question. I was asking about the sama7g5 macb 
series, which you claimed that breaks your current patch set.
This is a link to the series :
https://patchwork.ozlabs.org/project/uboot/list/?series=218367

Since you claimed that this series breaks your series, I am asking what 
exactly is the breakage. How does the fdt relocation in your board 
environment has anything to do with macb and these patches which are not 
applied ?

Thanks,
Eugen

> 
> Regards
> Padmarao
> 
>     I saw a pull request with your patches that was NAK-ed, if your two
>     macb
>     patches are tested and reviewed I could apply them to the atmel tree as
>     well and send them, if your PR is delayed. But we are interested to
>     have
>     our sama7g5 series pushed as well, so we need to know if it's ok on
>     your
>     side, and what is wrong with the sama7g5 series.
> 
>     Thanks!
>     Eugen
>      >
>      > Regards
>      > Padmarao
>      >
>     ------------------------------------------------------------------------
>      > *From:* Eugen Hristev - M18282 <Eugen.Hristev@microchip.com
>     <mailto:Eugen.Hristev@microchip.com>>
>      > *Sent:* Wednesday, December 16, 2020 12:24 PM
>      > *To:* anup.patel at wdc.com <mailto:anup.patel@wdc.com>
>     <anup.patel at wdc.com <mailto:anup.patel@wdc.com>>;
>     bin.meng at windriver.com <mailto:bin.meng@windriver.com>
>      > <bin.meng at windriver.com <mailto:bin.meng@windriver.com>>;
>     Padmarao Begari - I30397
>      > <Padmarao.Begari@microchip.com
>     <mailto:Padmarao.Begari@microchip.com>>
>      > *Cc:* Claudiu Beznea - M18063 <Claudiu.Beznea@microchip.com
>     <mailto:Claudiu.Beznea@microchip.com>>;
>      > joe.hershberger at ni.com <mailto:joe.hershberger@ni.com>
>     <joe.hershberger at ni.com <mailto:joe.hershberger@ni.com>>;
>     u-boot at lists.denx.de <mailto:u-boot@lists.denx.de>
>      > <u-boot at lists.denx.de <mailto:u-boot@lists.denx.de>>
>      > *Subject:* Re: [PATCH 1/6] net: macb: use dummy descriptor for RBQP
>      > On 03.12.2020 11:25, Claudiu Beznea wrote:
>      >> In case of multiple queues on RX side the queue scheduler
>      >> will try to use all the available configured queues (with
>      >> descriptors having TX_USED bit cleared). If at least one RBQP
>      >> points to a descriptor with a valid used bit configuration then
>      >> the reception may block as this may point to any memory. To avoid
>      >> this scenario all the queues (except queue zero) were disabled by
>      >> setting DMA descriptors with used bit set on proper RBQP. The driver
>      >> anyway uses only queue 0 for TX/RX.
>      >>
>      >> Signed-off-by: Claudiu Beznea <claudiu.beznea@microchip.com
>     <mailto:claudiu.beznea@microchip.com>>
>      >> ---
>      >
>      > Hi Anup, Bin, Padmarao,
>      >
>      > I noticed on the mailing list that you have been actively working and
>      > testing the Macb driver on various platforms, we have this series
>      > outstanding and I want to make sure that it does not break
>     anything on
>      > your side, so it would be appreciated if you could have a look or
>     test
>      > it before it goes into master branch.
>      >
>      > Thanks !
>      > Eugen
>      >
>      >
>      >>?? drivers/net/macb.c | 4 +++-
>      >>?? drivers/net/macb.h | 2 ++
>      >>?? 2 files changed, 5 insertions(+), 1 deletion(-)
>      >>
>      >> diff --git a/drivers/net/macb.c b/drivers/net/macb.c
>      >> index b80a259ff757..836eb85ec96a 100644
>      >> --- a/drivers/net/macb.c
>      >> +++ b/drivers/net/macb.c
>      >> @@ -732,8 +732,10 @@ static int gmac_init_multi_queues(struct
>     macb_device *macb)
>      >>??????? flush_dcache_range(macb->dummy_desc_dma,
>     macb->dummy_desc_dma +
>      >>??????????????????????? ALIGN(MACB_TX_DUMMY_DMA_DESC_SIZE,
>     PKTALIGN));
>      >>
>      >> -???? for (i = 1; i < num_queues; i++)
>      >> +???? for (i = 1; i < num_queues; i++) {
>      >>??????????????? gem_writel_queue_TBQP(macb, macb->dummy_desc_dma,
>     i - 1);
>      >> +???????????? gem_writel_queue_RBQP(macb, macb->dummy_desc_dma,
>     i - 1);
>      >> +???? }
>      >>
>      >>??????? return 0;
>      >>?? }
>      >> diff --git a/drivers/net/macb.h b/drivers/net/macb.h
>      >> index 9b16383eba46..28c7fe306883 100644
>      >> --- a/drivers/net/macb.h
>      >> +++ b/drivers/net/macb.h
>      >> @@ -768,5 +768,7 @@
>      >>?? #define GEM_RX_CSUM_CHECKED_MASK??????????? 2
>      >>?? #define gem_writel_queue_TBQP(port, value, queue_num)?????? \
>      >>??????? writel((value), (port)->regs + GEM_TBQP(queue_num))
>      >> +#define gem_writel_queue_RBQP(port, value, queue_num)??????? \
>      >> +???? writel((value), (port)->regs + GEM_RBQP(queue_num))
>      >>
>      >>?? #endif /* __DRIVERS_MACB_H__ */
>      >>
>      >
> 

^ permalink raw reply	[flat|nested] 16+ messages in thread
* [PATCH 1/6] net: macb: use dummy descriptor for RBQP
  2021-01-15  8:04           ` Eugen.Hristev at microchip.com
@ 2021-01-15 12:26             ` Padmarao Begari
  2021-01-15 12:42               ` Eugen.Hristev at microchip.com
  0 siblings, 1 reply; 16+ messages in thread
From: Padmarao Begari @ 2021-01-15 12:26 UTC (permalink / raw)
  To: u-boot

Hi Eugen,

On Fri, Jan 15, 2021 at 1:34 PM <Eugen.Hristev@microchip.com> wrote:

> On 15.01.2021 06:02, Padmarao Begari wrote:
> > Hi Eugen,
> >
> > On Thu, Jan 14, 2021 at 4:50 PM <Eugen.Hristev@microchip.com
> > <mailto:Eugen.Hristev@microchip.com>> wrote:
> >
> >     On 17.12.2020 07:22, Padmarao Begari - I30397 wrote:
> >      > Hi Eugen,
> >      >
> >      > This series of patches break my side of work(patches) so you need
> to
> >      > create patches after my patches are going into master branch
> >     because my
> >      > patches are already reviewed and tested.
> >
> >     Hi,
> >
> >     Could you please detail the breakage ?
> >
> >
> > The breakage is the fdt relocation disabled in the board environment
> > variables so I have removed it and enabled fdt relocation in PATCH v9.
>
> Maybe you misunderstand my question. I was asking about the sama7g5 macb
> series, which you claimed that breaks your current patch set.
> This is a link to the series :
> https://patchwork.ozlabs.org/project/uboot/list/?series=218367
>
> Since you claimed that this series breaks your series, I am asking what
> exactly is the breakage. How does the fdt relocation in your board
> environment has anything to do with macb and these patches which are not
> applied ?
>
>
My mistake, misunderstood your question,
Yes the fdt relocation has nothing to do with the macb.
We both are adding a member into struct mac_config, a dummy descriptor
for RBQP and my changes are both 32-bit and 64-bit DMA.

Regards
Padmarao


> Thanks,
> Eugen
>
> >
> > Regards
> > Padmarao
> >
> >     I saw a pull request with your patches that was NAK-ed, if your two
> >     macb
> >     patches are tested and reviewed I could apply them to the atmel tree
> as
> >     well and send them, if your PR is delayed. But we are interested to
> >     have
> >     our sama7g5 series pushed as well, so we need to know if it's ok on
> >     your
> >     side, and what is wrong with the sama7g5 series.
> >
> >     Thanks!
> >     Eugen
> >      >
> >      > Regards
> >      > Padmarao
> >      >
> >
>  ------------------------------------------------------------------------
> >      > *From:* Eugen Hristev - M18282 <Eugen.Hristev@microchip.com
> >     <mailto:Eugen.Hristev@microchip.com>>
> >      > *Sent:* Wednesday, December 16, 2020 12:24 PM
> >      > *To:* anup.patel at wdc.com <mailto:anup.patel@wdc.com>
> >     <anup.patel at wdc.com <mailto:anup.patel@wdc.com>>;
> >     bin.meng at windriver.com <mailto:bin.meng@windriver.com>
> >      > <bin.meng at windriver.com <mailto:bin.meng@windriver.com>>;
> >     Padmarao Begari - I30397
> >      > <Padmarao.Begari@microchip.com
> >     <mailto:Padmarao.Begari@microchip.com>>
> >      > *Cc:* Claudiu Beznea - M18063 <Claudiu.Beznea@microchip.com
> >     <mailto:Claudiu.Beznea@microchip.com>>;
> >      > joe.hershberger at ni.com <mailto:joe.hershberger@ni.com>
> >     <joe.hershberger at ni.com <mailto:joe.hershberger@ni.com>>;
> >     u-boot at lists.denx.de <mailto:u-boot@lists.denx.de>
> >      > <u-boot at lists.denx.de <mailto:u-boot@lists.denx.de>>
> >      > *Subject:* Re: [PATCH 1/6] net: macb: use dummy descriptor for
> RBQP
> >      > On 03.12.2020 11:25, Claudiu Beznea wrote:
> >      >> In case of multiple queues on RX side the queue scheduler
> >      >> will try to use all the available configured queues (with
> >      >> descriptors having TX_USED bit cleared). If at least one RBQP
> >      >> points to a descriptor with a valid used bit configuration then
> >      >> the reception may block as this may point to any memory. To avoid
> >      >> this scenario all the queues (except queue zero) were disabled by
> >      >> setting DMA descriptors with used bit set on proper RBQP. The
> driver
> >      >> anyway uses only queue 0 for TX/RX.
> >      >>
> >      >> Signed-off-by: Claudiu Beznea <claudiu.beznea@microchip.com
> >     <mailto:claudiu.beznea@microchip.com>>
> >      >> ---
> >      >
> >      > Hi Anup, Bin, Padmarao,
> >      >
> >      > I noticed on the mailing list that you have been actively working
> and
> >      > testing the Macb driver on various platforms, we have this series
> >      > outstanding and I want to make sure that it does not break
> >     anything on
> >      > your side, so it would be appreciated if you could have a look or
> >     test
> >      > it before it goes into master branch.
> >      >
> >      > Thanks !
> >      > Eugen
> >      >
> >      >
> >      >>   drivers/net/macb.c | 4 +++-
> >      >>   drivers/net/macb.h | 2 ++
> >      >>   2 files changed, 5 insertions(+), 1 deletion(-)
> >      >>
> >      >> diff --git a/drivers/net/macb.c b/drivers/net/macb.c
> >      >> index b80a259ff757..836eb85ec96a 100644
> >      >> --- a/drivers/net/macb.c
> >      >> +++ b/drivers/net/macb.c
> >      >> @@ -732,8 +732,10 @@ static int gmac_init_multi_queues(struct
> >     macb_device *macb)
> >      >>        flush_dcache_range(macb->dummy_desc_dma,
> >     macb->dummy_desc_dma +
> >      >>                        ALIGN(MACB_TX_DUMMY_DMA_DESC_SIZE,
> >     PKTALIGN));
> >      >>
> >      >> -     for (i = 1; i < num_queues; i++)
> >      >> +     for (i = 1; i < num_queues; i++) {
> >      >>                gem_writel_queue_TBQP(macb, macb->dummy_desc_dma,
> >     i - 1);
> >      >> +             gem_writel_queue_RBQP(macb, macb->dummy_desc_dma,
> >     i - 1);
> >      >> +     }
> >      >>
> >      >>        return 0;
> >      >>   }
> >      >> diff --git a/drivers/net/macb.h b/drivers/net/macb.h
> >      >> index 9b16383eba46..28c7fe306883 100644
> >      >> --- a/drivers/net/macb.h
> >      >> +++ b/drivers/net/macb.h
> >      >> @@ -768,5 +768,7 @@
> >      >>   #define GEM_RX_CSUM_CHECKED_MASK            2
> >      >>   #define gem_writel_queue_TBQP(port, value, queue_num)       \
> >      >>        writel((value), (port)->regs + GEM_TBQP(queue_num))
> >      >> +#define gem_writel_queue_RBQP(port, value, queue_num)        \
> >      >> +     writel((value), (port)->regs + GEM_RBQP(queue_num))
> >      >>
> >      >>   #endif /* __DRIVERS_MACB_H__ */
> >      >>
> >      >
> >
>
>

^ permalink raw reply	[flat|nested] 16+ messages in thread
* [PATCH 1/6] net: macb: use dummy descriptor for RBQP
  2021-01-15 12:26             ` Padmarao Begari
@ 2021-01-15 12:42               ` Eugen.Hristev at microchip.com
  0 siblings, 0 replies; 16+ messages in thread
From: Eugen.Hristev at microchip.com @ 2021-01-15 12:42 UTC (permalink / raw)
  To: u-boot

On 15.01.2021 14:26, Padmarao Begari wrote:
> Hi Eugen,
> 
> On Fri, Jan 15, 2021 at 1:34 PM <Eugen.Hristev@microchip.com 
> <mailto:Eugen.Hristev@microchip.com>> wrote:
> 
>     On 15.01.2021 06:02, Padmarao Begari wrote:
>      > Hi Eugen,
>      >
>      > On Thu, Jan 14, 2021 at 4:50 PM <Eugen.Hristev@microchip.com
>     <mailto:Eugen.Hristev@microchip.com>
>      > <mailto:Eugen.Hristev@microchip.com
>     <mailto:Eugen.Hristev@microchip.com>>> wrote:
>      >
>      >? ? ?On 17.12.2020 07:22, Padmarao Begari - I30397 wrote:
>      >? ? ? > Hi Eugen,
>      >? ? ? >
>      >? ? ? > This series of patches break my side of work(patches) so
>     you need to
>      >? ? ? > create patches after my patches are going into master branch
>      >? ? ?because my
>      >? ? ? > patches are already reviewed and tested.
>      >
>      >? ? ?Hi,
>      >
>      >? ? ?Could you please detail the breakage ?
>      >
>      >
>      > The breakage is the fdt relocation disabled in the board environment
>      > variables so I have removed it and enabled fdt relocation in
>     PATCH v9.
> 
>     Maybe you misunderstand my question. I was asking about the sama7g5
>     macb
>     series, which you claimed that breaks your current patch set.
>     This is a link to the series :
>     https://patchwork.ozlabs.org/project/uboot/list/?series=218367
> 
>     Since you claimed that this series breaks your series, I am asking what
>     exactly is the breakage. How does the fdt relocation in your board
>     environment has anything to do with macb and these patches which are
>     not
>     applied ?
> 
> 
> My mistake, misunderstood your question,
> Yes the fdt relocation has nothing to do with the macb.
> We both are adding a member into struct mac_config, a dummy descriptor 
> for?RBQP and my changes are both 32-bit and 64-bit DMA.

Okay, so, could you please tell me why you told us that our sama7g5 
series breaks your solarfire SoC series ?
It would be good for both of us if you could test our sama7g5 series on 
top of your patches, on your platform, such that we know that we do not 
affect anything on your board.

Thanks again,
Eugen

> 
> Regards
> Padmarao
> 
>     Thanks,
>     Eugen
> 
>      >
>      > Regards
>      > Padmarao
>      >
>      >? ? ?I saw a pull request with your patches that was NAK-ed, if
>     your two
>      >? ? ?macb
>      >? ? ?patches are tested and reviewed I could apply them to the
>     atmel tree as
>      >? ? ?well and send them, if your PR is delayed. But we are
>     interested to
>      >? ? ?have
>      >? ? ?our sama7g5 series pushed as well, so we need to know if it's
>     ok on
>      >? ? ?your
>      >? ? ?side, and what is wrong with the sama7g5 series.
>      >
>      >? ? ?Thanks!
>      >? ? ?Eugen
>      >? ? ? >
>      >? ? ? > Regards
>      >? ? ? > Padmarao
>      >? ? ? >
>      >   
>      ?------------------------------------------------------------------------
>      >? ? ? > *From:* Eugen Hristev - M18282
>     <Eugen.Hristev at microchip.com <mailto:Eugen.Hristev@microchip.com>
>      >? ? ?<mailto:Eugen.Hristev@microchip.com
>     <mailto:Eugen.Hristev@microchip.com>>>
>      >? ? ? > *Sent:* Wednesday, December 16, 2020 12:24 PM
>      >? ? ? > *To:* anup.patel at wdc.com <mailto:anup.patel@wdc.com>
>     <mailto:anup.patel at wdc.com <mailto:anup.patel@wdc.com>>
>      >? ? ?<anup.patel at wdc.com <mailto:anup.patel@wdc.com>
>     <mailto:anup.patel at wdc.com <mailto:anup.patel@wdc.com>>>;
>      > bin.meng at windriver.com <mailto:bin.meng@windriver.com>
>     <mailto:bin.meng at windriver.com <mailto:bin.meng@windriver.com>>
>      >? ? ? > <bin.meng at windriver.com <mailto:bin.meng@windriver.com>
>     <mailto:bin.meng at windriver.com <mailto:bin.meng@windriver.com>>>;
>      >? ? ?Padmarao Begari - I30397
>      >? ? ? > <Padmarao.Begari@microchip.com
>     <mailto:Padmarao.Begari@microchip.com>
>      >? ? ?<mailto:Padmarao.Begari@microchip.com
>     <mailto:Padmarao.Begari@microchip.com>>>
>      >? ? ? > *Cc:* Claudiu Beznea - M18063
>     <Claudiu.Beznea at microchip.com <mailto:Claudiu.Beznea@microchip.com>
>      >? ? ?<mailto:Claudiu.Beznea@microchip.com
>     <mailto:Claudiu.Beznea@microchip.com>>>;
>      >? ? ? > joe.hershberger at ni.com <mailto:joe.hershberger@ni.com>
>     <mailto:joe.hershberger at ni.com <mailto:joe.hershberger@ni.com>>
>      >? ? ?<joe.hershberger at ni.com <mailto:joe.hershberger@ni.com>
>     <mailto:joe.hershberger at ni.com <mailto:joe.hershberger@ni.com>>>;
>      > u-boot at lists.denx.de <mailto:u-boot@lists.denx.de>
>     <mailto:u-boot at lists.denx.de <mailto:u-boot@lists.denx.de>>
>      >? ? ? > <u-boot at lists.denx.de <mailto:u-boot@lists.denx.de>
>     <mailto:u-boot at lists.denx.de <mailto:u-boot@lists.denx.de>>>
>      >? ? ? > *Subject:* Re: [PATCH 1/6] net: macb: use dummy descriptor
>     for RBQP
>      >? ? ? > On 03.12.2020 11:25, Claudiu Beznea wrote:
>      >? ? ? >> In case of multiple queues on RX side the queue scheduler
>      >? ? ? >> will try to use all the available configured queues (with
>      >? ? ? >> descriptors having TX_USED bit cleared). If at least one RBQP
>      >? ? ? >> points to a descriptor with a valid used bit
>     configuration then
>      >? ? ? >> the reception may block as this may point to any memory.
>     To avoid
>      >? ? ? >> this scenario all the queues (except queue zero) were
>     disabled by
>      >? ? ? >> setting DMA descriptors with used bit set on proper RBQP.
>     The driver
>      >? ? ? >> anyway uses only queue 0 for TX/RX.
>      >? ? ? >>
>      >? ? ? >> Signed-off-by: Claudiu Beznea
>     <claudiu.beznea at microchip.com <mailto:claudiu.beznea@microchip.com>
>      >? ? ?<mailto:claudiu.beznea@microchip.com
>     <mailto:claudiu.beznea@microchip.com>>>
>      >? ? ? >> ---
>      >? ? ? >
>      >? ? ? > Hi Anup, Bin, Padmarao,
>      >? ? ? >
>      >? ? ? > I noticed on the mailing list that you have been actively
>     working and
>      >? ? ? > testing the Macb driver on various platforms, we have this
>     series
>      >? ? ? > outstanding and I want to make sure that it does not break
>      >? ? ?anything on
>      >? ? ? > your side, so it would be appreciated if you could have a
>     look or
>      >? ? ?test
>      >? ? ? > it before it goes into master branch.
>      >? ? ? >
>      >? ? ? > Thanks !
>      >? ? ? > Eugen
>      >? ? ? >
>      >? ? ? >
>      >? ? ? >>?? drivers/net/macb.c | 4 +++-
>      >? ? ? >>?? drivers/net/macb.h | 2 ++
>      >? ? ? >>?? 2 files changed, 5 insertions(+), 1 deletion(-)
>      >? ? ? >>
>      >? ? ? >> diff --git a/drivers/net/macb.c b/drivers/net/macb.c
>      >? ? ? >> index b80a259ff757..836eb85ec96a 100644
>      >? ? ? >> --- a/drivers/net/macb.c
>      >? ? ? >> +++ b/drivers/net/macb.c
>      >? ? ? >> @@ -732,8 +732,10 @@ static int gmac_init_multi_queues(struct
>      >? ? ?macb_device *macb)
>      >? ? ? >>??????? flush_dcache_range(macb->dummy_desc_dma,
>      >? ? ?macb->dummy_desc_dma +
>      >? ? ? >>??????????????????????? ALIGN(MACB_TX_DUMMY_DMA_DESC_SIZE,
>      >? ? ?PKTALIGN));
>      >? ? ? >>
>      >? ? ? >> -???? for (i = 1; i < num_queues; i++)
>      >? ? ? >> +???? for (i = 1; i < num_queues; i++) {
>      >? ? ? >>??????????????? gem_writel_queue_TBQP(macb,
>     macb->dummy_desc_dma,
>      >? ? ?i - 1);
>      >? ? ? >> +???????????? gem_writel_queue_RBQP(macb,
>     macb->dummy_desc_dma,
>      >? ? ?i - 1);
>      >? ? ? >> +???? }
>      >? ? ? >>
>      >? ? ? >>??????? return 0;
>      >? ? ? >>?? }
>      >? ? ? >> diff --git a/drivers/net/macb.h b/drivers/net/macb.h
>      >? ? ? >> index 9b16383eba46..28c7fe306883 100644
>      >? ? ? >> --- a/drivers/net/macb.h
>      >? ? ? >> +++ b/drivers/net/macb.h
>      >? ? ? >> @@ -768,5 +768,7 @@
>      >? ? ? >>?? #define GEM_RX_CSUM_CHECKED_MASK??????????? 2
>      >? ? ? >>?? #define gem_writel_queue_TBQP(port, value,
>     queue_num)?????? \
>      >? ? ? >>??????? writel((value), (port)->regs + GEM_TBQP(queue_num))
>      >? ? ? >> +#define gem_writel_queue_RBQP(port, value,
>     queue_num)??????? \
>      >? ? ? >> +???? writel((value), (port)->regs + GEM_RBQP(queue_num))
>      >? ? ? >>
>      >? ? ? >>?? #endif /* __DRIVERS_MACB_H__ */
>      >? ? ? >>
>      >? ? ? >
>      >
> 

^ permalink raw reply	[flat|nested] 16+ messages in thread
end of thread, other threads:[~2021-01-15 12:42 UTC | newest]

Thread overview: 16+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-12-03  9:25 [PATCH 0/6] add support for sama7g5 ethernet interfaces Claudiu Beznea
2020-12-03  9:25 ` [PATCH 1/6] net: macb: use dummy descriptor for RBQP Claudiu Beznea
2020-12-16  6:54   ` Eugen.Hristev at microchip.com
2020-12-16  7:17     ` Bin Meng
2020-12-16  8:29       ` Eugen.Hristev at microchip.com
2020-12-17  5:22     ` Padmarao.Begari at microchip.com
2021-01-14 11:19       ` Eugen.Hristev at microchip.com
2021-01-15  4:02         ` Padmarao Begari
2021-01-15  8:04           ` Eugen.Hristev at microchip.com
2021-01-15 12:26             ` Padmarao Begari
2021-01-15 12:42               ` Eugen.Hristev at microchip.com
2020-12-03  9:25 ` [PATCH 2/6] net: macb: add user io config data structure Claudiu Beznea
2020-12-03  9:25 ` [PATCH 3/6] net: macb: check clk_set_rate return value to be negative Claudiu Beznea
2020-12-03  9:25 ` [PATCH 4/6] net: macb: add support for sama7g5 gmac Claudiu Beznea
2020-12-03  9:25 ` [PATCH 5/6] net: macb: add support for sama7g5 emac Claudiu Beznea
2020-12-03  9:25 ` [PATCH 6/6] net: macb: take into account all RGMII interface types Claudiu Beznea

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.