All of lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH 0/5] simple-mfd and syscon LEDs
@ 2015-03-03  9:32 Linus Walleij
       [not found] ` <1425375148-4369-1-git-send-email-linus.walleij-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
                   ` (4 more replies)
  0 siblings, 5 replies; 40+ messages in thread
From: Linus Walleij @ 2015-03-03  9:32 UTC (permalink / raw)
  To: linux-arm-kernel

This patch series implements a suggestion from Lee Jones on how to
resolve the dilemma with subnodes under syscons that do things like
the simple syscon LEDs.

Please see the bigger picture, this is not about LEDs only but any
simple subnodes under an MFD.

Linus Walleij (5):
  MFD/OF: document MFD devices and handle simple-mfd
  ARM: dts: update syscons to use simple-mfd
  leds: syscon: instantiate from platform device
  arm64: juno: Add APB registers and LEDs using syscon
  arm64: add LEDs and some trigger support to defconfig

 Documentation/devicetree/bindings/mfd/mfd.txt |  40 ++++++
 arch/arm/boot/dts/arm-realview-pb1176.dts     |   2 +-
 arch/arm/boot/dts/integrator.dtsi             |   4 +-
 arch/arm64/boot/dts/arm/juno-motherboard.dtsi |  68 +++++++++++
 arch/arm64/configs/defconfig                  |   6 +
 drivers/leds/leds-syscon.c                    | 170 +++++++++++++-------------
 drivers/of/platform.c                         |   1 +
 7 files changed, 203 insertions(+), 88 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/mfd/mfd.txt

-- 
1.9.3

^ permalink raw reply	[flat|nested] 40+ messages in thread

* [PATCH 1/5] MFD/OF: document MFD devices and handle simple-mfd
  2015-03-03  9:32 [PATCH 0/5] simple-mfd and syscon LEDs Linus Walleij
@ 2015-03-03  9:32     ` Linus Walleij
  2015-03-03  9:32 ` [PATCH 2/5] ARM: dts: update syscons to use simple-mfd Linus Walleij
                       ` (3 subsequent siblings)
  4 siblings, 0 replies; 40+ messages in thread
From: Linus Walleij @ 2015-03-03  9:32 UTC (permalink / raw)
  To: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Arnd Bergmann,
	Lee Jones, Bryan Wu
  Cc: Catalin Marinas, Will Deacon, Richard Purdie, Linus Walleij,
	Devicetree, Rob Herring, Benjamin Herrenschmidt, Grant Likely,
	Pawel Moll, Mark Rutland, Ian Campbell, Kumar Gala

This defines a new compatible option for MFD devices "simple-mfd" that will
make the OF core spawn child devices for all subnodes of that MFD device.
It is optional but handy for things like syscon and possibly other
simpler MFD devices.

Since there was no file to put the documentation in, I took this opportunity
to make a small writeup on MFD devices and add the compatible definition
there.

Suggested-by: Lee Jones <lee.jones-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
Cc: Arnd Bergmann <arnd-r2nGTMty4D4@public.gmane.org>
Cc: Devicetree <devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>
Cc: Rob Herring <robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
Cc: Benjamin Herrenschmidt <benh-XVmvHMARGAS8U2dJNN8I7kB+6BGkLq7r@public.gmane.org>
Cc: Grant Likely <grant.likely-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
Cc: Pawel Moll <pawel.moll-5wv7dgnIgG8@public.gmane.org>
Cc: Mark Rutland <mark.rutland-5wv7dgnIgG8@public.gmane.org>
Cc: Ian Campbell <ijc+devicetree-KcIKpvwj1kUDXYZnReoRVg@public.gmane.org>
Cc: Kumar Gala <galak-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
Signed-off-by: Linus Walleij <linus.walleij-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
---
I make the patch to the OF core in this one, it makes much more sense since
it's a oneliner

Lee: this is a (tested!) implementation of your suggestion for simple-mfd.
If you can eventually ACK this from the MFD side, I think it should be
funneled through the ARM SoC tree.

Grant/Rob: if either of you can ACK the change to the OF core likewise it can
be taken through ARM SoC.

DT binings maintainers: there is some background discussion on this here:
http://marc.info/?l=linux-arm-kernel&m=142486676603889&w=2
http://marc.info/?l=devicetree&m=142166313621469&w=2
---
 Documentation/devicetree/bindings/mfd/mfd.txt | 40 +++++++++++++++++++++++++++
 drivers/of/platform.c                         |  1 +
 2 files changed, 41 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/mfd/mfd.txt

diff --git a/Documentation/devicetree/bindings/mfd/mfd.txt b/Documentation/devicetree/bindings/mfd/mfd.txt
new file mode 100644
index 000000000000..cc057438abe8
--- /dev/null
+++ b/Documentation/devicetree/bindings/mfd/mfd.txt
@@ -0,0 +1,40 @@
+Multi-Function Devices (MFD)
+
+These devices comprise a nexus for heterogeneous hardware blocks spawning
+multiple child devices.
+
+A typical MFD can be:
+
+- A mixed signal ASIC on an external bus, sometimes a PMIC (power management
+  integrated circuit) that is manufactured in a lower technology node (rough
+  silicon) that handles analog drivers for things like audio amplifiers, LED
+  drivers, level shifters, PHY (physical interfaces to things like USB or
+  ethernet), regulators etc.
+
+- A range of memory registers containing "miscellaneous system registers" also
+  known as a system controller "syscon" or any other memory range containing a
+  mix of unrelated registers.
+
+Optional properties:
+
+- compatible : "simple-mfd" - this signifies that the operating system should
+  spawn child devices for all the subnodes of the MFD device akin to how
+  "simple-bus" inidicates when to spawn children for a simple memory-mapped
+  bus. For more complex devices, when the nexus driver has to probe registers
+  to figure out what children exist etc, this should not be used. In the latter
+  case the child devices will be instantiated by the operating system.
+
+Example:
+
+foo@1000 {
+		compatible = "syscon", "simple-mfd";
+		reg = <0x010000 0x1000>;
+
+		led@08.0 {
+			compatible = "register-bit-led";
+			offset = <0x08>;
+			mask = <0x01>;
+			label = "myled";
+			default-state = "on";
+		};
+};
diff --git a/drivers/of/platform.c b/drivers/of/platform.c
index b189733a1539..969ba4e1460c 100644
--- a/drivers/of/platform.c
+++ b/drivers/of/platform.c
@@ -26,6 +26,7 @@
 
 const struct of_device_id of_default_bus_match_table[] = {
 	{ .compatible = "simple-bus", },
+	{ .compatible = "simple-mfd", },
 #ifdef CONFIG_ARM_AMBA
 	{ .compatible = "arm,amba-bus", },
 #endif /* CONFIG_ARM_AMBA */
-- 
1.9.3

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

^ permalink raw reply related	[flat|nested] 40+ messages in thread

* [PATCH 1/5] MFD/OF: document MFD devices and handle simple-mfd
@ 2015-03-03  9:32     ` Linus Walleij
  0 siblings, 0 replies; 40+ messages in thread
From: Linus Walleij @ 2015-03-03  9:32 UTC (permalink / raw)
  To: linux-arm-kernel

This defines a new compatible option for MFD devices "simple-mfd" that will
make the OF core spawn child devices for all subnodes of that MFD device.
It is optional but handy for things like syscon and possibly other
simpler MFD devices.

Since there was no file to put the documentation in, I took this opportunity
to make a small writeup on MFD devices and add the compatible definition
there.

Suggested-by: Lee Jones <lee.jones@linaro.org>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Devicetree <devicetree@vger.kernel.org>
Cc: Rob Herring <robh+dt@kernel.org>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Grant Likely <grant.likely@linaro.org>
Cc: Pawel Moll <pawel.moll@arm.com>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Ian Campbell <ijc+devicetree@hellion.org.uk>
Cc: Kumar Gala <galak@codeaurora.org>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
---
I make the patch to the OF core in this one, it makes much more sense since
it's a oneliner

Lee: this is a (tested!) implementation of your suggestion for simple-mfd.
If you can eventually ACK this from the MFD side, I think it should be
funneled through the ARM SoC tree.

Grant/Rob: if either of you can ACK the change to the OF core likewise it can
be taken through ARM SoC.

DT binings maintainers: there is some background discussion on this here:
http://marc.info/?l=linux-arm-kernel&m=142486676603889&w=2
http://marc.info/?l=devicetree&m=142166313621469&w=2
---
 Documentation/devicetree/bindings/mfd/mfd.txt | 40 +++++++++++++++++++++++++++
 drivers/of/platform.c                         |  1 +
 2 files changed, 41 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/mfd/mfd.txt

