[PATCH v2 1/3] clk: bcm2835: Add bindings for the auxiliary peripheral clock gates.

[PATCH v2 1/3] clk: bcm2835: Add bindings for the auxiliary peripheral clock gates.

[Eric Anholt]

These will be used for enabling UART1, SPI1, and SPI2.

Signed-off-by: Eric Anholt <eric@anholt.net>
---

v2: Make the binding cover both the IRQ and clock enable registers.

 .../bindings/clock/brcm,bcm2835-aux-clock.txt      | 31 ++++++++++++++++++++++
 include/dt-bindings/clock/bcm2835-aux.h            | 17 ++++++++++++
 2 files changed, 48 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/clock/brcm,bcm2835-aux-clock.txt
 create mode 100644 include/dt-bindings/clock/bcm2835-aux.h

diff --git a/Documentation/devicetree/bindings/clock/brcm,bcm2835-aux-clock.txt b/Documentation/devicetree/bindings/clock/brcm,bcm2835-aux-clock.txt
new file mode 100644
index 0000000..7a837d2
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/brcm,bcm2835-aux-clock.txt
@@ -0,0 +1,31 @@
+Broadcom BCM2835 auxiliary peripheral support
+
+This binding uses the common clock binding:
+    Documentation/devicetree/bindings/clock/clock-bindings.txt
+
+The auxiliary peripherals (UART, SPI1, and SPI2) have a small register
+area controlling clock gating to the peripherals, and providing an IRQ
+status register.
+
+Required properties:
+- compatible:	Should be "brcm,bcm2835-aux"
+- #clock-cells:	Should be <1>. The permitted clock-specifier values can be
+		  found in include/dt-bindings/clock/bcm2835-aux.h
+- reg:		Specifies base physical address and size of the registers
+- clocks:	The parent clock phandle
+
+Example:
+
+	clocks: cprman@7e101000 {
+		compatible = "brcm,bcm2835-cprman";
+		#clock-cells = <1>;
+		reg = <0x7e101000 0x2000>;
+		clocks = <&clk_osc>;
+	};
+
+	aux: aux@0x7e215004 {
+		compatible = "brcm,bcm2835-aux";
+		#clock-cells = <1>;
+		reg = <0x7e215000 0x8>;
+		clocks = <&clocks BCM2835_CLOCK_VPU>;
+	};
diff --git a/include/dt-bindings/clock/bcm2835-aux.h b/include/dt-bindings/clock/bcm2835-aux.h
new file mode 100644
index 0000000..d91156e
--- /dev/null
+++ b/include/dt-bindings/clock/bcm2835-aux.h
@@ -0,0 +1,17 @@
+/*
+ * Copyright (C) 2015 Broadcom Corporation
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation version 2.
+ *
+ * This program is distributed "as is" WITHOUT ANY WARRANTY of any
+ * kind, whether express or implied; without even the implied warranty
+ * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#define BCM2835_AUX_CLOCK_UART		0
+#define BCM2835_AUX_CLOCK_SPI1		1
+#define BCM2835_AUX_CLOCK_SPI2		2
+#define BCM2835_AUX_CLOCK_COUNT		3
-- 
2.6.2

[PATCH v2 1/3] clk: bcm2835: Add bindings for the auxiliary peripheral clock gates.

[Eric Anholt]

These will be used for enabling UART1, SPI1, and SPI2.

Signed-off-by: Eric Anholt <eric@anholt.net>
---

v2: Make the binding cover both the IRQ and clock enable registers.

 .../bindings/clock/brcm,bcm2835-aux-clock.txt      | 31 ++++++++++++++++++++++
 include/dt-bindings/clock/bcm2835-aux.h            | 17 ++++++++++++
 2 files changed, 48 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/clock/brcm,bcm2835-aux-clock.txt
 create mode 100644 include/dt-bindings/clock/bcm2835-aux.h

diff --git a/Documentation/devicetree/bindings/clock/brcm,bcm2835-aux-clock.txt b/Documentation/devicetree/bindings/clock/brcm,bcm2835-aux-clock.txt
new file mode 100644
index 0000000..7a837d2
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/brcm,bcm2835-aux-clock.txt
@@ -0,0 +1,31 @@
+Broadcom BCM2835 auxiliary peripheral support
+
+This binding uses the common clock binding:
+    Documentation/devicetree/bindings/clock/clock-bindings.txt
+
+The auxiliary peripherals (UART, SPI1, and SPI2) have a small register
+area controlling clock gating to the peripherals, and providing an IRQ
+status register.
+
+Required properties:
+- compatible:	Should be "brcm,bcm2835-aux"
+- #clock-cells:	Should be <1>. The permitted clock-specifier values can be
+		  found in include/dt-bindings/clock/bcm2835-aux.h
+- reg:		Specifies base physical address and size of the registers
+- clocks:	The parent clock phandle
+
+Example:
+
+	clocks: cprman at 7e101000 {
+		compatible = "brcm,bcm2835-cprman";
+		#clock-cells = <1>;
+		reg = <0x7e101000 0x2000>;
+		clocks = <&clk_osc>;
+	};
+
+	aux: aux at 0x7e215004 {
+		compatible = "brcm,bcm2835-aux";
+		#clock-cells = <1>;
+		reg = <0x7e215000 0x8>;
+		clocks = <&clocks BCM2835_CLOCK_VPU>;
+	};
diff --git a/include/dt-bindings/clock/bcm2835-aux.h b/include/dt-bindings/clock/bcm2835-aux.h
new file mode 100644
index 0000000..d91156e
--- /dev/null
+++ b/include/dt-bindings/clock/bcm2835-aux.h
@@ -0,0 +1,17 @@
+/*
+ * Copyright (C) 2015 Broadcom Corporation
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation version 2.
+ *
+ * This program is distributed "as is" WITHOUT ANY WARRANTY of any
+ * kind, whether express or implied; without even the implied warranty
+ * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#define BCM2835_AUX_CLOCK_UART		0
+#define BCM2835_AUX_CLOCK_SPI1		1
+#define BCM2835_AUX_CLOCK_SPI2		2
+#define BCM2835_AUX_CLOCK_COUNT		3
-- 
2.6.2

[PATCH v2 2/3] clk: bcm2835: Add a driver for the auxiliary peripheral clock gates.

[Eric Anholt]

There are a pair of SPI masters and a mini UART that were last minute
additions.  As a result, they didn't get integrated in the same way as
the other gates off of the VPU clock in CPRMAN.

Signed-off-by: Eric Anholt <eric@anholt.net>
---

v2: Make the binding cover both the IRQ and clock enable registers.
    Use devm_ allocation, ioremap, and and clock get functions.  Don't
    return the error from of_clk_add_provider(), since that would
    leave the clocks registered, but their registers unmapped.  Trim
    includes.

 drivers/clk/bcm/Makefile          |  1 +
 drivers/clk/bcm/clk-bcm2835-aux.c | 85 +++++++++++++++++++++++++++++++++++++++
 2 files changed, 86 insertions(+)
 create mode 100644 drivers/clk/bcm/clk-bcm2835-aux.c

diff --git a/drivers/clk/bcm/Makefile b/drivers/clk/bcm/Makefile
index 3fc9506..183484c 100644
--- a/drivers/clk/bcm/Makefile
+++ b/drivers/clk/bcm/Makefile
@@ -4,6 +4,7 @@ obj-$(CONFIG_CLK_BCM_KONA)	+= clk-bcm281xx.o
 obj-$(CONFIG_CLK_BCM_KONA)	+= clk-bcm21664.o
 obj-$(CONFIG_COMMON_CLK_IPROC)	+= clk-iproc-armpll.o clk-iproc-pll.o clk-iproc-asiu.o
 obj-$(CONFIG_ARCH_BCM2835)	+= clk-bcm2835.o
+obj-$(CONFIG_ARCH_BCM2835)	+= clk-bcm2835-aux.o
 obj-$(CONFIG_COMMON_CLK_IPROC)	+= clk-ns2.o
 obj-$(CONFIG_ARCH_BCM_CYGNUS)	+= clk-cygnus.o
 obj-$(CONFIG_ARCH_BCM_NSP)	+= clk-nsp.o
diff --git a/drivers/clk/bcm/clk-bcm2835-aux.c b/drivers/clk/bcm/clk-bcm2835-aux.c
new file mode 100644
index 0000000..e4f89e2
--- /dev/null
+++ b/drivers/clk/bcm/clk-bcm2835-aux.c
@@ -0,0 +1,85 @@
+/*
+ * Copyright (C) 2015 Broadcom
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include <linux/clk.h>
+#include <linux/clk-provider.h>
+#include <linux/clk/bcm2835.h>
+#include <linux/module.h>
+#include <linux/platform_device.h>
+#include <dt-bindings/clock/bcm2835-aux.h>
+
+#define BCM2835_AUXIRQ		0x00
+#define BCM2835_AUXENB		0x04
+
+static int bcm2835_aux_clk_probe(struct platform_device *pdev)
+{
+	struct device *dev = &pdev->dev;
+	struct clk_onecell_data *onecell;
+	const char *parent;
+	struct clk *parent_clk;
+	struct resource *res;
+	void __iomem *reg, *gate;
+
+	parent_clk = devm_clk_get(dev, NULL);
+	if (IS_ERR(parent_clk))
+		return PTR_ERR(parent_clk);
+	parent = __clk_get_name(parent_clk);
+
+	res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+	reg = devm_ioremap_resource(dev, res);
+	if (!reg)
+		return -ENODEV;
+
+	onecell = devm_kmalloc(dev, sizeof(*onecell), GFP_KERNEL);
+	if (!onecell)
+		return -ENOMEM;
+	onecell->clk_num = BCM2835_AUX_CLOCK_COUNT;
+	onecell->clks = devm_kcalloc(dev, BCM2835_AUX_CLOCK_COUNT,
+				     sizeof(*onecell->clks), GFP_KERNEL);
+	if (!onecell->clks)
+		return -ENOMEM;
+
+	gate = reg + BCM2835_AUXENB;
+	onecell->clks[BCM2835_AUX_CLOCK_UART] =
+		clk_register_gate(dev, "aux_uart", parent, 0, gate, 0, 0, NULL);
+
+	onecell->clks[BCM2835_AUX_CLOCK_SPI1] =
+		clk_register_gate(dev, "aux_spi1", parent, 0, gate, 1, 0, NULL);
+
+	onecell->clks[BCM2835_AUX_CLOCK_SPI2] =
+		clk_register_gate(dev, "aux_spi2", parent, 0, gate, 2, 0, NULL);
+
+	of_clk_add_provider(pdev->dev.of_node, of_clk_src_onecell_get, onecell);
+
+	return 0;
+}
+
+static const struct of_device_id bcm2835_aux_clk_of_match[] = {
+	{ .compatible = "brcm,bcm2835-aux", },
+	{},
+};
+MODULE_DEVICE_TABLE(of, bcm2835_aux_clk_of_match);
+
+static struct platform_driver bcm2835_aux_clk_driver = {
+	.driver = {
+		.name = "bcm2835-aux-clk",
+		.of_match_table = bcm2835_aux_clk_of_match,
+	},
+	.probe          = bcm2835_aux_clk_probe,
+};
+builtin_platform_driver(bcm2835_aux_clk_driver);
+
+MODULE_AUTHOR("Eric Anholt <eric@anholt.net>");
+MODULE_DESCRIPTION("BCM2835 auxiliary peripheral clock driver");
+MODULE_LICENSE("GPL v2");
-- 
2.6.2

[PATCH v2 2/3] clk: bcm2835: Add a driver for the auxiliary peripheral clock gates.

[Eric Anholt]

There are a pair of SPI masters and a mini UART that were last minute
additions.  As a result, they didn't get integrated in the same way as
the other gates off of the VPU clock in CPRMAN.

Signed-off-by: Eric Anholt <eric@anholt.net>
---

v2: Make the binding cover both the IRQ and clock enable registers.
    Use devm_ allocation, ioremap, and and clock get functions.  Don't
    return the error from of_clk_add_provider(), since that would
    leave the clocks registered, but their registers unmapped.  Trim
    includes.

 drivers/clk/bcm/Makefile          |  1 +
 drivers/clk/bcm/clk-bcm2835-aux.c | 85 +++++++++++++++++++++++++++++++++++++++
 2 files changed, 86 insertions(+)
 create mode 100644 drivers/clk/bcm/clk-bcm2835-aux.c

diff --git a/drivers/clk/bcm/Makefile b/drivers/clk/bcm/Makefile
index 3fc9506..183484c 100644
--- a/drivers/clk/bcm/Makefile
+++ b/drivers/clk/bcm/Makefile
@@ -4,6 +4,7 @@ obj-$(CONFIG_CLK_BCM_KONA)	+= clk-bcm281xx.o
 obj-$(CONFIG_CLK_BCM_KONA)	+= clk-bcm21664.o
 obj-$(CONFIG_COMMON_CLK_IPROC)	+= clk-iproc-armpll.o clk-iproc-pll.o clk-iproc-asiu.o
 obj-$(CONFIG_ARCH_BCM2835)	+= clk-bcm2835.o
+obj-$(CONFIG_ARCH_BCM2835)	+= clk-bcm2835-aux.o
 obj-$(CONFIG_COMMON_CLK_IPROC)	+= clk-ns2.o
 obj-$(CONFIG_ARCH_BCM_CYGNUS)	+= clk-cygnus.o
 obj-$(CONFIG_ARCH_BCM_NSP)	+= clk-nsp.o
diff --git a/drivers/clk/bcm/clk-bcm2835-aux.c b/drivers/clk/bcm/clk-bcm2835-aux.c
new file mode 100644
index 0000000..e4f89e2
--- /dev/null
+++ b/drivers/clk/bcm/clk-bcm2835-aux.c
@@ -0,0 +1,85 @@
+/*
+ * Copyright (C) 2015 Broadcom
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include <linux/clk.h>
+#include <linux/clk-provider.h>
+#include <linux/clk/bcm2835.h>
+#include <linux/module.h>
+#include <linux/platform_device.h>
+#include <dt-bindings/clock/bcm2835-aux.h>
+
+#define BCM2835_AUXIRQ		0x00
+#define BCM2835_AUXENB		0x04
+
+static int bcm2835_aux_clk_probe(struct platform_device *pdev)
+{
+	struct device *dev = &pdev->dev;
+	struct clk_onecell_data *onecell;
+	const char *parent;
+	struct clk *parent_clk;
+	struct resource *res;
+	void __iomem *reg, *gate;
+
+	parent_clk = devm_clk_get(dev, NULL);
+	if (IS_ERR(parent_clk))
+		return PTR_ERR(parent_clk);
+	parent = __clk_get_name(parent_clk);
+
+	res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+	reg = devm_ioremap_resource(dev, res);
+	if (!reg)
+		return -ENODEV;
+
+	onecell = devm_kmalloc(dev, sizeof(*onecell), GFP_KERNEL);
+	if (!onecell)
+		return -ENOMEM;
+	onecell->clk_num = BCM2835_AUX_CLOCK_COUNT;
+	onecell->clks = devm_kcalloc(dev, BCM2835_AUX_CLOCK_COUNT,
+				     sizeof(*onecell->clks), GFP_KERNEL);
+	if (!onecell->clks)
+		return -ENOMEM;
+
+	gate = reg + BCM2835_AUXENB;
+	onecell->clks[BCM2835_AUX_CLOCK_UART] =
+		clk_register_gate(dev, "aux_uart", parent, 0, gate, 0, 0, NULL);
+
+	onecell->clks[BCM2835_AUX_CLOCK_SPI1] =
+		clk_register_gate(dev, "aux_spi1", parent, 0, gate, 1, 0, NULL);
+
+	onecell->clks[BCM2835_AUX_CLOCK_SPI2] =
+		clk_register_gate(dev, "aux_spi2", parent, 0, gate, 2, 0, NULL);
+
+	of_clk_add_provider(pdev->dev.of_node, of_clk_src_onecell_get, onecell);
+
+	return 0;
+}
+
+static const struct of_device_id bcm2835_aux_clk_of_match[] = {
+	{ .compatible = "brcm,bcm2835-aux", },
+	{},
+};
+MODULE_DEVICE_TABLE(of, bcm2835_aux_clk_of_match);
+
+static struct platform_driver bcm2835_aux_clk_driver = {
+	.driver = {
+		.name = "bcm2835-aux-clk",
+		.of_match_table = bcm2835_aux_clk_of_match,
+	},
+	.probe          = bcm2835_aux_clk_probe,
+};
+builtin_platform_driver(bcm2835_aux_clk_driver);
+
+MODULE_AUTHOR("Eric Anholt <eric@anholt.net>");
+MODULE_DESCRIPTION("BCM2835 auxiliary peripheral clock driver");
+MODULE_LICENSE("GPL v2");
-- 
2.6.2

Re: [PATCH v2 2/3] clk: bcm2835: Add a driver for the auxiliary peripheral clock gates.

[Michael Turquette]

On Tue, Dec 15, 2015 at 3:35 PM, Eric Anholt <eric@anholt.net> wrote:
> There are a pair of SPI masters and a mini UART that were last minute
> additions.  As a result, they didn't get integrated in the same way as
> the other gates off of the VPU clock in CPRMAN.
>
> Signed-off-by: Eric Anholt <eric@anholt.net>

Applied to clk-next.

Regards,
Mike

> ---
>
> v2: Make the binding cover both the IRQ and clock enable registers.
>     Use devm_ allocation, ioremap, and and clock get functions.  Don't
>     return the error from of_clk_add_provider(), since that would
>     leave the clocks registered, but their registers unmapped.  Trim
>     includes.
>
>  drivers/clk/bcm/Makefile          |  1 +
>  drivers/clk/bcm/clk-bcm2835-aux.c | 85 +++++++++++++++++++++++++++++++++++++++
>  2 files changed, 86 insertions(+)
>  create mode 100644 drivers/clk/bcm/clk-bcm2835-aux.c
>
> diff --git a/drivers/clk/bcm/Makefile b/drivers/clk/bcm/Makefile
> index 3fc9506..183484c 100644
> --- a/drivers/clk/bcm/Makefile
> +++ b/drivers/clk/bcm/Makefile
> @@ -4,6 +4,7 @@ obj-$(CONFIG_CLK_BCM_KONA)      += clk-bcm281xx.o
>  obj-$(CONFIG_CLK_BCM_KONA)     += clk-bcm21664.o
>  obj-$(CONFIG_COMMON_CLK_IPROC) += clk-iproc-armpll.o clk-iproc-pll.o clk-iproc-asiu.o
>  obj-$(CONFIG_ARCH_BCM2835)     += clk-bcm2835.o
> +obj-$(CONFIG_ARCH_BCM2835)     += clk-bcm2835-aux.o
>  obj-$(CONFIG_COMMON_CLK_IPROC) += clk-ns2.o
>  obj-$(CONFIG_ARCH_BCM_CYGNUS)  += clk-cygnus.o
>  obj-$(CONFIG_ARCH_BCM_NSP)     += clk-nsp.o
> diff --git a/drivers/clk/bcm/clk-bcm2835-aux.c b/drivers/clk/bcm/clk-bcm2835-aux.c
> new file mode 100644
> index 0000000..e4f89e2
> --- /dev/null
> +++ b/drivers/clk/bcm/clk-bcm2835-aux.c
> @@ -0,0 +1,85 @@
> +/*
> + * Copyright (C) 2015 Broadcom
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; either version 2 of the License, or
> + * (at your option) any later version.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + */
> +
> +#include <linux/clk.h>
> +#include <linux/clk-provider.h>
> +#include <linux/clk/bcm2835.h>
> +#include <linux/module.h>
> +#include <linux/platform_device.h>
> +#include <dt-bindings/clock/bcm2835-aux.h>
> +
> +#define BCM2835_AUXIRQ         0x00
> +#define BCM2835_AUXENB         0x04
> +
> +static int bcm2835_aux_clk_probe(struct platform_device *pdev)
> +{
> +       struct device *dev = &pdev->dev;
> +       struct clk_onecell_data *onecell;
> +       const char *parent;
> +       struct clk *parent_clk;
> +       struct resource *res;
> +       void __iomem *reg, *gate;
> +
> +       parent_clk = devm_clk_get(dev, NULL);
> +       if (IS_ERR(parent_clk))
> +               return PTR_ERR(parent_clk);
> +       parent = __clk_get_name(parent_clk);
> +
> +       res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> +       reg = devm_ioremap_resource(dev, res);
> +       if (!reg)
> +               return -ENODEV;
> +
> +       onecell = devm_kmalloc(dev, sizeof(*onecell), GFP_KERNEL);
> +       if (!onecell)
> +               return -ENOMEM;
> +       onecell->clk_num = BCM2835_AUX_CLOCK_COUNT;
> +       onecell->clks = devm_kcalloc(dev, BCM2835_AUX_CLOCK_COUNT,
> +                                    sizeof(*onecell->clks), GFP_KERNEL);
> +       if (!onecell->clks)
> +               return -ENOMEM;
> +
> +       gate = reg + BCM2835_AUXENB;
> +       onecell->clks[BCM2835_AUX_CLOCK_UART] =
> +               clk_register_gate(dev, "aux_uart", parent, 0, gate, 0, 0, NULL);
> +
> +       onecell->clks[BCM2835_AUX_CLOCK_SPI1] =
> +               clk_register_gate(dev, "aux_spi1", parent, 0, gate, 1, 0, NULL);
> +
> +       onecell->clks[BCM2835_AUX_CLOCK_SPI2] =
> +               clk_register_gate(dev, "aux_spi2", parent, 0, gate, 2, 0, NULL);
> +
> +       of_clk_add_provider(pdev->dev.of_node, of_clk_src_onecell_get, onecell);
> +
> +       return 0;
> +}
> +
> +static const struct of_device_id bcm2835_aux_clk_of_match[] = {
> +       { .compatible = "brcm,bcm2835-aux", },
> +       {},
> +};
> +MODULE_DEVICE_TABLE(of, bcm2835_aux_clk_of_match);
> +
> +static struct platform_driver bcm2835_aux_clk_driver = {
> +       .driver = {
> +               .name = "bcm2835-aux-clk",
> +               .of_match_table = bcm2835_aux_clk_of_match,
> +       },
> +       .probe          = bcm2835_aux_clk_probe,
> +};
> +builtin_platform_driver(bcm2835_aux_clk_driver);
> +
> +MODULE_AUTHOR("Eric Anholt <eric@anholt.net>");
> +MODULE_DESCRIPTION("BCM2835 auxiliary peripheral clock driver");
> +MODULE_LICENSE("GPL v2");
> --
> 2.6.2
>



