[PATCH v5 0/4] Add Ethernet support on STM32F429

STM32F429 Chip embeds a Synopsys 3.50a MAC IP.
This series:
 -enhance current stmmac driver to control it (code already
available) and adds basic glue for STM32F429 chip.
 -Enable basic Net config in kernel.

Note that DT patches are not present because STM32 pinctrl code is not
yet avalaible.

Changes since v4:
 -Fix dirty copy/past in bindings documentation patch.

Changes since v3:
 -Fix "tx-clk" and "rx-clk" as required clocks. Driver and bindings are
modified.

Changes since v2:
 -Fix alphabetic order in Kconfig and Makefile.
 -Improve code according to Joachim review.
 -Binding: remove useless entry.

Changes since v1:
 -Fix Kbuild issue in Kconfig.
 -Remove init/exit callbacks. Suspend/Resume and remove driver is no more
driven in stmmac_pltfr but directly in dwmac-stm32 glue driver.
 -Take into account Joachim review.

Regards.

Alexandre.

Alexandre TORGUE (4):
  net: ethernet: dwmac: add Ethernet glue logic for stm32 chip
  Documentation: Bindings: Add STM32 DWMAC glue
  net: ethernet: stmmac: add support of Synopsys 3.50a MAC IP
  ARM: STM32: Enable Ethernet in stm32_defconfig

 .../devicetree/bindings/net/stm32-dwmac.txt        |  32 ++++
 arch/arm/configs/stm32_defconfig                   |   9 +
 drivers/net/ethernet/stmicro/stmmac/Kconfig        |  12 ++
 drivers/net/ethernet/stmicro/stmmac/Makefile       |   1 +
 drivers/net/ethernet/stmicro/stmmac/dwmac-stm32.c  | 193 +++++++++++++++++++++
 .../net/ethernet/stmicro/stmmac/stmmac_platform.c  |   1 +
 6 files changed, 248 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/net/stm32-dwmac.txt
 create mode 100644 drivers/net/ethernet/stmicro/stmmac/dwmac-stm32.c

-- 
1.9.1

Signed-off-by: Alexandre TORGUE <redacted>

diff --git a/Documentation/devicetree/bindings/net/stm32-dwmac.txt b/Documentation/devicetree/bindings/net/stm32-dwmac.txt
new file mode 100644
index 0000000..ada2aa4
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/stm32-dwmac.txt

@@ -0,0 +1,32 @@
+STMicroelectronics STM32 / MCU DWMAC glue layer controller
+
+This file documents platform glue layer for stmmac.
+Please see stmmac.txt for the other unchanged properties.
+
+The device node has following properties.
+
+Required properties:
+- compatible:  Should be "st,stm32-dwmac" to select glue, and
+	       "snps,dwmac-3.50a" to select IP vesrion.
+- clocks: Must contain a phandle for each entry in clock-names.
+- clock-names: Should be "stmmaceth" for the host clock.
+	       Should be "tx-clk" for the MAC TX clock.
+	       Should be "rx-clk" for the MAC RX clock.
+- st,syscon : Should be phandle/offset pair. The phandle to the syscon node which
+	      encompases the glue register, and the offset of the control register.
+Example:
+
+		ethernet0: dwmac@40028000 {
+			compatible = "st,stm32-dwmac", "snps,dwmac-3.50a";
+			status = "disabled";
+			reg = <0x40028000 0x8000>;
+			reg-names = "stmmaceth";
+			interrupts = <0 61 0>, <0 62 0>;
+			interrupt-names = "macirq", "eth_wake_irq";
+			clock-names = "stmmaceth", "tx-clk", "rx-clk";
+			clocks = <&rcc 0 25>, <&rcc 0 26>, <&rcc 0 27>;
+			st,syscon = <&syscfg 0x4>;
+			snps,pbl = <8>;
+			snps,mixed-burst;
+			dma-ranges;
+		};

-- 
1.9.1

Adds support of Synopsys 3.50a MAC IP in stmmac driver.

Acked-by: Giuseppe Cavallaro <redacted>
Tested-by: Maxime Coquelin <redacted>
Signed-off-by: Alexandre TORGUE <redacted>

diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
index 6a52fa1..6cca626 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c

