Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1274808 > unrolled thread

[PATCH 00/13] mvneta Buffer Management and enhancements

Back to article view | Back to linux.kernel

Contents

  [PATCH 00/13] mvneta Buffer Management and enhancements Marcin Wojtas <mw@semihalf.com> - 2015-11-22 09:00 +0100
    [PATCH 13/13] ARM: mvebu: enable buffer manager support on Armada XP boards Marcin Wojtas <mw@semihalf.com> - 2015-11-22 09:00 +0100
    [PATCH 04/13] net: mvneta: enable suspend/resume support Marcin Wojtas <mw@semihalf.com> - 2015-11-22 09:00 +0100
      Re: [PATCH 04/13] net: mvneta: enable suspend/resume support Gregory CLEMENT <gregory.clement@free-electrons.com> - 2015-11-25 19:40 +0100
        Re: [PATCH 04/13] net: mvneta: enable suspend/resume support Marcin Wojtas <mw@semihalf.com> - 2015-11-26 18:40 +0100
    [PATCH 12/13] ARM: mvebu: add buffer manager nodes to armada-xp.dtsi Marcin Wojtas <mw@semihalf.com> - 2015-11-22 09:00 +0100
    [PATCH 01/13] net: mvneta: add configuration for MBUS windows access protection Marcin Wojtas <mw@semihalf.com> - 2015-11-22 09:00 +0100
      Re: [PATCH 01/13] net: mvneta: add configuration for MBUS windows access protection Gregory CLEMENT <gregory.clement@free-electrons.com> - 2015-11-25 19:20 +0100
    [PATCH 11/13] ARM: mvebu: enable buffer manager support on Armada 38x boards Marcin Wojtas <mw@semihalf.com> - 2015-11-22 09:00 +0100
    [PATCH 07/13] bus: mvebu-mbus: provide api for obtaining IO and DRAM window information Marcin Wojtas <mw@semihalf.com> - 2015-11-22 09:00 +0100
      Re: [PATCH 07/13] bus: mvebu-mbus: provide api for obtaining IO and DRAM window information Arnd Bergmann <arnd@arndb.de> - 2015-11-22 21:10 +0100
        Re: [PATCH 07/13] bus: mvebu-mbus: provide api for obtaining IO and  DRAM window information Marcin Wojtas <mw@semihalf.com> - 2015-11-22 22:30 +0100
          Re: [PATCH 07/13] bus: mvebu-mbus: provide api for obtaining IO and DRAM window information Arnd Bergmann <arnd@arndb.de> - 2015-11-23 18:00 +0100
    Re: [PATCH 00/13] mvneta Buffer Management and enhancements Arnd Bergmann <arnd@arndb.de> - 2015-11-22 21:10 +0100
      Re: [PATCH 00/13] mvneta Buffer Management and enhancements Marcin Wojtas <mw@semihalf.com> - 2015-11-22 22:40 +0100
    Re: [PATCH 00/13] mvneta Buffer Management and enhancements David Miller <davem@davemloft.net> - 2015-11-24 17:30 +0100
      Re: [PATCH 00/13] mvneta Buffer Management and enhancements Marcin Wojtas <mw@semihalf.com> - 2015-11-24 17:50 +0100
    Re: [PATCH 00/13] mvneta Buffer Management and enhancements Florian Fainelli <f.fainelli@gmail.com> - 2015-11-25 19:40 +0100
      Re: [PATCH 00/13] mvneta Buffer Management and enhancements Marcin Wojtas <mw@semihalf.com> - 2015-11-29 14:30 +0100
        Re: [PATCH 00/13] mvneta Buffer Management and enhancements David Miller <davem@davemloft.net> - 2015-11-30 03:10 +0100
          Re: [PATCH 00/13] mvneta Buffer Management and enhancements Marcin Wojtas <mw@semihalf.com> - 2015-11-30 15:20 +0100

Page 1 of 2  [1] 2  Next page →

#1274808 — [PATCH 00/13] mvneta Buffer Management and enhancements

Hi,

Hereby I submit a patchset that introduces various fixes and support
for new features and enhancements to the mvneta driver:

1. First three patches are minimal fixes, stable-CC'ed.

2. Suspend to ram ('s2ram') support. Due to some stability problems
Thomas Petazzoni's patches did not get merged yet, but I used them for
verification. Contrary to wfi mode ('standby' - linux does not
differentiate between them, so same routines are used) all registers'
contents are lost due to power down, so the configuration has to be
fully reconstructed during resume.

3. Optimisations - concatenating TX descriptors' flush, basing on
xmit_more support and combined approach for finalizing egress processing.
Thanks to HR timer buffers can be released with small latency, which is
good for low transfer and small queues. Along with the timer, coalescing
irqs are used, whose threshold could be increased back to 15.

4. Buffer manager (BM) support with two preparatory commits. As it is a
separate block, common for all network ports, a new driver is introduced,
which configures it and exposes API to the main network driver. It is
throughly described in binding documentation and commit log. Please note,
that enabling per-port BM usage is done using phandle and the data passed
in mvneta_bm_probe. It is designed for usage of on-demand device probe
and dev_set/get_drvdata, however it's awaiting merge to linux-next.
Therefore, deferring probe is not used - if something goes wrong (same
in case of errors during changing MTU or suspend/resume cycle) mvneta
driver falls back to software buffer management and works in a regular way.

Known issues:
- problems with obtaining all mapped buffers from internal SRAM, when
destroying the buffer pointer pool
- problems with unmapping chunk of SRAM during driver removal
Above do not have an impact on the operation, as they are called during
driver removal or in error path.

5. Enable BM on Armada XP and 38X development boards - those ones and
A370 I could check on my own. In all cases they survived night-long
linerate iperf. Also tests were performed with A388 SoC working as a
network bridge between two packet generators. They showed increase of
maximum processed 64B packets by ~20k (~555k packets with BM enabled
vs ~535 packets without BM). Also when pushing 1500B-packets with a
line rate achieved, CPU load decreased from around 25% without BM vs
18-20% with BM.

I'm looking forward to any remarks and comments.

Best regards,
Marcin Wojtas

Marcin Wojtas (12):
  net: mvneta: add configuration for MBUS windows access protection
  net: mvneta: enable IP checksum with jumbo frames for Armada 38x on
    Port0
  net: mvneta: fix bit assignment in MVNETA_RXQ_CONFIG_REG
  net: mvneta: enable suspend/resume support
  net: mvneta: enable mixed egress processing using HR timer
  bus: mvebu-mbus: provide api for obtaining IO and DRAM window
    information
  ARM: mvebu: enable SRAM support in mvebu_v7_defconfig
  net: mvneta: bm: add support for hardware buffer management
  ARM: mvebu: add buffer manager nodes to armada-38x.dtsi
  ARM: mvebu: enable buffer manager support on Armada 38x boards
  ARM: mvebu: add buffer manager nodes to armada-xp.dtsi
  ARM: mvebu: enable buffer manager support on Armada XP boards