-- 
Michael Turquette
CEO
BayLibre - At the Heart of Embedded Linux
http://baylibre.com/

[PATCH v2 2/3] clk: bcm2835: Add a driver for the auxiliary peripheral clock gates.

[Michael Turquette]

On Tue, Dec 15, 2015 at 3:35 PM, Eric Anholt <eric@anholt.net> wrote:
> There are a pair of SPI masters and a mini UART that were last minute
> additions.  As a result, they didn't get integrated in the same way as
> the other gates off of the VPU clock in CPRMAN.
>
> Signed-off-by: Eric Anholt <eric@anholt.net>

Applied to clk-next.

Regards,
Mike

> ---
>
> v2: Make the binding cover both the IRQ and clock enable registers.
>     Use devm_ allocation, ioremap, and and clock get functions.  Don't
>     return the error from of_clk_add_provider(), since that would
>     leave the clocks registered, but their registers unmapped.  Trim
>     includes.
>
>  drivers/clk/bcm/Makefile          |  1 +
>  drivers/clk/bcm/clk-bcm2835-aux.c | 85 +++++++++++++++++++++++++++++++++++++++
>  2 files changed, 86 insertions(+)
>  create mode 100644 drivers/clk/bcm/clk-bcm2835-aux.c
>
> diff --git a/drivers/clk/bcm/Makefile b/drivers/clk/bcm/Makefile
> index 3fc9506..183484c 100644
> --- a/drivers/clk/bcm/Makefile
> +++ b/drivers/clk/bcm/Makefile
> @@ -4,6 +4,7 @@ obj-$(CONFIG_CLK_BCM_KONA)      += clk-bcm281xx.o
>  obj-$(CONFIG_CLK_BCM_KONA)     += clk-bcm21664.o
>  obj-$(CONFIG_COMMON_CLK_IPROC) += clk-iproc-armpll.o clk-iproc-pll.o clk-iproc-asiu.o
>  obj-$(CONFIG_ARCH_BCM2835)     += clk-bcm2835.o
> +obj-$(CONFIG_ARCH_BCM2835)     += clk-bcm2835-aux.o
>  obj-$(CONFIG_COMMON_CLK_IPROC) += clk-ns2.o
>  obj-$(CONFIG_ARCH_BCM_CYGNUS)  += clk-cygnus.o
>  obj-$(CONFIG_ARCH_BCM_NSP)     += clk-nsp.o
> diff --git a/drivers/clk/bcm/clk-bcm2835-aux.c b/drivers/clk/bcm/clk-bcm2835-aux.c
> new file mode 100644
> index 0000000..e4f89e2
> --- /dev/null
> +++ b/drivers/clk/bcm/clk-bcm2835-aux.c
> @@ -0,0 +1,85 @@
> +/*
> + * Copyright (C) 2015 Broadcom
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; either version 2 of the License, or
> + * (at your option) any later version.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + */
> +
> +#include <linux/clk.h>
> +#include <linux/clk-provider.h>
> +#include <linux/clk/bcm2835.h>
> +#include <linux/module.h>
> +#include <linux/platform_device.h>
> +#include <dt-bindings/clock/bcm2835-aux.h>
> +
> +#define BCM2835_AUXIRQ         0x00
> +#define BCM2835_AUXENB         0x04
> +
> +static int bcm2835_aux_clk_probe(struct platform_device *pdev)
> +{
> +       struct device *dev = &pdev->dev;
> +       struct clk_onecell_data *onecell;
> +       const char *parent;
> +       struct clk *parent_clk;
> +       struct resource *res;
> +       void __iomem *reg, *gate;
> +
> +       parent_clk = devm_clk_get(dev, NULL);
> +       if (IS_ERR(parent_clk))
> +               return PTR_ERR(parent_clk);
> +       parent = __clk_get_name(parent_clk);
> +
> +       res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> +       reg = devm_ioremap_resource(dev, res);
> +       if (!reg)
> +               return -ENODEV;
> +
> +       onecell = devm_kmalloc(dev, sizeof(*onecell), GFP_KERNEL);
> +       if (!onecell)
> +               return -ENOMEM;
> +       onecell->clk_num = BCM2835_AUX_CLOCK_COUNT;
> +       onecell->clks = devm_kcalloc(dev, BCM2835_AUX_CLOCK_COUNT,
> +                                    sizeof(*onecell->clks), GFP_KERNEL);
> +       if (!onecell->clks)
> +               return -ENOMEM;
> +
> +       gate = reg + BCM2835_AUXENB;
> +       onecell->clks[BCM2835_AUX_CLOCK_UART] =
> +               clk_register_gate(dev, "aux_uart", parent, 0, gate, 0, 0, NULL);
> +
> +       onecell->clks[BCM2835_AUX_CLOCK_SPI1] =
> +               clk_register_gate(dev, "aux_spi1", parent, 0, gate, 1, 0, NULL);
> +
> +       onecell->clks[BCM2835_AUX_CLOCK_SPI2] =
> +               clk_register_gate(dev, "aux_spi2", parent, 0, gate, 2, 0, NULL);
> +
> +       of_clk_add_provider(pdev->dev.of_node, of_clk_src_onecell_get, onecell);
> +
> +       return 0;
> +}
> +
> +static const struct of_device_id bcm2835_aux_clk_of_match[] = {
> +       { .compatible = "brcm,bcm2835-aux", },
> +       {},
> +};
> +MODULE_DEVICE_TABLE(of, bcm2835_aux_clk_of_match);
> +
> +static struct platform_driver bcm2835_aux_clk_driver = {
> +       .driver = {
> +               .name = "bcm2835-aux-clk",
> +               .of_match_table = bcm2835_aux_clk_of_match,
> +       },
> +       .probe          = bcm2835_aux_clk_probe,
> +};
> +builtin_platform_driver(bcm2835_aux_clk_driver);
> +
> +MODULE_AUTHOR("Eric Anholt <eric@anholt.net>");
> +MODULE_DESCRIPTION("BCM2835 auxiliary peripheral clock driver");
> +MODULE_LICENSE("GPL v2");
> --
> 2.6.2
>



-- 
Michael Turquette
CEO
BayLibre - At the Heart of Embedded Linux
http://baylibre.com/

Re: [PATCH v2 2/3] clk: bcm2835: Add a driver for the auxiliary peripheral clock gates.

[Michael Turquette]

On Tue, Dec 15, 2015 at 3:35 PM, Eric Anholt <eric@anholt.net> wrote:
> There are a pair of SPI masters and a mini UART that were last minute
> additions.  As a result, they didn't get integrated in the same way as
> the other gates off of the VPU clock in CPRMAN.
>
> Signed-off-by: Eric Anholt <eric@anholt.net>

Applied to clk-next.

Regards,
Mike

