All of lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH net-next v2 00/15] ARM: sun8i: r40: Add Ethernet support
@ 2018-05-01 16:12 ` Chen-Yu Tsai
  0 siblings, 0 replies; 80+ messages in thread
From: Chen-Yu Tsai @ 2018-05-01 16:12 UTC (permalink / raw)
  To: Maxime Ripard, Michael Turquette, Stephen Boyd,
	Giuseppe Cavallaro, Rob Herring, Mark Rutland, Mark Brown
  Cc: devicetree, netdev, Chen-Yu Tsai, Corentin Labbe, linux-clk,
	linux-arm-kernel, Icenowy Zheng

Hi everyone,

This is v2 of my R40 Ethernet support series.

Changes since v1:

  - Default to fetching regmap from device pointed to by syscon phandle,
    and falling back to syscon API if that fails.

  - Dropped .syscon_from_dev field in device data as a result of the
    previous change.

  - Added a large comment block explaining the first change.

  - Simplified description of syscon property in sun8i-dwmac binding.

  - Regmap now only exposes the EMAC/GMAC register, but retains the
    offset within its address space.

  - Added patches for A64, which reuse the same sun8i-dwmac changes.

This series adds support for the DWMAC based Ethernet controller found
on the Allwinner R40 SoC. The controller is either a DWMAC clone or
DWMAC core with its registers rearranged. This is already supported by
the dwmac-sun8i driver. The glue layer control registers, unlike other
sun8i family SoCs, is not in the system controller region, but in the
clock control unit, like with the older A20 and A31 SoCs.

While we reuse the bindings for dwmac-sun8i using a syscon phandle
reference, we need some custom plumbing for the clock driver to export
a regmap that only allows access to the GMAC register to the dwmac-sun8i
driver. An alternative would be to allow drivers to register custom
syscon devices with their own regmap and locking.

Patch 1 converts the CLK_OF_DECLARE style clock driver to a platform
one, so the regmap introduced later has a struct device to tie to.

Patch 2 adds a regmap that is exported by the clock driver for the
dwmac-sun8i driver to use.

Patches 3, 4, and 5 clean up the dwmac-sun8i binding.

Patch 6 adds device tree binding for Allwinner R40's Ethernet
controller.

Patch 7 converts regmap access of the syscon region in the dwmac-sun8i
driver to regmap_field, in anticipation of different field widths on
the R40.

Patch 8 introduces custom plumbing in the dwmac-sun8i driver to fetch
a regmap from another device, by looking up said device via a phandle,
then getting the regmap associated with that device.

Patch 9 adds support for different or absent TX/RX delay chain ranges
to the dwmac-sun8i driver.

Patch 10 adds support for the R40's ethernet controller.

Patch 11 cleans up the Bananapi M2 Ultra device tree file.

Patch 12 adds a GMAC device node and RGMII mode pinmux setting for the
R40.

Patch 13 enables Ethernet on the Bananapi M2 Ultra.

Patches 14 and 15 are for the A64. They convert the existing syscon
device to an SRAM controller device that exports a regmap. The needed
driver changes are in patch 14, and the device tree changes are in
patch 15.


Please have a look.

Regards
ChenYu

Chen-Yu Tsai (11):
  dt-bindings: net: dwmac-sun8i: Clean up clock delay chain descriptions
  dt-bindings: net: dwmac-sun8i: Sort syscon compatibles by alphabetical
    order
  dt-bindings: net: dwmac-sun8i: simplify description of syscon property
  dt-bindings: net: dwmac-sun8i: Add binding for GMAC on Allwinner R40
    SoC
  net: stmmac: dwmac-sun8i: Use regmap_field for syscon register access
  net: stmmac: dwmac-sun8i: Allow getting syscon regmap from external
    device
  net: stmmac: dwmac-sun8i: Support different ranges for TX/RX delay
    chains
  net: stmmac: dwmac-sun8i: Add support for GMAC on Allwinner R40 SoC
  ARM: dts: sun8i: r40: bananapi-m2-ultra: Sort device node dereferences
  ARM: dts: sun8i: r40: Add device node and RGMII pinmux node for GMAC
  ARM: dts: sun8i: r40: bananapi-m2-ultra: Enable GMAC ethernet
    controller

Icenowy Zheng (4):
  clk: sunxi-ng: r40: rewrite init code to a platform driver
  clk: sunxi-ng: r40: export a regmap to access the GMAC register
  soc: sunxi: export a regmap for EMAC clock reg on A64
  arm64: dts: allwinner: a64: add SRAM controller device tree node

 .../devicetree/bindings/net/dwmac-sun8i.txt   |  21 +--
 .../boot/dts/sun8i-r40-bananapi-m2-ultra.dts  |  99 ++++++++-----
 arch/arm/boot/dts/sun8i-r40.dtsi              |  34 +++++
 arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi |  23 ++-
 drivers/clk/sunxi-ng/ccu-sun8i-r40.c          |  72 +++++++--
 .../net/ethernet/stmicro/stmmac/dwmac-sun8i.c | 139 +++++++++++++++---
 drivers/soc/sunxi/sunxi_sram.c                |  57 ++++++-
 7 files changed, 364 insertions(+), 81 deletions(-)

-- 
2.17.0

^ permalink raw reply	[flat|nested] 80+ messages in thread
* [PATCH net-next v2 00/15] ARM: sun8i: r40: Add Ethernet support
@ 2018-05-01 16:12 ` Chen-Yu Tsai
  0 siblings, 0 replies; 80+ messages in thread
From: Chen-Yu Tsai @ 2018-05-01 16:12 UTC (permalink / raw)
  To: Maxime Ripard, Michael Turquette, Stephen Boyd,
	Giuseppe Cavallaro, Rob Herring, Mark Rutland, Mark Brown
  Cc: Chen-Yu Tsai, linux-arm-kernel, linux-clk, devicetree, netdev,
	Corentin Labbe, Icenowy Zheng

Hi everyone,

This is v2 of my R40 Ethernet support series.

Changes since v1:

  - Default to fetching regmap from device pointed to by syscon phandle,
    and falling back to syscon API if that fails.

  - Dropped .syscon_from_dev field in device data as a result of the
    previous change.

  - Added a large comment block explaining the first change.

  - Simplified description of syscon property in sun8i-dwmac binding.

  - Regmap now only exposes the EMAC/GMAC register, but retains the
    offset within its address space.

  - Added patches for A64, which reuse the same sun8i-dwmac changes.

This series adds support for the DWMAC based Ethernet controller found
on the Allwinner R40 SoC. The controller is either a DWMAC clone or
DWMAC core with its registers rearranged. This is already supported by
the dwmac-sun8i driver. The glue layer control registers, unlike other
sun8i family SoCs, is not in the system controller region, but in the
clock control unit, like with the older A20 and A31 SoCs.

While we reuse the bindings for dwmac-sun8i using a syscon phandle
reference, we need some custom plumbing for the clock driver to export
a regmap that only allows access to the GMAC register to the dwmac-sun8i
driver. An alternative would be to allow drivers to register custom
syscon devices with their own regmap and locking.

Patch 1 converts the CLK_OF_DECLARE style clock driver to a platform
one, so the regmap introduced later has a struct device to tie to.

Patch 2 adds a regmap that is exported by the clock driver for the
dwmac-sun8i driver to use.

Patches 3, 4, and 5 clean up the dwmac-sun8i binding.

Patch 6 adds device tree binding for Allwinner R40's Ethernet
controller.

Patch 7 converts regmap access of the syscon region in the dwmac-sun8i
driver to regmap_field, in anticipation of different field widths on
the R40.

Patch 8 introduces custom plumbing in the dwmac-sun8i driver to fetch
a regmap from another device, by looking up said device via a phandle,
then getting the regmap associated with that device.

Patch 9 adds support for different or absent TX/RX delay chain ranges
to the dwmac-sun8i driver.

Patch 10 adds support for the R40's ethernet controller.

Patch 11 cleans up the Bananapi M2 Ultra device tree file.

Patch 12 adds a GMAC device node and RGMII mode pinmux setting for the
R40.

Patch 13 enables Ethernet on the Bananapi M2 Ultra.

Patches 14 and 15 are for the A64. They convert the existing syscon
device to an SRAM controller device that exports a regmap. The needed
driver changes are in patch 14, and the device tree changes are in
patch 15.


Please have a look.

Regards
ChenYu

Chen-Yu Tsai (11):
  dt-bindings: net: dwmac-sun8i: Clean up clock delay chain descriptions
  dt-bindings: net: dwmac-sun8i: Sort syscon compatibles by alphabetical
    order
  dt-bindings: net: dwmac-sun8i: simplify description of syscon property
  dt-bindings: net: dwmac-sun8i: Add binding for GMAC on Allwinner R40
    SoC
  net: stmmac: dwmac-sun8i: Use regmap_field for syscon register access
  net: stmmac: dwmac-sun8i: Allow getting syscon regmap from external
    device
  net: stmmac: dwmac-sun8i: Support different ranges for TX/RX delay
    chains
  net: stmmac: dwmac-sun8i: Add support for GMAC on Allwinner R40 SoC
  ARM: dts: sun8i: r40: bananapi-m2-ultra: Sort device node dereferences
  ARM: dts: sun8i: r40: Add device node and RGMII pinmux node for GMAC
  ARM: dts: sun8i: r40: bananapi-m2-ultra: Enable GMAC ethernet
    controller

Icenowy Zheng (4):
  clk: sunxi-ng: r40: rewrite init code to a platform driver
  clk: sunxi-ng: r40: export a regmap to access the GMAC register
  soc: sunxi: export a regmap for EMAC clock reg on A64
  arm64: dts: allwinner: a64: add SRAM controller device tree node

 .../devicetree/bindings/net/dwmac-sun8i.txt   |  21 +--
 .../boot/dts/sun8i-r40-bananapi-m2-ultra.dts  |  99 ++++++++-----
 arch/arm/boot/dts/sun8i-r40.dtsi              |  34 +++++
 arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi |  23 ++-
 drivers/clk/sunxi-ng/ccu-sun8i-r40.c          |  72 +++++++--
 .../net/ethernet/stmicro/stmmac/dwmac-sun8i.c | 139 +++++++++++++++---
 drivers/soc/sunxi/sunxi_sram.c                |  57 ++++++-
 7 files changed, 364 insertions(+), 81 deletions(-)

-- 
2.17.0

^ permalink raw reply	[flat|nested] 80+ messages in thread
* [PATCH net-next v2 00/15] ARM: sun8i: r40: Add Ethernet support
@ 2018-05-01 16:12 ` Chen-Yu Tsai
  0 siblings, 0 replies; 80+ messages in thread
From: Chen-Yu Tsai @ 2018-05-01 16:12 UTC (permalink / raw)
  To: linux-arm-kernel

Hi everyone,

This is v2 of my R40 Ethernet support series.

Changes since v1:

  - Default to fetching regmap from device pointed to by syscon phandle,
    and falling back to syscon API if that fails.

  - Dropped .syscon_from_dev field in device data as a result of the
    previous change.

  - Added a large comment block explaining the first change.

  - Simplified description of syscon property in sun8i-dwmac binding.

  - Regmap now only exposes the EMAC/GMAC register, but retains the
    offset within its address space.

  - Added patches for A64, which reuse the same sun8i-dwmac changes.

This series adds support for the DWMAC based Ethernet controller found
on the Allwinner R40 SoC. The controller is either a DWMAC clone or
DWMAC core with its registers rearranged. This is already supported by
the dwmac-sun8i driver. The glue layer control registers, unlike other
sun8i family SoCs, is not in the system controller region, but in the
clock control unit, like with the older A20 and A31 SoCs.

While we reuse the bindings for dwmac-sun8i using a syscon phandle
reference, we need some custom plumbing for the clock driver to export
a regmap that only allows access to the GMAC register to the dwmac-sun8i
driver. An alternative would be to allow drivers to register custom
syscon devices with their own regmap and locking.

Patch 1 converts the CLK_OF_DECLARE style clock driver to a platform
one, so the regmap introduced later has a struct device to tie to.

Patch 2 adds a regmap that is exported by the clock driver for the
dwmac-sun8i driver to use.

Patches 3, 4, and 5 clean up the dwmac-sun8i binding.

Patch 6 adds device tree binding for Allwinner R40's Ethernet
controller.

Patch 7 converts regmap access of the syscon region in the dwmac-sun8i
driver to regmap_field, in anticipation of different field widths on
the R40.

Patch 8 introduces custom plumbing in the dwmac-sun8i driver to fetch
a regmap from another device, by looking up said device via a phandle,
then getting the regmap associated with that device.

Patch 9 adds support for different or absent TX/RX delay chain ranges
to the dwmac-sun8i driver.

Patch 10 adds support for the R40's ethernet controller.

Patch 11 cleans up the Bananapi M2 Ultra device tree file.

Patch 12 adds a GMAC device node and RGMII mode pinmux setting for the
R40.

Patch 13 enables Ethernet on the Bananapi M2 Ultra.

Patches 14 and 15 are for the A64. They convert the existing syscon
device to an SRAM controller device that exports a regmap. The needed
driver changes are in patch 14, and the device tree changes are in
patch 15.


Please have a look.

Regards
ChenYu

Chen-Yu Tsai (11):
  dt-bindings: net: dwmac-sun8i: Clean up clock delay chain descriptions
  dt-bindings: net: dwmac-sun8i: Sort syscon compatibles by alphabetical
    order
  dt-bindings: net: dwmac-sun8i: simplify description of syscon property
  dt-bindings: net: dwmac-sun8i: Add binding for GMAC on Allwinner R40
    SoC
  net: stmmac: dwmac-sun8i: Use regmap_field for syscon register access
  net: stmmac: dwmac-sun8i: Allow getting syscon regmap from external
    device
  net: stmmac: dwmac-sun8i: Support different ranges for TX/RX delay
    chains
  net: stmmac: dwmac-sun8i: Add support for GMAC on Allwinner R40 SoC
  ARM: dts: sun8i: r40: bananapi-m2-ultra: Sort device node dereferences
  ARM: dts: sun8i: r40: Add device node and RGMII pinmux node for GMAC
  ARM: dts: sun8i: r40: bananapi-m2-ultra: Enable GMAC ethernet
    controller

Icenowy Zheng (4):
  clk: sunxi-ng: r40: rewrite init code to a platform driver
  clk: sunxi-ng: r40: export a regmap to access the GMAC register
  soc: sunxi: export a regmap for EMAC clock reg on A64
  arm64: dts: allwinner: a64: add SRAM controller device tree node

 .../devicetree/bindings/net/dwmac-sun8i.txt   |  21 +--
 .../boot/dts/sun8i-r40-bananapi-m2-ultra.dts  |  99 ++++++++-----
 arch/arm/boot/dts/sun8i-r40.dtsi              |  34 +++++
 arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi |  23 ++-
 drivers/clk/sunxi-ng/ccu-sun8i-r40.c          |  72 +++++++--
 .../net/ethernet/stmicro/stmmac/dwmac-sun8i.c | 139 +++++++++++++++---
 drivers/soc/sunxi/sunxi_sram.c                |  57 ++++++-
 7 files changed, 364 insertions(+), 81 deletions(-)

-- 
2.17.0

^ permalink raw reply	[flat|nested] 80+ messages in thread
* [PATCH net-next v2 01/15] clk: sunxi-ng: r40: rewrite init code to a platform driver
  2018-05-01 16:12 ` Chen-Yu Tsai
  (?)
@ 2018-05-01 16:12   ` Chen-Yu Tsai
  -1 siblings, 0 replies; 80+ messages in thread
From: Chen-Yu Tsai @ 2018-05-01 16:12 UTC (permalink / raw)
  To: Maxime Ripard, Michael Turquette, Stephen Boyd,
	Giuseppe Cavallaro, Rob Herring, Mark Rutland, Mark Brown
  Cc: devicetree, netdev, Chen-Yu Tsai, Corentin Labbe, linux-clk,
	linux-arm-kernel, Icenowy Zheng

From: Icenowy Zheng <icenowy@aosc.io>

As we need to register a regmap on the R40 CCU, there needs to be a
device structure bound to the CCU device node.

Rewrite the R40 CCU driver initial code to make it a proper platform
driver, thus we will have a platform device bound to it.

Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
Signed-off-by: Chen-Yu Tsai <wens@csie.org>
---
 drivers/clk/sunxi-ng/ccu-sun8i-r40.c | 39 ++++++++++++++++++++--------
 1 file changed, 28 insertions(+), 11 deletions(-)

diff --git a/drivers/clk/sunxi-ng/ccu-sun8i-r40.c b/drivers/clk/sunxi-ng/ccu-sun8i-r40.c
index 933f2e68f42a..c3aa839a453d 100644
--- a/drivers/clk/sunxi-ng/ccu-sun8i-r40.c
+++ b/drivers/clk/sunxi-ng/ccu-sun8i-r40.c
@@ -12,7 +12,8 @@
  */
 
 #include <linux/clk-provider.h>
-#include <linux/of_address.h>
+#include <linux/platform_device.h>
+#include <linux/regmap.h>
 
 #include "ccu_common.h"
 #include "ccu_reset.h"
@@ -1250,17 +1251,17 @@ static struct ccu_mux_nb sun8i_r40_cpu_nb = {
 	.bypass_index	= 1, /* index of 24 MHz oscillator */
 };
 
-static void __init sun8i_r40_ccu_setup(struct device_node *node)
+static int sun8i_r40_ccu_probe(struct platform_device *pdev)
 {
+	struct resource *res;
 	void __iomem *reg;
 	u32 val;
+	int ret;
 
-	reg = of_io_request_and_map(node, 0, of_node_full_name(node));
-	if (IS_ERR(reg)) {
-		pr_err("%s: Could not map the clock registers\n",
-		       of_node_full_name(node));
-		return;
-	}
+	res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+	reg = devm_ioremap_resource(&pdev->dev, res);
+	if (IS_ERR(reg))
+		return PTR_ERR(reg);
 
 	/* Force the PLL-Audio-1x divider to 4 */
 	val = readl(reg + SUN8I_R40_PLL_AUDIO_REG);
@@ -1277,7 +1278,9 @@ static void __init sun8i_r40_ccu_setup(struct device_node *node)
 	val &= ~GENMASK(25, 20);
 	writel(val, reg + SUN8I_R40_USB_CLK_REG);
 
-	sunxi_ccu_probe(node, reg, &sun8i_r40_ccu_desc);
+	ret = sunxi_ccu_probe(pdev->dev.of_node, reg, &sun8i_r40_ccu_desc);
+	if (ret)
+		return ret;
 
 	/* Gate then ungate PLL CPU after any rate changes */
 	ccu_pll_notifier_register(&sun8i_r40_pll_cpu_nb);
@@ -1285,6 +1288,20 @@ static void __init sun8i_r40_ccu_setup(struct device_node *node)
 	/* Reparent CPU during PLL CPU rate changes */
 	ccu_mux_notifier_register(pll_cpu_clk.common.hw.clk,
 				  &sun8i_r40_cpu_nb);
+
+	return 0;
 }
-CLK_OF_DECLARE(sun8i_r40_ccu, "allwinner,sun8i-r40-ccu",
-	       sun8i_r40_ccu_setup);
+
+static const struct of_device_id sun8i_r40_ccu_ids[] = {
+	{ .compatible = "allwinner,sun8i-r40-ccu" },
+	{ }
+};
+
+static struct platform_driver sun8i_r40_ccu_driver = {
+	.probe	= sun8i_r40_ccu_probe,
+	.driver	= {
+		.name	= "sun8i-r40-ccu",
+		.of_match_table	= sun8i_r40_ccu_ids,
+	},
+};
+builtin_platform_driver(sun8i_r40_ccu_driver);
-- 
2.17.0

^ permalink raw reply related	[flat|nested] 80+ messages in thread
* [PATCH net-next v2 01/15] clk: sunxi-ng: r40: rewrite init code to a platform driver
@ 2018-05-01 16:12   ` Chen-Yu Tsai
  0 siblings, 0 replies; 80+ messages in thread
From: Chen-Yu Tsai @ 2018-05-01 16:12 UTC (permalink / raw)
  To: Maxime Ripard, Michael Turquette, Stephen Boyd,
	Giuseppe Cavallaro, Rob Herring, Mark Rutland, Mark Brown
  Cc: Icenowy Zheng, linux-arm-kernel, linux-clk, devicetree, netdev,
	Corentin Labbe, Chen-Yu Tsai

From: Icenowy Zheng <icenowy@aosc.io>

As we need to register a regmap on the R40 CCU, there needs to be a
device structure bound to the CCU device node.

Rewrite the R40 CCU driver initial code to make it a proper platform
driver, thus we will have a platform device bound to it.

Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
Signed-off-by: Chen-Yu Tsai <wens@csie.org>
---
 drivers/clk/sunxi-ng/ccu-sun8i-r40.c | 39 ++++++++++++++++++++--------
 1 file changed, 28 insertions(+), 11 deletions(-)

diff --git a/drivers/clk/sunxi-ng/ccu-sun8i-r40.c b/drivers/clk/sunxi-ng/ccu-sun8i-r40.c
index 933f2e68f42a..c3aa839a453d 100644
--- a/drivers/clk/sunxi-ng/ccu-sun8i-r40.c
+++ b/drivers/clk/sunxi-ng/ccu-sun8i-r40.c
@@ -12,7 +12,8 @@
  */
 
 #include <linux/clk-provider.h>
-#include <linux/of_address.h>
+#include <linux/platform_device.h>
+#include <linux/regmap.h>
 
 #include "ccu_common.h"
 #include "ccu_reset.h"
@@ -1250,17 +1251,17 @@ static struct ccu_mux_nb sun8i_r40_cpu_nb = {
 	.bypass_index	= 1, /* index of 24 MHz oscillator */
 };
 
-static void __init sun8i_r40_ccu_setup(struct device_node *node)
+static int sun8i_r40_ccu_probe(struct platform_device *pdev)
 {
+	struct resource *res;
 	void __iomem *reg;
 	u32 val;
+	int ret;
 
-	reg = of_io_request_and_map(node, 0, of_node_full_name(node));
-	if (IS_ERR(reg)) {
-		pr_err("%s: Could not map the clock registers\n",
-		       of_node_full_name(node));
-		return;
-	}
+	res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+	reg = devm_ioremap_resource(&pdev->dev, res);
+	if (IS_ERR(reg))
+		return PTR_ERR(reg);
 
 	/* Force the PLL-Audio-1x divider to 4 */
 	val = readl(reg + SUN8I_R40_PLL_AUDIO_REG);
@@ -1277,7 +1278,9 @@ static void __init sun8i_r40_ccu_setup(struct device_node *node)
 	val &= ~GENMASK(25, 20);
 	writel(val, reg + SUN8I_R40_USB_CLK_REG);
 
-	sunxi_ccu_probe(node, reg, &sun8i_r40_ccu_desc);
+	ret = sunxi_ccu_probe(pdev->dev.of_node, reg, &sun8i_r40_ccu_desc);
+	if (ret)
+		return ret;
 
 	/* Gate then ungate PLL CPU after any rate changes */
 	ccu_pll_notifier_register(&sun8i_r40_pll_cpu_nb);
@@ -1285,6 +1288,20 @@ static void __init sun8i_r40_ccu_setup(struct device_node *node)
 	/* Reparent CPU during PLL CPU rate changes */
 	ccu_mux_notifier_register(pll_cpu_clk.common.hw.clk,
 				  &sun8i_r40_cpu_nb);
+
+	return 0;
 }
-CLK_OF_DECLARE(sun8i_r40_ccu, "allwinner,sun8i-r40-ccu",
-	       sun8i_r40_ccu_setup);
+
+static const struct of_device_id sun8i_r40_ccu_ids[] = {
+	{ .compatible = "allwinner,sun8i-r40-ccu" },
+	{ }
+};
+
+static struct platform_driver sun8i_r40_ccu_driver = {
+	.probe	= sun8i_r40_ccu_probe,
+	.driver	= {
+		.name	= "sun8i-r40-ccu",
+		.of_match_table	= sun8i_r40_ccu_ids,
+	},
+};
+builtin_platform_driver(sun8i_r40_ccu_driver);
-- 
2.17.0

^ permalink raw reply related	[flat|nested] 80+ messages in thread
* [PATCH net-next v2 01/15] clk: sunxi-ng: r40: rewrite init code to a platform driver
@ 2018-05-01 16:12   ` Chen-Yu Tsai
  0 siblings, 0 replies; 80+ messages in thread
From: Chen-Yu Tsai @ 2018-05-01 16:12 UTC (permalink / raw)
  To: linux-arm-kernel

From: Icenowy Zheng <icenowy@aosc.io>

As we need to register a regmap on the R40 CCU, there needs to be a
device structure bound to the CCU device node.

Rewrite the R40 CCU driver initial code to make it a proper platform
driver, thus we will have a platform device bound to it.

Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
Signed-off-by: Chen-Yu Tsai <wens@csie.org>
---
 drivers/clk/sunxi-ng/ccu-sun8i-r40.c | 39 ++++++++++++++++++++--------
 1 file changed, 28 insertions(+), 11 deletions(-)

diff --git a/drivers/clk/sunxi-ng/ccu-sun8i-r40.c b/drivers/clk/sunxi-ng/ccu-sun8i-r40.c
index 933f2e68f42a..c3aa839a453d 100644
--- a/drivers/clk/sunxi-ng/ccu-sun8i-r40.c
+++ b/drivers/clk/sunxi-ng/ccu-sun8i-r40.c
@@ -12,7 +12,8 @@
  */
 
 #include <linux/clk-provider.h>
-#include <linux/of_address.h>
+#include <linux/platform_device.h>
+#include <linux/regmap.h>
 
 #include "ccu_common.h"
 #include "ccu_reset.h"
@@ -1250,17 +1251,17 @@ static struct ccu_mux_nb sun8i_r40_cpu_nb = {
 	.bypass_index	= 1, /* index of 24 MHz oscillator */
 };
 
-static void __init sun8i_r40_ccu_setup(struct device_node *node)
+static int sun8i_r40_ccu_probe(struct platform_device *pdev)
 {
+	struct resource *res;
 	void __iomem *reg;
 	u32 val;
+	int ret;
 
-	reg = of_io_request_and_map(node, 0, of_node_full_name(node));
-	if (IS_ERR(reg)) {
-		pr_err("%s: Could not map the clock registers\n",
-		       of_node_full_name(node));
-		return;
-	}
+	res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+	reg = devm_ioremap_resource(&pdev->dev, res);
+	if (IS_ERR(reg))
+		return PTR_ERR(reg);
 
 	/* Force the PLL-Audio-1x divider to 4 */
 	val = readl(reg + SUN8I_R40_PLL_AUDIO_REG);
@@ -1277,7 +1278,9 @@ static void __init sun8i_r40_ccu_setup(struct device_node *node)
 	val &= ~GENMASK(25, 20);
 	writel(val, reg + SUN8I_R40_USB_CLK_REG);
 
-	sunxi_ccu_probe(node, reg, &sun8i_r40_ccu_desc);
+	ret = sunxi_ccu_probe(pdev->dev.of_node, reg, &sun8i_r40_ccu_desc);
+	if (ret)
+		return ret;
 
 	/* Gate then ungate PLL CPU after any rate changes */
 	ccu_pll_notifier_register(&sun8i_r40_pll_cpu_nb);
@@ -1285,6 +1288,20 @@ static void __init sun8i_r40_ccu_setup(struct device_node *node)
 	/* Reparent CPU during PLL CPU rate changes */
 	ccu_mux_notifier_register(pll_cpu_clk.common.hw.clk,
 				  &sun8i_r40_cpu_nb);
+
+	return 0;
 }
-CLK_OF_DECLARE(sun8i_r40_ccu, "allwinner,sun8i-r40-ccu",
-	       sun8i_r40_ccu_setup);
+
+static const struct of_device_id sun8i_r40_ccu_ids[] = {
+	{ .compatible = "allwinner,sun8i-r40-ccu" },
+	{ }
+};
+
+static struct platform_driver sun8i_r40_ccu_driver = {
+	.probe	= sun8i_r40_ccu_probe,
+	.driver	= {
+		.name	= "sun8i-r40-ccu",
+		.of_match_table	= sun8i_r40_ccu_ids,
+	},
+};
+builtin_platform_driver(sun8i_r40_ccu_driver);
-- 
2.17.0

^ permalink raw reply related	[flat|nested] 80+ messages in thread
* [PATCH net-next v2 02/15] clk: sunxi-ng: r40: export a regmap to access the GMAC register
  2018-05-01 16:12 ` Chen-Yu Tsai
  (?)
@ 2018-05-01 16:12   ` Chen-Yu Tsai
  -1 siblings, 0 replies; 80+ messages in thread
From: Chen-Yu Tsai @ 2018-05-01 16:12 UTC (permalink / raw)
  To: Maxime Ripard, Michael Turquette, Stephen Boyd,
	Giuseppe Cavallaro, Rob Herring, Mark Rutland, Mark Brown
  Cc: devicetree, netdev, Chen-Yu Tsai, Corentin Labbe, linux-clk,
	linux-arm-kernel, Icenowy Zheng

From: Icenowy Zheng <icenowy@aosc.io>

There's a GMAC configuration register, which exists on A64/A83T/H3/H5 in
the syscon part, in the CCU of R40 SoC.

Export a regmap of the CCU.

Read access is not restricted to all registers, but only the GMAC
register is allowed to be written.

Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
Signed-off-by: Chen-Yu Tsai <wens@csie.org>
---
 drivers/clk/sunxi-ng/ccu-sun8i-r40.c | 33 ++++++++++++++++++++++++++++
 1 file changed, 33 insertions(+)

diff --git a/drivers/clk/sunxi-ng/ccu-sun8i-r40.c b/drivers/clk/sunxi-ng/ccu-sun8i-r40.c
index c3aa839a453d..65ba6455feb7 100644
--- a/drivers/clk/sunxi-ng/ccu-sun8i-r40.c
+++ b/drivers/clk/sunxi-ng/ccu-sun8i-r40.c
@@ -1251,9 +1251,37 @@ static struct ccu_mux_nb sun8i_r40_cpu_nb = {
 	.bypass_index	= 1, /* index of 24 MHz oscillator */
 };
 
+/*
+ * Add a regmap for the GMAC driver (dwmac-sun8i) to access the
+ * GMAC configuration register.
+ * Only this register is allowed to be written, in order to
+ * prevent overriding critical clock configuration.
+ */
+
+#define SUN8I_R40_GMAC_CFG_REG 0x164
+static bool sun8i_r40_ccu_regmap_accessible_reg(struct device *dev,
+						unsigned int reg)
+{
+	if (reg == SUN8I_R40_GMAC_CFG_REG)
+		return true;
+	return false;
+}
+
+static struct regmap_config sun8i_r40_ccu_regmap_config = {
+	.reg_bits	= 32,
+	.val_bits	= 32,
+	.reg_stride	= 4,
+	.max_register	= 0x320, /* PLL_LOCK_CTRL_REG */
+
+	/* other devices have no business accessing other registers */
+	.readable_reg	= sun8i_r40_ccu_regmap_accessible_reg,
+	.writeable_reg	= sun8i_r40_ccu_regmap_accessible_reg,
+};
+
 static int sun8i_r40_ccu_probe(struct platform_device *pdev)
 {
 	struct resource *res;
+	struct regmap *regmap;
 	void __iomem *reg;
 	u32 val;
 	int ret;
@@ -1278,6 +1306,11 @@ static int sun8i_r40_ccu_probe(struct platform_device *pdev)
 	val &= ~GENMASK(25, 20);
 	writel(val, reg + SUN8I_R40_USB_CLK_REG);
 
+	regmap = devm_regmap_init_mmio(&pdev->dev, reg,
+				       &sun8i_r40_ccu_regmap_config);
+	if (IS_ERR(regmap))
+		return PTR_ERR(regmap);
+
 	ret = sunxi_ccu_probe(pdev->dev.of_node, reg, &sun8i_r40_ccu_desc);
 	if (ret)
 		return ret;
-- 
2.17.0

^ permalink raw reply related	[flat|nested] 80+ messages in thread
* [PATCH net-next v2 02/15] clk: sunxi-ng: r40: export a regmap to access the GMAC register
@ 2018-05-01 16:12   ` Chen-Yu Tsai
  0 siblings, 0 replies; 80+ messages in thread
From: Chen-Yu Tsai @ 2018-05-01 16:12 UTC (permalink / raw)
  To: Maxime Ripard, Michael Turquette, Stephen Boyd,
	Giuseppe Cavallaro, Rob Herring, Mark Rutland, Mark Brown
  Cc: Icenowy Zheng, linux-arm-kernel, linux-clk, devicetree, netdev,
	Corentin Labbe, Chen-Yu Tsai

From: Icenowy Zheng <icenowy@aosc.io>

There's a GMAC configuration register, which exists on A64/A83T/H3/H5 in
the syscon part, in the CCU of R40 SoC.

Export a regmap of the CCU.

Read access is not restricted to all registers, but only the GMAC
register is allowed to be written.

Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
Signed-off-by: Chen-Yu Tsai <wens@csie.org>
---
 drivers/clk/sunxi-ng/ccu-sun8i-r40.c | 33 ++++++++++++++++++++++++++++
 1 file changed, 33 insertions(+)

diff --git a/drivers/clk/sunxi-ng/ccu-sun8i-r40.c b/drivers/clk/sunxi-ng/ccu-sun8i-r40.c
index c3aa839a453d..65ba6455feb7 100644
--- a/drivers/clk/sunxi-ng/ccu-sun8i-r40.c
+++ b/drivers/clk/sunxi-ng/ccu-sun8i-r40.c
@@ -1251,9 +1251,37 @@ static struct ccu_mux_nb sun8i_r40_cpu_nb = {
 	.bypass_index	= 1, /* index of 24 MHz oscillator */
 };
 