Simon Guinot (1):
  net: mvneta: add xmit_more support

 .../bindings/net/marvell-armada-370-neta.txt       |  19 +-
 .../devicetree/bindings/net/marvell-neta-bm.txt    |  49 ++
 arch/arm/boot/dts/armada-385-db-ap.dts             |  20 +-
 arch/arm/boot/dts/armada-388-db.dts                |  17 +-
 arch/arm/boot/dts/armada-388-gp.dts                |  17 +-
 arch/arm/boot/dts/armada-38x.dtsi                  |  20 +-
 arch/arm/boot/dts/armada-xp-db.dts                 |  19 +-
 arch/arm/boot/dts/armada-xp-gp.dts                 |  19 +-
 arch/arm/boot/dts/armada-xp.dtsi                   |  18 +
 arch/arm/configs/mvebu_v7_defconfig                |   1 +
 drivers/bus/mvebu-mbus.c                           |  51 ++
 drivers/net/ethernet/marvell/Kconfig               |  14 +
 drivers/net/ethernet/marvell/Makefile              |   1 +
 drivers/net/ethernet/marvell/mvneta.c              | 660 +++++++++++++++++++--
 drivers/net/ethernet/marvell/mvneta_bm.c           | 642 ++++++++++++++++++++
 drivers/net/ethernet/marvell/mvneta_bm.h           | 171 ++++++
 include/linux/mbus.h                               |   3 +
 17 files changed, 1677 insertions(+), 64 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/net/marvell-neta-bm.txt
 create mode 100644 drivers/net/ethernet/marvell/mvneta_bm.c
 create mode 100644 drivers/net/ethernet/marvell/mvneta_bm.h

-- 
1.8.3.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [next] | [standalone]

#1274809 — [PATCH 13/13] ARM: mvebu: enable buffer manager support on Armada XP boards

Since mvneta driver supports using hardware buffer management (BM), in
order to use it, board files have to be adjusted accordingly. This commit
enables BM on AXP-DB and AXP-GP in same manner - because number of ports
on those boards is the same as number of possible pools, each port is
supposed to use single pool for all kind of packets.

Moreover appropriate entry is added to 'soc' node ranges, as well as "okay"
status for 'bm' and 'bm-bppi' (internal SRAM) nodes.

Signed-off-by: Marcin Wojtas <mw@semihalf.com>
---
 arch/arm/boot/dts/armada-xp-db.dts | 19 ++++++++++++++++++-
 arch/arm/boot/dts/armada-xp-gp.dts | 19 ++++++++++++++++++-
 2 files changed, 36 insertions(+), 2 deletions(-)

diff --git a/arch/arm/boot/dts/armada-xp-db.dts b/arch/arm/boot/dts/armada-xp-db.dts
index f774101..3065730 100644
--- a/arch/arm/boot/dts/armada-xp-db.dts
+++ b/arch/arm/boot/dts/armada-xp-db.dts
@@ -77,7 +77,8 @@
 			  MBUS_ID(0x01, 0x1d) 0 0 0xfff00000 0x100000
 			  MBUS_ID(0x01, 0x2f) 0 0 0xf0000000 0x1000000
 			  MBUS_ID(0x09, 0x09) 0 0 0xf8100000 0x10000
-			  MBUS_ID(0x09, 0x05) 0 0 0xf8110000 0x10000>;
+			  MBUS_ID(0x09, 0x05) 0 0 0xf8110000 0x10000
+			  MBUS_ID(0x0c, 0x04) 0 0 0xf1200000 0x100000>;
 
 		devbus-bootcs {
 			status = "okay";
@@ -181,21 +182,33 @@
 				status = "okay";
 				phy = <&phy0>;
 				phy-mode = "rgmii-id";
+				buffer-manager = <&bm>;
+				bm,pool-long = <0>;
 			};
 			ethernet@74000 {
 				status = "okay";
 				phy = <&phy1>;
 				phy-mode = "rgmii-id";
+				buffer-manager = <&bm>;
+				bm,pool-long = <1>;
 			};
 			ethernet@30000 {
 				status = "okay";
 				phy = <&phy2>;
 				phy-mode = "sgmii";
+				buffer-manager = <&bm>;
+				bm,pool-long = <2>;
 			};
 			ethernet@34000 {
 				status = "okay";
 				phy = <&phy3>;
 				phy-mode = "sgmii";
+				buffer-manager = <&bm>;
+				bm,pool-long = <3>;
+			};
+
+			bm@c0000 {
+				status = "okay";
 			};
 
 			mvsdio@d4000 {
@@ -230,5 +243,9 @@
 				};
 			};
 		};
+
+		bm-bppi {
+			status = "okay";
+		};
 	};
 };
diff --git a/arch/arm/boot/dts/armada-xp-gp.dts b/arch/arm/boot/dts/armada-xp-gp.dts
index 4878d73..a1ded01 100644
--- a/arch/arm/boot/dts/armada-xp-gp.dts
+++ b/arch/arm/boot/dts/armada-xp-gp.dts
@@ -96,7 +96,8 @@
 			  MBUS_ID(0x01, 0x1d) 0 0 0xfff00000 0x100000
 			  MBUS_ID(0x01, 0x2f) 0 0 0xf0000000 0x1000000
 			  MBUS_ID(0x09, 0x09) 0 0 0xf8100000 0x10000
-			  MBUS_ID(0x09, 0x05) 0 0 0xf8110000 0x10000>;
+			  MBUS_ID(0x09, 0x05) 0 0 0xf8110000 0x10000
+			  MBUS_ID(0x0c, 0x04) 0 0 0xf1200000 0x100000>;
 
 		devbus-bootcs {
 			status = "okay";
@@ -196,21 +197,29 @@
 				status = "okay";
 				phy = <&phy0>;
 				phy-mode = "qsgmii";
+				buffer-manager = <&bm>;
+				bm,pool-long = <0>;
 			};
 			ethernet@74000 {
 				status = "okay";
 				phy = <&phy1>;
 				phy-mode = "qsgmii";
+				buffer-manager = <&bm>;
+				bm,pool-long = <1>;
 			};
 			ethernet@30000 {
 				status = "okay";
 				phy = <&phy2>;
 				phy-mode = "qsgmii";
+				buffer-manager = <&bm>;
+				bm,pool-long = <2>;
 			};
 			ethernet@34000 {
 				status = "okay";
 				phy = <&phy3>;
 				phy-mode = "qsgmii";
+				buffer-manager = <&bm>;
+				bm,pool-long = <3>;
 			};
 
 			/* Front-side USB slot */
@@ -235,6 +244,10 @@
 				};
 			};
 
+			bm@c0000 {
+				status = "okay";
+			};
+
 			nand@d0000 {
 				status = "okay";
 				num-cs = <1>;
@@ -243,5 +256,9 @@
 				nand-on-flash-bbt;
 			};
 		};