> ---
>
> v2: Make the binding cover both the IRQ and clock enable registers.
>     Use devm_ allocation, ioremap, and and clock get functions.  Don't
>     return the error from of_clk_add_provider(), since that would
>     leave the clocks registered, but their registers unmapped.  Trim
>     includes.
>
>  drivers/clk/bcm/Makefile          |  1 +
>  drivers/clk/bcm/clk-bcm2835-aux.c | 85 +++++++++++++++++++++++++++++++++++++++
>  2 files changed, 86 insertions(+)
>  create mode 100644 drivers/clk/bcm/clk-bcm2835-aux.c
>
> diff --git a/drivers/clk/bcm/Makefile b/drivers/clk/bcm/Makefile
> index 3fc9506..183484c 100644
> --- a/drivers/clk/bcm/Makefile
> +++ b/drivers/clk/bcm/Makefile
> @@ -4,6 +4,7 @@ obj-$(CONFIG_CLK_BCM_KONA)      += clk-bcm281xx.o
>  obj-$(CONFIG_CLK_BCM_KONA)     += clk-bcm21664.o
>  obj-$(CONFIG_COMMON_CLK_IPROC) += clk-iproc-armpll.o clk-iproc-pll.o clk-iproc-asiu.o
>  obj-$(CONFIG_ARCH_BCM2835)     += clk-bcm2835.o
> +obj-$(CONFIG_ARCH_BCM2835)     += clk-bcm2835-aux.o
>  obj-$(CONFIG_COMMON_CLK_IPROC) += clk-ns2.o
>  obj-$(CONFIG_ARCH_BCM_CYGNUS)  += clk-cygnus.o
>  obj-$(CONFIG_ARCH_BCM_NSP)     += clk-nsp.o
> diff --git a/drivers/clk/bcm/clk-bcm2835-aux.c b/drivers/clk/bcm/clk-bcm2835-aux.c
> new file mode 100644
> index 0000000..e4f89e2
> --- /dev/null
> +++ b/drivers/clk/bcm/clk-bcm2835-aux.c
> @@ -0,0 +1,85 @@
> +/*
> + * Copyright (C) 2015 Broadcom
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; either version 2 of the License, or
> + * (at your option) any later version.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + */
> +
> +#include <linux/clk.h>
> +#include <linux/clk-provider.h>
> +#include <linux/clk/bcm2835.h>
> +#include <linux/module.h>
> +#include <linux/platform_device.h>
> +#include <dt-bindings/clock/bcm2835-aux.h>
> +
> +#define BCM2835_AUXIRQ         0x00
> +#define BCM2835_AUXENB         0x04
> +
> +static int bcm2835_aux_clk_probe(struct platform_device *pdev)
> +{
> +       struct device *dev = &pdev->dev;
> +       struct clk_onecell_data *onecell;
> +       const char *parent;
> +       struct clk *parent_clk;
> +       struct resource *res;
> +       void __iomem *reg, *gate;
> +
> +       parent_clk = devm_clk_get(dev, NULL);
> +       if (IS_ERR(parent_clk))
> +               return PTR_ERR(parent_clk);
> +       parent = __clk_get_name(parent_clk);
> +
> +       res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> +       reg = devm_ioremap_resource(dev, res);
> +       if (!reg)
> +               return -ENODEV;
> +
> +       onecell = devm_kmalloc(dev, sizeof(*onecell), GFP_KERNEL);
> +       if (!onecell)
> +               return -ENOMEM;
> +       onecell->clk_num = BCM2835_AUX_CLOCK_COUNT;
> +       onecell->clks = devm_kcalloc(dev, BCM2835_AUX_CLOCK_COUNT,
> +                                    sizeof(*onecell->clks), GFP_KERNEL);
> +       if (!onecell->clks)
> +               return -ENOMEM;
> +
> +       gate = reg + BCM2835_AUXENB;
> +       onecell->clks[BCM2835_AUX_CLOCK_UART] =
> +               clk_register_gate(dev, "aux_uart", parent, 0, gate, 0, 0, NULL);
> +
> +       onecell->clks[BCM2835_AUX_CLOCK_SPI1] =
> +               clk_register_gate(dev, "aux_spi1", parent, 0, gate, 1, 0, NULL);
> +
> +       onecell->clks[BCM2835_AUX_CLOCK_SPI2] =
> +               clk_register_gate(dev, "aux_spi2", parent, 0, gate, 2, 0, NULL);
> +
> +       of_clk_add_provider(pdev->dev.of_node, of_clk_src_onecell_get, onecell);
> +
> +       return 0;
> +}
> +
> +static const struct of_device_id bcm2835_aux_clk_of_match[] = {
> +       { .compatible = "brcm,bcm2835-aux", },
> +       {},
> +};
> +MODULE_DEVICE_TABLE(of, bcm2835_aux_clk_of_match);
> +
> +static struct platform_driver bcm2835_aux_clk_driver = {
> +       .driver = {
> +               .name = "bcm2835-aux-clk",
> +               .of_match_table = bcm2835_aux_clk_of_match,
> +       },
> +       .probe          = bcm2835_aux_clk_probe,
> +};
> +builtin_platform_driver(bcm2835_aux_clk_driver);
> +
> +MODULE_AUTHOR("Eric Anholt <eric@anholt.net>");
> +MODULE_DESCRIPTION("BCM2835 auxiliary peripheral clock driver");
> +MODULE_LICENSE("GPL v2");
> --
> 2.6.2
>



-- 
Michael Turquette
CEO
BayLibre - At the Heart of Embedded Linux
http://baylibre.com/

Re: [PATCH v2 2/3] clk: bcm2835: Add a driver for the auxiliary peripheral clock gates.

[Michael Turquette]

On Tue, Dec 15, 2015 at 3:35 PM, Eric Anholt <eric@anholt.net> wrote:
> There are a pair of SPI masters and a mini UART that were last minute
> additions.  As a result, they didn't get integrated in the same way as
> the other gates off of the VPU clock in CPRMAN.
>
> Signed-off-by: Eric Anholt <eric@anholt.net>

Applied to clk-next.

Regards,
Mike

> ---
>
> v2: Make the binding cover both the IRQ and clock enable registers.
>     Use devm_ allocation, ioremap, and and clock get functions.  Don't
>     return the error from of_clk_add_provider(), since that would
>     leave the clocks registered, but their registers unmapped.  Trim
>     includes.
>
>  drivers/clk/bcm/Makefile          |  1 +
>  drivers/clk/bcm/clk-bcm2835-aux.c | 85 +++++++++++++++++++++++++++++++++++++++
>  2 files changed, 86 insertions(+)
>  create mode 100644 drivers/clk/bcm/clk-bcm2835-aux.c
>
> diff --git a/drivers/clk/bcm/Makefile b/drivers/clk/bcm/Makefile
> index 3fc9506..183484c 100644
> --- a/drivers/clk/bcm/Makefile
> +++ b/drivers/clk/bcm/Makefile
> @@ -4,6 +4,7 @@ obj-$(CONFIG_CLK_BCM_KONA)      += clk-bcm281xx.o
>  obj-$(CONFIG_CLK_BCM_KONA)     += clk-bcm21664.o
>  obj-$(CONFIG_COMMON_CLK_IPROC) += clk-iproc-armpll.o clk-iproc-pll.o clk-iproc-asiu.o
>  obj-$(CONFIG_ARCH_BCM2835)     += clk-bcm2835.o
> +obj-$(CONFIG_ARCH_BCM2835)     += clk-bcm2835-aux.o
>  obj-$(CONFIG_COMMON_CLK_IPROC) += clk-ns2.o
>  obj-$(CONFIG_ARCH_BCM_CYGNUS)  += clk-cygnus.o
>  obj-$(CONFIG_ARCH_BCM_NSP)     += clk-nsp.o
> diff --git a/drivers/clk/bcm/clk-bcm2835-aux.c b/drivers/clk/bcm/clk-bcm2835-aux.c
> new file mode 100644
> index 0000000..e4f89e2
> --- /dev/null
> +++ b/drivers/clk/bcm/clk-bcm2835-aux.c
> @@ -0,0 +1,85 @@
> +/*
> + * Copyright (C) 2015 Broadcom
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; either version 2 of the License, or
> + * (at your option) any later version.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + */
> +
> +#include <linux/clk.h>
> +#include <linux/clk-provider.h>
> +#include <linux/clk/bcm2835.h>
> +#include <linux/module.h>
> +#include <linux/platform_device.h>
> +#include <dt-bindings/clock/bcm2835-aux.h>
> +
> +#define BCM2835_AUXIRQ         0x00
> +#define BCM2835_AUXENB         0x04
> +
> +static int bcm2835_aux_clk_probe(struct platform_device *pdev)
> +{
> +       struct device *dev = &pdev->dev;
> +       struct clk_onecell_data *onecell;
> +       const char *parent;
> +       struct clk *parent_clk;
> +       struct resource *res;
> +       void __iomem *reg, *gate;
> +
> +       parent_clk = devm_clk_get(dev, NULL);
> +       if (IS_ERR(parent_clk))
> +               return PTR_ERR(parent_clk);
> +       parent = __clk_get_name(parent_clk);
> +
> +       res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> +       reg = devm_ioremap_resource(dev, res);
> +       if (!reg)
> +               return -ENODEV;
> +
> +       onecell = devm_kmalloc(dev, sizeof(*onecell), GFP_KERNEL);
> +       if (!onecell)
> +               return -ENOMEM;
> +       onecell->clk_num = BCM2835_AUX_CLOCK_COUNT;
> +       onecell->clks = devm_kcalloc(dev, BCM2835_AUX_CLOCK_COUNT,
> +                                    sizeof(*onecell->clks), GFP_KERNEL);
> +       if (!onecell->clks)
> +               return -ENOMEM;
> +
> +       gate = reg + BCM2835_AUXENB;
> +       onecell->clks[BCM2835_AUX_CLOCK_UART] =
> +               clk_register_gate(dev, "aux_uart", parent, 0, gate, 0, 0, NULL);
> +
> +       onecell->clks[BCM2835_AUX_CLOCK_SPI1] =
> +               clk_register_gate(dev, "aux_spi1", parent, 0, gate, 1, 0, NULL);
> +
> +       onecell->clks[BCM2835_AUX_CLOCK_SPI2] =
> +               clk_register_gate(dev, "aux_spi2", parent, 0, gate, 2, 0, NULL);
> +
> +       of_clk_add_provider(pdev->dev.of_node, of_clk_src_onecell_get, onecell);
> +
> +       return 0;
> +}
> +
> +static const struct of_device_id bcm2835_aux_clk_of_match[] = {
> +       { .compatible = "brcm,bcm2835-aux", },
> +       {},
> +};
> +MODULE_DEVICE_TABLE(of, bcm2835_aux_clk_of_match);
> +
> +static struct platform_driver bcm2835_aux_clk_driver = {
> +       .driver = {
> +               .name = "bcm2835-aux-clk",
> +               .of_match_table = bcm2835_aux_clk_of_match,
> +       },
> +       .probe          = bcm2835_aux_clk_probe,
> +};
> +builtin_platform_driver(bcm2835_aux_clk_driver);
> +
> +MODULE_AUTHOR("Eric Anholt <eric@anholt.net>");
> +MODULE_DESCRIPTION("BCM2835 auxiliary peripheral clock driver");
> +MODULE_LICENSE("GPL v2");
> --
> 2.6.2
>



-- 
Michael Turquette
CEO
BayLibre - At the Heart of Embedded Linux
http://baylibre.com/

[PATCH v2 3/3] ARM: bcm2835: Add the auxiliary clocks to the device tree.

[Eric Anholt]

These will be used for enabling UART1, SPI1, and SPI2.

Signed-off-by: Eric Anholt <eric@anholt.net>
---

v2: Make the binding cover both the IRQ and clock enable registers.

 arch/arm/boot/dts/bcm2835.dtsi | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/arch/arm/boot/dts/bcm2835.dtsi b/arch/arm/boot/dts/bcm2835.dtsi
index aef64de..a27d40b 100644
--- a/arch/arm/boot/dts/bcm2835.dtsi
+++ b/arch/arm/boot/dts/bcm2835.dtsi
@@ -73,6 +73,13 @@
 			clocks = <&clk_osc>;
 		};
 
+		aux: aux@0x7e215000 {
+			compatible = "brcm,bcm2835-aux";
+			#clock-cells = <1>;
+			reg = <0x7e215000 0x8>;
+			clocks = <&clocks BCM2835_CLOCK_VPU>;
+		};
+
 		rng@7e104000 {
 			compatible = "brcm,bcm2835-rng";
 			reg = <0x7e104000 0x10>;
-- 
2.6.2

[PATCH v2 3/3] ARM: bcm2835: Add the auxiliary clocks to the device tree.

[Eric Anholt]

These will be used for enabling UART1, SPI1, and SPI2.

Signed-off-by: Eric Anholt <eric@anholt.net>
---

v2: Make the binding cover both the IRQ and clock enable registers.

 arch/arm/boot/dts/bcm2835.dtsi | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/arch/arm/boot/dts/bcm2835.dtsi b/arch/arm/boot/dts/bcm2835.dtsi
index aef64de..a27d40b 100644
--- a/arch/arm/boot/dts/bcm2835.dtsi
+++ b/arch/arm/boot/dts/bcm2835.dtsi
@@ -73,6 +73,13 @@
 			clocks = <&clk_osc>;
 		};
 
+		aux: aux at 0x7e215000 {
+			compatible = "brcm,bcm2835-aux";
+			#clock-cells = <1>;
+			reg = <0x7e215000 0x8>;
+			clocks = <&clocks BCM2835_CLOCK_VPU>;
+		};
+
 		rng at 7e104000 {
 			compatible = "brcm,bcm2835-rng";
 			reg = <0x7e104000 0x10>;
-- 
2.6.2

Re: [PATCH v2 3/3] ARM: bcm2835: Add the auxiliary clocks to the device tree.

[Stefan Wahren]

Hi Eric,

Am 16.12.2015 um 00:35 schrieb Eric Anholt:
> These will be used for enabling UART1, SPI1, and SPI2.
>
> Signed-off-by: Eric Anholt <eric@anholt.net>
> ---
>
> v2: Make the binding cover both the IRQ and clock enable registers.
>
>  arch/arm/boot/dts/bcm2835.dtsi | 7 +++++++
>  1 file changed, 7 insertions(+)
>
> diff --git a/arch/arm/boot/dts/bcm2835.dtsi b/arch/arm/boot/dts/bcm2835.dtsi
> index aef64de..a27d40b 100644
> --- a/arch/arm/boot/dts/bcm2835.dtsi
> +++ b/arch/arm/boot/dts/bcm2835.dtsi
> @@ -73,6 +73,13 @@
>  			clocks = <&clk_osc>;
>  		};
>  
> +		aux: aux@0x7e215000 {
> +			compatible = "brcm,bcm2835-aux";
> +			#clock-cells = <1>;
> +			reg = <0x7e215000 0x8>;
> +			clocks = <&clocks BCM2835_CLOCK_VPU>;
> +		};
> +

just a nit. Since the nodes should be ordered by address this should
better go between|||i2c0 and sdhci.

Thanks

Stefan