+/*
+ * Add a regmap for the GMAC driver (dwmac-sun8i) to access the
+ * GMAC configuration register.
+ * Only this register is allowed to be written, in order to
+ * prevent overriding critical clock configuration.
+ */
+
+#define SUN8I_R40_GMAC_CFG_REG 0x164
+static bool sun8i_r40_ccu_regmap_accessible_reg(struct device *dev,
+						unsigned int reg)
+{
+	if (reg == SUN8I_R40_GMAC_CFG_REG)
+		return true;
+	return false;
+}
+
+static struct regmap_config sun8i_r40_ccu_regmap_config = {
+	.reg_bits	= 32,
+	.val_bits	= 32,
+	.reg_stride	= 4,
+	.max_register	= 0x320, /* PLL_LOCK_CTRL_REG */
+
+	/* other devices have no business accessing other registers */
+	.readable_reg	= sun8i_r40_ccu_regmap_accessible_reg,
+	.writeable_reg	= sun8i_r40_ccu_regmap_accessible_reg,
+};
+
 static int sun8i_r40_ccu_probe(struct platform_device *pdev)
 {
 	struct resource *res;
+	struct regmap *regmap;
 	void __iomem *reg;
 	u32 val;
 	int ret;
@@ -1278,6 +1306,11 @@ static int sun8i_r40_ccu_probe(struct platform_device *pdev)
 	val &= ~GENMASK(25, 20);
 	writel(val, reg + SUN8I_R40_USB_CLK_REG);
 
+	regmap = devm_regmap_init_mmio(&pdev->dev, reg,
+				       &sun8i_r40_ccu_regmap_config);
+	if (IS_ERR(regmap))
+		return PTR_ERR(regmap);
+
 	ret = sunxi_ccu_probe(pdev->dev.of_node, reg, &sun8i_r40_ccu_desc);
 	if (ret)
 		return ret;
-- 
2.17.0

^ permalink raw reply related	[flat|nested] 80+ messages in thread
* [PATCH net-next v2 02/15] clk: sunxi-ng: r40: export a regmap to access the GMAC register
@ 2018-05-01 16:12   ` Chen-Yu Tsai
  0 siblings, 0 replies; 80+ messages in thread
From: Chen-Yu Tsai @ 2018-05-01 16:12 UTC (permalink / raw)
  To: linux-arm-kernel

From: Icenowy Zheng <icenowy@aosc.io>

There's a GMAC configuration register, which exists on A64/A83T/H3/H5 in
the syscon part, in the CCU of R40 SoC.

Export a regmap of the CCU.

Read access is not restricted to all registers, but only the GMAC
register is allowed to be written.

Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
Signed-off-by: Chen-Yu Tsai <wens@csie.org>
---
 drivers/clk/sunxi-ng/ccu-sun8i-r40.c | 33 ++++++++++++++++++++++++++++
 1 file changed, 33 insertions(+)

diff --git a/drivers/clk/sunxi-ng/ccu-sun8i-r40.c b/drivers/clk/sunxi-ng/ccu-sun8i-r40.c
index c3aa839a453d..65ba6455feb7 100644
--- a/drivers/clk/sunxi-ng/ccu-sun8i-r40.c
+++ b/drivers/clk/sunxi-ng/ccu-sun8i-r40.c
@@ -1251,9 +1251,37 @@ static struct ccu_mux_nb sun8i_r40_cpu_nb = {
 	.bypass_index	= 1, /* index of 24 MHz oscillator */
 };
 
+/*
+ * Add a regmap for the GMAC driver (dwmac-sun8i) to access the
+ * GMAC configuration register.
+ * Only this register is allowed to be written, in order to
+ * prevent overriding critical clock configuration.
+ */
+
+#define SUN8I_R40_GMAC_CFG_REG 0x164
+static bool sun8i_r40_ccu_regmap_accessible_reg(struct device *dev,
+						unsigned int reg)
+{
+	if (reg == SUN8I_R40_GMAC_CFG_REG)
+		return true;
+	return false;
+}
+
+static struct regmap_config sun8i_r40_ccu_regmap_config = {
+	.reg_bits	= 32,
+	.val_bits	= 32,
+	.reg_stride	= 4,
+	.max_register	= 0x320, /* PLL_LOCK_CTRL_REG */
+
+	/* other devices have no business accessing other registers */
+	.readable_reg	= sun8i_r40_ccu_regmap_accessible_reg,
+	.writeable_reg	= sun8i_r40_ccu_regmap_accessible_reg,
+};
+
 static int sun8i_r40_ccu_probe(struct platform_device *pdev)
 {
 	struct resource *res;
+	struct regmap *regmap;
 	void __iomem *reg;
 	u32 val;
 	int ret;
@@ -1278,6 +1306,11 @@ static int sun8i_r40_ccu_probe(struct platform_device *pdev)
 	val &= ~GENMASK(25, 20);
 	writel(val, reg + SUN8I_R40_USB_CLK_REG);
 
+	regmap = devm_regmap_init_mmio(&pdev->dev, reg,
+				       &sun8i_r40_ccu_regmap_config);
+	if (IS_ERR(regmap))
+		return PTR_ERR(regmap);
+
 	ret = sunxi_ccu_probe(pdev->dev.of_node, reg, &sun8i_r40_ccu_desc);
 	if (ret)
 		return ret;
-- 
2.17.0

^ permalink raw reply related	[flat|nested] 80+ messages in thread
* [PATCH net-next v2 03/15] dt-bindings: net: dwmac-sun8i: Clean up clock delay chain descriptions
  2018-05-01 16:12 ` Chen-Yu Tsai
  (?)
@ 2018-05-01 16:12   ` Chen-Yu Tsai
  -1 siblings, 0 replies; 80+ messages in thread
From: Chen-Yu Tsai @ 2018-05-01 16:12 UTC (permalink / raw)
  To: Maxime Ripard, Michael Turquette, Stephen Boyd,
	Giuseppe Cavallaro, Rob Herring, Mark Rutland, Mark Brown
  Cc: devicetree, netdev, Chen-Yu Tsai, Corentin Labbe, linux-clk,
	linux-arm-kernel, Icenowy Zheng

The clock delay chains found in the glue layer for dwmac-sun8i are only
used with RGMII PHYs. They are not intended for non-RGMII PHYs, such as
MII external PHYs or the internal PHY. Also, a recent SoC has a smaller
range of possible values for the delay chain.

This patch reformats the delay chain section of the device tree binding
to make it clear that the delay chains only apply to RGMII PHYs, and
make it easier to add the R40-specific bits later.

Signed-off-by: Chen-Yu Tsai <wens@csie.org>
---
 Documentation/devicetree/bindings/net/dwmac-sun8i.txt | 11 +++++++----
 1 file changed, 7 insertions(+), 4 deletions(-)

diff --git a/Documentation/devicetree/bindings/net/dwmac-sun8i.txt b/Documentation/devicetree/bindings/net/dwmac-sun8i.txt
index 3d6d5fa0c4d5..e04ce75e24a3 100644
--- a/Documentation/devicetree/bindings/net/dwmac-sun8i.txt
+++ b/Documentation/devicetree/bindings/net/dwmac-sun8i.txt
@@ -28,10 +28,13 @@ Required properties:
   - allwinner,sun8i-a83t-system-controller
 
 Optional properties:
-- allwinner,tx-delay-ps: TX clock delay chain value in ps. Range value is 0-700. Default is 0)
-- allwinner,rx-delay-ps: RX clock delay chain value in ps. Range value is 0-3100. Default is 0)
-Both delay properties need to be a multiple of 100. They control the delay for
-external PHY.
+- allwinner,tx-delay-ps: TX clock delay chain value in ps.
+			 Range is 0-700. Default is 0.
+- allwinner,rx-delay-ps: RX clock delay chain value in ps.
+			 Range is 0-3100. Default is 0.
+Both delay properties need to be a multiple of 100. They control the
+clock delay for external RGMII PHY. They do not apply to the internal
+PHY or external non-RGMII PHYs.
 
 Optional properties for the following compatibles:
   - "allwinner,sun8i-h3-emac",
-- 
2.17.0

^ permalink raw reply related	[flat|nested] 80+ messages in thread
* [PATCH net-next v2 03/15] dt-bindings: net: dwmac-sun8i: Clean up clock delay chain descriptions
@ 2018-05-01 16:12   ` Chen-Yu Tsai
  0 siblings, 0 replies; 80+ messages in thread
From: Chen-Yu Tsai @ 2018-05-01 16:12 UTC (permalink / raw)
  To: Maxime Ripard, Michael Turquette, Stephen Boyd,
	Giuseppe Cavallaro, Rob Herring, Mark Rutland, Mark Brown
  Cc: Chen-Yu Tsai, linux-arm-kernel, linux-clk, devicetree, netdev,
	Corentin Labbe, Icenowy Zheng

The clock delay chains found in the glue layer for dwmac-sun8i are only
used with RGMII PHYs. They are not intended for non-RGMII PHYs, such as
MII external PHYs or the internal PHY. Also, a recent SoC has a smaller
range of possible values for the delay chain.

This patch reformats the delay chain section of the device tree binding
to make it clear that the delay chains only apply to RGMII PHYs, and
make it easier to add the R40-specific bits later.

Signed-off-by: Chen-Yu Tsai <wens@csie.org>
---
 Documentation/devicetree/bindings/net/dwmac-sun8i.txt | 11 +++++++----
 1 file changed, 7 insertions(+), 4 deletions(-)

diff --git a/Documentation/devicetree/bindings/net/dwmac-sun8i.txt b/Documentation/devicetree/bindings/net/dwmac-sun8i.txt
index 3d6d5fa0c4d5..e04ce75e24a3 100644
--- a/Documentation/devicetree/bindings/net/dwmac-sun8i.txt
+++ b/Documentation/devicetree/bindings/net/dwmac-sun8i.txt
@@ -28,10 +28,13 @@ Required properties:
   - allwinner,sun8i-a83t-system-controller
 
 Optional properties:
-- allwinner,tx-delay-ps: TX clock delay chain value in ps. Range value is 0-700. Default is 0)
-- allwinner,rx-delay-ps: RX clock delay chain value in ps. Range value is 0-3100. Default is 0)
-Both delay properties need to be a multiple of 100. They control the delay for
-external PHY.
+- allwinner,tx-delay-ps: TX clock delay chain value in ps.
+			 Range is 0-700. Default is 0.
+- allwinner,rx-delay-ps: RX clock delay chain value in ps.
+			 Range is 0-3100. Default is 0.
+Both delay properties need to be a multiple of 100. They control the
+clock delay for external RGMII PHY. They do not apply to the internal
+PHY or external non-RGMII PHYs.
 
 Optional properties for the following compatibles:
   - "allwinner,sun8i-h3-emac",
-- 
2.17.0

^ permalink raw reply related	[flat|nested] 80+ messages in thread
* [PATCH net-next v2 03/15] dt-bindings: net: dwmac-sun8i: Clean up clock delay chain descriptions
@ 2018-05-01 16:12   ` Chen-Yu Tsai
  0 siblings, 0 replies; 80+ messages in thread
From: Chen-Yu Tsai @ 2018-05-01 16:12 UTC (permalink / raw)
  To: linux-arm-kernel

The clock delay chains found in the glue layer for dwmac-sun8i are only
used with RGMII PHYs. They are not intended for non-RGMII PHYs, such as
MII external PHYs or the internal PHY. Also, a recent SoC has a smaller
range of possible values for the delay chain.

This patch reformats the delay chain section of the device tree binding
to make it clear that the delay chains only apply to RGMII PHYs, and
make it easier to add the R40-specific bits later.

Signed-off-by: Chen-Yu Tsai <wens@csie.org>
---
 Documentation/devicetree/bindings/net/dwmac-sun8i.txt | 11 +++++++----
 1 file changed, 7 insertions(+), 4 deletions(-)

diff --git a/Documentation/devicetree/bindings/net/dwmac-sun8i.txt b/Documentation/devicetree/bindings/net/dwmac-sun8i.txt
index 3d6d5fa0c4d5..e04ce75e24a3 100644
--- a/Documentation/devicetree/bindings/net/dwmac-sun8i.txt
+++ b/Documentation/devicetree/bindings/net/dwmac-sun8i.txt
@@ -28,10 +28,13 @@ Required properties:
   - allwinner,sun8i-a83t-system-controller
 
 Optional properties:
-- allwinner,tx-delay-ps: TX clock delay chain value in ps. Range value is 0-700. Default is 0)
-- allwinner,rx-delay-ps: RX clock delay chain value in ps. Range value is 0-3100. Default is 0)
-Both delay properties need to be a multiple of 100. They control the delay for
-external PHY.
+- allwinner,tx-delay-ps: TX clock delay chain value in ps.
+			 Range is 0-700. Default is 0.
+- allwinner,rx-delay-ps: RX clock delay chain value in ps.
+			 Range is 0-3100. Default is 0.
+Both delay properties need to be a multiple of 100. They control the
+clock delay for external RGMII PHY. They do not apply to the internal
+PHY or external non-RGMII PHYs.
 
 Optional properties for the following compatibles:
   - "allwinner,sun8i-h3-emac",
-- 
2.17.0

^ permalink raw reply related	[flat|nested] 80+ messages in thread
* [PATCH net-next v2 04/15] dt-bindings: net: dwmac-sun8i: Sort syscon compatibles by alphabetical order
  2018-05-01 16:12 ` Chen-Yu Tsai
  (?)
@ 2018-05-01 16:12   ` Chen-Yu Tsai
  -1 siblings, 0 replies; 80+ messages in thread
From: Chen-Yu Tsai @ 2018-05-01 16:12 UTC (permalink / raw)
  To: Maxime Ripard, Michael Turquette, Stephen Boyd,
	Giuseppe Cavallaro, Rob Herring, Mark Rutland, Mark Brown
  Cc: devicetree, netdev, Chen-Yu Tsai, Corentin Labbe, linux-clk,
	linux-arm-kernel, Icenowy Zheng

The A83T syscon compatible was appended to the syscon compatibles list,
instead of inserted in to preserve the ordering.

Move it to the proper place to keep the list sorted.

Signed-off-by: Chen-Yu Tsai <wens@csie.org>
Reviewed-by: Rob Herring <robh@kernel.org>
---
 Documentation/devicetree/bindings/net/dwmac-sun8i.txt | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/net/dwmac-sun8i.txt b/Documentation/devicetree/bindings/net/dwmac-sun8i.txt
index e04ce75e24a3..1b8e33e71651 100644
--- a/Documentation/devicetree/bindings/net/dwmac-sun8i.txt
+++ b/Documentation/devicetree/bindings/net/dwmac-sun8i.txt
@@ -22,10 +22,10 @@ Required properties:
 - #size-cells: shall be 0
 - syscon: A phandle to the syscon of the SoC with one of the following
  compatible string:
+  - allwinner,sun8i-a83t-system-controller
   - allwinner,sun8i-h3-system-controller
   - allwinner,sun8i-v3s-system-controller
   - allwinner,sun50i-a64-system-controller
-  - allwinner,sun8i-a83t-system-controller
 
 Optional properties:
 - allwinner,tx-delay-ps: TX clock delay chain value in ps.
-- 
2.17.0

^ permalink raw reply related	[flat|nested] 80+ messages in thread
* [PATCH net-next v2 04/15] dt-bindings: net: dwmac-sun8i: Sort syscon compatibles by alphabetical order
@ 2018-05-01 16:12   ` Chen-Yu Tsai
  0 siblings, 0 replies; 80+ messages in thread
From: Chen-Yu Tsai @ 2018-05-01 16:12 UTC (permalink / raw)
  To: Maxime Ripard, Michael Turquette, Stephen Boyd,
	Giuseppe Cavallaro, Rob Herring, Mark Rutland, Mark Brown
  Cc: Chen-Yu Tsai, linux-arm-kernel, linux-clk, devicetree, netdev,
	Corentin Labbe, Icenowy Zheng

The A83T syscon compatible was appended to the syscon compatibles list,
instead of inserted in to preserve the ordering.

Move it to the proper place to keep the list sorted.

Signed-off-by: Chen-Yu Tsai <wens@csie.org>
Reviewed-by: Rob Herring <robh@kernel.org>
---
 Documentation/devicetree/bindings/net/dwmac-sun8i.txt | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/net/dwmac-sun8i.txt b/Documentation/devicetree/bindings/net/dwmac-sun8i.txt
index e04ce75e24a3..1b8e33e71651 100644
--- a/Documentation/devicetree/bindings/net/dwmac-sun8i.txt
+++ b/Documentation/devicetree/bindings/net/dwmac-sun8i.txt
@@ -22,10 +22,10 @@ Required properties:
 - #size-cells: shall be 0
 - syscon: A phandle to the syscon of the SoC with one of the following
  compatible string:
+  - allwinner,sun8i-a83t-system-controller
   - allwinner,sun8i-h3-system-controller
   - allwinner,sun8i-v3s-system-controller
   - allwinner,sun50i-a64-system-controller
-  - allwinner,sun8i-a83t-system-controller
 
 Optional properties:
 - allwinner,tx-delay-ps: TX clock delay chain value in ps.
-- 
2.17.0

^ permalink raw reply related	[flat|nested] 80+ messages in thread
* [PATCH net-next v2 04/15] dt-bindings: net: dwmac-sun8i: Sort syscon compatibles by alphabetical order
@ 2018-05-01 16:12   ` Chen-Yu Tsai
  0 siblings, 0 replies; 80+ messages in thread
From: Chen-Yu Tsai @ 2018-05-01 16:12 UTC (permalink / raw)
  To: linux-arm-kernel

The A83T syscon compatible was appended to the syscon compatibles list,
instead of inserted in to preserve the ordering.

Move it to the proper place to keep the list sorted.

Signed-off-by: Chen-Yu Tsai <wens@csie.org>
Reviewed-by: Rob Herring <robh@kernel.org>
---
 Documentation/devicetree/bindings/net/dwmac-sun8i.txt | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/net/dwmac-sun8i.txt b/Documentation/devicetree/bindings/net/dwmac-sun8i.txt
index e04ce75e24a3..1b8e33e71651 100644
--- a/Documentation/devicetree/bindings/net/dwmac-sun8i.txt
+++ b/Documentation/devicetree/bindings/net/dwmac-sun8i.txt
@@ -22,10 +22,10 @@ Required properties:
 - #size-cells: shall be 0
 - syscon: A phandle to the syscon of the SoC with one of the following
  compatible string:
+  - allwinner,sun8i-a83t-system-controller
   - allwinner,sun8i-h3-system-controller
   - allwinner,sun8i-v3s-system-controller
   - allwinner,sun50i-a64-system-controller
-  - allwinner,sun8i-a83t-system-controller
 
 Optional properties:
 - allwinner,tx-delay-ps: TX clock delay chain value in ps.
-- 
2.17.0

^ permalink raw reply related	[flat|nested] 80+ messages in thread
* [PATCH net-next v2 05/15] dt-bindings: net: dwmac-sun8i: simplify description of syscon property
  2018-05-01 16:12 ` Chen-Yu Tsai
@ 2018-05-01 16:12   ` Chen-Yu Tsai
  -1 siblings, 0 replies; 80+ messages in thread
From: Chen-Yu Tsai @ 2018-05-01 16:12 UTC (permalink / raw)
  To: Maxime Ripard, Michael Turquette, Stephen Boyd,
	Giuseppe Cavallaro, Rob Herring, Mark Rutland, Mark Brown
  Cc: Chen-Yu Tsai, linux-arm-kernel, linux-clk, devicetree, netdev,
	Corentin Labbe, Icenowy Zheng

The syscon property is used to point to the device that holds the glue
layer control register known as the "EMAC (or GMAC) clock register".

We do not need to explicitly list what compatible strings are needed, as
this information is readily available in the user manuals. Also the
"syscon" device type is more of an implementation detail. There are many
ways to access a register not in a device's address range, the syscon
interface being the most generic and unrestricted one.

Simplify the description so that it says what it is supposed to
describe.

Signed-off-by: Chen-Yu Tsai <wens@csie.org>
---
 Documentation/devicetree/bindings/net/dwmac-sun8i.txt | 7 +------
 1 file changed, 1 insertion(+), 6 deletions(-)

diff --git a/Documentation/devicetree/bindings/net/dwmac-sun8i.txt b/Documentation/devicetree/bindings/net/dwmac-sun8i.txt
index 1b8e33e71651..1c0906a5c02b 100644
--- a/Documentation/devicetree/bindings/net/dwmac-sun8i.txt
+++ b/Documentation/devicetree/bindings/net/dwmac-sun8i.txt
@@ -20,12 +20,7 @@ Required properties:
 - phy-handle: See ethernet.txt
 - #address-cells: shall be 1
 - #size-cells: shall be 0
-- syscon: A phandle to the syscon of the SoC with one of the following
- compatible string:
-  - allwinner,sun8i-a83t-system-controller
-  - allwinner,sun8i-h3-system-controller
-  - allwinner,sun8i-v3s-system-controller
-  - allwinner,sun50i-a64-system-controller
+- syscon: A phandle to the device containing the EMAC or GMAC clock register
 
 Optional properties:
 - allwinner,tx-delay-ps: TX clock delay chain value in ps.
-- 
2.17.0

^ permalink raw reply related	[flat|nested] 80+ messages in thread
* [PATCH net-next v2 05/15] dt-bindings: net: dwmac-sun8i: simplify description of syscon property
@ 2018-05-01 16:12   ` Chen-Yu Tsai
  0 siblings, 0 replies; 80+ messages in thread
From: Chen-Yu Tsai @ 2018-05-01 16:12 UTC (permalink / raw)
  To: linux-arm-kernel

The syscon property is used to point to the device that holds the glue
layer control register known as the "EMAC (or GMAC) clock register".

We do not need to explicitly list what compatible strings are needed, as
this information is readily available in the user manuals. Also the
"syscon" device type is more of an implementation detail. There are many
ways to access a register not in a device's address range, the syscon
interface being the most generic and unrestricted one.

Simplify the description so that it says what it is supposed to
describe.

Signed-off-by: Chen-Yu Tsai <wens@csie.org>
---
 Documentation/devicetree/bindings/net/dwmac-sun8i.txt | 7 +------
 1 file changed, 1 insertion(+), 6 deletions(-)

diff --git a/Documentation/devicetree/bindings/net/dwmac-sun8i.txt b/Documentation/devicetree/bindings/net/dwmac-sun8i.txt
index 1b8e33e71651..1c0906a5c02b 100644
--- a/Documentation/devicetree/bindings/net/dwmac-sun8i.txt
+++ b/Documentation/devicetree/bindings/net/dwmac-sun8i.txt
@@ -20,12 +20,7 @@ Required properties:
 - phy-handle: See ethernet.txt
 - #address-cells: shall be 1
 - #size-cells: shall be 0
-- syscon: A phandle to the syscon of the SoC with one of the following
- compatible string:
-  - allwinner,sun8i-a83t-system-controller
-  - allwinner,sun8i-h3-system-controller
-  - allwinner,sun8i-v3s-system-controller
-  - allwinner,sun50i-a64-system-controller
+- syscon: A phandle to the device containing the EMAC or GMAC clock register
 
 Optional properties:
 - allwinner,tx-delay-ps: TX clock delay chain value in ps.
-- 
2.17.0

^ permalink raw reply related	[flat|nested] 80+ messages in thread
* [PATCH net-next v2 06/15] dt-bindings: net: dwmac-sun8i: Add binding for GMAC on Allwinner R40 SoC
  2018-05-01 16:12 ` Chen-Yu Tsai
  (?)
@ 2018-05-01 16:12   ` Chen-Yu Tsai
  -1 siblings, 0 replies; 80+ messages in thread
From: Chen-Yu Tsai @ 2018-05-01 16:12 UTC (permalink / raw)
  To: Maxime Ripard, Michael Turquette, Stephen Boyd,
	Giuseppe Cavallaro, Rob Herring, Mark Rutland, Mark Brown
  Cc: devicetree, netdev, Chen-Yu Tsai, Corentin Labbe, linux-clk,
	linux-arm-kernel, Icenowy Zheng

The Allwinner R40 SoC has the EMAC controller supported by dwmac-sun8i.
It is named "GMAC", while EMAC refers to the 10/100 Mbps Ethernet
controller supported by sun4i-emac. The controller is the same, but
the R40 has the glue layer controls in the clock control unit (CCU),
with a reduced RX delay chain, and no TX delay chain.

This patch adds the R40 specific bits to the dwmac-sun8i binding.

Signed-off-by: Chen-Yu Tsai <wens@csie.org>
---
 Documentation/devicetree/bindings/net/dwmac-sun8i.txt | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/Documentation/devicetree/bindings/net/dwmac-sun8i.txt b/Documentation/devicetree/bindings/net/dwmac-sun8i.txt
index 1c0906a5c02b..cfe724398a12 100644
--- a/Documentation/devicetree/bindings/net/dwmac-sun8i.txt
+++ b/Documentation/devicetree/bindings/net/dwmac-sun8i.txt
@@ -7,6 +7,7 @@ Required properties:
 - compatible: must be one of the following string:
 		"allwinner,sun8i-a83t-emac"
 		"allwinner,sun8i-h3-emac"
+		"allwinner,sun8i-r40-gmac"
 		"allwinner,sun8i-v3s-emac"
 		"allwinner,sun50i-a64-emac"
 - reg: address and length of the register for the device.
@@ -25,8 +26,10 @@ Required properties:
 Optional properties:
 - allwinner,tx-delay-ps: TX clock delay chain value in ps.
 			 Range is 0-700. Default is 0.
+			 Unavailable for allwinner,sun8i-r40-gmac
 - allwinner,rx-delay-ps: RX clock delay chain value in ps.
 			 Range is 0-3100. Default is 0.
+			 Range is 0-700 for allwinner,sun8i-r40-gmac
 Both delay properties need to be a multiple of 100. They control the
 clock delay for external RGMII PHY. They do not apply to the internal
 PHY or external non-RGMII PHYs.
-- 
2.17.0

^ permalink raw reply related	[flat|nested] 80+ messages in thread
* [PATCH net-next v2 06/15] dt-bindings: net: dwmac-sun8i: Add binding for GMAC on Allwinner R40 SoC
@ 2018-05-01 16:12   ` Chen-Yu Tsai
  0 siblings, 0 replies; 80+ messages in thread
From: Chen-Yu Tsai @ 2018-05-01 16:12 UTC (permalink / raw)
  To: Maxime Ripard, Michael Turquette, Stephen Boyd,
	Giuseppe Cavallaro, Rob Herring, Mark Rutland, Mark Brown
  Cc: Chen-Yu Tsai, linux-arm-kernel, linux-clk, devicetree, netdev,
	Corentin Labbe, Icenowy Zheng

The Allwinner R40 SoC has the EMAC controller supported by dwmac-sun8i.
It is named "GMAC", while EMAC refers to the 10/100 Mbps Ethernet
controller supported by sun4i-emac. The controller is the same, but
the R40 has the glue layer controls in the clock control unit (CCU),
with a reduced RX delay chain, and no TX delay chain.

This patch adds the R40 specific bits to the dwmac-sun8i binding.

Signed-off-by: Chen-Yu Tsai <wens@csie.org>
---
 Documentation/devicetree/bindings/net/dwmac-sun8i.txt | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/Documentation/devicetree/bindings/net/dwmac-sun8i.txt b/Documentation/devicetree/bindings/net/dwmac-sun8i.txt
index 1c0906a5c02b..cfe724398a12 100644
--- a/Documentation/devicetree/bindings/net/dwmac-sun8i.txt
+++ b/Documentation/devicetree/bindings/net/dwmac-sun8i.txt
@@ -7,6 +7,7 @@ Required properties:
 - compatible: must be one of the following string:
 		"allwinner,sun8i-a83t-emac"
 		"allwinner,sun8i-h3-emac"
+		"allwinner,sun8i-r40-gmac"
 		"allwinner,sun8i-v3s-emac"
 		"allwinner,sun50i-a64-emac"
 - reg: address and length of the register for the device.
@@ -25,8 +26,10 @@ Required properties:
 Optional properties:
 - allwinner,tx-delay-ps: TX clock delay chain value in ps.
 			 Range is 0-700. Default is 0.
+			 Unavailable for allwinner,sun8i-r40-gmac
 - allwinner,rx-delay-ps: RX clock delay chain value in ps.
 			 Range is 0-3100. Default is 0.
+			 Range is 0-700 for allwinner,sun8i-r40-gmac
 Both delay properties need to be a multiple of 100. They control the
 clock delay for external RGMII PHY. They do not apply to the internal
 PHY or external non-RGMII PHYs.
-- 
2.17.0

^ permalink raw reply related	[flat|nested] 80+ messages in thread
* [PATCH net-next v2 06/15] dt-bindings: net: dwmac-sun8i: Add binding for GMAC on Allwinner R40 SoC
@ 2018-05-01 16:12   ` Chen-Yu Tsai
  0 siblings, 0 replies; 80+ messages in thread
From: Chen-Yu Tsai @ 2018-05-01 16:12 UTC (permalink / raw)
  To: linux-arm-kernel

The Allwinner R40 SoC has the EMAC controller supported by dwmac-sun8i.
It is named "GMAC", while EMAC refers to the 10/100 Mbps Ethernet
controller supported by sun4i-emac. The controller is the same, but
the R40 has the glue layer controls in the clock control unit (CCU),
with a reduced RX delay chain, and no TX delay chain.

This patch adds the R40 specific bits to the dwmac-sun8i binding.

Signed-off-by: Chen-Yu Tsai <wens@csie.org>
---
 Documentation/devicetree/bindings/net/dwmac-sun8i.txt | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/Documentation/devicetree/bindings/net/dwmac-sun8i.txt b/Documentation/devicetree/bindings/net/dwmac-sun8i.txt
index 1c0906a5c02b..cfe724398a12 100644
--- a/Documentation/devicetree/bindings/net/dwmac-sun8i.txt
+++ b/Documentation/devicetree/bindings/net/dwmac-sun8i.txt
@@ -7,6 +7,7 @@ Required properties:
 - compatible: must be one of the following string:
 		"allwinner,sun8i-a83t-emac"
 		"allwinner,sun8i-h3-emac"
+		"allwinner,sun8i-r40-gmac"
 		"allwinner,sun8i-v3s-emac"
 		"allwinner,sun50i-a64-emac"
 - reg: address and length of the register for the device.
@@ -25,8 +26,10 @@ Required properties:
 Optional properties:
 - allwinner,tx-delay-ps: TX clock delay chain value in ps.
 			 Range is 0-700. Default is 0.
+			 Unavailable for allwinner,sun8i-r40-gmac
 - allwinner,rx-delay-ps: RX clock delay chain value in ps.
 			 Range is 0-3100. Default is 0.
+			 Range is 0-700 for allwinner,sun8i-r40-gmac
 Both delay properties need to be a multiple of 100. They control the
 clock delay for external RGMII PHY. They do not apply to the internal
 PHY or external non-RGMII PHYs.
-- 
2.17.0

^ permalink raw reply related	[flat|nested] 80+ messages in thread
* [PATCH net-next v2 07/15] net: stmmac: dwmac-sun8i: Use regmap_field for syscon register access
  2018-05-01 16:12 ` Chen-Yu Tsai
@ 2018-05-01 16:12   ` Chen-Yu Tsai
  -1 siblings, 0 replies; 80+ messages in thread
From: Chen-Yu Tsai @ 2018-05-01 16:12 UTC (permalink / raw)
  To: Maxime Ripard, Michael Turquette, Stephen Boyd,
	Giuseppe Cavallaro, Rob Herring, Mark Rutland, Mark Brown
  Cc: Chen-Yu Tsai, linux-arm-kernel, linux-clk, devicetree, netdev,
	Corentin Labbe, Icenowy Zheng

On the Allwinner R40, the "GMAC clock" register is located in the CCU
block, at a different register address than the other SoCs that have
it in the "system control" block.

This patch converts the use of regmap to regmap_field for mapping and
accessing the syscon register, so we can have the register address in
the variants data, and not in the actual register manipulation code.

This patch only converts regmap_read() and regmap_write() calls to
regmap_field_read() and regmap_field_write() calls. There are some
places where it might make sense to switch to regmap_field_update_bits(),
but this is not done here to keep the patch simple.

Signed-off-by: Chen-Yu Tsai <wens@csie.org>
---
 .../net/ethernet/stmicro/stmmac/dwmac-sun8i.c | 42 ++++++++++++++-----
 1 file changed, 31 insertions(+), 11 deletions(-)

diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c b/drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c
index a3fa65b1ca8e..bbc051474806 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c
@@ -42,6 +42,7 @@
  *				This value is used for disabling properly EMAC
  *				and used as a good starting value in case of the
  *				boot process(uboot) leave some stuff.
+ * @syscon_field		reg_field for the syscon's gmac register
  * @soc_has_internal_phy:	Does the MAC embed an internal PHY
  * @support_mii:		Does the MAC handle MII
  * @support_rmii:		Does the MAC handle RMII