diff --git a/Documentation/devicetree/bindings/mfd/mfd.txt b/Documentation/devicetree/bindings/mfd/mfd.txt
new file mode 100644
index 000000000000..cc057438abe8
--- /dev/null
+++ b/Documentation/devicetree/bindings/mfd/mfd.txt
@@ -0,0 +1,40 @@
+Multi-Function Devices (MFD)
+
+These devices comprise a nexus for heterogeneous hardware blocks spawning
+multiple child devices.
+
+A typical MFD can be:
+
+- A mixed signal ASIC on an external bus, sometimes a PMIC (power management
+  integrated circuit) that is manufactured in a lower technology node (rough
+  silicon) that handles analog drivers for things like audio amplifiers, LED
+  drivers, level shifters, PHY (physical interfaces to things like USB or
+  ethernet), regulators etc.
+
+- A range of memory registers containing "miscellaneous system registers" also
+  known as a system controller "syscon" or any other memory range containing a
+  mix of unrelated registers.
+
+Optional properties:
+
+- compatible : "simple-mfd" - this signifies that the operating system should
+  spawn child devices for all the subnodes of the MFD device akin to how
+  "simple-bus" inidicates when to spawn children for a simple memory-mapped
+  bus. For more complex devices, when the nexus driver has to probe registers
+  to figure out what children exist etc, this should not be used. In the latter
+  case the child devices will be instantiated by the operating system.
+
+Example:
+
+foo at 1000 {
+		compatible = "syscon", "simple-mfd";
+		reg = <0x010000 0x1000>;
+
+		led at 08.0 {
+			compatible = "register-bit-led";
+			offset = <0x08>;
+			mask = <0x01>;
+			label = "myled";
+			default-state = "on";
+		};
+};
diff --git a/drivers/of/platform.c b/drivers/of/platform.c
index b189733a1539..969ba4e1460c 100644
--- a/drivers/of/platform.c
+++ b/drivers/of/platform.c
@@ -26,6 +26,7 @@
 
 const struct of_device_id of_default_bus_match_table[] = {
 	{ .compatible = "simple-bus", },
+	{ .compatible = "simple-mfd", },
 #ifdef CONFIG_ARM_AMBA
 	{ .compatible = "arm,amba-bus", },
 #endif /* CONFIG_ARM_AMBA */
-- 
1.9.3

^ permalink raw reply related	[flat|nested] 40+ messages in thread

* [PATCH 2/5] ARM: dts: update syscons to use simple-mfd
  2015-03-03  9:32 [PATCH 0/5] simple-mfd and syscon LEDs Linus Walleij
       [not found] ` <1425375148-4369-1-git-send-email-linus.walleij-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
@ 2015-03-03  9:32 ` Linus Walleij
  2015-03-03  9:32 ` [PATCH 3/5] leds: syscon: instantiate from platform device Linus Walleij
                   ` (2 subsequent siblings)
  4 siblings, 0 replies; 40+ messages in thread
From: Linus Walleij @ 2015-03-03  9:32 UTC (permalink / raw)
  To: linux-arm-kernel

The Integrators and the RealView use simple MFD devices with register bit
LEDs as subnodes, update these to use the "simple-mfd" compatible property
so that subdevices get spawned from the MFD nexi.

Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Lee Jones <lee.jones@linaro.org>
Cc: Pawel Moll <pawel.moll@arm.com>
Cc: Mark Rutland <mark.rutland@arm.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
---
 arch/arm/boot/dts/arm-realview-pb1176.dts | 2 +-
 arch/arm/boot/dts/integrator.dtsi         | 4 ++--
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/arch/arm/boot/dts/arm-realview-pb1176.dts b/arch/arm/boot/dts/arm-realview-pb1176.dts
index ff26c7ed8c41..1bc64cda819e 100644
--- a/arch/arm/boot/dts/arm-realview-pb1176.dts
+++ b/arch/arm/boot/dts/arm-realview-pb1176.dts
@@ -114,7 +114,7 @@
 		ranges;
 
 		syscon: syscon at 10000000 {
-			compatible = "arm,realview-pb1176-syscon", "syscon";
+			compatible = "arm,realview-pb1176-syscon", "syscon", "simple-mfd";
 			reg = <0x10000000 0x1000>;
 
 			led at 08.0 {
diff --git a/arch/arm/boot/dts/integrator.dtsi b/arch/arm/boot/dts/integrator.dtsi
index 28e38f8c6b0f..3807d4f46ef7 100644
--- a/arch/arm/boot/dts/integrator.dtsi
+++ b/arch/arm/boot/dts/integrator.dtsi
@@ -6,7 +6,7 @@
 
 / {
 	core-module at 10000000 {
-		compatible = "arm,core-module-integrator", "syscon";
+		compatible = "arm,core-module-integrator", "syscon", "simple-mfd";
 		reg = <0x10000000 0x200>;
 
 		/* Use core module LED to indicate CPU load */
@@ -95,7 +95,7 @@
 
 		syscon {
 			/* Debug registers mapped as syscon */
-			compatible = "syscon";
+			compatible = "syscon", "simple-mfd";
 			reg = <0x1a000000 0x10>;
 
 			led at 04.0 {
-- 
1.9.3

^ permalink raw reply related	[flat|nested] 40+ messages in thread

* [PATCH 3/5] leds: syscon: instantiate from platform device
  2015-03-03  9:32 [PATCH 0/5] simple-mfd and syscon LEDs Linus Walleij
       [not found] ` <1425375148-4369-1-git-send-email-linus.walleij-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
  2015-03-03  9:32 ` [PATCH 2/5] ARM: dts: update syscons to use simple-mfd Linus Walleij
@ 2015-03-03  9:32 ` Linus Walleij
  2015-03-17 10:36   ` Linus Walleij
  2015-03-24 16:50   ` Bjorn Andersson
  2015-03-03  9:32 ` [PATCH 4/5] arm64: juno: Add APB registers and LEDs using syscon Linus Walleij
  2015-03-03  9:32 ` [PATCH 5/5] arm64: add LEDs and some trigger support to defconfig Linus Walleij
  4 siblings, 2 replies; 40+ messages in thread
From: Linus Walleij @ 2015-03-03  9:32 UTC (permalink / raw)
  To: linux-arm-kernel

Currently syscon LEDs will traverse the device tree looking for syscon devices
and if found, traverse any subnodes of these to identify matching children
and from there instantiate LED class devices.

This is not a good use of the Linux device model. Instead we have converted the
device trees to add the "simple-mfd" property to the MFD nexi spawning syscon
LEDs so that these will appear as platform devices in the system and we can
use the proper device probing mechanism.

Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Lee Jones <lee.jones@linaro.org>
Cc: Pawel Moll <pawel.moll@arm.com>
Cc: Mark Rutland <mark.rutland@arm.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
---
Bryan: if you're OK with it, please ACK this patch so we can funnel it through
ARM SoC with the rest of the patches in this series.
---
 drivers/leds/leds-syscon.c | 170 ++++++++++++++++++++++-----------------------
 1 file changed, 85 insertions(+), 85 deletions(-)

diff --git a/drivers/leds/leds-syscon.c b/drivers/leds/leds-syscon.c
index 6896e2d9ba58..d1660b039812 100644
--- a/drivers/leds/leds-syscon.c
+++ b/drivers/leds/leds-syscon.c
@@ -20,6 +20,7 @@
  * MA 02111-1307 USA
  */
 #include <linux/io.h>
+#include <linux/module.h>
 #include <linux/of_device.h>
 #include <linux/of_address.h>
 #include <linux/platform_device.h>
@@ -66,102 +67,101 @@ static void syscon_led_set(struct led_classdev *led_cdev,
 		dev_err(sled->cdev.dev, "error updating LED status\n");
 }
 
-static int __init syscon_leds_spawn(struct device_node *np,
-				    struct device *dev,
-				    struct regmap *map)
+static int syscon_led_probe(struct platform_device *pdev)
 {
-	struct device_node *child;
+	struct device *dev = &pdev->dev;
+	struct device_node *np = dev->of_node;
+	struct device *parent;
+	struct regmap *map;
+	struct syscon_led *sled;
+	const char *state;
 	int ret;
 
-	for_each_available_child_of_node(np, child) {
-		struct syscon_led *sled;
-		const char *state;
-
-		/* Only check for register-bit-leds */
-		if (of_property_match_string(child, "compatible",
-					     "register-bit-led") < 0)
-			continue;
-
-		sled = devm_kzalloc(dev, sizeof(*sled), GFP_KERNEL);
-		if (!sled)
-			return -ENOMEM;
-
-		sled->map = map;
-
-		if (of_property_read_u32(child, "offset", &sled->offset))
-			return -EINVAL;
-		if (of_property_read_u32(child, "mask", &sled->mask))
-			return -EINVAL;
-		sled->cdev.name =
-			of_get_property(child, "label", NULL) ? : child->name;
-		sled->cdev.default_trigger =
-			of_get_property(child, "linux,default-trigger", NULL);
-
-		state = of_get_property(child, "default-state", NULL);
-		if (state) {
-			if (!strcmp(state, "keep")) {
-				u32 val;
-
-				ret = regmap_read(map, sled->offset, &val);
-				if (ret < 0)
-					return ret;
-				sled->state = !!(val & sled->mask);
-			} else if (!strcmp(state, "on")) {
-				sled->state = true;
-				ret = regmap_update_bits(map, sled->offset,
-							 sled->mask,
-							 sled->mask);
-				if (ret < 0)
-					return ret;
-			} else {
-				sled->state = false;
-				ret = regmap_update_bits(map, sled->offset,
-							 sled->mask, 0);
-				if (ret < 0)
-					return ret;
-			}
+	parent = dev->parent;
+	if (!parent) {
+		dev_err(dev, "no parent for syscon LED\n");
+		return -ENODEV;
+	}
+	map = syscon_node_to_regmap(parent->of_node);
+	if (!map) {
+		dev_err(dev, "no regmap for syscon LED parent\n");
+		return -ENODEV;
+	}
+
+	sled = devm_kzalloc(dev, sizeof(*sled), GFP_KERNEL);
+	if (!sled)
+		return -ENOMEM;
+
+	sled->map = map;
+
+	if (of_property_read_u32(np, "offset", &sled->offset))
+		return -EINVAL;
+	if (of_property_read_u32(np, "mask", &sled->mask))
+		return -EINVAL;
+	sled->cdev.name =
+		of_get_property(np, "label", NULL) ? : np->name;
+	sled->cdev.default_trigger =
+		of_get_property(np, "linux,default-trigger", NULL);
+
+	state = of_get_property(np, "default-state", NULL);
+	if (state) {
+		if (!strcmp(state, "keep")) {
+			u32 val;
+
+			ret = regmap_read(map, sled->offset, &val);
+			if (ret < 0)
+				return ret;
+			sled->state = !!(val & sled->mask);
+		} else if (!strcmp(state, "on")) {
+			sled->state = true;
+			ret = regmap_update_bits(map, sled->offset,
+						 sled->mask,
+						 sled->mask);
+			if (ret < 0)
+				return ret;
+		} else {
+			sled->state = false;
+			ret = regmap_update_bits(map, sled->offset,
+						 sled->mask, 0);
+			if (ret < 0)
+				return ret;
 		}
-		sled->cdev.brightness_set = syscon_led_set;
+	}
+	sled->cdev.brightness_set = syscon_led_set;
 
-		ret = led_classdev_register(dev, &sled->cdev);
-		if (ret < 0)
-			return ret;
+	ret = led_classdev_register(dev, &sled->cdev);
+	if (ret < 0)
+		return ret;
+
+	platform_set_drvdata(pdev, sled);
+	dev_info(dev, "registered LED %s\n", sled->cdev.name);
 
-		dev_info(dev, "registered LED %s\n", sled->cdev.name);
-	}
 	return 0;
 }
 
-static int __init syscon_leds_init(void)
+static int syscon_led_remove(struct platform_device *pdev)
 {
-	struct device_node *np;
-
-	for_each_of_allnodes(np) {
-		struct platform_device *pdev;
-		struct regmap *map;
-		int ret;
+	struct syscon_led *sled = platform_get_drvdata(pdev);
 
-		if (!of_device_is_compatible(np, "syscon"))
-			continue;
+	led_classdev_unregister(&sled->cdev);
+	/* Turn it off */
+	regmap_update_bits(sled->map, sled->offset, sled->mask, 0);
+	return 0;
+}
 
-		map = syscon_node_to_regmap(np);
-		if (IS_ERR(map)) {
-			pr_err("error getting regmap for syscon LEDs\n");
-			continue;
-		}
+static const struct of_device_id of_syscon_leds_match[] = {
+	{ .compatible = "register-bit-led", },
+	{},
+};
 
-		/*
-		 * If the map is there, the device should be there, we allocate
-		 * memory on the syscon device's behalf here.
-		 */
-		pdev = of_find_device_by_node(np);
-		if (!pdev)
-			return -ENODEV;
-		ret = syscon_leds_spawn(np, &pdev->dev, map);
-		if (ret)
-			dev_err(&pdev->dev, "could not spawn syscon LEDs\n");
-	}
+MODULE_DEVICE_TABLE(of, of_syscon_leds_match);
 
-	return 0;
-}
-device_initcall(syscon_leds_init);
+static struct platform_driver syscon_led_driver = {
+	.probe		= syscon_led_probe,
+	.remove		= syscon_led_remove,
+	.driver		= {
+		.name	= "leds-syscon",
+		.of_match_table = of_syscon_leds_match,
+	},
+};
+module_platform_driver(syscon_led_driver);
-- 
1.9.3

^ permalink raw reply related	[flat|nested] 40+ messages in thread

* [PATCH 4/5] arm64: juno: Add APB registers and LEDs using syscon
  2015-03-03  9:32 [PATCH 0/5] simple-mfd and syscon LEDs Linus Walleij
                   ` (2 preceding siblings ...)
  2015-03-03  9:32 ` [PATCH 3/5] leds: syscon: instantiate from platform device Linus Walleij
@ 2015-03-03  9:32 ` Linus Walleij
  2015-03-04 15:57   ` Liviu Dudau
  2015-03-03  9:32 ` [PATCH 5/5] arm64: add LEDs and some trigger support to defconfig Linus Walleij
  4 siblings, 1 reply; 40+ messages in thread
From: Linus Walleij @ 2015-03-03  9:32 UTC (permalink / raw)
  To: linux-arm-kernel

This defines the Juno "APB system registers" as a syscon device,
and all the LEDs controlled by the APB system registers right
below it using the syscon LEDs driver on top of syscon. Define
LED0 for heartbeat, LED1 for MMC0 activity and the following
four LEDs indicating CPU activity using the Linux-specific
DT bindings for triggers.

This is the pattern and same drivers as used on the legacy
platform device trees for the ARM Integrators and the RealView
PB1176.

Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Liviu Dudau <Liviu.Dudau@arm.com>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Robin Murphy <robin.murphy@arm.com>
Cc: Pawel Moll <pawel.moll@arm.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
---
ChangeLog v1->v2:
- Use "simple-mfd" so that the syscon LEDs get spawned from the
  syscon as sub-platform devices.
---
 arch/arm64/boot/dts/arm/juno-motherboard.dtsi | 68 +++++++++++++++++++++++++++
 1 file changed, 68 insertions(+)

diff --git a/arch/arm64/boot/dts/arm/juno-motherboard.dtsi b/arch/arm64/boot/dts/arm/juno-motherboard.dtsi
index c138b95a8356..5ce111dcf16d 100644
--- a/arch/arm64/boot/dts/arm/juno-motherboard.dtsi
+++ b/arch/arm64/boot/dts/arm/juno-motherboard.dtsi
@@ -66,6 +66,74 @@
 				#size-cells = <1>;
 				ranges = <0 3 0 0x200000>;
 
+				apbregs at 010000 {
+					compatible = "syscon", "simple-mfd";
+					reg = <0x010000 0x1000>;
+
+					led at 08.0 {
+						compatible = "register-bit-led";
+						offset = <0x08>;
+						mask = <0x01>;
+						label = "vexpress:0";
+						linux,default-trigger = "heartbeat";
+						default-state = "on";
+					};
+					led at 08.1 {
+						compatible = "register-bit-led";
+						offset = <0x08>;
+						mask = <0x02>;
+						label = "vexpress:1";
+						linux,default-trigger = "mmc0";
+						default-state = "off";
+					};
+					led at 08.2 {
+						compatible = "register-bit-led";
+						offset = <0x08>;
+						mask = <0x04>;
+						label = "vexpress:2";
+						linux,default-trigger = "cpu0";
+						default-state = "off";
+					};
+					led at 08.3 {
+						compatible = "register-bit-led";
+						offset = <0x08>;
+						mask = <0x08>;
+						label = "vexpress:3";
+						linux,default-trigger = "cpu1";
+						default-state = "off";
+					};
+					led at 08.4 {
+						compatible = "register-bit-led";
+						offset = <0x08>;
+						mask = <0x10>;
+						label = "vexpress:4";
+						linux,default-trigger = "cpu2";
+						default-state = "off";
+					};
+					led at 08.5 {
+						compatible = "register-bit-led";
+						offset = <0x08>;
+						mask = <0x20>;
+						label = "vexpress:5";
+						linux,default-trigger = "cpu3";
+						default-state = "off";
+					};
+					led at 08.6 {
+						compatible = "register-bit-led";
+						offset = <0x08>;
+						mask = <0x40>;
+						label = "vexpress:6";
+						default-state = "off";
+					};
+					led at 08.7 {
+						compatible = "register-bit-led";
+						offset = <0x08>;
+						mask = <0x80>;
+						label = "vexpress:7";
+						default-state = "off";
+					};
+				};
+
 				mmci at 050000 {
 					compatible = "arm,pl180", "arm,primecell";
 					reg = <0x050000 0x1000>;
-- 
1.9.3

^ permalink raw reply related	[flat|nested] 40+ messages in thread

* [PATCH 5/5] arm64: add LEDs and some trigger support to defconfig
  2015-03-03  9:32 [PATCH 0/5] simple-mfd and syscon LEDs Linus Walleij
                   ` (3 preceding siblings ...)
  2015-03-03  9:32 ` [PATCH 4/5] arm64: juno: Add APB registers and LEDs using syscon Linus Walleij
@ 2015-03-03  9:32 ` Linus Walleij
  4 siblings, 0 replies; 40+ messages in thread
From: Linus Walleij @ 2015-03-03  9:32 UTC (permalink / raw)
  To: linux-arm-kernel

Since many boards for ARM, experimental or server alike, will
feature LEDs, let's include LED class and trigger support for
heartbeat and CPU in the defconfig. Many systems (such as the
ARM Juno) will use a system controller "syscon" to access the
LED registers, so include support for this as well.

Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Liviu Dudau <Liviu.Dudau@arm.com>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Robin Murphy <robin.murphy@arm.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
---
 arch/arm64/configs/defconfig | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
index be1f12a5a5f0..b715e194034c 100644
--- a/arch/arm64/configs/defconfig
+++ b/arch/arm64/configs/defconfig
@@ -122,6 +122,12 @@ CONFIG_MMC_ARMMMCI=y
 CONFIG_MMC_SDHCI=y
 CONFIG_MMC_SDHCI_PLTFM=y
 CONFIG_MMC_SPI=y
+CONFIG_NEW_LEDS=y
+CONFIG_LEDS_CLASS=y
+CONFIG_LEDS_SYSCON=y
+CONFIG_LEDS_TRIGGERS=y
+CONFIG_LEDS_TRIGGER_HEARTBEAT=y
+CONFIG_LEDS_TRIGGER_CPU=y
 CONFIG_RTC_CLASS=y
 CONFIG_RTC_DRV_EFI=y
 CONFIG_RTC_DRV_XGENE=y
-- 
1.9.3

^ permalink raw reply related	[flat|nested] 40+ messages in thread

* Re: [PATCH 1/5] MFD/OF: document MFD devices and handle simple-mfd
  2015-03-03  9:32     ` Linus Walleij
@ 2015-03-03 10:25         ` Lee Jones
  -1 siblings, 0 replies; 40+ messages in thread
From: Lee Jones @ 2015-03-03 10:25 UTC (permalink / raw)
  To: Linus Walleij
  Cc: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Arnd Bergmann,
	Bryan Wu, Catalin Marinas, Will Deacon, Richard Purdie,
	Devicetree, Rob Herring, Benjamin Herrenschmidt, Grant Likely,
	Pawel Moll, Mark Rutland, Ian Campbell, Kumar Gala

On Tue, 03 Mar 2015, Linus Walleij wrote:

> This defines a new compatible option for MFD devices "simple-mfd" that will
> make the OF core spawn child devices for all subnodes of that MFD device.
> It is optional but handy for things like syscon and possibly other
> simpler MFD devices.
> 
> Since there was no file to put the documentation in, I took this opportunity
> to make a small writeup on MFD devices and add the compatible definition
> there.
> 
> Suggested-by: Lee Jones <lee.jones-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
> Cc: Arnd Bergmann <arnd-r2nGTMty4D4@public.gmane.org>
> Cc: Devicetree <devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>
> Cc: Rob Herring <robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
> Cc: Benjamin Herrenschmidt <benh-XVmvHMARGAS8U2dJNN8I7kB+6BGkLq7r@public.gmane.org>
> Cc: Grant Likely <grant.likely-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
> Cc: Pawel Moll <pawel.moll-5wv7dgnIgG8@public.gmane.org>
> Cc: Mark Rutland <mark.rutland-5wv7dgnIgG8@public.gmane.org>
> Cc: Ian Campbell <ijc+devicetree-KcIKpvwj1kUDXYZnReoRVg@public.gmane.org>
> Cc: Kumar Gala <galak-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
> Signed-off-by: Linus Walleij <linus.walleij-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
> ---
> I make the patch to the OF core in this one, it makes much more sense since
> it's a oneliner
> 
> Lee: this is a (tested!) implementation of your suggestion for simple-mfd.
> If you can eventually ACK this from the MFD side, I think it should be
> funneled through the ARM SoC tree.
> 
> Grant/Rob: if either of you can ACK the change to the OF core likewise it can
> be taken through ARM SoC.
> 
> DT binings maintainers: there is some background discussion on this here:
> http://marc.info/?l=linux-arm-kernel&m=142486676603889&w=2
> http://marc.info/?l=devicetree&m=142166313621469&w=2
> ---
>  Documentation/devicetree/bindings/mfd/mfd.txt | 40 +++++++++++++++++++++++++++
>  drivers/of/platform.c                         |  1 +
>  2 files changed, 41 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/mfd/mfd.txt
> 
> diff --git a/Documentation/devicetree/bindings/mfd/mfd.txt b/Documentation/devicetree/bindings/mfd/mfd.txt
> new file mode 100644
> index 000000000000..cc057438abe8
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/mfd/mfd.txt
> @@ -0,0 +1,40 @@
> +Multi-Function Devices (MFD)
> +
> +These devices comprise a nexus for heterogeneous hardware blocks 

I don't think you meant 'comprise' here.  Perhaps 'represent' might
fit better?

> +spawning multiple child devices.

Spawning devices is something software will do.  Think less about what
the actions the OS will take order to handle these IPs and more about
what they are physically.  I would prefer the description mentions
that these chips are single pieces of silicon which contain >1 devices
with non-unique/varying functionality.

> +A typical MFD can be:
> +
> +- A mixed signal ASIC on an external bus, sometimes a PMIC (power management
> +  integrated circuit) that is manufactured in a lower technology node (rough

Please capitalise the expanded PMIC abbreviation.

> +  silicon) that handles analog drivers for things like audio amplifiers, LED
> +  drivers, level shifters, PHY (physical interfaces to things like USB or
> +  ethernet), regulators etc.
> +
> +- A range of memory registers containing "miscellaneous system registers" also
> +  known as a system controller "syscon" or any other memory range containing a
> +  mix of unrelated registers.

s/registers/{hardware|devices}/

> +Optional properties:
> +
> +- compatible : "simple-mfd" - this signifies that the operating system should
> +  spawn child devices for all the subnodes of the MFD device akin to how

This is pretty Linux specific IMHO.  Other OSes might not spawn
seperate devices to handle MFD type h/w.  The idea is fine, but please
generify a little.

> +  "simple-bus" inidicates when to spawn children for a simple memory-mapped
> +  bus. For more complex devices, when the nexus driver has to probe registers
> +  to figure out what children exist etc, this should not be used. In the latter
> +  case the child devices will be instantiated by the operating system.
> +
> +Example:
> +
> +foo@1000 {

Should be 10000.
> +		compatible = "syscon", "simple-mfd";

Please address your tabbing issues.

> +		reg = <0x010000 0x1000>;
> +
> +		led@08.0 {
> +			compatible = "register-bit-led";
> +			offset = <0x08>;
> +			mask = <0x01>;
> +			label = "myled";
> +			default-state = "on";
> +		};
> +};
> diff --git a/drivers/of/platform.c b/drivers/of/platform.c
> index b189733a1539..969ba4e1460c 100644
> --- a/drivers/of/platform.c
> +++ b/drivers/of/platform.c
> @@ -26,6 +26,7 @@
>  
>  const struct of_device_id of_default_bus_match_table[] = {
>  	{ .compatible = "simple-bus", },
> +	{ .compatible = "simple-mfd", },
>  #ifdef CONFIG_ARM_AMBA
>  	{ .compatible = "arm,amba-bus", },
>  #endif /* CONFIG_ARM_AMBA */

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply	[flat|nested] 40+ messages in thread

* [PATCH 1/5] MFD/OF: document MFD devices and handle simple-mfd
@ 2015-03-03 10:25         ` Lee Jones
  0 siblings, 0 replies; 40+ messages in thread
From: Lee Jones @ 2015-03-03 10:25 UTC (permalink / raw)
  To: linux-arm-kernel

On Tue, 03 Mar 2015, Linus Walleij wrote:

> This defines a new compatible option for MFD devices "simple-mfd" that will
> make the OF core spawn child devices for all subnodes of that MFD device.
> It is optional but handy for things like syscon and possibly other
> simpler MFD devices.
> 
> Since there was no file to put the documentation in, I took this opportunity
> to make a small writeup on MFD devices and add the compatible definition
> there.
> 
> Suggested-by: Lee Jones <lee.jones@linaro.org>
> Cc: Arnd Bergmann <arnd@arndb.de>
> Cc: Devicetree <devicetree@vger.kernel.org>
> Cc: Rob Herring <robh+dt@kernel.org>
> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> Cc: Grant Likely <grant.likely@linaro.org>
> Cc: Pawel Moll <pawel.moll@arm.com>
> Cc: Mark Rutland <mark.rutland@arm.com>
> Cc: Ian Campbell <ijc+devicetree@hellion.org.uk>
> Cc: Kumar Gala <galak@codeaurora.org>
> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
> ---
> I make the patch to the OF core in this one, it makes much more sense since
> it's a oneliner
> 
> Lee: this is a (tested!) implementation of your suggestion for simple-mfd.
> If you can eventually ACK this from the MFD side, I think it should be
> funneled through the ARM SoC tree.
> 
> Grant/Rob: if either of you can ACK the change to the OF core likewise it can
> be taken through ARM SoC.
> 
> DT binings maintainers: there is some background discussion on this here:
> http://marc.info/?l=linux-arm-kernel&m=142486676603889&w=2
> http://marc.info/?l=devicetree&m=142166313621469&w=2
> ---
>  Documentation/devicetree/bindings/mfd/mfd.txt | 40 +++++++++++++++++++++++++++
>  drivers/of/platform.c                         |  1 +
>  2 files changed, 41 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/mfd/mfd.txt
> 
> diff --git a/Documentation/devicetree/bindings/mfd/mfd.txt b/Documentation/devicetree/bindings/mfd/mfd.txt
> new file mode 100644
> index 000000000000..cc057438abe8
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/mfd/mfd.txt
> @@ -0,0 +1,40 @@
> +Multi-Function Devices (MFD)
> +
> +These devices comprise a nexus for heterogeneous hardware blocks 

I don't think you meant 'comprise' here.  Perhaps 'represent' might
fit better?

> +spawning multiple child devices.

Spawning devices is something software will do.  Think less about what
the actions the OS will take order to handle these IPs and more about
what they are physically.  I would prefer the description mentions
that these chips are single pieces of silicon which contain >1 devices
with non-unique/varying functionality.

> +A typical MFD can be:
> +
> +- A mixed signal ASIC on an external bus, sometimes a PMIC (power management
> +  integrated circuit) that is manufactured in a lower technology node (rough

Please capitalise the expanded PMIC abbreviation.

> +  silicon) that handles analog drivers for things like audio amplifiers, LED
> +  drivers, level shifters, PHY (physical interfaces to things like USB or
> +  ethernet), regulators etc.
> +
> +- A range of memory registers containing "miscellaneous system registers" also
> +  known as a system controller "syscon" or any other memory range containing a
> +  mix of unrelated registers.

s/registers/{hardware|devices}/

> +Optional properties:
> +
> +- compatible : "simple-mfd" - this signifies that the operating system should
> +  spawn child devices for all the subnodes of the MFD device akin to how

This is pretty Linux specific IMHO.  Other OSes might not spawn
seperate devices to handle MFD type h/w.  The idea is fine, but please
generify a little.

> +  "simple-bus" inidicates when to spawn children for a simple memory-mapped
> +  bus. For more complex devices, when the nexus driver has to probe registers
> +  to figure out what children exist etc, this should not be used. In the latter
> +  case the child devices will be instantiated by the operating system.
> +
> +Example:
> +
> +foo at 1000 {

Should be 10000.
> +		compatible = "syscon", "simple-mfd";

Please address your tabbing issues.

> +		reg = <0x010000 0x1000>;
> +
> +		led at 08.0 {
> +			compatible = "register-bit-led";
> +			offset = <0x08>;
> +			mask = <0x01>;
> +			label = "myled";
> +			default-state = "on";
> +		};
> +};
> diff --git a/drivers/of/platform.c b/drivers/of/platform.c
> index b189733a1539..969ba4e1460c 100644
> --- a/drivers/of/platform.c
> +++ b/drivers/of/platform.c
> @@ -26,6 +26,7 @@
>  
>  const struct of_device_id of_default_bus_match_table[] = {
>  	{ .compatible = "simple-bus", },
> +	{ .compatible = "simple-mfd", },
>  #ifdef CONFIG_ARM_AMBA
>  	{ .compatible = "arm,amba-bus", },
>  #endif /* CONFIG_ARM_AMBA */

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog

^ permalink raw reply	[flat|nested] 40+ messages in thread

* Re: [PATCH 1/5] MFD/OF: document MFD devices and handle simple-mfd
  2015-03-03  9:32     ` Linus Walleij
@ 2015-03-03 17:47         ` Rob Herring
  -1 siblings, 0 replies; 40+ messages in thread
From: Rob Herring @ 2015-03-03 17:47 UTC (permalink / raw)
  To: Linus Walleij
  Cc: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Arnd Bergmann,
	Lee Jones, Bryan Wu, Catalin Marinas, Will Deacon,
	Richard Purdie, Devicetree, Rob Herring, Benjamin Herrenschmidt,
	Grant Likely, Pawel Moll, Mark Rutland, Ian Campbell, Kumar Gala

On Tue, Mar 3, 2015 at 3:32 AM, Linus Walleij <linus.walleij-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org> wrote:
> This defines a new compatible option for MFD devices "simple-mfd" that will
> make the OF core spawn child devices for all subnodes of that MFD device.
> It is optional but handy for things like syscon and possibly other
> simpler MFD devices.
>
> Since there was no file to put the documentation in, I took this opportunity
> to make a small writeup on MFD devices and add the compatible definition
> there.
>
> Suggested-by: Lee Jones <lee.jones-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
> Cc: Arnd Bergmann <arnd-r2nGTMty4D4@public.gmane.org>
> Cc: Devicetree <devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>
> Cc: Rob Herring <robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
> Cc: Benjamin Herrenschmidt <benh-XVmvHMARGAS8U2dJNN8I7kB+6BGkLq7r@public.gmane.org>
> Cc: Grant Likely <grant.likely-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
> Cc: Pawel Moll <pawel.moll-5wv7dgnIgG8@public.gmane.org>
> Cc: Mark Rutland <mark.rutland-5wv7dgnIgG8@public.gmane.org>
> Cc: Ian Campbell <ijc+devicetree-KcIKpvwj1kUDXYZnReoRVg@public.gmane.org>
> Cc: Kumar Gala <galak-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
> Signed-off-by: Linus Walleij <linus.walleij-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
> ---
> I make the patch to the OF core in this one, it makes much more sense since
> it's a oneliner
>
> Lee: this is a (tested!) implementation of your suggestion for simple-mfd.
> If you can eventually ACK this from the MFD side, I think it should be
> funneled through the ARM SoC tree.
>
> Grant/Rob: if either of you can ACK the change to the OF core likewise it can
> be taken through ARM SoC.
>
> DT binings maintainers: there is some background discussion on this here:
> http://marc.info/?l=linux-arm-kernel&m=142486676603889&w=2
> http://marc.info/?l=devicetree&m=142166313621469&w=2
> ---
>  Documentation/devicetree/bindings/mfd/mfd.txt | 40 +++++++++++++++++++++++++++
>  drivers/of/platform.c                         |  1 +
>  2 files changed, 41 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/mfd/mfd.txt
>
> diff --git a/Documentation/devicetree/bindings/mfd/mfd.txt b/Documentation/devicetree/bindings/mfd/mfd.txt
> new file mode 100644
> index 000000000000..cc057438abe8
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/mfd/mfd.txt
> @@ -0,0 +1,40 @@
> +Multi-Function Devices (MFD)
> +
> +These devices comprise a nexus for heterogeneous hardware blocks spawning
> +multiple child devices.
> +
> +A typical MFD can be:
> +
> +- A mixed signal ASIC on an external bus, sometimes a PMIC (power management
> +  integrated circuit) that is manufactured in a lower technology node (rough
> +  silicon) that handles analog drivers for things like audio amplifiers, LED
> +  drivers, level shifters, PHY (physical interfaces to things like USB or
> +  ethernet), regulators etc.
> +
> +- A range of memory registers containing "miscellaneous system registers" also
> +  known as a system controller "syscon" or any other memory range containing a
> +  mix of unrelated registers.
> +
> +Optional properties:
> +
> +- compatible : "simple-mfd" - this signifies that the operating system should
> +  spawn child devices for all the subnodes of the MFD device akin to how
> +  "simple-bus" inidicates when to spawn children for a simple memory-mapped
> +  bus. For more complex devices, when the nexus driver has to probe registers
> +  to figure out what children exist etc, this should not be used. In the latter
> +  case the child devices will be instantiated by the operating system.

If you point of_platform_populate to the parent node, it should
instantiate all children regardless of "simple-bus" or any other
match. The match is to probe the grandchildren. I could be mistaken,
but that's how it works at the root level. You don't have a driver
probe for the parent, so you want the top level of_platform_populate
call to instantiate these devices?

Why does simple-bus not work for you? After all, it is not
"simple-memory-map-bus."

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

^ permalink raw reply	[flat|nested] 40+ messages in thread

* [PATCH 1/5] MFD/OF: document MFD devices and handle simple-mfd
@ 2015-03-03 17:47         ` Rob Herring
  0 siblings, 0 replies; 40+ messages in thread
From: Rob Herring @ 2015-03-03 17:47 UTC (permalink / raw)
  To: linux-arm-kernel

On Tue, Mar 3, 2015 at 3:32 AM, Linus Walleij <linus.walleij@linaro.org> wrote:
> This defines a new compatible option for MFD devices "simple-mfd" that will
> make the OF core spawn child devices for all subnodes of that MFD device.
> It is optional but handy for things like syscon and possibly other
> simpler MFD devices.
>
> Since there was no file to put the documentation in, I took this opportunity
> to make a small writeup on MFD devices and add the compatible definition
> there.
>
> Suggested-by: Lee Jones <lee.jones@linaro.org>
> Cc: Arnd Bergmann <arnd@arndb.de>
> Cc: Devicetree <devicetree@vger.kernel.org>
> Cc: Rob Herring <robh+dt@kernel.org>
> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> Cc: Grant Likely <grant.likely@linaro.org>
> Cc: Pawel Moll <pawel.moll@arm.com>
> Cc: Mark Rutland <mark.rutland@arm.com>
> Cc: Ian Campbell <ijc+devicetree@hellion.org.uk>
> Cc: Kumar Gala <galak@codeaurora.org>
> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
> ---
> I make the patch to the OF core in this one, it makes much more sense since
> it's a oneliner
>
> Lee: this is a (tested!) implementation of your suggestion for simple-mfd.
> If you can eventually ACK this from the MFD side, I think it should be
> funneled through the ARM SoC tree.
>
> Grant/Rob: if either of you can ACK the change to the OF core likewise it can
> be taken through ARM SoC.
>
> DT binings maintainers: there is some background discussion on this here:
> http://marc.info/?l=linux-arm-kernel&m=142486676603889&w=2
> http://marc.info/?l=devicetree&m=142166313621469&w=2
> ---
>  Documentation/devicetree/bindings/mfd/mfd.txt | 40 +++++++++++++++++++++++++++
>  drivers/of/platform.c                         |  1 +
>  2 files changed, 41 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/mfd/mfd.txt
>
> diff --git a/Documentation/devicetree/bindings/mfd/mfd.txt b/Documentation/devicetree/bindings/mfd/mfd.txt
> new file mode 100644
> index 000000000000..cc057438abe8
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/mfd/mfd.txt
> @@ -0,0 +1,40 @@
> +Multi-Function Devices (MFD)
> +
> +These devices comprise a nexus for heterogeneous hardware blocks spawning
> +multiple child devices.
> +
> +A typical MFD can be:
> +
> +- A mixed signal ASIC on an external bus, sometimes a PMIC (power management
> +  integrated circuit) that is manufactured in a lower technology node (rough
> +  silicon) that handles analog drivers for things like audio amplifiers, LED
> +  drivers, level shifters, PHY (physical interfaces to things like USB or
> +  ethernet), regulators etc.
> +
> +- A range of memory registers containing "miscellaneous system registers" also
> +  known as a system controller "syscon" or any other memory range containing a
> +  mix of unrelated registers.
> +
> +Optional properties:
> +
> +- compatible : "simple-mfd" - this signifies that the operating system should
> +  spawn child devices for all the subnodes of the MFD device akin to how
> +  "simple-bus" inidicates when to spawn children for a simple memory-mapped
> +  bus. For more complex devices, when the nexus driver has to probe registers
> +  to figure out what children exist etc, this should not be used. In the latter
> +  case the child devices will be instantiated by the operating system.

If you point of_platform_populate to the parent node, it should
instantiate all children regardless of "simple-bus" or any other
match. The match is to probe the grandchildren. I could be mistaken,
but that's how it works at the root level. You don't have a driver
probe for the parent, so you want the top level of_platform_populate
call to instantiate these devices?

Why does simple-bus not work for you? After all, it is not
"simple-memory-map-bus."

Rob

^ permalink raw reply	[flat|nested] 40+ messages in thread

* Re: [PATCH 1/5] MFD/OF: document MFD devices and handle simple-mfd
  2015-03-03 17:47         ` Rob Herring
@ 2015-03-03 17:56           ` Lee Jones
  -1 siblings, 0 replies; 40+ messages in thread
From: Lee Jones @ 2015-03-03 17:56 UTC (permalink / raw)
  To: Rob Herring
  Cc: Linus Walleij, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
	Arnd Bergmann, Bryan Wu, Catalin Marinas, Will Deacon,
	Richard Purdie, Devicetree, Rob Herring, Benjamin Herrenschmidt,
	Grant Likely, Pawel Moll, Mark Rutland, Ian Campbell, Kumar Gala

On Tue, 03 Mar 2015, Rob Herring wrote:

> On Tue, Mar 3, 2015 at 3:32 AM, Linus Walleij <linus.walleij@linaro.org> wrote:
> > This defines a new compatible option for MFD devices "simple-mfd" that will
> > make the OF core spawn child devices for all subnodes of that MFD device.
> > It is optional but handy for things like syscon and possibly other
> > simpler MFD devices.
> >
> > Since there was no file to put the documentation in, I took this opportunity
> > to make a small writeup on MFD devices and add the compatible definition
> > there.
> >
> > Suggested-by: Lee Jones <lee.jones-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
> > Cc: Arnd Bergmann <arnd-r2nGTMty4D4@public.gmane.org>
> > Cc: Devicetree <devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>
> > Cc: Rob Herring <robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
> > Cc: Benjamin Herrenschmidt <benh-XVmvHMARGAS8U2dJNN8I7kB+6BGkLq7r@public.gmane.org>
> > Cc: Grant Likely <grant.likely-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
> > Cc: Pawel Moll <pawel.moll-5wv7dgnIgG8@public.gmane.org>
> > Cc: Mark Rutland <mark.rutland-5wv7dgnIgG8@public.gmane.org>
> > Cc: Ian Campbell <ijc+devicetree-KcIKpvwj1kUDXYZnReoRVg@public.gmane.org>
> > Cc: Kumar Gala <galak-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
> > Signed-off-by: Linus Walleij <linus.walleij-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
> > ---
> > I make the patch to the OF core in this one, it makes much more sense since
> > it's a oneliner
> >
> > Lee: this is a (tested!) implementation of your suggestion for simple-mfd.
> > If you can eventually ACK this from the MFD side, I think it should be
> > funneled through the ARM SoC tree.
> >
> > Grant/Rob: if either of you can ACK the change to the OF core likewise it can
> > be taken through ARM SoC.
> >
> > DT binings maintainers: there is some background discussion on this here:
> > http://marc.info/?l=linux-arm-kernel&m=142486676603889&w=2
> > http://marc.info/?l=devicetree&m=142166313621469&w=2
> > ---
> >  Documentation/devicetree/bindings/mfd/mfd.txt | 40 +++++++++++++++++++++++++++
> >  drivers/of/platform.c                         |  1 +
> >  2 files changed, 41 insertions(+)
> >  create mode 100644 Documentation/devicetree/bindings/mfd/mfd.txt
> >
> > diff --git a/Documentation/devicetree/bindings/mfd/mfd.txt b/Documentation/devicetree/bindings/mfd/mfd.txt
> > new file mode 100644
> > index 000000000000..cc057438abe8
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/mfd/mfd.txt
> > @@ -0,0 +1,40 @@
> > +Multi-Function Devices (MFD)
> > +
> > +These devices comprise a nexus for heterogeneous hardware blocks spawning
> > +multiple child devices.
> > +
> > +A typical MFD can be:
> > +
> > +- A mixed signal ASIC on an external bus, sometimes a PMIC (power management
> > +  integrated circuit) that is manufactured in a lower technology node (rough
> > +  silicon) that handles analog drivers for things like audio amplifiers, LED
> > +  drivers, level shifters, PHY (physical interfaces to things like USB or
> > +  ethernet), regulators etc.
> > +
> > +- A range of memory registers containing "miscellaneous system registers" also
> > +  known as a system controller "syscon" or any other memory range containing a
> > +  mix of unrelated registers.
> > +
> > +Optional properties:
> > +
> > +- compatible : "simple-mfd" - this signifies that the operating system should
> > +  spawn child devices for all the subnodes of the MFD device akin to how
> > +  "simple-bus" inidicates when to spawn children for a simple memory-mapped
> > +  bus. For more complex devices, when the nexus driver has to probe registers
> > +  to figure out what children exist etc, this should not be used. In the latter
> > +  case the child devices will be instantiated by the operating system.
> 
> If you point of_platform_populate to the parent node, it should
> instantiate all children regardless of "simple-bus" or any other
> match. The match is to probe the grandchildren. I could be mistaken,
> but that's how it works at the root level. You don't have a driver
> probe for the parent, so you want the top level of_platform_populate
> call to instantiate these devices?
> 
> Why does simple-bus not work for you? After all, it is not
> "simple-memory-map-bus."

simple-bus does 'work'.  There are even some (3 I think) platforms
actively making use of it.  However, there was some controversy over
using it, as syscon isn't really a bus.

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply	[flat|nested] 40+ messages in thread

* [PATCH 1/5] MFD/OF: document MFD devices and handle simple-mfd
@ 2015-03-03 17:56           ` Lee Jones
  0 siblings, 0 replies; 40+ messages in thread
From: Lee Jones @ 2015-03-03 17:56 UTC (permalink / raw)
  To: linux-arm-kernel

On Tue, 03 Mar 2015, Rob Herring wrote:

> On Tue, Mar 3, 2015 at 3:32 AM, Linus Walleij <linus.walleij@linaro.org> wrote:
> > This defines a new compatible option for MFD devices "simple-mfd" that will
> > make the OF core spawn child devices for all subnodes of that MFD device.
> > It is optional but handy for things like syscon and possibly other
> > simpler MFD devices.
> >
> > Since there was no file to put the documentation in, I took this opportunity
> > to make a small writeup on MFD devices and add the compatible definition
> > there.
> >
> > Suggested-by: Lee Jones <lee.jones@linaro.org>
> > Cc: Arnd Bergmann <arnd@arndb.de>
> > Cc: Devicetree <devicetree@vger.kernel.org>
> > Cc: Rob Herring <robh+dt@kernel.org>
> > Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> > Cc: Grant Likely <grant.likely@linaro.org>
> > Cc: Pawel Moll <pawel.moll@arm.com>
> > Cc: Mark Rutland <mark.rutland@arm.com>
> > Cc: Ian Campbell <ijc+devicetree@hellion.org.uk>
> > Cc: Kumar Gala <galak@codeaurora.org>
> > Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
> > ---
> > I make the patch to the OF core in this one, it makes much more sense since
> > it's a oneliner
> >
> > Lee: this is a (tested!) implementation of your suggestion for simple-mfd.
> > If you can eventually ACK this from the MFD side, I think it should be
> > funneled through the ARM SoC tree.
> >
> > Grant/Rob: if either of you can ACK the change to the OF core likewise it can
> > be taken through ARM SoC.
> >
> > DT binings maintainers: there is some background discussion on this here:
> > http://marc.info/?l=linux-arm-kernel&m=142486676603889&w=2
> > http://marc.info/?l=devicetree&m=142166313621469&w=2
> > ---
> >  Documentation/devicetree/bindings/mfd/mfd.txt | 40 +++++++++++++++++++++++++++
> >  drivers/of/platform.c                         |  1 +
> >  2 files changed, 41 insertions(+)
> >  create mode 100644 Documentation/devicetree/bindings/mfd/mfd.txt
> >
> > diff --git a/Documentation/devicetree/bindings/mfd/mfd.txt b/Documentation/devicetree/bindings/mfd/mfd.txt
> > new file mode 100644
> > index 000000000000..cc057438abe8
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/mfd/mfd.txt
> > @@ -0,0 +1,40 @@
> > +Multi-Function Devices (MFD)
> > +
> > +These devices comprise a nexus for heterogeneous hardware blocks spawning
> > +multiple child devices.
> > +
> > +A typical MFD can be:
> > +
> > +- A mixed signal ASIC on an external bus, sometimes a PMIC (power management
> > +  integrated circuit) that is manufactured in a lower technology node (rough
> > +  silicon) that handles analog drivers for things like audio amplifiers, LED
> > +  drivers, level shifters, PHY (physical interfaces to things like USB or
> > +  ethernet), regulators etc.
> > +
> > +- A range of memory registers containing "miscellaneous system registers" also
> > +  known as a system controller "syscon" or any other memory range containing a
> > +  mix of unrelated registers.
> > +
> > +Optional properties:
> > +
> > +- compatible : "simple-mfd" - this signifies that the operating system should
> > +  spawn child devices for all the subnodes of the MFD device akin to how
> > +  "simple-bus" inidicates when to spawn children for a simple memory-mapped
> > +  bus. For more complex devices, when the nexus driver has to probe registers
> > +  to figure out what children exist etc, this should not be used. In the latter
> > +  case the child devices will be instantiated by the operating system.
> 
> If you point of_platform_populate to the parent node, it should
> instantiate all children regardless of "simple-bus" or any other
> match. The match is to probe the grandchildren. I could be mistaken,
> but that's how it works at the root level. You don't have a driver
> probe for the parent, so you want the top level of_platform_populate
> call to instantiate these devices?
> 
> Why does simple-bus not work for you? After all, it is not
> "simple-memory-map-bus."

simple-bus does 'work'.  There are even some (3 I think) platforms
actively making use of it.  However, there was some controversy over
using it, as syscon isn't really a bus.

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog

^ permalink raw reply	[flat|nested] 40+ messages in thread

* [PATCH 4/5] arm64: juno: Add APB registers and LEDs using syscon
  2015-03-03  9:32 ` [PATCH 4/5] arm64: juno: Add APB registers and LEDs using syscon Linus Walleij
@ 2015-03-04 15:57   ` Liviu Dudau
  0 siblings, 0 replies; 40+ messages in thread
From: Liviu Dudau @ 2015-03-04 15:57 UTC (permalink / raw)
  To: linux-arm-kernel

On Tue, Mar 03, 2015 at 09:32:27AM +0000, Linus Walleij wrote:
> This defines the Juno "APB system registers" as a syscon device,
> and all the LEDs controlled by the APB system registers right
> below it using the syscon LEDs driver on top of syscon. Define
> LED0 for heartbeat, LED1 for MMC0 activity and the following
> four LEDs indicating CPU activity using the Linux-specific
> DT bindings for triggers.
> 
> This is the pattern and same drivers as used on the legacy
> platform device trees for the ARM Integrators and the RealView
> PB1176.
> 
> Cc: Arnd Bergmann <arnd@arndb.de>
> Cc: Liviu Dudau <Liviu.Dudau@arm.com>
> Cc: Mark Rutland <mark.rutland@arm.com>
> Cc: Robin Murphy <robin.murphy@arm.com>
> Cc: Pawel Moll <pawel.moll@arm.com>
> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>

Tested-by: Liviu Dudau <Liviu.Dudau@arm.com>

KITT test shell script working beautifully. :)

Best regards,
Liviu

> ---
> ChangeLog v1->v2:
> - Use "simple-mfd" so that the syscon LEDs get spawned from the
>   syscon as sub-platform devices.
> ---
>  arch/arm64/boot/dts/arm/juno-motherboard.dtsi | 68 +++++++++++++++++++++++++++
>  1 file changed, 68 insertions(+)
> 
> diff --git a/arch/arm64/boot/dts/arm/juno-motherboard.dtsi b/arch/arm64/boot/dts/arm/juno-motherboard.dtsi
> index c138b95a8356..5ce111dcf16d 100644
> --- a/arch/arm64/boot/dts/arm/juno-motherboard.dtsi
> +++ b/arch/arm64/boot/dts/arm/juno-motherboard.dtsi
> @@ -66,6 +66,74 @@
>  				#size-cells = <1>;
>  				ranges = <0 3 0 0x200000>;
>  
> +				apbregs at 010000 {
> +					compatible = "syscon", "simple-mfd";
> +					reg = <0x010000 0x1000>;
> +
> +					led at 08.0 {
> +						compatible = "register-bit-led";
> +						offset = <0x08>;
> +						mask = <0x01>;
> +						label = "vexpress:0";
> +						linux,default-trigger = "heartbeat";
> +						default-state = "on";
> +					};
> +					led at 08.1 {
> +						compatible = "register-bit-led";
> +						offset = <0x08>;
> +						mask = <0x02>;
> +						label = "vexpress:1";
> +						linux,default-trigger = "mmc0";
> +						default-state = "off";
> +					};
> +					led at 08.2 {
> +						compatible = "register-bit-led";
> +						offset = <0x08>;
> +						mask = <0x04>;
> +						label = "vexpress:2";
> +						linux,default-trigger = "cpu0";
> +						default-state = "off";
> +					};
> +					led at 08.3 {
> +						compatible = "register-bit-led";
> +						offset = <0x08>;
> +						mask = <0x08>;
> +						label = "vexpress:3";
> +						linux,default-trigger = "cpu1";
> +						default-state = "off";
> +					};
> +					led at 08.4 {
> +						compatible = "register-bit-led";
> +						offset = <0x08>;
> +						mask = <0x10>;
> +						label = "vexpress:4";
> +						linux,default-trigger = "cpu2";
> +						default-state = "off";
> +					};
> +					led at 08.5 {
> +						compatible = "register-bit-led";
> +						offset = <0x08>;
> +						mask = <0x20>;
> +						label = "vexpress:5";
> +						linux,default-trigger = "cpu3";
> +						default-state = "off";
> +					};
> +					led at 08.6 {
> +						compatible = "register-bit-led";
> +						offset = <0x08>;
> +						mask = <0x40>;
> +						label = "vexpress:6";
> +						default-state = "off";
> +					};
> +					led at 08.7 {
> +						compatible = "register-bit-led";
> +						offset = <0x08>;
> +						mask = <0x80>;
> +						label = "vexpress:7";
> +						default-state = "off";
> +					};
> +				};
> +
>  				mmci at 050000 {
>  					compatible = "arm,pl180", "arm,primecell";
>  					reg = <0x050000 0x1000>;
> -- 
> 1.9.3
> 
> 

-- 
====================
| I would like to |
| fix the world,  |
| but they're not |
| giving me the   |
 \ source code!  /
  ---------------
    ?\_(?)_/?

^ permalink raw reply	[flat|nested] 40+ messages in thread

* Re: [PATCH 1/5] MFD/OF: document MFD devices and handle simple-mfd
  2015-03-03 10:25         ` Lee Jones
@ 2015-03-09 14:29           ` Linus Walleij
  -1 siblings, 0 replies; 40+ messages in thread
From: Linus Walleij @ 2015-03-09 14:29 UTC (permalink / raw)
  To: Lee Jones
  Cc: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Arnd Bergmann,
	Bryan Wu, Catalin Marinas, Will Deacon, Richard Purdie,
	Devicetree, Rob Herring, Benjamin Herrenschmidt, Grant Likely,
	Pawel Moll, Mark Rutland, Ian Campbell, Kumar Gala

On Tue, Mar 3, 2015 at 11:25 AM, Lee Jones <lee.jones-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org> wrote:
> On Tue, 03 Mar 2015, Linus Walleij wrote:

>> +Multi-Function Devices (MFD)
>> +
>> +These devices comprise a nexus for heterogeneous hardware blocks
>
> I don't think you meant 'comprise' here.  Perhaps 'represent' might
> fit better?

I meant "comprise", even looked up the same word in a Swedish-English
dictionary. I mean those devices really are such heterogeneous things,
not just modeled like such in Linux.

>> +spawning multiple child devices.
>
> Spawning devices is something software will do.  Think less about what
> the actions the OS will take order to handle these IPs and more about
> what they are physically.  I would prefer the description mentions
> that these chips are single pieces of silicon which contain >1 devices
> with non-unique/varying functionality.

OK.

>> +A typical MFD can be:
>> +
>> +- A mixed signal ASIC on an external bus, sometimes a PMIC (power management
>> +  integrated circuit) that is manufactured in a lower technology node (rough
>
> Please capitalise the expanded PMIC abbreviation.

OK.

>> +  silicon) that handles analog drivers for things like audio amplifiers, LED
>> +  drivers, level shifters, PHY (physical interfaces to things like USB or
>> +  ethernet), regulators etc.
>> +
>> +- A range of memory registers containing "miscellaneous system registers" also
>> +  known as a system controller "syscon" or any other memory range containing a
>> +  mix of unrelated registers.
>
> s/registers/{hardware|devices}/

OK.

>> +Optional properties:
>> +
>> +- compatible : "simple-mfd" - this signifies that the operating system should
>> +  spawn child devices for all the subnodes of the MFD device akin to how
>
> This is pretty Linux specific IMHO.  Other OSes might not spawn
> seperate devices to handle MFD type h/w.  The idea is fine, but please
> generify a little.

OK.

>> +foo@1000 {
>
> Should be 10000.

OK.

>> +             compatible = "syscon", "simple-mfd";
>
> Please address your tabbing issues.

OK.

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

^ permalink raw reply	[flat|nested] 40+ messages in thread

* [PATCH 1/5] MFD/OF: document MFD devices and handle simple-mfd
@ 2015-03-09 14:29           ` Linus Walleij
  0 siblings, 0 replies; 40+ messages in thread
From: Linus Walleij @ 2015-03-09 14:29 UTC (permalink / raw)
  To: linux-arm-kernel

On Tue, Mar 3, 2015 at 11:25 AM, Lee Jones <lee.jones@linaro.org> wrote:
> On Tue, 03 Mar 2015, Linus Walleij wrote:

>> +Multi-Function Devices (MFD)
>> +
>> +These devices comprise a nexus for heterogeneous hardware blocks
>
> I don't think you meant 'comprise' here.  Perhaps 'represent' might
> fit better?

I meant "comprise", even looked up the same word in a Swedish-English
dictionary. I mean those devices really are such heterogeneous things,
not just modeled like such in Linux.

>> +spawning multiple child devices.
>
> Spawning devices is something software will do.  Think less about what
> the actions the OS will take order to handle these IPs and more about
> what they are physically.  I would prefer the description mentions
> that these chips are single pieces of silicon which contain >1 devices
> with non-unique/varying functionality.

OK.

>> +A typical MFD can be:
>> +
>> +- A mixed signal ASIC on an external bus, sometimes a PMIC (power management
>> +  integrated circuit) that is manufactured in a lower technology node (rough
>
> Please capitalise the expanded PMIC abbreviation.

OK.

>> +  silicon) that handles analog drivers for things like audio amplifiers, LED
>> +  drivers, level shifters, PHY (physical interfaces to things like USB or
>> +  ethernet), regulators etc.
>> +
>> +- A range of memory registers containing "miscellaneous system registers" also
>> +  known as a system controller "syscon" or any other memory range containing a
>> +  mix of unrelated registers.
>
> s/registers/{hardware|devices}/

OK.

>> +Optional properties:
>> +
>> +- compatible : "simple-mfd" - this signifies that the operating system should
>> +  spawn child devices for all the subnodes of the MFD device akin to how
>
> This is pretty Linux specific IMHO.  Other OSes might not spawn
> seperate devices to handle MFD type h/w.  The idea is fine, but please
> generify a little.

OK.

>> +foo at 1000 {
>
> Should be 10000.

OK.

>> +             compatible = "syscon", "simple-mfd";
>
> Please address your tabbing issues.

OK.

Yours,
Linus Walleij

^ permalink raw reply	[flat|nested] 40+ messages in thread

* Re: [PATCH 1/5] MFD/OF: document MFD devices and handle simple-mfd
  2015-03-03 17:47         ` Rob Herring
@ 2015-03-09 14:35           ` Linus Walleij
  -1 siblings, 0 replies; 40+ messages in thread
From: Linus Walleij @ 2015-03-09 14:35 UTC (permalink / raw)
  To: Rob Herring
  Cc: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Arnd Bergmann,
	Lee Jones, Bryan Wu, Catalin Marinas, Will Deacon,
	Richard Purdie, Devicetree, Rob Herring, Benjamin Herrenschmidt,
	Grant Likely, Pawel Moll, Mark Rutland, Ian Campbell, Kumar Gala

On Tue, Mar 3, 2015 at 6:47 PM, Rob Herring <robherring2-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> On Tue, Mar 3, 2015 at 3:32 AM, Linus Walleij <linus.walleij-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org> wrote:

>> +Optional properties:
>> +
>> +- compatible : "simple-mfd" - this signifies that the operating system should
>> +  spawn child devices for all the subnodes of the MFD device akin to how
>> +  "simple-bus" inidicates when to spawn children for a simple memory-mapped
>> +  bus. For more complex devices, when the nexus driver has to probe registers
>> +  to figure out what children exist etc, this should not be used. In the latter
>> +  case the child devices will be instantiated by the operating system.
>
> If you point of_platform_populate to the parent node, it should
> instantiate all children regardless of "simple-bus" or any other
> match. The match is to probe the grandchildren.

Yep, if children are only children of the top node, yes.

> I could be mistaken,
> but that's how it works at the root level.

Yes but only at the root level.

> You don't have a driver
> probe for the parent, so you want the top level of_platform_populate
> call to instantiate these devices?

of_platform_populate() only populates one level unless the node has
something like "simple-bus" or this new "simple-mfd" compatible on
it.

> Why does simple-bus not work for you? After all, it is not
> "simple-memory-map-bus."

As Lee says it works (obviously since I'm just adding a oneliner
doing exactly the same thing as "simple-bus"), but the
terminology is just wrong. It's not a bus in any hardware sense,
as MFD is a logical subdevice split, nothing else.

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

^ permalink raw reply	[flat|nested] 40+ messages in thread

* [PATCH 1/5] MFD/OF: document MFD devices and handle simple-mfd
@ 2015-03-09 14:35           ` Linus Walleij
  0 siblings, 0 replies; 40+ messages in thread
From: Linus Walleij @ 2015-03-09 14:35 UTC (permalink / raw)
  To: linux-arm-kernel

On Tue, Mar 3, 2015 at 6:47 PM, Rob Herring <robherring2@gmail.com> wrote:
> On Tue, Mar 3, 2015 at 3:32 AM, Linus Walleij <linus.walleij@linaro.org> wrote:

>> +Optional properties:
>> +
>> +- compatible : "simple-mfd" - this signifies that the operating system should
>> +  spawn child devices for all the subnodes of the MFD device akin to how
>> +  "simple-bus" inidicates when to spawn children for a simple memory-mapped
>> +  bus. For more complex devices, when the nexus driver has to probe registers
>> +  to figure out what children exist etc, this should not be used. In the latter
>> +  case the child devices will be instantiated by the operating system.
>
> If you point of_platform_populate to the parent node, it should
> instantiate all children regardless of "simple-bus" or any other
> match. The match is to probe the grandchildren.

Yep, if children are only children of the top node, yes.

> I could be mistaken,
> but that's how it works at the root level.

Yes but only at the root level.

> You don't have a driver
> probe for the parent, so you want the top level of_platform_populate
> call to instantiate these devices?

of_platform_populate() only populates one level unless the node has
something like "simple-bus" or this new "simple-mfd" compatible on
it.

> Why does simple-bus not work for you? After all, it is not
> "simple-memory-map-bus."

As Lee says it works (obviously since I'm just adding a oneliner
doing exactly the same thing as "simple-bus"), but the
terminology is just wrong. It's not a bus in any hardware sense,
as MFD is a logical subdevice split, nothing else.

Yours,
Linus Walleij

^ permalink raw reply	[flat|nested] 40+ messages in thread

* Re: [PATCH 1/5] MFD/OF: document MFD devices and handle simple-mfd
  2015-03-03  9:32     ` Linus Walleij
@ 2015-03-12  9:14         ` Alexandre Belloni
  -1 siblings, 0 replies; 40+ messages in thread
From: Alexandre Belloni @ 2015-03-12  9:14 UTC (permalink / raw)
  To: Linus Walleij
  Cc: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Arnd Bergmann,
	Lee Jones, Bryan Wu, Mark Rutland, Devicetree, Pawel Moll,
	Ian Campbell, Catalin Marinas, Kumar Gala, Will Deacon,
	Rob Herring, Richard Purdie, Benjamin Herrenschmidt,
	Grant Likely

Hi,

As part of the system timer cleanup, I'll actually be needing that
patch. Is it scheduled for inclusion or should I use "simple-bus" in the
meantime?

On 03/03/2015 at 10:32:24 +0100, Linus Walleij wrote :
> This defines a new compatible option for MFD devices "simple-mfd" that will
> make the OF core spawn child devices for all subnodes of that MFD device.
> It is optional but handy for things like syscon and possibly other
> simpler MFD devices.
> 
> Since there was no file to put the documentation in, I took this opportunity
> to make a small writeup on MFD devices and add the compatible definition
> there.
> 
> Suggested-by: Lee Jones <lee.jones-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
> Cc: Arnd Bergmann <arnd-r2nGTMty4D4@public.gmane.org>
> Cc: Devicetree <devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>
> Cc: Rob Herring <robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
> Cc: Benjamin Herrenschmidt <benh-XVmvHMARGAS8U2dJNN8I7kB+6BGkLq7r@public.gmane.org>
> Cc: Grant Likely <grant.likely-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
> Cc: Pawel Moll <pawel.moll-5wv7dgnIgG8@public.gmane.org>
> Cc: Mark Rutland <mark.rutland-5wv7dgnIgG8@public.gmane.org>
> Cc: Ian Campbell <ijc+devicetree-KcIKpvwj1kUDXYZnReoRVg@public.gmane.org>
> Cc: Kumar Gala <galak-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
> Signed-off-by: Linus Walleij <linus.walleij-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
> ---
> I make the patch to the OF core in this one, it makes much more sense since
> it's a oneliner
> 
> Lee: this is a (tested!) implementation of your suggestion for simple-mfd.
> If you can eventually ACK this from the MFD side, I think it should be
> funneled through the ARM SoC tree.
> 
> Grant/Rob: if either of you can ACK the change to the OF core likewise it can
> be taken through ARM SoC.
> 
> DT binings maintainers: there is some background discussion on this here:
> http://marc.info/?l=linux-arm-kernel&m=142486676603889&w=2
> http://marc.info/?l=devicetree&m=142166313621469&w=2
> ---
>  Documentation/devicetree/bindings/mfd/mfd.txt | 40 +++++++++++++++++++++++++++
>  drivers/of/platform.c                         |  1 +
>  2 files changed, 41 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/mfd/mfd.txt
> 
> diff --git a/Documentation/devicetree/bindings/mfd/mfd.txt b/Documentation/devicetree/bindings/mfd/mfd.txt
> new file mode 100644
> index 000000000000..cc057438abe8
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/mfd/mfd.txt
> @@ -0,0 +1,40 @@
> +Multi-Function Devices (MFD)
> +
> +These devices comprise a nexus for heterogeneous hardware blocks spawning
> +multiple child devices.
> +
> +A typical MFD can be:
> +
> +- A mixed signal ASIC on an external bus, sometimes a PMIC (power management
> +  integrated circuit) that is manufactured in a lower technology node (rough
> +  silicon) that handles analog drivers for things like audio amplifiers, LED
> +  drivers, level shifters, PHY (physical interfaces to things like USB or
> +  ethernet), regulators etc.
> +
> +- A range of memory registers containing "miscellaneous system registers" also
> +  known as a system controller "syscon" or any other memory range containing a
> +  mix of unrelated registers.
> +
> +Optional properties:
> +
> +- compatible : "simple-mfd" - this signifies that the operating system should
> +  spawn child devices for all the subnodes of the MFD device akin to how
> +  "simple-bus" inidicates when to spawn children for a simple memory-mapped
> +  bus. For more complex devices, when the nexus driver has to probe registers
> +  to figure out what children exist etc, this should not be used. In the latter
> +  case the child devices will be instantiated by the operating system.
> +
> +Example:
> +
> +foo@1000 {
> +		compatible = "syscon", "simple-mfd";
> +		reg = <0x010000 0x1000>;
> +
> +		led@08.0 {
> +			compatible = "register-bit-led";
> +			offset = <0x08>;
> +			mask = <0x01>;
> +			label = "myled";
> +			default-state = "on";
> +		};
> +};
> diff --git a/drivers/of/platform.c b/drivers/of/platform.c
> index b189733a1539..969ba4e1460c 100644
> --- a/drivers/of/platform.c
> +++ b/drivers/of/platform.c
> @@ -26,6 +26,7 @@
>  
>  const struct of_device_id of_default_bus_match_table[] = {
>  	{ .compatible = "simple-bus", },
> +	{ .compatible = "simple-mfd", },
>  #ifdef CONFIG_ARM_AMBA
>  	{ .compatible = "arm,amba-bus", },
>  #endif /* CONFIG_ARM_AMBA */
> -- 
> 1.9.3
> 
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

-- 
Alexandre Belloni, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply	[flat|nested] 40+ messages in thread

* [PATCH 1/5] MFD/OF: document MFD devices and handle simple-mfd
@ 2015-03-12  9:14         ` Alexandre Belloni
  0 siblings, 0 replies; 40+ messages in thread
From: Alexandre Belloni @ 2015-03-12  9:14 UTC (permalink / raw)
  To: linux-arm-kernel

Hi,

As part of the system timer cleanup, I'll actually be needing that
patch. Is it scheduled for inclusion or should I use "simple-bus" in the
meantime?

On 03/03/2015 at 10:32:24 +0100, Linus Walleij wrote :
> This defines a new compatible option for MFD devices "simple-mfd" that will
> make the OF core spawn child devices for all subnodes of that MFD device.
> It is optional but handy for things like syscon and possibly other
> simpler MFD devices.
> 
> Since there was no file to put the documentation in, I took this opportunity
> to make a small writeup on MFD devices and add the compatible definition
> there.
> 
> Suggested-by: Lee Jones <lee.jones@linaro.org>
> Cc: Arnd Bergmann <arnd@arndb.de>
> Cc: Devicetree <devicetree@vger.kernel.org>
> Cc: Rob Herring <robh+dt@kernel.org>
> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> Cc: Grant Likely <grant.likely@linaro.org>
> Cc: Pawel Moll <pawel.moll@arm.com>
> Cc: Mark Rutland <mark.rutland@arm.com>
> Cc: Ian Campbell <ijc+devicetree@hellion.org.uk>
> Cc: Kumar Gala <galak@codeaurora.org>
> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
> ---
> I make the patch to the OF core in this one, it makes much more sense since
> it's a oneliner
> 
> Lee: this is a (tested!) implementation of your suggestion for simple-mfd.
> If you can eventually ACK this from the MFD side, I think it should be
> funneled through the ARM SoC tree.
> 
> Grant/Rob: if either of you can ACK the change to the OF core likewise it can
> be taken through ARM SoC.
> 
> DT binings maintainers: there is some background discussion on this here:
> http://marc.info/?l=linux-arm-kernel&m=142486676603889&w=2
> http://marc.info/?l=devicetree&m=142166313621469&w=2
> ---
>  Documentation/devicetree/bindings/mfd/mfd.txt | 40 +++++++++++++++++++++++++++
>  drivers/of/platform.c                         |  1 +
>  2 files changed, 41 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/mfd/mfd.txt
> 
> diff --git a/Documentation/devicetree/bindings/mfd/mfd.txt b/Documentation/devicetree/bindings/mfd/mfd.txt
> new file mode 100644
> index 000000000000..cc057438abe8
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/mfd/mfd.txt
> @@ -0,0 +1,40 @@
> +Multi-Function Devices (MFD)
> +
> +These devices comprise a nexus for heterogeneous hardware blocks spawning
> +multiple child devices.
> +
> +A typical MFD can be:
> +
> +- A mixed signal ASIC on an external bus, sometimes a PMIC (power management
> +  integrated circuit) that is manufactured in a lower technology node (rough
> +  silicon) that handles analog drivers for things like audio amplifiers, LED
> +  drivers, level shifters, PHY (physical interfaces to things like USB or
> +  ethernet), regulators etc.
> +
> +- A range of memory registers containing "miscellaneous system registers" also
> +  known as a system controller "syscon" or any other memory range containing a
> +  mix of unrelated registers.
> +
> +Optional properties:
> +
> +- compatible : "simple-mfd" - this signifies that the operating system should
> +  spawn child devices for all the subnodes of the MFD device akin to how
> +  "simple-bus" inidicates when to spawn children for a simple memory-mapped
> +  bus. For more complex devices, when the nexus driver has to probe registers
> +  to figure out what children exist etc, this should not be used. In the latter
> +  case the child devices will be instantiated by the operating system.
> +
> +Example:
> +
> +foo at 1000 {
> +		compatible = "syscon", "simple-mfd";
> +		reg = <0x010000 0x1000>;
> +
> +		led at 08.0 {
> +			compatible = "register-bit-led";
> +			offset = <0x08>;
> +			mask = <0x01>;
> +			label = "myled";
> +			default-state = "on";
> +		};
> +};
> diff --git a/drivers/of/platform.c b/drivers/of/platform.c
> index b189733a1539..969ba4e1460c 100644
> --- a/drivers/of/platform.c
> +++ b/drivers/of/platform.c
> @@ -26,6 +26,7 @@
>  
>  const struct of_device_id of_default_bus_match_table[] = {
>  	{ .compatible = "simple-bus", },
> +	{ .compatible = "simple-mfd", },
>  #ifdef CONFIG_ARM_AMBA
>  	{ .compatible = "arm,amba-bus", },
>  #endif /* CONFIG_ARM_AMBA */
> -- 
> 1.9.3
> 
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

-- 
Alexandre Belloni, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

^ permalink raw reply	[flat|nested] 40+ messages in thread

* Re: [PATCH 1/5] MFD/OF: document MFD devices and handle simple-mfd
  2015-03-12  9:14         ` Alexandre Belloni
@ 2015-03-17 10:28             ` Linus Walleij
  -1 siblings, 0 replies; 40+ messages in thread
From: Linus Walleij @ 2015-03-17 10:28 UTC (permalink / raw)
  To: Alexandre Belloni
  Cc: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Arnd Bergmann,
	Lee Jones, Bryan Wu, Mark Rutland, Devicetree, Pawel Moll,
	Ian Campbell, Catalin Marinas, Kumar Gala, Will Deacon,
	Rob Herring, Richard Purdie, Benjamin Herrenschmidt,
	Grant Likely

On Thu, Mar 12, 2015 at 10:14 AM, Alexandre Belloni
<alexandre.belloni-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org> wrote:

> As part of the system timer cleanup, I'll actually be needing that
> patch. Is it scheduled for inclusion or should I use "simple-bus" in the
> meantime?

No replies to the thread so I will send a pull request to ARM SoC cleanup
branch.

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

^ permalink raw reply	[flat|nested] 40+ messages in thread

* [PATCH 1/5] MFD/OF: document MFD devices and handle simple-mfd
@ 2015-03-17 10:28             ` Linus Walleij
  0 siblings, 0 replies; 40+ messages in thread
From: Linus Walleij @ 2015-03-17 10:28 UTC (permalink / raw)
  To: linux-arm-kernel

On Thu, Mar 12, 2015 at 10:14 AM, Alexandre Belloni
<alexandre.belloni@free-electrons.com> wrote:

> As part of the system timer cleanup, I'll actually be needing that
> patch. Is it scheduled for inclusion or should I use "simple-bus" in the
> meantime?

No replies to the thread so I will send a pull request to ARM SoC cleanup
branch.

Yours,
Linus Walleij

^ permalink raw reply	[flat|nested] 40+ messages in thread

* [PATCH 3/5] leds: syscon: instantiate from platform device
  2015-03-03  9:32 ` [PATCH 3/5] leds: syscon: instantiate from platform device Linus Walleij
@ 2015-03-17 10:36   ` Linus Walleij
  2015-03-24 16:50   ` Bjorn Andersson
  1 sibling, 0 replies; 40+ messages in thread
From: Linus Walleij @ 2015-03-17 10:36 UTC (permalink / raw)
  To: linux-arm-kernel

On Tue, Mar 3, 2015 at 10:32 AM, Linus Walleij <linus.walleij@linaro.org> wrote:

> Currently syscon LEDs will traverse the device tree looking for syscon devices
> and if found, traverse any subnodes of these to identify matching children
> and from there instantiate LED class devices.
>
> This is not a good use of the Linux device model. Instead we have converted the
> device trees to add the "simple-mfd" property to the MFD nexi spawning syscon
> LEDs so that these will appear as platform devices in the system and we can
> use the proper device probing mechanism.
>
> Cc: Arnd Bergmann <arnd@arndb.de>
> Cc: Lee Jones <lee.jones@linaro.org>
> Cc: Pawel Moll <pawel.moll@arm.com>
> Cc: Mark Rutland <mark.rutland@arm.com>
> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
> ---
> Bryan: if you're OK with it, please ACK this patch so we can funnel it through
> ARM SoC with the rest of the patches in this series.

Bryan, ping.

Yours,
Linus Walleij

^ permalink raw reply	[flat|nested] 40+ messages in thread

* Re: [PATCH 1/5] MFD/OF: document MFD devices and handle simple-mfd
  2015-03-17 10:28             ` Linus Walleij
@ 2015-03-17 10:38                 ` Linus Walleij
  -1 siblings, 0 replies; 40+ messages in thread
From: Linus Walleij @ 2015-03-17 10:38 UTC (permalink / raw)
  To: Alexandre Belloni, Antoine Ténart
  Cc: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Arnd Bergmann,
	Lee Jones, Bryan Wu, Mark Rutland, Devicetree, Pawel Moll,
	Ian Campbell, Catalin Marinas, Kumar Gala, Will Deacon,
	Rob Herring, Richard Purdie, Benjamin Herrenschmidt,
	Grant Likely

On Tue, Mar 17, 2015 at 11:28 AM, Linus Walleij
<linus.walleij-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org> wrote:
> On Thu, Mar 12, 2015 at 10:14 AM, Alexandre Belloni
> <alexandre.belloni-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org> wrote:
>
>> As part of the system timer cleanup, I'll actually be needing that
>> patch. Is it scheduled for inclusion or should I use "simple-bus" in the
>> meantime?
>
> No replies to the thread so I will send a pull request to ARM SoC cleanup
> branch.

Ah well I had some pending changes requested by Lee. Once Lee
ACK it for MFD and (hopefully) Bryan pitches in for LEDs, I'll post
a pull request.

BTW: Alexandre: your ACK or Reviewed-by would be appreciated ;)

Antione: if you're also using this, pls provide your ACK on the series.

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

^ permalink raw reply	[flat|nested] 40+ messages in thread

* [PATCH 1/5] MFD/OF: document MFD devices and handle simple-mfd
@ 2015-03-17 10:38                 ` Linus Walleij
  0 siblings, 0 replies; 40+ messages in thread
From: Linus Walleij @ 2015-03-17 10:38 UTC (permalink / raw)
  To: linux-arm-kernel

On Tue, Mar 17, 2015 at 11:28 AM, Linus Walleij
<linus.walleij@linaro.org> wrote:
> On Thu, Mar 12, 2015 at 10:14 AM, Alexandre Belloni
> <alexandre.belloni@free-electrons.com> wrote:
>
>> As part of the system timer cleanup, I'll actually be needing that
>> patch. Is it scheduled for inclusion or should I use "simple-bus" in the
>> meantime?
>
> No replies to the thread so I will send a pull request to ARM SoC cleanup
> branch.

Ah well I had some pending changes requested by Lee. Once Lee
ACK it for MFD and (hopefully) Bryan pitches in for LEDs, I'll post
a pull request.

BTW: Alexandre: your ACK or Reviewed-by would be appreciated ;)

Antione: if you're also using this, pls provide your ACK on the series.

Yours,
Linus Walleij

^ permalink raw reply	[flat|nested] 40+ messages in thread

* Re: [PATCH 1/5] MFD/OF: document MFD devices and handle simple-mfd
  2015-03-03  9:32     ` Linus Walleij
@ 2015-03-18 16:06         ` Alexandre Belloni
  -1 siblings, 0 replies; 40+ messages in thread
From: Alexandre Belloni @ 2015-03-18 16:06 UTC (permalink / raw)
  To: Linus Walleij
  Cc: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Arnd Bergmann,
	Lee Jones, Bryan Wu, Mark Rutland, Devicetree, Pawel Moll,
	Ian Campbell, Catalin Marinas, Kumar Gala, Will Deacon,
	Rob Herring, Richard Purdie, Benjamin Herrenschmidt,
	Grant Likely

On 03/03/2015 at 10:32:24 +0100, Linus Walleij wrote :
> This defines a new compatible option for MFD devices "simple-mfd" that will
> make the OF core spawn child devices for all subnodes of that MFD device.
> It is optional but handy for things like syscon and possibly other
> simpler MFD devices.
> 
> Since there was no file to put the documentation in, I took this opportunity
> to make a small writeup on MFD devices and add the compatible definition
> there.
> 
> Suggested-by: Lee Jones <lee.jones-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
> Cc: Arnd Bergmann <arnd-r2nGTMty4D4@public.gmane.org>
> Cc: Devicetree <devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>
> Cc: Rob Herring <robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
> Cc: Benjamin Herrenschmidt <benh-XVmvHMARGAS8U2dJNN8I7kB+6BGkLq7r@public.gmane.org>
> Cc: Grant Likely <grant.likely-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
> Cc: Pawel Moll <pawel.moll-5wv7dgnIgG8@public.gmane.org>
> Cc: Mark Rutland <mark.rutland-5wv7dgnIgG8@public.gmane.org>
> Cc: Ian Campbell <ijc+devicetree-KcIKpvwj1kUDXYZnReoRVg@public.gmane.org>
> Cc: Kumar Gala <galak-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
> Signed-off-by: Linus Walleij <linus.walleij-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>

Acked-by: Alexandre Belloni <alexandre.belloni-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>


-- 
Alexandre Belloni, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply	[flat|nested] 40+ messages in thread

* [PATCH 1/5] MFD/OF: document MFD devices and handle simple-mfd
@ 2015-03-18 16:06         ` Alexandre Belloni
  0 siblings, 0 replies; 40+ messages in thread
From: Alexandre Belloni @ 2015-03-18 16:06 UTC (permalink / raw)
  To: linux-arm-kernel

On 03/03/2015 at 10:32:24 +0100, Linus Walleij wrote :
> This defines a new compatible option for MFD devices "simple-mfd" that will
> make the OF core spawn child devices for all subnodes of that MFD device.
> It is optional but handy for things like syscon and possibly other
> simpler MFD devices.
> 
> Since there was no file to put the documentation in, I took this opportunity
> to make a small writeup on MFD devices and add the compatible definition
> there.
> 
> Suggested-by: Lee Jones <lee.jones@linaro.org>
> Cc: Arnd Bergmann <arnd@arndb.de>
> Cc: Devicetree <devicetree@vger.kernel.org>
> Cc: Rob Herring <robh+dt@kernel.org>
> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> Cc: Grant Likely <grant.likely@linaro.org>
> Cc: Pawel Moll <pawel.moll@arm.com>
> Cc: Mark Rutland <mark.rutland@arm.com>
> Cc: Ian Campbell <ijc+devicetree@hellion.org.uk>
> Cc: Kumar Gala <galak@codeaurora.org>
> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>

Acked-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>


-- 
Alexandre Belloni, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

^ permalink raw reply	[flat|nested] 40+ messages in thread

* Re: [PATCH 1/5] MFD/OF: document MFD devices and handle simple-mfd
  2015-03-03  9:32     ` Linus Walleij
@ 2015-03-20 13:26         ` Antoine Tenart
  -1 siblings, 0 replies; 40+ messages in thread
From: Antoine Tenart @ 2015-03-20 13:26 UTC (permalink / raw)
  To: Linus Walleij
  Cc: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Arnd Bergmann,
	Lee Jones, Bryan Wu, Mark Rutland, Devicetree, Pawel Moll,
	Ian Campbell, Catalin Marinas, Kumar Gala, Will Deacon,
	Rob Herring, Richard Purdie, Benjamin Herrenschmidt,
	Grant Likely

On Tue, Mar 03, 2015 at 10:32:24AM +0100, Linus Walleij wrote:
> This defines a new compatible option for MFD devices "simple-mfd" that will
> make the OF core spawn child devices for all subnodes of that MFD device.
> It is optional but handy for things like syscon and possibly other
> simpler MFD devices.
> 
> Since there was no file to put the documentation in, I took this opportunity
> to make a small writeup on MFD devices and add the compatible definition
> there.
> 
> Suggested-by: Lee Jones <lee.jones-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
> Cc: Arnd Bergmann <arnd-r2nGTMty4D4@public.gmane.org>
> Cc: Devicetree <devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>
> Cc: Rob Herring <robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
> Cc: Benjamin Herrenschmidt <benh-XVmvHMARGAS8U2dJNN8I7kB+6BGkLq7r@public.gmane.org>
> Cc: Grant Likely <grant.likely-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
> Cc: Pawel Moll <pawel.moll-5wv7dgnIgG8@public.gmane.org>
> Cc: Mark Rutland <mark.rutland-5wv7dgnIgG8@public.gmane.org>
> Cc: Ian Campbell <ijc+devicetree-KcIKpvwj1kUDXYZnReoRVg@public.gmane.org>
> Cc: Kumar Gala <galak-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
> Signed-off-by: Linus Walleij <linus.walleij-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>

Since I'm also using this,

Acked-by: Antoine Tenart <antoine.tenart-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>

> ---
> I make the patch to the OF core in this one, it makes much more sense since
> it's a oneliner
> 
> Lee: this is a (tested!) implementation of your suggestion for simple-mfd.
> If you can eventually ACK this from the MFD side, I think it should be
> funneled through the ARM SoC tree.
> 
> Grant/Rob: if either of you can ACK the change to the OF core likewise it can
> be taken through ARM SoC.
> 
> DT binings maintainers: there is some background discussion on this here:
> http://marc.info/?l=linux-arm-kernel&m=142486676603889&w=2
> http://marc.info/?l=devicetree&m=142166313621469&w=2
> ---
>  Documentation/devicetree/bindings/mfd/mfd.txt | 40 +++++++++++++++++++++++++++
>  drivers/of/platform.c                         |  1 +
>  2 files changed, 41 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/mfd/mfd.txt
> 
> diff --git a/Documentation/devicetree/bindings/mfd/mfd.txt b/Documentation/devicetree/bindings/mfd/mfd.txt
> new file mode 100644
> index 000000000000..cc057438abe8
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/mfd/mfd.txt
> @@ -0,0 +1,40 @@
> +Multi-Function Devices (MFD)
> +
> +These devices comprise a nexus for heterogeneous hardware blocks spawning
> +multiple child devices.
> +
> +A typical MFD can be:
> +
> +- A mixed signal ASIC on an external bus, sometimes a PMIC (power management
> +  integrated circuit) that is manufactured in a lower technology node (rough
> +  silicon) that handles analog drivers for things like audio amplifiers, LED
> +  drivers, level shifters, PHY (physical interfaces to things like USB or
> +  ethernet), regulators etc.
> +
> +- A range of memory registers containing "miscellaneous system registers" also
> +  known as a system controller "syscon" or any other memory range containing a
> +  mix of unrelated registers.
> +
> +Optional properties:
> +
> +- compatible : "simple-mfd" - this signifies that the operating system should
> +  spawn child devices for all the subnodes of the MFD device akin to how
> +  "simple-bus" inidicates when to spawn children for a simple memory-mapped
> +  bus. For more complex devices, when the nexus driver has to probe registers
> +  to figure out what children exist etc, this should not be used. In the latter
> +  case the child devices will be instantiated by the operating system.
> +
> +Example:
> +
> +foo@1000 {
> +		compatible = "syscon", "simple-mfd";
> +		reg = <0x010000 0x1000>;
> +
> +		led@08.0 {
> +			compatible = "register-bit-led";
> +			offset = <0x08>;
> +			mask = <0x01>;
> +			label = "myled";
> +			default-state = "on";
> +		};
> +};
> diff --git a/drivers/of/platform.c b/drivers/of/platform.c
> index b189733a1539..969ba4e1460c 100644
> --- a/drivers/of/platform.c
> +++ b/drivers/of/platform.c
> @@ -26,6 +26,7 @@
>  
>  const struct of_device_id of_default_bus_match_table[] = {
>  	{ .compatible = "simple-bus", },
> +	{ .compatible = "simple-mfd", },
>  #ifdef CONFIG_ARM_AMBA
>  	{ .compatible = "arm,amba-bus", },
>  #endif /* CONFIG_ARM_AMBA */
> -- 
> 1.9.3
> 
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

-- 
Antoine Ténart, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply	[flat|nested] 40+ messages in thread

* [PATCH 1/5] MFD/OF: document MFD devices and handle simple-mfd
@ 2015-03-20 13:26         ` Antoine Tenart
  0 siblings, 0 replies; 40+ messages in thread
From: Antoine Tenart @ 2015-03-20 13:26 UTC (permalink / raw)
  To: linux-arm-kernel

On Tue, Mar 03, 2015 at 10:32:24AM +0100, Linus Walleij wrote:
> This defines a new compatible option for MFD devices "simple-mfd" that will
> make the OF core spawn child devices for all subnodes of that MFD device.
> It is optional but handy for things like syscon and possibly other
> simpler MFD devices.
> 
> Since there was no file to put the documentation in, I took this opportunity
> to make a small writeup on MFD devices and add the compatible definition
> there.
> 
> Suggested-by: Lee Jones <lee.jones@linaro.org>
> Cc: Arnd Bergmann <arnd@arndb.de>
> Cc: Devicetree <devicetree@vger.kernel.org>
> Cc: Rob Herring <robh+dt@kernel.org>
> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> Cc: Grant Likely <grant.likely@linaro.org>
> Cc: Pawel Moll <pawel.moll@arm.com>
> Cc: Mark Rutland <mark.rutland@arm.com>
> Cc: Ian Campbell <ijc+devicetree@hellion.org.uk>
> Cc: Kumar Gala <galak@codeaurora.org>
> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>

Since I'm also using this,

Acked-by: Antoine Tenart <antoine.tenart@free-electrons.com>

> ---
> I make the patch to the OF core in this one, it makes much more sense since
> it's a oneliner
> 
> Lee: this is a (tested!) implementation of your suggestion for simple-mfd.
> If you can eventually ACK this from the MFD side, I think it should be
> funneled through the ARM SoC tree.
> 
> Grant/Rob: if either of you can ACK the change to the OF core likewise it can
> be taken through ARM SoC.
> 
> DT binings maintainers: there is some background discussion on this here:
> http://marc.info/?l=linux-arm-kernel&m=142486676603889&w=2
> http://marc.info/?l=devicetree&m=142166313621469&w=2
> ---
>  Documentation/devicetree/bindings/mfd/mfd.txt | 40 +++++++++++++++++++++++++++
>  drivers/of/platform.c                         |  1 +
>  2 files changed, 41 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/mfd/mfd.txt
> 
> diff --git a/Documentation/devicetree/bindings/mfd/mfd.txt b/Documentation/devicetree/bindings/mfd/mfd.txt
> new file mode 100644
> index 000000000000..cc057438abe8
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/mfd/mfd.txt
> @@ -0,0 +1,40 @@
> +Multi-Function Devices (MFD)
> +
> +These devices comprise a nexus for heterogeneous hardware blocks spawning
> +multiple child devices.
> +
> +A typical MFD can be:
> +
> +- A mixed signal ASIC on an external bus, sometimes a PMIC (power management
> +  integrated circuit) that is manufactured in a lower technology node (rough
> +  silicon) that handles analog drivers for things like audio amplifiers, LED
> +  drivers, level shifters, PHY (physical interfaces to things like USB or
> +  ethernet), regulators etc.
> +
> +- A range of memory registers containing "miscellaneous system registers" also
> +  known as a system controller "syscon" or any other memory range containing a
> +  mix of unrelated registers.
> +
> +Optional properties:
> +
> +- compatible : "simple-mfd" - this signifies that the operating system should
> +  spawn child devices for all the subnodes of the MFD device akin to how
> +  "simple-bus" inidicates when to spawn children for a simple memory-mapped
> +  bus. For more complex devices, when the nexus driver has to probe registers
> +  to figure out what children exist etc, this should not be used. In the latter
> +  case the child devices will be instantiated by the operating system.
> +
> +Example:
> +
> +foo at 1000 {
> +		compatible = "syscon", "simple-mfd";
> +		reg = <0x010000 0x1000>;
> +
> +		led at 08.0 {
> +			compatible = "register-bit-led";
> +			offset = <0x08>;
> +			mask = <0x01>;
> +			label = "myled";
> +			default-state = "on";
> +		};
> +};
> diff --git a/drivers/of/platform.c b/drivers/of/platform.c
> index b189733a1539..969ba4e1460c 100644
> --- a/drivers/of/platform.c
> +++ b/drivers/of/platform.c
> @@ -26,6 +26,7 @@
>  
>  const struct of_device_id of_default_bus_match_table[] = {
>  	{ .compatible = "simple-bus", },
> +	{ .compatible = "simple-mfd", },
>  #ifdef CONFIG_ARM_AMBA
>  	{ .compatible = "arm,amba-bus", },
>  #endif /* CONFIG_ARM_AMBA */
> -- 
> 1.9.3
> 
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

-- 
Antoine T?nart, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

^ permalink raw reply	[flat|nested] 40+ messages in thread

* [PATCH 3/5] leds: syscon: instantiate from platform device
  2015-03-03  9:32 ` [PATCH 3/5] leds: syscon: instantiate from platform device Linus Walleij
  2015-03-17 10:36   ` Linus Walleij
@ 2015-03-24 16:50   ` Bjorn Andersson
  1 sibling, 0 replies; 40+ messages in thread
From: Bjorn Andersson @ 2015-03-24 16:50 UTC (permalink / raw)
  To: linux-arm-kernel

On Tue, Mar 3, 2015 at 10:32 AM, Linus Walleij <linus.walleij@linaro.org> wrote:
[..]
> +static int syscon_led_remove(struct platform_device *pdev)
>  {
> -       struct device_node *np;
> -
> -       for_each_of_allnodes(np) {
> -               struct platform_device *pdev;
> -               struct regmap *map;
> -               int ret;
> +       struct syscon_led *sled = platform_get_drvdata(pdev);
>
> -               if (!of_device_is_compatible(np, "syscon"))
> -                       continue;
> +       led_classdev_unregister(&sled->cdev);
> +       /* Turn it off */
> +       regmap_update_bits(sled->map, sled->offset, sled->mask, 0);

led_classdev_unregister() should have called your brightness_set op
already to disable the LED - see led-class.c line 279. So you
shouldn't need this.
I like the rest and have been missing "simple-mfd" in other use cases...

So part of the extra disable:
Reviewed-by: Bjorn Andersson <bjorn.andersson@sonymobile.com>

Regards,
Bjorn

^ permalink raw reply	[flat|nested] 40+ messages in thread

* Re: [PATCH 1/5] MFD/OF: document MFD devices and handle simple-mfd
  2015-03-03  9:32     ` Linus Walleij
@ 2015-03-28 13:41         ` Grant Likely
  -1 siblings, 0 replies; 40+ messages in thread
From: Grant Likely @ 2015-03-28 13:41 UTC (permalink / raw)
  To: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Arnd Bergmann,
	Lee Jones, Bryan Wu
  Cc: Catalin Marinas, Will Deacon, Richard Purdie, Linus Walleij,
	Devicetree, Rob Herring, Benjamin Herrenschmidt, Pawel Moll,
	Mark Rutland, Ian Campbell, Kumar Gala

On Tue,  3 Mar 2015 10:32:24 +0100
, Linus Walleij <linus.walleij-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
 wrote:
> This defines a new compatible option for MFD devices "simple-mfd" that will
> make the OF core spawn child devices for all subnodes of that MFD device.
> It is optional but handy for things like syscon and possibly other
> simpler MFD devices.
> 
> Since there was no file to put the documentation in, I took this opportunity
> to make a small writeup on MFD devices and add the compatible definition
> there.
> 
> Suggested-by: Lee Jones <lee.jones-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
> Cc: Arnd Bergmann <arnd-r2nGTMty4D4@public.gmane.org>
> Cc: Devicetree <devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>
> Cc: Rob Herring <robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
> Cc: Benjamin Herrenschmidt <benh-XVmvHMARGAS8U2dJNN8I7kB+6BGkLq7r@public.gmane.org>
> Cc: Grant Likely <grant.likely-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
> Cc: Pawel Moll <pawel.moll-5wv7dgnIgG8@public.gmane.org>
> Cc: Mark Rutland <mark.rutland-5wv7dgnIgG8@public.gmane.org>
> Cc: Ian Campbell <ijc+devicetree-KcIKpvwj1kUDXYZnReoRVg@public.gmane.org>
> Cc: Kumar Gala <galak-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
> Signed-off-by: Linus Walleij <linus.walleij-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
> ---
> I make the patch to the OF core in this one, it makes much more sense since
> it's a oneliner
> 
> Lee: this is a (tested!) implementation of your suggestion for simple-mfd.
> If you can eventually ACK this from the MFD side, I think it should be
> funneled through the ARM SoC tree.
> 
> Grant/Rob: if either of you can ACK the change to the OF core likewise it can
> be taken through ARM SoC.
> 
> DT binings maintainers: there is some background discussion on this here:
> http://marc.info/?l=linux-arm-kernel&m=142486676603889&w=2
> http://marc.info/?l=devicetree&m=142166313621469&w=2
> ---
>  Documentation/devicetree/bindings/mfd/mfd.txt | 40 +++++++++++++++++++++++++++
>  drivers/of/platform.c                         |  1 +
>  2 files changed, 41 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/mfd/mfd.txt
> 
> diff --git a/Documentation/devicetree/bindings/mfd/mfd.txt b/Documentation/devicetree/bindings/mfd/mfd.txt
> new file mode 100644
> index 000000000000..cc057438abe8
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/mfd/mfd.txt
> @@ -0,0 +1,40 @@
> +Multi-Function Devices (MFD)
> +
> +These devices comprise a nexus for heterogeneous hardware blocks spawning
> +multiple child devices.
> +
> +A typical MFD can be:
> +
> +- A mixed signal ASIC on an external bus, sometimes a PMIC (power management
> +  integrated circuit) that is manufactured in a lower technology node (rough
> +  silicon) that handles analog drivers for things like audio amplifiers, LED
> +  drivers, level shifters, PHY (physical interfaces to things like USB or
> +  ethernet), regulators etc.
> +
> +- A range of memory registers containing "miscellaneous system registers" also
> +  known as a system controller "syscon" or any other memory range containing a
> +  mix of unrelated registers.
> +
> +Optional properties:
> +
> +- compatible : "simple-mfd" - this signifies that the operating system should
> +  spawn child devices for all the subnodes of the MFD device akin to how
> +  "simple-bus" inidicates when to spawn children for a simple memory-mapped
> +  bus. For more complex devices, when the nexus driver has to probe registers
> +  to figure out what children exist etc, this should not be used. In the latter
> +  case the child devices will be instantiated by the operating system.
> +
> +Example:
> +
> +foo@1000 {
> +		compatible = "syscon", "simple-mfd";
> +		reg = <0x010000 0x1000>;
> +
> +		led@08.0 {
> +			compatible = "register-bit-led";
> +			offset = <0x08>;
> +			mask = <0x01>;
> +			label = "myled";
> +			default-state = "on";
> +		};
> +};
> diff --git a/drivers/of/platform.c b/drivers/of/platform.c
> index b189733a1539..969ba4e1460c 100644
> --- a/drivers/of/platform.c
> +++ b/drivers/of/platform.c
> @@ -26,6 +26,7 @@
>  
>  const struct of_device_id of_default_bus_match_table[] = {
>  	{ .compatible = "simple-bus", },
> +	{ .compatible = "simple-mfd", },
>  #ifdef CONFIG_ARM_AMBA
>  	{ .compatible = "arm,amba-bus", },
>  #endif /* CONFIG_ARM_AMBA */

Alright, so:

Acked-by: Grant Likely <grant.likely-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>

However, I think this is going to lead to a future problem. It solves
the immediate case of getting an MFD device to be auto populated when
the kernel doesn't need to immediately do something. However, I can
forsee a situation where the device can be supported by simple-mfd, but
at some point it is discovered that better features can be enabled if
the mfd device has a proper driver.

If/when we get into that situation, the above still works, but we're
going to need to add a blacklist match table so that simple-mfd can be
overridden by a more-specific compatible value. I don't have any
problems with doing that, but someone needs to implement it.

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

^ permalink raw reply	[flat|nested] 40+ messages in thread

* [PATCH 1/5] MFD/OF: document MFD devices and handle simple-mfd
@ 2015-03-28 13:41         ` Grant Likely
  0 siblings, 0 replies; 40+ messages in thread
From: Grant Likely @ 2015-03-28 13:41 UTC (permalink / raw)
  To: linux-arm-kernel

On Tue,  3 Mar 2015 10:32:24 +0100
, Linus Walleij <linus.walleij@linaro.org>
 wrote:
> This defines a new compatible option for MFD devices "simple-mfd" that will
> make the OF core spawn child devices for all subnodes of that MFD device.
> It is optional but handy for things like syscon and possibly other
> simpler MFD devices.
> 
> Since there was no file to put the documentation in, I took this opportunity
> to make a small writeup on MFD devices and add the compatible definition
> there.
> 
> Suggested-by: Lee Jones <lee.jones@linaro.org>
> Cc: Arnd Bergmann <arnd@arndb.de>
> Cc: Devicetree <devicetree@vger.kernel.org>
> Cc: Rob Herring <robh+dt@kernel.org>
> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> Cc: Grant Likely <grant.likely@linaro.org>
> Cc: Pawel Moll <pawel.moll@arm.com>
> Cc: Mark Rutland <mark.rutland@arm.com>
> Cc: Ian Campbell <ijc+devicetree@hellion.org.uk>
> Cc: Kumar Gala <galak@codeaurora.org>
> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
> ---
> I make the patch to the OF core in this one, it makes much more sense since
> it's a oneliner
> 
> Lee: this is a (tested!) implementation of your suggestion for simple-mfd.
> If you can eventually ACK this from the MFD side, I think it should be
> funneled through the ARM SoC tree.
> 
> Grant/Rob: if either of you can ACK the change to the OF core likewise it can
> be taken through ARM SoC.
> 
> DT binings maintainers: there is some background discussion on this here:
> http://marc.info/?l=linux-arm-kernel&m=142486676603889&w=2
> http://marc.info/?l=devicetree&m=142166313621469&w=2
> ---
>  Documentation/devicetree/bindings/mfd/mfd.txt | 40 +++++++++++++++++++++++++++
>  drivers/of/platform.c                         |  1 +
>  2 files changed, 41 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/mfd/mfd.txt
> 
> diff --git a/Documentation/devicetree/bindings/mfd/mfd.txt b/Documentation/devicetree/bindings/mfd/mfd.txt
> new file mode 100644
> index 000000000000..cc057438abe8
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/mfd/mfd.txt
> @@ -0,0 +1,40 @@
> +Multi-Function Devices (MFD)
> +
> +These devices comprise a nexus for heterogeneous hardware blocks spawning
> +multiple child devices.
> +
> +A typical MFD can be:
> +
> +- A mixed signal ASIC on an external bus, sometimes a PMIC (power management
> +  integrated circuit) that is manufactured in a lower technology node (rough
> +  silicon) that handles analog drivers for things like audio amplifiers, LED
> +  drivers, level shifters, PHY (physical interfaces to things like USB or
> +  ethernet), regulators etc.
> +
> +- A range of memory registers containing "miscellaneous system registers" also
> +  known as a system controller "syscon" or any other memory range containing a
> +  mix of unrelated registers.
> +
> +Optional properties:
> +
> +- compatible : "simple-mfd" - this signifies that the operating system should
> +  spawn child devices for all the subnodes of the MFD device akin to how
> +  "simple-bus" inidicates when to spawn children for a simple memory-mapped
> +  bus. For more complex devices, when the nexus driver has to probe registers
> +  to figure out what children exist etc, this should not be used. In the latter
> +  case the child devices will be instantiated by the operating system.
> +
> +Example:
> +
> +foo at 1000 {
> +		compatible = "syscon", "simple-mfd";
> +		reg = <0x010000 0x1000>;
> +
> +		led at 08.0 {
> +			compatible = "register-bit-led";
> +			offset = <0x08>;
> +			mask = <0x01>;
> +			label = "myled";
> +			default-state = "on";
> +		};
> +};
> diff --git a/drivers/of/platform.c b/drivers/of/platform.c
> index b189733a1539..969ba4e1460c 100644
> --- a/drivers/of/platform.c
> +++ b/drivers/of/platform.c
> @@ -26,6 +26,7 @@
>  
>  const struct of_device_id of_default_bus_match_table[] = {
>  	{ .compatible = "simple-bus", },
> +	{ .compatible = "simple-mfd", },
>  #ifdef CONFIG_ARM_AMBA
>  	{ .compatible = "arm,amba-bus", },
>  #endif /* CONFIG_ARM_AMBA */

Alright, so:

Acked-by: Grant Likely <grant.likely@linaro.org>

However, I think this is going to lead to a future problem. It solves
the immediate case of getting an MFD device to be auto populated when
the kernel doesn't need to immediately do something. However, I can
forsee a situation where the device can be supported by simple-mfd, but
at some point it is discovered that better features can be enabled if
the mfd device has a proper driver.

If/when we get into that situation, the above still works, but we're
going to need to add a blacklist match table so that simple-mfd can be
overridden by a more-specific compatible value. I don't have any
problems with doing that, but someone needs to implement it.

g.

^ permalink raw reply	[flat|nested] 40+ messages in thread

* Re: [PATCH 1/5] MFD/OF: document MFD devices and handle simple-mfd
  2015-03-03  9:32     ` Linus Walleij
@ 2015-04-03 18:34         ` Olof Johansson
  -1 siblings, 0 replies; 40+ messages in thread
From: Olof Johansson @ 2015-04-03 18:34 UTC (permalink / raw)
  To: Linus Walleij
  Cc: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Arnd Bergmann,
	Lee Jones, Bryan Wu, Catalin Marinas, Will Deacon,
	Richard Purdie, Devicetree, Rob Herring, Benjamin Herrenschmidt,
	Grant Likely, Pawel Moll, Mark Rutland, Ian Campbell, Kumar Gala

Hi,

I understand this is bikeshedding to some extent, but I'd also like to
avoid needless variation in binding formats:

On Tue, Mar 3, 2015 at 1:32 AM, Linus Walleij <linus.walleij-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org> wrote:

> +
> +foo@1000 {
> +               compatible = "syscon", "simple-mfd";
> +               reg = <0x010000 0x1000>;
> +
> +               led@08.0 {

This doesn't seem to be a typo, you're using a period in the unit
address. I've never seen that done before, usually commas are used
instead.

Was there a reason for going with period?


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

^ permalink raw reply	[flat|nested] 40+ messages in thread

* [PATCH 1/5] MFD/OF: document MFD devices and handle simple-mfd
@ 2015-04-03 18:34         ` Olof Johansson
  0 siblings, 0 replies; 40+ messages in thread
From: Olof Johansson @ 2015-04-03 18:34 UTC (permalink / raw)
  To: linux-arm-kernel

Hi,

I understand this is bikeshedding to some extent, but I'd also like to
avoid needless variation in binding formats:

On Tue, Mar 3, 2015 at 1:32 AM, Linus Walleij <linus.walleij@linaro.org> wrote:

> +
> +foo at 1000 {
> +               compatible = "syscon", "simple-mfd";
> +               reg = <0x010000 0x1000>;
> +
> +               led at 08.0 {

This doesn't seem to be a typo, you're using a period in the unit
address. I've never seen that done before, usually commas are used
instead.

Was there a reason for going with period?


-Olof

^ permalink raw reply	[flat|nested] 40+ messages in thread

* Re: [PATCH 1/5] MFD/OF: document MFD devices and handle simple-mfd
  2015-04-03 18:34         ` Olof Johansson
@ 2015-04-07  7:16             ` Lee Jones
  -1 siblings, 0 replies; 40+ messages in thread
From: Lee Jones @ 2015-04-07  7:16 UTC (permalink / raw)
  To: Olof Johansson
  Cc: Linus Walleij, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
	Arnd Bergmann, Bryan Wu, Catalin Marinas, Will Deacon,
	Richard Purdie, Devicetree, Rob Herring, Benjamin Herrenschmidt,
	Grant Likely, Pawel Moll, Mark Rutland, Ian Campbell, Kumar Gala

On Fri, 03 Apr 2015, Olof Johansson wrote:

> Hi,
> 
> I understand this is bikeshedding to some extent, but I'd also like to
> avoid needless variation in binding formats:
> 
> On Tue, Mar 3, 2015 at 1:32 AM, Linus Walleij <linus.walleij@linaro.org> wrote:
> 
> > +
> > +foo@1000 {
> > +               compatible = "syscon", "simple-mfd";
> > +               reg = <0x010000 0x1000>;
> > +
> > +               led@08.0 {
> 
> This doesn't seem to be a typo, you're using a period in the unit
> address. I've never seen that done before, usually commas are used
> instead.
> 
> Was there a reason for going with period?

LEDs have always done it [1].  I guess Bryan would be the best person
to answer the 'why'.

git grep "led.*@[0-9]*[.,][0-9]*" -- Documentation/devicetree/ arch/arm/boot/dts/

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply	[flat|nested] 40+ messages in thread

* [PATCH 1/5] MFD/OF: document MFD devices and handle simple-mfd
@ 2015-04-07  7:16             ` Lee Jones
  0 siblings, 0 replies; 40+ messages in thread
From: Lee Jones @ 2015-04-07  7:16 UTC (permalink / raw)
  To: linux-arm-kernel

On Fri, 03 Apr 2015, Olof Johansson wrote:

> Hi,
> 
> I understand this is bikeshedding to some extent, but I'd also like to
> avoid needless variation in binding formats:
> 
> On Tue, Mar 3, 2015 at 1:32 AM, Linus Walleij <linus.walleij@linaro.org> wrote:
> 
> > +
> > +foo at 1000 {
> > +               compatible = "syscon", "simple-mfd";
> > +               reg = <0x010000 0x1000>;
> > +
> > +               led at 08.0 {
> 
> This doesn't seem to be a typo, you're using a period in the unit
> address. I've never seen that done before, usually commas are used
> instead.
> 
> Was there a reason for going with period?

LEDs have always done it [1].  I guess Bryan would be the best person
to answer the 'why'.

git grep "led.*@[0-9]*[.,][0-9]*" -- Documentation/devicetree/ arch/arm/boot/dts/

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog

^ permalink raw reply	[flat|nested] 40+ messages in thread

* Re: [PATCH 1/5] MFD/OF: document MFD devices and handle simple-mfd
  2015-04-03 18:34         ` Olof Johansson
@ 2015-04-07  9:00             ` Linus Walleij
  -1 siblings, 0 replies; 40+ messages in thread
From: Linus Walleij @ 2015-04-07  9:00 UTC (permalink / raw)
  To: Olof Johansson
  Cc: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Arnd Bergmann,
	Lee Jones, Bryan Wu, Catalin Marinas, Will Deacon,
	Richard Purdie, Devicetree, Rob Herring, Benjamin Herrenschmidt,
	Grant Likely, Pawel Moll, Mark Rutland, Ian Campbell, Kumar Gala

On Fri, Apr 3, 2015 at 8:34 PM, Olof Johansson <olof-nZhT3qVonbNeoWH0uzbU5w@public.gmane.org> wrote:
> On Tue, Mar 3, 2015 at 1:32 AM, Linus Walleij <linus.walleij-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org> wrote:
>
>> +
>> +foo@1000 {
>> +               compatible = "syscon", "simple-mfd";
>> +               reg = <0x010000 0x1000>;
>> +
>> +               led@08.0 {
>
> This doesn't seem to be a typo, you're using a period in the unit
> address. I've never seen that done before, usually commas are used
> instead.
>
> Was there a reason for going with period?

It was the suggested syntax from DT binding maintainer Rob Herring in
July last year:
http://marc.info/?l=linux-arm-kernel&m=140629736615939&w=2

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

^ permalink raw reply	[flat|nested] 40+ messages in thread

* [PATCH 1/5] MFD/OF: document MFD devices and handle simple-mfd
@ 2015-04-07  9:00             ` Linus Walleij
  0 siblings, 0 replies; 40+ messages in thread
From: Linus Walleij @ 2015-04-07  9:00 UTC (permalink / raw)
  To: linux-arm-kernel

On Fri, Apr 3, 2015 at 8:34 PM, Olof Johansson <olof@lixom.net> wrote:
> On Tue, Mar 3, 2015 at 1:32 AM, Linus Walleij <linus.walleij@linaro.org> wrote:
>
>> +
>> +foo at 1000 {
>> +               compatible = "syscon", "simple-mfd";
>> +               reg = <0x010000 0x1000>;
>> +
>> +               led at 08.0 {
>
> This doesn't seem to be a typo, you're using a period in the unit
> address. I've never seen that done before, usually commas are used
> instead.
>
> Was there a reason for going with period?

It was the suggested syntax from DT binding maintainer Rob Herring in
July last year:
http://marc.info/?l=linux-arm-kernel&m=140629736615939&w=2

Yours,
Linus Walleij

^ permalink raw reply	[flat|nested] 40+ messages in thread

* Re: [PATCH 1/5] MFD/OF: document MFD devices and handle simple-mfd
  2015-03-28 13:41         ` Grant Likely
@ 2015-04-07  9:03             ` Linus Walleij
  -1 siblings, 0 replies; 40+ messages in thread
From: Linus Walleij @ 2015-04-07  9:03 UTC (permalink / raw)
  To: Grant Likely
  Cc: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Arnd Bergmann,
	Lee Jones, Bryan Wu, Catalin Marinas, Will Deacon,
	Richard Purdie, Devicetree, Rob Herring, Benjamin Herrenschmidt,
	Pawel Moll, Mark Rutland, Ian Campbell, Kumar Gala

On Sat, Mar 28, 2015 at 2:41 PM, Grant Likely <grant.likely-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org> wrote:

> However, I think this is going to lead to a future problem. It solves
> the immediate case of getting an MFD device to be auto populated when
> the kernel doesn't need to immediately do something. However, I can
> forsee a situation where the device can be supported by simple-mfd, but
> at some point it is discovered that better features can be enabled if
> the mfd device has a proper driver.

For the general case where access to the MFD needs some mediation
or marshalling yes, I think this is theoretically possible.

For the most common MMIO case where the MFD devide is a syscon,
it is not so likely. Or rather extremelt unlikely.

We could restrict the use cases to strictly syscon/MMIO MFD devices
but it would just be a documentation fix.

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

^ permalink raw reply	[flat|nested] 40+ messages in thread

* [PATCH 1/5] MFD/OF: document MFD devices and handle simple-mfd
@ 2015-04-07  9:03             ` Linus Walleij
  0 siblings, 0 replies; 40+ messages in thread
From: Linus Walleij @ 2015-04-07  9:03 UTC (permalink / raw)
  To: linux-arm-kernel

On Sat, Mar 28, 2015 at 2:41 PM, Grant Likely <grant.likely@linaro.org> wrote:

> However, I think this is going to lead to a future problem. It solves
> the immediate case of getting an MFD device to be auto populated when
> the kernel doesn't need to immediately do something. However, I can
> forsee a situation where the device can be supported by simple-mfd, but
> at some point it is discovered that better features can be enabled if
> the mfd device has a proper driver.

For the general case where access to the MFD needs some mediation
or marshalling yes, I think this is theoretically possible.

For the most common MMIO case where the MFD devide is a syscon,
it is not so likely. Or rather extremelt unlikely.

We could restrict the use cases to strictly syscon/MMIO MFD devices
but it would just be a documentation fix.

Yours,
Linus Walleij

^ permalink raw reply	[flat|nested] 40+ messages in thread

end of thread, other threads:[~2015-04-07  9:03 UTC | newest]

Thread overview: 40+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2015-03-03  9:32 [PATCH 0/5] simple-mfd and syscon LEDs Linus Walleij
     [not found] ` <1425375148-4369-1-git-send-email-linus.walleij-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
2015-03-03  9:32   ` [PATCH 1/5] MFD/OF: document MFD devices and handle simple-mfd Linus Walleij
2015-03-03  9:32     ` Linus Walleij
     [not found]     ` <1425375148-4369-2-git-send-email-linus.walleij-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
2015-03-03 10:25       ` Lee Jones
2015-03-03 10:25         ` Lee Jones
2015-03-09 14:29         ` Linus Walleij
2015-03-09 14:29           ` Linus Walleij
2015-03-03 17:47       ` Rob Herring
2015-03-03 17:47         ` Rob Herring
2015-03-03 17:56         ` Lee Jones
2015-03-03 17:56           ` Lee Jones
2015-03-09 14:35         ` Linus Walleij
2015-03-09 14:35           ` Linus Walleij
2015-03-12  9:14       ` Alexandre Belloni
2015-03-12  9:14         ` Alexandre Belloni
     [not found]         ` <20150312091427.GA4329-m++hUPXGwpdeoWH0uzbU5w@public.gmane.org>
2015-03-17 10:28           ` Linus Walleij
2015-03-17 10:28             ` Linus Walleij
     [not found]             ` <CACRpkdacQ-MR+Sziu-TQXWr+1UCtBphZ5eNSWbJ2ZpCnH+o9JA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2015-03-17 10:38               ` Linus Walleij
2015-03-17 10:38                 ` Linus Walleij
2015-03-18 16:06       ` Alexandre Belloni
2015-03-18 16:06         ` Alexandre Belloni
2015-03-20 13:26       ` Antoine Tenart
2015-03-20 13:26         ` Antoine Tenart
2015-03-28 13:41       ` Grant Likely
2015-03-28 13:41         ` Grant Likely
     [not found]         ` <20150328134157.000A3C40AE0-WNowdnHR2B42iJbIjFUEsiwD8/FfD2ys@public.gmane.org>
2015-04-07  9:03           ` Linus Walleij
2015-04-07  9:03             ` Linus Walleij
2015-04-03 18:34       ` Olof Johansson
2015-04-03 18:34         ` Olof Johansson
     [not found]         ` <CAOesGMhz6WPweQFXfPhTO6Pz5L4Z1Si6YGiCRCiFD9B5qB9tVw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2015-04-07  7:16           ` Lee Jones
2015-04-07  7:16             ` Lee Jones
2015-04-07  9:00           ` Linus Walleij
2015-04-07  9:00             ` Linus Walleij
2015-03-03  9:32 ` [PATCH 2/5] ARM: dts: update syscons to use simple-mfd Linus Walleij
2015-03-03  9:32 ` [PATCH 3/5] leds: syscon: instantiate from platform device Linus Walleij
2015-03-17 10:36   ` Linus Walleij
2015-03-24 16:50   ` Bjorn Andersson
2015-03-03  9:32 ` [PATCH 4/5] arm64: juno: Add APB registers and LEDs using syscon Linus Walleij
2015-03-04 15:57   ` Liviu Dudau
2015-03-03  9:32 ` [PATCH 5/5] arm64: add LEDs and some trigger support to defconfig Linus Walleij

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