|
>  		rng@7e104000 {
>  			compatible = "brcm,bcm2835-rng";
>  			reg = <0x7e104000 0x10>;

[PATCH v2 3/3] ARM: bcm2835: Add the auxiliary clocks to the device tree.

[Stefan Wahren]

Hi Eric,

Am 16.12.2015 um 00:35 schrieb Eric Anholt:
> These will be used for enabling UART1, SPI1, and SPI2.
>
> Signed-off-by: Eric Anholt <eric@anholt.net>
> ---
>
> v2: Make the binding cover both the IRQ and clock enable registers.
>
>  arch/arm/boot/dts/bcm2835.dtsi | 7 +++++++
>  1 file changed, 7 insertions(+)
>
> diff --git a/arch/arm/boot/dts/bcm2835.dtsi b/arch/arm/boot/dts/bcm2835.dtsi
> index aef64de..a27d40b 100644
> --- a/arch/arm/boot/dts/bcm2835.dtsi
> +++ b/arch/arm/boot/dts/bcm2835.dtsi
> @@ -73,6 +73,13 @@
>  			clocks = <&clk_osc>;
>  		};
>  
> +		aux: aux at 0x7e215000 {
> +			compatible = "brcm,bcm2835-aux";
> +			#clock-cells = <1>;
> +			reg = <0x7e215000 0x8>;
> +			clocks = <&clocks BCM2835_CLOCK_VPU>;
> +		};
> +

just a nit. Since the nodes should be ordered by address this should
better go between|||i2c0 and sdhci.

Thanks

Stefan