+
+		bm-bppi {
+			status = "okay";
+		};
 	};
 };
-- 
1.8.3.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1274810 — [PATCH 04/13] net: mvneta: enable suspend/resume support

This commit introduces suspend/resume routines used for both in 'standby'
and 'mem' modes. For the latter, in which registers' contents are lost,
following steps are performed:
* in suspend - update port statistics and, if interface is running,
  detach netif, clean the queues, disable cpu notifier, shutdown
  interface and reset port's link status;
* in resume, for all interfaces, set default configuration of the port and
  MBUS windows;
* in resume, in case the interface is running, enable accepting packets in
  legacy parser, power up the port, register cpu notifier and attach netif.

Signed-off-by: Marcin Wojtas <mw@semihalf.com>
---
 drivers/net/ethernet/marvell/mvneta.c | 70 +++++++++++++++++++++++++++++++++++
 1 file changed, 70 insertions(+)

diff --git a/drivers/net/ethernet/marvell/mvneta.c b/drivers/net/ethernet/marvell/mvneta.c
index d12b8c6..f079b13 100644
--- a/drivers/net/ethernet/marvell/mvneta.c
+++ b/drivers/net/ethernet/marvell/mvneta.c
@@ -3442,6 +3442,72 @@ static int mvneta_remove(struct platform_device *pdev)
 	return 0;
 }
 