@@ -178,6 +178,7 @@ stmmac_probe_config_dt(struct platform_device *pdev, const char **mac)
 	 * once needed on other platforms.
 	 */
 	if (of_device_is_compatible(np, "st,spear600-gmac") ||
+		of_device_is_compatible(np, "snps,dwmac-3.50a") ||
 		of_device_is_compatible(np, "snps,dwmac-3.70a") ||
 		of_device_is_compatible(np, "snps,dwmac")) {
 		/* Note that the max-frame-size parameter as defined in the

-- 
1.9.1

stm324xx family chips support Synopsys MAC 3.510 IP.
This patch adds settings for logical glue logic:
-clocks
-mode selection MII or RMII.

Reviewed-by: Joachim Eastwood <redacted>
Acked-by: Giuseppe Cavallaro <redacted>
Tested-by: Maxime Coquelin <redacted>
Signed-off-by: Alexandre TORGUE <redacted>

diff --git a/drivers/net/ethernet/stmicro/stmmac/Kconfig b/drivers/net/ethernet/stmicro/stmmac/Kconfig
index cec147d..235d679 100644
--- a/drivers/net/ethernet/stmicro/stmmac/Kconfig
+++ b/drivers/net/ethernet/stmicro/stmmac/Kconfig

@@ -104,6 +104,18 @@ config DWMAC_STI
 	  device driver. This driver is used on for the STi series
 	  SOCs GMAC ethernet controller.
 
+config DWMAC_STM32
+	tristate "STM32 DWMAC support"
+	default ARCH_STM32
+	depends on OF && HAS_IOMEM
+	select MFD_SYSCON
+	---help---
+	  Support for ethernet controller on STM32 SOCs.
+
+	  This selects STM32 SoC glue layer support for the stmmac
+	  device driver. This driver is used on for the STM32 series
+	  SOCs GMAC ethernet controller.
+
 config DWMAC_SUNXI
 	tristate "Allwinner GMAC support"
 	default ARCH_SUNXI

diff --git a/drivers/net/ethernet/stmicro/stmmac/Makefile b/drivers/net/ethernet/stmicro/stmmac/Makefile
index b390161..5f7ff0a 100644
--- a/drivers/net/ethernet/stmicro/stmmac/Makefile
+++ b/drivers/net/ethernet/stmicro/stmmac/Makefile

@@ -12,6 +12,7 @@ obj-$(CONFIG_DWMAC_MESON)	+= dwmac-meson.o
 obj-$(CONFIG_DWMAC_ROCKCHIP)	+= dwmac-rk.o
 obj-$(CONFIG_DWMAC_SOCFPGA)	+= dwmac-socfpga.o
 obj-$(CONFIG_DWMAC_STI)		+= dwmac-sti.o
+obj-$(CONFIG_DWMAC_STM32)	+= dwmac-stm32.o
 obj-$(CONFIG_DWMAC_SUNXI)	+= dwmac-sunxi.o
 obj-$(CONFIG_DWMAC_GENERIC)	+= dwmac-generic.o
 stmmac-platform-objs:= stmmac_platform.o

diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-stm32.c b/drivers/net/ethernet/stmicro/stmmac/dwmac-stm32.c
new file mode 100644
index 0000000..88c8573
--- /dev/null
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-stm32.c

@@ -0,0 +1,193 @@
+/*
+ * dwmac-stm32.c - DWMAC Specific Glue layer for STM32 MCU
+ *
+ * Copyright (C) Alexandre Torgue 2015
+ * Author:  Alexandre Torgue <alexandre.torgue@gmail.com>
+ * License terms:  GNU General Public License (GPL), version 2
+ *
+ */
+
+#include <linux/clk.h>
+#include <linux/kernel.h>
+#include <linux/mfd/syscon.h>
+#include <linux/module.h>
+#include <linux/of.h>
+#include <linux/of_device.h>
+#include <linux/of_net.h>
+#include <linux/phy.h>
+#include <linux/platform_device.h>
+#include <linux/regmap.h>
+#include <linux/slab.h>
+#include <linux/stmmac.h>
+
+#include "stmmac_platform.h"
+
+#define MII_PHY_SEL_MASK	BIT(23)
+
+struct stm32_dwmac {
+	struct clk *clk_tx;
+	struct clk *clk_rx;
+	u32 mode_reg;		/* MAC glue-logic mode register */
+	struct regmap *regmap;
+	u32 speed;
+};
+
+static int stm32_dwmac_init(struct plat_stmmacenet_data *plat_dat)
+{
+	struct stm32_dwmac *dwmac = plat_dat->bsp_priv;
+	u32 reg = dwmac->mode_reg;
+	u32 val;
+	int ret;
+
+	val = (plat_dat->interface == PHY_INTERFACE_MODE_MII) ? 0 : 1;
+	ret = regmap_update_bits(dwmac->regmap, reg, MII_PHY_SEL_MASK, val);
+	if (ret)
+		return ret;
+
+	ret = clk_prepare_enable(dwmac->clk_tx);
+	if (ret)
+		return ret;
+
+	ret = clk_prepare_enable(dwmac->clk_rx);
+	if (ret)
+		clk_disable_unprepare(dwmac->clk_tx);
+
+	return ret;
+}
+
+static void stm32_dwmac_clk_disable(struct stm32_dwmac *dwmac)
+{
+	clk_disable_unprepare(dwmac->clk_tx);
+	clk_disable_unprepare(dwmac->clk_rx);
+}
+
+static int stm32_dwmac_parse_data(struct stm32_dwmac *dwmac,
+				  struct device *dev)
+{
+	struct device_node *np = dev->of_node;
+	int err;
+
+	/*  Get TX/RX clocks */
+	dwmac->clk_tx = devm_clk_get(dev, "tx-clk");
+	if (IS_ERR(dwmac->clk_tx)) {
+		dev_err(dev, "No tx clock provided...\n");
+		return PTR_ERR(dwmac->clk_tx);
+	}
+	dwmac->clk_rx = devm_clk_get(dev, "rx-clk");
+	if (IS_ERR(dwmac->clk_rx)) {
+		dev_err(dev, "No rx clock provided...\n");
+		return PTR_ERR(dwmac->clk_rx);
+	}
+
+	/* Get mode register */
+	dwmac->regmap = syscon_regmap_lookup_by_phandle(np, "st,syscon");
+	if (IS_ERR(dwmac->regmap))
+		return PTR_ERR(dwmac->regmap);
+
+	err = of_property_read_u32_index(np, "st,syscon", 1, &dwmac->mode_reg);
+	if (err)
+		dev_err(dev, "Can't get sysconfig mode offset (%d)\n", err);
+
+	return err;
+}
+
+static int stm32_dwmac_probe(struct platform_device *pdev)
+{
+	struct plat_stmmacenet_data *plat_dat;
+	struct stmmac_resources stmmac_res;
+	struct stm32_dwmac *dwmac;
+	int ret;
+
+	ret = stmmac_get_platform_resources(pdev, &stmmac_res);
+	if (ret)
+		return ret;
+
+	plat_dat = stmmac_probe_config_dt(pdev, &stmmac_res.mac);
+	if (IS_ERR(plat_dat))
+		return PTR_ERR(plat_dat);
+
+	dwmac = devm_kzalloc(&pdev->dev, sizeof(*dwmac), GFP_KERNEL);
+	if (!dwmac)
+		return -ENOMEM;
+
+	ret = stm32_dwmac_parse_data(dwmac, &pdev->dev);
+	if (ret) {
+		dev_err(&pdev->dev, "Unable to parse OF data\n");
+		return ret;
+	}
+
+	plat_dat->bsp_priv = dwmac;
+
+	ret = stm32_dwmac_init(plat_dat);
+	if (ret)
+		return ret;
+
+	ret = stmmac_dvr_probe(&pdev->dev, plat_dat, &stmmac_res);
+	if (ret)
+		stm32_dwmac_clk_disable(dwmac);
+
+	return ret;
+}
+
+static int stm32_dwmac_remove(struct platform_device *pdev)
+{
+	struct net_device *ndev = platform_get_drvdata(pdev);
+	struct stmmac_priv *priv = netdev_priv(ndev);
+	int ret = stmmac_dvr_remove(ndev);
+
+	stm32_dwmac_clk_disable(priv->plat->bsp_priv);
+
+	return ret;
+}
+
+#ifdef CONFIG_PM_SLEEP
+static int stm32_dwmac_suspend(struct device *dev)
+{
+	struct net_device *ndev = dev_get_drvdata(dev);
+	struct stmmac_priv *priv = netdev_priv(ndev);
+	int ret;
+
+	ret = stmmac_suspend(ndev);
+	stm32_dwmac_clk_disable(priv->plat->bsp_priv);
+
+	return ret;
+}
+
+static int stm32_dwmac_resume(struct device *dev)
+{
+	struct net_device *ndev = dev_get_drvdata(dev);
+	struct stmmac_priv *priv = netdev_priv(ndev);
+	int ret;
+
+	ret = stm32_dwmac_init(priv->plat);
+	if (ret)
+		return ret;
+
+	ret = stmmac_resume(ndev);
+
+	return ret;
+}
+#endif /* CONFIG_PM_SLEEP */
+
+SIMPLE_DEV_PM_OPS(stm32_dwmac_pm_ops, stm32_dwmac_suspend, stm32_dwmac_resume);
+
+static const struct of_device_id stm32_dwmac_match[] = {
+	{ .compatible = "st,stm32-dwmac"},
+	{ }
+};
+MODULE_DEVICE_TABLE(of, stm32_dwmac_match);
+
+static struct platform_driver stm32_dwmac_driver = {
+	.probe  = stm32_dwmac_probe,
+	.remove = stm32_dwmac_remove,
+	.driver = {
+		.name           = "stm32-dwmac",
+		.pm		= &stm32_dwmac_pm_ops,
+		.of_match_table = stm32_dwmac_match,
+	},
+};
+module_platform_driver(stm32_dwmac_driver);
+
+MODULE_AUTHOR("Alexandre Torgue <alexandre.torgue@gmail.com>");
+MODULE_DESCRIPTION("STMicroelectronics MCU DWMAC Specific Glue layer");
+MODULE_LICENSE("GPL v2");

-- 
1.9.1

Enable basic Ethernet support (IPV4) for stm32 defconfig.

Signed-off-by: Alexandre TORGUE <redacted>

diff --git a/arch/arm/configs/stm32_defconfig b/arch/arm/configs/stm32_defconfig
index ec52505..8b8abe0 100644
--- a/arch/arm/configs/stm32_defconfig
+++ b/arch/arm/configs/stm32_defconfig

@@ -33,11 +33,20 @@ CONFIG_XIP_PHYS_ADDR=0x08008000
 CONFIG_BINFMT_FLAT=y
 CONFIG_BINFMT_SHARED_FLAT=y
 # CONFIG_COREDUMP is not set
+CONFIG_NET=y
+CONFIG_INET=y
+# CONFIG_INET_XFRM_MODE_TRANSPORT is not set
+# CONFIG_INET_XFRM_MODE_TUNNEL is not set
+# CONFIG_INET_XFRM_MODE_BEET is not set
+# CONFIG_IPV6 is not set
 CONFIG_DEVTMPFS=y
 CONFIG_DEVTMPFS_MOUNT=y
 # CONFIG_FW_LOADER is not set
 # CONFIG_BLK_DEV is not set
 CONFIG_EEPROM_93CX6=y
+CONFIG_NETDEVICES=y
+CONFIG_STMMAC_ETH=y
+# CONFIG_WLAN is not set
 # CONFIG_INPUT is not set
 # CONFIG_SERIO is not set
 # CONFIG_VT is not set

-- 
1.9.1

Hi,

On Fri, Mar 18, 2016 at 11:37 PM, Alexandre TORGUE
[off-list ref] wrote:

If you need have sort of hardware glue, then it is not compatible.

ChenYu

+- clocks: Must contain a phandle for each entry in clock-names.
+- clock-names: Should be "stmmaceth" for the host clock.
+              Should be "tx-clk" for the MAC TX clock.
+              Should be "rx-clk" for the MAC RX clock.
+- st,syscon : Should be phandle/offset pair. The phandle to the syscon node which
+             encompases the glue register, and the offset of the control register.
+Example:
+
+               ethernet0: dwmac@40028000 {
+                       compatible = "st,stm32-dwmac", "snps,dwmac-3.50a";
+                       status = "disabled";
+                       reg = <0x40028000 0x8000>;
+                       reg-names = "stmmaceth";
+                       interrupts = <0 61 0>, <0 62 0>;
+                       interrupt-names = "macirq", "eth_wake_irq";
+                       clock-names = "stmmaceth", "tx-clk", "rx-clk";
+                       clocks = <&rcc 0 25>, <&rcc 0 26>, <&rcc 0 27>;
+                       st,syscon = <&syscfg 0x4>;
+                       snps,pbl = <8>;
+                       snps,mixed-burst;
+                       dma-ranges;
+               };
--
1.9.1


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Hi,

2016-03-18 17:00 GMT+01:00 Chen-Yu Tsai [off-list ref]:

Hi,

On Fri, Mar 18, 2016 at 11:37 PM, Alexandre TORGUE
[off-list ref] wrote:

quoted

Signed-off-by: Alexandre TORGUE <redacted>

diff --git a/Documentation/devicetree/bindings/net/stm32-dwmac.txt b/Documentation/devicetree/bindings/net/stm32-dwmac.txt
new file mode 100644
index 0000000..ada2aa4
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/stm32-dwmac.txt

@@ -0,0 +1,32 @@
+STMicroelectronics STM32 / MCU DWMAC glue layer controller
+
+This file documents platform glue layer for stmmac.
+Please see stmmac.txt for the other unchanged properties.
+
+The device node has following properties.
+
+Required properties:
+- compatible:  Should be "st,stm32-dwmac" to select glue, and
+              "snps,dwmac-3.50a" to select IP vesrion.

If you need have sort of hardware glue, then it is not compatible.

We could have the case where the glue is set by a bootloader.
In this case, we will select IP version in compatible and we will use
generic dwmac glue to probe stmmac driver.

Regards

Alex.

ChenYu

quoted

+- clocks: Must contain a phandle for each entry in clock-names.
+- clock-names: Should be "stmmaceth" for the host clock.
+              Should be "tx-clk" for the MAC TX clock.
+              Should be "rx-clk" for the MAC RX clock.
+- st,syscon : Should be phandle/offset pair. The phandle to the syscon node which
+             encompases the glue register, and the offset of the control register.
+Example:
+
+               ethernet0: dwmac@40028000 {
+                       compatible = "st,stm32-dwmac", "snps,dwmac-3.50a";
+                       status = "disabled";
+                       reg = <0x40028000 0x8000>;
+                       reg-names = "stmmaceth";
+                       interrupts = <0 61 0>, <0 62 0>;
+                       interrupt-names = "macirq", "eth_wake_irq";
+                       clock-names = "stmmaceth", "tx-clk", "rx-clk";
+                       clocks = <&rcc 0 25>, <&rcc 0 26>, <&rcc 0 27>;
+                       st,syscon = <&syscfg 0x4>;
+                       snps,pbl = <8>;
+                       snps,mixed-burst;
+                       dma-ranges;
+               };
--
1.9.1


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

On Mon, Mar 21, 2016 at 6:45 PM, Alexandre Torgue
[off-list ref] wrote:

Hi,

2016-03-18 17:00 GMT+01:00 Chen-Yu Tsai [off-list ref]:

quoted

Hi,

On Fri, Mar 18, 2016 at 11:37 PM, Alexandre TORGUE
[off-list ref] wrote:

quoted

Signed-off-by: Alexandre TORGUE <redacted>

diff --git a/Documentation/devicetree/bindings/net/stm32-dwmac.txt b/Documentation/devicetree/bindings/net/stm32-dwmac.txt
new file mode 100644
index 0000000..ada2aa4
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/stm32-dwmac.txt

@@ -0,0 +1,32 @@
+STMicroelectronics STM32 / MCU DWMAC glue layer controller
+
+This file documents platform glue layer for stmmac.
+Please see stmmac.txt for the other unchanged properties.
+
+The device node has following properties.
+
+Required properties:
+- compatible:  Should be "st,stm32-dwmac" to select glue, and
+              "snps,dwmac-3.50a" to select IP vesrion.

If you need have sort of hardware glue, then it is not compatible.

We could have the case where the glue is set by a bootloader.
In this case, we will select IP version in compatible and we will use
generic dwmac glue to probe stmmac driver.

It seems most platforms using DWMAC follow this design set by
the original stmmac bindings. I'm arguing that the requirement
of setting up the glue makes them incompatible.

What happens when the bootloader didn't setup the glue? And one
forgets to build the STM32 driver, only the generic one? The
generic driver even matches to some, but not all, version
strings.

Maybe it would've been better if the versioned strings were
only used to indicate functionality, and not used to bind
the drivers. But the bindings were set some time ago.


Regards
ChenYu

Regards

Alex.

quoted

ChenYu

quoted

+- clocks: Must contain a phandle for each entry in clock-names.
+- clock-names: Should be "stmmaceth" for the host clock.
+              Should be "tx-clk" for the MAC TX clock.
+              Should be "rx-clk" for the MAC RX clock.
+- st,syscon : Should be phandle/offset pair. The phandle to the syscon node which
+             encompases the glue register, and the offset of the control register.
+Example:
+
+               ethernet0: dwmac@40028000 {
+                       compatible = "st,stm32-dwmac", "snps,dwmac-3.50a";
+                       status = "disabled";
+                       reg = <0x40028000 0x8000>;
+                       reg-names = "stmmaceth";
+                       interrupts = <0 61 0>, <0 62 0>;
+                       interrupt-names = "macirq", "eth_wake_irq";
+                       clock-names = "stmmaceth", "tx-clk", "rx-clk";
+                       clocks = <&rcc 0 25>, <&rcc 0 26>, <&rcc 0 27>;
+                       st,syscon = <&syscfg 0x4>;
+                       snps,pbl = <8>;
+                       snps,mixed-burst;
+                       dma-ranges;
+               };
--
1.9.1


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Hi Chen-Yu,

On 21 March 2016 at 12:08, Chen-Yu Tsai [off-list ref] wrote:

On Mon, Mar 21, 2016 at 6:45 PM, Alexandre Torgue
[off-list ref] wrote:

quoted

Hi,

2016-03-18 17:00 GMT+01:00 Chen-Yu Tsai [off-list ref]:

quoted

Hi,

On Fri, Mar 18, 2016 at 11:37 PM, Alexandre TORGUE
[off-list ref] wrote:

quoted

Signed-off-by: Alexandre TORGUE <redacted>

diff --git a/Documentation/devicetree/bindings/net/stm32-dwmac.txt b/Documentation/devicetree/bindings/net/stm32-dwmac.txt
new file mode 100644
index 0000000..ada2aa4
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/stm32-dwmac.txt

@@ -0,0 +1,32 @@
+STMicroelectronics STM32 / MCU DWMAC glue layer controller
+
+This file documents platform glue layer for stmmac.
+Please see stmmac.txt for the other unchanged properties.
+
+The device node has following properties.
+
+Required properties:
+- compatible:  Should be "st,stm32-dwmac" to select glue, and
+              "snps,dwmac-3.50a" to select IP vesrion.

s/vesrion/version

quoted

quoted

If you need have sort of hardware glue, then it is not compatible.

We could have the case where the glue is set by a bootloader.
In this case, we will select IP version in compatible and we will use
generic dwmac glue to probe stmmac driver.

It seems most platforms using DWMAC follow this design set by
the original stmmac bindings. I'm arguing that the requirement
of setting up the glue makes them incompatible.

What happens when the bootloader didn't setup the glue? And one
forgets to build the STM32 driver, only the generic one? The
generic driver even matches to some, but not all, version
strings.

Maybe it would've been better if the versioned strings were
only used to indicate functionality, and not used to bind
the drivers. But the bindings were set some time ago.

Since Alexandre has not added "snps,dwmac-3.50a" to dwmac-generic
doesn't he use it as you suggest here?

Note that we can not remove all the generic compatible strings from
dwmac-generic because there is one platform that depend on one of
them.
(see arch/arm/boot/dts/exynos5440.dtsi:190)

So we can not remove "snps,dwmac-3.70a" from the dwmac-generic driver
if we want to keep backwards compatibility with exynos5440. But I
guess we could remove the others if we want to.


regards,
Joachim Eastwood
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

On Sat, Mar 19, 2016 at 12:00:22AM +0800, Chen-Yu Tsai wrote:

Hi,

On Fri, Mar 18, 2016 at 11:37 PM, Alexandre TORGUE
[off-list ref] wrote:

quoted

Signed-off-by: Alexandre TORGUE <redacted>

diff --git a/Documentation/devicetree/bindings/net/stm32-dwmac.txt b/Documentation/devicetree/bindings/net/stm32-dwmac.txt
new file mode 100644
index 0000000..ada2aa4
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/stm32-dwmac.txt

@@ -0,0 +1,32 @@
+STMicroelectronics STM32 / MCU DWMAC glue layer controller
+
+This file documents platform glue layer for stmmac.
+Please see stmmac.txt for the other unchanged properties.
+
+The device node has following properties.
+
+Required properties:
+- compatible:  Should be "st,stm32-dwmac" to select glue, and
+              "snps,dwmac-3.50a" to select IP vesrion.

If you need have sort of hardware glue, then it is not compatible.

Hence, the more specific compatible. Having the generic one is still 
useful.

ChenYu

quoted

+- clocks: Must contain a phandle for each entry in clock-names.
+- clock-names: Should be "stmmaceth" for the host clock.

This doesn't sound like the clock input signal name...

quoted

+              Should be "tx-clk" for the MAC TX clock.
+              Should be "rx-clk" for the MAC RX clock.

How can other DWMAC blocks not have these clocks? The glue can't really 
add these clocks. It could combine them into one or a new version of 
DWMAC could have a different number of clock inputs. So if there is 
variation here, then some of the bindings are probably wrong. I guess 
the only change I'm suggesting is possibly moving these into common 
binding doc.

quoted

+- st,syscon : Should be phandle/offset pair. The phandle to the syscon node which
+             encompases the glue register, and the offset of the control register.
+Example:
+
+               ethernet0: dwmac@40028000 {

ethernet@...

quoted

+                       compatible = "st,stm32-dwmac", "snps,dwmac-3.50a";
+                       status = "disabled";
+                       reg = <0x40028000 0x8000>;
+                       reg-names = "stmmaceth";
+                       interrupts = <0 61 0>, <0 62 0>;
+                       interrupt-names = "macirq", "eth_wake_irq";
+                       clock-names = "stmmaceth", "tx-clk", "rx-clk";
+                       clocks = <&rcc 0 25>, <&rcc 0 26>, <&rcc 0 27>;
+                       st,syscon = <&syscfg 0x4>;
+                       snps,pbl = <8>;
+                       snps,mixed-burst;
+                       dma-ranges;
+               };
--
1.9.1


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

On 3/21/2016 11:45 AM, Alexandre Torgue wrote:

Hi,

2016-03-18 17:00 GMT+01:00 Chen-Yu Tsai [off-list ref]:

quoted

Hi,

On Fri, Mar 18, 2016 at 11:37 PM, Alexandre TORGUE
[off-list ref] wrote:

quoted

Signed-off-by: Alexandre TORGUE <redacted>

diff --git a/Documentation/devicetree/bindings/net/stm32-dwmac.txt b/Documentation/devicetree/bindings/net/stm32-dwmac.txt
new file mode 100644
index 0000000..ada2aa4
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/stm32-dwmac.txt

@@ -0,0 +1,32 @@
+STMicroelectronics STM32 / MCU DWMAC glue layer controller
+
+This file documents platform glue layer for stmmac.
+Please see stmmac.txt for the other unchanged properties.
+
+The device node has following properties.
+
+Required properties:
+- compatible:  Should be "st,stm32-dwmac" to select glue, and
+              "snps,dwmac-3.50a" to select IP vesrion.

Almost all the synp gmac chips have the HW capability register that is
used for setting all the parameters at probe time.
This will override fields passed from DT. In theory, it is not
necessary to pass: "snps,dwmac-3.50a" from device tree at least there
is either no HW cap reg or the glue has some w/a for a specific chip
revision.
To be honest, I like to see the "snps,dwmac-3.50a" as compatibility
to also have a better readability (that's my personal view ;-) ).

Peppe

quoted

If you need have sort of hardware glue, then it is not compatible.

We could have the case where the glue is set by a bootloader.
In this case, we will select IP version in compatible and we will use
generic dwmac glue to probe stmmac driver.

Regards

Alex.

quoted

ChenYu

quoted

+- clocks: Must contain a phandle for each entry in clock-names.
+- clock-names: Should be "stmmaceth" for the host clock.
+              Should be "tx-clk" for the MAC TX clock.
+              Should be "rx-clk" for the MAC RX clock.
+- st,syscon : Should be phandle/offset pair. The phandle to the syscon node which
+             encompases the glue register, and the offset of the control register.
+Example:
+
+               ethernet0: dwmac@40028000 {
+                       compatible = "st,stm32-dwmac", "snps,dwmac-3.50a";
+                       status = "disabled";
+                       reg = <0x40028000 0x8000>;
+                       reg-names = "stmmaceth";
+                       interrupts = <0 61 0>, <0 62 0>;
+                       interrupt-names = "macirq", "eth_wake_irq";
+                       clock-names = "stmmaceth", "tx-clk", "rx-clk";
+                       clocks = <&rcc 0 25>, <&rcc 0 26>, <&rcc 0 27>;
+                       st,syscon = <&syscfg 0x4>;
+                       snps,pbl = <8>;
+                       snps,mixed-burst;
+                       dma-ranges;
+               };
--
1.9.1


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

On 21 March 2016 at 13:40, Rob Herring [off-list ref] wrote:

On Sat, Mar 19, 2016 at 12:00:22AM +0800, Chen-Yu Tsai wrote:

quoted

Hi,

On Fri, Mar 18, 2016 at 11:37 PM, Alexandre TORGUE
[off-list ref] wrote:

quoted

+- clocks: Must contain a phandle for each entry in clock-names.
+- clock-names: Should be "stmmaceth" for the host clock.

This doesn't sound like the clock input signal name...

quoted

quoted

+              Should be "tx-clk" for the MAC TX clock.
+              Should be "rx-clk" for the MAC RX clock.

How can other DWMAC blocks not have these clocks? The glue can't really
add these clocks. It could combine them into one or a new version of
DWMAC could have a different number of clock inputs. So if there is
variation here, then some of the bindings are probably wrong. I guess
the only change I'm suggesting is possibly moving these into common
binding doc.

The LPC18xx implementation probably have these clocks as well but the
LPC1850 user manual only documents the main clock. Someone with access
to the IP block doc from Synopsys should be able to check which clocks
the MAC really needs.

Rockchip bindings have two clocks named "mac_clk_rx" and "mac_clk_tx".
These are probably the same as stm32 needs so maybe use these names
and move them into the main doc and update the rockchip binding.


regards,
Joachim Eastwood

Hi guys,

I will fix typo issues (s/vesrion/version and ethernet @).

Concerning compatible string. For sure "snps,dwmac-3.50a" string is
not used inside glue driver.
I perfere to keep it for information but if you really want that I
remove it I will not block ;)

2016-03-21 16:36 GMT+01:00 Joachim  Eastwood [off-list ref]:

On 21 March 2016 at 13:40, Rob Herring [off-list ref] wrote:

quoted

On Sat, Mar 19, 2016 at 12:00:22AM +0800, Chen-Yu Tsai wrote:

quoted

Hi,

On Fri, Mar 18, 2016 at 11:37 PM, Alexandre TORGUE
[off-list ref] wrote:

quoted

+- clocks: Must contain a phandle for each entry in clock-names.
+- clock-names: Should be "stmmaceth" for the host clock.

We can remove host clock (stmmac eth) entry here and refer to
stmmac.txt binding for common entry

quoted

This doesn't sound like the clock input signal name...

quoted

quoted

+              Should be "tx-clk" for the MAC TX clock.
+              Should be "rx-clk" for the MAC RX clock.

How can other DWMAC blocks not have these clocks? The glue can't really
add these clocks. It could combine them into one or a new version of
DWMAC could have a different number of clock inputs. So if there is
variation here, then some of the bindings are probably wrong. I guess
the only change I'm suggesting is possibly moving these into common
binding doc.

The LPC18xx implementation probably have these clocks as well but the
LPC1850 user manual only documents the main clock. Someone with access
to the IP block doc from Synopsys should be able to check which clocks
the MAC really needs.

Rockchip bindings have two clocks named "mac_clk_rx" and "mac_clk_tx".
These are probably the same as stm32 needs so maybe use these names
and move them into the main doc and update the rockchip binding.

I think we can use same name. But I have a doubt on moving it in a
common bindings (maybe I don't well understood). When you say "common
binding file" is it "stmmac.txt" binding ? If yes does it mean that we
have to control it inside stmmac driver (no more in glue) ? In this
case those clocks will become "required" for stm32 and rockship but
not for others chip. It could create confusion?

Best regards

Alex

regards,
Joachim Eastwood

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

On Mon, Mar 21, 2016 at 10:02 PM, Giuseppe CAVALLARO
[off-list ref] wrote:

On 3/21/2016 11:45 AM, Alexandre Torgue wrote:

quoted

Hi,

2016-03-18 17:00 GMT+01:00 Chen-Yu Tsai [off-list ref]:

quoted

Hi,

On Fri, Mar 18, 2016 at 11:37 PM, Alexandre TORGUE
[off-list ref] wrote:

quoted

Signed-off-by: Alexandre TORGUE <redacted>

diff --git a/Documentation/devicetree/bindings/net/stm32-dwmac.txt

b/Documentation/devicetree/bindings/net/stm32-dwmac.txt
new file mode 100644
index 0000000..ada2aa4

--- /dev/null
+++ b/Documentation/devicetree/bindings/net/stm32-dwmac.txt

@@ -0,0 +1,32 @@
+STMicroelectronics STM32 / MCU DWMAC glue layer controller
+
+This file documents platform glue layer for stmmac.
+Please see stmmac.txt for the other unchanged properties.
+
+The device node has following properties.
+
+Required properties:
+- compatible:  Should be "st,stm32-dwmac" to select glue, and
+              "snps,dwmac-3.50a" to select IP vesrion.

Almost all the synp gmac chips have the HW capability register that is
used for setting all the parameters at probe time.
This will override fields passed from DT. In theory, it is not
necessary to pass: "snps,dwmac-3.50a" from device tree at least there
is either no HW cap reg or the glue has some w/a for a specific chip
revision.
To be honest, I like to see the "snps,dwmac-3.50a" as compatibility
to also have a better readability (that's my personal view ;-) ).

I agree having the versioned strings is good for informational purposes,
and to signal hardware capability. It is not so good for directly
binding drivers in the implementation though.

Unfortunately, as Joachim pointed out, exynos5440 uses it so we cannot
change it.

ChenYu

Peppe

quoted

quoted

If you need have sort of hardware glue, then it is not compatible.

We could have the case where the glue is set by a bootloader.
In this case, we will select IP version in compatible and we will use
generic dwmac glue to probe stmmac driver.

Regards

Alex.

quoted

ChenYu

quoted

+- clocks: Must contain a phandle for each entry in clock-names.
+- clock-names: Should be "stmmaceth" for the host clock.
+              Should be "tx-clk" for the MAC TX clock.
+              Should be "rx-clk" for the MAC RX clock.
+- st,syscon : Should be phandle/offset pair. The phandle to the syscon
node which
+             encompases the glue register, and the offset of the
control register.
+Example:
+
+               ethernet0: dwmac@40028000 {
+                       compatible = "st,stm32-dwmac",
"snps,dwmac-3.50a";
+                       status = "disabled";
+                       reg = <0x40028000 0x8000>;
+                       reg-names = "stmmaceth";
+                       interrupts = <0 61 0>, <0 62 0>;
+                       interrupt-names = "macirq", "eth_wake_irq";
+                       clock-names = "stmmaceth", "tx-clk", "rx-clk";
+                       clocks = <&rcc 0 25>, <&rcc 0 26>, <&rcc 0 27>;
+                       st,syscon = <&syscfg 0x4>;
+                       snps,pbl = <8>;
+                       snps,mixed-burst;
+                       dma-ranges;
+               };
--
1.9.1


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Hi Rob,

2016-03-22 17:11 GMT+01:00 Alexandre Torgue [off-list ref]:

Hi guys,

I will fix typo issues (s/vesrion/version and ethernet @).

Concerning compatible string. For sure "snps,dwmac-3.50a" string is
not used inside glue driver.
I perfere to keep it for information but if you really want that I
remove it I will not block ;)

2016-03-21 16:36 GMT+01:00 Joachim  Eastwood [off-list ref]:

quoted

On 21 March 2016 at 13:40, Rob Herring [off-list ref] wrote:

quoted

On Sat, Mar 19, 2016 at 12:00:22AM +0800, Chen-Yu Tsai wrote:

quoted

Hi,

On Fri, Mar 18, 2016 at 11:37 PM, Alexandre TORGUE
[off-list ref] wrote:

quoted

+- clocks: Must contain a phandle for each entry in clock-names.
+- clock-names: Should be "stmmaceth" for the host clock.

We can remove host clock (stmmac eth) entry here and refer to
stmmac.txt binding for common entry

quoted

quoted

This doesn't sound like the clock input signal name...

quoted

quoted

+              Should be "tx-clk" for the MAC TX clock.
+              Should be "rx-clk" for the MAC RX clock.

How can other DWMAC blocks not have these clocks? The glue can't really
add these clocks. It could combine them into one or a new version of
DWMAC could have a different number of clock inputs. So if there is
variation here, then some of the bindings are probably wrong. I guess
the only change I'm suggesting is possibly moving these into common
binding doc.

The LPC18xx implementation probably have these clocks as well but the
LPC1850 user manual only documents the main clock. Someone with access
to the IP block doc from Synopsys should be able to check which clocks
the MAC really needs.

Rockchip bindings have two clocks named "mac_clk_rx" and "mac_clk_tx".
These are probably the same as stm32 needs so maybe use these names
and move them into the main doc and update the rockchip binding.

I think we can use same name. But I have a doubt on moving it in a
common bindings (maybe I don't well understood). When you say "common
binding file" is it "stmmac.txt" binding ? If yes does it mean that we
have to control it inside stmmac driver (no more in glue) ? In this
case those clocks will become "required" for stm32 and rockship but
not for others chip. It could create confusion?

A gentle ping. Can you give me your feedback please ?
I will send next patchset version according to your answer.

Thanks in advance

Alex

Best regards

Alex

quoted

regards,
Joachim Eastwood

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

On 3/22/2016 5:11 PM, Alexandre Torgue wrote:

Hi guys,

I will fix typo issues (s/vesrion/version and ethernet @).

Concerning compatible string. For sure "snps,dwmac-3.50a" string is
not used inside glue driver.
I perfere to keep it for information but if you really want that I
remove it I will not block ;)

2016-03-21 16:36 GMT+01:00 Joachim  Eastwood [off-list ref]:

quoted

On 21 March 2016 at 13:40, Rob Herring [off-list ref] wrote:

quoted

On Sat, Mar 19, 2016 at 12:00:22AM +0800, Chen-Yu Tsai wrote:

quoted

Hi,

On Fri, Mar 18, 2016 at 11:37 PM, Alexandre TORGUE
[off-list ref] wrote:

quoted

+- clocks: Must contain a phandle for each entry in clock-names.
+- clock-names: Should be "stmmaceth" for the host clock.

We can remove host clock (stmmac eth) entry here and refer to
stmmac.txt binding for common entry

quoted

quoted

This doesn't sound like the clock input signal name...

quoted

quoted

+              Should be "tx-clk" for the MAC TX clock.
+              Should be "rx-clk" for the MAC RX clock.

How can other DWMAC blocks not have these clocks? The glue can't really
add these clocks. It could combine them into one or a new version of
DWMAC could have a different number of clock inputs. So if there is
variation here, then some of the bindings are probably wrong. I guess
the only change I'm suggesting is possibly moving these into common
binding doc.

The LPC18xx implementation probably have these clocks as well but the
LPC1850 user manual only documents the main clock. Someone with access
to the IP block doc from Synopsys should be able to check which clocks
the MAC really needs.

Rockchip bindings have two clocks named "mac_clk_rx" and "mac_clk_tx".
These are probably the same as stm32 needs so maybe use these names
and move them into the main doc and update the rockchip binding.

I think we can use same name. But I have a doubt on moving it in a
common bindings (maybe I don't well understood). When you say "common
binding file" is it "stmmac.txt" binding ? If yes does it mean that we
have to control it inside stmmac driver (no more in glue) ? In this
case those clocks will become "required" for stm32 and rockship but
not for others chip. It could create confusion?

Currently we keep the "host" and "csr" " ptp  "clock from common
bindings because directly connected to the either MAC core or optional
internals modules.
Indeed, also clk_tx_i and clk_rx_i could be treated in the same way.
but... (my personal view).
Many platforms, also inside STi, have different clock routing schema,
so we could relax them giving each glue the way to internally manage
all (as done nowadays).
So these clocks can stay inside the glue and documented inside each
binding doc. Maybe, it could be not so easy to have generic schema
suitable for all the glues so documenting all inside the same binding
text file.
We could try to better name these clocks in each glue. For example, for
this, although I do not know the clk schema, I can image a single
rmii_clk (maybe from internal oscillator) that is connected to
clk_tx_i and clk_rx_i. So it could be useless to pass both. Please
let me know if I am wrong...
In case of (G)MII, we should use something like (g)mii_tx_clk,
(g)mii_rx_clk according to the real connections (if from
an internal oscillator and not from an ext one connected to the phy).

Regards,
Peppe

Best regards

Alex

quoted

regards,
Joachim Eastwood