|
>  		rng at 7e104000 {
>  			compatible = "brcm,bcm2835-rng";
>  			reg = <0x7e104000 0x10>;

Re: [PATCH v2 1/3] clk: bcm2835: Add bindings for the auxiliary peripheral clock gates.

[Rob Herring]

On Tue, Dec 15, 2015 at 03:35:57PM -0800, Eric Anholt wrote:
> These will be used for enabling UART1, SPI1, and SPI2.
> 
> Signed-off-by: Eric Anholt <eric@anholt.net>
> ---
> 
> v2: Make the binding cover both the IRQ and clock enable registers.
> 
>  .../bindings/clock/brcm,bcm2835-aux-clock.txt      | 31 ++++++++++++++++++++++
>  include/dt-bindings/clock/bcm2835-aux.h            | 17 ++++++++++++
>  2 files changed, 48 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/clock/brcm,bcm2835-aux-clock.txt
>  create mode 100644 include/dt-bindings/clock/bcm2835-aux.h

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

Re: [PATCH v2 1/3] clk: bcm2835: Add bindings for the auxiliary peripheral clock gates.

[Rob Herring]

On Tue, Dec 15, 2015 at 03:35:57PM -0800, Eric Anholt wrote:
> These will be used for enabling UART1, SPI1, and SPI2.
> 
> Signed-off-by: Eric Anholt <eric@anholt.net>
> ---
> 
> v2: Make the binding cover both the IRQ and clock enable registers.
> 
>  .../bindings/clock/brcm,bcm2835-aux-clock.txt      | 31 ++++++++++++++++++++++
>  include/dt-bindings/clock/bcm2835-aux.h            | 17 ++++++++++++
>  2 files changed, 48 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/clock/brcm,bcm2835-aux-clock.txt
>  create mode 100644 include/dt-bindings/clock/bcm2835-aux.h

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

[PATCH v2 1/3] clk: bcm2835: Add bindings for the auxiliary peripheral clock gates.

[Rob Herring]

On Tue, Dec 15, 2015 at 03:35:57PM -0800, Eric Anholt wrote:
> These will be used for enabling UART1, SPI1, and SPI2.
> 
> Signed-off-by: Eric Anholt <eric@anholt.net>
> ---
> 
> v2: Make the binding cover both the IRQ and clock enable registers.
> 
>  .../bindings/clock/brcm,bcm2835-aux-clock.txt      | 31 ++++++++++++++++++++++
>  include/dt-bindings/clock/bcm2835-aux.h            | 17 ++++++++++++
>  2 files changed, 48 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/clock/brcm,bcm2835-aux-clock.txt
>  create mode 100644 include/dt-bindings/clock/bcm2835-aux.h

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

Re: [PATCH v2 1/3] clk: bcm2835: Add bindings for the auxiliary peripheral clock gates.

[Michael Turquette]

On Fri, Dec 18, 2015 at 8:19 PM, Rob Herring <robh@kernel.org> wrote:
> On Tue, Dec 15, 2015 at 03:35:57PM -0800, Eric Anholt wrote:
>> These will be used for enabling UART1, SPI1, and SPI2.
>>
>> Signed-off-by: Eric Anholt <eric@anholt.net>
>> ---
>>
>> v2: Make the binding cover both the IRQ and clock enable registers.
>>
>>  .../bindings/clock/brcm,bcm2835-aux-clock.txt      | 31 ++++++++++++++++++++++
>>  include/dt-bindings/clock/bcm2835-aux.h            | 17 ++++++++++++
>>  2 files changed, 48 insertions(+)
>>  create mode 100644 Documentation/devicetree/bindings/clock/brcm,bcm2835-aux-clock.txt
>>  create mode 100644 include/dt-bindings/clock/bcm2835-aux.h
>
> Acked-by: Rob Herring <robh@kernel.org>

Applied to clk-next.

Next time if you put the header into the clk driver patch then we can
send the binding description through the DT tree and take the header
and C file through the clk tree in one patch.

Regards,
Mike

-- 
Michael Turquette
CEO
BayLibre - At the Heart of Embedded Linux
http://baylibre.com/

[PATCH v2 1/3] clk: bcm2835: Add bindings for the auxiliary peripheral clock gates.

[Michael Turquette]

On Fri, Dec 18, 2015 at 8:19 PM, Rob Herring <robh@kernel.org> wrote:
> On Tue, Dec 15, 2015 at 03:35:57PM -0800, Eric Anholt wrote:
>> These will be used for enabling UART1, SPI1, and SPI2.
>>
>> Signed-off-by: Eric Anholt <eric@anholt.net>
>> ---
>>
>> v2: Make the binding cover both the IRQ and clock enable registers.
>>
>>  .../bindings/clock/brcm,bcm2835-aux-clock.txt      | 31 ++++++++++++++++++++++
>>  include/dt-bindings/clock/bcm2835-aux.h            | 17 ++++++++++++
>>  2 files changed, 48 insertions(+)
>>  create mode 100644 Documentation/devicetree/bindings/clock/brcm,bcm2835-aux-clock.txt
>>  create mode 100644 include/dt-bindings/clock/bcm2835-aux.h
>
> Acked-by: Rob Herring <robh@kernel.org>

Applied to clk-next.

Next time if you put the header into the clk driver patch then we can
send the binding description through the DT tree and take the header
and C file through the clk tree in one patch.

Regards,
Mike

-- 
Michael Turquette
CEO
BayLibre - At the Heart of Embedded Linux
http://baylibre.com/

Re: [PATCH v2 1/3] clk: bcm2835: Add bindings for the auxiliary peripheral clock gates.

[Michael Turquette]

On Fri, Dec 18, 2015 at 8:19 PM, Rob Herring <robh@kernel.org> wrote:
> On Tue, Dec 15, 2015 at 03:35:57PM -0800, Eric Anholt wrote:
>> These will be used for enabling UART1, SPI1, and SPI2.
>>
>> Signed-off-by: Eric Anholt <eric@anholt.net>
>> ---
>>
>> v2: Make the binding cover both the IRQ and clock enable registers.
>>
>>  .../bindings/clock/brcm,bcm2835-aux-clock.txt      | 31 ++++++++++++++++++++++
>>  include/dt-bindings/clock/bcm2835-aux.h            | 17 ++++++++++++
>>  2 files changed, 48 insertions(+)
>>  create mode 100644 Documentation/devicetree/bindings/clock/brcm,bcm2835-aux-clock.txt
>>  create mode 100644 include/dt-bindings/clock/bcm2835-aux.h
>
> Acked-by: Rob Herring <robh@kernel.org>

Applied to clk-next.

Next time if you put the header into the clk driver patch then we can
send the binding description through the DT tree and take the header
and C file through the clk tree in one patch.

Regards,
Mike

-- 
Michael Turquette
CEO
BayLibre - At the Heart of Embedded Linux
http://baylibre.com/

Re: [PATCH v2 1/3] clk: bcm2835: Add bindings for the auxiliary peripheral clock gates.

[Michael Turquette]

On Fri, Dec 18, 2015 at 8:19 PM, Rob Herring <robh@kernel.org> wrote:
> On Tue, Dec 15, 2015 at 03:35:57PM -0800, Eric Anholt wrote:
>> These will be used for enabling UART1, SPI1, and SPI2.
>>
>> Signed-off-by: Eric Anholt <eric@anholt.net>
>> ---
>>
>> v2: Make the binding cover both the IRQ and clock enable registers.
>>
>>  .../bindings/clock/brcm,bcm2835-aux-clock.txt      | 31 ++++++++++++++++++++++
>>  include/dt-bindings/clock/bcm2835-aux.h            | 17 ++++++++++++
>>  2 files changed, 48 insertions(+)
>>  create mode 100644 Documentation/devicetree/bindings/clock/brcm,bcm2835-aux-clock.txt
>>  create mode 100644 include/dt-bindings/clock/bcm2835-aux.h
>
> Acked-by: Rob Herring <robh@kernel.org>

Applied to clk-next.

Next time if you put the header into the clk driver patch then we can
send the binding description through the DT tree and take the header
and C file through the clk tree in one patch.

Regards,
Mike

-- 
Michael Turquette
CEO
BayLibre - At the Heart of Embedded Linux
http://baylibre.com/

Re: [PATCH v2 1/3] clk: bcm2835: Add bindings for the auxiliary peripheral clock gates.

[Eric Anholt]

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

Michael Turquette <mturquette@baylibre.com> writes:

> On Fri, Dec 18, 2015 at 8:19 PM, Rob Herring <robh@kernel.org> wrote:
>> On Tue, Dec 15, 2015 at 03:35:57PM -0800, Eric Anholt wrote:
>>> These will be used for enabling UART1, SPI1, and SPI2.
>>>
>>> Signed-off-by: Eric Anholt <eric@anholt.net>
>>> ---
>>>
>>> v2: Make the binding cover both the IRQ and clock enable registers.
>>>
>>>  .../bindings/clock/brcm,bcm2835-aux-clock.txt      | 31 ++++++++++++++++++++++
>>>  include/dt-bindings/clock/bcm2835-aux.h            | 17 ++++++++++++
>>>  2 files changed, 48 insertions(+)
>>>  create mode 100644 Documentation/devicetree/bindings/clock/brcm,bcm2835-aux-clock.txt
>>>  create mode 100644 include/dt-bindings/clock/bcm2835-aux.h
>>
>> Acked-by: Rob Herring <robh@kernel.org>
>
> Applied to clk-next.
>
> Next time if you put the header into the clk driver patch then we can
> send the binding description through the DT tree and take the header
> and C file through the clk tree in one patch.

I would *love* to do that, but I've previously been told that having the
bindings patch reference a header file not present as of the bindings
patch is not acceptable and made to change it.

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

[PATCH v2 1/3] clk: bcm2835: Add bindings for the auxiliary peripheral clock gates.

[Eric Anholt]

Michael Turquette <mturquette@baylibre.com> writes:

> On Fri, Dec 18, 2015 at 8:19 PM, Rob Herring <robh@kernel.org> wrote:
>> On Tue, Dec 15, 2015 at 03:35:57PM -0800, Eric Anholt wrote:
>>> These will be used for enabling UART1, SPI1, and SPI2.
>>>
>>> Signed-off-by: Eric Anholt <eric@anholt.net>
>>> ---
>>>
>>> v2: Make the binding cover both the IRQ and clock enable registers.
>>>
>>>  .../bindings/clock/brcm,bcm2835-aux-clock.txt      | 31 ++++++++++++++++++++++
>>>  include/dt-bindings/clock/bcm2835-aux.h            | 17 ++++++++++++
>>>  2 files changed, 48 insertions(+)
>>>  create mode 100644 Documentation/devicetree/bindings/clock/brcm,bcm2835-aux-clock.txt
>>>  create mode 100644 include/dt-bindings/clock/bcm2835-aux.h
>>
>> Acked-by: Rob Herring <robh@kernel.org>
>
> Applied to clk-next.
>
> Next time if you put the header into the clk driver patch then we can
> send the binding description through the DT tree and take the header
> and C file through the clk tree in one patch.

I would *love* to do that, but I've previously been told that having the
bindings patch reference a header file not present as of the bindings
patch is not acceptable and made to change it.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 818 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20151224/3f457eec/attachment.sig>

Re: [PATCH v2 1/3] clk: bcm2835: Add bindings for the auxiliary peripheral clock gates.

[Eric Anholt]

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

Michael Turquette <mturquette@baylibre.com> writes:

> On Fri, Dec 18, 2015 at 8:19 PM, Rob Herring <robh@kernel.org> wrote:
>> On Tue, Dec 15, 2015 at 03:35:57PM -0800, Eric Anholt wrote:
>>> These will be used for enabling UART1, SPI1, and SPI2.
>>>
>>> Signed-off-by: Eric Anholt <eric@anholt.net>
>>> ---
>>>
>>> v2: Make the binding cover both the IRQ and clock enable registers.
>>>
>>>  .../bindings/clock/brcm,bcm2835-aux-clock.txt      | 31 ++++++++++++++++++++++
>>>  include/dt-bindings/clock/bcm2835-aux.h            | 17 ++++++++++++
>>>  2 files changed, 48 insertions(+)
>>>  create mode 100644 Documentation/devicetree/bindings/clock/brcm,bcm2835-aux-clock.txt
>>>  create mode 100644 include/dt-bindings/clock/bcm2835-aux.h
>>
>> Acked-by: Rob Herring <robh@kernel.org>
>
> Applied to clk-next.
>
> Next time if you put the header into the clk driver patch then we can
> send the binding description through the DT tree and take the header
> and C file through the clk tree in one patch.

I would *love* to do that, but I've previously been told that having the
bindings patch reference a header file not present as of the bindings
patch is not acceptable and made to change it.

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

Re: [PATCH v2 1/3] clk: bcm2835: Add bindings for the auxiliary peripheral clock gates.

[Eric Anholt]

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

Michael Turquette <mturquette@baylibre.com> writes:

> On Fri, Dec 18, 2015 at 8:19 PM, Rob Herring <robh@kernel.org> wrote:
>> On Tue, Dec 15, 2015 at 03:35:57PM -0800, Eric Anholt wrote:
>>> These will be used for enabling UART1, SPI1, and SPI2.
>>>
>>> Signed-off-by: Eric Anholt <eric@anholt.net>
>>> ---
>>>
>>> v2: Make the binding cover both the IRQ and clock enable registers.
>>>
>>>  .../bindings/clock/brcm,bcm2835-aux-clock.txt      | 31 ++++++++++++++++++++++
>>>  include/dt-bindings/clock/bcm2835-aux.h            | 17 ++++++++++++
>>>  2 files changed, 48 insertions(+)
>>>  create mode 100644 Documentation/devicetree/bindings/clock/brcm,bcm2835-aux-clock.txt
>>>  create mode 100644 include/dt-bindings/clock/bcm2835-aux.h
>>
>> Acked-by: Rob Herring <robh@kernel.org>
>
> Applied to clk-next.
>
> Next time if you put the header into the clk driver patch then we can
> send the binding description through the DT tree and take the header
> and C file through the clk tree in one patch.

I would *love* to do that, but I've previously been told that having the
bindings patch reference a header file not present as of the bindings
patch is not acceptable and made to change it.

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

Re: [PATCH v2 1/3] clk: bcm2835: Add bindings for the auxiliary peripheral clock gates.

[Michael Turquette]

Quoting Eric Anholt (2015-12-24 15:45:15)
> Michael Turquette <mturquette@baylibre.com> writes:
> 
> > On Fri, Dec 18, 2015 at 8:19 PM, Rob Herring <robh@kernel.org> wrote:
> >> On Tue, Dec 15, 2015 at 03:35:57PM -0800, Eric Anholt wrote:
> >>> These will be used for enabling UART1, SPI1, and SPI2.
> >>>
> >>> Signed-off-by: Eric Anholt <eric@anholt.net>
> >>> ---
> >>>
> >>> v2: Make the binding cover both the IRQ and clock enable registers.
> >>>
> >>>  .../bindings/clock/brcm,bcm2835-aux-clock.txt      | 31 ++++++++++++++++++++++
> >>>  include/dt-bindings/clock/bcm2835-aux.h            | 17 ++++++++++++
> >>>  2 files changed, 48 insertions(+)
> >>>  create mode 100644 Documentation/devicetree/bindings/clock/brcm,bcm2835-aux-clock.txt
> >>>  create mode 100644 include/dt-bindings/clock/bcm2835-aux.h
> >>
> >> Acked-by: Rob Herring <robh@kernel.org>
> >
> > Applied to clk-next.
> >
> > Next time if you put the header into the clk driver patch then we can
> > send the binding description through the DT tree and take the header
> > and C file through the clk tree in one patch.
> 
> I would *love* to do that, but I've previously been told that having the
> bindings patch reference a header file not present as of the bindings
> patch is not acceptable and made to change it.

Ugh, that is annoying. I would think that having code compile properly
would trump the desire to have all of the documentation merged as one
patch.

On the other hand, I've been asked to not take binding descriptions
through the clk tree. That is a policy that I'm happy to comply with,
but it is at odds with the recommendation for the header and the binding
description to be merged together.

DT folks, what is the right way to do this? An immutable, shared branch
just for a single header file solves the problem, but also feels very
cumbersome for such a trivial issue.

How about allowing binding descriptions to be merged without the header
file, so long as it is merged through another tree?

Regards,
Mike

[PATCH v2 1/3] clk: bcm2835: Add bindings for the auxiliary peripheral clock gates.

[Michael Turquette]

Quoting Eric Anholt (2015-12-24 15:45:15)
> Michael Turquette <mturquette@baylibre.com> writes:
> 
> > On Fri, Dec 18, 2015 at 8:19 PM, Rob Herring <robh@kernel.org> wrote:
> >> On Tue, Dec 15, 2015 at 03:35:57PM -0800, Eric Anholt wrote:
> >>> These will be used for enabling UART1, SPI1, and SPI2.
> >>>
> >>> Signed-off-by: Eric Anholt <eric@anholt.net>
> >>> ---
> >>>
> >>> v2: Make the binding cover both the IRQ and clock enable registers.
> >>>
> >>>  .../bindings/clock/brcm,bcm2835-aux-clock.txt      | 31 ++++++++++++++++++++++
> >>>  include/dt-bindings/clock/bcm2835-aux.h            | 17 ++++++++++++
> >>>  2 files changed, 48 insertions(+)
> >>>  create mode 100644 Documentation/devicetree/bindings/clock/brcm,bcm2835-aux-clock.txt
> >>>  create mode 100644 include/dt-bindings/clock/bcm2835-aux.h
> >>
> >> Acked-by: Rob Herring <robh@kernel.org>
> >
> > Applied to clk-next.
> >
> > Next time if you put the header into the clk driver patch then we can
> > send the binding description through the DT tree and take the header
> > and C file through the clk tree in one patch.
> 
> I would *love* to do that, but I've previously been told that having the
> bindings patch reference a header file not present as of the bindings
> patch is not acceptable and made to change it.

Ugh, that is annoying. I would think that having code compile properly
would trump the desire to have all of the documentation merged as one
patch.

On the other hand, I've been asked to not take binding descriptions
through the clk tree. That is a policy that I'm happy to comply with,
but it is at odds with the recommendation for the header and the binding
description to be merged together.

DT folks, what is the right way to do this? An immutable, shared branch
just for a single header file solves the problem, but also feels very
cumbersome for such a trivial issue.

How about allowing binding descriptions to be merged without the header
file, so long as it is merged through another tree?

Regards,
Mike

Re: [PATCH v2 1/3] clk: bcm2835: Add bindings for the auxiliary peripheral clock gates.

[Michael Turquette]

Quoting Eric Anholt (2015-12-24 15:45:15)
> Michael Turquette <mturquette@baylibre.com> writes:
> =

> > On Fri, Dec 18, 2015 at 8:19 PM, Rob Herring <robh@kernel.org> wrote:
> >> On Tue, Dec 15, 2015 at 03:35:57PM -0800, Eric Anholt wrote:
> >>> These will be used for enabling UART1, SPI1, and SPI2.
> >>>
> >>> Signed-off-by: Eric Anholt <eric@anholt.net>
> >>> ---
> >>>
> >>> v2: Make the binding cover both the IRQ and clock enable registers.
> >>>
> >>>  .../bindings/clock/brcm,bcm2835-aux-clock.txt      | 31 ++++++++++++=
++++++++++
> >>>  include/dt-bindings/clock/bcm2835-aux.h            | 17 ++++++++++++
> >>>  2 files changed, 48 insertions(+)
> >>>  create mode 100644 Documentation/devicetree/bindings/clock/brcm,bcm2=
835-aux-clock.txt
> >>>  create mode 100644 include/dt-bindings/clock/bcm2835-aux.h
> >>
> >> Acked-by: Rob Herring <robh@kernel.org>
> >
> > Applied to clk-next.
> >
> > Next time if you put the header into the clk driver patch then we can
> > send the binding description through the DT tree and take the header
> > and C file through the clk tree in one patch.
> =

> I would *love* to do that, but I've previously been told that having the
> bindings patch reference a header file not present as of the bindings
> patch is not acceptable and made to change it.

Ugh, that is annoying. I would think that having code compile properly
would trump the desire to have all of the documentation merged as one
patch.

On the other hand, I've been asked to not take binding descriptions
through the clk tree. That is a policy that I'm happy to comply with,
but it is at odds with the recommendation for the header and the binding
description to be merged together.

DT folks, what is the right way to do this? An immutable, shared branch
just for a single header file solves the problem, but also feels very
cumbersome for such a trivial issue.

How about allowing binding descriptions to be merged without the header
file, so long as it is merged through another tree?

Regards,
Mike

Re: [PATCH v2 1/3] clk: bcm2835: Add bindings for the auxiliary peripheral clock gates.

[Michael Turquette]

Quoting Eric Anholt (2015-12-24 15:45:15)
> Michael Turquette <mturquette@baylibre.com> writes:
> 
> > On Fri, Dec 18, 2015 at 8:19 PM, Rob Herring <robh@kernel.org> wrote:
> >> On Tue, Dec 15, 2015 at 03:35:57PM -0800, Eric Anholt wrote:
> >>> These will be used for enabling UART1, SPI1, and SPI2.
> >>>
> >>> Signed-off-by: Eric Anholt <eric@anholt.net>
> >>> ---
> >>>
> >>> v2: Make the binding cover both the IRQ and clock enable registers.
> >>>
> >>>  .../bindings/clock/brcm,bcm2835-aux-clock.txt      | 31 ++++++++++++++++++++++
> >>>  include/dt-bindings/clock/bcm2835-aux.h            | 17 ++++++++++++
> >>>  2 files changed, 48 insertions(+)
> >>>  create mode 100644 Documentation/devicetree/bindings/clock/brcm,bcm2835-aux-clock.txt
> >>>  create mode 100644 include/dt-bindings/clock/bcm2835-aux.h
> >>
> >> Acked-by: Rob Herring <robh@kernel.org>
> >
> > Applied to clk-next.
> >
> > Next time if you put the header into the clk driver patch then we can
> > send the binding description through the DT tree and take the header
> > and C file through the clk tree in one patch.
> 
> I would *love* to do that, but I've previously been told that having the
> bindings patch reference a header file not present as of the bindings
> patch is not acceptable and made to change it.

Ugh, that is annoying. I would think that having code compile properly
would trump the desire to have all of the documentation merged as one
patch.

On the other hand, I've been asked to not take binding descriptions
through the clk tree. That is a policy that I'm happy to comply with,
but it is at odds with the recommendation for the header and the binding
description to be merged together.

DT folks, what is the right way to do this? An immutable, shared branch
just for a single header file solves the problem, but also feels very
cumbersome for such a trivial issue.

How about allowing binding descriptions to be merged without the header
file, so long as it is merged through another tree?

Regards,
Mike

Re: [PATCH v2 1/3] clk: bcm2835: Add bindings for the auxiliary peripheral clock gates.

[Rob Herring]

+Arnd and Olof

On Mon, Dec 28, 2015 at 4:39 PM, Michael Turquette
<mturquette@baylibre.com> wrote:
> Quoting Eric Anholt (2015-12-24 15:45:15)
>> Michael Turquette <mturquette@baylibre.com> writes:
>>
>> > On Fri, Dec 18, 2015 at 8:19 PM, Rob Herring <robh@kernel.org> wrote:
>> >> On Tue, Dec 15, 2015 at 03:35:57PM -0800, Eric Anholt wrote:
>> >>> These will be used for enabling UART1, SPI1, and SPI2.
>> >>>
>> >>> Signed-off-by: Eric Anholt <eric@anholt.net>
>> >>> ---
>> >>>
>> >>> v2: Make the binding cover both the IRQ and clock enable registers.
>> >>>
>> >>>  .../bindings/clock/brcm,bcm2835-aux-clock.txt      | 31 ++++++++++++++++++++++
>> >>>  include/dt-bindings/clock/bcm2835-aux.h            | 17 ++++++++++++
>> >>>  2 files changed, 48 insertions(+)
>> >>>  create mode 100644 Documentation/devicetree/bindings/clock/brcm,bcm2835-aux-clock.txt
>> >>>  create mode 100644 include/dt-bindings/clock/bcm2835-aux.h
>> >>
>> >> Acked-by: Rob Herring <robh@kernel.org>
>> >
>> > Applied to clk-next.
>> >
>> > Next time if you put the header into the clk driver patch then we can
>> > send the binding description through the DT tree and take the header
>> > and C file through the clk tree in one patch.
>>
>> I would *love* to do that, but I've previously been told that having the
>> bindings patch reference a header file not present as of the bindings
>> patch is not acceptable and made to change it.
>
> Ugh, that is annoying. I would think that having code compile properly
> would trump the desire to have all of the documentation merged as one
> patch.

What about compiling the dts?

> On the other hand, I've been asked to not take binding descriptions
> through the clk tree. That is a policy that I'm happy to comply with,
> but it is at odds with the recommendation for the header and the binding
> description to be merged together.

By who? Any bindings in a series I always expect the subsystem
maintainers to take the whole series. That doesn't solve the problem
though as there is still a dependency between a subsystem tree and
arm-soc typically.

> DT folks, what is the right way to do this? An immutable, shared branch
> just for a single header file solves the problem, but also feels very
> cumbersome for such a trivial issue.

Arnd and Olof have been complaining about this problem which is worse
when it is a binding, driver and dts.

I'm open to maintaining a branch for this purpose if that helps. That
or staggering merging of bindings and drivers/dts are the only ideas
I've come up with.

> How about allowing binding descriptions to be merged without the header
> file, so long as it is merged through another tree?

I think that is wrong if we have the goal to separate bindings from
the kernel and the bindings should stand on their own. However, if it
greatly simplifies things, i'd be okay with that.

Rob

[PATCH v2 1/3] clk: bcm2835: Add bindings for the auxiliary peripheral clock gates.

[Rob Herring]

+Arnd and Olof

On Mon, Dec 28, 2015 at 4:39 PM, Michael Turquette
<mturquette@baylibre.com> wrote:
> Quoting Eric Anholt (2015-12-24 15:45:15)
>> Michael Turquette <mturquette@baylibre.com> writes:
>>
>> > On Fri, Dec 18, 2015 at 8:19 PM, Rob Herring <robh@kernel.org> wrote:
>> >> On Tue, Dec 15, 2015 at 03:35:57PM -0800, Eric Anholt wrote:
>> >>> These will be used for enabling UART1, SPI1, and SPI2.
>> >>>
>> >>> Signed-off-by: Eric Anholt <eric@anholt.net>
>> >>> ---
>> >>>
>> >>> v2: Make the binding cover both the IRQ and clock enable registers.
>> >>>
>> >>>  .../bindings/clock/brcm,bcm2835-aux-clock.txt      | 31 ++++++++++++++++++++++
>> >>>  include/dt-bindings/clock/bcm2835-aux.h            | 17 ++++++++++++
>> >>>  2 files changed, 48 insertions(+)
>> >>>  create mode 100644 Documentation/devicetree/bindings/clock/brcm,bcm2835-aux-clock.txt
>> >>>  create mode 100644 include/dt-bindings/clock/bcm2835-aux.h
>> >>
>> >> Acked-by: Rob Herring <robh@kernel.org>
>> >
>> > Applied to clk-next.
>> >
>> > Next time if you put the header into the clk driver patch then we can
>> > send the binding description through the DT tree and take the header
>> > and C file through the clk tree in one patch.
>>
>> I would *love* to do that, but I've previously been told that having the
>> bindings patch reference a header file not present as of the bindings
>> patch is not acceptable and made to change it.
>
> Ugh, that is annoying. I would think that having code compile properly
> would trump the desire to have all of the documentation merged as one
> patch.

What about compiling the dts?

> On the other hand, I've been asked to not take binding descriptions
> through the clk tree. That is a policy that I'm happy to comply with,
> but it is at odds with the recommendation for the header and the binding
> description to be merged together.

By who? Any bindings in a series I always expect the subsystem
maintainers to take the whole series. That doesn't solve the problem
though as there is still a dependency between a subsystem tree and
arm-soc typically.

> DT folks, what is the right way to do this? An immutable, shared branch
> just for a single header file solves the problem, but also feels very
> cumbersome for such a trivial issue.

Arnd and Olof have been complaining about this problem which is worse
when it is a binding, driver and dts.

I'm open to maintaining a branch for this purpose if that helps. That
or staggering merging of bindings and drivers/dts are the only ideas
I've come up with.

> How about allowing binding descriptions to be merged without the header
> file, so long as it is merged through another tree?

I think that is wrong if we have the goal to separate bindings from
the kernel and the bindings should stand on their own. However, if it
greatly simplifies things, i'd be okay with that.

Rob

Re: [PATCH v2 1/3] clk: bcm2835: Add bindings for the auxiliary peripheral clock gates.

[Rob Herring]

+Arnd and Olof

On Mon, Dec 28, 2015 at 4:39 PM, Michael Turquette
<mturquette@baylibre.com> wrote:
> Quoting Eric Anholt (2015-12-24 15:45:15)
>> Michael Turquette <mturquette@baylibre.com> writes:
>>
>> > On Fri, Dec 18, 2015 at 8:19 PM, Rob Herring <robh@kernel.org> wrote:
>> >> On Tue, Dec 15, 2015 at 03:35:57PM -0800, Eric Anholt wrote:
>> >>> These will be used for enabling UART1, SPI1, and SPI2.
>> >>>
>> >>> Signed-off-by: Eric Anholt <eric@anholt.net>
>> >>> ---
>> >>>
>> >>> v2: Make the binding cover both the IRQ and clock enable registers.
>> >>>
>> >>>  .../bindings/clock/brcm,bcm2835-aux-clock.txt      | 31 ++++++++++++++++++++++
>> >>>  include/dt-bindings/clock/bcm2835-aux.h            | 17 ++++++++++++
>> >>>  2 files changed, 48 insertions(+)
>> >>>  create mode 100644 Documentation/devicetree/bindings/clock/brcm,bcm2835-aux-clock.txt
>> >>>  create mode 100644 include/dt-bindings/clock/bcm2835-aux.h
>> >>
>> >> Acked-by: Rob Herring <robh@kernel.org>
>> >
>> > Applied to clk-next.
>> >
>> > Next time if you put the header into the clk driver patch then we can
>> > send the binding description through the DT tree and take the header
>> > and C file through the clk tree in one patch.
>>
>> I would *love* to do that, but I've previously been told that having the
>> bindings patch reference a header file not present as of the bindings
>> patch is not acceptable and made to change it.
>
> Ugh, that is annoying. I would think that having code compile properly
> would trump the desire to have all of the documentation merged as one
> patch.

What about compiling the dts?

> On the other hand, I've been asked to not take binding descriptions
> through the clk tree. That is a policy that I'm happy to comply with,
> but it is at odds with the recommendation for the header and the binding
> description to be merged together.

By who? Any bindings in a series I always expect the subsystem
maintainers to take the whole series. That doesn't solve the problem
though as there is still a dependency between a subsystem tree and
arm-soc typically.

> DT folks, what is the right way to do this? An immutable, shared branch
> just for a single header file solves the problem, but also feels very
> cumbersome for such a trivial issue.

Arnd and Olof have been complaining about this problem which is worse
when it is a binding, driver and dts.

I'm open to maintaining a branch for this purpose if that helps. That
or staggering merging of bindings and drivers/dts are the only ideas
I've come up with.

> How about allowing binding descriptions to be merged without the header
> file, so long as it is merged through another tree?

I think that is wrong if we have the goal to separate bindings from
the kernel and the bindings should stand on their own. However, if it
greatly simplifies things, i'd be okay with that.

Rob

Re: [PATCH v2 1/3] clk: bcm2835: Add bindings for the auxiliary peripheral clock gates.

[Rob Herring]

+Arnd and Olof

On Mon, Dec 28, 2015 at 4:39 PM, Michael Turquette
<mturquette@baylibre.com> wrote:
> Quoting Eric Anholt (2015-12-24 15:45:15)
>> Michael Turquette <mturquette@baylibre.com> writes:
>>
>> > On Fri, Dec 18, 2015 at 8:19 PM, Rob Herring <robh@kernel.org> wrote:
>> >> On Tue, Dec 15, 2015 at 03:35:57PM -0800, Eric Anholt wrote:
>> >>> These will be used for enabling UART1, SPI1, and SPI2.
>> >>>
>> >>> Signed-off-by: Eric Anholt <eric@anholt.net>
>> >>> ---
>> >>>
>> >>> v2: Make the binding cover both the IRQ and clock enable registers.
>> >>>
>> >>>  .../bindings/clock/brcm,bcm2835-aux-clock.txt      | 31 ++++++++++++++++++++++
>> >>>  include/dt-bindings/clock/bcm2835-aux.h            | 17 ++++++++++++
>> >>>  2 files changed, 48 insertions(+)
>> >>>  create mode 100644 Documentation/devicetree/bindings/clock/brcm,bcm2835-aux-clock.txt
>> >>>  create mode 100644 include/dt-bindings/clock/bcm2835-aux.h
>> >>
>> >> Acked-by: Rob Herring <robh@kernel.org>
>> >
>> > Applied to clk-next.
>> >
>> > Next time if you put the header into the clk driver patch then we can
>> > send the binding description through the DT tree and take the header
>> > and C file through the clk tree in one patch.
>>
>> I would *love* to do that, but I've previously been told that having the
>> bindings patch reference a header file not present as of the bindings
>> patch is not acceptable and made to change it.
>
> Ugh, that is annoying. I would think that having code compile properly
> would trump the desire to have all of the documentation merged as one
> patch.

What about compiling the dts?

> On the other hand, I've been asked to not take binding descriptions
> through the clk tree. That is a policy that I'm happy to comply with,
> but it is at odds with the recommendation for the header and the binding
> description to be merged together.

By who? Any bindings in a series I always expect the subsystem
maintainers to take the whole series. That doesn't solve the problem
though as there is still a dependency between a subsystem tree and
arm-soc typically.

> DT folks, what is the right way to do this? An immutable, shared branch
> just for a single header file solves the problem, but also feels very
> cumbersome for such a trivial issue.

Arnd and Olof have been complaining about this problem which is worse
when it is a binding, driver and dts.

I'm open to maintaining a branch for this purpose if that helps. That
or staggering merging of bindings and drivers/dts are the only ideas
I've come up with.

> How about allowing binding descriptions to be merged without the header
> file, so long as it is merged through another tree?

I think that is wrong if we have the goal to separate bindings from
the kernel and the bindings should stand on their own. However, if it
greatly simplifies things, i'd be okay with that.

Rob

Re: [PATCH v2 1/3] clk: bcm2835: Add bindings for the auxiliary peripheral clock gates.

[Arnd Bergmann]

On Tuesday 29 December 2015 16:15:09 Rob Herring wrote:
> On Mon, Dec 28, 2015 at 4:39 PM, Michael Turquette
> <mturquette@baylibre.com> wrote:
> > Quoting Eric Anholt (2015-12-24 15:45:15)
> >> Michael Turquette <mturquette@baylibre.com> writes:
> >> I would *love* to do that, but I've previously been told that having the
> >> bindings patch reference a header file not present as of the bindings
> >> patch is not acceptable and made to change it.
> >
> > Ugh, that is annoying. I would think that having code compile properly
> > would trump the desire to have all of the documentation merged as one
> > patch.
> 
> What about compiling the dts?
> 
> > On the other hand, I've been asked to not take binding descriptions
> > through the clk tree. That is a policy that I'm happy to comply with,
> > but it is at odds with the recommendation for the header and the binding
> > description to be merged together.
> 
> By who? Any bindings in a series I always expect the subsystem
> maintainers to take the whole series. That doesn't solve the problem
> though as there is still a dependency between a subsystem tree and
> arm-soc typically.

I don't care too much which tree the binding description goes through either,
as long as it is kept in sync.

> > DT folks, what is the right way to do this? An immutable, shared branch
> > just for a single header file solves the problem, but also feels very
> > cumbersome for such a trivial issue.
> 
> Arnd and Olof have been complaining about this problem which is worse
> when it is a binding, driver and dts.
> 
> I'm open to maintaining a branch for this purpose if that helps. That
> or staggering merging of bindings and drivers/dts are the only ideas
> I've come up with.


> > How about allowing binding descriptions to be merged without the header
> > file, so long as it is merged through another tree?
> 
> I think that is wrong if we have the goal to separate bindings from
> the kernel and the bindings should stand on their own. However, if it
> greatly simplifies things, i'd be okay with that.

The header file is really the main issue we need to worry about. My preferred
way of doing this would be to give it an extra merge window: add the binding
document and the header file in one merge window, and then add the dts files
and the driver one release later. I've seen a lot of header files added for
no good reason at all, and at least that way we can get people to think about
the dependency more.

It's also ok to merge the header file and binding with either the dts file
changes or the driver and then do the other part the following release.

In the past, we've worked around the issue by merging the driver through
arm-soc, or by merging the dts changes through a driver tree, with the
appropriate Acks in each case. Both of those approaches work of course,
but the former always feels awkward to me as we are not using the right
maintainer path, and the latter approach tends to cause merge conflicts,
especially when multiple headers for different subsystems get added or
the dts files are added at the same time.

Having a shared branch for the header file is another way to do it, and
we can do that in some cases, but I'd prefer not to make it the default.

	Arnd

[PATCH v2 1/3] clk: bcm2835: Add bindings for the auxiliary peripheral clock gates.

[Arnd Bergmann]

On Tuesday 29 December 2015 16:15:09 Rob Herring wrote:
> On Mon, Dec 28, 2015 at 4:39 PM, Michael Turquette
> <mturquette@baylibre.com> wrote:
> > Quoting Eric Anholt (2015-12-24 15:45:15)
> >> Michael Turquette <mturquette@baylibre.com> writes:
> >> I would *love* to do that, but I've previously been told that having the
> >> bindings patch reference a header file not present as of the bindings
> >> patch is not acceptable and made to change it.
> >
> > Ugh, that is annoying. I would think that having code compile properly
> > would trump the desire to have all of the documentation merged as one
> > patch.
> 
> What about compiling the dts?
> 
> > On the other hand, I've been asked to not take binding descriptions
> > through the clk tree. That is a policy that I'm happy to comply with,
> > but it is at odds with the recommendation for the header and the binding
> > description to be merged together.
> 
> By who? Any bindings in a series I always expect the subsystem
> maintainers to take the whole series. That doesn't solve the problem
> though as there is still a dependency between a subsystem tree and
> arm-soc typically.

I don't care too much which tree the binding description goes through either,
as long as it is kept in sync.

> > DT folks, what is the right way to do this? An immutable, shared branch
> > just for a single header file solves the problem, but also feels very
> > cumbersome for such a trivial issue.
> 
> Arnd and Olof have been complaining about this problem which is worse
> when it is a binding, driver and dts.
> 
> I'm open to maintaining a branch for this purpose if that helps. That
> or staggering merging of bindings and drivers/dts are the only ideas
> I've come up with.


> > How about allowing binding descriptions to be merged without the header
> > file, so long as it is merged through another tree?
> 
> I think that is wrong if we have the goal to separate bindings from
> the kernel and the bindings should stand on their own. However, if it
> greatly simplifies things, i'd be okay with that.

The header file is really the main issue we need to worry about. My preferred
way of doing this would be to give it an extra merge window: add the binding
document and the header file in one merge window, and then add the dts files
and the driver one release later. I've seen a lot of header files added for
no good reason at all, and at least that way we can get people to think about
the dependency more.

It's also ok to merge the header file and binding with either the dts file
changes or the driver and then do the other part the following release.

In the past, we've worked around the issue by merging the driver through
arm-soc, or by merging the dts changes through a driver tree, with the
appropriate Acks in each case. Both of those approaches work of course,
but the former always feels awkward to me as we are not using the right
maintainer path, and the latter approach tends to cause merge conflicts,
especially when multiple headers for different subsystems get added or
the dts files are added at the same time.

Having a shared branch for the header file is another way to do it, and
we can do that in some cases, but I'd prefer not to make it the default.

	Arnd

Re: [PATCH v2 1/3] clk: bcm2835: Add bindings for the auxiliary peripheral clock gates.

[Arnd Bergmann]

On Tuesday 29 December 2015 16:15:09 Rob Herring wrote:
> On Mon, Dec 28, 2015 at 4:39 PM, Michael Turquette
> <mturquette@baylibre.com> wrote:
> > Quoting Eric Anholt (2015-12-24 15:45:15)
> >> Michael Turquette <mturquette@baylibre.com> writes:
> >> I would *love* to do that, but I've previously been told that having the
> >> bindings patch reference a header file not present as of the bindings
> >> patch is not acceptable and made to change it.
> >
> > Ugh, that is annoying. I would think that having code compile properly
> > would trump the desire to have all of the documentation merged as one
> > patch.
> 
> What about compiling the dts?
> 
> > On the other hand, I've been asked to not take binding descriptions
> > through the clk tree. That is a policy that I'm happy to comply with,
> > but it is at odds with the recommendation for the header and the binding
> > description to be merged together.
> 
> By who? Any bindings in a series I always expect the subsystem
> maintainers to take the whole series. That doesn't solve the problem
> though as there is still a dependency between a subsystem tree and
> arm-soc typically.

I don't care too much which tree the binding description goes through either,
as long as it is kept in sync.

> > DT folks, what is the right way to do this? An immutable, shared branch
> > just for a single header file solves the problem, but also feels very
> > cumbersome for such a trivial issue.
> 
> Arnd and Olof have been complaining about this problem which is worse
> when it is a binding, driver and dts.
> 
> I'm open to maintaining a branch for this purpose if that helps. That
> or staggering merging of bindings and drivers/dts are the only ideas
> I've come up with.


> > How about allowing binding descriptions to be merged without the header
> > file, so long as it is merged through another tree?
> 
> I think that is wrong if we have the goal to separate bindings from
> the kernel and the bindings should stand on their own. However, if it
> greatly simplifies things, i'd be okay with that.

The header file is really the main issue we need to worry about. My preferred
way of doing this would be to give it an extra merge window: add the binding
document and the header file in one merge window, and then add the dts files
and the driver one release later. I've seen a lot of header files added for
no good reason at all, and at least that way we can get people to think about
the dependency more.

It's also ok to merge the header file and binding with either the dts file
changes or the driver and then do the other part the following release.

In the past, we've worked around the issue by merging the driver through
arm-soc, or by merging the dts changes through a driver tree, with the
appropriate Acks in each case. Both of those approaches work of course,
but the former always feels awkward to me as we are not using the right
maintainer path, and the latter approach tends to cause merge conflicts,
especially when multiple headers for different subsystems get added or
the dts files are added at the same time.

Having a shared branch for the header file is another way to do it, and
we can do that in some cases, but I'd prefer not to make it the default.

	Arnd

Re: [PATCH v2 1/3] clk: bcm2835: Add bindings for the auxiliary peripheral clock gates.

[Arnd Bergmann]

On Tuesday 29 December 2015 16:15:09 Rob Herring wrote:
> On Mon, Dec 28, 2015 at 4:39 PM, Michael Turquette
> <mturquette@baylibre.com> wrote:
> > Quoting Eric Anholt (2015-12-24 15:45:15)
> >> Michael Turquette <mturquette@baylibre.com> writes:
> >> I would *love* to do that, but I've previously been told that having the
> >> bindings patch reference a header file not present as of the bindings
> >> patch is not acceptable and made to change it.
> >
> > Ugh, that is annoying. I would think that having code compile properly
> > would trump the desire to have all of the documentation merged as one
> > patch.
> 
> What about compiling the dts?
> 
> > On the other hand, I've been asked to not take binding descriptions
> > through the clk tree. That is a policy that I'm happy to comply with,
> > but it is at odds with the recommendation for the header and the binding
> > description to be merged together.
> 
> By who? Any bindings in a series I always expect the subsystem
> maintainers to take the whole series. That doesn't solve the problem
> though as there is still a dependency between a subsystem tree and
> arm-soc typically.

I don't care too much which tree the binding description goes through either,
as long as it is kept in sync.

> > DT folks, what is the right way to do this? An immutable, shared branch
> > just for a single header file solves the problem, but also feels very
> > cumbersome for such a trivial issue.
> 
> Arnd and Olof have been complaining about this problem which is worse
> when it is a binding, driver and dts.
> 
> I'm open to maintaining a branch for this purpose if that helps. That
> or staggering merging of bindings and drivers/dts are the only ideas
> I've come up with.


> > How about allowing binding descriptions to be merged without the header
> > file, so long as it is merged through another tree?
> 
> I think that is wrong if we have the goal to separate bindings from
> the kernel and the bindings should stand on their own. However, if it
> greatly simplifies things, i'd be okay with that.

The header file is really the main issue we need to worry about. My preferred
way of doing this would be to give it an extra merge window: add the binding
document and the header file in one merge window, and then add the dts files
and the driver one release later. I've seen a lot of header files added for
no good reason at all, and at least that way we can get people to think about
the dependency more.

It's also ok to merge the header file and binding with either the dts file
changes or the driver and then do the other part the following release.

In the past, we've worked around the issue by merging the driver through
arm-soc, or by merging the dts changes through a driver tree, with the
appropriate Acks in each case. Both of those approaches work of course,
but the former always feels awkward to me as we are not using the right
maintainer path, and the latter approach tends to cause merge conflicts,
especially when multiple headers for different subsystems get added or
the dts files are added at the same time.

Having a shared branch for the header file is another way to do it, and
we can do that in some cases, but I'd prefer not to make it the default.

	Arnd

Re: [PATCH v2 1/3] clk: bcm2835: Add bindings for the auxiliary peripheral clock gates.

[Michael Turquette]

Hi Arnd,

Quoting Arnd Bergmann (2015-12-30 01:29:02)
> On Tuesday 29 December 2015 16:15:09 Rob Herring wrote:
> > On Mon, Dec 28, 2015 at 4:39 PM, Michael Turquette
> > <mturquette@baylibre.com> wrote:
> > > Quoting Eric Anholt (2015-12-24 15:45:15)
> > >> Michael Turquette <mturquette@baylibre.com> writes:
> > >> I would *love* to do that, but I've previously been told that having the
> > >> bindings patch reference a header file not present as of the bindings
> > >> patch is not acceptable and made to change it.
> > >
> > > Ugh, that is annoying. I would think that having code compile properly
> > > would trump the desire to have all of the documentation merged as one
> > > patch.
> > 
> > What about compiling the dts?

Oops, good point Rob.

> > 
> > > On the other hand, I've been asked to not take binding descriptions
> > > through the clk tree. That is a policy that I'm happy to comply with,
> > > but it is at odds with the recommendation for the header and the binding
> > > description to be merged together.
> > 
> > By who? Any bindings in a series I always expect the subsystem
> > maintainers to take the whole series. That doesn't solve the problem
> > though as there is still a dependency between a subsystem tree and
> > arm-soc typically.
> 
> I don't care too much which tree the binding description goes through either,
> as long as it is kept in sync.

OK, I'm happy to merge the whole enchilada.

> 
> > > DT folks, what is the right way to do this? An immutable, shared branch
> > > just for a single header file solves the problem, but also feels very
> > > cumbersome for such a trivial issue.
> > 
> > Arnd and Olof have been complaining about this problem which is worse
> > when it is a binding, driver and dts.
> > 
> > I'm open to maintaining a branch for this purpose if that helps. That
> > or staggering merging of bindings and drivers/dts are the only ideas
> > I've come up with.
> 
> 
> > > How about allowing binding descriptions to be merged without the header
> > > file, so long as it is merged through another tree?
> > 
> > I think that is wrong if we have the goal to separate bindings from
> > the kernel and the bindings should stand on their own. However, if it
> > greatly simplifies things, i'd be okay with that.
> 
> The header file is really the main issue we need to worry about. My preferred
> way of doing this would be to give it an extra merge window: add the binding
> document and the header file in one merge window, and then add the dts files
> and the driver one release later.

I'd prefer not to stagger, as it just adds unnecessary delay to getting
things upstream. And the code being merged first (the binding doc +
header) is fairly useless on its own.

> I've seen a lot of header files added for
> no good reason at all, and at least that way we can get people to think about
> the dependency more.

Do you mean you prefer to declare the magic numbers in the binding
description directly instead of using a header and relying on the C code
to stay in sync?

Or do you mean that there is no reason to declare the constants/magic
numbers in a shared way at all?

> 
> It's also ok to merge the header file and binding with either the dts file
> changes or the driver and then do the other part the following release.
> 
> In the past, we've worked around the issue by merging the driver through
> arm-soc, or by merging the dts changes through a driver tree, with the
> appropriate Acks in each case. Both of those approaches work of course,
> but the former always feels awkward to me as we are not using the right
> maintainer path, and the latter approach tends to cause merge conflicts,
> especially when multiple headers for different subsystems get added or
> the dts files are added at the same time.
> 
> Having a shared branch for the header file is another way to do it, and
> we can do that in some cases, but I'd prefer not to make it the default.

Well, I'm thinking that an immutable branch isn't such a bad idea given
that both you and Rob are OK with subsystems merging headers and binding
descriptions.

A while back Stephen Boyd and I started to use topic branches for every
driver, all based on -rc1 and merging those into clk-next. This makes it
trivial for us to push a shareable branch with minimal dependencies.

So at least for the clk tree, how do you feel about us merging driver +
header + binding description and then sharing our topic branch as-needed
with arm-soc? We could even push our topic branches by default to cut
down on coordinating over email back-and-forth.

As an example, patch #1 from the Hi3519 series[0] includes the clk
driver, binding description and a shared header. Any objection to me
taking that patch as-is, based on -rc1, and pushing out that topic
branch as clk-hi3519 to the clk git tree with the expectation that
you'll just merge that if you need to?

You can let me know if you've pulled it in, and then I won't rebase
without consulting with the arm-soc folks first.

Does this workflow agreement Solve All the Problems?

(Note that the patch I referenced is still under review so the branch
name I mentioned above doesn't exist yet. It is just an example)

[0] http://lkml.kernel.org/r/<1451439832-13927-2-git-send-email-xuejiancheng@huawei.com>

Regards,
Mike

> 
>         Arnd

[PATCH v2 1/3] clk: bcm2835: Add bindings for the auxiliary peripheral clock gates.

[Michael Turquette]

Hi Arnd,

Quoting Arnd Bergmann (2015-12-30 01:29:02)
> On Tuesday 29 December 2015 16:15:09 Rob Herring wrote:
> > On Mon, Dec 28, 2015 at 4:39 PM, Michael Turquette
> > <mturquette@baylibre.com> wrote:
> > > Quoting Eric Anholt (2015-12-24 15:45:15)
> > >> Michael Turquette <mturquette@baylibre.com> writes:
> > >> I would *love* to do that, but I've previously been told that having the
> > >> bindings patch reference a header file not present as of the bindings
> > >> patch is not acceptable and made to change it.
> > >
> > > Ugh, that is annoying. I would think that having code compile properly
> > > would trump the desire to have all of the documentation merged as one
> > > patch.
> > 
> > What about compiling the dts?

Oops, good point Rob.

> > 
> > > On the other hand, I've been asked to not take binding descriptions
> > > through the clk tree. That is a policy that I'm happy to comply with,
> > > but it is at odds with the recommendation for the header and the binding
> > > description to be merged together.
> > 
> > By who? Any bindings in a series I always expect the subsystem
> > maintainers to take the whole series. That doesn't solve the problem
> > though as there is still a dependency between a subsystem tree and
> > arm-soc typically.
> 
> I don't care too much which tree the binding description goes through either,
> as long as it is kept in sync.

OK, I'm happy to merge the whole enchilada.

> 
> > > DT folks, what is the right way to do this? An immutable, shared branch
> > > just for a single header file solves the problem, but also feels very
> > > cumbersome for such a trivial issue.
> > 
> > Arnd and Olof have been complaining about this problem which is worse
> > when it is a binding, driver and dts.
> > 
> > I'm open to maintaining a branch for this purpose if that helps. That
> > or staggering merging of bindings and drivers/dts are the only ideas
> > I've come up with.
> 
> 
> > > How about allowing binding descriptions to be merged without the header
> > > file, so long as it is merged through another tree?
> > 
> > I think that is wrong if we have the goal to separate bindings from
> > the kernel and the bindings should stand on their own. However, if it
> > greatly simplifies things, i'd be okay with that.
> 
> The header file is really the main issue we need to worry about. My preferred
> way of doing this would be to give it an extra merge window: add the binding
> document and the header file in one merge window, and then add the dts files
> and the driver one release later.

I'd prefer not to stagger, as it just adds unnecessary delay to getting
things upstream. And the code being merged first (the binding doc +
header) is fairly useless on its own.

> I've seen a lot of header files added for
> no good reason at all, and at least that way we can get people to think about
> the dependency more.

Do you mean you prefer to declare the magic numbers in the binding
description directly instead of using a header and relying on the C code
to stay in sync?

Or do you mean that there is no reason to declare the constants/magic
numbers in a shared way at all?

> 
> It's also ok to merge the header file and binding with either the dts file
> changes or the driver and then do the other part the following release.
> 
> In the past, we've worked around the issue by merging the driver through
> arm-soc, or by merging the dts changes through a driver tree, with the
> appropriate Acks in each case. Both of those approaches work of course,
> but the former always feels awkward to me as we are not using the right
> maintainer path, and the latter approach tends to cause merge conflicts,
> especially when multiple headers for different subsystems get added or
> the dts files are added at the same time.
> 
> Having a shared branch for the header file is another way to do it, and
> we can do that in some cases, but I'd prefer not to make it the default.

Well, I'm thinking that an immutable branch isn't such a bad idea given
that both you and Rob are OK with subsystems merging headers and binding
descriptions.

A while back Stephen Boyd and I started to use topic branches for every
driver, all based on -rc1 and merging those into clk-next. This makes it
trivial for us to push a shareable branch with minimal dependencies.

So at least for the clk tree, how do you feel about us merging driver +
header + binding description and then sharing our topic branch as-needed
with arm-soc? We could even push our topic branches by default to cut
down on coordinating over email back-and-forth.

As an example, patch #1 from the Hi3519 series[0] includes the clk
driver, binding description and a shared header. Any objection to me
taking that patch as-is, based on -rc1, and pushing out that topic
branch as clk-hi3519 to the clk git tree with the expectation that
you'll just merge that if you need to?

You can let me know if you've pulled it in, and then I won't rebase
without consulting with the arm-soc folks first.

Does this workflow agreement Solve All the Problems?

(Note that the patch I referenced is still under review so the branch
name I mentioned above doesn't exist yet. It is just an example)

[0] http://lkml.kernel.org/r/<1451439832-13927-2-git-send-email-xuejiancheng@huawei.com>

Regards,
Mike

> 
>         Arnd

Re: [PATCH v2 1/3] clk: bcm2835: Add bindings for the auxiliary peripheral clock gates.

[Michael Turquette]

Hi Arnd,

Quoting Arnd Bergmann (2015-12-30 01:29:02)
> On Tuesday 29 December 2015 16:15:09 Rob Herring wrote:
> > On Mon, Dec 28, 2015 at 4:39 PM, Michael Turquette
> > <mturquette@baylibre.com> wrote:
> > > Quoting Eric Anholt (2015-12-24 15:45:15)
> > >> Michael Turquette <mturquette@baylibre.com> writes:
> > >> I would *love* to do that, but I've previously been told that having=
 the
> > >> bindings patch reference a header file not present as of the bindings
> > >> patch is not acceptable and made to change it.
> > >
> > > Ugh, that is annoying. I would think that having code compile properly
> > > would trump the desire to have all of the documentation merged as one
> > > patch.
> > =

> > What about compiling the dts?

Oops, good point Rob.

> > =

> > > On the other hand, I've been asked to not take binding descriptions
> > > through the clk tree. That is a policy that I'm happy to comply with,
> > > but it is at odds with the recommendation for the header and the bind=
ing
> > > description to be merged together.
> > =

> > By who? Any bindings in a series I always expect the subsystem
> > maintainers to take the whole series. That doesn't solve the problem
> > though as there is still a dependency between a subsystem tree and
> > arm-soc typically.
> =

> I don't care too much which tree the binding description goes through eit=
her,
> as long as it is kept in sync.

OK, I'm happy to merge the whole enchilada.

> =

> > > DT folks, what is the right way to do this? An immutable, shared bran=
ch
> > > just for a single header file solves the problem, but also feels very
> > > cumbersome for such a trivial issue.
> > =

> > Arnd and Olof have been complaining about this problem which is worse
> > when it is a binding, driver and dts.
> > =

> > I'm open to maintaining a branch for this purpose if that helps. That
> > or staggering merging of bindings and drivers/dts are the only ideas
> > I've come up with.
> =

> =

> > > How about allowing binding descriptions to be merged without the head=
er
> > > file, so long as it is merged through another tree?
> > =

> > I think that is wrong if we have the goal to separate bindings from
> > the kernel and the bindings should stand on their own. However, if it
> > greatly simplifies things, i'd be okay with that.
> =

> The header file is really the main issue we need to worry about. My prefe=
rred
> way of doing this would be to give it an extra merge window: add the bind=
ing
> document and the header file in one merge window, and then add the dts fi=
les
> and the driver one release later.

I'd prefer not to stagger, as it just adds unnecessary delay to getting
things upstream. And the code being merged first (the binding doc +
header) is fairly useless on its own.

> I've seen a lot of header files added for
> no good reason at all, and at least that way we can get people to think a=
bout
> the dependency more.

Do you mean you prefer to declare the magic numbers in the binding
description directly instead of using a header and relying on the C code
to stay in sync?

Or do you mean that there is no reason to declare the constants/magic
numbers in a shared way at all?

> =

> It's also ok to merge the header file and binding with either the dts file
> changes or the driver and then do the other part the following release.
> =

> In the past, we've worked around the issue by merging the driver through
> arm-soc, or by merging the dts changes through a driver tree, with the
> appropriate Acks in each case. Both of those approaches work of course,
> but the former always feels awkward to me as we are not using the right
> maintainer path, and the latter approach tends to cause merge conflicts,
> especially when multiple headers for different subsystems get added or
> the dts files are added at the same time.
> =

> Having a shared branch for the header file is another way to do it, and
> we can do that in some cases, but I'd prefer not to make it the default.

Well, I'm thinking that an immutable branch isn't such a bad idea given
that both you and Rob are OK with subsystems merging headers and binding
descriptions.

A while back Stephen Boyd and I started to use topic branches for every
driver, all based on -rc1 and merging those into clk-next. This makes it
trivial for us to push a shareable branch with minimal dependencies.

So at least for the clk tree, how do you feel about us merging driver +
header + binding description and then sharing our topic branch as-needed
with arm-soc? We could even push our topic branches by default to cut
down on coordinating over email back-and-forth.

As an example, patch #1 from the Hi3519 series[0] includes the clk
driver, binding description and a shared header. Any objection to me
taking that patch as-is, based on -rc1, and pushing out that topic
branch as clk-hi3519 to the clk git tree with the expectation that
you'll just merge that if you need to?

You can let me know if you've pulled it in, and then I won't rebase
without consulting with the arm-soc folks first.

Does this workflow agreement Solve All the Problems?

(Note that the patch I referenced is still under review so the branch
name I mentioned above doesn't exist yet. It is just an example)

[0] http://lkml.kernel.org/r/<1451439832-13927-2-git-send-email-xuejianchen=
g@huawei.com>

Regards,
Mike

> =

>         Arnd

Re: [PATCH v2 1/3] clk: bcm2835: Add bindings for the auxiliary peripheral clock gates.

[Michael Turquette]

Hi Arnd,

Quoting Arnd Bergmann (2015-12-30 01:29:02)
> On Tuesday 29 December 2015 16:15:09 Rob Herring wrote:
> > On Mon, Dec 28, 2015 at 4:39 PM, Michael Turquette
> > <mturquette@baylibre.com> wrote:
> > > Quoting Eric Anholt (2015-12-24 15:45:15)
> > >> Michael Turquette <mturquette@baylibre.com> writes:
> > >> I would *love* to do that, but I've previously been told that having the
> > >> bindings patch reference a header file not present as of the bindings
> > >> patch is not acceptable and made to change it.
> > >
> > > Ugh, that is annoying. I would think that having code compile properly
> > > would trump the desire to have all of the documentation merged as one
> > > patch.
> > 
> > What about compiling the dts?

Oops, good point Rob.

> > 
> > > On the other hand, I've been asked to not take binding descriptions
> > > through the clk tree. That is a policy that I'm happy to comply with,
> > > but it is at odds with the recommendation for the header and the binding
> > > description to be merged together.
> > 
> > By who? Any bindings in a series I always expect the subsystem
> > maintainers to take the whole series. That doesn't solve the problem
> > though as there is still a dependency between a subsystem tree and
> > arm-soc typically.
> 
> I don't care too much which tree the binding description goes through either,
> as long as it is kept in sync.

OK, I'm happy to merge the whole enchilada.

> 
> > > DT folks, what is the right way to do this? An immutable, shared branch
> > > just for a single header file solves the problem, but also feels very
> > > cumbersome for such a trivial issue.
> > 
> > Arnd and Olof have been complaining about this problem which is worse
> > when it is a binding, driver and dts.
> > 
> > I'm open to maintaining a branch for this purpose if that helps. That
> > or staggering merging of bindings and drivers/dts are the only ideas
> > I've come up with.
> 
> 
> > > How about allowing binding descriptions to be merged without the header
> > > file, so long as it is merged through another tree?
> > 
> > I think that is wrong if we have the goal to separate bindings from
> > the kernel and the bindings should stand on their own. However, if it
> > greatly simplifies things, i'd be okay with that.
> 
> The header file is really the main issue we need to worry about. My preferred
> way of doing this would be to give it an extra merge window: add the binding
> document and the header file in one merge window, and then add the dts files
> and the driver one release later.

I'd prefer not to stagger, as it just adds unnecessary delay to getting
things upstream. And the code being merged first (the binding doc +
header) is fairly useless on its own.

> I've seen a lot of header files added for
> no good reason at all, and at least that way we can get people to think about
> the dependency more.

Do you mean you prefer to declare the magic numbers in the binding
description directly instead of using a header and relying on the C code
to stay in sync?

Or do you mean that there is no reason to declare the constants/magic
numbers in a shared way at all?

> 
> It's also ok to merge the header file and binding with either the dts file
> changes or the driver and then do the other part the following release.
> 
> In the past, we've worked around the issue by merging the driver through
> arm-soc, or by merging the dts changes through a driver tree, with the
> appropriate Acks in each case. Both of those approaches work of course,
> but the former always feels awkward to me as we are not using the right
> maintainer path, and the latter approach tends to cause merge conflicts,
> especially when multiple headers for different subsystems get added or
> the dts files are added at the same time.
> 
> Having a shared branch for the header file is another way to do it, and
> we can do that in some cases, but I'd prefer not to make it the default.

Well, I'm thinking that an immutable branch isn't such a bad idea given
that both you and Rob are OK with subsystems merging headers and binding
descriptions.

A while back Stephen Boyd and I started to use topic branches for every
driver, all based on -rc1 and merging those into clk-next. This makes it
trivial for us to push a shareable branch with minimal dependencies.

So at least for the clk tree, how do you feel about us merging driver +
header + binding description and then sharing our topic branch as-needed
with arm-soc? We could even push our topic branches by default to cut
down on coordinating over email back-and-forth.

As an example, patch #1 from the Hi3519 series[0] includes the clk
driver, binding description and a shared header. Any objection to me
taking that patch as-is, based on -rc1, and pushing out that topic
branch as clk-hi3519 to the clk git tree with the expectation that
you'll just merge that if you need to?

You can let me know if you've pulled it in, and then I won't rebase
without consulting with the arm-soc folks first.

Does this workflow agreement Solve All the Problems?

(Note that the patch I referenced is still under review so the branch
name I mentioned above doesn't exist yet. It is just an example)

[0] http://lkml.kernel.org/r/<1451439832-13927-2-git-send-email-xuejiancheng@huawei.com>

Regards,
Mike

> 
>         Arnd

Re: [PATCH v2 1/3] clk: bcm2835: Add bindings for the auxiliary peripheral clock gates.

[Eric Anholt]

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

Michael Turquette <mturquette@baylibre.com> writes:

> Hi Arnd,
>
> Quoting Arnd Bergmann (2015-12-30 01:29:02)
>> It's also ok to merge the header file and binding with either the dts file
>> changes or the driver and then do the other part the following release.
>> 
>> In the past, we've worked around the issue by merging the driver through
>> arm-soc, or by merging the dts changes through a driver tree, with the
>> appropriate Acks in each case. Both of those approaches work of course,
>> but the former always feels awkward to me as we are not using the right
>> maintainer path, and the latter approach tends to cause merge conflicts,
>> especially when multiple headers for different subsystems get added or
>> the dts files are added at the same time.
>> 
>> Having a shared branch for the header file is another way to do it, and
>> we can do that in some cases, but I'd prefer not to make it the default.
>
> Well, I'm thinking that an immutable branch isn't such a bad idea given
> that both you and Rob are OK with subsystems merging headers and binding
> descriptions.
>
> A while back Stephen Boyd and I started to use topic branches for every
> driver, all based on -rc1 and merging those into clk-next. This makes it
> trivial for us to push a shareable branch with minimal dependencies.
>
> So at least for the clk tree, how do you feel about us merging driver +
> header + binding description and then sharing our topic branch as-needed
> with arm-soc? We could even push our topic branches by default to cut
> down on coordinating over email back-and-forth.
>
> As an example, patch #1 from the Hi3519 series[0] includes the clk
> driver, binding description and a shared header. Any objection to me
> taking that patch as-is, based on -rc1, and pushing out that topic
> branch as clk-hi3519 to the clk git tree with the expectation that
> you'll just merge that if you need to?
>
> You can let me know if you've pulled it in, and then I won't rebase
> without consulting with the arm-soc folks first.
>
> Does this workflow agreement Solve All the Problems?
>
> (Note that the patch I referenced is still under review so the branch
> name I mentioned above doesn't exist yet. It is just an example)

For what it's worth, this is a nice workflow for me as a driver
developer.  I have a couple of .dts patches that ended up waiting this
cycle because I didn't have the shareable branches necessary.

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

[PATCH v2 1/3] clk: bcm2835: Add bindings for the auxiliary peripheral clock gates.

[Eric Anholt]

Michael Turquette <mturquette@baylibre.com> writes:

> Hi Arnd,
>
> Quoting Arnd Bergmann (2015-12-30 01:29:02)
>> It's also ok to merge the header file and binding with either the dts file
>> changes or the driver and then do the other part the following release.
>> 
>> In the past, we've worked around the issue by merging the driver through
>> arm-soc, or by merging the dts changes through a driver tree, with the
>> appropriate Acks in each case. Both of those approaches work of course,
>> but the former always feels awkward to me as we are not using the right
>> maintainer path, and the latter approach tends to cause merge conflicts,
>> especially when multiple headers for different subsystems get added or
>> the dts files are added at the same time.
>> 
>> Having a shared branch for the header file is another way to do it, and
>> we can do that in some cases, but I'd prefer not to make it the default.
>
> Well, I'm thinking that an immutable branch isn't such a bad idea given
> that both you and Rob are OK with subsystems merging headers and binding
> descriptions.
>
> A while back Stephen Boyd and I started to use topic branches for every
> driver, all based on -rc1 and merging those into clk-next. This makes it
> trivial for us to push a shareable branch with minimal dependencies.
>
> So at least for the clk tree, how do you feel about us merging driver +
> header + binding description and then sharing our topic branch as-needed
> with arm-soc? We could even push our topic branches by default to cut
> down on coordinating over email back-and-forth.
>
> As an example, patch #1 from the Hi3519 series[0] includes the clk
> driver, binding description and a shared header. Any objection to me
> taking that patch as-is, based on -rc1, and pushing out that topic
> branch as clk-hi3519 to the clk git tree with the expectation that
> you'll just merge that if you need to?
>
> You can let me know if you've pulled it in, and then I won't rebase
> without consulting with the arm-soc folks first.
>
> Does this workflow agreement Solve All the Problems?
>
> (Note that the patch I referenced is still under review so the branch
> name I mentioned above doesn't exist yet. It is just an example)

For what it's worth, this is a nice workflow for me as a driver
developer.  I have a couple of .dts patches that ended up waiting this
cycle because I didn't have the shareable branches necessary.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 818 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160102/ac1cdc76/attachment.sig>

Re: [PATCH v2 1/3] clk: bcm2835: Add bindings for the auxiliary peripheral clock gates.

[Eric Anholt]

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

Michael Turquette <mturquette@baylibre.com> writes:

> Hi Arnd,
>
> Quoting Arnd Bergmann (2015-12-30 01:29:02)
>> It's also ok to merge the header file and binding with either the dts file
>> changes or the driver and then do the other part the following release.
>> 
>> In the past, we've worked around the issue by merging the driver through
>> arm-soc, or by merging the dts changes through a driver tree, with the
>> appropriate Acks in each case. Both of those approaches work of course,
>> but the former always feels awkward to me as we are not using the right
>> maintainer path, and the latter approach tends to cause merge conflicts,
>> especially when multiple headers for different subsystems get added or
>> the dts files are added at the same time.
>> 
>> Having a shared branch for the header file is another way to do it, and
>> we can do that in some cases, but I'd prefer not to make it the default.
>
> Well, I'm thinking that an immutable branch isn't such a bad idea given
> that both you and Rob are OK with subsystems merging headers and binding
> descriptions.
>
> A while back Stephen Boyd and I started to use topic branches for every
> driver, all based on -rc1 and merging those into clk-next. This makes it
> trivial for us to push a shareable branch with minimal dependencies.
>
> So at least for the clk tree, how do you feel about us merging driver +
> header + binding description and then sharing our topic branch as-needed
> with arm-soc? We could even push our topic branches by default to cut
> down on coordinating over email back-and-forth.
>
> As an example, patch #1 from the Hi3519 series[0] includes the clk
> driver, binding description and a shared header. Any objection to me
> taking that patch as-is, based on -rc1, and pushing out that topic
> branch as clk-hi3519 to the clk git tree with the expectation that
> you'll just merge that if you need to?
>
> You can let me know if you've pulled it in, and then I won't rebase
> without consulting with the arm-soc folks first.
>
> Does this workflow agreement Solve All the Problems?
>
> (Note that the patch I referenced is still under review so the branch
> name I mentioned above doesn't exist yet. It is just an example)

For what it's worth, this is a nice workflow for me as a driver
developer.  I have a couple of .dts patches that ended up waiting this
cycle because I didn't have the shareable branches necessary.

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

Re: [PATCH v2 1/3] clk: bcm2835: Add bindings for the auxiliary peripheral clock gates.

[Eric Anholt]

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

Michael Turquette <mturquette@baylibre.com> writes:

> Hi Arnd,
>
> Quoting Arnd Bergmann (2015-12-30 01:29:02)
>> It's also ok to merge the header file and binding with either the dts file
>> changes or the driver and then do the other part the following release.
>> 
>> In the past, we've worked around the issue by merging the driver through
>> arm-soc, or by merging the dts changes through a driver tree, with the
>> appropriate Acks in each case. Both of those approaches work of course,
>> but the former always feels awkward to me as we are not using the right
>> maintainer path, and the latter approach tends to cause merge conflicts,
>> especially when multiple headers for different subsystems get added or
>> the dts files are added at the same time.
>> 
>> Having a shared branch for the header file is another way to do it, and
>> we can do that in some cases, but I'd prefer not to make it the default.
>
> Well, I'm thinking that an immutable branch isn't such a bad idea given
> that both you and Rob are OK with subsystems merging headers and binding
> descriptions.
>
> A while back Stephen Boyd and I started to use topic branches for every
> driver, all based on -rc1 and merging those into clk-next. This makes it
> trivial for us to push a shareable branch with minimal dependencies.
>
> So at least for the clk tree, how do you feel about us merging driver +
> header + binding description and then sharing our topic branch as-needed
> with arm-soc? We could even push our topic branches by default to cut
> down on coordinating over email back-and-forth.
>
> As an example, patch #1 from the Hi3519 series[0] includes the clk
> driver, binding description and a shared header. Any objection to me
> taking that patch as-is, based on -rc1, and pushing out that topic
> branch as clk-hi3519 to the clk git tree with the expectation that
> you'll just merge that if you need to?
>
> You can let me know if you've pulled it in, and then I won't rebase
> without consulting with the arm-soc folks first.
>
> Does this workflow agreement Solve All the Problems?
>
> (Note that the patch I referenced is still under review so the branch
> name I mentioned above doesn't exist yet. It is just an example)

For what it's worth, this is a nice workflow for me as a driver
developer.  I have a couple of .dts patches that ended up waiting this
cycle because I didn't have the shareable branches necessary.

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