+#ifdef CONFIG_PM_SLEEP
+static int mvneta_suspend(struct platform_device *pdev, pm_message_t state)
+{
+	struct net_device *dev = platform_get_drvdata(pdev);
+	struct mvneta_port *pp = netdev_priv(dev);
+
+	mvneta_ethtool_update_stats(pp);
+
+	if (!netif_running(dev))
+		return 0;
+
+	netif_device_detach(dev);
+
+	mvneta_stop_dev(pp);
+	unregister_cpu_notifier(&pp->cpu_notifier);
+	mvneta_cleanup_rxqs(pp);
+	mvneta_cleanup_txqs(pp);
+
+	/* Reset link status */
+	pp->link = 0;
+	pp->duplex = -1;
+	pp->speed = 0;
+
+	return 0;
+}
+
+static int mvneta_resume(struct platform_device *pdev)
+{
+	const struct mbus_dram_target_info *dram_target_info;
+	struct net_device *dev = platform_get_drvdata(pdev);
+	struct mvneta_port *pp = netdev_priv(dev);
+	int ret;
+
+	mvneta_defaults_set(pp);
+	mvneta_port_power_up(pp, pp->phy_interface);
+
+	dram_target_info = mv_mbus_dram_info();
+	if (dram_target_info)
+		mvneta_conf_mbus_windows(pp, dram_target_info);
+
+	if (!netif_running(dev))
+		return 0;
+
+	ret = mvneta_setup_rxqs(pp);
+	if (ret) {
+		netdev_err(dev, "unable to setup rxqs after resume\n");
+		return ret;
+	}
+
+	ret = mvneta_setup_txqs(pp);
+	if (ret) {
+		netdev_err(dev, "unable to setup txqs after resume\n");
+		return ret;
+	}
+
+	mvneta_set_rx_mode(dev);
+	mvneta_percpu_elect(pp);
+	register_cpu_notifier(&pp->cpu_notifier);
+	mvneta_start_dev(pp);
+
+	netif_device_attach(dev);
+
+	return 0;
+}
+#endif /* CONFIG_PM_SLEEP */
+
 static const struct of_device_id mvneta_match[] = {
 	{ .compatible = "marvell,armada-370-neta" },
 	{ .compatible = "marvell,armada-xp-neta" },
@@ -3452,6 +3518,10 @@ MODULE_DEVICE_TABLE(of, mvneta_match);
 static struct platform_driver mvneta_driver = {
 	.probe = mvneta_probe,
 	.remove = mvneta_remove,
+#ifdef CONFIG_PM_SLEEP
+	.suspend = mvneta_suspend,
+	.resume = mvneta_resume,
+#endif
 	.driver = {
 		.name = MVNETA_DRIVER_NAME,
 		.of_match_table = mvneta_match,
-- 
1.8.3.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1277690 — Re: [PATCH 04/13] net: mvneta: enable suspend/resume support

Hi Marcin,
 
 On dim., nov. 22 2015, Marcin Wojtas <mw@semihalf.com> wrote:

> This commit introduces suspend/resume routines used for both in 'standby'
> and 'mem' modes. For the latter, in which registers' contents are lost,
> following steps are performed:
> * in suspend - update port statistics and, if interface is running,
>   detach netif, clean the queues, disable cpu notifier, shutdown
>   interface and reset port's link status;
> * in resume, for all interfaces, set default configuration of the port and
>   MBUS windows;
> * in resume, in case the interface is running, enable accepting packets in
>   legacy parser, power up the port, register cpu notifier and attach
> netif.

I don't have the hardware to use suspend to RAM on Armada XP but at
least in standby the network continue to work on wakeup.

>
> Signed-off-by: Marcin Wojtas <mw@semihalf.com>
> ---
>  drivers/net/ethernet/marvell/mvneta.c | 70 +++++++++++++++++++++++++++++++++++
>  1 file changed, 70 insertions(+)
>
> diff --git a/drivers/net/ethernet/marvell/mvneta.c b/drivers/net/ethernet/marvell/mvneta.c
> index d12b8c6..f079b13 100644
> --- a/drivers/net/ethernet/marvell/mvneta.c
> +++ b/drivers/net/ethernet/marvell/mvneta.c
> @@ -3442,6 +3442,72 @@ static int mvneta_remove(struct platform_device *pdev)
>  	return 0;
>  }
>  
> +#ifdef CONFIG_PM_SLEEP
> +static int mvneta_suspend(struct platform_device *pdev, pm_message_t state)
> +{
> +	struct net_device *dev = platform_get_drvdata(pdev);
> +	struct mvneta_port *pp = netdev_priv(dev);
> +
> +	mvneta_ethtool_update_stats(pp);
> +
> +	if (!netif_running(dev))
> +		return 0;
> +
> +	netif_device_detach(dev);
> +
> +	mvneta_stop_dev(pp);
> +	unregister_cpu_notifier(&pp->cpu_notifier);
> +	mvneta_cleanup_rxqs(pp);
> +	mvneta_cleanup_txqs(pp);
> +
> +	/* Reset link status */
> +	pp->link = 0;
> +	pp->duplex = -1;
> +	pp->speed = 0;
> +

Would it be possible to add a kind of mvneta_port_power_down(pp,
pp->phy_interface) here ? It would allow to save power in standby mode
too.

> +	return 0;
> +}
> +
> +static int mvneta_resume(struct platform_device *pdev)
> +{
> +	const struct mbus_dram_target_info *dram_target_info;
> +	struct net_device *dev = platform_get_drvdata(pdev);
> +	struct mvneta_port *pp = netdev_priv(dev);
> +	int ret;
> +
> +	mvneta_defaults_set(pp);
> +	mvneta_port_power_up(pp, pp->phy_interface);
> +
> +	dram_target_info = mv_mbus_dram_info();
> +	if (dram_target_info)
> +		mvneta_conf_mbus_windows(pp, dram_target_info);
> +
> +	if (!netif_running(dev))
> +		return 0;
> +
> +	ret = mvneta_setup_rxqs(pp);
> +	if (ret) {
> +		netdev_err(dev, "unable to setup rxqs after resume\n");
> +		return ret;
> +	}
> +
> +	ret = mvneta_setup_txqs(pp);
> +	if (ret) {
> +		netdev_err(dev, "unable to setup txqs after resume\n");
> +		return ret;
> +	}
> +
> +	mvneta_set_rx_mode(dev);
> +	mvneta_percpu_elect(pp);
> +	register_cpu_notifier(&pp->cpu_notifier);
> +	mvneta_start_dev(pp);
> +
> +	netif_device_attach(dev);
> +
> +	return 0;
> +}
> +#endif /* CONFIG_PM_SLEEP */
> +
>  static const struct of_device_id mvneta_match[] = {
>  	{ .compatible = "marvell,armada-370-neta" },
>  	{ .compatible = "marvell,armada-xp-neta" },
> @@ -3452,6 +3518,10 @@ MODULE_DEVICE_TABLE(of, mvneta_match);
>  static struct platform_driver mvneta_driver = {
>  	.probe = mvneta_probe,
>  	.remove = mvneta_remove,
> +#ifdef CONFIG_PM_SLEEP
> +	.suspend = mvneta_suspend,
> +	.resume = mvneta_resume,
> +#endif
>  	.driver = {
>  		.name = MVNETA_DRIVER_NAME,
>  		.of_match_table = mvneta_match,
> -- 
> 1.8.3.1
>

-- 
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1278367 — Re: [PATCH 04/13] net: mvneta: enable suspend/resume support

Hi Gregory,


>> +     /* Reset link status */
>> +     pp->link = 0;
>> +     pp->duplex = -1;
>> +     pp->speed = 0;
>> +
>
> Would it be possible to add a kind of mvneta_port_power_down(pp,
> pp->phy_interface) here ? It would allow to save power in standby mode
> too.
>

Sure, I'll try it.

Best regards,
Marcin
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1274811 — [PATCH 12/13] ARM: mvebu: add buffer manager nodes to armada-xp.dtsi

Armada XP network controller supports hardware buffer management (BM).
Since it is now enabled in mvneta driver, appropriate nodes can be added
to armada-xp.dtsi - for the actual common BM unit (bm@c0000) and its
internal SRAM (bm-bppi), which is used for indirect access to buffer
pointer ring residing in DRAM.

Pools - ports mapping, bm-bppi entry in 'soc' node's ranges and optional
parameters are supposed to be set in board files.

Signed-off-by: Marcin Wojtas <mw@semihalf.com>
---
 arch/arm/boot/dts/armada-xp.dtsi | 18 ++++++++++++++++++
 1 file changed, 18 insertions(+)

diff --git a/arch/arm/boot/dts/armada-xp.dtsi b/arch/arm/boot/dts/armada-xp.dtsi
index be23196..bd45936 100644
--- a/arch/arm/boot/dts/armada-xp.dtsi
+++ b/arch/arm/boot/dts/armada-xp.dtsi
@@ -253,6 +253,14 @@
 				marvell,crypto-sram-size = <0x800>;
 			};
 
+			bm: bm@c0000 {
+				compatible = "marvell,armada-380-neta-bm";
+				reg = <0xc0000 0xac>;
+				clocks = <&gateclk 13>;
+				internal-mem = <&bm_bppi>;
+				status = "disabled";
+			};
+
 			xor@f0900 {
 				compatible = "marvell,orion-xor";
 				reg = <0xF0900 0x100
@@ -291,6 +299,16 @@
 			#size-cells = <1>;
 			ranges = <0 MBUS_ID(0x09, 0x05) 0 0x800>;
 		};
+
+		bm_bppi: bm-bppi {
+			compatible = "mmio-sram";
+			reg = <MBUS_ID(0x0c, 0x04) 0 0x100000>;
+			ranges = <0 MBUS_ID(0x0c, 0x04) 0 0x100000>;
+			#address-cells = <1>;
+			#size-cells = <1>;
+			clocks = <&gateclk 13>;
+			status = "disabled";
+		};
 	};
 
 	clocks {
-- 
1.8.3.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1274812 — [PATCH 01/13] net: mvneta: add configuration for MBUS windows access protection

This commit adds missing configuration of MBUS windows access protection
in mvneta_conf_mbus_windows function - a dedicated variable for that
purpose remained there unused since v3.8 initial mvneta support. Because
of that the register contents were inherited from the bootloader.

Signed-off-by: Marcin Wojtas <mw@semihalf.com>
Cc: <stable@vger.kernel.org> # v3.8+
---
 drivers/net/ethernet/marvell/mvneta.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/net/ethernet/marvell/mvneta.c b/drivers/net/ethernet/marvell/mvneta.c
index e84c7f2..0f30aaa 100644
--- a/drivers/net/ethernet/marvell/mvneta.c
+++ b/drivers/net/ethernet/marvell/mvneta.c
@@ -62,6 +62,7 @@
 #define MVNETA_WIN_SIZE(w)                      (0x2204 + ((w) << 3))
 #define MVNETA_WIN_REMAP(w)                     (0x2280 + ((w) << 2))
 #define MVNETA_BASE_ADDR_ENABLE                 0x2290
+#define MVNETA_ACCESS_PROTECT_ENABLE		0x2294
 #define MVNETA_PORT_CONFIG                      0x2400
 #define      MVNETA_UNI_PROMISC_MODE            BIT(0)
 #define      MVNETA_DEF_RXQ(q)                  ((q) << 1)
@@ -3188,6 +3189,8 @@ static void mvneta_conf_mbus_windows(struct mvneta_port *pp,
 
 		win_enable &= ~(1 << i);
 		win_protect |= 3 << (2 * i);
+
+		mvreg_write(pp, MVNETA_ACCESS_PROTECT_ENABLE, win_protect);
 	}
 
 	mvreg_write(pp, MVNETA_BASE_ADDR_ENABLE, win_enable);
-- 
1.8.3.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1277676 — Re: [PATCH 01/13] net: mvneta: add configuration for MBUS windows access protection

Hi Marcin,
 
 On dim., nov. 22 2015, Marcin Wojtas <mw@semihalf.com> wrote:

> This commit adds missing configuration of MBUS windows access protection
> in mvneta_conf_mbus_windows function - a dedicated variable for that
> purpose remained there unused since v3.8 initial mvneta support. Because
> of that the register contents were inherited from the bootloader.

It looks OK for me and at least after applying the driver continues
working :)

I guess you find it when you tested suspend to ram.

Reviewed-by: Gregory CLEMENT <gregory.clement@free-electrons.com>

Thanks,

Gregory


>
> Signed-off-by: Marcin Wojtas <mw@semihalf.com>
> Cc: <stable@vger.kernel.org> # v3.8+
> ---
>  drivers/net/ethernet/marvell/mvneta.c | 3 +++
>  1 file changed, 3 insertions(+)
>
> diff --git a/drivers/net/ethernet/marvell/mvneta.c b/drivers/net/ethernet/marvell/mvneta.c
> index e84c7f2..0f30aaa 100644
> --- a/drivers/net/ethernet/marvell/mvneta.c
> +++ b/drivers/net/ethernet/marvell/mvneta.c
> @@ -62,6 +62,7 @@
>  #define MVNETA_WIN_SIZE(w)                      (0x2204 + ((w) << 3))
>  #define MVNETA_WIN_REMAP(w)                     (0x2280 + ((w) << 2))
>  #define MVNETA_BASE_ADDR_ENABLE                 0x2290
> +#define MVNETA_ACCESS_PROTECT_ENABLE		0x2294
>  #define MVNETA_PORT_CONFIG                      0x2400
>  #define      MVNETA_UNI_PROMISC_MODE            BIT(0)
>  #define      MVNETA_DEF_RXQ(q)                  ((q) << 1)
> @@ -3188,6 +3189,8 @@ static void mvneta_conf_mbus_windows(struct mvneta_port *pp,
>  
>  		win_enable &= ~(1 << i);
>  		win_protect |= 3 << (2 * i);
> +
> +		mvreg_write(pp, MVNETA_ACCESS_PROTECT_ENABLE, win_protect);
>  	}
>  
>  	mvreg_write(pp, MVNETA_BASE_ADDR_ENABLE, win_enable);
> -- 
> 1.8.3.1
>

-- 
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1274813 — [PATCH 11/13] ARM: mvebu: enable buffer manager support on Armada 38x boards

Since mvneta driver supports using hardware buffer management (BM), in
order to use it, board files have to be adjusted accordingly. This commit
enables BM on:
* A385-DB-AP - each port has its own pool for long and common pool for
short packets,
* A388-DB - to each port unique 'short' and 'long' pools are mapped,
* A388-GP - same as above.

Moreover appropriate entry is added to 'soc' node ranges, as well as "okay"
status for 'bm' and 'bm-bppi' (internal SRAM) nodes.

Signed-off-by: Marcin Wojtas <mw@semihalf.com>
---
 arch/arm/boot/dts/armada-385-db-ap.dts | 20 +++++++++++++++++++-
 arch/arm/boot/dts/armada-388-db.dts    | 17 ++++++++++++++++-
 arch/arm/boot/dts/armada-388-gp.dts    | 17 ++++++++++++++++-
 3 files changed, 51 insertions(+), 3 deletions(-)

diff --git a/arch/arm/boot/dts/armada-385-db-ap.dts b/arch/arm/boot/dts/armada-385-db-ap.dts
index acd5b15..5f9451b 100644
--- a/arch/arm/boot/dts/armada-385-db-ap.dts
+++ b/arch/arm/boot/dts/armada-385-db-ap.dts
@@ -61,7 +61,8 @@
 		ranges = <MBUS_ID(0xf0, 0x01) 0 0xf1000000 0x100000
 			  MBUS_ID(0x01, 0x1d) 0 0xfff00000 0x100000
 			  MBUS_ID(0x09, 0x19) 0 0xf1100000 0x10000
-			  MBUS_ID(0x09, 0x15) 0 0xf1110000 0x10000>;
+			  MBUS_ID(0x09, 0x15) 0 0xf1110000 0x10000
+			  MBUS_ID(0x0c, 0x04) 0 0xf1200000 0x100000>;
 
 		internal-regs {
 			spi1: spi@10680 {
@@ -138,12 +139,18 @@
 				status = "okay";
 				phy = <&phy2>;
 				phy-mode = "sgmii";
+				buffer-manager = <&bm>;
+				bm,pool-long = <1>;
+				bm,pool-short = <3>;
 			};
 
 			ethernet@34000 {
 				status = "okay";
 				phy = <&phy1>;
 				phy-mode = "sgmii";
+				buffer-manager = <&bm>;
+				bm,pool-long = <2>;
+				bm,pool-short = <3>;
 			};
 
 			ethernet@70000 {
@@ -157,6 +164,13 @@
 				status = "okay";
 				phy = <&phy0>;
 				phy-mode = "rgmii-id";
+				buffer-manager = <&bm>;
+				bm,pool-long = <0>;
+				bm,pool-short = <3>;
+			};
+
+			bm@c8000 {
+				status = "okay";
 			};
 
 			nfc: flash@d0000 {
@@ -178,6 +192,10 @@
 			};
 		};
 
+		bm-bppi {
+			status = "okay";
+		};
+
 		pcie-controller {
 			status = "okay";
 
diff --git a/arch/arm/boot/dts/armada-388-db.dts b/arch/arm/boot/dts/armada-388-db.dts
index ff47af5..ea93ed7 100644
--- a/arch/arm/boot/dts/armada-388-db.dts
+++ b/arch/arm/boot/dts/armada-388-db.dts
@@ -66,7 +66,8 @@
 		ranges = <MBUS_ID(0xf0, 0x01) 0 0xf1000000 0x100000
 			  MBUS_ID(0x01, 0x1d) 0 0xfff00000 0x100000
 			  MBUS_ID(0x09, 0x19) 0 0xf1100000 0x10000
-			  MBUS_ID(0x09, 0x15) 0 0xf1110000 0x10000>;
+			  MBUS_ID(0x09, 0x15) 0 0xf1110000 0x10000
+			  MBUS_ID(0x0c, 0x04) 0 0xf1200000 0x100000>;
 
 		internal-regs {
 			spi@10600 {
@@ -99,6 +100,9 @@
 				status = "okay";
 				phy = <&phy1>;
 				phy-mode = "rgmii-id";
+				buffer-manager = <&bm>;
+				bm,pool-long = <2>;
+				bm,pool-short = <3>;
 			};
 
 			usb@58000 {
@@ -109,6 +113,9 @@
 				status = "okay";
 				phy = <&phy0>;
 				phy-mode = "rgmii-id";
+				buffer-manager = <&bm>;
+				bm,pool-long = <0>;
+				bm,pool-short = <1>;
 			};
 
 			mdio@72004 {
@@ -129,6 +136,10 @@
 				status = "okay";
 			};
 
+			bm@c8000 {
+				status = "okay";
+			};
+
 			flash@d0000 {
 				status = "okay";
 				num-cs = <1>;
@@ -169,6 +180,10 @@
 			};
 		};
 
+		bm-bppi {
+			status = "okay";
+		};
+
 		pcie-controller {
 			status = "okay";
 			/*
diff --git a/arch/arm/boot/dts/armada-388-gp.dts b/arch/arm/boot/dts/armada-388-gp.dts
index a633be3..0a3bd7f 100644
--- a/arch/arm/boot/dts/armada-388-gp.dts
+++ b/arch/arm/boot/dts/armada-388-gp.dts
@@ -60,7 +60,8 @@
 		ranges = <MBUS_ID(0xf0, 0x01) 0 0xf1000000 0x100000
 			  MBUS_ID(0x01, 0x1d) 0 0xfff00000 0x100000
 			  MBUS_ID(0x09, 0x19) 0 0xf1100000 0x10000
-			  MBUS_ID(0x09, 0x15) 0 0xf1110000 0x10000>;
+			  MBUS_ID(0x09, 0x15) 0 0xf1110000 0x10000
+			  MBUS_ID(0x0c, 0x04) 0 0xf1200000 0x100000>;
 
 		internal-regs {
 			spi@10600 {
@@ -133,6 +134,9 @@
 				status = "okay";
 				phy = <&phy1>;
 				phy-mode = "rgmii-id";
+				buffer-manager = <&bm>;
+				bm,pool-long = <2>;
+				bm,pool-short = <3>;
 			};
 
 			/* CON4 */
@@ -152,6 +156,9 @@
 				status = "okay";
 				phy = <&phy0>;
 				phy-mode = "rgmii-id";
+				buffer-manager = <&bm>;
+				bm,pool-long = <0>;
+				bm,pool-short = <1>;
 			};
 
 
@@ -186,6 +193,10 @@
 				};
 			};
 
+			bm@c8000 {
+				status = "okay";
+			};
+
 			sata@e0000 {
 				pinctrl-names = "default";
 				pinctrl-0 = <&sata2_pins>, <&sata3_pins>;
@@ -240,6 +251,10 @@
 			};
 		};
 
+		bm-bppi {
+			status = "okay";
+		};
+
 		pcie-controller {
 			status = "okay";
 			/*
-- 
1.8.3.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1274814 — [PATCH 07/13] bus: mvebu-mbus: provide api for obtaining IO and DRAM window information

This commit enables finding appropriate mbus window and obtaining its
target id and attribute for given physical address in two separate
routines, both for IO and DRAM windows. This functionality
is needed for Armada XP/38x Network Controller's Buffer Manager and
PnC configuration.

Signed-off-by: Marcin Wojtas <mw@semihalf.com>

[DRAM window information reference in LKv3.10]
Signed-off-by: Evan Wang <xswang@marvell.com>
---
 drivers/bus/mvebu-mbus.c | 51 ++++++++++++++++++++++++++++++++++++++++++++++++
 include/linux/mbus.h     |  3 +++
 2 files changed, 54 insertions(+)

diff --git a/drivers/bus/mvebu-mbus.c b/drivers/bus/mvebu-mbus.c
index c43c3d2..3d1c0c3 100644
--- a/drivers/bus/mvebu-mbus.c
+++ b/drivers/bus/mvebu-mbus.c
@@ -948,6 +948,57 @@ void mvebu_mbus_get_pcie_io_aperture(struct resource *res)
 	*res = mbus_state.pcie_io_aperture;
 }
 
+int mvebu_mbus_get_dram_win_info(phys_addr_t phyaddr, u8 *target, u8 *attr)
+{
+	const struct mbus_dram_target_info *dram;
+	int i;
+
+	/* Get dram info */
+	dram = mv_mbus_dram_info();
+	if (!dram) {
+		pr_err("missing DRAM information\n");
+		return -ENODEV;
+	}
+
+	/* Try to find matching DRAM window for phyaddr */
+	for (i = 0; i < dram->num_cs; i++) {
+		const struct mbus_dram_window *cs = dram->cs + i;
+
+		if (cs->base <= phyaddr && phyaddr <= (cs->base + cs->size)) {
+			*target = dram->mbus_dram_target_id;
+			*attr = cs->mbus_attr;
+			return 0;
+		}
+	}
+
+	pr_err("invalid dram address 0x%x\n", phyaddr);
+	return -EINVAL;
+}
+EXPORT_SYMBOL_GPL(mvebu_mbus_get_dram_win_info);
+
+int mvebu_mbus_get_io_win_info(phys_addr_t phyaddr, u32 *size, u8 *target,
+			       u8 *attr)
+{
+	int win;
+
+	for (win = 0; win < mbus_state.soc->num_wins; win++) {
+		u64 wbase;
+		int enabled;
+
+		mvebu_mbus_read_window(&mbus_state, win, &enabled, &wbase,
+				       size, target, attr, NULL);
+
+		if (!enabled)
+			continue;
+
+		if (wbase <= phyaddr && phyaddr <= wbase + *size)
+			return win;
+	}
+
+	return -EINVAL;
+}
+EXPORT_SYMBOL_GPL(mvebu_mbus_get_io_win_info);
+
 static __init int mvebu_mbus_debugfs_init(void)
 {
 	struct mvebu_mbus_state *s = &mbus_state;
diff --git a/include/linux/mbus.h b/include/linux/mbus.h
index 1f7bc63..ea34a86 100644
--- a/include/linux/mbus.h
+++ b/include/linux/mbus.h
@@ -69,6 +69,9 @@ static inline const struct mbus_dram_target_info *mv_mbus_dram_info_nooverlap(vo
 int mvebu_mbus_save_cpu_target(u32 *store_addr);
 void mvebu_mbus_get_pcie_mem_aperture(struct resource *res);
 void mvebu_mbus_get_pcie_io_aperture(struct resource *res);
+int mvebu_mbus_get_dram_win_info(phys_addr_t phyaddr, u8 *target, u8 *attr);
+int mvebu_mbus_get_io_win_info(phys_addr_t phyaddr, u32 *size, u8 *target,
+			       u8 *attr);
 int mvebu_mbus_add_window_remap_by_id(unsigned int target,
 				      unsigned int attribute,
 				      phys_addr_t base, size_t size,
-- 
1.8.3.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1274938 — Re: [PATCH 07/13] bus: mvebu-mbus: provide api for obtaining IO and DRAM window information

On Sunday 22 November 2015 08:53:53 Marcin Wojtas wrote:
> This commit enables finding appropriate mbus window and obtaining its
> target id and attribute for given physical address in two separate
> routines, both for IO and DRAM windows. This functionality
> is needed for Armada XP/38x Network Controller's Buffer Manager and
> PnC configuration.
> 
> Signed-off-by: Marcin Wojtas <mw@semihalf.com>
> 
> [DRAM window information reference in LKv3.10]
> Signed-off-by: Evan Wang <xswang@marvell.com>
> 

It's too long ago to remember all the details, but I thought we
had designed this so the configuration can just be done by
describing it in DT. What am I missing?

	Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1274958 — Re: [PATCH 07/13] bus: mvebu-mbus: provide api for obtaining IO and DRAM window information

Arnd,

2015-11-22 21:02 GMT+01:00 Arnd Bergmann <arnd@arndb.de>:
> On Sunday 22 November 2015 08:53:53 Marcin Wojtas wrote:
>> This commit enables finding appropriate mbus window and obtaining its
>> target id and attribute for given physical address in two separate
>> routines, both for IO and DRAM windows. This functionality
>> is needed for Armada XP/38x Network Controller's Buffer Manager and
>> PnC configuration.
>>
>> Signed-off-by: Marcin Wojtas <mw@semihalf.com>
>>
>> [DRAM window information reference in LKv3.10]
>> Signed-off-by: Evan Wang <xswang@marvell.com>
>>
>
> It's too long ago to remember all the details, but I thought we
> had designed this so the configuration can just be done by
> describing it in DT. What am I missing?
>

And those functions do not break this approach. They just enable
finding and reading the settings of MBUS windows done during initial
configuration. Please remember that mvebu-mbus driver fills the MBUS
windows registers basing on DT, however it just configures access CPU
- DRAM/perfipheral.

In this particular case only physical adresses of buffers are known
and we have to 'open windows' between BM <-> DRAM and NETA <-> BM
internal memory. Hence instead of hardcoding size/target/attribute, we
can take information stored in CPU DRAM/IO windows registers.

Best regards,
Marcin
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1275645 — Re: [PATCH 07/13] bus: mvebu-mbus: provide api for obtaining IO and DRAM window information

On Sunday 22 November 2015 22:24:01 Marcin Wojtas wrote:
> 
> 2015-11-22 21:02 GMT+01:00 Arnd Bergmann <arnd@arndb.de>:
> > On Sunday 22 November 2015 08:53:53 Marcin Wojtas wrote:
> >> This commit enables finding appropriate mbus window and obtaining its
> >> target id and attribute for given physical address in two separate
> >> routines, both for IO and DRAM windows. This functionality
> >> is needed for Armada XP/38x Network Controller's Buffer Manager and
> >> PnC configuration.
> >>
> >> Signed-off-by: Marcin Wojtas <mw@semihalf.com>
> >>
> >> [DRAM window information reference in LKv3.10]
> >> Signed-off-by: Evan Wang <xswang@marvell.com>
> >>
> >
> > It's too long ago to remember all the details, but I thought we
> > had designed this so the configuration can just be done by
> > describing it in DT. What am I missing?
> >
> 
> And those functions do not break this approach. They just enable
> finding and reading the settings of MBUS windows done during initial
> configuration. Please remember that mvebu-mbus driver fills the MBUS
> windows registers basing on DT, however it just configures access CPU
> - DRAM/perfipheral.
> 
> In this particular case only physical adresses of buffers are known
> and we have to 'open windows' between BM <-> DRAM and NETA <-> BM
> internal memory. Hence instead of hardcoding size/target/attribute, we
> can take information stored in CPU DRAM/IO windows registers.
> 
> 

Ok, got it. Thanks for the explanation.

	Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1274939

On Sunday 22 November 2015 08:53:46 Marcin Wojtas wrote:
> 
> 3. Optimisations - concatenating TX descriptors' flush, basing on
> xmit_more support and combined approach for finalizing egress processing.
> Thanks to HR timer buffers can be released with small latency, which is
> good for low transfer and small queues. Along with the timer, coalescing
> irqs are used, whose threshold could be increased back to 15.
> 
> 

If you are already reworking the TX path, it probably makes sense to 
support BQL as well, see the Marvell skge and sky2 drivers for examples
using netdev_{tx_,}{sent,completed}_queue.

	Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1274962

Arnd,

2015-11-22 21:06 GMT+01:00 Arnd Bergmann <arnd@arndb.de>:
> On Sunday 22 November 2015 08:53:46 Marcin Wojtas wrote:
>>
>> 3. Optimisations - concatenating TX descriptors' flush, basing on
>> xmit_more support and combined approach for finalizing egress processing.
>> Thanks to HR timer buffers can be released with small latency, which is
>> good for low transfer and small queues. Along with the timer, coalescing
>> irqs are used, whose threshold could be increased back to 15.
>>
>>
>
> If you are already reworking the TX path, it probably makes sense to
> support BQL as well, see the Marvell skge and sky2 drivers for examples
> using netdev_{tx_,}{sent,completed}_queue.
>

Good idea, I'll take a look.

Best regards,
Marcin
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1276620

This patch series has a lot of problems.

The worst one is that you are mixing bug fixes and new
features/cleanups.

You cannot do that.

You _especially_ can't do that if you expect some of this stuff
to be submitted to -stable too.

Therefore you _must_ extract out the bug fixes, and submit those
against 'net'.  And you must then wait for 'net' to be merged
into 'net-next' before submitting the new feature patches.

Furthermore, you should explicitly show what tree you are targetting
your patches at, in your Subject lines.  In the form:

	Subject: [PATCH $(TREE) N/M]

Where $(TREE) is either 'net' or 'net-next'.

THanks.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1276637

Hi David,

Thanks for the remark. I will do the split and re-submit.

Best regards,
Marcin

2015-11-24 17:22 GMT+01:00 David Miller <davem@davemloft.net>:
>
> This patch series has a lot of problems.
>
> The worst one is that you are mixing bug fixes and new
> features/cleanups.
>
> You cannot do that.
>
> You _especially_ can't do that if you expect some of this stuff
> to be submitted to -stable too.
>
> Therefore you _must_ extract out the bug fixes, and submit those
> against 'net'.  And you must then wait for 'net' to be merged
> into 'net-next' before submitting the new feature patches.
>
> Furthermore, you should explicitly show what tree you are targetting
> your patches at, in your Subject lines.  In the form:
>
>         Subject: [PATCH $(TREE) N/M]
>
> Where $(TREE) is either 'net' or 'net-next'.
>
> THanks.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1277692

On 21/11/15 23:53, Marcin Wojtas wrote:
> 
> 4. Buffer manager (BM) support with two preparatory commits. As it is a
> separate block, common for all network ports, a new driver is introduced,
> which configures it and exposes API to the main network driver. It is
> throughly described in binding documentation and commit log. Please note,
> that enabling per-port BM usage is done using phandle and the data passed
> in mvneta_bm_probe. It is designed for usage of on-demand device probe
> and dev_set/get_drvdata, however it's awaiting merge to linux-next.
> Therefore, deferring probe is not used - if something goes wrong (same
> in case of errors during changing MTU or suspend/resume cycle) mvneta
> driver falls back to software buffer management and works in a regular way.

Looking at your patches, it was not entirely clear to me how the buffer
manager on these Marvell SoCs work, but other networking products have
something similar, like Broadcom's Cable Modem SoCs (BCM33xx) FPM, and
maybe Freescale's FMAN/DPAA seems to do something similar.

Does the buffer manager allocation work by giving you a reference/token
to a buffer as opposed to its address? If that is the case, it would be
good to design support for such hardware in a way that it can be used by
more drivers.

Eric Dumazet suggested a while ago to me that you could get abstract
such allocation using hardware-assisted buffer allocation by either
introducing a new mm zone (instead of ZONE_NORMAL/DMA/HIGHMEM etc.), or
using a different NUMA node id, such that SKB allocation and freeing
helpers could deal with the specifics, and your networking stack and
driver would be mostly unaware of the buffer manager underlying
implementation. The purpose would be to get a 'struct page' reference to
your buffer pool allocation object, so it becomes mostly transparent to
other areas of the kernel, and you could further specialize everything
that needs to be based on this node id or zone.

Finally, these hardware-assisted allocation schemes typically work very
well when there is a forwarding/routing workload involved, because you
can easily steal packets and SKBs from the network stack, but that does
not necessarily play nicely with host-terminated/initiated traffic which
wants to have good feedback on what's happening at the NIC level
(queueing, buffering, etc.).

> 
> Known issues:
> - problems with obtaining all mapped buffers from internal SRAM, when
> destroying the buffer pointer pool
> - problems with unmapping chunk of SRAM during driver removal
> Above do not have an impact on the operation, as they are called during
> driver removal or in error path.

Humm, what is the reason for using the on-chip SRAM here, is it because
that's the only storage location the Buffer Manager can allocate from,
or is it because it is presumably faster or with constant access times
than DRAM? Would be nice to explain a bit more in details how the buffer
manager works and its interfacing with the network controllers.

Can I use the buffer manager with other peripherals as well? Like if I
wanted to do zero-copy or hardware-assisted memcpy DMA, would that be a
suitable scheme?

Thanks!
-- 
Florian
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1279337

Hi Florian,

>
> Looking at your patches, it was not entirely clear to me how the buffer
> manager on these Marvell SoCs work, but other networking products have
> something similar, like Broadcom's Cable Modem SoCs (BCM33xx) FPM, and
> maybe Freescale's FMAN/DPAA seems to do something similar.
>
> Does the buffer manager allocation work by giving you a reference/token
> to a buffer as opposed to its address? If that is the case, it would be
> good to design support for such hardware in a way that it can be used by
> more drivers.

It does not operate on a reference/token but buffer pointers (physical
adresses). It's a ring and you cannot control which buffer will be
taken at given moment.

>
> Eric Dumazet suggested a while ago to me that you could get abstract
> such allocation using hardware-assisted buffer allocation by either
> introducing a new mm zone (instead of ZONE_NORMAL/DMA/HIGHMEM etc.), or
> using a different NUMA node id, such that SKB allocation and freeing
> helpers could deal with the specifics, and your networking stack and
> driver would be mostly unaware of the buffer manager underlying
> implementation. The purpose would be to get a 'struct page' reference to
> your buffer pool allocation object, so it becomes mostly transparent to
> other areas of the kernel, and you could further specialize everything
> that needs to be based on this node id or zone.

As this buffer manager is pretty tightly coupled with NIC (please see
below) and the solution is very platform specific, I'm not sure if it
wouldn't be an overdesign, to provide such generic, paralel to DMA
mechanism.

>
> Finally, these hardware-assisted allocation schemes typically work very
> well when there is a forwarding/routing workload involved, because you
> can easily steal packets and SKBs from the network stack, but that does
> not necessarily play nicely with host-terminated/initiated traffic which
> wants to have good feedback on what's happening at the NIC level
> (queueing, buffering, etc.).

Sure, I can imagine developing some applications that are developed on
top of the proposed patches, but I'm not sure if such things like
cutting network stack in half should be a part of original support.

>
>>
>> Known issues:
>> - problems with obtaining all mapped buffers from internal SRAM, when
>> destroying the buffer pointer pool
>> - problems with unmapping chunk of SRAM during driver removal
>> Above do not have an impact on the operation, as they are called during
>> driver removal or in error path.
>
> Humm, what is the reason for using the on-chip SRAM here, is it because
> that's the only storage location the Buffer Manager can allocate from,
> or is it because it is presumably faster or with constant access times
> than DRAM? Would be nice to explain a bit more in details how the buffer
> manager works and its interfacing with the network controllers.

Each pool of pointers is a ring maintained in DRAM (called buffer
pointers' pool external). SRAM (called buffer pointers' pool internal
memory, BPPI) ensures smaller latency, but is also the only way to
allocate/fetch buffer pointers from DRAM ring. Transfers between those
two memories are controlled by buffer manager itself.

In the beginning the external pool has to be filled with desired
amount of pointers. NIC (controlled by mvneta driver) has to be
informed, which pools it can use for longer and shorter packets, their
size and also SRAM physical address has to be written to one of NETA
registers. Moreover, in order to be able to provide direct access
between NETA and buffer manager SRAM, special, Marvell-specific
settings have to be configured (so called opening of MBUS window).

After enabling ingress, incoming packet is automatically placed in
next-to-be-used buffer from buffer manager resources and the
controller updates NIC's descriptor contents with pool's number and
buffer addresses. Once the packet is processed, a new buffer has to be
allocated and it's address written to SRAM - this way the pool of
pointers gets refilled.

>
> Can I use the buffer manager with other peripherals as well? Like if I
> wanted to do zero-copy or hardware-assisted memcpy DMA, would that be a
> suitable scheme?

Other peripherals cannot access SRAM directly - only DMA-based access
to DRAM. If one would like to access buffers using SRAM from other
drivers, it has to be done by read/write operations performed by CPU.
Moreover I see a limitation, which is a lack of control over the
current buffer index.

Best regards,
Marcin
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1279500

From: Marcin Wojtas <mw@semihalf.com>
Date: Sun, 29 Nov 2015 14:21:35 +0100

>> Looking at your patches, it was not entirely clear to me how the buffer
>> manager on these Marvell SoCs work, but other networking products have
>> something similar, like Broadcom's Cable Modem SoCs (BCM33xx) FPM, and
>> maybe Freescale's FMAN/DPAA seems to do something similar.
>>
>> Does the buffer manager allocation work by giving you a reference/token
>> to a buffer as opposed to its address? If that is the case, it would be
>> good to design support for such hardware in a way that it can be used by
>> more drivers.
> 
> It does not operate on a reference/token but buffer pointers (physical
> adresses). It's a ring and you cannot control which buffer will be
> taken at given moment.

He understands this, he's asking you to make an "abstraction".

FWIW, I know of at least one more chip that operates this way too and
the code I wrote for it, particularly the buffer management, took a
while to solidify.  Common helpers for this kind of situation would
have helped me back when I wrote it.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | linux.kernel

csiph-web