@@ -49,6 +50,7 @@
  */
 struct emac_variant {
 	u32 default_syscon_value;
+	const struct reg_field *syscon_field;
 	bool soc_has_internal_phy;
 	bool support_mii;
 	bool support_rmii;
@@ -71,13 +73,21 @@ struct sunxi_priv_data {
 	struct regulator *regulator;
 	struct reset_control *rst_ephy;
 	const struct emac_variant *variant;
-	struct regmap *regmap;
+	struct regmap_field *regmap_field;
 	bool internal_phy_powered;
 	void *mux_handle;
 };
 
+/* EMAC clock register @ 0x30 in the "system control" address range */
+static const struct reg_field sun8i_syscon_reg_field = {
+	.reg = 0x30,
+	.lsb = 0,
+	.msb = 31,
+};
+
 static const struct emac_variant emac_variant_h3 = {
 	.default_syscon_value = 0x58000,
+	.syscon_field = &sun8i_syscon_reg_field,
 	.soc_has_internal_phy = true,
 	.support_mii = true,
 	.support_rmii = true,
@@ -86,12 +96,14 @@ static const struct emac_variant emac_variant_h3 = {
 
 static const struct emac_variant emac_variant_v3s = {
 	.default_syscon_value = 0x38000,
+	.syscon_field = &sun8i_syscon_reg_field,
 	.soc_has_internal_phy = true,
 	.support_mii = true
 };
 
 static const struct emac_variant emac_variant_a83t = {
 	.default_syscon_value = 0,
+	.syscon_field = &sun8i_syscon_reg_field,
 	.soc_has_internal_phy = false,
 	.support_mii = true,
 	.support_rgmii = true
@@ -99,6 +111,7 @@ static const struct emac_variant emac_variant_a83t = {
 
 static const struct emac_variant emac_variant_a64 = {
 	.default_syscon_value = 0,
+	.syscon_field = &sun8i_syscon_reg_field,
 	.soc_has_internal_phy = false,
 	.support_mii = true,
 	.support_rmii = true,
@@ -216,7 +229,6 @@ static const struct emac_variant emac_variant_a64 = {
 #define SYSCON_ETCS_MII		0x0
 #define SYSCON_ETCS_EXT_GMII	0x1
 #define SYSCON_ETCS_INT_GMII	0x2
-#define SYSCON_EMAC_REG		0x30
 
 /* sun8i_dwmac_dma_reset() - reset the EMAC
  * Called from stmmac via stmmac_dma_ops->reset
@@ -745,7 +757,7 @@ static int mdio_mux_syscon_switch_fn(int current_child, int desired_child,
 	bool need_power_ephy = false;
 
 	if (current_child ^ desired_child) {
-		regmap_read(gmac->regmap, SYSCON_EMAC_REG, &reg);
+		regmap_field_read(gmac->regmap_field, &reg);
 		switch (desired_child) {
 		case DWMAC_SUN8I_MDIO_MUX_INTERNAL_ID:
 			dev_info(priv->device, "Switch mux to internal PHY");
@@ -763,7 +775,7 @@ static int mdio_mux_syscon_switch_fn(int current_child, int desired_child,
 				desired_child);
 			return -EINVAL;
 		}
-		regmap_write(gmac->regmap, SYSCON_EMAC_REG, val);
+		regmap_field_write(gmac->regmap_field, val);
 		if (need_power_ephy) {
 			ret = sun8i_dwmac_power_internal_phy(priv);
 			if (ret)
@@ -801,7 +813,7 @@ static int sun8i_dwmac_set_syscon(struct stmmac_priv *priv)
 	int ret;
 	u32 reg, val;
 
-	regmap_read(gmac->regmap, SYSCON_EMAC_REG, &val);
+	regmap_field_read(gmac->regmap_field, &val);
 	reg = gmac->variant->default_syscon_value;
 	if (reg != val)
 		dev_warn(priv->device,
@@ -883,7 +895,7 @@ static int sun8i_dwmac_set_syscon(struct stmmac_priv *priv)
 		return -EINVAL;
 	}
 
-	regmap_write(gmac->regmap, SYSCON_EMAC_REG, reg);
+	regmap_field_write(gmac->regmap_field, reg);
 
 	return 0;
 }
@@ -892,7 +904,7 @@ static void sun8i_dwmac_unset_syscon(struct sunxi_priv_data *gmac)
 {
 	u32 reg = gmac->variant->default_syscon_value;
 
-	regmap_write(gmac->regmap, SYSCON_EMAC_REG, reg);
+	regmap_field_write(gmac->regmap_field, reg);
 }
 
 static void sun8i_dwmac_exit(struct platform_device *pdev, void *priv)
@@ -980,6 +992,7 @@ static int sun8i_dwmac_probe(struct platform_device *pdev)
 	int ret;
 	struct stmmac_priv *priv;
 	struct net_device *ndev;
+	struct regmap *regmap;
 
 	ret = stmmac_get_platform_resources(pdev, &stmmac_res);
 	if (ret)
@@ -1014,14 +1027,21 @@ static int sun8i_dwmac_probe(struct platform_device *pdev)
 		gmac->regulator = NULL;
 	}
 
-	gmac->regmap = syscon_regmap_lookup_by_phandle(pdev->dev.of_node,
-						       "syscon");
-	if (IS_ERR(gmac->regmap)) {
-		ret = PTR_ERR(gmac->regmap);
+	regmap = syscon_regmap_lookup_by_phandle(pdev->dev.of_node, "syscon");
+	if (IS_ERR(regmap)) {
+		ret = PTR_ERR(regmap);
 		dev_err(&pdev->dev, "Unable to map syscon: %d\n", ret);
 		return ret;
 	}
 
+	gmac->regmap_field = devm_regmap_field_alloc(dev, regmap,
+						     *gmac->variant->syscon_field);
+	if (IS_ERR(gmac->regmap_field)) {
+		ret = PTR_ERR(gmac->regmap_field);
+		dev_err(dev, "Unable to map syscon register: %d\n", ret);
+		return ret;
+	}
+
 	plat_dat->interface = of_get_phy_mode(dev->of_node);
 
 	/* platform data specifying hardware features and callbacks.
-- 
2.17.0

^ permalink raw reply related	[flat|nested] 80+ messages in thread
* [PATCH net-next v2 07/15] net: stmmac: dwmac-sun8i: Use regmap_field for syscon register access
@ 2018-05-01 16:12   ` Chen-Yu Tsai
  0 siblings, 0 replies; 80+ messages in thread
From: Chen-Yu Tsai @ 2018-05-01 16:12 UTC (permalink / raw)
  To: linux-arm-kernel

On the Allwinner R40, the "GMAC clock" register is located in the CCU
block, at a different register address than the other SoCs that have
it in the "system control" block.

This patch converts the use of regmap to regmap_field for mapping and
accessing the syscon register, so we can have the register address in
the variants data, and not in the actual register manipulation code.

This patch only converts regmap_read() and regmap_write() calls to
regmap_field_read() and regmap_field_write() calls. There are some
places where it might make sense to switch to regmap_field_update_bits(),
but this is not done here to keep the patch simple.

Signed-off-by: Chen-Yu Tsai <wens@csie.org>
---
 .../net/ethernet/stmicro/stmmac/dwmac-sun8i.c | 42 ++++++++++++++-----
 1 file changed, 31 insertions(+), 11 deletions(-)

diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c b/drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c
index a3fa65b1ca8e..bbc051474806 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c
@@ -42,6 +42,7 @@
  *				This value is used for disabling properly EMAC
  *				and used as a good starting value in case of the
  *				boot process(uboot) leave some stuff.
+ * @syscon_field		reg_field for the syscon's gmac register
  * @soc_has_internal_phy:	Does the MAC embed an internal PHY
  * @support_mii:		Does the MAC handle MII
  * @support_rmii:		Does the MAC handle RMII
@@ -49,6 +50,7 @@
  */
 struct emac_variant {
 	u32 default_syscon_value;
+	const struct reg_field *syscon_field;
 	bool soc_has_internal_phy;
 	bool support_mii;
 	bool support_rmii;
@@ -71,13 +73,21 @@ struct sunxi_priv_data {
 	struct regulator *regulator;
 	struct reset_control *rst_ephy;
 	const struct emac_variant *variant;
-	struct regmap *regmap;
+	struct regmap_field *regmap_field;
 	bool internal_phy_powered;
 	void *mux_handle;
 };
 
+/* EMAC clock register @ 0x30 in the "system control" address range */
+static const struct reg_field sun8i_syscon_reg_field = {
+	.reg = 0x30,
+	.lsb = 0,
+	.msb = 31,
+};
+
 static const struct emac_variant emac_variant_h3 = {
 	.default_syscon_value = 0x58000,
+	.syscon_field = &sun8i_syscon_reg_field,
 	.soc_has_internal_phy = true,
 	.support_mii = true,
 	.support_rmii = true,
@@ -86,12 +96,14 @@ static const struct emac_variant emac_variant_h3 = {
 
 static const struct emac_variant emac_variant_v3s = {
 	.default_syscon_value = 0x38000,
+	.syscon_field = &sun8i_syscon_reg_field,
 	.soc_has_internal_phy = true,
 	.support_mii = true
 };
 
 static const struct emac_variant emac_variant_a83t = {
 	.default_syscon_value = 0,
+	.syscon_field = &sun8i_syscon_reg_field,
 	.soc_has_internal_phy = false,
 	.support_mii = true,
 	.support_rgmii = true
@@ -99,6 +111,7 @@ static const struct emac_variant emac_variant_a83t = {
 
 static const struct emac_variant emac_variant_a64 = {
 	.default_syscon_value = 0,
+	.syscon_field = &sun8i_syscon_reg_field,
 	.soc_has_internal_phy = false,
 	.support_mii = true,
 	.support_rmii = true,
@@ -216,7 +229,6 @@ static const struct emac_variant emac_variant_a64 = {
 #define SYSCON_ETCS_MII		0x0
 #define SYSCON_ETCS_EXT_GMII	0x1
 #define SYSCON_ETCS_INT_GMII	0x2
-#define SYSCON_EMAC_REG		0x30
 
 /* sun8i_dwmac_dma_reset() - reset the EMAC
  * Called from stmmac via stmmac_dma_ops->reset
@@ -745,7 +757,7 @@ static int mdio_mux_syscon_switch_fn(int current_child, int desired_child,
 	bool need_power_ephy = false;
 
 	if (current_child ^ desired_child) {
-		regmap_read(gmac->regmap, SYSCON_EMAC_REG, &reg);
+		regmap_field_read(gmac->regmap_field, &reg);
 		switch (desired_child) {
 		case DWMAC_SUN8I_MDIO_MUX_INTERNAL_ID:
 			dev_info(priv->device, "Switch mux to internal PHY");
@@ -763,7 +775,7 @@ static int mdio_mux_syscon_switch_fn(int current_child, int desired_child,
 				desired_child);
 			return -EINVAL;
 		}
-		regmap_write(gmac->regmap, SYSCON_EMAC_REG, val);
+		regmap_field_write(gmac->regmap_field, val);
 		if (need_power_ephy) {
 			ret = sun8i_dwmac_power_internal_phy(priv);
 			if (ret)
@@ -801,7 +813,7 @@ static int sun8i_dwmac_set_syscon(struct stmmac_priv *priv)
 	int ret;
 	u32 reg, val;
 
-	regmap_read(gmac->regmap, SYSCON_EMAC_REG, &val);
+	regmap_field_read(gmac->regmap_field, &val);
 	reg = gmac->variant->default_syscon_value;
 	if (reg != val)
 		dev_warn(priv->device,
@@ -883,7 +895,7 @@ static int sun8i_dwmac_set_syscon(struct stmmac_priv *priv)
 		return -EINVAL;
 	}
 
-	regmap_write(gmac->regmap, SYSCON_EMAC_REG, reg);
+	regmap_field_write(gmac->regmap_field, reg);
 
 	return 0;
 }
@@ -892,7 +904,7 @@ static void sun8i_dwmac_unset_syscon(struct sunxi_priv_data *gmac)
 {
 	u32 reg = gmac->variant->default_syscon_value;
 
-	regmap_write(gmac->regmap, SYSCON_EMAC_REG, reg);
+	regmap_field_write(gmac->regmap_field, reg);
 }
 
 static void sun8i_dwmac_exit(struct platform_device *pdev, void *priv)
@@ -980,6 +992,7 @@ static int sun8i_dwmac_probe(struct platform_device *pdev)
 	int ret;
 	struct stmmac_priv *priv;
 	struct net_device *ndev;
+	struct regmap *regmap;
 
 	ret = stmmac_get_platform_resources(pdev, &stmmac_res);
 	if (ret)
@@ -1014,14 +1027,21 @@ static int sun8i_dwmac_probe(struct platform_device *pdev)
 		gmac->regulator = NULL;
 	}
 
-	gmac->regmap = syscon_regmap_lookup_by_phandle(pdev->dev.of_node,
-						       "syscon");
-	if (IS_ERR(gmac->regmap)) {
-		ret = PTR_ERR(gmac->regmap);
+	regmap = syscon_regmap_lookup_by_phandle(pdev->dev.of_node, "syscon");
+	if (IS_ERR(regmap)) {
+		ret = PTR_ERR(regmap);
 		dev_err(&pdev->dev, "Unable to map syscon: %d\n", ret);
 		return ret;
 	}
 
+	gmac->regmap_field = devm_regmap_field_alloc(dev, regmap,
+						     *gmac->variant->syscon_field);
+	if (IS_ERR(gmac->regmap_field)) {
+		ret = PTR_ERR(gmac->regmap_field);
+		dev_err(dev, "Unable to map syscon register: %d\n", ret);
+		return ret;
+	}
+
 	plat_dat->interface = of_get_phy_mode(dev->of_node);
 
 	/* platform data specifying hardware features and callbacks.
-- 
2.17.0

^ permalink raw reply related	[flat|nested] 80+ messages in thread
* [PATCH net-next v2 08/15] net: stmmac: dwmac-sun8i: Allow getting syscon regmap from external device
  2018-05-01 16:12 ` Chen-Yu Tsai
@ 2018-05-01 16:12   ` Chen-Yu Tsai
  -1 siblings, 0 replies; 80+ messages in thread
From: Chen-Yu Tsai @ 2018-05-01 16:12 UTC (permalink / raw)
  To: Maxime Ripard, Michael Turquette, Stephen Boyd,
	Giuseppe Cavallaro, Rob Herring, Mark Rutland, Mark Brown
  Cc: Chen-Yu Tsai, linux-arm-kernel, linux-clk, devicetree, netdev,
	Corentin Labbe, Icenowy Zheng

On the Allwinner R40 SoC, the "GMAC clock" register is in the CCU
address space. Using a standard syscon to access it provides no
coordination with the CCU driver for register access. Neither does
it prevent this and other drivers from accessing other, maybe critical,
clock control registers. On other SoCs, the register is in the "system
control" address space, which might also contain controls for mapping
SRAM to devices or the CPU. This hardware has the same issues.

Instead, for these types of setups, we let the device containing the
control register create a regmap tied to it. We can then get the device
from the existing syscon phandle, and retrieve the regmap with
dev_get_regmap().

Signed-off-by: Chen-Yu Tsai <wens@csie.org>
---
 .../net/ethernet/stmicro/stmmac/dwmac-sun8i.c | 50 ++++++++++++++++++-
 1 file changed, 49 insertions(+), 1 deletion(-)

diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c b/drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c
index bbc051474806..79e104a20e20 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c
@@ -983,6 +983,34 @@ static struct mac_device_info *sun8i_dwmac_setup(void *ppriv)
 	return mac;
 }
 
+static struct regmap *sun8i_dwmac_get_syscon_from_dev(struct device_node *node)
+{
+	struct device_node *syscon_node;
+	struct platform_device *syscon_pdev;
+	struct regmap *regmap = NULL;
+
+	syscon_node = of_parse_phandle(node, "syscon", 0);
+	if (!syscon_node)
+		return ERR_PTR(-ENODEV);
+
+	syscon_pdev = of_find_device_by_node(syscon_node);
+	if (!syscon_pdev) {
+		/* platform device might not be probed yet */
+		regmap = ERR_PTR(-EPROBE_DEFER);
+		goto out_put_node;
+	}
+
+	/* If no regmap is found then the other device driver is at fault */
+	regmap = dev_get_regmap(&syscon_pdev->dev, NULL);
+	if (!regmap)
+		regmap = ERR_PTR(-EINVAL);
+
+	platform_device_put(syscon_pdev);
+out_put_node:
+	of_node_put(syscon_node);
+	return regmap;
+}
+
 static int sun8i_dwmac_probe(struct platform_device *pdev)
 {
 	struct plat_stmmacenet_data *plat_dat;
@@ -1027,7 +1055,27 @@ static int sun8i_dwmac_probe(struct platform_device *pdev)
 		gmac->regulator = NULL;
 	}
 
-	regmap = syscon_regmap_lookup_by_phandle(pdev->dev.of_node, "syscon");
+	/* The "GMAC clock control" register might be located in the
+	 * CCU address range (on the R40), or the system control address
+	 * range (on most other sun8i and later SoCs).
+	 *
+	 * The former controls most if not all clocks in the SoC. The
+	 * latter has an SoC identification register, and on some SoCs,
+	 * controls to map device specific SRAM to either the intended
+	 * peripheral, or the CPU address space.
+	 *
+	 * In either case, there should be a coordinated and restricted
+	 * method of accessing the register needed here. This is done by
+	 * having the device export a custom regmap, instead of a generic
+	 * syscon, which grants all access to all registers.
+	 *
+	 * To support old device trees, we fall back to using the syscon
+	 * interface if possible.
+	 */
+	regmap = sun8i_dwmac_get_syscon_from_dev(pdev->dev.of_node);
+	if (IS_ERR(regmap))
+		regmap = syscon_regmap_lookup_by_phandle(pdev->dev.of_node,
+							 "syscon");
 	if (IS_ERR(regmap)) {
 		ret = PTR_ERR(regmap);
 		dev_err(&pdev->dev, "Unable to map syscon: %d\n", ret);
-- 
2.17.0

^ permalink raw reply related	[flat|nested] 80+ messages in thread
* [PATCH net-next v2 08/15] net: stmmac: dwmac-sun8i: Allow getting syscon regmap from external device
@ 2018-05-01 16:12   ` Chen-Yu Tsai
  0 siblings, 0 replies; 80+ messages in thread
From: Chen-Yu Tsai @ 2018-05-01 16:12 UTC (permalink / raw)
  To: linux-arm-kernel

On the Allwinner R40 SoC, the "GMAC clock" register is in the CCU
address space. Using a standard syscon to access it provides no
coordination with the CCU driver for register access. Neither does
it prevent this and other drivers from accessing other, maybe critical,
clock control registers. On other SoCs, the register is in the "system
control" address space, which might also contain controls for mapping
SRAM to devices or the CPU. This hardware has the same issues.

Instead, for these types of setups, we let the device containing the
control register create a regmap tied to it. We can then get the device
from the existing syscon phandle, and retrieve the regmap with
dev_get_regmap().

Signed-off-by: Chen-Yu Tsai <wens@csie.org>
---
 .../net/ethernet/stmicro/stmmac/dwmac-sun8i.c | 50 ++++++++++++++++++-
 1 file changed, 49 insertions(+), 1 deletion(-)

diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c b/drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c
index bbc051474806..79e104a20e20 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c
@@ -983,6 +983,34 @@ static struct mac_device_info *sun8i_dwmac_setup(void *ppriv)
 	return mac;
 }
 
+static struct regmap *sun8i_dwmac_get_syscon_from_dev(struct device_node *node)
+{
+	struct device_node *syscon_node;
+	struct platform_device *syscon_pdev;
+	struct regmap *regmap = NULL;
+
+	syscon_node = of_parse_phandle(node, "syscon", 0);
+	if (!syscon_node)
+		return ERR_PTR(-ENODEV);
+
+	syscon_pdev = of_find_device_by_node(syscon_node);
+	if (!syscon_pdev) {
+		/* platform device might not be probed yet */
+		regmap = ERR_PTR(-EPROBE_DEFER);
+		goto out_put_node;
+	}
+
+	/* If no regmap is found then the other device driver is at fault */
+	regmap = dev_get_regmap(&syscon_pdev->dev, NULL);
+	if (!regmap)
+		regmap = ERR_PTR(-EINVAL);
+
+	platform_device_put(syscon_pdev);
+out_put_node:
+	of_node_put(syscon_node);
+	return regmap;
+}
+
 static int sun8i_dwmac_probe(struct platform_device *pdev)
 {
 	struct plat_stmmacenet_data *plat_dat;
@@ -1027,7 +1055,27 @@ static int sun8i_dwmac_probe(struct platform_device *pdev)
 		gmac->regulator = NULL;
 	}
 
-	regmap = syscon_regmap_lookup_by_phandle(pdev->dev.of_node, "syscon");
+	/* The "GMAC clock control" register might be located in the
+	 * CCU address range (on the R40), or the system control address
+	 * range (on most other sun8i and later SoCs).
+	 *
+	 * The former controls most if not all clocks in the SoC. The
+	 * latter has an SoC identification register, and on some SoCs,
+	 * controls to map device specific SRAM to either the intended
+	 * peripheral, or the CPU address space.
+	 *
+	 * In either case, there should be a coordinated and restricted
+	 * method of accessing the register needed here. This is done by
+	 * having the device export a custom regmap, instead of a generic
+	 * syscon, which grants all access to all registers.
+	 *
+	 * To support old device trees, we fall back to using the syscon
+	 * interface if possible.
+	 */
+	regmap = sun8i_dwmac_get_syscon_from_dev(pdev->dev.of_node);
+	if (IS_ERR(regmap))
+		regmap = syscon_regmap_lookup_by_phandle(pdev->dev.of_node,
+							 "syscon");
 	if (IS_ERR(regmap)) {
 		ret = PTR_ERR(regmap);
 		dev_err(&pdev->dev, "Unable to map syscon: %d\n", ret);
-- 
2.17.0

^ permalink raw reply related	[flat|nested] 80+ messages in thread
* [PATCH net-next v2 09/15] net: stmmac: dwmac-sun8i: Support different ranges for TX/RX delay chains
  2018-05-01 16:12 ` Chen-Yu Tsai
@ 2018-05-01 16:12   ` Chen-Yu Tsai
  -1 siblings, 0 replies; 80+ messages in thread
From: Chen-Yu Tsai @ 2018-05-01 16:12 UTC (permalink / raw)
  To: Maxime Ripard, Michael Turquette, Stephen Boyd,
	Giuseppe Cavallaro, Rob Herring, Mark Rutland, Mark Brown
  Cc: Chen-Yu Tsai, linux-arm-kernel, linux-clk, devicetree, netdev,
	Corentin Labbe, Icenowy Zheng

On the R40 SoC, the RX delay chain only has a range of 0~7 (hundred
picoseconds), instead of 0~31. Also the TX delay chain is completely
absent.

This patch adds support for different ranges by adding per-compatible
maximum values in the variant data. A maximum of 0 indicates that the
delay chain is not supported or absent.

Signed-off-by: Chen-Yu Tsai <wens@csie.org>
---
 .../net/ethernet/stmicro/stmmac/dwmac-sun8i.c | 32 +++++++++++++------
 1 file changed, 23 insertions(+), 9 deletions(-)

diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c b/drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c
index 79e104a20e20..4f5612a3c855 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c
@@ -47,6 +47,12 @@
  * @support_mii:		Does the MAC handle MII
  * @support_rmii:		Does the MAC handle RMII
  * @support_rgmii:		Does the MAC handle RGMII
+ *
+ * @rx_delay_max:		Maximum raw value for RX delay chain
+ * @tx_delay_max:		Maximum raw value for TX delay chain
+ *				These two also indicate the bitmask for
+ *				the RX and TX delay chain registers. A
+ *				value of zero indicates this is not supported.
  */
 struct emac_variant {
 	u32 default_syscon_value;
@@ -55,6 +61,8 @@ struct emac_variant {
 	bool support_mii;
 	bool support_rmii;
 	bool support_rgmii;
+	u8 rx_delay_max;
+	u8 tx_delay_max;
 };
 
 /* struct sunxi_priv_data - hold all sunxi private data
@@ -91,7 +99,9 @@ static const struct emac_variant emac_variant_h3 = {
 	.soc_has_internal_phy = true,
 	.support_mii = true,
 	.support_rmii = true,
-	.support_rgmii = true
+	.support_rgmii = true,
+	.rx_delay_max = 31,
+	.tx_delay_max = 7,
 };
 
 static const struct emac_variant emac_variant_v3s = {
@@ -106,7 +116,9 @@ static const struct emac_variant emac_variant_a83t = {
 	.syscon_field = &sun8i_syscon_reg_field,
 	.soc_has_internal_phy = false,
 	.support_mii = true,
-	.support_rgmii = true
+	.support_rgmii = true,
+	.rx_delay_max = 31,
+	.tx_delay_max = 7,
 };
 
 static const struct emac_variant emac_variant_a64 = {
@@ -115,7 +127,9 @@ static const struct emac_variant emac_variant_a64 = {
 	.soc_has_internal_phy = false,
 	.support_mii = true,
 	.support_rmii = true,
-	.support_rgmii = true
+	.support_rgmii = true,
+	.rx_delay_max = 31,
+	.tx_delay_max = 7,
 };
 
 #define EMAC_BASIC_CTL0 0x00
@@ -219,9 +233,7 @@ static const struct emac_variant emac_variant_a64 = {
 #define SYSCON_RMII_EN		BIT(13) /* 1: enable RMII (overrides EPIT) */
 
 /* Generic system control EMAC_CLK bits */
-#define SYSCON_ETXDC_MASK		GENMASK(2, 0)
 #define SYSCON_ETXDC_SHIFT		10
-#define SYSCON_ERXDC_MASK		GENMASK(4, 0)
 #define SYSCON_ERXDC_SHIFT		5
 /* EMAC PHY Interface Type */
 #define SYSCON_EPIT			BIT(2) /* 1: RGMII, 0: MII */
@@ -847,8 +859,9 @@ static int sun8i_dwmac_set_syscon(struct stmmac_priv *priv)
 		}
 		val /= 100;
 		dev_dbg(priv->device, "set tx-delay to %x\n", val);
-		if (val <= SYSCON_ETXDC_MASK) {
-			reg &= ~(SYSCON_ETXDC_MASK << SYSCON_ETXDC_SHIFT);
+		if (val <= gmac->variant->tx_delay_max) {
+			reg &= ~(gmac->variant->tx_delay_max <<
+				 SYSCON_ETXDC_SHIFT);
 			reg |= (val << SYSCON_ETXDC_SHIFT);
 		} else {
 			dev_err(priv->device, "Invalid TX clock delay: %d\n",
@@ -864,8 +877,9 @@ static int sun8i_dwmac_set_syscon(struct stmmac_priv *priv)
 		}
 		val /= 100;
 		dev_dbg(priv->device, "set rx-delay to %x\n", val);
-		if (val <= SYSCON_ERXDC_MASK) {
-			reg &= ~(SYSCON_ERXDC_MASK << SYSCON_ERXDC_SHIFT);
+		if (val <= gmac->variant->rx_delay_max) {
+			reg &= ~(gmac->variant->rx_delay_max <<
+				 SYSCON_ERXDC_SHIFT);
 			reg |= (val << SYSCON_ERXDC_SHIFT);
 		} else {
 			dev_err(priv->device, "Invalid RX clock delay: %d\n",
-- 
2.17.0

^ permalink raw reply related	[flat|nested] 80+ messages in thread
* [PATCH net-next v2 09/15] net: stmmac: dwmac-sun8i: Support different ranges for TX/RX delay chains
@ 2018-05-01 16:12   ` Chen-Yu Tsai
  0 siblings, 0 replies; 80+ messages in thread
From: Chen-Yu Tsai @ 2018-05-01 16:12 UTC (permalink / raw)
  To: linux-arm-kernel

On the R40 SoC, the RX delay chain only has a range of 0~7 (hundred
picoseconds), instead of 0~31. Also the TX delay chain is completely
absent.

This patch adds support for different ranges by adding per-compatible
maximum values in the variant data. A maximum of 0 indicates that the
delay chain is not supported or absent.

Signed-off-by: Chen-Yu Tsai <wens@csie.org>
---
 .../net/ethernet/stmicro/stmmac/dwmac-sun8i.c | 32 +++++++++++++------
 1 file changed, 23 insertions(+), 9 deletions(-)

diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c b/drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c
index 79e104a20e20..4f5612a3c855 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c
@@ -47,6 +47,12 @@
  * @support_mii:		Does the MAC handle MII
  * @support_rmii:		Does the MAC handle RMII
  * @support_rgmii:		Does the MAC handle RGMII
+ *
+ * @rx_delay_max:		Maximum raw value for RX delay chain
+ * @tx_delay_max:		Maximum raw value for TX delay chain
+ *				These two also indicate the bitmask for
+ *				the RX and TX delay chain registers. A
+ *				value of zero indicates this is not supported.
  */
 struct emac_variant {
 	u32 default_syscon_value;
@@ -55,6 +61,8 @@ struct emac_variant {
 	bool support_mii;
 	bool support_rmii;
 	bool support_rgmii;
+	u8 rx_delay_max;
+	u8 tx_delay_max;
 };
 
 /* struct sunxi_priv_data - hold all sunxi private data
@@ -91,7 +99,9 @@ static const struct emac_variant emac_variant_h3 = {
 	.soc_has_internal_phy = true,
 	.support_mii = true,
 	.support_rmii = true,
-	.support_rgmii = true
+	.support_rgmii = true,
+	.rx_delay_max = 31,
+	.tx_delay_max = 7,
 };
 
 static const struct emac_variant emac_variant_v3s = {
@@ -106,7 +116,9 @@ static const struct emac_variant emac_variant_a83t = {
 	.syscon_field = &sun8i_syscon_reg_field,
 	.soc_has_internal_phy = false,
 	.support_mii = true,
-	.support_rgmii = true
+	.support_rgmii = true,
+	.rx_delay_max = 31,
+	.tx_delay_max = 7,
 };
 
 static const struct emac_variant emac_variant_a64 = {
@@ -115,7 +127,9 @@ static const struct emac_variant emac_variant_a64 = {
 	.soc_has_internal_phy = false,
 	.support_mii = true,
 	.support_rmii = true,
-	.support_rgmii = true
+	.support_rgmii = true,
+	.rx_delay_max = 31,
+	.tx_delay_max = 7,
 };
 
 #define EMAC_BASIC_CTL0 0x00
@@ -219,9 +233,7 @@ static const struct emac_variant emac_variant_a64 = {
 #define SYSCON_RMII_EN		BIT(13) /* 1: enable RMII (overrides EPIT) */
 
 /* Generic system control EMAC_CLK bits */
-#define SYSCON_ETXDC_MASK		GENMASK(2, 0)
 #define SYSCON_ETXDC_SHIFT		10
-#define SYSCON_ERXDC_MASK		GENMASK(4, 0)
 #define SYSCON_ERXDC_SHIFT		5
 /* EMAC PHY Interface Type */
 #define SYSCON_EPIT			BIT(2) /* 1: RGMII, 0: MII */
@@ -847,8 +859,9 @@ static int sun8i_dwmac_set_syscon(struct stmmac_priv *priv)
 		}
 		val /= 100;
 		dev_dbg(priv->device, "set tx-delay to %x\n", val);
-		if (val <= SYSCON_ETXDC_MASK) {
-			reg &= ~(SYSCON_ETXDC_MASK << SYSCON_ETXDC_SHIFT);
+		if (val <= gmac->variant->tx_delay_max) {
+			reg &= ~(gmac->variant->tx_delay_max <<
+				 SYSCON_ETXDC_SHIFT);
 			reg |= (val << SYSCON_ETXDC_SHIFT);
 		} else {
 			dev_err(priv->device, "Invalid TX clock delay: %d\n",
@@ -864,8 +877,9 @@ static int sun8i_dwmac_set_syscon(struct stmmac_priv *priv)
 		}
 		val /= 100;
 		dev_dbg(priv->device, "set rx-delay to %x\n", val);
-		if (val <= SYSCON_ERXDC_MASK) {
-			reg &= ~(SYSCON_ERXDC_MASK << SYSCON_ERXDC_SHIFT);
+		if (val <= gmac->variant->rx_delay_max) {
+			reg &= ~(gmac->variant->rx_delay_max <<
+				 SYSCON_ERXDC_SHIFT);
 			reg |= (val << SYSCON_ERXDC_SHIFT);
 		} else {
 			dev_err(priv->device, "Invalid RX clock delay: %d\n",
-- 
2.17.0

^ permalink raw reply related	[flat|nested] 80+ messages in thread
* [PATCH net-next v2 10/15] net: stmmac: dwmac-sun8i: Add support for GMAC on Allwinner R40 SoC
  2018-05-01 16:12 ` Chen-Yu Tsai
  (?)
@ 2018-05-01 16:12   ` Chen-Yu Tsai
  -1 siblings, 0 replies; 80+ messages in thread
From: Chen-Yu Tsai @ 2018-05-01 16:12 UTC (permalink / raw)
  To: Maxime Ripard, Michael Turquette, Stephen Boyd,
	Giuseppe Cavallaro, Rob Herring, Mark Rutland, Mark Brown
  Cc: devicetree, netdev, Chen-Yu Tsai, Corentin Labbe, linux-clk,
	linux-arm-kernel, Icenowy Zheng

The Allwinner R40 SoC has the EMAC controller supported by dwmac-sun8i.
It is named "GMAC", while EMAC refers to the 10/100 Mbps Ethernet
controller supported by sun4i-emac. The controller is the same, but
the R40 has the glue layer controls in the clock control unit (CCU),
with a reduced RX delay chain, and no TX delay chain.

This patch adds support for it using the framework laid out by previous
patches to map the differences.

Signed-off-by: Chen-Yu Tsai <wens@csie.org>
---
 .../net/ethernet/stmicro/stmmac/dwmac-sun8i.c   | 17 +++++++++++++++++
 1 file changed, 17 insertions(+)

diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c b/drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c
index 4f5612a3c855..2f7f0915f071 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c
@@ -93,6 +93,13 @@ static const struct reg_field sun8i_syscon_reg_field = {
 	.msb = 31,
 };
 
+/* EMAC clock register @ 0x164 in the CCU address range */
+static const struct reg_field sun8i_ccu_reg_field = {
+	.reg = 0x164,
+	.lsb = 0,
+	.msb = 31,
+};
+
 static const struct emac_variant emac_variant_h3 = {
 	.default_syscon_value = 0x58000,
 	.syscon_field = &sun8i_syscon_reg_field,
@@ -121,6 +128,14 @@ static const struct emac_variant emac_variant_a83t = {
 	.tx_delay_max = 7,
 };
 
+static const struct emac_variant emac_variant_r40 = {
+	.default_syscon_value = 0,
+	.syscon_field = &sun8i_ccu_reg_field,
+	.support_mii = true,
+	.support_rgmii = true,
+	.rx_delay_max = 7,
+};
+
 static const struct emac_variant emac_variant_a64 = {
 	.default_syscon_value = 0,
 	.syscon_field = &sun8i_syscon_reg_field,
@@ -1160,6 +1175,8 @@ static const struct of_device_id sun8i_dwmac_match[] = {
 		.data = &emac_variant_v3s },
 	{ .compatible = "allwinner,sun8i-a83t-emac",
 		.data = &emac_variant_a83t },
+	{ .compatible = "allwinner,sun8i-r40-gmac",
+		.data = &emac_variant_r40 },
 	{ .compatible = "allwinner,sun50i-a64-emac",
 		.data = &emac_variant_a64 },
 	{ }
-- 
2.17.0

^ permalink raw reply related	[flat|nested] 80+ messages in thread
* [PATCH net-next v2 10/15] net: stmmac: dwmac-sun8i: Add support for GMAC on Allwinner R40 SoC
@ 2018-05-01 16:12   ` Chen-Yu Tsai
  0 siblings, 0 replies; 80+ messages in thread
From: Chen-Yu Tsai @ 2018-05-01 16:12 UTC (permalink / raw)
  To: Maxime Ripard, Michael Turquette, Stephen Boyd,
	Giuseppe Cavallaro, Rob Herring, Mark Rutland, Mark Brown
  Cc: Chen-Yu Tsai, linux-arm-kernel, linux-clk, devicetree, netdev,
	Corentin Labbe, Icenowy Zheng

The Allwinner R40 SoC has the EMAC controller supported by dwmac-sun8i.
It is named "GMAC", while EMAC refers to the 10/100 Mbps Ethernet
controller supported by sun4i-emac. The controller is the same, but
the R40 has the glue layer controls in the clock control unit (CCU),
with a reduced RX delay chain, and no TX delay chain.

This patch adds support for it using the framework laid out by previous
patches to map the differences.

Signed-off-by: Chen-Yu Tsai <wens@csie.org>
---
 .../net/ethernet/stmicro/stmmac/dwmac-sun8i.c   | 17 +++++++++++++++++
 1 file changed, 17 insertions(+)

diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c b/drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c
index 4f5612a3c855..2f7f0915f071 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c
@@ -93,6 +93,13 @@ static const struct reg_field sun8i_syscon_reg_field = {
 	.msb = 31,
 };
 
+/* EMAC clock register @ 0x164 in the CCU address range */
+static const struct reg_field sun8i_ccu_reg_field = {
+	.reg = 0x164,
+	.lsb = 0,
+	.msb = 31,
+};
+
 static const struct emac_variant emac_variant_h3 = {
 	.default_syscon_value = 0x58000,
 	.syscon_field = &sun8i_syscon_reg_field,
@@ -121,6 +128,14 @@ static const struct emac_variant emac_variant_a83t = {
 	.tx_delay_max = 7,
 };
 
+static const struct emac_variant emac_variant_r40 = {
+	.default_syscon_value = 0,
+	.syscon_field = &sun8i_ccu_reg_field,
+	.support_mii = true,
+	.support_rgmii = true,
+	.rx_delay_max = 7,
+};
+
 static const struct emac_variant emac_variant_a64 = {
 	.default_syscon_value = 0,
 	.syscon_field = &sun8i_syscon_reg_field,
@@ -1160,6 +1175,8 @@ static const struct of_device_id sun8i_dwmac_match[] = {
 		.data = &emac_variant_v3s },
 	{ .compatible = "allwinner,sun8i-a83t-emac",
 		.data = &emac_variant_a83t },
+	{ .compatible = "allwinner,sun8i-r40-gmac",
+		.data = &emac_variant_r40 },
 	{ .compatible = "allwinner,sun50i-a64-emac",
 		.data = &emac_variant_a64 },
 	{ }
-- 
2.17.0

^ permalink raw reply related	[flat|nested] 80+ messages in thread
* [PATCH net-next v2 10/15] net: stmmac: dwmac-sun8i: Add support for GMAC on Allwinner R40 SoC
@ 2018-05-01 16:12   ` Chen-Yu Tsai
  0 siblings, 0 replies; 80+ messages in thread
From: Chen-Yu Tsai @ 2018-05-01 16:12 UTC (permalink / raw)
  To: linux-arm-kernel

The Allwinner R40 SoC has the EMAC controller supported by dwmac-sun8i.
It is named "GMAC", while EMAC refers to the 10/100 Mbps Ethernet
controller supported by sun4i-emac. The controller is the same, but
the R40 has the glue layer controls in the clock control unit (CCU),
with a reduced RX delay chain, and no TX delay chain.

This patch adds support for it using the framework laid out by previous
patches to map the differences.

Signed-off-by: Chen-Yu Tsai <wens@csie.org>
---
 .../net/ethernet/stmicro/stmmac/dwmac-sun8i.c   | 17 +++++++++++++++++
 1 file changed, 17 insertions(+)

diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c b/drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c
index 4f5612a3c855..2f7f0915f071 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c
@@ -93,6 +93,13 @@ static const struct reg_field sun8i_syscon_reg_field = {
 	.msb = 31,
 };
 
+/* EMAC clock register @ 0x164 in the CCU address range */
+static const struct reg_field sun8i_ccu_reg_field = {
+	.reg = 0x164,
+	.lsb = 0,
+	.msb = 31,
+};
+
 static const struct emac_variant emac_variant_h3 = {
 	.default_syscon_value = 0x58000,
 	.syscon_field = &sun8i_syscon_reg_field,
@@ -121,6 +128,14 @@ static const struct emac_variant emac_variant_a83t = {
 	.tx_delay_max = 7,
 };
 
+static const struct emac_variant emac_variant_r40 = {
+	.default_syscon_value = 0,
+	.syscon_field = &sun8i_ccu_reg_field,
+	.support_mii = true,
+	.support_rgmii = true,
+	.rx_delay_max = 7,
+};
+
 static const struct emac_variant emac_variant_a64 = {
 	.default_syscon_value = 0,
 	.syscon_field = &sun8i_syscon_reg_field,
@@ -1160,6 +1175,8 @@ static const struct of_device_id sun8i_dwmac_match[] = {
 		.data = &emac_variant_v3s },
 	{ .compatible = "allwinner,sun8i-a83t-emac",
 		.data = &emac_variant_a83t },
+	{ .compatible = "allwinner,sun8i-r40-gmac",
+		.data = &emac_variant_r40 },
 	{ .compatible = "allwinner,sun50i-a64-emac",
 		.data = &emac_variant_a64 },
 	{ }
-- 
2.17.0

^ permalink raw reply related	[flat|nested] 80+ messages in thread
* [PATCH net-next v2 11/15] ARM: dts: sun8i: r40: bananapi-m2-ultra: Sort device node dereferences
  2018-05-01 16:12 ` Chen-Yu Tsai
  (?)
@ 2018-05-01 16:12   ` Chen-Yu Tsai
  -1 siblings, 0 replies; 80+ messages in thread
From: Chen-Yu Tsai @ 2018-05-01 16:12 UTC (permalink / raw)
  To: Maxime Ripard, Michael Turquette, Stephen Boyd,
	Giuseppe Cavallaro, Rob Herring, Mark Rutland, Mark Brown
  Cc: devicetree, netdev, Chen-Yu Tsai, Corentin Labbe, linux-clk,
	linux-arm-kernel, Icenowy Zheng

The device nodes dereference (&foo) usages should be sorted by the label
names, barring any parsing order issues such as the #include statement
for the PMIC's .dtsi file that must come after the PMIC.

Move the mmc and ohci blocks in front of the PMIC's regulator blocks.

Signed-off-by: Chen-Yu Tsai <wens@csie.org>
---
 .../boot/dts/sun8i-r40-bananapi-m2-ultra.dts  | 69 ++++++++++---------
 1 file changed, 35 insertions(+), 34 deletions(-)

diff --git a/arch/arm/boot/dts/sun8i-r40-bananapi-m2-ultra.dts b/arch/arm/boot/dts/sun8i-r40-bananapi-m2-ultra.dts
index 27d9ccd0ef2f..c6da21e43572 100644
--- a/arch/arm/boot/dts/sun8i-r40-bananapi-m2-ultra.dts
+++ b/arch/arm/boot/dts/sun8i-r40-bananapi-m2-ultra.dts
@@ -114,6 +114,41 @@
 
 #include "axp22x.dtsi"
 
+&mmc0 {
+	vmmc-supply = <&reg_dcdc1>;
+	bus-width = <4>;
+	cd-gpios = <&pio 7 13 GPIO_ACTIVE_HIGH>; /* PH13 */
+	cd-inverted;
+	status = "okay";
+};
+
+&mmc1 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&mmc1_pg_pins>;
+	vmmc-supply = <&reg_dldo2>;
+	vqmmc-supply = <&reg_dldo1>;
+	mmc-pwrseq = <&wifi_pwrseq>;
+	bus-width = <4>;
+	non-removable;
+	status = "okay";
+};
+
+&mmc2 {
+	vmmc-supply = <&reg_dcdc1>;
+	vqmmc-supply = <&reg_dcdc1>;
+	bus-width = <8>;
+	non-removable;
+	status = "okay";
+};
+
+&ohci1 {
+	status = "okay";
+};
+
+&ohci2 {
+	status = "okay";
+};
+
 &reg_aldo3 {
 	regulator-always-on;
 	regulator-min-microvolt = <2700000>;
@@ -161,40 +196,6 @@
 	regulator-name = "vcc-wifi";
 };
 
-&mmc0 {
-	vmmc-supply = <&reg_dcdc1>;
-	bus-width = <4>;
-	cd-gpios = <&pio 7 13 GPIO_ACTIVE_LOW>; /* PH13 */
-	status = "okay";
-};
-
-&mmc1 {
-	pinctrl-names = "default";
-	pinctrl-0 = <&mmc1_pg_pins>;
-	vmmc-supply = <&reg_dldo2>;
-	vqmmc-supply = <&reg_dldo1>;
-	mmc-pwrseq = <&wifi_pwrseq>;
-	bus-width = <4>;
-	non-removable;
-	status = "okay";
-};
-
-&mmc2 {
-	vmmc-supply = <&reg_dcdc1>;
-	vqmmc-supply = <&reg_dcdc1>;
-	bus-width = <8>;
-	non-removable;
-	status = "okay";
-};
-
-&ohci1 {
-	status = "okay";
-};
-
-&ohci2 {
-	status = "okay";
-};
-
 &uart0 {
 	pinctrl-names = "default";
 	pinctrl-0 = <&uart0_pb_pins>;
-- 
2.17.0

^ permalink raw reply related	[flat|nested] 80+ messages in thread
* [PATCH net-next v2 11/15] ARM: dts: sun8i: r40: bananapi-m2-ultra: Sort device node dereferences
@ 2018-05-01 16:12   ` Chen-Yu Tsai
  0 siblings, 0 replies; 80+ messages in thread
From: Chen-Yu Tsai @ 2018-05-01 16:12 UTC (permalink / raw)
  To: Maxime Ripard, Michael Turquette, Stephen Boyd,
	Giuseppe Cavallaro, Rob Herring, Mark Rutland, Mark Brown
  Cc: Chen-Yu Tsai, linux-arm-kernel, linux-clk, devicetree, netdev,
	Corentin Labbe, Icenowy Zheng

The device nodes dereference (&foo) usages should be sorted by the label
names, barring any parsing order issues such as the #include statement
for the PMIC's .dtsi file that must come after the PMIC.

Move the mmc and ohci blocks in front of the PMIC's regulator blocks.

Signed-off-by: Chen-Yu Tsai <wens@csie.org>
---
 .../boot/dts/sun8i-r40-bananapi-m2-ultra.dts  | 69 ++++++++++---------
 1 file changed, 35 insertions(+), 34 deletions(-)

diff --git a/arch/arm/boot/dts/sun8i-r40-bananapi-m2-ultra.dts b/arch/arm/boot/dts/sun8i-r40-bananapi-m2-ultra.dts
index 27d9ccd0ef2f..c6da21e43572 100644
--- a/arch/arm/boot/dts/sun8i-r40-bananapi-m2-ultra.dts
+++ b/arch/arm/boot/dts/sun8i-r40-bananapi-m2-ultra.dts
@@ -114,6 +114,41 @@
 
 #include "axp22x.dtsi"
 
+&mmc0 {
+	vmmc-supply = <&reg_dcdc1>;
+	bus-width = <4>;
+	cd-gpios = <&pio 7 13 GPIO_ACTIVE_HIGH>; /* PH13 */
+	cd-inverted;
+	status = "okay";
+};
+
+&mmc1 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&mmc1_pg_pins>;
+	vmmc-supply = <&reg_dldo2>;
+	vqmmc-supply = <&reg_dldo1>;
+	mmc-pwrseq = <&wifi_pwrseq>;
+	bus-width = <4>;
+	non-removable;
+	status = "okay";
+};
+
+&mmc2 {
+	vmmc-supply = <&reg_dcdc1>;
+	vqmmc-supply = <&reg_dcdc1>;
+	bus-width = <8>;
+	non-removable;
+	status = "okay";
+};
+
+&ohci1 {
+	status = "okay";
+};
+
+&ohci2 {
+	status = "okay";
+};
+
 &reg_aldo3 {
 	regulator-always-on;
 	regulator-min-microvolt = <2700000>;
@@ -161,40 +196,6 @@
 	regulator-name = "vcc-wifi";
 };
 
-&mmc0 {
-	vmmc-supply = <&reg_dcdc1>;
-	bus-width = <4>;
-	cd-gpios = <&pio 7 13 GPIO_ACTIVE_LOW>; /* PH13 */
-	status = "okay";
-};
-
-&mmc1 {
-	pinctrl-names = "default";
-	pinctrl-0 = <&mmc1_pg_pins>;
-	vmmc-supply = <&reg_dldo2>;
-	vqmmc-supply = <&reg_dldo1>;
-	mmc-pwrseq = <&wifi_pwrseq>;
-	bus-width = <4>;
-	non-removable;
-	status = "okay";
-};
-
-&mmc2 {
-	vmmc-supply = <&reg_dcdc1>;
-	vqmmc-supply = <&reg_dcdc1>;
-	bus-width = <8>;
-	non-removable;
-	status = "okay";
-};
-
-&ohci1 {
-	status = "okay";
-};
-
-&ohci2 {
-	status = "okay";
-};
-
 &uart0 {
 	pinctrl-names = "default";
 	pinctrl-0 = <&uart0_pb_pins>;
-- 
2.17.0

^ permalink raw reply related	[flat|nested] 80+ messages in thread
* [PATCH net-next v2 11/15] ARM: dts: sun8i: r40: bananapi-m2-ultra: Sort device node dereferences
@ 2018-05-01 16:12   ` Chen-Yu Tsai
  0 siblings, 0 replies; 80+ messages in thread
From: Chen-Yu Tsai @ 2018-05-01 16:12 UTC (permalink / raw)
  To: linux-arm-kernel

The device nodes dereference (&foo) usages should be sorted by the label
names, barring any parsing order issues such as the #include statement
for the PMIC's .dtsi file that must come after the PMIC.

Move the mmc and ohci blocks in front of the PMIC's regulator blocks.

Signed-off-by: Chen-Yu Tsai <wens@csie.org>
---
 .../boot/dts/sun8i-r40-bananapi-m2-ultra.dts  | 69 ++++++++++---------
 1 file changed, 35 insertions(+), 34 deletions(-)

diff --git a/arch/arm/boot/dts/sun8i-r40-bananapi-m2-ultra.dts b/arch/arm/boot/dts/sun8i-r40-bananapi-m2-ultra.dts
index 27d9ccd0ef2f..c6da21e43572 100644
--- a/arch/arm/boot/dts/sun8i-r40-bananapi-m2-ultra.dts
+++ b/arch/arm/boot/dts/sun8i-r40-bananapi-m2-ultra.dts
@@ -114,6 +114,41 @@
 
 #include "axp22x.dtsi"
 
+&mmc0 {
+	vmmc-supply = <&reg_dcdc1>;
+	bus-width = <4>;
+	cd-gpios = <&pio 7 13 GPIO_ACTIVE_HIGH>; /* PH13 */
+	cd-inverted;
+	status = "okay";
+};
+
+&mmc1 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&mmc1_pg_pins>;
+	vmmc-supply = <&reg_dldo2>;
+	vqmmc-supply = <&reg_dldo1>;
+	mmc-pwrseq = <&wifi_pwrseq>;
+	bus-width = <4>;
+	non-removable;
+	status = "okay";
+};
+
+&mmc2 {
+	vmmc-supply = <&reg_dcdc1>;
+	vqmmc-supply = <&reg_dcdc1>;
+	bus-width = <8>;
+	non-removable;
+	status = "okay";
+};
+
+&ohci1 {
+	status = "okay";
+};
+
+&ohci2 {
+	status = "okay";
+};
+
 &reg_aldo3 {
 	regulator-always-on;
 	regulator-min-microvolt = <2700000>;
@@ -161,40 +196,6 @@
 	regulator-name = "vcc-wifi";
 };
 
-&mmc0 {
-	vmmc-supply = <&reg_dcdc1>;
-	bus-width = <4>;
-	cd-gpios = <&pio 7 13 GPIO_ACTIVE_LOW>; /* PH13 */
-	status = "okay";
-};
-
-&mmc1 {
-	pinctrl-names = "default";
-	pinctrl-0 = <&mmc1_pg_pins>;
-	vmmc-supply = <&reg_dldo2>;
-	vqmmc-supply = <&reg_dldo1>;
-	mmc-pwrseq = <&wifi_pwrseq>;
-	bus-width = <4>;
-	non-removable;
-	status = "okay";
-};
-
-&mmc2 {
-	vmmc-supply = <&reg_dcdc1>;
-	vqmmc-supply = <&reg_dcdc1>;
-	bus-width = <8>;
-	non-removable;
-	status = "okay";
-};
-
-&ohci1 {
-	status = "okay";
-};
-
-&ohci2 {
-	status = "okay";
-};
-
 &uart0 {
 	pinctrl-names = "default";
 	pinctrl-0 = <&uart0_pb_pins>;
-- 
2.17.0

^ permalink raw reply related	[flat|nested] 80+ messages in thread
* [PATCH net-next v2 12/15] ARM: dts: sun8i: r40: Add device node and RGMII pinmux node for GMAC
  2018-05-01 16:12 ` Chen-Yu Tsai
  (?)
@ 2018-05-01 16:12   ` Chen-Yu Tsai
  -1 siblings, 0 replies; 80+ messages in thread
From: Chen-Yu Tsai @ 2018-05-01 16:12 UTC (permalink / raw)
  To: Maxime Ripard, Michael Turquette, Stephen Boyd,
	Giuseppe Cavallaro, Rob Herring, Mark Rutland, Mark Brown
  Cc: devicetree, netdev, Chen-Yu Tsai, Corentin Labbe, linux-clk,
	linux-arm-kernel, Icenowy Zheng

The R40 SoC has a GMAC (gigabit capable Ethernet controller). Add a
device node for it. The only publicly available board for this SoC
uses an RGMII PHY. Add a pinmux node for it as well.

Since this SoC also has an old 10/100 Mbps EMAC, which also has an
MDIO bus controller, the MDIO bus for the GMAC is labeled "gmac_mdio".

Signed-off-by: Chen-Yu Tsai <wens@csie.org>
---
 arch/arm/boot/dts/sun8i-r40.dtsi | 34 ++++++++++++++++++++++++++++++++
 1 file changed, 34 insertions(+)

diff --git a/arch/arm/boot/dts/sun8i-r40.dtsi b/arch/arm/boot/dts/sun8i-r40.dtsi
index 173dcc1652d2..bd97ca3dc2fa 100644
--- a/arch/arm/boot/dts/sun8i-r40.dtsi
+++ b/arch/arm/boot/dts/sun8i-r40.dtsi
@@ -265,6 +265,19 @@
 			#interrupt-cells = <3>;
 			#gpio-cells = <3>;
 
+			gmac_rgmii_pins: gmac-rgmii-pins {
+				pins = "PA0", "PA1", "PA2", "PA3",
+				       "PA4", "PA5", "PA6", "PA7",
+				       "PA8", "PA10", "PA11", "PA12",
+				       "PA13", "PA15", "PA16";
+				function = "gmac";
+				/*
+				 * data lines in RGMII mode use DDR mode
+				 * and need a higher signal drive strength
+				 */
+				drive-strength = <40>;
+			};
+
 			i2c0_pins: i2c0-pins {
 				pins = "PB0", "PB1";
 				function = "i2c0";
@@ -451,6 +464,27 @@
 			#size-cells = <0>;
 		};
 
+		gmac: ethernet@1c50000 {
+			compatible = "allwinner,sun8i-r40-gmac";
+			syscon = <&ccu>;
+			reg = <0x01c50000 0x10000>;
+			interrupts = <GIC_SPI 85 IRQ_TYPE_LEVEL_HIGH>;
+			interrupt-names = "macirq";
+			resets = <&ccu RST_BUS_GMAC>;
+			reset-names = "stmmaceth";
+			clocks = <&ccu CLK_BUS_GMAC>;
+			clock-names = "stmmaceth";
+			#address-cells = <1>;
+			#size-cells = <0>;
+			status = "disabled";
+
+			gmac_mdio: mdio {
+				compatible = "snps,dwmac-mdio";
+				#address-cells = <1>;
+				#size-cells = <0>;
+			};
+		};
+
 		gic: interrupt-controller@1c81000 {
 			compatible = "arm,gic-400";
 			reg = <0x01c81000 0x1000>,
-- 
2.17.0

^ permalink raw reply related	[flat|nested] 80+ messages in thread
* [PATCH net-next v2 12/15] ARM: dts: sun8i: r40: Add device node and RGMII pinmux node for GMAC
@ 2018-05-01 16:12   ` Chen-Yu Tsai
  0 siblings, 0 replies; 80+ messages in thread
From: Chen-Yu Tsai @ 2018-05-01 16:12 UTC (permalink / raw)
  To: Maxime Ripard, Michael Turquette, Stephen Boyd,
	Giuseppe Cavallaro, Rob Herring, Mark Rutland, Mark Brown
  Cc: Chen-Yu Tsai, linux-arm-kernel, linux-clk, devicetree, netdev,
	Corentin Labbe, Icenowy Zheng

The R40 SoC has a GMAC (gigabit capable Ethernet controller). Add a
device node for it. The only publicly available board for this SoC
uses an RGMII PHY. Add a pinmux node for it as well.

Since this SoC also has an old 10/100 Mbps EMAC, which also has an
MDIO bus controller, the MDIO bus for the GMAC is labeled "gmac_mdio".

Signed-off-by: Chen-Yu Tsai <wens@csie.org>
---
 arch/arm/boot/dts/sun8i-r40.dtsi | 34 ++++++++++++++++++++++++++++++++
 1 file changed, 34 insertions(+)

diff --git a/arch/arm/boot/dts/sun8i-r40.dtsi b/arch/arm/boot/dts/sun8i-r40.dtsi
index 173dcc1652d2..bd97ca3dc2fa 100644
--- a/arch/arm/boot/dts/sun8i-r40.dtsi
+++ b/arch/arm/boot/dts/sun8i-r40.dtsi
@@ -265,6 +265,19 @@
 			#interrupt-cells = <3>;
 			#gpio-cells = <3>;
 
+			gmac_rgmii_pins: gmac-rgmii-pins {
+				pins = "PA0", "PA1", "PA2", "PA3",
+				       "PA4", "PA5", "PA6", "PA7",
+				       "PA8", "PA10", "PA11", "PA12",
+				       "PA13", "PA15", "PA16";
+				function = "gmac";
+				/*
+				 * data lines in RGMII mode use DDR mode
+				 * and need a higher signal drive strength
+				 */
+				drive-strength = <40>;
+			};
+
 			i2c0_pins: i2c0-pins {
 				pins = "PB0", "PB1";
 				function = "i2c0";
@@ -451,6 +464,27 @@
 			#size-cells = <0>;
 		};
 
+		gmac: ethernet@1c50000 {
+			compatible = "allwinner,sun8i-r40-gmac";
+			syscon = <&ccu>;
+			reg = <0x01c50000 0x10000>;
+			interrupts = <GIC_SPI 85 IRQ_TYPE_LEVEL_HIGH>;
+			interrupt-names = "macirq";
+			resets = <&ccu RST_BUS_GMAC>;
+			reset-names = "stmmaceth";
+			clocks = <&ccu CLK_BUS_GMAC>;
+			clock-names = "stmmaceth";
+			#address-cells = <1>;
+			#size-cells = <0>;
+			status = "disabled";
+
+			gmac_mdio: mdio {
+				compatible = "snps,dwmac-mdio";
+				#address-cells = <1>;
+				#size-cells = <0>;
+			};
+		};
+
 		gic: interrupt-controller@1c81000 {
 			compatible = "arm,gic-400";
 			reg = <0x01c81000 0x1000>,
-- 
2.17.0

^ permalink raw reply related	[flat|nested] 80+ messages in thread
* [PATCH net-next v2 12/15] ARM: dts: sun8i: r40: Add device node and RGMII pinmux node for GMAC
@ 2018-05-01 16:12   ` Chen-Yu Tsai
  0 siblings, 0 replies; 80+ messages in thread
From: Chen-Yu Tsai @ 2018-05-01 16:12 UTC (permalink / raw)
  To: linux-arm-kernel

The R40 SoC has a GMAC (gigabit capable Ethernet controller). Add a
device node for it. The only publicly available board for this SoC
uses an RGMII PHY. Add a pinmux node for it as well.

Since this SoC also has an old 10/100 Mbps EMAC, which also has an
MDIO bus controller, the MDIO bus for the GMAC is labeled "gmac_mdio".

Signed-off-by: Chen-Yu Tsai <wens@csie.org>
---
 arch/arm/boot/dts/sun8i-r40.dtsi | 34 ++++++++++++++++++++++++++++++++
 1 file changed, 34 insertions(+)

diff --git a/arch/arm/boot/dts/sun8i-r40.dtsi b/arch/arm/boot/dts/sun8i-r40.dtsi
index 173dcc1652d2..bd97ca3dc2fa 100644
--- a/arch/arm/boot/dts/sun8i-r40.dtsi
+++ b/arch/arm/boot/dts/sun8i-r40.dtsi
@@ -265,6 +265,19 @@
 			#interrupt-cells = <3>;
 			#gpio-cells = <3>;
 
+			gmac_rgmii_pins: gmac-rgmii-pins {
+				pins = "PA0", "PA1", "PA2", "PA3",
+				       "PA4", "PA5", "PA6", "PA7",
+				       "PA8", "PA10", "PA11", "PA12",
+				       "PA13", "PA15", "PA16";
+				function = "gmac";
+				/*
+				 * data lines in RGMII mode use DDR mode
+				 * and need a higher signal drive strength
+				 */
+				drive-strength = <40>;
+			};
+
 			i2c0_pins: i2c0-pins {
 				pins = "PB0", "PB1";
 				function = "i2c0";
@@ -451,6 +464,27 @@
 			#size-cells = <0>;
 		};
 
+		gmac: ethernet at 1c50000 {
+			compatible = "allwinner,sun8i-r40-gmac";
+			syscon = <&ccu>;
+			reg = <0x01c50000 0x10000>;
+			interrupts = <GIC_SPI 85 IRQ_TYPE_LEVEL_HIGH>;
+			interrupt-names = "macirq";
+			resets = <&ccu RST_BUS_GMAC>;
+			reset-names = "stmmaceth";
+			clocks = <&ccu CLK_BUS_GMAC>;
+			clock-names = "stmmaceth";
+			#address-cells = <1>;
+			#size-cells = <0>;
+			status = "disabled";
+
+			gmac_mdio: mdio {
+				compatible = "snps,dwmac-mdio";
+				#address-cells = <1>;
+				#size-cells = <0>;
+			};
+		};
+
 		gic: interrupt-controller at 1c81000 {
 			compatible = "arm,gic-400";
 			reg = <0x01c81000 0x1000>,
-- 
2.17.0

^ permalink raw reply related	[flat|nested] 80+ messages in thread
* [PATCH net-next v2 13/15] ARM: dts: sun8i: r40: bananapi-m2-ultra: Enable GMAC ethernet controller
  2018-05-01 16:12 ` Chen-Yu Tsai
  (?)
@ 2018-05-01 16:12   ` Chen-Yu Tsai
  -1 siblings, 0 replies; 80+ messages in thread
From: Chen-Yu Tsai @ 2018-05-01 16:12 UTC (permalink / raw)
  To: Maxime Ripard, Michael Turquette, Stephen Boyd,
	Giuseppe Cavallaro, Rob Herring, Mark Rutland, Mark Brown
  Cc: devicetree, netdev, Chen-Yu Tsai, Corentin Labbe, linux-clk,
	linux-arm-kernel, Icenowy Zheng

The Bananapi M2 Ultra has a Realtek RTL8211E RGMII PHY tied to the GMAC.
The PMIC's DC1SW output provides power for the PHY, while the ALDO2
output provides I/O voltages on both sides.

Signed-off-by: Chen-Yu Tsai <wens@csie.org>
---
 .../boot/dts/sun8i-r40-bananapi-m2-ultra.dts  | 30 +++++++++++++++++++
 1 file changed, 30 insertions(+)

diff --git a/arch/arm/boot/dts/sun8i-r40-bananapi-m2-ultra.dts b/arch/arm/boot/dts/sun8i-r40-bananapi-m2-ultra.dts
index c6da21e43572..25fb048c7df2 100644
--- a/arch/arm/boot/dts/sun8i-r40-bananapi-m2-ultra.dts
+++ b/arch/arm/boot/dts/sun8i-r40-bananapi-m2-ultra.dts
@@ -51,6 +51,7 @@
 	compatible = "sinovoip,bpi-m2-ultra", "allwinner,sun8i-r40";
 
 	aliases {
+		ethernet0 = &gmac;
 		serial0 = &uart0;
 	};
 
@@ -101,6 +102,22 @@
 	status = "okay";
 };
 
+&gmac {
+	pinctrl-names = "default";
+	pinctrl-0 = <&gmac_rgmii_pins>;
+	phy-handle = <&phy1>;
+	phy-mode = "rgmii";
+	phy-supply = <&reg_dc1sw>;
+	status = "okay";
+};
+
+&gmac_mdio {
+	phy1: ethernet-phy@1 {
+		compatible = "ethernet-phy-ieee802.3-c22";
+		reg = <1>;
+	};
+};
+
 &i2c0 {
 	status = "okay";
 
@@ -149,6 +166,13 @@
 	status = "okay";
 };
 
+&reg_aldo2 {
+	regulator-always-on;
+	regulator-min-microvolt = <2500000>;
+	regulator-max-microvolt = <2500000>;
+	regulator-name = "vcc-pa";
+};
+
 &reg_aldo3 {
 	regulator-always-on;
 	regulator-min-microvolt = <2700000>;
@@ -156,6 +180,12 @@
 	regulator-name = "avcc";
 };
 
+&reg_dc1sw {
+	regulator-min-microvolt = <3000000>;
+	regulator-max-microvolt = <3000000>;
+	regulator-name = "vcc-gmac-phy";
+};
+
 &reg_dcdc1 {
 	regulator-always-on;
 	regulator-min-microvolt = <3000000>;
-- 
2.17.0

^ permalink raw reply related	[flat|nested] 80+ messages in thread
* [PATCH net-next v2 13/15] ARM: dts: sun8i: r40: bananapi-m2-ultra: Enable GMAC ethernet controller
@ 2018-05-01 16:12   ` Chen-Yu Tsai
  0 siblings, 0 replies; 80+ messages in thread
From: Chen-Yu Tsai @ 2018-05-01 16:12 UTC (permalink / raw)
  To: Maxime Ripard, Michael Turquette, Stephen Boyd,
	Giuseppe Cavallaro, Rob Herring, Mark Rutland, Mark Brown
  Cc: Chen-Yu Tsai, linux-arm-kernel, linux-clk, devicetree, netdev,
	Corentin Labbe, Icenowy Zheng

The Bananapi M2 Ultra has a Realtek RTL8211E RGMII PHY tied to the GMAC.
The PMIC's DC1SW output provides power for the PHY, while the ALDO2
output provides I/O voltages on both sides.

Signed-off-by: Chen-Yu Tsai <wens@csie.org>
---
 .../boot/dts/sun8i-r40-bananapi-m2-ultra.dts  | 30 +++++++++++++++++++
 1 file changed, 30 insertions(+)

diff --git a/arch/arm/boot/dts/sun8i-r40-bananapi-m2-ultra.dts b/arch/arm/boot/dts/sun8i-r40-bananapi-m2-ultra.dts
index c6da21e43572..25fb048c7df2 100644
--- a/arch/arm/boot/dts/sun8i-r40-bananapi-m2-ultra.dts
+++ b/arch/arm/boot/dts/sun8i-r40-bananapi-m2-ultra.dts
@@ -51,6 +51,7 @@
 	compatible = "sinovoip,bpi-m2-ultra", "allwinner,sun8i-r40";
 
 	aliases {
+		ethernet0 = &gmac;
 		serial0 = &uart0;
 	};
 
@@ -101,6 +102,22 @@
 	status = "okay";
 };
 
+&gmac {
+	pinctrl-names = "default";
+	pinctrl-0 = <&gmac_rgmii_pins>;
+	phy-handle = <&phy1>;
+	phy-mode = "rgmii";
+	phy-supply = <&reg_dc1sw>;
+	status = "okay";
+};
+
+&gmac_mdio {
+	phy1: ethernet-phy@1 {
+		compatible = "ethernet-phy-ieee802.3-c22";
+		reg = <1>;
+	};
+};
+
 &i2c0 {
 	status = "okay";
 
@@ -149,6 +166,13 @@
 	status = "okay";
 };
 
+&reg_aldo2 {
+	regulator-always-on;
+	regulator-min-microvolt = <2500000>;
+	regulator-max-microvolt = <2500000>;
+	regulator-name = "vcc-pa";
+};
+
 &reg_aldo3 {
 	regulator-always-on;
 	regulator-min-microvolt = <2700000>;
@@ -156,6 +180,12 @@
 	regulator-name = "avcc";
 };
 
+&reg_dc1sw {
+	regulator-min-microvolt = <3000000>;
+	regulator-max-microvolt = <3000000>;
+	regulator-name = "vcc-gmac-phy";
+};
+
 &reg_dcdc1 {
 	regulator-always-on;
 	regulator-min-microvolt = <3000000>;
-- 
2.17.0

^ permalink raw reply related	[flat|nested] 80+ messages in thread
* [PATCH net-next v2 13/15] ARM: dts: sun8i: r40: bananapi-m2-ultra: Enable GMAC ethernet controller
@ 2018-05-01 16:12   ` Chen-Yu Tsai
  0 siblings, 0 replies; 80+ messages in thread
From: Chen-Yu Tsai @ 2018-05-01 16:12 UTC (permalink / raw)
  To: linux-arm-kernel

The Bananapi M2 Ultra has a Realtek RTL8211E RGMII PHY tied to the GMAC.
The PMIC's DC1SW output provides power for the PHY, while the ALDO2
output provides I/O voltages on both sides.

Signed-off-by: Chen-Yu Tsai <wens@csie.org>
---
 .../boot/dts/sun8i-r40-bananapi-m2-ultra.dts  | 30 +++++++++++++++++++
 1 file changed, 30 insertions(+)

diff --git a/arch/arm/boot/dts/sun8i-r40-bananapi-m2-ultra.dts b/arch/arm/boot/dts/sun8i-r40-bananapi-m2-ultra.dts
index c6da21e43572..25fb048c7df2 100644
--- a/arch/arm/boot/dts/sun8i-r40-bananapi-m2-ultra.dts
+++ b/arch/arm/boot/dts/sun8i-r40-bananapi-m2-ultra.dts
@@ -51,6 +51,7 @@
 	compatible = "sinovoip,bpi-m2-ultra", "allwinner,sun8i-r40";
 
 	aliases {
+		ethernet0 = &gmac;
 		serial0 = &uart0;
 	};
 
@@ -101,6 +102,22 @@
 	status = "okay";
 };
 
+&gmac {
+	pinctrl-names = "default";
+	pinctrl-0 = <&gmac_rgmii_pins>;
+	phy-handle = <&phy1>;
+	phy-mode = "rgmii";
+	phy-supply = <&reg_dc1sw>;
+	status = "okay";
+};
+
+&gmac_mdio {
+	phy1: ethernet-phy at 1 {
+		compatible = "ethernet-phy-ieee802.3-c22";
+		reg = <1>;
+	};
+};
+
 &i2c0 {
 	status = "okay";
 
@@ -149,6 +166,13 @@
 	status = "okay";
 };
 
+&reg_aldo2 {
+	regulator-always-on;
+	regulator-min-microvolt = <2500000>;
+	regulator-max-microvolt = <2500000>;
+	regulator-name = "vcc-pa";
+};
+
 &reg_aldo3 {
 	regulator-always-on;
 	regulator-min-microvolt = <2700000>;
@@ -156,6 +180,12 @@
 	regulator-name = "avcc";
 };
 
+&reg_dc1sw {
+	regulator-min-microvolt = <3000000>;
+	regulator-max-microvolt = <3000000>;
+	regulator-name = "vcc-gmac-phy";
+};
+
 &reg_dcdc1 {
 	regulator-always-on;
 	regulator-min-microvolt = <3000000>;
-- 
2.17.0

^ permalink raw reply related	[flat|nested] 80+ messages in thread
* [PATCH net-next v2 14/15] soc: sunxi: export a regmap for EMAC clock reg on A64
  2018-05-01 16:12 ` Chen-Yu Tsai
  (?)
@ 2018-05-01 16:12   ` Chen-Yu Tsai
  -1 siblings, 0 replies; 80+ messages in thread
From: Chen-Yu Tsai @ 2018-05-01 16:12 UTC (permalink / raw)
  To: Maxime Ripard, Michael Turquette, Stephen Boyd,
	Giuseppe Cavallaro, Rob Herring, Mark Rutland, Mark Brown
  Cc: devicetree, netdev, Chen-Yu Tsai, Corentin Labbe, linux-clk,
	linux-arm-kernel, Icenowy Zheng

From: Icenowy Zheng <icenowy@aosc.io>

The A64 SRAM controller memory zone has a EMAC clock register, which is
needed by the Ethernet MAC driver (dwmac-sun8i).

Export a regmap for this register on A64.

Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
[wens@csie.org: export whole address range with only EMAC register
		accessible and drop regmap name]
Signed-off-by: Chen-Yu Tsai <wens@csie.org>
---
 drivers/soc/sunxi/sunxi_sram.c | 57 ++++++++++++++++++++++++++++++++--
 1 file changed, 55 insertions(+), 2 deletions(-)

diff --git a/drivers/soc/sunxi/sunxi_sram.c b/drivers/soc/sunxi/sunxi_sram.c
index 882be5ed7e84..eec7fc6e9f66 100644
--- a/drivers/soc/sunxi/sunxi_sram.c
+++ b/drivers/soc/sunxi/sunxi_sram.c
@@ -17,6 +17,7 @@
 #include <linux/of_address.h>
 #include <linux/of_device.h>
 #include <linux/platform_device.h>
+#include <linux/regmap.h>
 
 #include <linux/soc/sunxi/sunxi_sram.h>
 
@@ -281,13 +282,51 @@ int sunxi_sram_release(struct device *dev)
 }
 EXPORT_SYMBOL(sunxi_sram_release);
 
+struct sunxi_sramc_variant {
+	bool has_emac_clock;
+};
+
+static const struct sunxi_sramc_variant sun4i_a10_sramc_variant = {
+	/* Nothing special */
+};
+
+static const struct sunxi_sramc_variant sun50i_a64_sramc_variant = {
+	.has_emac_clock = true,
+};
+
+#define SUNXI_SRAM_EMAC_CLOCK_REG	0x30
+static bool sunxi_sram_regmap_accessible_reg(struct device *dev,
+					     unsigned int reg)
+{
+	if (reg == SUNXI_SRAM_EMAC_CLOCK_REG)
+		return true;
+	return false;
+}
+
+static struct regmap_config sunxi_sram_emac_clock_regmap = {
+	.reg_bits       = 32,
+	.val_bits       = 32,
+	.reg_stride     = 4,
+	/* last defined register */
+	.max_register   = SUNXI_SRAM_EMAC_CLOCK_REG,
+	/* other devices have no business accessing other registers */
+	.readable_reg	= sunxi_sram_regmap_accessible_reg,
+	.writeable_reg	= sunxi_sram_regmap_accessible_reg,
+};
+
 static int sunxi_sram_probe(struct platform_device *pdev)
 {
 	struct resource *res;
 	struct dentry *d;
+	struct regmap *emac_clock;
+	const struct sunxi_sramc_variant *variant;
 
 	sram_dev = &pdev->dev;
 
+	variant = of_device_get_match_data(&pdev->dev);
+	if (!variant)
+		return -EINVAL;
+
 	res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
 	base = devm_ioremap_resource(&pdev->dev, res);
 	if (IS_ERR(base))
@@ -300,12 +339,26 @@ static int sunxi_sram_probe(struct platform_device *pdev)
 	if (!d)
 		return -ENOMEM;
 
+	if (variant->has_emac_clock) {
+		emac_clock = devm_regmap_init_mmio(&pdev->dev, base,
+						   &sunxi_sram_emac_clock_regmap);
+
+		if (IS_ERR(emac_clock))
+			return PTR_ERR(emac_clock);
+	}
+
 	return 0;
 }
 
 static const struct of_device_id sunxi_sram_dt_match[] = {
-	{ .compatible = "allwinner,sun4i-a10-sram-controller" },
-	{ .compatible = "allwinner,sun50i-a64-sram-controller" },
+	{
+		.compatible = "allwinner,sun4i-a10-sram-controller",
+		.data = &sun4i_a10_sramc_variant,
+	},
+	{
+		.compatible = "allwinner,sun50i-a64-sram-controller",
+		.data = &sun50i_a64_sramc_variant,
+	},
 	{ },
 };
 MODULE_DEVICE_TABLE(of, sunxi_sram_dt_match);
-- 
2.17.0

^ permalink raw reply related	[flat|nested] 80+ messages in thread
* [PATCH net-next v2 14/15] soc: sunxi: export a regmap for EMAC clock reg on A64
@ 2018-05-01 16:12   ` Chen-Yu Tsai
  0 siblings, 0 replies; 80+ messages in thread
From: Chen-Yu Tsai @ 2018-05-01 16:12 UTC (permalink / raw)
  To: Maxime Ripard, Michael Turquette, Stephen Boyd,
	Giuseppe Cavallaro, Rob Herring, Mark Rutland, Mark Brown
  Cc: Icenowy Zheng, linux-arm-kernel, linux-clk, devicetree, netdev,
	Corentin Labbe, Chen-Yu Tsai

From: Icenowy Zheng <icenowy@aosc.io>

The A64 SRAM controller memory zone has a EMAC clock register, which is
needed by the Ethernet MAC driver (dwmac-sun8i).

Export a regmap for this register on A64.

Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
[wens@csie.org: export whole address range with only EMAC register
		accessible and drop regmap name]
Signed-off-by: Chen-Yu Tsai <wens@csie.org>
---
 drivers/soc/sunxi/sunxi_sram.c | 57 ++++++++++++++++++++++++++++++++--
 1 file changed, 55 insertions(+), 2 deletions(-)

diff --git a/drivers/soc/sunxi/sunxi_sram.c b/drivers/soc/sunxi/sunxi_sram.c
index 882be5ed7e84..eec7fc6e9f66 100644
--- a/drivers/soc/sunxi/sunxi_sram.c
+++ b/drivers/soc/sunxi/sunxi_sram.c
@@ -17,6 +17,7 @@
 #include <linux/of_address.h>
 #include <linux/of_device.h>
 #include <linux/platform_device.h>
+#include <linux/regmap.h>
 
 #include <linux/soc/sunxi/sunxi_sram.h>
 
@@ -281,13 +282,51 @@ int sunxi_sram_release(struct device *dev)
 }
 EXPORT_SYMBOL(sunxi_sram_release);
 
+struct sunxi_sramc_variant {
+	bool has_emac_clock;
+};
+
+static const struct sunxi_sramc_variant sun4i_a10_sramc_variant = {
+	/* Nothing special */
+};
+
+static const struct sunxi_sramc_variant sun50i_a64_sramc_variant = {
+	.has_emac_clock = true,
+};
+
+#define SUNXI_SRAM_EMAC_CLOCK_REG	0x30
+static bool sunxi_sram_regmap_accessible_reg(struct device *dev,
+					     unsigned int reg)
+{
+	if (reg == SUNXI_SRAM_EMAC_CLOCK_REG)
+		return true;
+	return false;
+}
+
+static struct regmap_config sunxi_sram_emac_clock_regmap = {
+	.reg_bits       = 32,
+	.val_bits       = 32,
+	.reg_stride     = 4,
+	/* last defined register */
+	.max_register   = SUNXI_SRAM_EMAC_CLOCK_REG,
+	/* other devices have no business accessing other registers */
+	.readable_reg	= sunxi_sram_regmap_accessible_reg,
+	.writeable_reg	= sunxi_sram_regmap_accessible_reg,
+};
+
 static int sunxi_sram_probe(struct platform_device *pdev)
 {
 	struct resource *res;
 	struct dentry *d;
+	struct regmap *emac_clock;
+	const struct sunxi_sramc_variant *variant;
 
 	sram_dev = &pdev->dev;
 
+	variant = of_device_get_match_data(&pdev->dev);
+	if (!variant)
+		return -EINVAL;
+
 	res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
 	base = devm_ioremap_resource(&pdev->dev, res);
 	if (IS_ERR(base))
@@ -300,12 +339,26 @@ static int sunxi_sram_probe(struct platform_device *pdev)
 	if (!d)
 		return -ENOMEM;
 
+	if (variant->has_emac_clock) {
+		emac_clock = devm_regmap_init_mmio(&pdev->dev, base,
+						   &sunxi_sram_emac_clock_regmap);
+
+		if (IS_ERR(emac_clock))
+			return PTR_ERR(emac_clock);
+	}
+
 	return 0;
 }
 
 static const struct of_device_id sunxi_sram_dt_match[] = {
-	{ .compatible = "allwinner,sun4i-a10-sram-controller" },
-	{ .compatible = "allwinner,sun50i-a64-sram-controller" },
+	{
+		.compatible = "allwinner,sun4i-a10-sram-controller",
+		.data = &sun4i_a10_sramc_variant,
+	},
+	{
+		.compatible = "allwinner,sun50i-a64-sram-controller",
+		.data = &sun50i_a64_sramc_variant,
+	},
 	{ },
 };
 MODULE_DEVICE_TABLE(of, sunxi_sram_dt_match);
-- 
2.17.0

^ permalink raw reply related	[flat|nested] 80+ messages in thread
* [PATCH net-next v2 14/15] soc: sunxi: export a regmap for EMAC clock reg on A64
@ 2018-05-01 16:12   ` Chen-Yu Tsai
  0 siblings, 0 replies; 80+ messages in thread
From: Chen-Yu Tsai @ 2018-05-01 16:12 UTC (permalink / raw)
  To: linux-arm-kernel

From: Icenowy Zheng <icenowy@aosc.io>

The A64 SRAM controller memory zone has a EMAC clock register, which is
needed by the Ethernet MAC driver (dwmac-sun8i).

Export a regmap for this register on A64.

Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
[wens at csie.org: export whole address range with only EMAC register
		accessible and drop regmap name]
Signed-off-by: Chen-Yu Tsai <wens@csie.org>
---
 drivers/soc/sunxi/sunxi_sram.c | 57 ++++++++++++++++++++++++++++++++--
 1 file changed, 55 insertions(+), 2 deletions(-)

diff --git a/drivers/soc/sunxi/sunxi_sram.c b/drivers/soc/sunxi/sunxi_sram.c
index 882be5ed7e84..eec7fc6e9f66 100644
--- a/drivers/soc/sunxi/sunxi_sram.c
+++ b/drivers/soc/sunxi/sunxi_sram.c
@@ -17,6 +17,7 @@
 #include <linux/of_address.h>
 #include <linux/of_device.h>
 #include <linux/platform_device.h>
+#include <linux/regmap.h>
 
 #include <linux/soc/sunxi/sunxi_sram.h>
 
@@ -281,13 +282,51 @@ int sunxi_sram_release(struct device *dev)
 }
 EXPORT_SYMBOL(sunxi_sram_release);
 
+struct sunxi_sramc_variant {
+	bool has_emac_clock;
+};
+
+static const struct sunxi_sramc_variant sun4i_a10_sramc_variant = {
+	/* Nothing special */
+};
+
+static const struct sunxi_sramc_variant sun50i_a64_sramc_variant = {
+	.has_emac_clock = true,
+};
+
+#define SUNXI_SRAM_EMAC_CLOCK_REG	0x30
+static bool sunxi_sram_regmap_accessible_reg(struct device *dev,
+					     unsigned int reg)
+{
+	if (reg == SUNXI_SRAM_EMAC_CLOCK_REG)
+		return true;
+	return false;
+}
+
+static struct regmap_config sunxi_sram_emac_clock_regmap = {
+	.reg_bits       = 32,
+	.val_bits       = 32,
+	.reg_stride     = 4,
+	/* last defined register */
+	.max_register   = SUNXI_SRAM_EMAC_CLOCK_REG,
+	/* other devices have no business accessing other registers */
+	.readable_reg	= sunxi_sram_regmap_accessible_reg,
+	.writeable_reg	= sunxi_sram_regmap_accessible_reg,
+};
+
 static int sunxi_sram_probe(struct platform_device *pdev)
 {
 	struct resource *res;
 	struct dentry *d;
+	struct regmap *emac_clock;
+	const struct sunxi_sramc_variant *variant;
 
 	sram_dev = &pdev->dev;
 
+	variant = of_device_get_match_data(&pdev->dev);
+	if (!variant)
+		return -EINVAL;
+
 	res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
 	base = devm_ioremap_resource(&pdev->dev, res);
 	if (IS_ERR(base))
@@ -300,12 +339,26 @@ static int sunxi_sram_probe(struct platform_device *pdev)
 	if (!d)
 		return -ENOMEM;
 
+	if (variant->has_emac_clock) {
+		emac_clock = devm_regmap_init_mmio(&pdev->dev, base,
+						   &sunxi_sram_emac_clock_regmap);
+
+		if (IS_ERR(emac_clock))
+			return PTR_ERR(emac_clock);
+	}
+
 	return 0;
 }
 
 static const struct of_device_id sunxi_sram_dt_match[] = {
-	{ .compatible = "allwinner,sun4i-a10-sram-controller" },
-	{ .compatible = "allwinner,sun50i-a64-sram-controller" },
+	{
+		.compatible = "allwinner,sun4i-a10-sram-controller",
+		.data = &sun4i_a10_sramc_variant,
+	},
+	{
+		.compatible = "allwinner,sun50i-a64-sram-controller",
+		.data = &sun50i_a64_sramc_variant,
+	},
 	{ },
 };
 MODULE_DEVICE_TABLE(of, sunxi_sram_dt_match);
-- 
2.17.0

^ permalink raw reply related	[flat|nested] 80+ messages in thread
* [PATCH net-next v2 15/15] arm64: dts: allwinner: a64: add SRAM controller device tree node
  2018-05-01 16:12 ` Chen-Yu Tsai
@ 2018-05-01 16:12   ` Chen-Yu Tsai
  -1 siblings, 0 replies; 80+ messages in thread
From: Chen-Yu Tsai @ 2018-05-01 16:12 UTC (permalink / raw)
  To: Maxime Ripard, Michael Turquette, Stephen Boyd,
	Giuseppe Cavallaro, Rob Herring, Mark Rutland, Mark Brown
  Cc: Icenowy Zheng, linux-arm-kernel, linux-clk, devicetree, netdev,
	Corentin Labbe, Chen-Yu Tsai

From: Icenowy Zheng <icenowy@aosc.io>

Allwinner A64 has a SRAM controller, and in the device tree currently
we have a syscon node to enable EMAC driver to access the EMAC clock
register. As SRAM controller driver can now export regmap for this
register, replace the syscon node to the SRAM controller device node,
and let EMAC driver to acquire its EMAC clock regmap.

Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
Signed-off-by: Chen-Yu Tsai <wens@csie.org>
---
 arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi | 23 +++++++++++++++----
 1 file changed, 19 insertions(+), 4 deletions(-)

diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
index 1b2ef28c42bd..1c37659d9d41 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
+++ b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
@@ -168,10 +168,25 @@
 		#size-cells = <1>;
 		ranges;
 
-		syscon: syscon@1c00000 {
-			compatible = "allwinner,sun50i-a64-system-controller",
-				"syscon";
+		sram_controller: sram-controller@1c00000 {
+			compatible = "allwinner,sun50i-a64-sram-controller";
 			reg = <0x01c00000 0x1000>;
+			#address-cells = <1>;
+			#size-cells = <1>;
+			ranges;
+
+			sram_c: sram@18000 {
+				compatible = "mmio-sram";
+				reg = <0x00018000 0x28000>;
+				#address-cells = <1>;
+				#size-cells = <1>;
+				ranges = <0 0x00018000 0x28000>;
+
+				de2_sram: sram-section@0 {
+					compatible = "allwinner,sun50i-a64-sram-c";
+					reg = <0x0000 0x28000>;
+				};
+			};
 		};
 
 		dma: dma-controller@1c02000 {
@@ -599,7 +614,7 @@
 
 		emac: ethernet@1c30000 {
 			compatible = "allwinner,sun50i-a64-emac";
-			syscon = <&syscon>;
+			syscon = <&sram_controller>;
 			reg = <0x01c30000 0x10000>;
 			interrupts = <GIC_SPI 82 IRQ_TYPE_LEVEL_HIGH>;
 			interrupt-names = "macirq";
-- 
2.17.0

^ permalink raw reply related	[flat|nested] 80+ messages in thread
* [PATCH net-next v2 15/15] arm64: dts: allwinner: a64: add SRAM controller device tree node
@ 2018-05-01 16:12   ` Chen-Yu Tsai
  0 siblings, 0 replies; 80+ messages in thread
From: Chen-Yu Tsai @ 2018-05-01 16:12 UTC (permalink / raw)
  To: linux-arm-kernel

From: Icenowy Zheng <icenowy@aosc.io>

Allwinner A64 has a SRAM controller, and in the device tree currently
we have a syscon node to enable EMAC driver to access the EMAC clock
register. As SRAM controller driver can now export regmap for this
register, replace the syscon node to the SRAM controller device node,
and let EMAC driver to acquire its EMAC clock regmap.

Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
Signed-off-by: Chen-Yu Tsai <wens@csie.org>
---
 arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi | 23 +++++++++++++++----
 1 file changed, 19 insertions(+), 4 deletions(-)

diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
index 1b2ef28c42bd..1c37659d9d41 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
+++ b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
@@ -168,10 +168,25 @@
 		#size-cells = <1>;
 		ranges;
 
-		syscon: syscon at 1c00000 {
-			compatible = "allwinner,sun50i-a64-system-controller",
-				"syscon";
+		sram_controller: sram-controller at 1c00000 {
+			compatible = "allwinner,sun50i-a64-sram-controller";
 			reg = <0x01c00000 0x1000>;
+			#address-cells = <1>;
+			#size-cells = <1>;
+			ranges;
+
+			sram_c: sram at 18000 {
+				compatible = "mmio-sram";
+				reg = <0x00018000 0x28000>;
+				#address-cells = <1>;
+				#size-cells = <1>;
+				ranges = <0 0x00018000 0x28000>;
+
+				de2_sram: sram-section at 0 {
+					compatible = "allwinner,sun50i-a64-sram-c";
+					reg = <0x0000 0x28000>;
+				};
+			};
 		};
 
 		dma: dma-controller at 1c02000 {
@@ -599,7 +614,7 @@
 
 		emac: ethernet at 1c30000 {
 			compatible = "allwinner,sun50i-a64-emac";
-			syscon = <&syscon>;
+			syscon = <&sram_controller>;
 			reg = <0x01c30000 0x10000>;
 			interrupts = <GIC_SPI 82 IRQ_TYPE_LEVEL_HIGH>;
 			interrupt-names = "macirq";
-- 
2.17.0

^ permalink raw reply related	[flat|nested] 80+ messages in thread
* Re: [PATCH net-next v2 03/15] dt-bindings: net: dwmac-sun8i: Clean up clock delay chain descriptions
  2018-05-01 16:12   ` Chen-Yu Tsai
@ 2018-05-01 16:26     ` Rob Herring
  -1 siblings, 0 replies; 80+ messages in thread
From: Rob Herring @ 2018-05-01 16:26 UTC (permalink / raw)
  To: Chen-Yu Tsai
  Cc: Maxime Ripard, Michael Turquette, Stephen Boyd,
	Giuseppe Cavallaro, Mark Rutland, Mark Brown, linux-arm-kernel,
	linux-clk, devicetree, netdev, Corentin Labbe, Icenowy Zheng

On Wed, May 02, 2018 at 12:12:15AM +0800, Chen-Yu Tsai wrote:
> The clock delay chains found in the glue layer for dwmac-sun8i are only
> used with RGMII PHYs. They are not intended for non-RGMII PHYs, such as
> MII external PHYs or the internal PHY. Also, a recent SoC has a smaller
> range of possible values for the delay chain.
> 
> This patch reformats the delay chain section of the device tree binding
> to make it clear that the delay chains only apply to RGMII PHYs, and
> make it easier to add the R40-specific bits later.
> 
> Signed-off-by: Chen-Yu Tsai <wens@csie.org>
> ---
>  Documentation/devicetree/bindings/net/dwmac-sun8i.txt | 11 +++++++----
>  1 file changed, 7 insertions(+), 4 deletions(-)

Reviewed-by: Rob Herring <robh@kernel.org>

^ permalink raw reply	[flat|nested] 80+ messages in thread
* [PATCH net-next v2 03/15] dt-bindings: net: dwmac-sun8i: Clean up clock delay chain descriptions
@ 2018-05-01 16:26     ` Rob Herring
  0 siblings, 0 replies; 80+ messages in thread
From: Rob Herring @ 2018-05-01 16:26 UTC (permalink / raw)
  To: linux-arm-kernel

On Wed, May 02, 2018 at 12:12:15AM +0800, Chen-Yu Tsai wrote:
> The clock delay chains found in the glue layer for dwmac-sun8i are only
> used with RGMII PHYs. They are not intended for non-RGMII PHYs, such as
> MII external PHYs or the internal PHY. Also, a recent SoC has a smaller
> range of possible values for the delay chain.
> 
> This patch reformats the delay chain section of the device tree binding
> to make it clear that the delay chains only apply to RGMII PHYs, and
> make it easier to add the R40-specific bits later.
> 
> Signed-off-by: Chen-Yu Tsai <wens@csie.org>
> ---
>  Documentation/devicetree/bindings/net/dwmac-sun8i.txt | 11 +++++++----
>  1 file changed, 7 insertions(+), 4 deletions(-)

Reviewed-by: Rob Herring <robh@kernel.org>

^ permalink raw reply	[flat|nested] 80+ messages in thread
* Re: [PATCH net-next v2 05/15] dt-bindings: net: dwmac-sun8i: simplify description of syscon property
  2018-05-01 16:12   ` Chen-Yu Tsai
@ 2018-05-01 16:27     ` Rob Herring
  -1 siblings, 0 replies; 80+ messages in thread
From: Rob Herring @ 2018-05-01 16:27 UTC (permalink / raw)
  To: Chen-Yu Tsai
  Cc: Maxime Ripard, Michael Turquette, Stephen Boyd,
	Giuseppe Cavallaro, Mark Rutland, Mark Brown, linux-arm-kernel,
	linux-clk, devicetree, netdev, Corentin Labbe, Icenowy Zheng

On Wed, May 02, 2018 at 12:12:17AM +0800, Chen-Yu Tsai wrote:
> The syscon property is used to point to the device that holds the glue
> layer control register known as the "EMAC (or GMAC) clock register".
> 
> We do not need to explicitly list what compatible strings are needed, as
> this information is readily available in the user manuals. Also the
> "syscon" device type is more of an implementation detail. There are many
> ways to access a register not in a device's address range, the syscon
> interface being the most generic and unrestricted one.
> 
> Simplify the description so that it says what it is supposed to
> describe.
> 
> Signed-off-by: Chen-Yu Tsai <wens@csie.org>
> ---
>  Documentation/devicetree/bindings/net/dwmac-sun8i.txt | 7 +------
>  1 file changed, 1 insertion(+), 6 deletions(-)

Reviewed-by: Rob Herring <robh@kernel.org>

^ permalink raw reply	[flat|nested] 80+ messages in thread
* [PATCH net-next v2 05/15] dt-bindings: net: dwmac-sun8i: simplify description of syscon property
@ 2018-05-01 16:27     ` Rob Herring
  0 siblings, 0 replies; 80+ messages in thread
From: Rob Herring @ 2018-05-01 16:27 UTC (permalink / raw)
  To: linux-arm-kernel

On Wed, May 02, 2018 at 12:12:17AM +0800, Chen-Yu Tsai wrote:
> The syscon property is used to point to the device that holds the glue
> layer control register known as the "EMAC (or GMAC) clock register".
> 
> We do not need to explicitly list what compatible strings are needed, as
> this information is readily available in the user manuals. Also the
> "syscon" device type is more of an implementation detail. There are many
> ways to access a register not in a device's address range, the syscon
> interface being the most generic and unrestricted one.
> 
> Simplify the description so that it says what it is supposed to
> describe.
> 
> Signed-off-by: Chen-Yu Tsai <wens@csie.org>
> ---
>  Documentation/devicetree/bindings/net/dwmac-sun8i.txt | 7 +------
>  1 file changed, 1 insertion(+), 6 deletions(-)

Reviewed-by: Rob Herring <robh@kernel.org>

^ permalink raw reply	[flat|nested] 80+ messages in thread
* Re: [PATCH net-next v2 06/15] dt-bindings: net: dwmac-sun8i: Add binding for GMAC on Allwinner R40 SoC
  2018-05-01 16:12   ` Chen-Yu Tsai
@ 2018-05-01 16:28     ` Rob Herring
  -1 siblings, 0 replies; 80+ messages in thread
From: Rob Herring @ 2018-05-01 16:28 UTC (permalink / raw)
  To: Chen-Yu Tsai
  Cc: Maxime Ripard, Michael Turquette, Stephen Boyd,
	Giuseppe Cavallaro, Mark Rutland, Mark Brown, linux-arm-kernel,
	linux-clk, devicetree, netdev, Corentin Labbe, Icenowy Zheng

On Wed, May 02, 2018 at 12:12:18AM +0800, Chen-Yu Tsai wrote:
> The Allwinner R40 SoC has the EMAC controller supported by dwmac-sun8i.
> It is named "GMAC", while EMAC refers to the 10/100 Mbps Ethernet
> controller supported by sun4i-emac. The controller is the same, but
> the R40 has the glue layer controls in the clock control unit (CCU),
> with a reduced RX delay chain, and no TX delay chain.
> 
> This patch adds the R40 specific bits to the dwmac-sun8i binding.
> 
> Signed-off-by: Chen-Yu Tsai <wens@csie.org>
> ---
>  Documentation/devicetree/bindings/net/dwmac-sun8i.txt | 3 +++
>  1 file changed, 3 insertions(+)

Reviewed-by: Rob Herring <robh@kernel.org>

^ permalink raw reply	[flat|nested] 80+ messages in thread
* [PATCH net-next v2 06/15] dt-bindings: net: dwmac-sun8i: Add binding for GMAC on Allwinner R40 SoC
@ 2018-05-01 16:28     ` Rob Herring
  0 siblings, 0 replies; 80+ messages in thread
From: Rob Herring @ 2018-05-01 16:28 UTC (permalink / raw)
  To: linux-arm-kernel

On Wed, May 02, 2018 at 12:12:18AM +0800, Chen-Yu Tsai wrote:
> The Allwinner R40 SoC has the EMAC controller supported by dwmac-sun8i.
> It is named "GMAC", while EMAC refers to the 10/100 Mbps Ethernet
> controller supported by sun4i-emac. The controller is the same, but
> the R40 has the glue layer controls in the clock control unit (CCU),
> with a reduced RX delay chain, and no TX delay chain.
> 
> This patch adds the R40 specific bits to the dwmac-sun8i binding.
> 
> Signed-off-by: Chen-Yu Tsai <wens@csie.org>
> ---
>  Documentation/devicetree/bindings/net/dwmac-sun8i.txt | 3 +++
>  1 file changed, 3 insertions(+)

Reviewed-by: Rob Herring <robh@kernel.org>

^ permalink raw reply	[flat|nested] 80+ messages in thread
* Re: [PATCH net-next v2 00/15] ARM: sun8i: r40: Add Ethernet support
  2018-05-01 16:12 ` Chen-Yu Tsai
@ 2018-05-01 16:33   ` Chen-Yu Tsai
  -1 siblings, 0 replies; 80+ messages in thread
From: Chen-Yu Tsai @ 2018-05-01 16:33 UTC (permalink / raw)
  To: Maxime Ripard, Michael Turquette, Stephen Boyd,
	Giuseppe Cavallaro, Rob Herring, Mark Rutland, Mark Brown
  Cc: Chen-Yu Tsai, linux-arm-kernel, linux-clk, devicetree, netdev,
	Corentin Labbe, Icenowy Zheng

On Wed, May 2, 2018 at 12:12 AM, Chen-Yu Tsai <wens@csie.org> wrote:
> Hi everyone,
>
> This is v2 of my R40 Ethernet support series.
>
> Changes since v1:
>
>   - Default to fetching regmap from device pointed to by syscon phandle,
>     and falling back to syscon API if that fails.
>
>   - Dropped .syscon_from_dev field in device data as a result of the
>     previous change.
>
>   - Added a large comment block explaining the first change.
>
>   - Simplified description of syscon property in sun8i-dwmac binding.
>
>   - Regmap now only exposes the EMAC/GMAC register, but retains the
>     offset within its address space.
>
>   - Added patches for A64, which reuse the same sun8i-dwmac changes.
>
> This series adds support for the DWMAC based Ethernet controller found
> on the Allwinner R40 SoC. The controller is either a DWMAC clone or
> DWMAC core with its registers rearranged. This is already supported by
> the dwmac-sun8i driver. The glue layer control registers, unlike other
> sun8i family SoCs, is not in the system controller region, but in the
> clock control unit, like with the older A20 and A31 SoCs.
>
> While we reuse the bindings for dwmac-sun8i using a syscon phandle
> reference, we need some custom plumbing for the clock driver to export
> a regmap that only allows access to the GMAC register to the dwmac-sun8i
> driver. An alternative would be to allow drivers to register custom
> syscon devices with their own regmap and locking.
>
> Patch 1 converts the CLK_OF_DECLARE style clock driver to a platform
> one, so the regmap introduced later has a struct device to tie to.
>
> Patch 2 adds a regmap that is exported by the clock driver for the
> dwmac-sun8i driver to use.
>
> Patches 3, 4, and 5 clean up the dwmac-sun8i binding.
>
> Patch 6 adds device tree binding for Allwinner R40's Ethernet
> controller.
>
> Patch 7 converts regmap access of the syscon region in the dwmac-sun8i
> driver to regmap_field, in anticipation of different field widths on
> the R40.
>
> Patch 8 introduces custom plumbing in the dwmac-sun8i driver to fetch
> a regmap from another device, by looking up said device via a phandle,
> then getting the regmap associated with that device.
>
> Patch 9 adds support for different or absent TX/RX delay chain ranges
> to the dwmac-sun8i driver.
>
> Patch 10 adds support for the R40's ethernet controller.

I should've mentioned that patches 3 ~ 10, and only these, should go
through net-next. sunxi will handle the remaining clk, device tree, and
soc driver patches.

Thanks
ChenYu

> Patch 11 cleans up the Bananapi M2 Ultra device tree file.
>
> Patch 12 adds a GMAC device node and RGMII mode pinmux setting for the
> R40.
>
> Patch 13 enables Ethernet on the Bananapi M2 Ultra.
>
> Patches 14 and 15 are for the A64. They convert the existing syscon
> device to an SRAM controller device that exports a regmap. The needed
> driver changes are in patch 14, and the device tree changes are in
> patch 15.
>
>
> Please have a look.
>
> Regards
> ChenYu
>
> Chen-Yu Tsai (11):
>   dt-bindings: net: dwmac-sun8i: Clean up clock delay chain descriptions
>   dt-bindings: net: dwmac-sun8i: Sort syscon compatibles by alphabetical
>     order
>   dt-bindings: net: dwmac-sun8i: simplify description of syscon property
>   dt-bindings: net: dwmac-sun8i: Add binding for GMAC on Allwinner R40
>     SoC
>   net: stmmac: dwmac-sun8i: Use regmap_field for syscon register access
>   net: stmmac: dwmac-sun8i: Allow getting syscon regmap from external
>     device
>   net: stmmac: dwmac-sun8i: Support different ranges for TX/RX delay
>     chains
>   net: stmmac: dwmac-sun8i: Add support for GMAC on Allwinner R40 SoC
>   ARM: dts: sun8i: r40: bananapi-m2-ultra: Sort device node dereferences
>   ARM: dts: sun8i: r40: Add device node and RGMII pinmux node for GMAC
>   ARM: dts: sun8i: r40: bananapi-m2-ultra: Enable GMAC ethernet
>     controller
>
> Icenowy Zheng (4):
>   clk: sunxi-ng: r40: rewrite init code to a platform driver
>   clk: sunxi-ng: r40: export a regmap to access the GMAC register
>   soc: sunxi: export a regmap for EMAC clock reg on A64
>   arm64: dts: allwinner: a64: add SRAM controller device tree node
>
>  .../devicetree/bindings/net/dwmac-sun8i.txt   |  21 +--
>  .../boot/dts/sun8i-r40-bananapi-m2-ultra.dts  |  99 ++++++++-----
>  arch/arm/boot/dts/sun8i-r40.dtsi              |  34 +++++
>  arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi |  23 ++-
>  drivers/clk/sunxi-ng/ccu-sun8i-r40.c          |  72 +++++++--
>  .../net/ethernet/stmicro/stmmac/dwmac-sun8i.c | 139 +++++++++++++++---
>  drivers/soc/sunxi/sunxi_sram.c                |  57 ++++++-
>  7 files changed, 364 insertions(+), 81 deletions(-)
>
> --
> 2.17.0
>

^ permalink raw reply	[flat|nested] 80+ messages in thread
* [PATCH net-next v2 00/15] ARM: sun8i: r40: Add Ethernet support
@ 2018-05-01 16:33   ` Chen-Yu Tsai
  0 siblings, 0 replies; 80+ messages in thread
From: Chen-Yu Tsai @ 2018-05-01 16:33 UTC (permalink / raw)
  To: linux-arm-kernel

On Wed, May 2, 2018 at 12:12 AM, Chen-Yu Tsai <wens@csie.org> wrote:
> Hi everyone,
>
> This is v2 of my R40 Ethernet support series.
>
> Changes since v1:
>
>   - Default to fetching regmap from device pointed to by syscon phandle,
>     and falling back to syscon API if that fails.
>
>   - Dropped .syscon_from_dev field in device data as a result of the
>     previous change.
>
>   - Added a large comment block explaining the first change.
>
>   - Simplified description of syscon property in sun8i-dwmac binding.
>
>   - Regmap now only exposes the EMAC/GMAC register, but retains the
>     offset within its address space.
>
>   - Added patches for A64, which reuse the same sun8i-dwmac changes.
>
> This series adds support for the DWMAC based Ethernet controller found
> on the Allwinner R40 SoC. The controller is either a DWMAC clone or
> DWMAC core with its registers rearranged. This is already supported by
> the dwmac-sun8i driver. The glue layer control registers, unlike other
> sun8i family SoCs, is not in the system controller region, but in the
> clock control unit, like with the older A20 and A31 SoCs.
>
> While we reuse the bindings for dwmac-sun8i using a syscon phandle
> reference, we need some custom plumbing for the clock driver to export
> a regmap that only allows access to the GMAC register to the dwmac-sun8i
> driver. An alternative would be to allow drivers to register custom
> syscon devices with their own regmap and locking.
>
> Patch 1 converts the CLK_OF_DECLARE style clock driver to a platform
> one, so the regmap introduced later has a struct device to tie to.
>
> Patch 2 adds a regmap that is exported by the clock driver for the
> dwmac-sun8i driver to use.
>
> Patches 3, 4, and 5 clean up the dwmac-sun8i binding.
>
> Patch 6 adds device tree binding for Allwinner R40's Ethernet
> controller.
>
> Patch 7 converts regmap access of the syscon region in the dwmac-sun8i
> driver to regmap_field, in anticipation of different field widths on
> the R40.
>
> Patch 8 introduces custom plumbing in the dwmac-sun8i driver to fetch
> a regmap from another device, by looking up said device via a phandle,
> then getting the regmap associated with that device.
>
> Patch 9 adds support for different or absent TX/RX delay chain ranges
> to the dwmac-sun8i driver.
>
> Patch 10 adds support for the R40's ethernet controller.

I should've mentioned that patches 3 ~ 10, and only these, should go
through net-next. sunxi will handle the remaining clk, device tree, and
soc driver patches.

Thanks
ChenYu

> Patch 11 cleans up the Bananapi M2 Ultra device tree file.
>
> Patch 12 adds a GMAC device node and RGMII mode pinmux setting for the
> R40.
>
> Patch 13 enables Ethernet on the Bananapi M2 Ultra.
>
> Patches 14 and 15 are for the A64. They convert the existing syscon
> device to an SRAM controller device that exports a regmap. The needed
> driver changes are in patch 14, and the device tree changes are in
> patch 15.
>
>
> Please have a look.
>
> Regards
> ChenYu
>
> Chen-Yu Tsai (11):
>   dt-bindings: net: dwmac-sun8i: Clean up clock delay chain descriptions
>   dt-bindings: net: dwmac-sun8i: Sort syscon compatibles by alphabetical
>     order
>   dt-bindings: net: dwmac-sun8i: simplify description of syscon property
>   dt-bindings: net: dwmac-sun8i: Add binding for GMAC on Allwinner R40
>     SoC
>   net: stmmac: dwmac-sun8i: Use regmap_field for syscon register access
>   net: stmmac: dwmac-sun8i: Allow getting syscon regmap from external
>     device
>   net: stmmac: dwmac-sun8i: Support different ranges for TX/RX delay
>     chains
>   net: stmmac: dwmac-sun8i: Add support for GMAC on Allwinner R40 SoC
>   ARM: dts: sun8i: r40: bananapi-m2-ultra: Sort device node dereferences
>   ARM: dts: sun8i: r40: Add device node and RGMII pinmux node for GMAC
>   ARM: dts: sun8i: r40: bananapi-m2-ultra: Enable GMAC ethernet
>     controller
>
> Icenowy Zheng (4):
>   clk: sunxi-ng: r40: rewrite init code to a platform driver
>   clk: sunxi-ng: r40: export a regmap to access the GMAC register
>   soc: sunxi: export a regmap for EMAC clock reg on A64
>   arm64: dts: allwinner: a64: add SRAM controller device tree node
>
>  .../devicetree/bindings/net/dwmac-sun8i.txt   |  21 +--
>  .../boot/dts/sun8i-r40-bananapi-m2-ultra.dts  |  99 ++++++++-----
>  arch/arm/boot/dts/sun8i-r40.dtsi              |  34 +++++
>  arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi |  23 ++-
>  drivers/clk/sunxi-ng/ccu-sun8i-r40.c          |  72 +++++++--
>  .../net/ethernet/stmicro/stmmac/dwmac-sun8i.c | 139 +++++++++++++++---
>  drivers/soc/sunxi/sunxi_sram.c                |  57 ++++++-
>  7 files changed, 364 insertions(+), 81 deletions(-)
>
> --
> 2.17.0
>

^ permalink raw reply	[flat|nested] 80+ messages in thread
* Re: [PATCH net-next v2 15/15] arm64: dts: allwinner: a64: add SRAM controller device tree node
  2018-05-01 16:12   ` Chen-Yu Tsai
@ 2018-05-02  9:51     ` Maxime Ripard
  -1 siblings, 0 replies; 80+ messages in thread
From: Maxime Ripard @ 2018-05-02  9:51 UTC (permalink / raw)
  To: Chen-Yu Tsai
  Cc: Michael Turquette, Stephen Boyd, Giuseppe Cavallaro, Rob Herring,
	Mark Rutland, Mark Brown, Icenowy Zheng, linux-arm-kernel,
	linux-clk, devicetree, netdev, Corentin Labbe

[-- Attachment #1: Type: text/plain, Size: 1653 bytes --]

Hi,

On Wed, May 02, 2018 at 12:12:27AM +0800, Chen-Yu Tsai wrote:
> From: Icenowy Zheng <icenowy@aosc.io>
> 
> Allwinner A64 has a SRAM controller, and in the device tree currently
> we have a syscon node to enable EMAC driver to access the EMAC clock
> register. As SRAM controller driver can now export regmap for this
> register, replace the syscon node to the SRAM controller device node,
> and let EMAC driver to acquire its EMAC clock regmap.
> 
> Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
> Signed-off-by: Chen-Yu Tsai <wens@csie.org>
> ---
>  arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi | 23 +++++++++++++++----
>  1 file changed, 19 insertions(+), 4 deletions(-)
> 
> diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
> index 1b2ef28c42bd..1c37659d9d41 100644
> --- a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
> +++ b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
> @@ -168,10 +168,25 @@
>  		#size-cells = <1>;
>  		ranges;
>  
> -		syscon: syscon@1c00000 {
> -			compatible = "allwinner,sun50i-a64-system-controller",
> -				"syscon";
> +		sram_controller: sram-controller@1c00000 {
> +			compatible = "allwinner,sun50i-a64-sram-controller";

I don't think there's anything preventing us from keeping the
-system-controller compatible. It's what was in the DT before, and
it's how it's called in the datasheet.

Otherwise, the whole serie looks good to me:
Acked-by: Maxime Ripard <maxime.ripard@bootlin.com>

Maxime

-- 
Maxime Ripard, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

^ permalink raw reply	[flat|nested] 80+ messages in thread
* [PATCH net-next v2 15/15] arm64: dts: allwinner: a64: add SRAM controller device tree node
@ 2018-05-02  9:51     ` Maxime Ripard
  0 siblings, 0 replies; 80+ messages in thread
From: Maxime Ripard @ 2018-05-02  9:51 UTC (permalink / raw)
  To: linux-arm-kernel

Hi,

On Wed, May 02, 2018 at 12:12:27AM +0800, Chen-Yu Tsai wrote:
> From: Icenowy Zheng <icenowy@aosc.io>
> 
> Allwinner A64 has a SRAM controller, and in the device tree currently
> we have a syscon node to enable EMAC driver to access the EMAC clock
> register. As SRAM controller driver can now export regmap for this
> register, replace the syscon node to the SRAM controller device node,
> and let EMAC driver to acquire its EMAC clock regmap.
> 
> Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
> Signed-off-by: Chen-Yu Tsai <wens@csie.org>
> ---
>  arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi | 23 +++++++++++++++----
>  1 file changed, 19 insertions(+), 4 deletions(-)
> 
> diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
> index 1b2ef28c42bd..1c37659d9d41 100644
> --- a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
> +++ b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
> @@ -168,10 +168,25 @@
>  		#size-cells = <1>;
>  		ranges;
>  
> -		syscon: syscon at 1c00000 {
> -			compatible = "allwinner,sun50i-a64-system-controller",
> -				"syscon";
> +		sram_controller: sram-controller at 1c00000 {
> +			compatible = "allwinner,sun50i-a64-sram-controller";

I don't think there's anything preventing us from keeping the
-system-controller compatible. It's what was in the DT before, and
it's how it's called in the datasheet.

Otherwise, the whole serie looks good to me:
Acked-by: Maxime Ripard <maxime.ripard@bootlin.com>

Maxime

-- 
Maxime Ripard, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20180502/108aad0b/attachment.sig>

^ permalink raw reply	[flat|nested] 80+ messages in thread
* Re: [PATCH net-next v2 15/15] arm64: dts: allwinner: a64: add SRAM controller device tree node
  2018-05-02  9:51     ` Maxime Ripard
@ 2018-05-02  9:53       ` Chen-Yu Tsai
  -1 siblings, 0 replies; 80+ messages in thread
From: Chen-Yu Tsai @ 2018-05-02  9:53 UTC (permalink / raw)
  To: Maxime Ripard
  Cc: Michael Turquette, Stephen Boyd, Giuseppe Cavallaro, Rob Herring,
	Mark Rutland, Mark Brown, Icenowy Zheng, linux-arm-kernel,
	linux-clk, devicetree, netdev, Corentin Labbe

On Wed, May 2, 2018 at 5:51 PM, Maxime Ripard <maxime.ripard@bootlin.com> wrote:
> Hi,
>
> On Wed, May 02, 2018 at 12:12:27AM +0800, Chen-Yu Tsai wrote:
>> From: Icenowy Zheng <icenowy@aosc.io>
>>
>> Allwinner A64 has a SRAM controller, and in the device tree currently
>> we have a syscon node to enable EMAC driver to access the EMAC clock
>> register. As SRAM controller driver can now export regmap for this
>> register, replace the syscon node to the SRAM controller device node,
>> and let EMAC driver to acquire its EMAC clock regmap.
>>
>> Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
>> Signed-off-by: Chen-Yu Tsai <wens@csie.org>
>> ---
>>  arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi | 23 +++++++++++++++----
>>  1 file changed, 19 insertions(+), 4 deletions(-)
>>
>> diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
>> index 1b2ef28c42bd..1c37659d9d41 100644
>> --- a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
>> +++ b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
>> @@ -168,10 +168,25 @@
>>               #size-cells = <1>;
>>               ranges;
>>
>> -             syscon: syscon@1c00000 {
>> -                     compatible = "allwinner,sun50i-a64-system-controller",
>> -                             "syscon";
>> +             sram_controller: sram-controller@1c00000 {
>> +                     compatible = "allwinner,sun50i-a64-sram-controller";
>
> I don't think there's anything preventing us from keeping the
> -system-controller compatible. It's what was in the DT before, and
> it's how it's called in the datasheet.

I actually meant to ask you about this. The -system-controller compatible
matches the datasheet better. Maybe we should just switch to that one?

ChenYu

> Otherwise, the whole serie looks good to me:
> Acked-by: Maxime Ripard <maxime.ripard@bootlin.com>
>
> Maxime
>
> --
> Maxime Ripard, Bootlin (formerly Free Electrons)
> Embedded Linux and Kernel engineering
> https://bootlin.com

^ permalink raw reply	[flat|nested] 80+ messages in thread
* [PATCH net-next v2 15/15] arm64: dts: allwinner: a64: add SRAM controller device tree node
@ 2018-05-02  9:53       ` Chen-Yu Tsai
  0 siblings, 0 replies; 80+ messages in thread
From: Chen-Yu Tsai @ 2018-05-02  9:53 UTC (permalink / raw)
  To: linux-arm-kernel

On Wed, May 2, 2018 at 5:51 PM, Maxime Ripard <maxime.ripard@bootlin.com> wrote:
> Hi,
>
> On Wed, May 02, 2018 at 12:12:27AM +0800, Chen-Yu Tsai wrote:
>> From: Icenowy Zheng <icenowy@aosc.io>
>>
>> Allwinner A64 has a SRAM controller, and in the device tree currently
>> we have a syscon node to enable EMAC driver to access the EMAC clock
>> register. As SRAM controller driver can now export regmap for this
>> register, replace the syscon node to the SRAM controller device node,
>> and let EMAC driver to acquire its EMAC clock regmap.
>>
>> Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
>> Signed-off-by: Chen-Yu Tsai <wens@csie.org>
>> ---
>>  arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi | 23 +++++++++++++++----
>>  1 file changed, 19 insertions(+), 4 deletions(-)
>>
>> diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
>> index 1b2ef28c42bd..1c37659d9d41 100644
>> --- a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
>> +++ b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
>> @@ -168,10 +168,25 @@
>>               #size-cells = <1>;
>>               ranges;
>>
>> -             syscon: syscon at 1c00000 {
>> -                     compatible = "allwinner,sun50i-a64-system-controller",
>> -                             "syscon";
>> +             sram_controller: sram-controller at 1c00000 {
>> +                     compatible = "allwinner,sun50i-a64-sram-controller";
>
> I don't think there's anything preventing us from keeping the
> -system-controller compatible. It's what was in the DT before, and
> it's how it's called in the datasheet.

I actually meant to ask you about this. The -system-controller compatible
matches the datasheet better. Maybe we should just switch to that one?

ChenYu

> Otherwise, the whole serie looks good to me:
> Acked-by: Maxime Ripard <maxime.ripard@bootlin.com>
>
> Maxime
>
> --
> Maxime Ripard, Bootlin (formerly Free Electrons)
> Embedded Linux and Kernel engineering
> https://bootlin.com

^ permalink raw reply	[flat|nested] 80+ messages in thread
* Re: [PATCH net-next v2 15/15] arm64: dts: allwinner: a64: add SRAM controller device tree node
  2018-05-02  9:53       ` Chen-Yu Tsai
  (?)
@ 2018-05-02 10:19         ` Icenowy Zheng
  -1 siblings, 0 replies; 80+ messages in thread
From: Icenowy Zheng @ 2018-05-02 10:19 UTC (permalink / raw)
  To: linux-arm-kernel, Chen-Yu Tsai, Maxime Ripard
  Cc: Mark Rutland, devicetree, Stephen Boyd, netdev,
	Michael Turquette, Rob Herring, Corentin Labbe, Mark Brown,
	Giuseppe Cavallaro, linux-clk, linux-arm-kernel



于 2018年5月2日 GMT+08:00 下午5:53:21, Chen-Yu Tsai <wens@csie.org> 写到:
>On Wed, May 2, 2018 at 5:51 PM, Maxime Ripard
><maxime.ripard@bootlin.com> wrote:
>> Hi,
>>
>> On Wed, May 02, 2018 at 12:12:27AM +0800, Chen-Yu Tsai wrote:
>>> From: Icenowy Zheng <icenowy@aosc.io>
>>>
>>> Allwinner A64 has a SRAM controller, and in the device tree
>currently
>>> we have a syscon node to enable EMAC driver to access the EMAC clock
>>> register. As SRAM controller driver can now export regmap for this
>>> register, replace the syscon node to the SRAM controller device
>node,
>>> and let EMAC driver to acquire its EMAC clock regmap.
>>>
>>> Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
>>> Signed-off-by: Chen-Yu Tsai <wens@csie.org>
>>> ---
>>>  arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi | 23
>+++++++++++++++----
>>>  1 file changed, 19 insertions(+), 4 deletions(-)
>>>
>>> diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
>b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
>>> index 1b2ef28c42bd..1c37659d9d41 100644
>>> --- a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
>>> +++ b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
>>> @@ -168,10 +168,25 @@
>>>               #size-cells = <1>;
>>>               ranges;
>>>
>>> -             syscon: syscon@1c00000 {
>>> -                     compatible =
>"allwinner,sun50i-a64-system-controller",
>>> -                             "syscon";
>>> +             sram_controller: sram-controller@1c00000 {
>>> +                     compatible =
>"allwinner,sun50i-a64-sram-controller";
>>
>> I don't think there's anything preventing us from keeping the
>> -system-controller compatible. It's what was in the DT before, and
>> it's how it's called in the datasheet.
>
>I actually meant to ask you about this. The -system-controller
>compatible
>matches the datasheet better. Maybe we should just switch to that one?

No, if we do the switch the system-controller compatible,
the device will be probed on the same memory region with
a syscon on old DTs.

>
>ChenYu
>
>> Otherwise, the whole serie looks good to me:
>> Acked-by: Maxime Ripard <maxime.ripard@bootlin.com>
>>
>> Maxime
>>
>> --
>> Maxime Ripard, Bootlin (formerly Free Electrons)
>> Embedded Linux and Kernel engineering
>> https://bootlin.com
>
>_______________________________________________
>linux-arm-kernel mailing list
>linux-arm-kernel@lists.infradead.org
>http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply	[flat|nested] 80+ messages in thread
* Re: [PATCH net-next v2 15/15] arm64: dts: allwinner: a64: add SRAM controller device tree node
@ 2018-05-02 10:19         ` Icenowy Zheng
  0 siblings, 0 replies; 80+ messages in thread
From: Icenowy Zheng @ 2018-05-02 10:19 UTC (permalink / raw)
  To: Chen-Yu Tsai, Maxime Ripard
  Cc: Mark Rutland, devicetree, Stephen Boyd, netdev,
	Michael Turquette, Rob Herring, Corentin Labbe, Mark Brown,
	Giuseppe Cavallaro, linux-clk, linux-arm-kernel



于 2018年5月2日 GMT+08:00 下午5:53:21, Chen-Yu Tsai <wens@csie.org> 写到:
>On Wed, May 2, 2018 at 5:51 PM, Maxime Ripard
><maxime.ripard@bootlin.com> wrote:
>> Hi,
>>
>> On Wed, May 02, 2018 at 12:12:27AM +0800, Chen-Yu Tsai wrote:
>>> From: Icenowy Zheng <icenowy@aosc.io>
>>>
>>> Allwinner A64 has a SRAM controller, and in the device tree
>currently
>>> we have a syscon node to enable EMAC driver to access the EMAC clock
>>> register. As SRAM controller driver can now export regmap for this
>>> register, replace the syscon node to the SRAM controller device
>node,
>>> and let EMAC driver to acquire its EMAC clock regmap.
>>>
>>> Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
>>> Signed-off-by: Chen-Yu Tsai <wens@csie.org>
>>> ---
>>>  arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi | 23
>+++++++++++++++----
>>>  1 file changed, 19 insertions(+), 4 deletions(-)
>>>
>>> diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
>b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
>>> index 1b2ef28c42bd..1c37659d9d41 100644
>>> --- a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
>>> +++ b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
>>> @@ -168,10 +168,25 @@
>>>               #size-cells = <1>;
>>>               ranges;
>>>
>>> -             syscon: syscon@1c00000 {
>>> -                     compatible =
>"allwinner,sun50i-a64-system-controller",
>>> -                             "syscon";
>>> +             sram_controller: sram-controller@1c00000 {
>>> +                     compatible =
>"allwinner,sun50i-a64-sram-controller";
>>
>> I don't think there's anything preventing us from keeping the
>> -system-controller compatible. It's what was in the DT before, and
>> it's how it's called in the datasheet.
>
>I actually meant to ask you about this. The -system-controller
>compatible
>matches the datasheet better. Maybe we should just switch to that one?

No, if we do the switch the system-controller compatible,
the device will be probed on the same memory region with
a syscon on old DTs.

>
>ChenYu
>
>> Otherwise, the whole serie looks good to me:
>> Acked-by: Maxime Ripard <maxime.ripard@bootlin.com>
>>
>> Maxime
>>
>> --
>> Maxime Ripard, Bootlin (formerly Free Electrons)
>> Embedded Linux and Kernel engineering
>> https://bootlin.com
>
>_______________________________________________
>linux-arm-kernel mailing list
>linux-arm-kernel@lists.infradead.org
>http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply	[flat|nested] 80+ messages in thread
* [PATCH net-next v2 15/15] arm64: dts: allwinner: a64: add SRAM controller device tree node
@ 2018-05-02 10:19         ` Icenowy Zheng
  0 siblings, 0 replies; 80+ messages in thread
From: Icenowy Zheng @ 2018-05-02 10:19 UTC (permalink / raw)
  To: linux-arm-kernel



? 2018?5?2? GMT+08:00 ??5:53:21, Chen-Yu Tsai <wens@csie.org> ??:
>On Wed, May 2, 2018 at 5:51 PM, Maxime Ripard
><maxime.ripard@bootlin.com> wrote:
>> Hi,
>>
>> On Wed, May 02, 2018 at 12:12:27AM +0800, Chen-Yu Tsai wrote:
>>> From: Icenowy Zheng <icenowy@aosc.io>
>>>
>>> Allwinner A64 has a SRAM controller, and in the device tree
>currently
>>> we have a syscon node to enable EMAC driver to access the EMAC clock
>>> register. As SRAM controller driver can now export regmap for this
>>> register, replace the syscon node to the SRAM controller device
>node,
>>> and let EMAC driver to acquire its EMAC clock regmap.
>>>
>>> Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
>>> Signed-off-by: Chen-Yu Tsai <wens@csie.org>
>>> ---
>>>  arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi | 23
>+++++++++++++++----
>>>  1 file changed, 19 insertions(+), 4 deletions(-)
>>>
>>> diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
>b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
>>> index 1b2ef28c42bd..1c37659d9d41 100644
>>> --- a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
>>> +++ b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
>>> @@ -168,10 +168,25 @@
>>>               #size-cells = <1>;
>>>               ranges;
>>>
>>> -             syscon: syscon at 1c00000 {
>>> -                     compatible =
>"allwinner,sun50i-a64-system-controller",
>>> -                             "syscon";
>>> +             sram_controller: sram-controller at 1c00000 {
>>> +                     compatible =
>"allwinner,sun50i-a64-sram-controller";
>>
>> I don't think there's anything preventing us from keeping the
>> -system-controller compatible. It's what was in the DT before, and
>> it's how it's called in the datasheet.
>
>I actually meant to ask you about this. The -system-controller
>compatible
>matches the datasheet better. Maybe we should just switch to that one?

No, if we do the switch the system-controller compatible,
the device will be probed on the same memory region with
a syscon on old DTs.

>
>ChenYu
>
>> Otherwise, the whole serie looks good to me:
>> Acked-by: Maxime Ripard <maxime.ripard@bootlin.com>
>>
>> Maxime
>>
>> --
>> Maxime Ripard, Bootlin (formerly Free Electrons)
>> Embedded Linux and Kernel engineering
>> https://bootlin.com
>
>_______________________________________________
>linux-arm-kernel mailing list
>linux-arm-kernel at lists.infradead.org
>http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply	[flat|nested] 80+ messages in thread
* Re: [PATCH net-next v2 15/15] arm64: dts: allwinner: a64: add SRAM controller device tree node
  2018-05-02 10:19         ` Icenowy Zheng
@ 2018-05-02 11:54           ` Maxime Ripard
  -1 siblings, 0 replies; 80+ messages in thread
From: Maxime Ripard @ 2018-05-02 11:54 UTC (permalink / raw)
  To: Icenowy Zheng
  Cc: linux-arm-kernel, Chen-Yu Tsai, Mark Rutland, devicetree,
	Stephen Boyd, netdev, Michael Turquette, Rob Herring,
	Corentin Labbe, Mark Brown, Giuseppe Cavallaro, linux-clk

[-- Attachment #1: Type: text/plain, Size: 2579 bytes --]

On Wed, May 02, 2018 at 06:19:51PM +0800, Icenowy Zheng wrote:
> 
> 
> 于 2018年5月2日 GMT+08:00 下午5:53:21, Chen-Yu Tsai <wens@csie.org> 写到:
> >On Wed, May 2, 2018 at 5:51 PM, Maxime Ripard
> ><maxime.ripard@bootlin.com> wrote:
> >> Hi,
> >>
> >> On Wed, May 02, 2018 at 12:12:27AM +0800, Chen-Yu Tsai wrote:
> >>> From: Icenowy Zheng <icenowy@aosc.io>
> >>>
> >>> Allwinner A64 has a SRAM controller, and in the device tree
> >currently
> >>> we have a syscon node to enable EMAC driver to access the EMAC clock
> >>> register. As SRAM controller driver can now export regmap for this
> >>> register, replace the syscon node to the SRAM controller device
> >node,
> >>> and let EMAC driver to acquire its EMAC clock regmap.
> >>>
> >>> Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
> >>> Signed-off-by: Chen-Yu Tsai <wens@csie.org>
> >>> ---
> >>>  arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi | 23
> >+++++++++++++++----
> >>>  1 file changed, 19 insertions(+), 4 deletions(-)
> >>>
> >>> diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
> >b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
> >>> index 1b2ef28c42bd..1c37659d9d41 100644
> >>> --- a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
> >>> +++ b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
> >>> @@ -168,10 +168,25 @@
> >>>               #size-cells = <1>;
> >>>               ranges;
> >>>
> >>> -             syscon: syscon@1c00000 {
> >>> -                     compatible =
> >"allwinner,sun50i-a64-system-controller",
> >>> -                             "syscon";
> >>> +             sram_controller: sram-controller@1c00000 {
> >>> +                     compatible =
> >"allwinner,sun50i-a64-sram-controller";
> >>
> >> I don't think there's anything preventing us from keeping the
> >> -system-controller compatible. It's what was in the DT before, and
> >> it's how it's called in the datasheet.
> >
> >I actually meant to ask you about this. The -system-controller
> >compatible matches the datasheet better. Maybe we should just
> >switch to that one?
> 
> No, if we do the switch the system-controller compatible,
> the device will be probed on the same memory region with
> a syscon on old DTs.

The device hasn't magically changed either. Maybe we just need to add
a check to make sure we don't have the syscon compatible in the SRAM
driver probe so that the double driver issue doesn't happen?

Maxime

-- 
Maxime Ripard, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

^ permalink raw reply	[flat|nested] 80+ messages in thread
* [PATCH net-next v2 15/15] arm64: dts: allwinner: a64: add SRAM controller device tree node
@ 2018-05-02 11:54           ` Maxime Ripard
  0 siblings, 0 replies; 80+ messages in thread
From: Maxime Ripard @ 2018-05-02 11:54 UTC (permalink / raw)
  To: linux-arm-kernel

On Wed, May 02, 2018 at 06:19:51PM +0800, Icenowy Zheng wrote:
> 
> 
> ? 2018?5?2? GMT+08:00 ??5:53:21, Chen-Yu Tsai <wens@csie.org> ??:
> >On Wed, May 2, 2018 at 5:51 PM, Maxime Ripard
> ><maxime.ripard@bootlin.com> wrote:
> >> Hi,
> >>
> >> On Wed, May 02, 2018 at 12:12:27AM +0800, Chen-Yu Tsai wrote:
> >>> From: Icenowy Zheng <icenowy@aosc.io>
> >>>
> >>> Allwinner A64 has a SRAM controller, and in the device tree
> >currently
> >>> we have a syscon node to enable EMAC driver to access the EMAC clock
> >>> register. As SRAM controller driver can now export regmap for this
> >>> register, replace the syscon node to the SRAM controller device
> >node,
> >>> and let EMAC driver to acquire its EMAC clock regmap.
> >>>
> >>> Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
> >>> Signed-off-by: Chen-Yu Tsai <wens@csie.org>
> >>> ---
> >>>  arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi | 23
> >+++++++++++++++----
> >>>  1 file changed, 19 insertions(+), 4 deletions(-)
> >>>
> >>> diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
> >b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
> >>> index 1b2ef28c42bd..1c37659d9d41 100644
> >>> --- a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
> >>> +++ b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
> >>> @@ -168,10 +168,25 @@
> >>>               #size-cells = <1>;
> >>>               ranges;
> >>>
> >>> -             syscon: syscon at 1c00000 {
> >>> -                     compatible =
> >"allwinner,sun50i-a64-system-controller",
> >>> -                             "syscon";
> >>> +             sram_controller: sram-controller at 1c00000 {
> >>> +                     compatible =
> >"allwinner,sun50i-a64-sram-controller";
> >>
> >> I don't think there's anything preventing us from keeping the
> >> -system-controller compatible. It's what was in the DT before, and
> >> it's how it's called in the datasheet.
> >
> >I actually meant to ask you about this. The -system-controller
> >compatible matches the datasheet better. Maybe we should just
> >switch to that one?
> 
> No, if we do the switch the system-controller compatible,
> the device will be probed on the same memory region with
> a syscon on old DTs.

The device hasn't magically changed either. Maybe we just need to add
a check to make sure we don't have the syscon compatible in the SRAM
driver probe so that the double driver issue doesn't happen?

Maxime

-- 
Maxime Ripard, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20180502/229e3e2b/attachment.sig>

^ permalink raw reply	[flat|nested] 80+ messages in thread
* Re: [PATCH net-next v2 00/15] ARM: sun8i: r40: Add Ethernet support
  2018-05-01 16:12 ` Chen-Yu Tsai
@ 2018-05-02 15:04   ` David Miller
  -1 siblings, 0 replies; 80+ messages in thread
From: David Miller @ 2018-05-02 15:04 UTC (permalink / raw)
  To: wens
  Cc: maxime.ripard, mturquette, sboyd, peppe.cavallaro, robh+dt,
	mark.rutland, broonie, linux-arm-kernel, linux-clk, devicetree,
	netdev, clabbe.montjoie, icenowy

From: Chen-Yu Tsai <wens@csie.org>
Date: Wed,  2 May 2018 00:12:12 +0800

> This is v2 of my R40 Ethernet support series.

There are a lot of non-networking changes in here, in particular DTS
changes and modifications to clock drivers.

Are all parties involved OK with the entire series going into net-next?

Thanks.

^ permalink raw reply	[flat|nested] 80+ messages in thread
* [PATCH net-next v2 00/15] ARM: sun8i: r40: Add Ethernet support
@ 2018-05-02 15:04   ` David Miller
  0 siblings, 0 replies; 80+ messages in thread
From: David Miller @ 2018-05-02 15:04 UTC (permalink / raw)
  To: linux-arm-kernel

From: Chen-Yu Tsai <wens@csie.org>
Date: Wed,  2 May 2018 00:12:12 +0800

> This is v2 of my R40 Ethernet support series.

There are a lot of non-networking changes in here, in particular DTS
changes and modifications to clock drivers.

Are all parties involved OK with the entire series going into net-next?

Thanks.

^ permalink raw reply	[flat|nested] 80+ messages in thread
* Re: [PATCH net-next v2 00/15] ARM: sun8i: r40: Add Ethernet support
  2018-05-01 16:33   ` Chen-Yu Tsai
@ 2018-05-02 15:06     ` David Miller
  -1 siblings, 0 replies; 80+ messages in thread
From: David Miller @ 2018-05-02 15:06 UTC (permalink / raw)
  To: wens
  Cc: maxime.ripard, mturquette, sboyd, peppe.cavallaro, robh+dt,
	mark.rutland, broonie, linux-arm-kernel, linux-clk, devicetree,
	netdev, clabbe.montjoie, icenowy

From: Chen-Yu Tsai <wens@csie.org>
Date: Wed, 2 May 2018 00:33:45 +0800

> I should've mentioned that patches 3 ~ 10, and only these, should go
> through net-next. sunxi will handle the remaining clk, device tree, and
> soc driver patches.

Ok, I just noticed this.

Why don't you just post those patches separately as a series on their
own then, in order to avoid confusion?

Then you can adjust the patch series header posting to explain the
non-net-next changes, where they got merged, and what they provide
in order to faciliate the net-next changes.

Thanks.

^ permalink raw reply	[flat|nested] 80+ messages in thread
* [PATCH net-next v2 00/15] ARM: sun8i: r40: Add Ethernet support
@ 2018-05-02 15:06     ` David Miller
  0 siblings, 0 replies; 80+ messages in thread
From: David Miller @ 2018-05-02 15:06 UTC (permalink / raw)
  To: linux-arm-kernel

From: Chen-Yu Tsai <wens@csie.org>
Date: Wed, 2 May 2018 00:33:45 +0800

> I should've mentioned that patches 3 ~ 10, and only these, should go
> through net-next. sunxi will handle the remaining clk, device tree, and
> soc driver patches.

Ok, I just noticed this.

Why don't you just post those patches separately as a series on their
own then, in order to avoid confusion?

Then you can adjust the patch series header posting to explain the
non-net-next changes, where they got merged, and what they provide
in order to faciliate the net-next changes.

Thanks.

^ permalink raw reply	[flat|nested] 80+ messages in thread
* Re: [PATCH net-next v2 00/15] ARM: sun8i: r40: Add Ethernet support
  2018-05-02 15:06     ` David Miller
@ 2018-05-03 13:12       ` Maxime Ripard
  -1 siblings, 0 replies; 80+ messages in thread
From: Maxime Ripard @ 2018-05-03 13:12 UTC (permalink / raw)
  To: David Miller
  Cc: wens, mturquette, sboyd, peppe.cavallaro, robh+dt, mark.rutland,
	broonie, linux-arm-kernel, linux-clk, devicetree, netdev,
	clabbe.montjoie, icenowy

[-- Attachment #1: Type: text/plain, Size: 1261 bytes --]

Hi Dave,

On Wed, May 02, 2018 at 11:06:17AM -0400, David Miller wrote:
> From: Chen-Yu Tsai <wens@csie.org>
> Date: Wed, 2 May 2018 00:33:45 +0800
> 
> > I should've mentioned that patches 3 ~ 10, and only these, should go
> > through net-next. sunxi will handle the remaining clk, device tree, and
> > soc driver patches.
> 
> Ok, I just noticed this.
> 
> Why don't you just post those patches separately as a series on their
> own then, in order to avoid confusion?
> 
> Then you can adjust the patch series header posting to explain the
> non-net-next changes, where they got merged, and what they provide
> in order to faciliate the net-next changes.

I now that we usually have some feedback from non-net maintainers that
they actually prefer seeing the full picture (and I also tend to
prefer that as well) and having all the patches relevant to enable a
particular feature, even if it means getting multiple maintainers
involved.

Just to make sure we understood you fully, do you want Chen-Yu to
resend his serie following your comments, or was that just a general
remark for next time?

Thanks!
Maxime

-- 
Maxime Ripard, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

^ permalink raw reply	[flat|nested] 80+ messages in thread
* [PATCH net-next v2 00/15] ARM: sun8i: r40: Add Ethernet support
@ 2018-05-03 13:12       ` Maxime Ripard
  0 siblings, 0 replies; 80+ messages in thread
From: Maxime Ripard @ 2018-05-03 13:12 UTC (permalink / raw)
  To: linux-arm-kernel

Hi Dave,

On Wed, May 02, 2018 at 11:06:17AM -0400, David Miller wrote:
> From: Chen-Yu Tsai <wens@csie.org>
> Date: Wed, 2 May 2018 00:33:45 +0800
> 
> > I should've mentioned that patches 3 ~ 10, and only these, should go
> > through net-next. sunxi will handle the remaining clk, device tree, and
> > soc driver patches.
> 
> Ok, I just noticed this.
> 
> Why don't you just post those patches separately as a series on their
> own then, in order to avoid confusion?
> 
> Then you can adjust the patch series header posting to explain the
> non-net-next changes, where they got merged, and what they provide
> in order to faciliate the net-next changes.

I now that we usually have some feedback from non-net maintainers that
they actually prefer seeing the full picture (and I also tend to
prefer that as well) and having all the patches relevant to enable a
particular feature, even if it means getting multiple maintainers
involved.

Just to make sure we understood you fully, do you want Chen-Yu to
resend his serie following your comments, or was that just a general
remark for next time?

Thanks!
Maxime

-- 
Maxime Ripard, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20180503/ca25c556/attachment.sig>

^ permalink raw reply	[flat|nested] 80+ messages in thread
* Re: [PATCH net-next v2 00/15] ARM: sun8i: r40: Add Ethernet support
  2018-05-03 13:12       ` Maxime Ripard
@ 2018-05-03 18:40         ` David Miller
  -1 siblings, 0 replies; 80+ messages in thread
From: David Miller @ 2018-05-03 18:40 UTC (permalink / raw)
  To: maxime.ripard
  Cc: wens, mturquette, sboyd, peppe.cavallaro, robh+dt, mark.rutland,
	broonie, linux-arm-kernel, linux-clk, devicetree, netdev,
	clabbe.montjoie, icenowy

From: Maxime Ripard <maxime.ripard@bootlin.com>
Date: Thu, 3 May 2018 15:12:57 +0200

> Hi Dave,
> 
> On Wed, May 02, 2018 at 11:06:17AM -0400, David Miller wrote:
>> From: Chen-Yu Tsai <wens@csie.org>
>> Date: Wed, 2 May 2018 00:33:45 +0800
>> 
>> > I should've mentioned that patches 3 ~ 10, and only these, should go
>> > through net-next. sunxi will handle the remaining clk, device tree, and
>> > soc driver patches.
>> 
>> Ok, I just noticed this.
>> 
>> Why don't you just post those patches separately as a series on their
>> own then, in order to avoid confusion?
>> 
>> Then you can adjust the patch series header posting to explain the
>> non-net-next changes, where they got merged, and what they provide
>> in order to faciliate the net-next changes.
> 
> I now that we usually have some feedback from non-net maintainers that
> they actually prefer seeing the full picture (and I also tend to
> prefer that as well) and having all the patches relevant to enable a
> particular feature, even if it means getting multiple maintainers
> involved.
> 
> Just to make sure we understood you fully, do you want Chen-Yu to
> resend his serie following your comments, or was that just a general
> remark for next time?

Yeah, good questions.

I think it can be argued either way.  For review having the complete
context is important.

But from a maintainer's standpoint, when there is any ambiguity
whatsoever about what patches go into this tree or that, it is really
frowned upon and is quite error prone.

Also, that header posting is _SO_ important.  It explains the series.
But for these 'partial apply' situations the header posting refers
to patches not in the series.

This looks terrible in the logs, when, as I do, the header posting
text is added to a marge commit for the series.  People will read it
and say "where are all of these other changes mentioned in the text?
was this series misapplied?"

That's why, maybe after the review is successful, I want the actual
patch series standalone with appropriately updated header posting
text.

^ permalink raw reply	[flat|nested] 80+ messages in thread
* [PATCH net-next v2 00/15] ARM: sun8i: r40: Add Ethernet support
@ 2018-05-03 18:40         ` David Miller
  0 siblings, 0 replies; 80+ messages in thread
From: David Miller @ 2018-05-03 18:40 UTC (permalink / raw)
  To: linux-arm-kernel

From: Maxime Ripard <maxime.ripard@bootlin.com>
Date: Thu, 3 May 2018 15:12:57 +0200

> Hi Dave,
> 
> On Wed, May 02, 2018 at 11:06:17AM -0400, David Miller wrote:
>> From: Chen-Yu Tsai <wens@csie.org>
>> Date: Wed, 2 May 2018 00:33:45 +0800
>> 
>> > I should've mentioned that patches 3 ~ 10, and only these, should go
>> > through net-next. sunxi will handle the remaining clk, device tree, and
>> > soc driver patches.
>> 
>> Ok, I just noticed this.
>> 
>> Why don't you just post those patches separately as a series on their
>> own then, in order to avoid confusion?
>> 
>> Then you can adjust the patch series header posting to explain the
>> non-net-next changes, where they got merged, and what they provide
>> in order to faciliate the net-next changes.
> 
> I now that we usually have some feedback from non-net maintainers that
> they actually prefer seeing the full picture (and I also tend to
> prefer that as well) and having all the patches relevant to enable a
> particular feature, even if it means getting multiple maintainers
> involved.
> 
> Just to make sure we understood you fully, do you want Chen-Yu to
> resend his serie following your comments, or was that just a general
> remark for next time?

Yeah, good questions.

I think it can be argued either way.  For review having the complete
context is important.

But from a maintainer's standpoint, when there is any ambiguity
whatsoever about what patches go into this tree or that, it is really
frowned upon and is quite error prone.

Also, that header posting is _SO_ important.  It explains the series.
But for these 'partial apply' situations the header posting refers
to patches not in the series.

This looks terrible in the logs, when, as I do, the header posting
text is added to a marge commit for the series.  People will read it
and say "where are all of these other changes mentioned in the text?
was this series misapplied?"

That's why, maybe after the review is successful, I want the actual
patch series standalone with appropriately updated header posting
text.

^ permalink raw reply	[flat|nested] 80+ messages in thread
* Re: [PATCH net-next v2 00/15] ARM: sun8i: r40: Add Ethernet support
  2018-05-03 18:40         ` David Miller
@ 2018-05-04 15:03           ` Maxime Ripard
  -1 siblings, 0 replies; 80+ messages in thread
From: Maxime Ripard @ 2018-05-04 15:03 UTC (permalink / raw)
  To: David Miller
  Cc: wens, mturquette, sboyd, peppe.cavallaro, robh+dt, mark.rutland,
	broonie, linux-arm-kernel, linux-clk, devicetree, netdev,
	clabbe.montjoie, icenowy

[-- Attachment #1: Type: text/plain, Size: 2461 bytes --]

On Thu, May 03, 2018 at 02:40:42PM -0400, David Miller wrote:
> From: Maxime Ripard <maxime.ripard@bootlin.com>
> Date: Thu, 3 May 2018 15:12:57 +0200
> 
> > Hi Dave,
> > 
> > On Wed, May 02, 2018 at 11:06:17AM -0400, David Miller wrote:
> >> From: Chen-Yu Tsai <wens@csie.org>
> >> Date: Wed, 2 May 2018 00:33:45 +0800
> >> 
> >> > I should've mentioned that patches 3 ~ 10, and only these, should go
> >> > through net-next. sunxi will handle the remaining clk, device tree, and
> >> > soc driver patches.
> >> 
> >> Ok, I just noticed this.
> >> 
> >> Why don't you just post those patches separately as a series on their
> >> own then, in order to avoid confusion?
> >> 
> >> Then you can adjust the patch series header posting to explain the
> >> non-net-next changes, where they got merged, and what they provide
> >> in order to faciliate the net-next changes.
> > 
> > I now that we usually have some feedback from non-net maintainers that
> > they actually prefer seeing the full picture (and I also tend to
> > prefer that as well) and having all the patches relevant to enable a
> > particular feature, even if it means getting multiple maintainers
> > involved.
> > 
> > Just to make sure we understood you fully, do you want Chen-Yu to
> > resend his serie following your comments, or was that just a general
> > remark for next time?
> 
> Yeah, good questions.
> 
> I think it can be argued either way.  For review having the complete
> context is important.
> 
> But from a maintainer's standpoint, when there is any ambiguity
> whatsoever about what patches go into this tree or that, it is really
> frowned upon and is quite error prone.
> 
> Also, that header posting is _SO_ important.  It explains the series.
> But for these 'partial apply' situations the header posting refers
> to patches not in the series.
> 
> This looks terrible in the logs, when, as I do, the header posting
> text is added to a marge commit for the series.  People will read it
> and say "where are all of these other changes mentioned in the text?
> was this series misapplied?"
> 
> That's why, maybe after the review is successful, I want the actual
> patch series standalone with appropriately updated header posting
> text.

Ok, thanks for the explanation, that makes sense :)

Maxime

-- 
Maxime Ripard, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

^ permalink raw reply	[flat|nested] 80+ messages in thread
* [PATCH net-next v2 00/15] ARM: sun8i: r40: Add Ethernet support
@ 2018-05-04 15:03           ` Maxime Ripard
  0 siblings, 0 replies; 80+ messages in thread
From: Maxime Ripard @ 2018-05-04 15:03 UTC (permalink / raw)
  To: linux-arm-kernel

On Thu, May 03, 2018 at 02:40:42PM -0400, David Miller wrote:
> From: Maxime Ripard <maxime.ripard@bootlin.com>
> Date: Thu, 3 May 2018 15:12:57 +0200
> 
> > Hi Dave,
> > 
> > On Wed, May 02, 2018 at 11:06:17AM -0400, David Miller wrote:
> >> From: Chen-Yu Tsai <wens@csie.org>
> >> Date: Wed, 2 May 2018 00:33:45 +0800
> >> 
> >> > I should've mentioned that patches 3 ~ 10, and only these, should go
> >> > through net-next. sunxi will handle the remaining clk, device tree, and
> >> > soc driver patches.
> >> 
> >> Ok, I just noticed this.
> >> 
> >> Why don't you just post those patches separately as a series on their
> >> own then, in order to avoid confusion?
> >> 
> >> Then you can adjust the patch series header posting to explain the
> >> non-net-next changes, where they got merged, and what they provide
> >> in order to faciliate the net-next changes.
> > 
> > I now that we usually have some feedback from non-net maintainers that
> > they actually prefer seeing the full picture (and I also tend to
> > prefer that as well) and having all the patches relevant to enable a
> > particular feature, even if it means getting multiple maintainers
> > involved.
> > 
> > Just to make sure we understood you fully, do you want Chen-Yu to
> > resend his serie following your comments, or was that just a general
> > remark for next time?
> 
> Yeah, good questions.
> 
> I think it can be argued either way.  For review having the complete
> context is important.
> 
> But from a maintainer's standpoint, when there is any ambiguity
> whatsoever about what patches go into this tree or that, it is really
> frowned upon and is quite error prone.
> 
> Also, that header posting is _SO_ important.  It explains the series.
> But for these 'partial apply' situations the header posting refers
> to patches not in the series.
> 
> This looks terrible in the logs, when, as I do, the header posting
> text is added to a marge commit for the series.  People will read it
> and say "where are all of these other changes mentioned in the text?
> was this series misapplied?"
> 
> That's why, maybe after the review is successful, I want the actual
> patch series standalone with appropriately updated header posting
> text.

Ok, thanks for the explanation, that makes sense :)

Maxime

-- 
Maxime Ripard, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20180504/fe9e3279/attachment.sig>

^ permalink raw reply	[flat|nested] 80+ messages in thread
* Re: [PATCH net-next v2 15/15] arm64: dts: allwinner: a64: add SRAM controller device tree node
  2018-05-02 11:54           ` Maxime Ripard
  (?)
@ 2018-05-13 19:37             ` Chen-Yu Tsai
  -1 siblings, 0 replies; 80+ messages in thread
From: Chen-Yu Tsai @ 2018-05-13 19:37 UTC (permalink / raw)
  To: Maxime Ripard
  Cc: Icenowy Zheng, linux-arm-kernel, Mark Rutland, devicetree,
	Stephen Boyd, netdev, Michael Turquette, Rob Herring,
	Corentin Labbe, Mark Brown, Giuseppe Cavallaro, linux-clk

On Wed, May 2, 2018 at 4:54 AM, Maxime Ripard <maxime.ripard@bootlin.com> wrote:
> On Wed, May 02, 2018 at 06:19:51PM +0800, Icenowy Zheng wrote:
>>
>>
>> 于 2018年5月2日 GMT+08:00 下午5:53:21, Chen-Yu Tsai <wens@csie.org> 写到:
>> >On Wed, May 2, 2018 at 5:51 PM, Maxime Ripard
>> ><maxime.ripard@bootlin.com> wrote:
>> >> Hi,
>> >>
>> >> On Wed, May 02, 2018 at 12:12:27AM +0800, Chen-Yu Tsai wrote:
>> >>> From: Icenowy Zheng <icenowy@aosc.io>
>> >>>
>> >>> Allwinner A64 has a SRAM controller, and in the device tree
>> >currently
>> >>> we have a syscon node to enable EMAC driver to access the EMAC clock
>> >>> register. As SRAM controller driver can now export regmap for this
>> >>> register, replace the syscon node to the SRAM controller device
>> >node,
>> >>> and let EMAC driver to acquire its EMAC clock regmap.
>> >>>
>> >>> Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
>> >>> Signed-off-by: Chen-Yu Tsai <wens@csie.org>
>> >>> ---
>> >>>  arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi | 23
>> >+++++++++++++++----
>> >>>  1 file changed, 19 insertions(+), 4 deletions(-)
>> >>>
>> >>> diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
>> >b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
>> >>> index 1b2ef28c42bd..1c37659d9d41 100644
>> >>> --- a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
>> >>> +++ b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
>> >>> @@ -168,10 +168,25 @@
>> >>>               #size-cells = <1>;
>> >>>               ranges;
>> >>>
>> >>> -             syscon: syscon@1c00000 {
>> >>> -                     compatible =
>> >"allwinner,sun50i-a64-system-controller",
>> >>> -                             "syscon";
>> >>> +             sram_controller: sram-controller@1c00000 {
>> >>> +                     compatible =
>> >"allwinner,sun50i-a64-sram-controller";
>> >>
>> >> I don't think there's anything preventing us from keeping the
>> >> -system-controller compatible. It's what was in the DT before, and
>> >> it's how it's called in the datasheet.
>> >
>> >I actually meant to ask you about this. The -system-controller
>> >compatible matches the datasheet better. Maybe we should just
>> >switch to that one?
>>
>> No, if we do the switch the system-controller compatible,
>> the device will be probed on the same memory region with
>> a syscon on old DTs.
>
> The device hasn't magically changed either. Maybe we just need to add
> a check to make sure we don't have the syscon compatible in the SRAM
> driver probe so that the double driver issue doesn't happen?

The syscon interface (which is not even a full blown device driver)
only looks at the "syscon" compatible. Either way we're removing that
part from the device tree so things should be ok for new device trees.
As Maxime mentioned we can do a check for the syscon compatible and
either give a warning to the user asking them to update their device
tree, or not register our custom regmap, or not probe the SRAM driver.
Personally I prefer the first option. The system controller block is
probed before any syscon users, so we should be fine, given the dwmac
driver goes the custom regmap path first.

BTW, I still might end up changing the compatible. The manual uses
"system control", not "system controller", which I think makes sense,
since it is just a bunch of register files, kind of like the GRF
(General Register Files) block found in Rockchip SoCs [1], and not an
actual "controller".

ChenYu

[1] https://www.kernel.org/doc/Documentation/devicetree/bindings/soc/rockchip/grf.txt

^ permalink raw reply	[flat|nested] 80+ messages in thread
* Re: [PATCH net-next v2 15/15] arm64: dts: allwinner: a64: add SRAM controller device tree node
@ 2018-05-13 19:37             ` Chen-Yu Tsai
  0 siblings, 0 replies; 80+ messages in thread
From: Chen-Yu Tsai @ 2018-05-13 19:37 UTC (permalink / raw)
  To: Maxime Ripard
  Cc: Icenowy Zheng, linux-arm-kernel, Mark Rutland, devicetree,
	Stephen Boyd, netdev, Michael Turquette, Rob Herring,
	Corentin Labbe, Mark Brown, Giuseppe Cavallaro, linux-clk

On Wed, May 2, 2018 at 4:54 AM, Maxime Ripard <maxime.ripard@bootlin.com> w=
rote:
> On Wed, May 02, 2018 at 06:19:51PM +0800, Icenowy Zheng wrote:
>>
>>
>> =E4=BA=8E 2018=E5=B9=B45=E6=9C=882=E6=97=A5 GMT+08:00 =E4=B8=8B=E5=8D=88=
5:53:21, Chen-Yu Tsai <wens@csie.org> =E5=86=99=E5=88=B0:
>> >On Wed, May 2, 2018 at 5:51 PM, Maxime Ripard
>> ><maxime.ripard@bootlin.com> wrote:
>> >> Hi,
>> >>
>> >> On Wed, May 02, 2018 at 12:12:27AM +0800, Chen-Yu Tsai wrote:
>> >>> From: Icenowy Zheng <icenowy@aosc.io>
>> >>>
>> >>> Allwinner A64 has a SRAM controller, and in the device tree
>> >currently
>> >>> we have a syscon node to enable EMAC driver to access the EMAC clock
>> >>> register. As SRAM controller driver can now export regmap for this
>> >>> register, replace the syscon node to the SRAM controller device
>> >node,
>> >>> and let EMAC driver to acquire its EMAC clock regmap.
>> >>>
>> >>> Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
>> >>> Signed-off-by: Chen-Yu Tsai <wens@csie.org>
>> >>> ---
>> >>>  arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi | 23
>> >+++++++++++++++----
>> >>>  1 file changed, 19 insertions(+), 4 deletions(-)
>> >>>
>> >>> diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
>> >b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
>> >>> index 1b2ef28c42bd..1c37659d9d41 100644
>> >>> --- a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
>> >>> +++ b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
>> >>> @@ -168,10 +168,25 @@
>> >>>               #size-cells =3D <1>;
>> >>>               ranges;
>> >>>
>> >>> -             syscon: syscon@1c00000 {
>> >>> -                     compatible =3D
>> >"allwinner,sun50i-a64-system-controller",
>> >>> -                             "syscon";
>> >>> +             sram_controller: sram-controller@1c00000 {
>> >>> +                     compatible =3D
>> >"allwinner,sun50i-a64-sram-controller";
>> >>
>> >> I don't think there's anything preventing us from keeping the
>> >> -system-controller compatible. It's what was in the DT before, and
>> >> it's how it's called in the datasheet.
>> >
>> >I actually meant to ask you about this. The -system-controller
>> >compatible matches the datasheet better. Maybe we should just
>> >switch to that one?
>>
>> No, if we do the switch the system-controller compatible,
>> the device will be probed on the same memory region with
>> a syscon on old DTs.
>
> The device hasn't magically changed either. Maybe we just need to add
> a check to make sure we don't have the syscon compatible in the SRAM
> driver probe so that the double driver issue doesn't happen?

The syscon interface (which is not even a full blown device driver)
only looks at the "syscon" compatible. Either way we're removing that
part from the device tree so things should be ok for new device trees.
As Maxime mentioned we can do a check for the syscon compatible and
either give a warning to the user asking them to update their device
tree, or not register our custom regmap, or not probe the SRAM driver.
Personally I prefer the first option. The system controller block is
probed before any syscon users, so we should be fine, given the dwmac
driver goes the custom regmap path first.

BTW, I still might end up changing the compatible. The manual uses
"system control", not "system controller", which I think makes sense,
since it is just a bunch of register files, kind of like the GRF
(General Register Files) block found in Rockchip SoCs [1], and not an
actual "controller".

ChenYu

[1] https://www.kernel.org/doc/Documentation/devicetree/bindings/soc/rockch=
ip/grf.txt

^ permalink raw reply	[flat|nested] 80+ messages in thread
* [PATCH net-next v2 15/15] arm64: dts: allwinner: a64: add SRAM controller device tree node
@ 2018-05-13 19:37             ` Chen-Yu Tsai
  0 siblings, 0 replies; 80+ messages in thread
From: Chen-Yu Tsai @ 2018-05-13 19:37 UTC (permalink / raw)
  To: linux-arm-kernel

On Wed, May 2, 2018 at 4:54 AM, Maxime Ripard <maxime.ripard@bootlin.com> wrote:
> On Wed, May 02, 2018 at 06:19:51PM +0800, Icenowy Zheng wrote:
>>
>>
>> ? 2018?5?2? GMT+08:00 ??5:53:21, Chen-Yu Tsai <wens@csie.org> ??:
>> >On Wed, May 2, 2018 at 5:51 PM, Maxime Ripard
>> ><maxime.ripard@bootlin.com> wrote:
>> >> Hi,
>> >>
>> >> On Wed, May 02, 2018 at 12:12:27AM +0800, Chen-Yu Tsai wrote:
>> >>> From: Icenowy Zheng <icenowy@aosc.io>
>> >>>
>> >>> Allwinner A64 has a SRAM controller, and in the device tree
>> >currently
>> >>> we have a syscon node to enable EMAC driver to access the EMAC clock
>> >>> register. As SRAM controller driver can now export regmap for this
>> >>> register, replace the syscon node to the SRAM controller device
>> >node,
>> >>> and let EMAC driver to acquire its EMAC clock regmap.
>> >>>
>> >>> Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
>> >>> Signed-off-by: Chen-Yu Tsai <wens@csie.org>
>> >>> ---
>> >>>  arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi | 23
>> >+++++++++++++++----
>> >>>  1 file changed, 19 insertions(+), 4 deletions(-)
>> >>>
>> >>> diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
>> >b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
>> >>> index 1b2ef28c42bd..1c37659d9d41 100644
>> >>> --- a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
>> >>> +++ b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
>> >>> @@ -168,10 +168,25 @@
>> >>>               #size-cells = <1>;
>> >>>               ranges;
>> >>>
>> >>> -             syscon: syscon at 1c00000 {
>> >>> -                     compatible =
>> >"allwinner,sun50i-a64-system-controller",
>> >>> -                             "syscon";
>> >>> +             sram_controller: sram-controller at 1c00000 {
>> >>> +                     compatible =
>> >"allwinner,sun50i-a64-sram-controller";
>> >>
>> >> I don't think there's anything preventing us from keeping the
>> >> -system-controller compatible. It's what was in the DT before, and
>> >> it's how it's called in the datasheet.
>> >
>> >I actually meant to ask you about this. The -system-controller
>> >compatible matches the datasheet better. Maybe we should just
>> >switch to that one?
>>
>> No, if we do the switch the system-controller compatible,
>> the device will be probed on the same memory region with
>> a syscon on old DTs.
>
> The device hasn't magically changed either. Maybe we just need to add
> a check to make sure we don't have the syscon compatible in the SRAM
> driver probe so that the double driver issue doesn't happen?

The syscon interface (which is not even a full blown device driver)
only looks at the "syscon" compatible. Either way we're removing that
part from the device tree so things should be ok for new device trees.
As Maxime mentioned we can do a check for the syscon compatible and
either give a warning to the user asking them to update their device
tree, or not register our custom regmap, or not probe the SRAM driver.
Personally I prefer the first option. The system controller block is
probed before any syscon users, so we should be fine, given the dwmac
driver goes the custom regmap path first.

BTW, I still might end up changing the compatible. The manual uses
"system control", not "system controller", which I think makes sense,
since it is just a bunch of register files, kind of like the GRF
(General Register Files) block found in Rockchip SoCs [1], and not an
actual "controller".

ChenYu

[1] https://www.kernel.org/doc/Documentation/devicetree/bindings/soc/rockchip/grf.txt

^ permalink raw reply	[flat|nested] 80+ messages in thread
* Re: [PATCH net-next v2 15/15] arm64: dts: allwinner: a64: add SRAM controller device tree node
  2018-05-13 19:37             ` Chen-Yu Tsai
@ 2018-05-14  8:03               ` Maxime Ripard
  -1 siblings, 0 replies; 80+ messages in thread
From: Maxime Ripard @ 2018-05-14  8:03 UTC (permalink / raw)
  To: Chen-Yu Tsai
  Cc: Icenowy Zheng, linux-arm-kernel, Mark Rutland, devicetree,
	Stephen Boyd, netdev, Michael Turquette, Rob Herring,
	Corentin Labbe, Mark Brown, Giuseppe Cavallaro, linux-clk

[-- Attachment #1: Type: text/plain, Size: 3965 bytes --]

1;5201;0c
On Sun, May 13, 2018 at 12:37:49PM -0700, Chen-Yu Tsai wrote:
> On Wed, May 2, 2018 at 4:54 AM, Maxime Ripard <maxime.ripard@bootlin.com> wrote:
> > On Wed, May 02, 2018 at 06:19:51PM +0800, Icenowy Zheng wrote:
> >>
> >>
> >> 于 2018年5月2日 GMT+08:00 下午5:53:21, Chen-Yu Tsai <wens@csie.org> 写到:
> >> >On Wed, May 2, 2018 at 5:51 PM, Maxime Ripard
> >> ><maxime.ripard@bootlin.com> wrote:
> >> >> Hi,
> >> >>
> >> >> On Wed, May 02, 2018 at 12:12:27AM +0800, Chen-Yu Tsai wrote:
> >> >>> From: Icenowy Zheng <icenowy@aosc.io>
> >> >>>
> >> >>> Allwinner A64 has a SRAM controller, and in the device tree
> >> >currently
> >> >>> we have a syscon node to enable EMAC driver to access the EMAC clock
> >> >>> register. As SRAM controller driver can now export regmap for this
> >> >>> register, replace the syscon node to the SRAM controller device
> >> >node,
> >> >>> and let EMAC driver to acquire its EMAC clock regmap.
> >> >>>
> >> >>> Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
> >> >>> Signed-off-by: Chen-Yu Tsai <wens@csie.org>
> >> >>> ---
> >> >>>  arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi | 23
> >> >+++++++++++++++----
> >> >>>  1 file changed, 19 insertions(+), 4 deletions(-)
> >> >>>
> >> >>> diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
> >> >b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
> >> >>> index 1b2ef28c42bd..1c37659d9d41 100644
> >> >>> --- a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
> >> >>> +++ b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
> >> >>> @@ -168,10 +168,25 @@
> >> >>>               #size-cells = <1>;
> >> >>>               ranges;
> >> >>>
> >> >>> -             syscon: syscon@1c00000 {
> >> >>> -                     compatible =
> >> >"allwinner,sun50i-a64-system-controller",
> >> >>> -                             "syscon";
> >> >>> +             sram_controller: sram-controller@1c00000 {
> >> >>> +                     compatible =
> >> >"allwinner,sun50i-a64-sram-controller";
> >> >>
> >> >> I don't think there's anything preventing us from keeping the
> >> >> -system-controller compatible. It's what was in the DT before, and
> >> >> it's how it's called in the datasheet.
> >> >
> >> >I actually meant to ask you about this. The -system-controller
> >> >compatible matches the datasheet better. Maybe we should just
> >> >switch to that one?
> >>
> >> No, if we do the switch the system-controller compatible,
> >> the device will be probed on the same memory region with
> >> a syscon on old DTs.
> >
> > The device hasn't magically changed either. Maybe we just need to add
> > a check to make sure we don't have the syscon compatible in the SRAM
> > driver probe so that the double driver issue doesn't happen?
> 
> The syscon interface (which is not even a full blown device driver)
> only looks at the "syscon" compatible. Either way we're removing that
> part from the device tree so things should be ok for new device trees.
> As Maxime mentioned we can do a check for the syscon compatible and
> either give a warning to the user asking them to update their device
> tree, or not register our custom regmap, or not probe the SRAM driver.
> Personally I prefer the first option. The system controller block is
> probed before any syscon users, so we should be fine, given the dwmac
> driver goes the custom regmap path first.
> 
> BTW, I still might end up changing the compatible. The manual uses
> "system control", not "system controller", which I think makes sense,
> since it is just a bunch of register files, kind of like the GRF
> (General Register Files) block found in Rockchip SoCs [1], and not an
> actual "controller".

I'm not really fond of that, but we should at least make it consistent
on the other patches Paul sent then.

Maxime

-- 
Maxime Ripard, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

^ permalink raw reply	[flat|nested] 80+ messages in thread
* [PATCH net-next v2 15/15] arm64: dts: allwinner: a64: add SRAM controller device tree node
@ 2018-05-14  8:03               ` Maxime Ripard
  0 siblings, 0 replies; 80+ messages in thread
From: Maxime Ripard @ 2018-05-14  8:03 UTC (permalink / raw)
  To: linux-arm-kernel

1;5201;0c
On Sun, May 13, 2018 at 12:37:49PM -0700, Chen-Yu Tsai wrote:
> On Wed, May 2, 2018 at 4:54 AM, Maxime Ripard <maxime.ripard@bootlin.com> wrote:
> > On Wed, May 02, 2018 at 06:19:51PM +0800, Icenowy Zheng wrote:
> >>
> >>
> >> ? 2018?5?2? GMT+08:00 ??5:53:21, Chen-Yu Tsai <wens@csie.org> ??:
> >> >On Wed, May 2, 2018 at 5:51 PM, Maxime Ripard
> >> ><maxime.ripard@bootlin.com> wrote:
> >> >> Hi,
> >> >>
> >> >> On Wed, May 02, 2018 at 12:12:27AM +0800, Chen-Yu Tsai wrote:
> >> >>> From: Icenowy Zheng <icenowy@aosc.io>
> >> >>>
> >> >>> Allwinner A64 has a SRAM controller, and in the device tree
> >> >currently
> >> >>> we have a syscon node to enable EMAC driver to access the EMAC clock
> >> >>> register. As SRAM controller driver can now export regmap for this
> >> >>> register, replace the syscon node to the SRAM controller device
> >> >node,
> >> >>> and let EMAC driver to acquire its EMAC clock regmap.
> >> >>>
> >> >>> Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
> >> >>> Signed-off-by: Chen-Yu Tsai <wens@csie.org>
> >> >>> ---
> >> >>>  arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi | 23
> >> >+++++++++++++++----
> >> >>>  1 file changed, 19 insertions(+), 4 deletions(-)
> >> >>>
> >> >>> diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
> >> >b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
> >> >>> index 1b2ef28c42bd..1c37659d9d41 100644
> >> >>> --- a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
> >> >>> +++ b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
> >> >>> @@ -168,10 +168,25 @@
> >> >>>               #size-cells = <1>;
> >> >>>               ranges;
> >> >>>
> >> >>> -             syscon: syscon at 1c00000 {
> >> >>> -                     compatible =
> >> >"allwinner,sun50i-a64-system-controller",
> >> >>> -                             "syscon";
> >> >>> +             sram_controller: sram-controller at 1c00000 {
> >> >>> +                     compatible =
> >> >"allwinner,sun50i-a64-sram-controller";
> >> >>
> >> >> I don't think there's anything preventing us from keeping the
> >> >> -system-controller compatible. It's what was in the DT before, and
> >> >> it's how it's called in the datasheet.
> >> >
> >> >I actually meant to ask you about this. The -system-controller
> >> >compatible matches the datasheet better. Maybe we should just
> >> >switch to that one?
> >>
> >> No, if we do the switch the system-controller compatible,
> >> the device will be probed on the same memory region with
> >> a syscon on old DTs.
> >
> > The device hasn't magically changed either. Maybe we just need to add
> > a check to make sure we don't have the syscon compatible in the SRAM
> > driver probe so that the double driver issue doesn't happen?
> 
> The syscon interface (which is not even a full blown device driver)
> only looks at the "syscon" compatible. Either way we're removing that
> part from the device tree so things should be ok for new device trees.
> As Maxime mentioned we can do a check for the syscon compatible and
> either give a warning to the user asking them to update their device
> tree, or not register our custom regmap, or not probe the SRAM driver.
> Personally I prefer the first option. The system controller block is
> probed before any syscon users, so we should be fine, given the dwmac
> driver goes the custom regmap path first.
> 
> BTW, I still might end up changing the compatible. The manual uses
> "system control", not "system controller", which I think makes sense,
> since it is just a bunch of register files, kind of like the GRF
> (General Register Files) block found in Rockchip SoCs [1], and not an
> actual "controller".

I'm not really fond of that, but we should at least make it consistent
on the other patches Paul sent then.

Maxime

-- 
Maxime Ripard, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20180514/1e0da858/attachment-0001.sig>

^ permalink raw reply	[flat|nested] 80+ messages in thread
* Re: [PATCH net-next v2 15/15] arm64: dts: allwinner: a64: add SRAM controller device tree node
  2018-05-14  8:03               ` Maxime Ripard
  (?)
@ 2018-05-16  6:47                 ` Chen-Yu Tsai
  -1 siblings, 0 replies; 80+ messages in thread
From: Chen-Yu Tsai @ 2018-05-16  6:47 UTC (permalink / raw)
  To: Maxime Ripard
  Cc: Icenowy Zheng, linux-arm-kernel, Mark Rutland, devicetree,
	Stephen Boyd, netdev, Michael Turquette, Rob Herring,
	Corentin Labbe, Mark Brown, Giuseppe Cavallaro, linux-clk

On Mon, May 14, 2018 at 1:03 AM, Maxime Ripard
<maxime.ripard@bootlin.com> wrote:
> 1;5201;0c
> On Sun, May 13, 2018 at 12:37:49PM -0700, Chen-Yu Tsai wrote:
>> On Wed, May 2, 2018 at 4:54 AM, Maxime Ripard <maxime.ripard@bootlin.com> wrote:
>> > On Wed, May 02, 2018 at 06:19:51PM +0800, Icenowy Zheng wrote:
>> >>
>> >>
>> >> 于 2018年5月2日 GMT+08:00 下午5:53:21, Chen-Yu Tsai <wens@csie.org> 写到:
>> >> >On Wed, May 2, 2018 at 5:51 PM, Maxime Ripard
>> >> ><maxime.ripard@bootlin.com> wrote:
>> >> >> Hi,
>> >> >>
>> >> >> On Wed, May 02, 2018 at 12:12:27AM +0800, Chen-Yu Tsai wrote:
>> >> >>> From: Icenowy Zheng <icenowy@aosc.io>
>> >> >>>
>> >> >>> Allwinner A64 has a SRAM controller, and in the device tree
>> >> >currently
>> >> >>> we have a syscon node to enable EMAC driver to access the EMAC clock
>> >> >>> register. As SRAM controller driver can now export regmap for this
>> >> >>> register, replace the syscon node to the SRAM controller device
>> >> >node,
>> >> >>> and let EMAC driver to acquire its EMAC clock regmap.
>> >> >>>
>> >> >>> Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
>> >> >>> Signed-off-by: Chen-Yu Tsai <wens@csie.org>
>> >> >>> ---
>> >> >>>  arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi | 23
>> >> >+++++++++++++++----
>> >> >>>  1 file changed, 19 insertions(+), 4 deletions(-)
>> >> >>>
>> >> >>> diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
>> >> >b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
>> >> >>> index 1b2ef28c42bd..1c37659d9d41 100644
>> >> >>> --- a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
>> >> >>> +++ b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
>> >> >>> @@ -168,10 +168,25 @@
>> >> >>>               #size-cells = <1>;
>> >> >>>               ranges;
>> >> >>>
>> >> >>> -             syscon: syscon@1c00000 {
>> >> >>> -                     compatible =
>> >> >"allwinner,sun50i-a64-system-controller",
>> >> >>> -                             "syscon";
>> >> >>> +             sram_controller: sram-controller@1c00000 {
>> >> >>> +                     compatible =
>> >> >"allwinner,sun50i-a64-sram-controller";
>> >> >>
>> >> >> I don't think there's anything preventing us from keeping the
>> >> >> -system-controller compatible. It's what was in the DT before, and
>> >> >> it's how it's called in the datasheet.
>> >> >
>> >> >I actually meant to ask you about this. The -system-controller
>> >> >compatible matches the datasheet better. Maybe we should just
>> >> >switch to that one?
>> >>
>> >> No, if we do the switch the system-controller compatible,
>> >> the device will be probed on the same memory region with
>> >> a syscon on old DTs.
>> >
>> > The device hasn't magically changed either. Maybe we just need to add
>> > a check to make sure we don't have the syscon compatible in the SRAM
>> > driver probe so that the double driver issue doesn't happen?
>>
>> The syscon interface (which is not even a full blown device driver)
>> only looks at the "syscon" compatible. Either way we're removing that
>> part from the device tree so things should be ok for new device trees.
>> As Maxime mentioned we can do a check for the syscon compatible and
>> either give a warning to the user asking them to update their device
>> tree, or not register our custom regmap, or not probe the SRAM driver.
>> Personally I prefer the first option. The system controller block is
>> probed before any syscon users, so we should be fine, given the dwmac
>> driver goes the custom regmap path first.
>>
>> BTW, I still might end up changing the compatible. The manual uses
>> "system control", not "system controller", which I think makes sense,
>> since it is just a bunch of register files, kind of like the GRF
>> (General Register Files) block found in Rockchip SoCs [1], and not an
>> actual "controller".
>
> I'm not really fond of that, but we should at least make it consistent
> on the other patches Paul sent then.

For the A10s / A13 right?

I think my naming is slightly better, but it's just a minor detail.
While we're still debating this, can I merge the R40 stuff first?
The driver bits are already in.

Thanks
ChenYu

^ permalink raw reply	[flat|nested] 80+ messages in thread
* Re: [PATCH net-next v2 15/15] arm64: dts: allwinner: a64: add SRAM controller device tree node
@ 2018-05-16  6:47                 ` Chen-Yu Tsai
  0 siblings, 0 replies; 80+ messages in thread
From: Chen-Yu Tsai @ 2018-05-16  6:47 UTC (permalink / raw)
  To: Maxime Ripard
  Cc: Icenowy Zheng, linux-arm-kernel, Mark Rutland, devicetree,
	Stephen Boyd, netdev, Michael Turquette, Rob Herring,
	Corentin Labbe, Mark Brown, Giuseppe Cavallaro, linux-clk

On Mon, May 14, 2018 at 1:03 AM, Maxime Ripard
<maxime.ripard@bootlin.com> wrote:
> 1;5201;0c
> On Sun, May 13, 2018 at 12:37:49PM -0700, Chen-Yu Tsai wrote:
>> On Wed, May 2, 2018 at 4:54 AM, Maxime Ripard <maxime.ripard@bootlin.com=
> wrote:
>> > On Wed, May 02, 2018 at 06:19:51PM +0800, Icenowy Zheng wrote:
>> >>
>> >>
>> >> =E4=BA=8E 2018=E5=B9=B45=E6=9C=882=E6=97=A5 GMT+08:00 =E4=B8=8B=E5=8D=
=885:53:21, Chen-Yu Tsai <wens@csie.org> =E5=86=99=E5=88=B0:
>> >> >On Wed, May 2, 2018 at 5:51 PM, Maxime Ripard
>> >> ><maxime.ripard@bootlin.com> wrote:
>> >> >> Hi,
>> >> >>
>> >> >> On Wed, May 02, 2018 at 12:12:27AM +0800, Chen-Yu Tsai wrote:
>> >> >>> From: Icenowy Zheng <icenowy@aosc.io>
>> >> >>>
>> >> >>> Allwinner A64 has a SRAM controller, and in the device tree
>> >> >currently
>> >> >>> we have a syscon node to enable EMAC driver to access the EMAC cl=
ock
>> >> >>> register. As SRAM controller driver can now export regmap for thi=
s
>> >> >>> register, replace the syscon node to the SRAM controller device
>> >> >node,
>> >> >>> and let EMAC driver to acquire its EMAC clock regmap.
>> >> >>>
>> >> >>> Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
>> >> >>> Signed-off-by: Chen-Yu Tsai <wens@csie.org>
>> >> >>> ---
>> >> >>>  arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi | 23
>> >> >+++++++++++++++----
>> >> >>>  1 file changed, 19 insertions(+), 4 deletions(-)
>> >> >>>
>> >> >>> diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
>> >> >b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
>> >> >>> index 1b2ef28c42bd..1c37659d9d41 100644
>> >> >>> --- a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
>> >> >>> +++ b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
>> >> >>> @@ -168,10 +168,25 @@
>> >> >>>               #size-cells =3D <1>;
>> >> >>>               ranges;
>> >> >>>
>> >> >>> -             syscon: syscon@1c00000 {
>> >> >>> -                     compatible =3D
>> >> >"allwinner,sun50i-a64-system-controller",
>> >> >>> -                             "syscon";
>> >> >>> +             sram_controller: sram-controller@1c00000 {
>> >> >>> +                     compatible =3D
>> >> >"allwinner,sun50i-a64-sram-controller";
>> >> >>
>> >> >> I don't think there's anything preventing us from keeping the
>> >> >> -system-controller compatible. It's what was in the DT before, and
>> >> >> it's how it's called in the datasheet.
>> >> >
>> >> >I actually meant to ask you about this. The -system-controller
>> >> >compatible matches the datasheet better. Maybe we should just
>> >> >switch to that one?
>> >>
>> >> No, if we do the switch the system-controller compatible,
>> >> the device will be probed on the same memory region with
>> >> a syscon on old DTs.
>> >
>> > The device hasn't magically changed either. Maybe we just need to add
>> > a check to make sure we don't have the syscon compatible in the SRAM
>> > driver probe so that the double driver issue doesn't happen?
>>
>> The syscon interface (which is not even a full blown device driver)
>> only looks at the "syscon" compatible. Either way we're removing that
>> part from the device tree so things should be ok for new device trees.
>> As Maxime mentioned we can do a check for the syscon compatible and
>> either give a warning to the user asking them to update their device
>> tree, or not register our custom regmap, or not probe the SRAM driver.
>> Personally I prefer the first option. The system controller block is
>> probed before any syscon users, so we should be fine, given the dwmac
>> driver goes the custom regmap path first.
>>
>> BTW, I still might end up changing the compatible. The manual uses
>> "system control", not "system controller", which I think makes sense,
>> since it is just a bunch of register files, kind of like the GRF
>> (General Register Files) block found in Rockchip SoCs [1], and not an
>> actual "controller".
>
> I'm not really fond of that, but we should at least make it consistent
> on the other patches Paul sent then.

For the A10s / A13 right?

I think my naming is slightly better, but it's just a minor detail.
While we're still debating this, can I merge the R40 stuff first?
The driver bits are already in.

Thanks
ChenYu

^ permalink raw reply	[flat|nested] 80+ messages in thread
* [PATCH net-next v2 15/15] arm64: dts: allwinner: a64: add SRAM controller device tree node
@ 2018-05-16  6:47                 ` Chen-Yu Tsai
  0 siblings, 0 replies; 80+ messages in thread
From: Chen-Yu Tsai @ 2018-05-16  6:47 UTC (permalink / raw)
  To: linux-arm-kernel

On Mon, May 14, 2018 at 1:03 AM, Maxime Ripard
<maxime.ripard@bootlin.com> wrote:
> 1;5201;0c
> On Sun, May 13, 2018 at 12:37:49PM -0700, Chen-Yu Tsai wrote:
>> On Wed, May 2, 2018 at 4:54 AM, Maxime Ripard <maxime.ripard@bootlin.com> wrote:
>> > On Wed, May 02, 2018 at 06:19:51PM +0800, Icenowy Zheng wrote:
>> >>
>> >>
>> >> ? 2018?5?2? GMT+08:00 ??5:53:21, Chen-Yu Tsai <wens@csie.org> ??:
>> >> >On Wed, May 2, 2018 at 5:51 PM, Maxime Ripard
>> >> ><maxime.ripard@bootlin.com> wrote:
>> >> >> Hi,
>> >> >>
>> >> >> On Wed, May 02, 2018 at 12:12:27AM +0800, Chen-Yu Tsai wrote:
>> >> >>> From: Icenowy Zheng <icenowy@aosc.io>
>> >> >>>
>> >> >>> Allwinner A64 has a SRAM controller, and in the device tree
>> >> >currently
>> >> >>> we have a syscon node to enable EMAC driver to access the EMAC clock
>> >> >>> register. As SRAM controller driver can now export regmap for this
>> >> >>> register, replace the syscon node to the SRAM controller device
>> >> >node,
>> >> >>> and let EMAC driver to acquire its EMAC clock regmap.
>> >> >>>
>> >> >>> Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
>> >> >>> Signed-off-by: Chen-Yu Tsai <wens@csie.org>
>> >> >>> ---
>> >> >>>  arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi | 23
>> >> >+++++++++++++++----
>> >> >>>  1 file changed, 19 insertions(+), 4 deletions(-)
>> >> >>>
>> >> >>> diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
>> >> >b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
>> >> >>> index 1b2ef28c42bd..1c37659d9d41 100644
>> >> >>> --- a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
>> >> >>> +++ b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
>> >> >>> @@ -168,10 +168,25 @@
>> >> >>>               #size-cells = <1>;
>> >> >>>               ranges;
>> >> >>>
>> >> >>> -             syscon: syscon at 1c00000 {
>> >> >>> -                     compatible =
>> >> >"allwinner,sun50i-a64-system-controller",
>> >> >>> -                             "syscon";
>> >> >>> +             sram_controller: sram-controller at 1c00000 {
>> >> >>> +                     compatible =
>> >> >"allwinner,sun50i-a64-sram-controller";
>> >> >>
>> >> >> I don't think there's anything preventing us from keeping the
>> >> >> -system-controller compatible. It's what was in the DT before, and
>> >> >> it's how it's called in the datasheet.
>> >> >
>> >> >I actually meant to ask you about this. The -system-controller
>> >> >compatible matches the datasheet better. Maybe we should just
>> >> >switch to that one?
>> >>
>> >> No, if we do the switch the system-controller compatible,
>> >> the device will be probed on the same memory region with
>> >> a syscon on old DTs.
>> >
>> > The device hasn't magically changed either. Maybe we just need to add
>> > a check to make sure we don't have the syscon compatible in the SRAM
>> > driver probe so that the double driver issue doesn't happen?
>>
>> The syscon interface (which is not even a full blown device driver)
>> only looks at the "syscon" compatible. Either way we're removing that
>> part from the device tree so things should be ok for new device trees.
>> As Maxime mentioned we can do a check for the syscon compatible and
>> either give a warning to the user asking them to update their device
>> tree, or not register our custom regmap, or not probe the SRAM driver.
>> Personally I prefer the first option. The system controller block is
>> probed before any syscon users, so we should be fine, given the dwmac
>> driver goes the custom regmap path first.
>>
>> BTW, I still might end up changing the compatible. The manual uses
>> "system control", not "system controller", which I think makes sense,
>> since it is just a bunch of register files, kind of like the GRF
>> (General Register Files) block found in Rockchip SoCs [1], and not an
>> actual "controller".
>
> I'm not really fond of that, but we should at least make it consistent
> on the other patches Paul sent then.

For the A10s / A13 right?

I think my naming is slightly better, but it's just a minor detail.
While we're still debating this, can I merge the R40 stuff first?
The driver bits are already in.

Thanks
ChenYu

^ permalink raw reply	[flat|nested] 80+ messages in thread
* Re: [PATCH net-next v2 15/15] arm64: dts: allwinner: a64: add SRAM controller device tree node
  2018-05-16  6:47                 ` Chen-Yu Tsai
@ 2018-05-16 13:31                   ` Maxime Ripard
  -1 siblings, 0 replies; 80+ messages in thread
From: Maxime Ripard @ 2018-05-16 13:31 UTC (permalink / raw)
  To: Chen-Yu Tsai
  Cc: Icenowy Zheng, linux-arm-kernel, Mark Rutland, devicetree,
	Stephen Boyd, netdev, Michael Turquette, Rob Herring,
	Corentin Labbe, Mark Brown, Giuseppe Cavallaro, linux-clk

[-- Attachment #1: Type: text/plain, Size: 4635 bytes --]

Hi,

On Tue, May 15, 2018 at 11:47:16PM -0700, Chen-Yu Tsai wrote:
> On Mon, May 14, 2018 at 1:03 AM, Maxime Ripard
> <maxime.ripard@bootlin.com> wrote:
> > 1;5201;0c
> > On Sun, May 13, 2018 at 12:37:49PM -0700, Chen-Yu Tsai wrote:
> >> On Wed, May 2, 2018 at 4:54 AM, Maxime Ripard <maxime.ripard@bootlin.com> wrote:
> >> > On Wed, May 02, 2018 at 06:19:51PM +0800, Icenowy Zheng wrote:
> >> >>
> >> >>
> >> >> 于 2018年5月2日 GMT+08:00 下午5:53:21, Chen-Yu Tsai <wens@csie.org> 写到:
> >> >> >On Wed, May 2, 2018 at 5:51 PM, Maxime Ripard
> >> >> ><maxime.ripard@bootlin.com> wrote:
> >> >> >> Hi,
> >> >> >>
> >> >> >> On Wed, May 02, 2018 at 12:12:27AM +0800, Chen-Yu Tsai wrote:
> >> >> >>> From: Icenowy Zheng <icenowy@aosc.io>
> >> >> >>>
> >> >> >>> Allwinner A64 has a SRAM controller, and in the device tree
> >> >> >currently
> >> >> >>> we have a syscon node to enable EMAC driver to access the EMAC clock
> >> >> >>> register. As SRAM controller driver can now export regmap for this
> >> >> >>> register, replace the syscon node to the SRAM controller device
> >> >> >node,
> >> >> >>> and let EMAC driver to acquire its EMAC clock regmap.
> >> >> >>>
> >> >> >>> Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
> >> >> >>> Signed-off-by: Chen-Yu Tsai <wens@csie.org>
> >> >> >>> ---
> >> >> >>>  arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi | 23
> >> >> >+++++++++++++++----
> >> >> >>>  1 file changed, 19 insertions(+), 4 deletions(-)
> >> >> >>>
> >> >> >>> diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
> >> >> >b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
> >> >> >>> index 1b2ef28c42bd..1c37659d9d41 100644
> >> >> >>> --- a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
> >> >> >>> +++ b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
> >> >> >>> @@ -168,10 +168,25 @@
> >> >> >>>               #size-cells = <1>;
> >> >> >>>               ranges;
> >> >> >>>
> >> >> >>> -             syscon: syscon@1c00000 {
> >> >> >>> -                     compatible =
> >> >> >"allwinner,sun50i-a64-system-controller",
> >> >> >>> -                             "syscon";
> >> >> >>> +             sram_controller: sram-controller@1c00000 {
> >> >> >>> +                     compatible =
> >> >> >"allwinner,sun50i-a64-sram-controller";
> >> >> >>
> >> >> >> I don't think there's anything preventing us from keeping the
> >> >> >> -system-controller compatible. It's what was in the DT before, and
> >> >> >> it's how it's called in the datasheet.
> >> >> >
> >> >> >I actually meant to ask you about this. The -system-controller
> >> >> >compatible matches the datasheet better. Maybe we should just
> >> >> >switch to that one?
> >> >>
> >> >> No, if we do the switch the system-controller compatible,
> >> >> the device will be probed on the same memory region with
> >> >> a syscon on old DTs.
> >> >
> >> > The device hasn't magically changed either. Maybe we just need to add
> >> > a check to make sure we don't have the syscon compatible in the SRAM
> >> > driver probe so that the double driver issue doesn't happen?
> >>
> >> The syscon interface (which is not even a full blown device driver)
> >> only looks at the "syscon" compatible. Either way we're removing that
> >> part from the device tree so things should be ok for new device trees.
> >> As Maxime mentioned we can do a check for the syscon compatible and
> >> either give a warning to the user asking them to update their device
> >> tree, or not register our custom regmap, or not probe the SRAM driver.
> >> Personally I prefer the first option. The system controller block is
> >> probed before any syscon users, so we should be fine, given the dwmac
> >> driver goes the custom regmap path first.
> >>
> >> BTW, I still might end up changing the compatible. The manual uses
> >> "system control", not "system controller", which I think makes sense,
> >> since it is just a bunch of register files, kind of like the GRF
> >> (General Register Files) block found in Rockchip SoCs [1], and not an
> >> actual "controller".
> >
> > I'm not really fond of that, but we should at least make it consistent
> > on the other patches Paul sent then.
> 
> For the A10s / A13 right?

And A33, yep.

> I think my naming is slightly better, but it's just a minor detail.

Let's do this then.

> While we're still debating this, can I merge the R40 stuff first?
> The driver bits are already in.

Yep, go ahead.

Maxime

-- 
Maxime Ripard, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

^ permalink raw reply	[flat|nested] 80+ messages in thread
* [PATCH net-next v2 15/15] arm64: dts: allwinner: a64: add SRAM controller device tree node
@ 2018-05-16 13:31                   ` Maxime Ripard
  0 siblings, 0 replies; 80+ messages in thread
From: Maxime Ripard @ 2018-05-16 13:31 UTC (permalink / raw)
  To: linux-arm-kernel

Hi,

On Tue, May 15, 2018 at 11:47:16PM -0700, Chen-Yu Tsai wrote:
> On Mon, May 14, 2018 at 1:03 AM, Maxime Ripard
> <maxime.ripard@bootlin.com> wrote:
> > 1;5201;0c
> > On Sun, May 13, 2018 at 12:37:49PM -0700, Chen-Yu Tsai wrote:
> >> On Wed, May 2, 2018 at 4:54 AM, Maxime Ripard <maxime.ripard@bootlin.com> wrote:
> >> > On Wed, May 02, 2018 at 06:19:51PM +0800, Icenowy Zheng wrote:
> >> >>
> >> >>
> >> >> ? 2018?5?2? GMT+08:00 ??5:53:21, Chen-Yu Tsai <wens@csie.org> ??:
> >> >> >On Wed, May 2, 2018 at 5:51 PM, Maxime Ripard
> >> >> ><maxime.ripard@bootlin.com> wrote:
> >> >> >> Hi,
> >> >> >>
> >> >> >> On Wed, May 02, 2018 at 12:12:27AM +0800, Chen-Yu Tsai wrote:
> >> >> >>> From: Icenowy Zheng <icenowy@aosc.io>
> >> >> >>>
> >> >> >>> Allwinner A64 has a SRAM controller, and in the device tree
> >> >> >currently
> >> >> >>> we have a syscon node to enable EMAC driver to access the EMAC clock
> >> >> >>> register. As SRAM controller driver can now export regmap for this
> >> >> >>> register, replace the syscon node to the SRAM controller device
> >> >> >node,
> >> >> >>> and let EMAC driver to acquire its EMAC clock regmap.
> >> >> >>>
> >> >> >>> Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
> >> >> >>> Signed-off-by: Chen-Yu Tsai <wens@csie.org>
> >> >> >>> ---
> >> >> >>>  arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi | 23
> >> >> >+++++++++++++++----
> >> >> >>>  1 file changed, 19 insertions(+), 4 deletions(-)
> >> >> >>>
> >> >> >>> diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
> >> >> >b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
> >> >> >>> index 1b2ef28c42bd..1c37659d9d41 100644
> >> >> >>> --- a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
> >> >> >>> +++ b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
> >> >> >>> @@ -168,10 +168,25 @@
> >> >> >>>               #size-cells = <1>;
> >> >> >>>               ranges;
> >> >> >>>
> >> >> >>> -             syscon: syscon at 1c00000 {
> >> >> >>> -                     compatible =
> >> >> >"allwinner,sun50i-a64-system-controller",
> >> >> >>> -                             "syscon";
> >> >> >>> +             sram_controller: sram-controller at 1c00000 {
> >> >> >>> +                     compatible =
> >> >> >"allwinner,sun50i-a64-sram-controller";
> >> >> >>
> >> >> >> I don't think there's anything preventing us from keeping the
> >> >> >> -system-controller compatible. It's what was in the DT before, and
> >> >> >> it's how it's called in the datasheet.
> >> >> >
> >> >> >I actually meant to ask you about this. The -system-controller
> >> >> >compatible matches the datasheet better. Maybe we should just
> >> >> >switch to that one?
> >> >>
> >> >> No, if we do the switch the system-controller compatible,
> >> >> the device will be probed on the same memory region with
> >> >> a syscon on old DTs.
> >> >
> >> > The device hasn't magically changed either. Maybe we just need to add
> >> > a check to make sure we don't have the syscon compatible in the SRAM
> >> > driver probe so that the double driver issue doesn't happen?
> >>
> >> The syscon interface (which is not even a full blown device driver)
> >> only looks at the "syscon" compatible. Either way we're removing that
> >> part from the device tree so things should be ok for new device trees.
> >> As Maxime mentioned we can do a check for the syscon compatible and
> >> either give a warning to the user asking them to update their device
> >> tree, or not register our custom regmap, or not probe the SRAM driver.
> >> Personally I prefer the first option. The system controller block is
> >> probed before any syscon users, so we should be fine, given the dwmac
> >> driver goes the custom regmap path first.
> >>
> >> BTW, I still might end up changing the compatible. The manual uses
> >> "system control", not "system controller", which I think makes sense,
> >> since it is just a bunch of register files, kind of like the GRF
> >> (General Register Files) block found in Rockchip SoCs [1], and not an
> >> actual "controller".
> >
> > I'm not really fond of that, but we should at least make it consistent
> > on the other patches Paul sent then.
> 
> For the A10s / A13 right?

And A33, yep.

> I think my naming is slightly better, but it's just a minor detail.

Let's do this then.

> While we're still debating this, can I merge the R40 stuff first?
> The driver bits are already in.

Yep, go ahead.

Maxime

-- 
Maxime Ripard, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20180516/7dfafd46/attachment.sig>

^ permalink raw reply	[flat|nested] 80+ messages in thread
end of thread, other threads:[~2018-05-16 13:31 UTC | newest]

Thread overview: 80+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2018-05-01 16:12 [PATCH net-next v2 00/15] ARM: sun8i: r40: Add Ethernet support Chen-Yu Tsai
2018-05-01 16:12 ` Chen-Yu Tsai
2018-05-01 16:12 ` Chen-Yu Tsai
2018-05-01 16:12 ` [PATCH net-next v2 01/15] clk: sunxi-ng: r40: rewrite init code to a platform driver Chen-Yu Tsai
2018-05-01 16:12   ` Chen-Yu Tsai
2018-05-01 16:12   ` Chen-Yu Tsai
2018-05-01 16:12 ` [PATCH net-next v2 02/15] clk: sunxi-ng: r40: export a regmap to access the GMAC register Chen-Yu Tsai
2018-05-01 16:12   ` Chen-Yu Tsai
2018-05-01 16:12   ` Chen-Yu Tsai
2018-05-01 16:12 ` [PATCH net-next v2 03/15] dt-bindings: net: dwmac-sun8i: Clean up clock delay chain descriptions Chen-Yu Tsai
2018-05-01 16:12   ` Chen-Yu Tsai
2018-05-01 16:12   ` Chen-Yu Tsai
2018-05-01 16:26   ` Rob Herring
2018-05-01 16:26     ` Rob Herring
2018-05-01 16:12 ` [PATCH net-next v2 04/15] dt-bindings: net: dwmac-sun8i: Sort syscon compatibles by alphabetical order Chen-Yu Tsai
2018-05-01 16:12   ` Chen-Yu Tsai
2018-05-01 16:12   ` Chen-Yu Tsai
2018-05-01 16:12 ` [PATCH net-next v2 05/15] dt-bindings: net: dwmac-sun8i: simplify description of syscon property Chen-Yu Tsai
2018-05-01 16:12   ` Chen-Yu Tsai
2018-05-01 16:27   ` Rob Herring
2018-05-01 16:27     ` Rob Herring
2018-05-01 16:12 ` [PATCH net-next v2 06/15] dt-bindings: net: dwmac-sun8i: Add binding for GMAC on Allwinner R40 SoC Chen-Yu Tsai
2018-05-01 16:12   ` Chen-Yu Tsai
2018-05-01 16:12   ` Chen-Yu Tsai
2018-05-01 16:28   ` Rob Herring
2018-05-01 16:28     ` Rob Herring
2018-05-01 16:12 ` [PATCH net-next v2 07/15] net: stmmac: dwmac-sun8i: Use regmap_field for syscon register access Chen-Yu Tsai
2018-05-01 16:12   ` Chen-Yu Tsai
2018-05-01 16:12 ` [PATCH net-next v2 08/15] net: stmmac: dwmac-sun8i: Allow getting syscon regmap from external device Chen-Yu Tsai
2018-05-01 16:12   ` Chen-Yu Tsai
2018-05-01 16:12 ` [PATCH net-next v2 09/15] net: stmmac: dwmac-sun8i: Support different ranges for TX/RX delay chains Chen-Yu Tsai
2018-05-01 16:12   ` Chen-Yu Tsai
2018-05-01 16:12 ` [PATCH net-next v2 10/15] net: stmmac: dwmac-sun8i: Add support for GMAC on Allwinner R40 SoC Chen-Yu Tsai
2018-05-01 16:12   ` Chen-Yu Tsai
2018-05-01 16:12   ` Chen-Yu Tsai
2018-05-01 16:12 ` [PATCH net-next v2 11/15] ARM: dts: sun8i: r40: bananapi-m2-ultra: Sort device node dereferences Chen-Yu Tsai
2018-05-01 16:12   ` Chen-Yu Tsai
2018-05-01 16:12   ` Chen-Yu Tsai
2018-05-01 16:12 ` [PATCH net-next v2 12/15] ARM: dts: sun8i: r40: Add device node and RGMII pinmux node for GMAC Chen-Yu Tsai
2018-05-01 16:12   ` Chen-Yu Tsai
2018-05-01 16:12   ` Chen-Yu Tsai
2018-05-01 16:12 ` [PATCH net-next v2 13/15] ARM: dts: sun8i: r40: bananapi-m2-ultra: Enable GMAC ethernet controller Chen-Yu Tsai
2018-05-01 16:12   ` Chen-Yu Tsai
2018-05-01 16:12   ` Chen-Yu Tsai
2018-05-01 16:12 ` [PATCH net-next v2 14/15] soc: sunxi: export a regmap for EMAC clock reg on A64 Chen-Yu Tsai
2018-05-01 16:12   ` Chen-Yu Tsai
2018-05-01 16:12   ` Chen-Yu Tsai
2018-05-01 16:12 ` [PATCH net-next v2 15/15] arm64: dts: allwinner: a64: add SRAM controller device tree node Chen-Yu Tsai
2018-05-01 16:12   ` Chen-Yu Tsai
2018-05-02  9:51   ` Maxime Ripard
2018-05-02  9:51     ` Maxime Ripard
2018-05-02  9:53     ` Chen-Yu Tsai
2018-05-02  9:53       ` Chen-Yu Tsai
2018-05-02 10:19       ` Icenowy Zheng
2018-05-02 10:19         ` Icenowy Zheng
2018-05-02 10:19         ` Icenowy Zheng
2018-05-02 11:54         ` Maxime Ripard
2018-05-02 11:54           ` Maxime Ripard
2018-05-13 19:37           ` Chen-Yu Tsai
2018-05-13 19:37             ` Chen-Yu Tsai
2018-05-13 19:37             ` Chen-Yu Tsai
2018-05-14  8:03             ` Maxime Ripard
2018-05-14  8:03               ` Maxime Ripard
2018-05-16  6:47               ` Chen-Yu Tsai
2018-05-16  6:47                 ` Chen-Yu Tsai
2018-05-16  6:47                 ` Chen-Yu Tsai
2018-05-16 13:31                 ` Maxime Ripard
2018-05-16 13:31                   ` Maxime Ripard
2018-05-01 16:33 ` [PATCH net-next v2 00/15] ARM: sun8i: r40: Add Ethernet support Chen-Yu Tsai
2018-05-01 16:33   ` Chen-Yu Tsai
2018-05-02 15:06   ` David Miller
2018-05-02 15:06     ` David Miller
2018-05-03 13:12     ` Maxime Ripard
2018-05-03 13:12       ` Maxime Ripard
2018-05-03 18:40       ` David Miller
2018-05-03 18:40         ` David Miller
2018-05-04 15:03         ` Maxime Ripard
2018-05-04 15:03           ` Maxime Ripard
2018-05-02 15:04 ` David Miller
2018-05-02 15:04   ` David Miller

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