[PATCH v3 0/4] Raspberry Pi power domains

[PATCH v3 0/4] Raspberry Pi power domains

[Eric Anholt]

Since the pm_genpd_exit() patch is still going through review, and
other drivers in the tree just ignore the error cases, Ulf offered to
merge the series as a builtin driver not depending on that interface.
We still avoid dangling pointer references, by just continuing with
probing if of_genpd_add_provider_onecell() fails.  We can easily go
back and update the driver when a pm_genpd_exit() lands.

Alexander Aring (3):
  ARM: bcm2835: add rpi power domain driver
  dt-bindings: add rpi power domain driver bindings
  ARM: bcm2835: Add the Raspberry Pi power domain driver to the DT.

Eric Anholt (1):
  ARM: bcm2835: Define two new packets from the latest firmware.

 .../bindings/arm/bcm/raspberrypi,bcm2835-power.txt |  47 ++++
 arch/arm/boot/dts/bcm2835-rpi.dtsi                 |  11 +
 arch/arm/boot/dts/bcm2835.dtsi                     |   2 +-
 arch/arm/mach-bcm/Kconfig                          |  10 +
 arch/arm/mach-bcm/Makefile                         |   1 +
 arch/arm/mach-bcm/raspberrypi-power.c              | 247 +++++++++++++++++++++
 include/dt-bindings/arm/raspberrypi-power.h        |  41 ++++
 include/soc/bcm2835/raspberrypi-firmware.h         |   2 +
 8 files changed, 360 insertions(+), 1 deletion(-)
 create mode 100644 Documentation/devicetree/bindings/arm/bcm/raspberrypi,bcm2835-power.txt
 create mode 100644 arch/arm/mach-bcm/raspberrypi-power.c
 create mode 100644 include/dt-bindings/arm/raspberrypi-power.h

-- 
2.6.2

[PATCH v3 0/4] Raspberry Pi power domains

[Eric Anholt]

Since the pm_genpd_exit() patch is still going through review, and
other drivers in the tree just ignore the error cases, Ulf offered to
merge the series as a builtin driver not depending on that interface.
We still avoid dangling pointer references, by just continuing with
probing if of_genpd_add_provider_onecell() fails.  We can easily go
back and update the driver when a pm_genpd_exit() lands.

Alexander Aring (3):
  ARM: bcm2835: add rpi power domain driver
  dt-bindings: add rpi power domain driver bindings
  ARM: bcm2835: Add the Raspberry Pi power domain driver to the DT.

Eric Anholt (1):
  ARM: bcm2835: Define two new packets from the latest firmware.

 .../bindings/arm/bcm/raspberrypi,bcm2835-power.txt |  47 ++++
 arch/arm/boot/dts/bcm2835-rpi.dtsi                 |  11 +
 arch/arm/boot/dts/bcm2835.dtsi                     |   2 +-
 arch/arm/mach-bcm/Kconfig                          |  10 +
 arch/arm/mach-bcm/Makefile                         |   1 +
 arch/arm/mach-bcm/raspberrypi-power.c              | 247 +++++++++++++++++++++
 include/dt-bindings/arm/raspberrypi-power.h        |  41 ++++
 include/soc/bcm2835/raspberrypi-firmware.h         |   2 +
 8 files changed, 360 insertions(+), 1 deletion(-)
 create mode 100644 Documentation/devicetree/bindings/arm/bcm/raspberrypi,bcm2835-power.txt
 create mode 100644 arch/arm/mach-bcm/raspberrypi-power.c
 create mode 100644 include/dt-bindings/arm/raspberrypi-power.h

-- 
2.6.2

[PATCH v3 1/4] ARM: bcm2835: Define two new packets from the latest firmware.

[Eric Anholt]

These packets give us direct access to the firmware's power management
code, as opposed to GET/SET_POWER_STATE packets that only had a couple
of domains implemented.

Signed-off-by: Eric Anholt <eric@anholt.net>
---
 include/soc/bcm2835/raspberrypi-firmware.h | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/include/soc/bcm2835/raspberrypi-firmware.h b/include/soc/bcm2835/raspberrypi-firmware.h
index c07d74a..3fb3571 100644
--- a/include/soc/bcm2835/raspberrypi-firmware.h
+++ b/include/soc/bcm2835/raspberrypi-firmware.h
@@ -72,10 +72,12 @@ enum rpi_firmware_property_tag {
 	RPI_FIRMWARE_SET_ENABLE_QPU =                         0x00030012,
 	RPI_FIRMWARE_GET_DISPMANX_RESOURCE_MEM_HANDLE =       0x00030014,
 	RPI_FIRMWARE_GET_EDID_BLOCK =                         0x00030020,
+	RPI_FIRMWARE_GET_DOMAIN_STATE =                       0x00030030,
 	RPI_FIRMWARE_SET_CLOCK_STATE =                        0x00038001,
 	RPI_FIRMWARE_SET_CLOCK_RATE =                         0x00038002,
 	RPI_FIRMWARE_SET_VOLTAGE =                            0x00038003,
 	RPI_FIRMWARE_SET_TURBO =                              0x00038009,
+	RPI_FIRMWARE_SET_DOMAIN_STATE =                       0x00038030,
 
 	/* Dispmanx TAGS */
 	RPI_FIRMWARE_FRAMEBUFFER_ALLOCATE =                   0x00040001,
-- 
2.6.2

[PATCH v3 1/4] ARM: bcm2835: Define two new packets from the latest firmware.

[Eric Anholt]

These packets give us direct access to the firmware's power management
code, as opposed to GET/SET_POWER_STATE packets that only had a couple
of domains implemented.

Signed-off-by: Eric Anholt <eric@anholt.net>
---
 include/soc/bcm2835/raspberrypi-firmware.h | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/include/soc/bcm2835/raspberrypi-firmware.h b/include/soc/bcm2835/raspberrypi-firmware.h
index c07d74a..3fb3571 100644
--- a/include/soc/bcm2835/raspberrypi-firmware.h
+++ b/include/soc/bcm2835/raspberrypi-firmware.h
@@ -72,10 +72,12 @@ enum rpi_firmware_property_tag {
 	RPI_FIRMWARE_SET_ENABLE_QPU =                         0x00030012,
 	RPI_FIRMWARE_GET_DISPMANX_RESOURCE_MEM_HANDLE =       0x00030014,
 	RPI_FIRMWARE_GET_EDID_BLOCK =                         0x00030020,
+	RPI_FIRMWARE_GET_DOMAIN_STATE =                       0x00030030,
 	RPI_FIRMWARE_SET_CLOCK_STATE =                        0x00038001,
 	RPI_FIRMWARE_SET_CLOCK_RATE =                         0x00038002,
 	RPI_FIRMWARE_SET_VOLTAGE =                            0x00038003,
 	RPI_FIRMWARE_SET_TURBO =                              0x00038009,
+	RPI_FIRMWARE_SET_DOMAIN_STATE =                       0x00038030,
 
 	/* Dispmanx TAGS */
 	RPI_FIRMWARE_FRAMEBUFFER_ALLOCATE =                   0x00040001,
-- 
2.6.2

[PATCH v3 2/4] ARM: bcm2835: add rpi power domain driver

[Eric Anholt]

From: Alexander Aring <alex.aring@gmail.com>

This patch adds support for several power domains on Raspberry Pi,
including USB (so it can be enabled even if the bootloader didn't do
it), and graphics.

This patch is the combined work of Eric Anholt (who wrote USB support
inside of the Raspberry Pi firmware driver, and wrote the non-USB
domain support) and Alexander Aring (who separated the original USB
work out from the firmware driver).

Signed-off-by: Alexander Aring <alex.aring@gmail.com>
Signed-off-by: Eric Anholt <eric@anholt.net>
---

v2: Add support for power domains other than USB, using the new
    firmware interface, reword commit message (changes by Eric)

v3: Restructure as a builtin driver, and drop
    of_genpd_add_provider_onecell error handling to avoid
    pm_genpd_exit() dependency until that API can be settled.  Clean
    up copyright header, add missing ISP initialization, and fix typo
    in transposer's name.

 arch/arm/mach-bcm/Kconfig                   |  10 ++
 arch/arm/mach-bcm/Makefile                  |   1 +
 arch/arm/mach-bcm/raspberrypi-power.c       | 247 ++++++++++++++++++++++++++++
 include/dt-bindings/arm/raspberrypi-power.h |  41 +++++
 4 files changed, 299 insertions(+)
 create mode 100644 arch/arm/mach-bcm/raspberrypi-power.c
 create mode 100644 include/dt-bindings/arm/raspberrypi-power.h

diff --git a/arch/arm/mach-bcm/Kconfig b/arch/arm/mach-bcm/Kconfig
index 8c53c55..0f23bad 100644
--- a/arch/arm/mach-bcm/Kconfig
+++ b/arch/arm/mach-bcm/Kconfig
@@ -134,6 +134,16 @@ config ARCH_BCM2835
 	  This enables support for the Broadcom BCM2835 SoC. This SoC is
 	  used in the Raspberry Pi and Roku 2 devices.
 
+config RASPBERRYPI_POWER
+	bool "Raspberry Pi power domain driver"
+	depends on ARCH_BCM2835 || COMPILE_TEST
+	depends on RASPBERRYPI_FIRMWARE
+	select PM_GENERIC_DOMAINS if PM
+	select PM_GENERIC_DOMAINS_OF if PM
+	help
+	  This enables support for the RPi power domains which can be enabled
+	  or disabled via the RPi firmware.
+
 config ARCH_BCM_63XX
 	bool "Broadcom BCM63xx DSL SoC" if ARCH_MULTI_V7
 	depends on MMU
diff --git a/arch/arm/mach-bcm/Makefile b/arch/arm/mach-bcm/Makefile
index 892261f..fec2d6b 100644
--- a/arch/arm/mach-bcm/Makefile
+++ b/arch/arm/mach-bcm/Makefile
@@ -36,6 +36,7 @@ endif
 
 # BCM2835
 obj-$(CONFIG_ARCH_BCM2835)	+= board_bcm2835.o
+obj-$(CONFIG_RASPBERRYPI_POWER)	+= raspberrypi-power.o
 
 # BCM5301X
 obj-$(CONFIG_ARCH_BCM_5301X)	+= bcm_5301x.o
diff --git a/arch/arm/mach-bcm/raspberrypi-power.c b/arch/arm/mach-bcm/raspberrypi-power.c
new file mode 100644
index 0000000..9dc8b43
--- /dev/null
+++ b/arch/arm/mach-bcm/raspberrypi-power.c
@@ -0,0 +1,247 @@
+/* (C) 2015 Pengutronix, Alexander Aring <aar@pengutronix.de>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * Authors:
+ * Alexander Aring <aar@pengutronix.de>
+ * Eric Anholt <eric@anholt.net>
+ */
+
+#include <linux/module.h>
+#include <linux/of_platform.h>
+#include <linux/platform_device.h>
+#include <linux/pm_domain.h>
+#include <dt-bindings/arm/raspberrypi-power.h>
+#include <soc/bcm2835/raspberrypi-firmware.h>
+
+/*
+ * Firmware indices for the old power domains interface.  Only a few
+ * of them were actually implemented.
+ */
+#define RPI_OLD_POWER_DOMAIN_USB		3
+#define RPI_OLD_POWER_DOMAIN_V3D		10
+
+struct rpi_power_domain {
+	u32 domain;
+	bool enabled;
+	bool old_interface;
+	struct generic_pm_domain base;
+	struct rpi_firmware *fw;
+};
+
+struct rpi_power_domains {
+	bool has_new_interface;
+	struct genpd_onecell_data xlate;
+	struct rpi_firmware *fw;
+	struct rpi_power_domain domains[RPI_POWER_DOMAIN_COUNT];
+};
+
+/*
+ * Packet definition used by RPI_FIRMWARE_SET_POWER_STATE and
+ * RPI_FIRMWARE_SET_DOMAIN_STATE
+ */
+struct rpi_power_domain_packet {
+	u32 domain;
+	u32 on;
+} __packet;
+
+/*
+ * Asks the firmware to enable or disable power on a specific power
+ * domain.
+ */
+static int rpi_firmware_set_power(struct rpi_power_domain *rpi_domain, bool on)
+{
+	struct rpi_power_domain_packet packet;
+
+	packet.domain = rpi_domain->domain;
+	packet.on = on;
+	return rpi_firmware_property(rpi_domain->fw,
+				     rpi_domain->old_interface ?
+				     RPI_FIRMWARE_SET_POWER_STATE :
+				     RPI_FIRMWARE_SET_DOMAIN_STATE,
+				     &packet, sizeof(packet));
+}
+
+static int rpi_domain_off(struct generic_pm_domain *domain)
+{
+	struct rpi_power_domain *rpi_domain =
+		container_of(domain, struct rpi_power_domain, base);
+
+	return rpi_firmware_set_power(rpi_domain, false);
+}
+
+static int rpi_domain_on(struct generic_pm_domain *domain)
+{
+	struct rpi_power_domain *rpi_domain =
+		container_of(domain, struct rpi_power_domain, base);
+
+	return rpi_firmware_set_power(rpi_domain, true);
+}
+
+static void rpi_common_init_power_domain(struct rpi_power_domains *rpi_domains,
+					 int xlate_index, const char *name)
+{
+	struct rpi_power_domain *dom = &rpi_domains->domains[xlate_index];
+
+	dom->fw = rpi_domains->fw;
+
+	dom->base.name = name;
+	dom->base.power_on = rpi_domain_on;
+	dom->base.power_off = rpi_domain_off;
+
+	/*
+	 * Treat all power domains as off at boot.
+	 *
+	 * The firmware itself may be keeping some domains on, but
+	 * from Linux's perspective all we control is the refcounts
+	 * that we give to the firmware, and we can't ask the firmware
+	 * to turn off something that we haven't ourselves turned on.
+	 */
+	pm_genpd_init(&dom->base, NULL, true);
+
+	rpi_domains->xlate.domains[xlate_index] = &dom->base;
+}
+
+static void rpi_init_power_domain(struct rpi_power_domains *rpi_domains,
+				  int xlate_index, const char *name)
+{
+	struct rpi_power_domain *dom = &rpi_domains->domains[xlate_index];
+
+	if (!rpi_domains->has_new_interface)
+		return;
+
+	/* The DT binding index is the firmware's domain index minus one. */
+	dom->domain = xlate_index + 1;
+
+	rpi_common_init_power_domain(rpi_domains, xlate_index, name);
+}
+
+static void rpi_init_old_power_domain(struct rpi_power_domains *rpi_domains,
+				      int xlate_index, int domain,
+				      const char *name)
+{
+	struct rpi_power_domain *dom = &rpi_domains->domains[xlate_index];
+
+	dom->old_interface = true;
+	dom->domain = domain;
+
+	rpi_common_init_power_domain(rpi_domains, xlate_index, name);
+}
+
+/*
+ * Detects whether the firmware supports the new power domains interface.
+ *
+ * The firmware doesn't actually return an error on an unknown tag,
+ * and just skips over it, so we do the detection by putting an
+ * unexpected value in the return field and checking if it was
+ * unchanged.
+ */
+static bool
+rpi_has_new_domain_support(struct rpi_power_domains *rpi_domains)
+{
+	struct rpi_power_domain_packet packet;
+	int ret;
+
+	packet.domain = RPI_POWER_DOMAIN_ARM;
+	packet.on = ~0;
+
+	ret = rpi_firmware_property(rpi_domains->fw,
+				    RPI_FIRMWARE_GET_DOMAIN_STATE,
+				    &packet, sizeof(packet));
+
+	return ret == 0 && packet.on != ~0;
+}
+
+static int rpi_power_probe(struct platform_device *pdev)
+{
+	struct device_node *fw_np;
+	struct device *dev = &pdev->dev;
+	struct rpi_power_domains *rpi_domains;
+
+	rpi_domains = devm_kzalloc(dev, sizeof(*rpi_domains), GFP_KERNEL);
+	if (!rpi_domains)
+		return -ENOMEM;
+
+	rpi_domains->xlate.domains =
+		devm_kzalloc(dev, sizeof(*rpi_domains->xlate.domains) *
+			     RPI_POWER_DOMAIN_COUNT, GFP_KERNEL);
+	if (!rpi_domains->xlate.domains)
+		return -ENOMEM;
+
+	rpi_domains->xlate.num_domains = RPI_POWER_DOMAIN_COUNT;
+
+	fw_np = of_parse_phandle(pdev->dev.of_node, "firmware", 0);
+	if (!fw_np) {
+		dev_err(&pdev->dev, "no firmware node\n");
+		return -ENODEV;
+	}
+
+	rpi_domains->fw = rpi_firmware_get(fw_np);
+	of_node_put(fw_np);
+	if (!rpi_domains->fw)
+		return -EPROBE_DEFER;
+
+	rpi_domains->has_new_interface =
+		rpi_has_new_domain_support(rpi_domains);
+
+	rpi_init_power_domain(rpi_domains, RPI_POWER_DOMAIN_I2C0, "I2C0");
+	rpi_init_power_domain(rpi_domains, RPI_POWER_DOMAIN_I2C1, "I2C1");
+	rpi_init_power_domain(rpi_domains, RPI_POWER_DOMAIN_I2C2, "I2C2");
+	rpi_init_power_domain(rpi_domains, RPI_POWER_DOMAIN_VIDEO_SCALER,
+			      "VIDEO_SCALER");
+	rpi_init_power_domain(rpi_domains, RPI_POWER_DOMAIN_VPU1, "VPU1");
+	rpi_init_power_domain(rpi_domains, RPI_POWER_DOMAIN_HDMI, "HDMI");
+
+	/*
+	 * Use the old firmware interface for USB power, so that we
+	 * can turn it on even if the firmware hasn't been updated.
+	 */
+	rpi_init_old_power_domain(rpi_domains, RPI_POWER_DOMAIN_USB,
+				  RPI_OLD_POWER_DOMAIN_USB, "USB");
+
+	rpi_init_power_domain(rpi_domains, RPI_POWER_DOMAIN_VEC, "VEC");
+	rpi_init_power_domain(rpi_domains, RPI_POWER_DOMAIN_JPEG, "JPEG");
+	rpi_init_power_domain(rpi_domains, RPI_POWER_DOMAIN_H264, "H264");
+	rpi_init_power_domain(rpi_domains, RPI_POWER_DOMAIN_V3D, "V3D");
+	rpi_init_power_domain(rpi_domains, RPI_POWER_DOMAIN_ISP, "ISP");
+	rpi_init_power_domain(rpi_domains, RPI_POWER_DOMAIN_UNICAM0, "UNICAM0");
+	rpi_init_power_domain(rpi_domains, RPI_POWER_DOMAIN_UNICAM1, "UNICAM1");
+	rpi_init_power_domain(rpi_domains, RPI_POWER_DOMAIN_CCP2RX, "CCP2RX");
+	rpi_init_power_domain(rpi_domains, RPI_POWER_DOMAIN_CSI2, "CSI2");
+	rpi_init_power_domain(rpi_domains, RPI_POWER_DOMAIN_CPI, "CPI");
+	rpi_init_power_domain(rpi_domains, RPI_POWER_DOMAIN_DSI0, "DSI0");
+	rpi_init_power_domain(rpi_domains, RPI_POWER_DOMAIN_DSI1, "DSI1");
+	rpi_init_power_domain(rpi_domains, RPI_POWER_DOMAIN_TRANSPOSER,
+			      "TRANSPOSER");
+	rpi_init_power_domain(rpi_domains, RPI_POWER_DOMAIN_CCP2TX, "CCP2TX");
+	rpi_init_power_domain(rpi_domains, RPI_POWER_DOMAIN_CDP, "CDP");
+	rpi_init_power_domain(rpi_domains, RPI_POWER_DOMAIN_ARM, "ARM");
+
+	of_genpd_add_provider_onecell(dev->of_node, &rpi_domains->xlate);
+
+	platform_set_drvdata(pdev, rpi_domains);
+
+	return 0;
+}
+
+static const struct of_device_id rpi_power_of_match[] = {
+	{ .compatible = "raspberrypi,bcm2835-power", },
+	{},
+};
+MODULE_DEVICE_TABLE(of, rpi_power_of_match);
+
+static struct platform_driver rpi_power_driver = {
+	.driver = {
+		.name = "raspberrypi-power",
+		.of_match_table = rpi_power_of_match,
+	},
+	.probe		= rpi_power_probe,
+};
+builtin_platform_driver(rpi_power_driver);
+
+MODULE_AUTHOR("Alexander Aring <aar@pengutronix.de>");
+MODULE_AUTHOR("Eric Anholt <eric@anholt.net>");
+MODULE_DESCRIPTION("Raspberry Pi power domain driver");
+MODULE_LICENSE("GPL v2");
diff --git a/include/dt-bindings/arm/raspberrypi-power.h b/include/dt-bindings/arm/raspberrypi-power.h
new file mode 100644
index 0000000..b3ff8e0
--- /dev/null
+++ b/include/dt-bindings/arm/raspberrypi-power.h
@@ -0,0 +1,41 @@
+/*
+ *  Copyright © 2015 Broadcom
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#ifndef _DT_BINDINGS_ARM_BCM2835_RPI_POWER_H
+#define _DT_BINDINGS_ARM_BCM2835_RPI_POWER_H
+
+/* These power domain indices are the firmware interface's indices
+ * minus one.
+ */
+#define RPI_POWER_DOMAIN_I2C0		0
+#define RPI_POWER_DOMAIN_I2C1		1
+#define RPI_POWER_DOMAIN_I2C2		2
+#define RPI_POWER_DOMAIN_VIDEO_SCALER	3
+#define RPI_POWER_DOMAIN_VPU1		4
+#define RPI_POWER_DOMAIN_HDMI		5
+#define RPI_POWER_DOMAIN_USB		6
+#define RPI_POWER_DOMAIN_VEC		7
+#define RPI_POWER_DOMAIN_JPEG		8
+#define RPI_POWER_DOMAIN_H264		9
+#define RPI_POWER_DOMAIN_V3D		10
+#define RPI_POWER_DOMAIN_ISP		11
+#define RPI_POWER_DOMAIN_UNICAM0	12
+#define RPI_POWER_DOMAIN_UNICAM1	13
+#define RPI_POWER_DOMAIN_CCP2RX		14
+#define RPI_POWER_DOMAIN_CSI2		15
+#define RPI_POWER_DOMAIN_CPI		16
+#define RPI_POWER_DOMAIN_DSI0		17
+#define RPI_POWER_DOMAIN_DSI1		18
+#define RPI_POWER_DOMAIN_TRANSPOSER	19
+#define RPI_POWER_DOMAIN_CCP2TX		20
+#define RPI_POWER_DOMAIN_CDP		21
+#define RPI_POWER_DOMAIN_ARM		22
+
+#define RPI_POWER_DOMAIN_COUNT		23
+
+#endif /* _DT_BINDINGS_ARM_BCM2835_RPI_POWER_H */
-- 
2.6.2

[PATCH v3 2/4] ARM: bcm2835: add rpi power domain driver

[Eric Anholt]

From: Alexander Aring <alex.aring@gmail.com>

This patch adds support for several power domains on Raspberry Pi,
including USB (so it can be enabled even if the bootloader didn't do
it), and graphics.

This patch is the combined work of Eric Anholt (who wrote USB support
inside of the Raspberry Pi firmware driver, and wrote the non-USB
domain support) and Alexander Aring (who separated the original USB
work out from the firmware driver).

Signed-off-by: Alexander Aring <alex.aring@gmail.com>
Signed-off-by: Eric Anholt <eric@anholt.net>
---

v2: Add support for power domains other than USB, using the new
    firmware interface, reword commit message (changes by Eric)

v3: Restructure as a builtin driver, and drop
    of_genpd_add_provider_onecell error handling to avoid
    pm_genpd_exit() dependency until that API can be settled.  Clean
    up copyright header, add missing ISP initialization, and fix typo
    in transposer's name.

 arch/arm/mach-bcm/Kconfig                   |  10 ++
 arch/arm/mach-bcm/Makefile                  |   1 +
 arch/arm/mach-bcm/raspberrypi-power.c       | 247 ++++++++++++++++++++++++++++
 include/dt-bindings/arm/raspberrypi-power.h |  41 +++++
 4 files changed, 299 insertions(+)
 create mode 100644 arch/arm/mach-bcm/raspberrypi-power.c
 create mode 100644 include/dt-bindings/arm/raspberrypi-power.h

diff --git a/arch/arm/mach-bcm/Kconfig b/arch/arm/mach-bcm/Kconfig
index 8c53c55..0f23bad 100644
--- a/arch/arm/mach-bcm/Kconfig
+++ b/arch/arm/mach-bcm/Kconfig
@@ -134,6 +134,16 @@ config ARCH_BCM2835
 	  This enables support for the Broadcom BCM2835 SoC. This SoC is
 	  used in the Raspberry Pi and Roku 2 devices.
 
+config RASPBERRYPI_POWER
+	bool "Raspberry Pi power domain driver"
+	depends on ARCH_BCM2835 || COMPILE_TEST
+	depends on RASPBERRYPI_FIRMWARE
+	select PM_GENERIC_DOMAINS if PM
+	select PM_GENERIC_DOMAINS_OF if PM
+	help
+	  This enables support for the RPi power domains which can be enabled
+	  or disabled via the RPi firmware.
+
 config ARCH_BCM_63XX
 	bool "Broadcom BCM63xx DSL SoC" if ARCH_MULTI_V7
 	depends on MMU
diff --git a/arch/arm/mach-bcm/Makefile b/arch/arm/mach-bcm/Makefile
index 892261f..fec2d6b 100644
--- a/arch/arm/mach-bcm/Makefile
+++ b/arch/arm/mach-bcm/Makefile
@@ -36,6 +36,7 @@ endif
 
 # BCM2835
 obj-$(CONFIG_ARCH_BCM2835)	+= board_bcm2835.o
+obj-$(CONFIG_RASPBERRYPI_POWER)	+= raspberrypi-power.o
 
 # BCM5301X
 obj-$(CONFIG_ARCH_BCM_5301X)	+= bcm_5301x.o
diff --git a/arch/arm/mach-bcm/raspberrypi-power.c b/arch/arm/mach-bcm/raspberrypi-power.c
new file mode 100644
index 0000000..9dc8b43
--- /dev/null
+++ b/arch/arm/mach-bcm/raspberrypi-power.c
@@ -0,0 +1,247 @@
+/* (C) 2015 Pengutronix, Alexander Aring <aar@pengutronix.de>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * Authors:
+ * Alexander Aring <aar@pengutronix.de>
+ * Eric Anholt <eric@anholt.net>
+ */
+
+#include <linux/module.h>
+#include <linux/of_platform.h>
+#include <linux/platform_device.h>
+#include <linux/pm_domain.h>
+#include <dt-bindings/arm/raspberrypi-power.h>
+#include <soc/bcm2835/raspberrypi-firmware.h>
+
+/*
+ * Firmware indices for the old power domains interface.  Only a few
+ * of them were actually implemented.
+ */
+#define RPI_OLD_POWER_DOMAIN_USB		3
+#define RPI_OLD_POWER_DOMAIN_V3D		10
+
+struct rpi_power_domain {
+	u32 domain;
+	bool enabled;
+	bool old_interface;
+	struct generic_pm_domain base;
+	struct rpi_firmware *fw;
+};
+
+struct rpi_power_domains {
+	bool has_new_interface;
+	struct genpd_onecell_data xlate;
+	struct rpi_firmware *fw;
+	struct rpi_power_domain domains[RPI_POWER_DOMAIN_COUNT];
+};
+
+/*
+ * Packet definition used by RPI_FIRMWARE_SET_POWER_STATE and
+ * RPI_FIRMWARE_SET_DOMAIN_STATE
+ */
+struct rpi_power_domain_packet {
+	u32 domain;
+	u32 on;
+} __packet;
+
+/*
+ * Asks the firmware to enable or disable power on a specific power
+ * domain.
+ */
+static int rpi_firmware_set_power(struct rpi_power_domain *rpi_domain, bool on)
+{
+	struct rpi_power_domain_packet packet;
+
+	packet.domain = rpi_domain->domain;
+	packet.on = on;
+	return rpi_firmware_property(rpi_domain->fw,
+				     rpi_domain->old_interface ?
+				     RPI_FIRMWARE_SET_POWER_STATE :
+				     RPI_FIRMWARE_SET_DOMAIN_STATE,
+				     &packet, sizeof(packet));
+}
+
+static int rpi_domain_off(struct generic_pm_domain *domain)
+{
+	struct rpi_power_domain *rpi_domain =
+		container_of(domain, struct rpi_power_domain, base);
+
+	return rpi_firmware_set_power(rpi_domain, false);
+}
+
+static int rpi_domain_on(struct generic_pm_domain *domain)
+{
+	struct rpi_power_domain *rpi_domain =
+		container_of(domain, struct rpi_power_domain, base);
+
+	return rpi_firmware_set_power(rpi_domain, true);
+}
+
+static void rpi_common_init_power_domain(struct rpi_power_domains *rpi_domains,
+					 int xlate_index, const char *name)
+{
+	struct rpi_power_domain *dom = &rpi_domains->domains[xlate_index];
+
+	dom->fw = rpi_domains->fw;
+
+	dom->base.name = name;
+	dom->base.power_on = rpi_domain_on;
+	dom->base.power_off = rpi_domain_off;
+
+	/*
+	 * Treat all power domains as off at boot.
+	 *
+	 * The firmware itself may be keeping some domains on, but
+	 * from Linux's perspective all we control is the refcounts
+	 * that we give to the firmware, and we can't ask the firmware
+	 * to turn off something that we haven't ourselves turned on.
+	 */
+	pm_genpd_init(&dom->base, NULL, true);
+
+	rpi_domains->xlate.domains[xlate_index] = &dom->base;
+}
+
+static void rpi_init_power_domain(struct rpi_power_domains *rpi_domains,
+				  int xlate_index, const char *name)
+{
+	struct rpi_power_domain *dom = &rpi_domains->domains[xlate_index];
+
+	if (!rpi_domains->has_new_interface)
+		return;
+
+	/* The DT binding index is the firmware's domain index minus one. */
+	dom->domain = xlate_index + 1;
+
+	rpi_common_init_power_domain(rpi_domains, xlate_index, name);
+}
+
+static void rpi_init_old_power_domain(struct rpi_power_domains *rpi_domains,
+				      int xlate_index, int domain,
+				      const char *name)
+{
+	struct rpi_power_domain *dom = &rpi_domains->domains[xlate_index];
+
+	dom->old_interface = true;
+	dom->domain = domain;
+
+	rpi_common_init_power_domain(rpi_domains, xlate_index, name);
+}
+
+/*
+ * Detects whether the firmware supports the new power domains interface.
+ *
+ * The firmware doesn't actually return an error on an unknown tag,
+ * and just skips over it, so we do the detection by putting an
+ * unexpected value in the return field and checking if it was
+ * unchanged.
+ */
+static bool
+rpi_has_new_domain_support(struct rpi_power_domains *rpi_domains)
+{
+	struct rpi_power_domain_packet packet;
+	int ret;
+
+	packet.domain = RPI_POWER_DOMAIN_ARM;
+	packet.on = ~0;
+
+	ret = rpi_firmware_property(rpi_domains->fw,
+				    RPI_FIRMWARE_GET_DOMAIN_STATE,
+				    &packet, sizeof(packet));
+
+	return ret == 0 && packet.on != ~0;
+}
+
+static int rpi_power_probe(struct platform_device *pdev)
+{
+	struct device_node *fw_np;
+	struct device *dev = &pdev->dev;
+	struct rpi_power_domains *rpi_domains;
+
+	rpi_domains = devm_kzalloc(dev, sizeof(*rpi_domains), GFP_KERNEL);
+	if (!rpi_domains)
+		return -ENOMEM;
+
+	rpi_domains->xlate.domains =
+		devm_kzalloc(dev, sizeof(*rpi_domains->xlate.domains) *
+			     RPI_POWER_DOMAIN_COUNT, GFP_KERNEL);
+	if (!rpi_domains->xlate.domains)
+		return -ENOMEM;
+
+	rpi_domains->xlate.num_domains = RPI_POWER_DOMAIN_COUNT;
+
+	fw_np = of_parse_phandle(pdev->dev.of_node, "firmware", 0);
+	if (!fw_np) {
+		dev_err(&pdev->dev, "no firmware node\n");
+		return -ENODEV;
+	}
+
+	rpi_domains->fw = rpi_firmware_get(fw_np);
+	of_node_put(fw_np);
+	if (!rpi_domains->fw)
+		return -EPROBE_DEFER;
+
+	rpi_domains->has_new_interface =
+		rpi_has_new_domain_support(rpi_domains);
+
+	rpi_init_power_domain(rpi_domains, RPI_POWER_DOMAIN_I2C0, "I2C0");
+	rpi_init_power_domain(rpi_domains, RPI_POWER_DOMAIN_I2C1, "I2C1");
+	rpi_init_power_domain(rpi_domains, RPI_POWER_DOMAIN_I2C2, "I2C2");
+	rpi_init_power_domain(rpi_domains, RPI_POWER_DOMAIN_VIDEO_SCALER,
+			      "VIDEO_SCALER");
+	rpi_init_power_domain(rpi_domains, RPI_POWER_DOMAIN_VPU1, "VPU1");
+	rpi_init_power_domain(rpi_domains, RPI_POWER_DOMAIN_HDMI, "HDMI");
+
+	/*
+	 * Use the old firmware interface for USB power, so that we
+	 * can turn it on even if the firmware hasn't been updated.
+	 */
+	rpi_init_old_power_domain(rpi_domains, RPI_POWER_DOMAIN_USB,
+				  RPI_OLD_POWER_DOMAIN_USB, "USB");
+
+	rpi_init_power_domain(rpi_domains, RPI_POWER_DOMAIN_VEC, "VEC");
+	rpi_init_power_domain(rpi_domains, RPI_POWER_DOMAIN_JPEG, "JPEG");
+	rpi_init_power_domain(rpi_domains, RPI_POWER_DOMAIN_H264, "H264");
+	rpi_init_power_domain(rpi_domains, RPI_POWER_DOMAIN_V3D, "V3D");
+	rpi_init_power_domain(rpi_domains, RPI_POWER_DOMAIN_ISP, "ISP");
+	rpi_init_power_domain(rpi_domains, RPI_POWER_DOMAIN_UNICAM0, "UNICAM0");
+	rpi_init_power_domain(rpi_domains, RPI_POWER_DOMAIN_UNICAM1, "UNICAM1");
+	rpi_init_power_domain(rpi_domains, RPI_POWER_DOMAIN_CCP2RX, "CCP2RX");
+	rpi_init_power_domain(rpi_domains, RPI_POWER_DOMAIN_CSI2, "CSI2");
+	rpi_init_power_domain(rpi_domains, RPI_POWER_DOMAIN_CPI, "CPI");
+	rpi_init_power_domain(rpi_domains, RPI_POWER_DOMAIN_DSI0, "DSI0");
+	rpi_init_power_domain(rpi_domains, RPI_POWER_DOMAIN_DSI1, "DSI1");
+	rpi_init_power_domain(rpi_domains, RPI_POWER_DOMAIN_TRANSPOSER,
+			      "TRANSPOSER");
+	rpi_init_power_domain(rpi_domains, RPI_POWER_DOMAIN_CCP2TX, "CCP2TX");
+	rpi_init_power_domain(rpi_domains, RPI_POWER_DOMAIN_CDP, "CDP");
+	rpi_init_power_domain(rpi_domains, RPI_POWER_DOMAIN_ARM, "ARM");
+
+	of_genpd_add_provider_onecell(dev->of_node, &rpi_domains->xlate);
+
+	platform_set_drvdata(pdev, rpi_domains);
+
+	return 0;
+}
+
+static const struct of_device_id rpi_power_of_match[] = {
+	{ .compatible = "raspberrypi,bcm2835-power", },
+	{},
+};
+MODULE_DEVICE_TABLE(of, rpi_power_of_match);
+
+static struct platform_driver rpi_power_driver = {
+	.driver = {
+		.name = "raspberrypi-power",
+		.of_match_table = rpi_power_of_match,
+	},
+	.probe		= rpi_power_probe,
+};
+builtin_platform_driver(rpi_power_driver);
+
+MODULE_AUTHOR("Alexander Aring <aar@pengutronix.de>");
+MODULE_AUTHOR("Eric Anholt <eric@anholt.net>");
+MODULE_DESCRIPTION("Raspberry Pi power domain driver");
+MODULE_LICENSE("GPL v2");
diff --git a/include/dt-bindings/arm/raspberrypi-power.h b/include/dt-bindings/arm/raspberrypi-power.h
new file mode 100644
index 0000000..b3ff8e0
--- /dev/null
+++ b/include/dt-bindings/arm/raspberrypi-power.h
@@ -0,0 +1,41 @@
+/*
+ *  Copyright ? 2015 Broadcom
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#ifndef _DT_BINDINGS_ARM_BCM2835_RPI_POWER_H
+#define _DT_BINDINGS_ARM_BCM2835_RPI_POWER_H
+
+/* These power domain indices are the firmware interface's indices
+ * minus one.
+ */
+#define RPI_POWER_DOMAIN_I2C0		0
+#define RPI_POWER_DOMAIN_I2C1		1
+#define RPI_POWER_DOMAIN_I2C2		2
+#define RPI_POWER_DOMAIN_VIDEO_SCALER	3
+#define RPI_POWER_DOMAIN_VPU1		4
+#define RPI_POWER_DOMAIN_HDMI		5
+#define RPI_POWER_DOMAIN_USB		6
+#define RPI_POWER_DOMAIN_VEC		7
+#define RPI_POWER_DOMAIN_JPEG		8
+#define RPI_POWER_DOMAIN_H264		9
+#define RPI_POWER_DOMAIN_V3D		10
+#define RPI_POWER_DOMAIN_ISP		11
+#define RPI_POWER_DOMAIN_UNICAM0	12
+#define RPI_POWER_DOMAIN_UNICAM1	13
+#define RPI_POWER_DOMAIN_CCP2RX		14
+#define RPI_POWER_DOMAIN_CSI2		15
+#define RPI_POWER_DOMAIN_CPI		16
+#define RPI_POWER_DOMAIN_DSI0		17
+#define RPI_POWER_DOMAIN_DSI1		18
+#define RPI_POWER_DOMAIN_TRANSPOSER	19
+#define RPI_POWER_DOMAIN_CCP2TX		20
+#define RPI_POWER_DOMAIN_CDP		21
+#define RPI_POWER_DOMAIN_ARM		22
+
+#define RPI_POWER_DOMAIN_COUNT		23
+
+#endif /* _DT_BINDINGS_ARM_BCM2835_RPI_POWER_H */
-- 
2.6.2

[PATCH v3 3/4] dt-bindings: add rpi power domain driver bindings

[Eric Anholt]

From: Alexander Aring <alex.aring@gmail.com>

This patch adds devicetree tree bindings for the Raspberry Pi power
domain driver.

Signed-off-by: Alexander Aring <alex.aring@gmail.com>
Acked-by: Rob Herring <robh@kernel.org>
Signed-off-by: Eric Anholt <eric@anholt.net>
---

v2: Add the new domains present in v2 to the list.

 .../bindings/arm/bcm/raspberrypi,bcm2835-power.txt | 47 ++++++++++++++++++++++
 1 file changed, 47 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/arm/bcm/raspberrypi,bcm2835-power.txt

diff --git a/Documentation/devicetree/bindings/arm/bcm/raspberrypi,bcm2835-power.txt b/Documentation/devicetree/bindings/arm/bcm/raspberrypi,bcm2835-power.txt
new file mode 100644
index 0000000..30942cf
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/bcm/raspberrypi,bcm2835-power.txt
@@ -0,0 +1,47 @@
+Raspberry Pi power domain driver
+
+Required properties:
+
+- compatible:		Should be "raspberrypi,bcm2835-power".
+- firmware:		Reference to the RPi firmware device node.
+- #power-domain-cells:	Should be <1>, we providing multiple power domains.
+
+The valid defines for power domain are:
+
+ RPI_POWER_DOMAIN_I2C0
+ RPI_POWER_DOMAIN_I2C1
+ RPI_POWER_DOMAIN_I2C2
+ RPI_POWER_DOMAIN_VIDEO_SCALER
+ RPI_POWER_DOMAIN_VPU1
+ RPI_POWER_DOMAIN_HDMI
+ RPI_POWER_DOMAIN_USB
+ RPI_POWER_DOMAIN_VEC
+ RPI_POWER_DOMAIN_JPEG
+ RPI_POWER_DOMAIN_H264
+ RPI_POWER_DOMAIN_V3D
+ RPI_POWER_DOMAIN_ISP
+ RPI_POWER_DOMAIN_UNICAM0
+ RPI_POWER_DOMAIN_UNICAM1
+ RPI_POWER_DOMAIN_CCP2RX
+ RPI_POWER_DOMAIN_CSI2
+ RPI_POWER_DOMAIN_CPI
+ RPI_POWER_DOMAIN_DSI0
+ RPI_POWER_DOMAIN_DSI1
+ RPI_POWER_DOMAIN_TRANSPOSER
+ RPI_POWER_DOMAIN_CCP2TX
+ RPI_POWER_DOMAIN_CDP
+ RPI_POWER_DOMAIN_ARM
+
+Example:
+
+power: power {
+	compatible = "raspberrypi,bcm2835-power";
+	firmware = <&firmware>;
+	#power-domain-cells = <1>;
+};
+
+Example for using power domain:
+
+&usb {
+       power-domains = <&power RPI_POWER_DOMAIN_USB>;
+};
-- 
2.6.2

[PATCH v3 3/4] dt-bindings: add rpi power domain driver bindings

[Eric Anholt]

From: Alexander Aring <alex.aring-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>

This patch adds devicetree tree bindings for the Raspberry Pi power
domain driver.

Signed-off-by: Alexander Aring <alex.aring-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
Signed-off-by: Eric Anholt <eric-WhKQ6XTQaPysTnJN9+BGXg@public.gmane.org>
---

v2: Add the new domains present in v2 to the list.

 .../bindings/arm/bcm/raspberrypi,bcm2835-power.txt | 47 ++++++++++++++++++++++
 1 file changed, 47 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/arm/bcm/raspberrypi,bcm2835-power.txt

diff --git a/Documentation/devicetree/bindings/arm/bcm/raspberrypi,bcm2835-power.txt b/Documentation/devicetree/bindings/arm/bcm/raspberrypi,bcm2835-power.txt
new file mode 100644
index 0000000..30942cf
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/bcm/raspberrypi,bcm2835-power.txt
@@ -0,0 +1,47 @@
+Raspberry Pi power domain driver
+
+Required properties:
+
+- compatible:		Should be "raspberrypi,bcm2835-power".
+- firmware:		Reference to the RPi firmware device node.
+- #power-domain-cells:	Should be <1>, we providing multiple power domains.
+
+The valid defines for power domain are:
+
+ RPI_POWER_DOMAIN_I2C0
+ RPI_POWER_DOMAIN_I2C1
+ RPI_POWER_DOMAIN_I2C2
+ RPI_POWER_DOMAIN_VIDEO_SCALER
+ RPI_POWER_DOMAIN_VPU1
+ RPI_POWER_DOMAIN_HDMI
+ RPI_POWER_DOMAIN_USB
+ RPI_POWER_DOMAIN_VEC
+ RPI_POWER_DOMAIN_JPEG
+ RPI_POWER_DOMAIN_H264
+ RPI_POWER_DOMAIN_V3D
+ RPI_POWER_DOMAIN_ISP
+ RPI_POWER_DOMAIN_UNICAM0
+ RPI_POWER_DOMAIN_UNICAM1
+ RPI_POWER_DOMAIN_CCP2RX
+ RPI_POWER_DOMAIN_CSI2
+ RPI_POWER_DOMAIN_CPI
+ RPI_POWER_DOMAIN_DSI0
+ RPI_POWER_DOMAIN_DSI1
+ RPI_POWER_DOMAIN_TRANSPOSER
+ RPI_POWER_DOMAIN_CCP2TX
+ RPI_POWER_DOMAIN_CDP
+ RPI_POWER_DOMAIN_ARM
+
+Example:
+
+power: power {
+	compatible = "raspberrypi,bcm2835-power";
+	firmware = <&firmware>;
+	#power-domain-cells = <1>;
+};
+
+Example for using power domain:
+
+&usb {
+       power-domains = <&power RPI_POWER_DOMAIN_USB>;
+};
-- 
2.6.2

--
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

[PATCH v3 3/4] dt-bindings: add rpi power domain driver bindings

[Eric Anholt]

From: Alexander Aring <alex.aring@gmail.com>

This patch adds devicetree tree bindings for the Raspberry Pi power
domain driver.

Signed-off-by: Alexander Aring <alex.aring@gmail.com>
Acked-by: Rob Herring <robh@kernel.org>
Signed-off-by: Eric Anholt <eric@anholt.net>
---

v2: Add the new domains present in v2 to the list.

 .../bindings/arm/bcm/raspberrypi,bcm2835-power.txt | 47 ++++++++++++++++++++++
 1 file changed, 47 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/arm/bcm/raspberrypi,bcm2835-power.txt

diff --git a/Documentation/devicetree/bindings/arm/bcm/raspberrypi,bcm2835-power.txt b/Documentation/devicetree/bindings/arm/bcm/raspberrypi,bcm2835-power.txt
new file mode 100644
index 0000000..30942cf
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/bcm/raspberrypi,bcm2835-power.txt
@@ -0,0 +1,47 @@
+Raspberry Pi power domain driver
+
+Required properties:
+
+- compatible:		Should be "raspberrypi,bcm2835-power".
+- firmware:		Reference to the RPi firmware device node.
+- #power-domain-cells:	Should be <1>, we providing multiple power domains.
+
+The valid defines for power domain are:
+
+ RPI_POWER_DOMAIN_I2C0
+ RPI_POWER_DOMAIN_I2C1
+ RPI_POWER_DOMAIN_I2C2
+ RPI_POWER_DOMAIN_VIDEO_SCALER
+ RPI_POWER_DOMAIN_VPU1
+ RPI_POWER_DOMAIN_HDMI
+ RPI_POWER_DOMAIN_USB
+ RPI_POWER_DOMAIN_VEC
+ RPI_POWER_DOMAIN_JPEG
+ RPI_POWER_DOMAIN_H264
+ RPI_POWER_DOMAIN_V3D
+ RPI_POWER_DOMAIN_ISP
+ RPI_POWER_DOMAIN_UNICAM0
+ RPI_POWER_DOMAIN_UNICAM1
+ RPI_POWER_DOMAIN_CCP2RX
+ RPI_POWER_DOMAIN_CSI2
+ RPI_POWER_DOMAIN_CPI
+ RPI_POWER_DOMAIN_DSI0
+ RPI_POWER_DOMAIN_DSI1
+ RPI_POWER_DOMAIN_TRANSPOSER
+ RPI_POWER_DOMAIN_CCP2TX
+ RPI_POWER_DOMAIN_CDP
+ RPI_POWER_DOMAIN_ARM
+
+Example:
+
+power: power {
+	compatible = "raspberrypi,bcm2835-power";
+	firmware = <&firmware>;
+	#power-domain-cells = <1>;
+};
+
+Example for using power domain:
+
+&usb {
+       power-domains = <&power RPI_POWER_DOMAIN_USB>;
+};
-- 
2.6.2

[PATCH v3 4/4] ARM: bcm2835: Add the Raspberry Pi power domain driver to the DT.

[Eric Anholt]

From: Alexander Aring <alex.aring@gmail.com>

This connects the USB driver to the USB power domain, so that USB can
actually be turned on at boot if the bootloader didn't do it for us.

Signed-off-by: Alexander Aring <alex.aring@gmail.com>
Signed-off-by: Eric Anholt <eric@anholt.net>
---
 arch/arm/boot/dts/bcm2835-rpi.dtsi | 11 +++++++++++
 arch/arm/boot/dts/bcm2835.dtsi     |  2 +-
 2 files changed, 12 insertions(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/bcm2835-rpi.dtsi b/arch/arm/boot/dts/bcm2835-rpi.dtsi
index 3572f03..f828202 100644
--- a/arch/arm/boot/dts/bcm2835-rpi.dtsi
+++ b/arch/arm/boot/dts/bcm2835-rpi.dtsi
@@ -1,3 +1,4 @@
+#include <dt-bindings/arm/raspberrypi-power.h>
 #include "bcm2835.dtsi"
 
 / {
@@ -20,6 +21,12 @@
 			compatible = "raspberrypi,bcm2835-firmware";
 			mboxes = <&mailbox>;
 		};
+
+		power: power {
+			compatible = "raspberrypi,bcm2835-power";
+			firmware = <&firmware>;
+			#power-domain-cells = <1>;
+		};
 	};
 };
 
@@ -60,3 +67,7 @@
 	status = "okay";
 	bus-width = <4>;
 };
+
+&usb {
+	power-domains = <&power RPI_POWER_DOMAIN_USB>;
+};
diff --git a/arch/arm/boot/dts/bcm2835.dtsi b/arch/arm/boot/dts/bcm2835.dtsi
index aef64de..6d62af0 100644
--- a/arch/arm/boot/dts/bcm2835.dtsi
+++ b/arch/arm/boot/dts/bcm2835.dtsi
@@ -177,7 +177,7 @@
 			status = "disabled";
 		};
 
-		usb@7e980000 {
+		usb: usb@7e980000 {
 			compatible = "brcm,bcm2835-usb";
 			reg = <0x7e980000 0x10000>;
 			interrupts = <1 9>;
-- 
2.6.2

[PATCH v3 4/4] ARM: bcm2835: Add the Raspberry Pi power domain driver to the DT.

[Eric Anholt]

From: Alexander Aring <alex.aring@gmail.com>

This connects the USB driver to the USB power domain, so that USB can
actually be turned on at boot if the bootloader didn't do it for us.

Signed-off-by: Alexander Aring <alex.aring@gmail.com>
Signed-off-by: Eric Anholt <eric@anholt.net>
---
 arch/arm/boot/dts/bcm2835-rpi.dtsi | 11 +++++++++++
 arch/arm/boot/dts/bcm2835.dtsi     |  2 +-
 2 files changed, 12 insertions(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/bcm2835-rpi.dtsi b/arch/arm/boot/dts/bcm2835-rpi.dtsi
index 3572f03..f828202 100644
--- a/arch/arm/boot/dts/bcm2835-rpi.dtsi
+++ b/arch/arm/boot/dts/bcm2835-rpi.dtsi
@@ -1,3 +1,4 @@
+#include <dt-bindings/arm/raspberrypi-power.h>
 #include "bcm2835.dtsi"
 
 / {
@@ -20,6 +21,12 @@
 			compatible = "raspberrypi,bcm2835-firmware";
 			mboxes = <&mailbox>;
 		};
+
+		power: power {
+			compatible = "raspberrypi,bcm2835-power";
+			firmware = <&firmware>;
+			#power-domain-cells = <1>;
+		};
 	};
 };
 
@@ -60,3 +67,7 @@
 	status = "okay";
 	bus-width = <4>;
 };
+
+&usb {
+	power-domains = <&power RPI_POWER_DOMAIN_USB>;
+};
diff --git a/arch/arm/boot/dts/bcm2835.dtsi b/arch/arm/boot/dts/bcm2835.dtsi
index aef64de..6d62af0 100644
--- a/arch/arm/boot/dts/bcm2835.dtsi
+++ b/arch/arm/boot/dts/bcm2835.dtsi
@@ -177,7 +177,7 @@
 			status = "disabled";
 		};
 
-		usb at 7e980000 {
+		usb: usb at 7e980000 {
 			compatible = "brcm,bcm2835-usb";
 			reg = <0x7e980000 0x10000>;
 			interrupts = <1 9>;
-- 
2.6.2

Re: [PATCH v3 2/4] ARM: bcm2835: add rpi power domain driver

[Florian Fainelli]

On 15/12/15 13:40, Eric Anholt wrote:
> From: Alexander Aring <alex.aring@gmail.com>
> 
> This patch adds support for several power domains on Raspberry Pi,
> including USB (so it can be enabled even if the bootloader didn't do
> it), and graphics.
> 
> This patch is the combined work of Eric Anholt (who wrote USB support
> inside of the Raspberry Pi firmware driver, and wrote the non-USB
> domain support) and Alexander Aring (who separated the original USB
> work out from the firmware driver).
> 
> Signed-off-by: Alexander Aring <alex.aring@gmail.com>
> Signed-off-by: Eric Anholt <eric@anholt.net>
> ---
> 
> v2: Add support for power domains other than USB, using the new
>     firmware interface, reword commit message (changes by Eric)
> 
> v3: Restructure as a builtin driver, and drop
>     of_genpd_add_provider_onecell error handling to avoid
>     pm_genpd_exit() dependency until that API can be settled.  Clean
>     up copyright header, add missing ISP initialization, and fix typo
>     in transposer's name.
> 
>  arch/arm/mach-bcm/Kconfig                   |  10 ++
>  arch/arm/mach-bcm/Makefile                  |   1 +
>  arch/arm/mach-bcm/raspberrypi-power.c       | 247 ++++++++++++++++++++++++++++
>  include/dt-bindings/arm/raspberrypi-power.h |  41 +++++
>  4 files changed, 299 insertions(+)
>  create mode 100644 arch/arm/mach-bcm/raspberrypi-power.c

What motivated the location of this power domain driver in
arch/arm/mach-bcm? Should not we have this in drivers/power/ or
somewhere in drivers/ at the very least?
-- 
Florian

[PATCH v3 2/4] ARM: bcm2835: add rpi power domain driver

[Florian Fainelli]

On 15/12/15 13:40, Eric Anholt wrote:
> From: Alexander Aring <alex.aring@gmail.com>
> 
> This patch adds support for several power domains on Raspberry Pi,
> including USB (so it can be enabled even if the bootloader didn't do
> it), and graphics.
> 
> This patch is the combined work of Eric Anholt (who wrote USB support
> inside of the Raspberry Pi firmware driver, and wrote the non-USB
> domain support) and Alexander Aring (who separated the original USB
> work out from the firmware driver).
> 
> Signed-off-by: Alexander Aring <alex.aring@gmail.com>
> Signed-off-by: Eric Anholt <eric@anholt.net>
> ---
> 
> v2: Add support for power domains other than USB, using the new
>     firmware interface, reword commit message (changes by Eric)
> 
> v3: Restructure as a builtin driver, and drop
>     of_genpd_add_provider_onecell error handling to avoid
>     pm_genpd_exit() dependency until that API can be settled.  Clean
>     up copyright header, add missing ISP initialization, and fix typo
>     in transposer's name.
> 
>  arch/arm/mach-bcm/Kconfig                   |  10 ++
>  arch/arm/mach-bcm/Makefile                  |   1 +
>  arch/arm/mach-bcm/raspberrypi-power.c       | 247 ++++++++++++++++++++++++++++
>  include/dt-bindings/arm/raspberrypi-power.h |  41 +++++
>  4 files changed, 299 insertions(+)
>  create mode 100644 arch/arm/mach-bcm/raspberrypi-power.c

What motivated the location of this power domain driver in
arch/arm/mach-bcm? Should not we have this in drivers/power/ or
somewhere in drivers/ at the very least?
-- 
Florian

Re: [PATCH v3 2/4] ARM: bcm2835: add rpi power domain driver

[Eric Anholt]

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

Florian Fainelli <f.fainelli@gmail.com> writes:

> On 15/12/15 13:40, Eric Anholt wrote:
>> From: Alexander Aring <alex.aring@gmail.com>
>> 
>> This patch adds support for several power domains on Raspberry Pi,
>> including USB (so it can be enabled even if the bootloader didn't do
>> it), and graphics.
>> 
>> This patch is the combined work of Eric Anholt (who wrote USB support
>> inside of the Raspberry Pi firmware driver, and wrote the non-USB
>> domain support) and Alexander Aring (who separated the original USB
>> work out from the firmware driver).
>> 
>> Signed-off-by: Alexander Aring <alex.aring@gmail.com>
>> Signed-off-by: Eric Anholt <eric@anholt.net>
>> ---
>> 
>> v2: Add support for power domains other than USB, using the new
>>     firmware interface, reword commit message (changes by Eric)
>> 
>> v3: Restructure as a builtin driver, and drop
>>     of_genpd_add_provider_onecell error handling to avoid
>>     pm_genpd_exit() dependency until that API can be settled.  Clean
>>     up copyright header, add missing ISP initialization, and fix typo
>>     in transposer's name.
>> 
>>  arch/arm/mach-bcm/Kconfig                   |  10 ++
>>  arch/arm/mach-bcm/Makefile                  |   1 +
>>  arch/arm/mach-bcm/raspberrypi-power.c       | 247 ++++++++++++++++++++++++++++
>>  include/dt-bindings/arm/raspberrypi-power.h |  41 +++++
>>  4 files changed, 299 insertions(+)
>>  create mode 100644 arch/arm/mach-bcm/raspberrypi-power.c
>
> What motivated the location of this power domain driver in
> arch/arm/mach-bcm? Should not we have this in drivers/power/ or
> somewhere in drivers/ at the very least?

ls stronly suggests that power contains drivers for power supplies and
batteries, not power domains.  There are 6 power domain drivers in
arch/arm, 3 in drivers/clk, and 3 in drivers/soc.

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

Re: [PATCH v3 2/4] ARM: bcm2835: add rpi power domain driver

[Eric Anholt]

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

Florian Fainelli <f.fainelli-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> writes:

> On 15/12/15 13:40, Eric Anholt wrote:
>> From: Alexander Aring <alex.aring-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
>> 
>> This patch adds support for several power domains on Raspberry Pi,
>> including USB (so it can be enabled even if the bootloader didn't do
>> it), and graphics.
>> 
>> This patch is the combined work of Eric Anholt (who wrote USB support
>> inside of the Raspberry Pi firmware driver, and wrote the non-USB
>> domain support) and Alexander Aring (who separated the original USB
>> work out from the firmware driver).
>> 
>> Signed-off-by: Alexander Aring <alex.aring-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
>> Signed-off-by: Eric Anholt <eric-WhKQ6XTQaPysTnJN9+BGXg@public.gmane.org>
>> ---
>> 
>> v2: Add support for power domains other than USB, using the new
>>     firmware interface, reword commit message (changes by Eric)
>> 
>> v3: Restructure as a builtin driver, and drop
>>     of_genpd_add_provider_onecell error handling to avoid
>>     pm_genpd_exit() dependency until that API can be settled.  Clean
>>     up copyright header, add missing ISP initialization, and fix typo
>>     in transposer's name.
>> 
>>  arch/arm/mach-bcm/Kconfig                   |  10 ++
>>  arch/arm/mach-bcm/Makefile                  |   1 +
>>  arch/arm/mach-bcm/raspberrypi-power.c       | 247 ++++++++++++++++++++++++++++
>>  include/dt-bindings/arm/raspberrypi-power.h |  41 +++++
>>  4 files changed, 299 insertions(+)
>>  create mode 100644 arch/arm/mach-bcm/raspberrypi-power.c
>
> What motivated the location of this power domain driver in
> arch/arm/mach-bcm? Should not we have this in drivers/power/ or
> somewhere in drivers/ at the very least?

ls stronly suggests that power contains drivers for power supplies and
batteries, not power domains.  There are 6 power domain drivers in
arch/arm, 3 in drivers/clk, and 3 in drivers/soc.

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

[PATCH v3 2/4] ARM: bcm2835: add rpi power domain driver

[Eric Anholt]

Florian Fainelli <f.fainelli@gmail.com> writes:

> On 15/12/15 13:40, Eric Anholt wrote:
>> From: Alexander Aring <alex.aring@gmail.com>
>> 
>> This patch adds support for several power domains on Raspberry Pi,
>> including USB (so it can be enabled even if the bootloader didn't do
>> it), and graphics.
>> 
>> This patch is the combined work of Eric Anholt (who wrote USB support
>> inside of the Raspberry Pi firmware driver, and wrote the non-USB
>> domain support) and Alexander Aring (who separated the original USB
>> work out from the firmware driver).
>> 
>> Signed-off-by: Alexander Aring <alex.aring@gmail.com>
>> Signed-off-by: Eric Anholt <eric@anholt.net>
>> ---
>> 
>> v2: Add support for power domains other than USB, using the new
>>     firmware interface, reword commit message (changes by Eric)
>> 
>> v3: Restructure as a builtin driver, and drop
>>     of_genpd_add_provider_onecell error handling to avoid
>>     pm_genpd_exit() dependency until that API can be settled.  Clean
>>     up copyright header, add missing ISP initialization, and fix typo
>>     in transposer's name.
>> 
>>  arch/arm/mach-bcm/Kconfig                   |  10 ++
>>  arch/arm/mach-bcm/Makefile                  |   1 +
>>  arch/arm/mach-bcm/raspberrypi-power.c       | 247 ++++++++++++++++++++++++++++
>>  include/dt-bindings/arm/raspberrypi-power.h |  41 +++++
>>  4 files changed, 299 insertions(+)
>>  create mode 100644 arch/arm/mach-bcm/raspberrypi-power.c
>
> What motivated the location of this power domain driver in
> arch/arm/mach-bcm? Should not we have this in drivers/power/ or
> somewhere in drivers/ at the very least?

ls stronly suggests that power contains drivers for power supplies and
batteries, not power domains.  There are 6 power domain drivers in
arch/arm, 3 in drivers/clk, and 3 in drivers/soc.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 818 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20151215/54ad096c/attachment.sig>

Re: [PATCH v3 2/4] ARM: bcm2835: add rpi power domain driver

[Florian Fainelli]

On 15/12/15 15:55, Eric Anholt wrote:
> Florian Fainelli <f.fainelli@gmail.com> writes:
> 
>> On 15/12/15 13:40, Eric Anholt wrote:
>>> From: Alexander Aring <alex.aring@gmail.com>
>>>
>>> This patch adds support for several power domains on Raspberry Pi,
>>> including USB (so it can be enabled even if the bootloader didn't do
>>> it), and graphics.
>>>
>>> This patch is the combined work of Eric Anholt (who wrote USB support
>>> inside of the Raspberry Pi firmware driver, and wrote the non-USB
>>> domain support) and Alexander Aring (who separated the original USB
>>> work out from the firmware driver).
>>>
>>> Signed-off-by: Alexander Aring <alex.aring@gmail.com>
>>> Signed-off-by: Eric Anholt <eric@anholt.net>
>>> ---
>>>
>>> v2: Add support for power domains other than USB, using the new
>>>     firmware interface, reword commit message (changes by Eric)
>>>
>>> v3: Restructure as a builtin driver, and drop
>>>     of_genpd_add_provider_onecell error handling to avoid
>>>     pm_genpd_exit() dependency until that API can be settled.  Clean
>>>     up copyright header, add missing ISP initialization, and fix typo
>>>     in transposer's name.
>>>
>>>  arch/arm/mach-bcm/Kconfig                   |  10 ++
>>>  arch/arm/mach-bcm/Makefile                  |   1 +
>>>  arch/arm/mach-bcm/raspberrypi-power.c       | 247 ++++++++++++++++++++++++++++
>>>  include/dt-bindings/arm/raspberrypi-power.h |  41 +++++
>>>  4 files changed, 299 insertions(+)
>>>  create mode 100644 arch/arm/mach-bcm/raspberrypi-power.c
>>
>> What motivated the location of this power domain driver in
>> arch/arm/mach-bcm? Should not we have this in drivers/power/ or
>> somewhere in drivers/ at the very least?
> 
> ls stronly suggests that power contains drivers for power supplies and
> batteries, not power domains.  There are 6 power domain drivers in
> arch/arm, 3 in drivers/clk, and 3 in drivers/soc.

If we ever have to support a different architecture which happens to use
a similar power domain, then we want it to be in a location which makes
it easy for sharing it in the first place. As it stands today, it does
not seem useful to me to have this code in arch/arm/mach-bcm/ at all.

Maybe there is room from a drivers/power/domains/ of some kind?
-- 
Florian

Re: [PATCH v3 2/4] ARM: bcm2835: add rpi power domain driver

[Florian Fainelli]

On 15/12/15 15:55, Eric Anholt wrote:
> Florian Fainelli <f.fainelli-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> writes:
> 
>> On 15/12/15 13:40, Eric Anholt wrote:
>>> From: Alexander Aring <alex.aring-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
>>>
>>> This patch adds support for several power domains on Raspberry Pi,
>>> including USB (so it can be enabled even if the bootloader didn't do
>>> it), and graphics.
>>>
>>> This patch is the combined work of Eric Anholt (who wrote USB support
>>> inside of the Raspberry Pi firmware driver, and wrote the non-USB
>>> domain support) and Alexander Aring (who separated the original USB
>>> work out from the firmware driver).
>>>
>>> Signed-off-by: Alexander Aring <alex.aring-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
>>> Signed-off-by: Eric Anholt <eric-WhKQ6XTQaPysTnJN9+BGXg@public.gmane.org>
>>> ---
>>>
>>> v2: Add support for power domains other than USB, using the new
>>>     firmware interface, reword commit message (changes by Eric)
>>>
>>> v3: Restructure as a builtin driver, and drop
>>>     of_genpd_add_provider_onecell error handling to avoid
>>>     pm_genpd_exit() dependency until that API can be settled.  Clean
>>>     up copyright header, add missing ISP initialization, and fix typo
>>>     in transposer's name.
>>>
>>>  arch/arm/mach-bcm/Kconfig                   |  10 ++
>>>  arch/arm/mach-bcm/Makefile                  |   1 +
>>>  arch/arm/mach-bcm/raspberrypi-power.c       | 247 ++++++++++++++++++++++++++++
>>>  include/dt-bindings/arm/raspberrypi-power.h |  41 +++++
>>>  4 files changed, 299 insertions(+)
>>>  create mode 100644 arch/arm/mach-bcm/raspberrypi-power.c
>>
>> What motivated the location of this power domain driver in
>> arch/arm/mach-bcm? Should not we have this in drivers/power/ or
>> somewhere in drivers/ at the very least?
> 
> ls stronly suggests that power contains drivers for power supplies and
> batteries, not power domains.  There are 6 power domain drivers in
> arch/arm, 3 in drivers/clk, and 3 in drivers/soc.

If we ever have to support a different architecture which happens to use
a similar power domain, then we want it to be in a location which makes
it easy for sharing it in the first place. As it stands today, it does
not seem useful to me to have this code in arch/arm/mach-bcm/ at all.

Maybe there is room from a drivers/power/domains/ of some kind?
-- 
Florian
--
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

[PATCH v3 2/4] ARM: bcm2835: add rpi power domain driver

[Florian Fainelli]

On 15/12/15 15:55, Eric Anholt wrote:
> Florian Fainelli <f.fainelli@gmail.com> writes:
> 
>> On 15/12/15 13:40, Eric Anholt wrote:
>>> From: Alexander Aring <alex.aring@gmail.com>
>>>
>>> This patch adds support for several power domains on Raspberry Pi,
>>> including USB (so it can be enabled even if the bootloader didn't do
>>> it), and graphics.
>>>
>>> This patch is the combined work of Eric Anholt (who wrote USB support
>>> inside of the Raspberry Pi firmware driver, and wrote the non-USB
>>> domain support) and Alexander Aring (who separated the original USB
>>> work out from the firmware driver).
>>>
>>> Signed-off-by: Alexander Aring <alex.aring@gmail.com>
>>> Signed-off-by: Eric Anholt <eric@anholt.net>
>>> ---
>>>
>>> v2: Add support for power domains other than USB, using the new
>>>     firmware interface, reword commit message (changes by Eric)
>>>
>>> v3: Restructure as a builtin driver, and drop
>>>     of_genpd_add_provider_onecell error handling to avoid
>>>     pm_genpd_exit() dependency until that API can be settled.  Clean
>>>     up copyright header, add missing ISP initialization, and fix typo
>>>     in transposer's name.
>>>
>>>  arch/arm/mach-bcm/Kconfig                   |  10 ++
>>>  arch/arm/mach-bcm/Makefile                  |   1 +
>>>  arch/arm/mach-bcm/raspberrypi-power.c       | 247 ++++++++++++++++++++++++++++
>>>  include/dt-bindings/arm/raspberrypi-power.h |  41 +++++
>>>  4 files changed, 299 insertions(+)
>>>  create mode 100644 arch/arm/mach-bcm/raspberrypi-power.c
>>
>> What motivated the location of this power domain driver in
>> arch/arm/mach-bcm? Should not we have this in drivers/power/ or
>> somewhere in drivers/ at the very least?
> 
> ls stronly suggests that power contains drivers for power supplies and
> batteries, not power domains.  There are 6 power domain drivers in
> arch/arm, 3 in drivers/clk, and 3 in drivers/soc.

If we ever have to support a different architecture which happens to use
a similar power domain, then we want it to be in a location which makes
it easy for sharing it in the first place. As it stands today, it does
not seem useful to me to have this code in arch/arm/mach-bcm/ at all.

Maybe there is room from a drivers/power/domains/ of some kind?
-- 
Florian

Re: [PATCH v3 2/4] ARM: bcm2835: add rpi power domain driver

[Eric Anholt]

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

Florian Fainelli <f.fainelli@gmail.com> writes:

> On 15/12/15 15:55, Eric Anholt wrote:
>> Florian Fainelli <f.fainelli@gmail.com> writes:
>> 
>>> On 15/12/15 13:40, Eric Anholt wrote:
>>>> From: Alexander Aring <alex.aring@gmail.com>
>>>>
>>>> This patch adds support for several power domains on Raspberry Pi,
>>>> including USB (so it can be enabled even if the bootloader didn't do
>>>> it), and graphics.
>>>>
>>>> This patch is the combined work of Eric Anholt (who wrote USB support
>>>> inside of the Raspberry Pi firmware driver, and wrote the non-USB
>>>> domain support) and Alexander Aring (who separated the original USB
>>>> work out from the firmware driver).
>>>>
>>>> Signed-off-by: Alexander Aring <alex.aring@gmail.com>
>>>> Signed-off-by: Eric Anholt <eric@anholt.net>
>>>> ---
>>>>
>>>> v2: Add support for power domains other than USB, using the new
>>>>     firmware interface, reword commit message (changes by Eric)
>>>>
>>>> v3: Restructure as a builtin driver, and drop
>>>>     of_genpd_add_provider_onecell error handling to avoid
>>>>     pm_genpd_exit() dependency until that API can be settled.  Clean
>>>>     up copyright header, add missing ISP initialization, and fix typo
>>>>     in transposer's name.
>>>>
>>>>  arch/arm/mach-bcm/Kconfig                   |  10 ++
>>>>  arch/arm/mach-bcm/Makefile                  |   1 +
>>>>  arch/arm/mach-bcm/raspberrypi-power.c       | 247 ++++++++++++++++++++++++++++
>>>>  include/dt-bindings/arm/raspberrypi-power.h |  41 +++++
>>>>  4 files changed, 299 insertions(+)
>>>>  create mode 100644 arch/arm/mach-bcm/raspberrypi-power.c
>>>
>>> What motivated the location of this power domain driver in
>>> arch/arm/mach-bcm? Should not we have this in drivers/power/ or
>>> somewhere in drivers/ at the very least?
>> 
>> ls stronly suggests that power contains drivers for power supplies and
>> batteries, not power domains.  There are 6 power domain drivers in
>> arch/arm, 3 in drivers/clk, and 3 in drivers/soc.
>
> If we ever have to support a different architecture which happens to use
> a similar power domain, then we want it to be in a location which makes
> it easy for sharing it in the first place. As it stands today, it does
> not seem useful to me to have this code in arch/arm/mach-bcm/ at all.
>
> Maybe there is room from a drivers/power/domains/ of some kind?

The great thing about git is that moving code is easy, even after it's
first committed.

The subsystem maintainer didn't comment on the code's location in v1 or
v2, and I think they probably have the final say on that.  Whatever they
want, where there is currently a genpd driver, is fine with me.

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

[PATCH v3 2/4] ARM: bcm2835: add rpi power domain driver

[Eric Anholt]

Florian Fainelli <f.fainelli@gmail.com> writes:

> On 15/12/15 15:55, Eric Anholt wrote:
>> Florian Fainelli <f.fainelli@gmail.com> writes:
>> 
>>> On 15/12/15 13:40, Eric Anholt wrote:
>>>> From: Alexander Aring <alex.aring@gmail.com>
>>>>
>>>> This patch adds support for several power domains on Raspberry Pi,
>>>> including USB (so it can be enabled even if the bootloader didn't do
>>>> it), and graphics.
>>>>
>>>> This patch is the combined work of Eric Anholt (who wrote USB support
>>>> inside of the Raspberry Pi firmware driver, and wrote the non-USB
>>>> domain support) and Alexander Aring (who separated the original USB
>>>> work out from the firmware driver).
>>>>
>>>> Signed-off-by: Alexander Aring <alex.aring@gmail.com>
>>>> Signed-off-by: Eric Anholt <eric@anholt.net>
>>>> ---
>>>>
>>>> v2: Add support for power domains other than USB, using the new
>>>>     firmware interface, reword commit message (changes by Eric)
>>>>
>>>> v3: Restructure as a builtin driver, and drop
>>>>     of_genpd_add_provider_onecell error handling to avoid
>>>>     pm_genpd_exit() dependency until that API can be settled.  Clean
>>>>     up copyright header, add missing ISP initialization, and fix typo
>>>>     in transposer's name.
>>>>
>>>>  arch/arm/mach-bcm/Kconfig                   |  10 ++
>>>>  arch/arm/mach-bcm/Makefile                  |   1 +
>>>>  arch/arm/mach-bcm/raspberrypi-power.c       | 247 ++++++++++++++++++++++++++++
>>>>  include/dt-bindings/arm/raspberrypi-power.h |  41 +++++
>>>>  4 files changed, 299 insertions(+)
>>>>  create mode 100644 arch/arm/mach-bcm/raspberrypi-power.c
>>>
>>> What motivated the location of this power domain driver in
>>> arch/arm/mach-bcm? Should not we have this in drivers/power/ or
>>> somewhere in drivers/ at the very least?
>> 
>> ls stronly suggests that power contains drivers for power supplies and
>> batteries, not power domains.  There are 6 power domain drivers in
>> arch/arm, 3 in drivers/clk, and 3 in drivers/soc.
>
> If we ever have to support a different architecture which happens to use
> a similar power domain, then we want it to be in a location which makes
> it easy for sharing it in the first place. As it stands today, it does
> not seem useful to me to have this code in arch/arm/mach-bcm/ at all.
>
> Maybe there is room from a drivers/power/domains/ of some kind?

The great thing about git is that moving code is easy, even after it's
first committed.

The subsystem maintainer didn't comment on the code's location in v1 or
v2, and I think they probably have the final say on that.  Whatever they
want, where there is currently a genpd driver, is fine with me.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 818 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20151215/734717d8/attachment.sig>

Re: [PATCH v3 2/4] ARM: bcm2835: add rpi power domain driver

[Sebastian Reichel]

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

Hi,

On Tue, Dec 15, 2015 at 04:53:31PM -0800, Eric Anholt wrote:
> >>> What motivated the location of this power domain driver in
> >>> arch/arm/mach-bcm? Should not we have this in drivers/power/ or
> >>> somewhere in drivers/ at the very least?
> >> 
> >> ls stronly suggests that power contains drivers for power supplies and
> >> batteries, not power domains.

Indeed it's used for fuel gauges and chargers, but also for
reboot/powerdown and adaptive voltage scaling, so another
subdirectory for power-domains wouldn't be that odd.

> >> There are 6 power domain drivers in
> >> arch/arm, 3 in drivers/clk, and 3 in drivers/soc.
> >
> > If we ever have to support a different architecture which happens to use
> > a similar power domain, then we want it to be in a location which makes
> > it easy for sharing it in the first place. As it stands today, it does
> > not seem useful to me to have this code in arch/arm/mach-bcm/ at all.
> >
> > Maybe there is room from a drivers/power/domains/ of some kind?

I like the idea, but let's include generic power domain maintainers
in this discussion, as I suggested here (I got a power domain driver
patch for drivers/power just a few days ago):

https://lkml.org/lkml/2015/12/15/815

Also somebody would have to step up to maintain that directory.

> The great thing about git is that moving code is easy, even after it's
> first committed.
>
> The subsystem maintainer didn't comment on the code's location in v1 or
> v2, and I think they probably have the final say on that.  Whatever they
> want, where there is currently a genpd driver, is fine with me.

sounds reasonable.

P.S.: Thanks for taking bringing RPI support upstream :)

-- Sebastian

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

Re: [PATCH v3 2/4] ARM: bcm2835: add rpi power domain driver

[Sebastian Reichel]

[-- Attachment #1.1: Type: text/plain, Size: 1745 bytes --]

Hi,

On Tue, Dec 15, 2015 at 04:53:31PM -0800, Eric Anholt wrote:
> >>> What motivated the location of this power domain driver in
> >>> arch/arm/mach-bcm? Should not we have this in drivers/power/ or
> >>> somewhere in drivers/ at the very least?
> >> 
> >> ls stronly suggests that power contains drivers for power supplies and
> >> batteries, not power domains.

Indeed it's used for fuel gauges and chargers, but also for
reboot/powerdown and adaptive voltage scaling, so another
subdirectory for power-domains wouldn't be that odd.

> >> There are 6 power domain drivers in
> >> arch/arm, 3 in drivers/clk, and 3 in drivers/soc.
> >
> > If we ever have to support a different architecture which happens to use
> > a similar power domain, then we want it to be in a location which makes
> > it easy for sharing it in the first place. As it stands today, it does
> > not seem useful to me to have this code in arch/arm/mach-bcm/ at all.
> >
> > Maybe there is room from a drivers/power/domains/ of some kind?

I like the idea, but let's include generic power domain maintainers
in this discussion, as I suggested here (I got a power domain driver
patch for drivers/power just a few days ago):

https://lkml.org/lkml/2015/12/15/815

Also somebody would have to step up to maintain that directory.

> The great thing about git is that moving code is easy, even after it's
> first committed.
>
> The subsystem maintainer didn't comment on the code's location in v1 or
> v2, and I think they probably have the final say on that.  Whatever they
> want, where there is currently a genpd driver, is fine with me.

sounds reasonable.

P.S.: Thanks for taking bringing RPI support upstream :)

-- Sebastian

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

[-- Attachment #2: Type: text/plain, Size: 176 bytes --]

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

[PATCH v3 2/4] ARM: bcm2835: add rpi power domain driver

[Sebastian Reichel]

Hi,

On Tue, Dec 15, 2015 at 04:53:31PM -0800, Eric Anholt wrote:
> >>> What motivated the location of this power domain driver in
> >>> arch/arm/mach-bcm? Should not we have this in drivers/power/ or
> >>> somewhere in drivers/ at the very least?
> >> 
> >> ls stronly suggests that power contains drivers for power supplies and
> >> batteries, not power domains.

Indeed it's used for fuel gauges and chargers, but also for
reboot/powerdown and adaptive voltage scaling, so another
subdirectory for power-domains wouldn't be that odd.

> >> There are 6 power domain drivers in
> >> arch/arm, 3 in drivers/clk, and 3 in drivers/soc.
> >
> > If we ever have to support a different architecture which happens to use
> > a similar power domain, then we want it to be in a location which makes
> > it easy for sharing it in the first place. As it stands today, it does
> > not seem useful to me to have this code in arch/arm/mach-bcm/ at all.
> >
> > Maybe there is room from a drivers/power/domains/ of some kind?

I like the idea, but let's include generic power domain maintainers
in this discussion, as I suggested here (I got a power domain driver
patch for drivers/power just a few days ago):

https://lkml.org/lkml/2015/12/15/815

Also somebody would have to step up to maintain that directory.

> The great thing about git is that moving code is easy, even after it's
> first committed.
>
> The subsystem maintainer didn't comment on the code's location in v1 or
> v2, and I think they probably have the final say on that.  Whatever they
> want, where there is currently a genpd driver, is fine with me.

sounds reasonable.

P.S.: Thanks for taking bringing RPI support upstream :)

-- Sebastian
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20151216/987f00f3/attachment.sig>

Re: [PATCH v3 2/4] ARM: bcm2835: add rpi power domain driver

[Krzysztof Kozlowski]

2015-12-16 10:11 GMT+09:00 Sebastian Reichel <sre@ring0.de>:
> Hi,
>
> On Tue, Dec 15, 2015 at 04:53:31PM -0800, Eric Anholt wrote:
>> >>> What motivated the location of this power domain driver in
>> >>> arch/arm/mach-bcm? Should not we have this in drivers/power/ or
>> >>> somewhere in drivers/ at the very least?
>> >>
>> >> ls stronly suggests that power contains drivers for power supplies and
>> >> batteries, not power domains.
>
> Indeed it's used for fuel gauges and chargers, but also for
> reboot/powerdown and adaptive voltage scaling, so another
> subdirectory for power-domains wouldn't be that odd.
>
>> >> There are 6 power domain drivers in
>> >> arch/arm, 3 in drivers/clk, and 3 in drivers/soc.
>> >
>> > If we ever have to support a different architecture which happens to use
>> > a similar power domain, then we want it to be in a location which makes
>> > it easy for sharing it in the first place. As it stands today, it does
>> > not seem useful to me to have this code in arch/arm/mach-bcm/ at all.
>> >
>> > Maybe there is room from a drivers/power/domains/ of some kind?
>
> I like the idea, but let's include generic power domain maintainers
> in this discussion, as I suggested here (I got a power domain driver
> patch for drivers/power just a few days ago):
>
> https://lkml.org/lkml/2015/12/15/815
>
> Also somebody would have to step up to maintain that directory.

This could go into drivers/soc. We put there a lot of mach-specific
stuff which we want to make a little more generic (like generic enough
multiplatform, multiarchitecture etc). Rockchip has its own power
domains there. Dove and Mediatek seem as well but I am not sure. Some
other architectures keep this still in arm/mach (exynos, ux500, zx,
imx, s34c64xx, shmobile) but this looks more of like a legacy choice.

However, since generic power domains have its own maintainers entry
and reside under drivers/base/power, maybe making a separate directory
for power domains drivers makes sense?

Best regards,
Krzysztof

Re: [PATCH v3 2/4] ARM: bcm2835: add rpi power domain driver

[Krzysztof Kozlowski]

2015-12-16 10:11 GMT+09:00 Sebastian Reichel <sre@ring0.de>:
> Hi,
>
> On Tue, Dec 15, 2015 at 04:53:31PM -0800, Eric Anholt wrote:
>> >>> What motivated the location of this power domain driver in
>> >>> arch/arm/mach-bcm? Should not we have this in drivers/power/ or
>> >>> somewhere in drivers/ at the very least?
>> >>
>> >> ls stronly suggests that power contains drivers for power supplies and
>> >> batteries, not power domains.
>
> Indeed it's used for fuel gauges and chargers, but also for
> reboot/powerdown and adaptive voltage scaling, so another
> subdirectory for power-domains wouldn't be that odd.
>
>> >> There are 6 power domain drivers in
>> >> arch/arm, 3 in drivers/clk, and 3 in drivers/soc.
>> >
>> > If we ever have to support a different architecture which happens to use
>> > a similar power domain, then we want it to be in a location which makes
>> > it easy for sharing it in the first place. As it stands today, it does
>> > not seem useful to me to have this code in arch/arm/mach-bcm/ at all.
>> >
>> > Maybe there is room from a drivers/power/domains/ of some kind?
>
> I like the idea, but let's include generic power domain maintainers
> in this discussion, as I suggested here (I got a power domain driver
> patch for drivers/power just a few days ago):
>
> https://lkml.org/lkml/2015/12/15/815
>
> Also somebody would have to step up to maintain that directory.

This could go into drivers/soc. We put there a lot of mach-specific
stuff which we want to make a little more generic (like generic enough
multiplatform, multiarchitecture etc). Rockchip has its own power
domains there. Dove and Mediatek seem as well but I am not sure. Some
other architectures keep this still in arm/mach (exynos, ux500, zx,
imx, s34c64xx, shmobile) but this looks more of like a legacy choice.

However, since generic power domains have its own maintainers entry
and reside under drivers/base/power, maybe making a separate directory
for power domains drivers makes sense?

Best regards,
Krzysztof

[PATCH v3 2/4] ARM: bcm2835: add rpi power domain driver

[Krzysztof Kozlowski]

2015-12-16 10:11 GMT+09:00 Sebastian Reichel <sre@ring0.de>:
> Hi,
>
> On Tue, Dec 15, 2015 at 04:53:31PM -0800, Eric Anholt wrote:
>> >>> What motivated the location of this power domain driver in
>> >>> arch/arm/mach-bcm? Should not we have this in drivers/power/ or
>> >>> somewhere in drivers/ at the very least?
>> >>
>> >> ls stronly suggests that power contains drivers for power supplies and
>> >> batteries, not power domains.
>
> Indeed it's used for fuel gauges and chargers, but also for
> reboot/powerdown and adaptive voltage scaling, so another
> subdirectory for power-domains wouldn't be that odd.
>
>> >> There are 6 power domain drivers in
>> >> arch/arm, 3 in drivers/clk, and 3 in drivers/soc.
>> >
>> > If we ever have to support a different architecture which happens to use
>> > a similar power domain, then we want it to be in a location which makes
>> > it easy for sharing it in the first place. As it stands today, it does
>> > not seem useful to me to have this code in arch/arm/mach-bcm/ at all.
>> >
>> > Maybe there is room from a drivers/power/domains/ of some kind?
>
> I like the idea, but let's include generic power domain maintainers
> in this discussion, as I suggested here (I got a power domain driver
> patch for drivers/power just a few days ago):
>
> https://lkml.org/lkml/2015/12/15/815
>
> Also somebody would have to step up to maintain that directory.

This could go into drivers/soc. We put there a lot of mach-specific
stuff which we want to make a little more generic (like generic enough
multiplatform, multiarchitecture etc). Rockchip has its own power
domains there. Dove and Mediatek seem as well but I am not sure. Some
other architectures keep this still in arm/mach (exynos, ux500, zx,
imx, s34c64xx, shmobile) but this looks more of like a legacy choice.

However, since generic power domains have its own maintainers entry
and reside under drivers/base/power, maybe making a separate directory
for power domains drivers makes sense?

Best regards,
Krzysztof

Re: [PATCH v3 2/4] ARM: bcm2835: add rpi power domain driver

[Ulf Hansson]

On 16 December 2015 at 02:27, Krzysztof Kozlowski
<k.kozlowski@samsung.com> wrote:
> 2015-12-16 10:11 GMT+09:00 Sebastian Reichel <sre@ring0.de>:
>> Hi,
>>
>> On Tue, Dec 15, 2015 at 04:53:31PM -0800, Eric Anholt wrote:
>>> >>> What motivated the location of this power domain driver in
>>> >>> arch/arm/mach-bcm? Should not we have this in drivers/power/ or
>>> >>> somewhere in drivers/ at the very least?
>>> >>
>>> >> ls stronly suggests that power contains drivers for power supplies and
>>> >> batteries, not power domains.
>>
>> Indeed it's used for fuel gauges and chargers, but also for
>> reboot/powerdown and adaptive voltage scaling, so another
>> subdirectory for power-domains wouldn't be that odd.
>>
>>> >> There are 6 power domain drivers in
>>> >> arch/arm, 3 in drivers/clk, and 3 in drivers/soc.
>>> >
>>> > If we ever have to support a different architecture which happens to use
>>> > a similar power domain, then we want it to be in a location which makes
>>> > it easy for sharing it in the first place. As it stands today, it does
>>> > not seem useful to me to have this code in arch/arm/mach-bcm/ at all.
>>> >
>>> > Maybe there is room from a drivers/power/domains/ of some kind?
>>
>> I like the idea, but let's include generic power domain maintainers
>> in this discussion, as I suggested here (I got a power domain driver
>> patch for drivers/power just a few days ago):
>>
>> https://lkml.org/lkml/2015/12/15/815
>>
>> Also somebody would have to step up to maintain that directory.
>
> This could go into drivers/soc. We put there a lot of mach-specific
> stuff which we want to make a little more generic (like generic enough
> multiplatform, multiarchitecture etc). Rockchip has its own power
> domains there. Dove and Mediatek seem as well but I am not sure. Some
> other architectures keep this still in arm/mach (exynos, ux500, zx,
> imx, s34c64xx, shmobile) but this looks more of like a legacy choice.

Agree, drivers/soc is good.

>
> However, since the generic power domains have its own maintainers entry
> and reside under drivers/base/power, maybe making a separate directory
> for power domains drivers makes sense?

That could work as well, but I have no strong opinion.
Perhaps it would become a bit more clear, although in that case I
would also move drivers/base/power/domain* in there.

If that happens, I am willing to help maintain it.

Kind regards
Uffe

Re: [PATCH v3 2/4] ARM: bcm2835: add rpi power domain driver

[Ulf Hansson]

On 16 December 2015 at 02:27, Krzysztof Kozlowski
<k.kozlowski@samsung.com> wrote:
> 2015-12-16 10:11 GMT+09:00 Sebastian Reichel <sre@ring0.de>:
>> Hi,
>>
>> On Tue, Dec 15, 2015 at 04:53:31PM -0800, Eric Anholt wrote:
>>> >>> What motivated the location of this power domain driver in
>>> >>> arch/arm/mach-bcm? Should not we have this in drivers/power/ or
>>> >>> somewhere in drivers/ at the very least?
>>> >>
>>> >> ls stronly suggests that power contains drivers for power supplies and
>>> >> batteries, not power domains.
>>
>> Indeed it's used for fuel gauges and chargers, but also for
>> reboot/powerdown and adaptive voltage scaling, so another
>> subdirectory for power-domains wouldn't be that odd.
>>
>>> >> There are 6 power domain drivers in
>>> >> arch/arm, 3 in drivers/clk, and 3 in drivers/soc.
>>> >
>>> > If we ever have to support a different architecture which happens to use
>>> > a similar power domain, then we want it to be in a location which makes
>>> > it easy for sharing it in the first place. As it stands today, it does
>>> > not seem useful to me to have this code in arch/arm/mach-bcm/ at all.
>>> >
>>> > Maybe there is room from a drivers/power/domains/ of some kind?
>>
>> I like the idea, but let's include generic power domain maintainers
>> in this discussion, as I suggested here (I got a power domain driver
>> patch for drivers/power just a few days ago):
>>
>> https://lkml.org/lkml/2015/12/15/815
>>
>> Also somebody would have to step up to maintain that directory.
>
> This could go into drivers/soc. We put there a lot of mach-specific
> stuff which we want to make a little more generic (like generic enough
> multiplatform, multiarchitecture etc). Rockchip has its own power
> domains there. Dove and Mediatek seem as well but I am not sure. Some
> other architectures keep this still in arm/mach (exynos, ux500, zx,
> imx, s34c64xx, shmobile) but this looks more of like a legacy choice.

Agree, drivers/soc is good.

>
> However, since the generic power domains have its own maintainers entry
> and reside under drivers/base/power, maybe making a separate directory
> for power domains drivers makes sense?

That could work as well, but I have no strong opinion.
Perhaps it would become a bit more clear, although in that case I
would also move drivers/base/power/domain* in there.

If that happens, I am willing to help maintain it.

Kind regards
Uffe

[PATCH v3 2/4] ARM: bcm2835: add rpi power domain driver

[Ulf Hansson]

On 16 December 2015 at 02:27, Krzysztof Kozlowski
<k.kozlowski@samsung.com> wrote:
> 2015-12-16 10:11 GMT+09:00 Sebastian Reichel <sre@ring0.de>:
>> Hi,
>>
>> On Tue, Dec 15, 2015 at 04:53:31PM -0800, Eric Anholt wrote:
>>> >>> What motivated the location of this power domain driver in
>>> >>> arch/arm/mach-bcm? Should not we have this in drivers/power/ or
>>> >>> somewhere in drivers/ at the very least?
>>> >>
>>> >> ls stronly suggests that power contains drivers for power supplies and
>>> >> batteries, not power domains.
>>
>> Indeed it's used for fuel gauges and chargers, but also for
>> reboot/powerdown and adaptive voltage scaling, so another
>> subdirectory for power-domains wouldn't be that odd.
>>
>>> >> There are 6 power domain drivers in
>>> >> arch/arm, 3 in drivers/clk, and 3 in drivers/soc.
>>> >
>>> > If we ever have to support a different architecture which happens to use
>>> > a similar power domain, then we want it to be in a location which makes
>>> > it easy for sharing it in the first place. As it stands today, it does
>>> > not seem useful to me to have this code in arch/arm/mach-bcm/ at all.
>>> >
>>> > Maybe there is room from a drivers/power/domains/ of some kind?
>>
>> I like the idea, but let's include generic power domain maintainers
>> in this discussion, as I suggested here (I got a power domain driver
>> patch for drivers/power just a few days ago):
>>
>> https://lkml.org/lkml/2015/12/15/815
>>
>> Also somebody would have to step up to maintain that directory.
>
> This could go into drivers/soc. We put there a lot of mach-specific
> stuff which we want to make a little more generic (like generic enough
> multiplatform, multiarchitecture etc). Rockchip has its own power
> domains there. Dove and Mediatek seem as well but I am not sure. Some
> other architectures keep this still in arm/mach (exynos, ux500, zx,
> imx, s34c64xx, shmobile) but this looks more of like a legacy choice.

Agree, drivers/soc is good.

>
> However, since the generic power domains have its own maintainers entry
> and reside under drivers/base/power, maybe making a separate directory
> for power domains drivers makes sense?

That could work as well, but I have no strong opinion.
Perhaps it would become a bit more clear, although in that case I
would also move drivers/base/power/domain* in there.

If that happens, I am willing to help maintain it.

Kind regards
Uffe

Re: [PATCH v3 2/4] ARM: bcm2835: add rpi power domain driver

[Eric Anholt]

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

Ulf Hansson <ulf.hansson@linaro.org> writes:

> On 16 December 2015 at 02:27, Krzysztof Kozlowski
> <k.kozlowski@samsung.com> wrote:
>> 2015-12-16 10:11 GMT+09:00 Sebastian Reichel <sre@ring0.de>:
>>> Hi,
>>>
>>> On Tue, Dec 15, 2015 at 04:53:31PM -0800, Eric Anholt wrote:
>>>> >> There are 6 power domain drivers in
>>>> >> arch/arm, 3 in drivers/clk, and 3 in drivers/soc.
>>>> >
>>>> > If we ever have to support a different architecture which happens to use
>>>> > a similar power domain, then we want it to be in a location which makes
>>>> > it easy for sharing it in the first place. As it stands today, it does
>>>> > not seem useful to me to have this code in arch/arm/mach-bcm/ at all.
>>>> >
>>>> > Maybe there is room from a drivers/power/domains/ of some kind?
>>>
>>> I like the idea, but let's include generic power domain maintainers
>>> in this discussion, as I suggested here (I got a power domain driver
>>> patch for drivers/power just a few days ago):
>>>
>>> https://lkml.org/lkml/2015/12/15/815
>>>
>>> Also somebody would have to step up to maintain that directory.
>>
>> This could go into drivers/soc. We put there a lot of mach-specific
>> stuff which we want to make a little more generic (like generic enough
>> multiplatform, multiarchitecture etc). Rockchip has its own power
>> domains there. Dove and Mediatek seem as well but I am not sure. Some
>> other architectures keep this still in arm/mach (exynos, ux500, zx,
>> imx, s34c64xx, shmobile) but this looks more of like a legacy choice.
>
> Agree, drivers/soc is good.

OK, I've resent with a move to drivers/soc/bcm/.

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

Re: [PATCH v3 2/4] ARM: bcm2835: add rpi power domain driver

[Eric Anholt]

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

Ulf Hansson <ulf.hansson@linaro.org> writes:

> On 16 December 2015 at 02:27, Krzysztof Kozlowski
> <k.kozlowski@samsung.com> wrote:
>> 2015-12-16 10:11 GMT+09:00 Sebastian Reichel <sre@ring0.de>:
>>> Hi,
>>>
>>> On Tue, Dec 15, 2015 at 04:53:31PM -0800, Eric Anholt wrote:
>>>> >> There are 6 power domain drivers in
>>>> >> arch/arm, 3 in drivers/clk, and 3 in drivers/soc.
>>>> >
>>>> > If we ever have to support a different architecture which happens to use
>>>> > a similar power domain, then we want it to be in a location which makes
>>>> > it easy for sharing it in the first place. As it stands today, it does
>>>> > not seem useful to me to have this code in arch/arm/mach-bcm/ at all.
>>>> >
>>>> > Maybe there is room from a drivers/power/domains/ of some kind?
>>>
>>> I like the idea, but let's include generic power domain maintainers
>>> in this discussion, as I suggested here (I got a power domain driver
>>> patch for drivers/power just a few days ago):
>>>
>>> https://lkml.org/lkml/2015/12/15/815
>>>
>>> Also somebody would have to step up to maintain that directory.
>>
>> This could go into drivers/soc. We put there a lot of mach-specific
>> stuff which we want to make a little more generic (like generic enough
>> multiplatform, multiarchitecture etc). Rockchip has its own power
>> domains there. Dove and Mediatek seem as well but I am not sure. Some
>> other architectures keep this still in arm/mach (exynos, ux500, zx,
>> imx, s34c64xx, shmobile) but this looks more of like a legacy choice.
>
> Agree, drivers/soc is good.

OK, I've resent with a move to drivers/soc/bcm/.

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

[PATCH v3 2/4] ARM: bcm2835: add rpi power domain driver

[Eric Anholt]

Ulf Hansson <ulf.hansson@linaro.org> writes:

> On 16 December 2015 at 02:27, Krzysztof Kozlowski
> <k.kozlowski@samsung.com> wrote:
>> 2015-12-16 10:11 GMT+09:00 Sebastian Reichel <sre@ring0.de>:
>>> Hi,
>>>
>>> On Tue, Dec 15, 2015 at 04:53:31PM -0800, Eric Anholt wrote:
>>>> >> There are 6 power domain drivers in
>>>> >> arch/arm, 3 in drivers/clk, and 3 in drivers/soc.
>>>> >
>>>> > If we ever have to support a different architecture which happens to use
>>>> > a similar power domain, then we want it to be in a location which makes
>>>> > it easy for sharing it in the first place. As it stands today, it does
>>>> > not seem useful to me to have this code in arch/arm/mach-bcm/ at all.
>>>> >
>>>> > Maybe there is room from a drivers/power/domains/ of some kind?
>>>
>>> I like the idea, but let's include generic power domain maintainers
>>> in this discussion, as I suggested here (I got a power domain driver
>>> patch for drivers/power just a few days ago):
>>>
>>> https://lkml.org/lkml/2015/12/15/815
>>>
>>> Also somebody would have to step up to maintain that directory.
>>
>> This could go into drivers/soc. We put there a lot of mach-specific
>> stuff which we want to make a little more generic (like generic enough
>> multiplatform, multiarchitecture etc). Rockchip has its own power
>> domains there. Dove and Mediatek seem as well but I am not sure. Some
>> other architectures keep this still in arm/mach (exynos, ux500, zx,
>> imx, s34c64xx, shmobile) but this looks more of like a legacy choice.
>
> Agree, drivers/soc is good.

OK, I've resent with a move to drivers/soc/bcm/.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 818 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20151216/5f8e7d40/attachment.sig>

Re: [PATCH v3 0/4] Raspberry Pi power domains

[Ulf Hansson]

On 15 December 2015 at 22:40, Eric Anholt <eric@anholt.net> wrote:
> Since the pm_genpd_exit() patch is still going through review, and
> other drivers in the tree just ignore the error cases, Ulf offered to
> merge the series as a builtin driver not depending on that interface.
> We still avoid dangling pointer references, by just continuing with
> probing if of_genpd_add_provider_onecell() fails.  We can easily go
> back and update the driver when a pm_genpd_exit() lands.
>
> Alexander Aring (3):
>   ARM: bcm2835: add rpi power domain driver
>   dt-bindings: add rpi power domain driver bindings
>   ARM: bcm2835: Add the Raspberry Pi power domain driver to the DT.
>
> Eric Anholt (1):
>   ARM: bcm2835: Define two new packets from the latest firmware.
>
>  .../bindings/arm/bcm/raspberrypi,bcm2835-power.txt |  47 ++++
>  arch/arm/boot/dts/bcm2835-rpi.dtsi                 |  11 +
>  arch/arm/boot/dts/bcm2835.dtsi                     |   2 +-
>  arch/arm/mach-bcm/Kconfig                          |  10 +
>  arch/arm/mach-bcm/Makefile                         |   1 +
>  arch/arm/mach-bcm/raspberrypi-power.c              | 247 +++++++++++++++++++++
>  include/dt-bindings/arm/raspberrypi-power.h        |  41 ++++
>  include/soc/bcm2835/raspberrypi-firmware.h         |   2 +
>  8 files changed, 360 insertions(+), 1 deletion(-)
>  create mode 100644 Documentation/devicetree/bindings/arm/bcm/raspberrypi,bcm2835-power.txt
>  create mode 100644 arch/arm/mach-bcm/raspberrypi-power.c
>  create mode 100644 include/dt-bindings/arm/raspberrypi-power.h
>
> --
> 2.6.2
>

Besides a nitpick for patch2, I would also reverse the order of patch3
and patch2. DT docs should go in before the actual parsing of the new
bindings/compatibles.

Anyway, for the hole series, you may add my:

Reviewed-by: Ulf Hansson <ulf.hansson@linaro.org>

Kind regards
Uffe

Re: [PATCH v3 0/4] Raspberry Pi power domains

[Ulf Hansson]

On 15 December 2015 at 22:40, Eric Anholt <eric@anholt.net> wrote:
> Since the pm_genpd_exit() patch is still going through review, and
> other drivers in the tree just ignore the error cases, Ulf offered to
> merge the series as a builtin driver not depending on that interface.
> We still avoid dangling pointer references, by just continuing with
> probing if of_genpd_add_provider_onecell() fails.  We can easily go
> back and update the driver when a pm_genpd_exit() lands.
>
> Alexander Aring (3):
>   ARM: bcm2835: add rpi power domain driver
>   dt-bindings: add rpi power domain driver bindings
>   ARM: bcm2835: Add the Raspberry Pi power domain driver to the DT.
>
> Eric Anholt (1):
>   ARM: bcm2835: Define two new packets from the latest firmware.
>
>  .../bindings/arm/bcm/raspberrypi,bcm2835-power.txt |  47 ++++
>  arch/arm/boot/dts/bcm2835-rpi.dtsi                 |  11 +
>  arch/arm/boot/dts/bcm2835.dtsi                     |   2 +-
>  arch/arm/mach-bcm/Kconfig                          |  10 +
>  arch/arm/mach-bcm/Makefile                         |   1 +
>  arch/arm/mach-bcm/raspberrypi-power.c              | 247 +++++++++++++++++++++
>  include/dt-bindings/arm/raspberrypi-power.h        |  41 ++++
>  include/soc/bcm2835/raspberrypi-firmware.h         |   2 +
>  8 files changed, 360 insertions(+), 1 deletion(-)
>  create mode 100644 Documentation/devicetree/bindings/arm/bcm/raspberrypi,bcm2835-power.txt
>  create mode 100644 arch/arm/mach-bcm/raspberrypi-power.c
>  create mode 100644 include/dt-bindings/arm/raspberrypi-power.h
>
> --
> 2.6.2
>

Besides a nitpick for patch2, I would also reverse the order of patch3
and patch2. DT docs should go in before the actual parsing of the new
bindings/compatibles.

Anyway, for the hole series, you may add my:

Reviewed-by: Ulf Hansson <ulf.hansson@linaro.org>

Kind regards
Uffe

[PATCH v3 0/4] Raspberry Pi power domains

[Ulf Hansson]

On 15 December 2015 at 22:40, Eric Anholt <eric@anholt.net> wrote:
> Since the pm_genpd_exit() patch is still going through review, and
> other drivers in the tree just ignore the error cases, Ulf offered to
> merge the series as a builtin driver not depending on that interface.
> We still avoid dangling pointer references, by just continuing with
> probing if of_genpd_add_provider_onecell() fails.  We can easily go
> back and update the driver when a pm_genpd_exit() lands.
>
> Alexander Aring (3):
>   ARM: bcm2835: add rpi power domain driver
>   dt-bindings: add rpi power domain driver bindings
>   ARM: bcm2835: Add the Raspberry Pi power domain driver to the DT.
>
> Eric Anholt (1):
>   ARM: bcm2835: Define two new packets from the latest firmware.
>
>  .../bindings/arm/bcm/raspberrypi,bcm2835-power.txt |  47 ++++
>  arch/arm/boot/dts/bcm2835-rpi.dtsi                 |  11 +
>  arch/arm/boot/dts/bcm2835.dtsi                     |   2 +-
>  arch/arm/mach-bcm/Kconfig                          |  10 +
>  arch/arm/mach-bcm/Makefile                         |   1 +
>  arch/arm/mach-bcm/raspberrypi-power.c              | 247 +++++++++++++++++++++
>  include/dt-bindings/arm/raspberrypi-power.h        |  41 ++++
>  include/soc/bcm2835/raspberrypi-firmware.h         |   2 +
>  8 files changed, 360 insertions(+), 1 deletion(-)
>  create mode 100644 Documentation/devicetree/bindings/arm/bcm/raspberrypi,bcm2835-power.txt
>  create mode 100644 arch/arm/mach-bcm/raspberrypi-power.c
>  create mode 100644 include/dt-bindings/arm/raspberrypi-power.h
>
> --
> 2.6.2
>

Besides a nitpick for patch2, I would also reverse the order of patch3
and patch2. DT docs should go in before the actual parsing of the new
bindings/compatibles.

Anyway, for the hole series, you may add my:

Reviewed-by: Ulf Hansson <ulf.hansson@linaro.org>

Kind regards
Uffe

Re: [PATCH v3 0/4] Raspberry Pi power domains

[Eric Anholt]

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

Ulf Hansson <ulf.hansson@linaro.org> writes:

> On 15 December 2015 at 22:40, Eric Anholt <eric@anholt.net> wrote:
>> Since the pm_genpd_exit() patch is still going through review, and
>> other drivers in the tree just ignore the error cases, Ulf offered to
>> merge the series as a builtin driver not depending on that interface.
>> We still avoid dangling pointer references, by just continuing with
>> probing if of_genpd_add_provider_onecell() fails.  We can easily go
>> back and update the driver when a pm_genpd_exit() lands.
>>
>> Alexander Aring (3):
>>   ARM: bcm2835: add rpi power domain driver
>>   dt-bindings: add rpi power domain driver bindings
>>   ARM: bcm2835: Add the Raspberry Pi power domain driver to the DT.
>>
>> Eric Anholt (1):
>>   ARM: bcm2835: Define two new packets from the latest firmware.
>>
>>  .../bindings/arm/bcm/raspberrypi,bcm2835-power.txt |  47 ++++
>>  arch/arm/boot/dts/bcm2835-rpi.dtsi                 |  11 +
>>  arch/arm/boot/dts/bcm2835.dtsi                     |   2 +-
>>  arch/arm/mach-bcm/Kconfig                          |  10 +
>>  arch/arm/mach-bcm/Makefile                         |   1 +
>>  arch/arm/mach-bcm/raspberrypi-power.c              | 247 +++++++++++++++++++++
>>  include/dt-bindings/arm/raspberrypi-power.h        |  41 ++++
>>  include/soc/bcm2835/raspberrypi-firmware.h         |   2 +
>>  8 files changed, 360 insertions(+), 1 deletion(-)
>>  create mode 100644 Documentation/devicetree/bindings/arm/bcm/raspberrypi,bcm2835-power.txt
>>  create mode 100644 arch/arm/mach-bcm/raspberrypi-power.c
>>  create mode 100644 include/dt-bindings/arm/raspberrypi-power.h
>>
>> --
>> 2.6.2
>>
>
> Besides a nitpick for patch2, I would also reverse the order of patch3
> and patch2. DT docs should go in before the actual parsing of the new
> bindings/compatibles.
>
> Anyway, for the hole series, you may add my:
>
> Reviewed-by: Ulf Hansson <ulf.hansson@linaro.org>

Would your tree be pulling the series (since it's power domains), or
should I (since it's SOC stuff)?

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

Re: [PATCH v3 0/4] Raspberry Pi power domains

[Eric Anholt]

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

Ulf Hansson <ulf.hansson@linaro.org> writes:

> On 15 December 2015 at 22:40, Eric Anholt <eric@anholt.net> wrote:
>> Since the pm_genpd_exit() patch is still going through review, and
>> other drivers in the tree just ignore the error cases, Ulf offered to
>> merge the series as a builtin driver not depending on that interface.
>> We still avoid dangling pointer references, by just continuing with
>> probing if of_genpd_add_provider_onecell() fails.  We can easily go
>> back and update the driver when a pm_genpd_exit() lands.
>>
>> Alexander Aring (3):
>>   ARM: bcm2835: add rpi power domain driver
>>   dt-bindings: add rpi power domain driver bindings
>>   ARM: bcm2835: Add the Raspberry Pi power domain driver to the DT.
>>
>> Eric Anholt (1):
>>   ARM: bcm2835: Define two new packets from the latest firmware.
>>
>>  .../bindings/arm/bcm/raspberrypi,bcm2835-power.txt |  47 ++++
>>  arch/arm/boot/dts/bcm2835-rpi.dtsi                 |  11 +
>>  arch/arm/boot/dts/bcm2835.dtsi                     |   2 +-
>>  arch/arm/mach-bcm/Kconfig                          |  10 +
>>  arch/arm/mach-bcm/Makefile                         |   1 +
>>  arch/arm/mach-bcm/raspberrypi-power.c              | 247 +++++++++++++++++++++
>>  include/dt-bindings/arm/raspberrypi-power.h        |  41 ++++
>>  include/soc/bcm2835/raspberrypi-firmware.h         |   2 +
>>  8 files changed, 360 insertions(+), 1 deletion(-)
>>  create mode 100644 Documentation/devicetree/bindings/arm/bcm/raspberrypi,bcm2835-power.txt
>>  create mode 100644 arch/arm/mach-bcm/raspberrypi-power.c
>>  create mode 100644 include/dt-bindings/arm/raspberrypi-power.h
>>
>> --
>> 2.6.2
>>
>
> Besides a nitpick for patch2, I would also reverse the order of patch3
> and patch2. DT docs should go in before the actual parsing of the new
> bindings/compatibles.
>
> Anyway, for the hole series, you may add my:
>
> Reviewed-by: Ulf Hansson <ulf.hansson@linaro.org>

Would your tree be pulling the series (since it's power domains), or
should I (since it's SOC stuff)?

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

[PATCH v3 0/4] Raspberry Pi power domains

[Eric Anholt]

Ulf Hansson <ulf.hansson@linaro.org> writes:

> On 15 December 2015 at 22:40, Eric Anholt <eric@anholt.net> wrote:
>> Since the pm_genpd_exit() patch is still going through review, and
>> other drivers in the tree just ignore the error cases, Ulf offered to
>> merge the series as a builtin driver not depending on that interface.
>> We still avoid dangling pointer references, by just continuing with
>> probing if of_genpd_add_provider_onecell() fails.  We can easily go
>> back and update the driver when a pm_genpd_exit() lands.
>>
>> Alexander Aring (3):
>>   ARM: bcm2835: add rpi power domain driver
>>   dt-bindings: add rpi power domain driver bindings
>>   ARM: bcm2835: Add the Raspberry Pi power domain driver to the DT.
>>
>> Eric Anholt (1):
>>   ARM: bcm2835: Define two new packets from the latest firmware.
>>
>>  .../bindings/arm/bcm/raspberrypi,bcm2835-power.txt |  47 ++++
>>  arch/arm/boot/dts/bcm2835-rpi.dtsi                 |  11 +
>>  arch/arm/boot/dts/bcm2835.dtsi                     |   2 +-
>>  arch/arm/mach-bcm/Kconfig                          |  10 +
>>  arch/arm/mach-bcm/Makefile                         |   1 +
>>  arch/arm/mach-bcm/raspberrypi-power.c              | 247 +++++++++++++++++++++
>>  include/dt-bindings/arm/raspberrypi-power.h        |  41 ++++
>>  include/soc/bcm2835/raspberrypi-firmware.h         |   2 +
>>  8 files changed, 360 insertions(+), 1 deletion(-)
>>  create mode 100644 Documentation/devicetree/bindings/arm/bcm/raspberrypi,bcm2835-power.txt
>>  create mode 100644 arch/arm/mach-bcm/raspberrypi-power.c
>>  create mode 100644 include/dt-bindings/arm/raspberrypi-power.h
>>
>> --
>> 2.6.2
>>
>
> Besides a nitpick for patch2, I would also reverse the order of patch3
> and patch2. DT docs should go in before the actual parsing of the new
> bindings/compatibles.
>
> Anyway, for the hole series, you may add my:
>
> Reviewed-by: Ulf Hansson <ulf.hansson@linaro.org>

Would your tree be pulling the series (since it's power domains), or
should I (since it's SOC stuff)?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 818 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20151217/53cfcc42/attachment-0001.sig>

Re: [PATCH v3 0/4] Raspberry Pi power domains

[Arnd Bergmann]

On Thursday 17 December 2015 11:03:47 Eric Anholt wrote:
> >>
> >>  .../bindings/arm/bcm/raspberrypi,bcm2835-power.txt |  47 ++++
> >>  arch/arm/boot/dts/bcm2835-rpi.dtsi                 |  11 +
> >>  arch/arm/boot/dts/bcm2835.dtsi                     |   2 +-
> >>  arch/arm/mach-bcm/Kconfig                          |  10 +
> >>  arch/arm/mach-bcm/Makefile                         |   1 +
> >>  arch/arm/mach-bcm/raspberrypi-power.c              | 247 +++++++++++++++++++++
> >>  include/dt-bindings/arm/raspberrypi-power.h        |  41 ++++
> >>  include/soc/bcm2835/raspberrypi-firmware.h         |   2 +
> >>  8 files changed, 360 insertions(+), 1 deletion(-)
> >>  create mode 100644 Documentation/devicetree/bindings/arm/bcm/raspberrypi,bcm2835-power.txt
> >>  create mode 100644 arch/arm/mach-bcm/raspberrypi-power.c
> >>  create mode 100644 include/dt-bindings/arm/raspberrypi-power.h
> >>
> >> --
> >> 2.6.2
> >>
> >
> > Besides a nitpick for patch2, I would also reverse the order of patch3
> > and patch2. DT docs should go in before the actual parsing of the new
> > bindings/compatibles.
> >
> > Anyway, for the hole series, you may add my:
> >
> > Reviewed-by: Ulf Hansson <ulf.hansson@linaro.org>
> 
> Would your tree be pulling the series (since it's power domains), or
> should I (since it's SOC stuff)?
> 

All of the above files go through the arm-soc tree by default.

	Arnd

Re: [PATCH v3 0/4] Raspberry Pi power domains

[Arnd Bergmann]

On Thursday 17 December 2015 11:03:47 Eric Anholt wrote:
> >>
> >>  .../bindings/arm/bcm/raspberrypi,bcm2835-power.txt |  47 ++++
> >>  arch/arm/boot/dts/bcm2835-rpi.dtsi                 |  11 +
> >>  arch/arm/boot/dts/bcm2835.dtsi                     |   2 +-
> >>  arch/arm/mach-bcm/Kconfig                          |  10 +
> >>  arch/arm/mach-bcm/Makefile                         |   1 +
> >>  arch/arm/mach-bcm/raspberrypi-power.c              | 247 +++++++++++++++++++++
> >>  include/dt-bindings/arm/raspberrypi-power.h        |  41 ++++
> >>  include/soc/bcm2835/raspberrypi-firmware.h         |   2 +
> >>  8 files changed, 360 insertions(+), 1 deletion(-)
> >>  create mode 100644 Documentation/devicetree/bindings/arm/bcm/raspberrypi,bcm2835-power.txt
> >>  create mode 100644 arch/arm/mach-bcm/raspberrypi-power.c
> >>  create mode 100644 include/dt-bindings/arm/raspberrypi-power.h
> >>
> >> --
> >> 2.6.2
> >>
> >
> > Besides a nitpick for patch2, I would also reverse the order of patch3
> > and patch2. DT docs should go in before the actual parsing of the new
> > bindings/compatibles.
> >
> > Anyway, for the hole series, you may add my:
> >
> > Reviewed-by: Ulf Hansson <ulf.hansson-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
> 
> Would your tree be pulling the series (since it's power domains), or
> should I (since it's SOC stuff)?
> 

All of the above files go through the arm-soc tree by default.

	Arnd
--
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

[PATCH v3 0/4] Raspberry Pi power domains

[Arnd Bergmann]

On Thursday 17 December 2015 11:03:47 Eric Anholt wrote:
> >>
> >>  .../bindings/arm/bcm/raspberrypi,bcm2835-power.txt |  47 ++++
> >>  arch/arm/boot/dts/bcm2835-rpi.dtsi                 |  11 +
> >>  arch/arm/boot/dts/bcm2835.dtsi                     |   2 +-
> >>  arch/arm/mach-bcm/Kconfig                          |  10 +
> >>  arch/arm/mach-bcm/Makefile                         |   1 +
> >>  arch/arm/mach-bcm/raspberrypi-power.c              | 247 +++++++++++++++++++++
> >>  include/dt-bindings/arm/raspberrypi-power.h        |  41 ++++
> >>  include/soc/bcm2835/raspberrypi-firmware.h         |   2 +
> >>  8 files changed, 360 insertions(+), 1 deletion(-)
> >>  create mode 100644 Documentation/devicetree/bindings/arm/bcm/raspberrypi,bcm2835-power.txt
> >>  create mode 100644 arch/arm/mach-bcm/raspberrypi-power.c
> >>  create mode 100644 include/dt-bindings/arm/raspberrypi-power.h
> >>
> >> --
> >> 2.6.2
> >>
> >
> > Besides a nitpick for patch2, I would also reverse the order of patch3
> > and patch2. DT docs should go in before the actual parsing of the new
> > bindings/compatibles.
> >
> > Anyway, for the hole series, you may add my:
> >
> > Reviewed-by: Ulf Hansson <ulf.hansson@linaro.org>
> 
> Would your tree be pulling the series (since it's power domains), or
> should I (since it's SOC stuff)?
> 

All of the above files go through the arm-soc tree by default.

	Arnd

Re: [PATCH v3 0/4] Raspberry Pi power domains

[Ulf Hansson]

On 17 December 2015 at 21:11, Arnd Bergmann <arnd@arndb.de> wrote:
> On Thursday 17 December 2015 11:03:47 Eric Anholt wrote:
>> >>
>> >>  .../bindings/arm/bcm/raspberrypi,bcm2835-power.txt |  47 ++++
>> >>  arch/arm/boot/dts/bcm2835-rpi.dtsi                 |  11 +
>> >>  arch/arm/boot/dts/bcm2835.dtsi                     |   2 +-
>> >>  arch/arm/mach-bcm/Kconfig                          |  10 +
>> >>  arch/arm/mach-bcm/Makefile                         |   1 +
>> >>  arch/arm/mach-bcm/raspberrypi-power.c              | 247 +++++++++++++++++++++
>> >>  include/dt-bindings/arm/raspberrypi-power.h        |  41 ++++
>> >>  include/soc/bcm2835/raspberrypi-firmware.h         |   2 +
>> >>  8 files changed, 360 insertions(+), 1 deletion(-)
>> >>  create mode 100644 Documentation/devicetree/bindings/arm/bcm/raspberrypi,bcm2835-power.txt
>> >>  create mode 100644 arch/arm/mach-bcm/raspberrypi-power.c
>> >>  create mode 100644 include/dt-bindings/arm/raspberrypi-power.h
>> >>
>> >> --
>> >> 2.6.2
>> >>
>> >
>> > Besides a nitpick for patch2, I would also reverse the order of patch3
>> > and patch2. DT docs should go in before the actual parsing of the new
>> > bindings/compatibles.
>> >
>> > Anyway, for the hole series, you may add my:
>> >
>> > Reviewed-by: Ulf Hansson <ulf.hansson@linaro.org>
>>
>> Would your tree be pulling the series (since it's power domains), or
>> should I (since it's SOC stuff)?
>>
>
> All of the above files go through the arm-soc tree by default.

That should work as I don't see any other dependency, unless
Eric/Alexander think there is.

Kind regards
Uffe

Re: [PATCH v3 0/4] Raspberry Pi power domains

[Ulf Hansson]

On 17 December 2015 at 21:11, Arnd Bergmann <arnd@arndb.de> wrote:
> On Thursday 17 December 2015 11:03:47 Eric Anholt wrote:
>> >>
>> >>  .../bindings/arm/bcm/raspberrypi,bcm2835-power.txt |  47 ++++
>> >>  arch/arm/boot/dts/bcm2835-rpi.dtsi                 |  11 +
>> >>  arch/arm/boot/dts/bcm2835.dtsi                     |   2 +-
>> >>  arch/arm/mach-bcm/Kconfig                          |  10 +
>> >>  arch/arm/mach-bcm/Makefile                         |   1 +
>> >>  arch/arm/mach-bcm/raspberrypi-power.c              | 247 +++++++++++++++++++++
>> >>  include/dt-bindings/arm/raspberrypi-power.h        |  41 ++++
>> >>  include/soc/bcm2835/raspberrypi-firmware.h         |   2 +
>> >>  8 files changed, 360 insertions(+), 1 deletion(-)
>> >>  create mode 100644 Documentation/devicetree/bindings/arm/bcm/raspberrypi,bcm2835-power.txt
>> >>  create mode 100644 arch/arm/mach-bcm/raspberrypi-power.c
>> >>  create mode 100644 include/dt-bindings/arm/raspberrypi-power.h
>> >>
>> >> --
>> >> 2.6.2
>> >>
>> >
>> > Besides a nitpick for patch2, I would also reverse the order of patch3
>> > and patch2. DT docs should go in before the actual parsing of the new
>> > bindings/compatibles.
>> >
>> > Anyway, for the hole series, you may add my:
>> >
>> > Reviewed-by: Ulf Hansson <ulf.hansson@linaro.org>
>>
>> Would your tree be pulling the series (since it's power domains), or
>> should I (since it's SOC stuff)?
>>
>
> All of the above files go through the arm-soc tree by default.

That should work as I don't see any other dependency, unless
Eric/Alexander think there is.

Kind regards
Uffe

[PATCH v3 0/4] Raspberry Pi power domains

[Ulf Hansson]

On 17 December 2015 at 21:11, Arnd Bergmann <arnd@arndb.de> wrote:
> On Thursday 17 December 2015 11:03:47 Eric Anholt wrote:
>> >>
>> >>  .../bindings/arm/bcm/raspberrypi,bcm2835-power.txt |  47 ++++
>> >>  arch/arm/boot/dts/bcm2835-rpi.dtsi                 |  11 +
>> >>  arch/arm/boot/dts/bcm2835.dtsi                     |   2 +-
>> >>  arch/arm/mach-bcm/Kconfig                          |  10 +
>> >>  arch/arm/mach-bcm/Makefile                         |   1 +
>> >>  arch/arm/mach-bcm/raspberrypi-power.c              | 247 +++++++++++++++++++++
>> >>  include/dt-bindings/arm/raspberrypi-power.h        |  41 ++++
>> >>  include/soc/bcm2835/raspberrypi-firmware.h         |   2 +
>> >>  8 files changed, 360 insertions(+), 1 deletion(-)
>> >>  create mode 100644 Documentation/devicetree/bindings/arm/bcm/raspberrypi,bcm2835-power.txt
>> >>  create mode 100644 arch/arm/mach-bcm/raspberrypi-power.c
>> >>  create mode 100644 include/dt-bindings/arm/raspberrypi-power.h
>> >>
>> >> --
>> >> 2.6.2
>> >>
>> >
>> > Besides a nitpick for patch2, I would also reverse the order of patch3
>> > and patch2. DT docs should go in before the actual parsing of the new
>> > bindings/compatibles.
>> >
>> > Anyway, for the hole series, you may add my:
>> >
>> > Reviewed-by: Ulf Hansson <ulf.hansson@linaro.org>
>>
>> Would your tree be pulling the series (since it's power domains), or
>> should I (since it's SOC stuff)?
>>
>
> All of the above files go through the arm-soc tree by default.

That should work as I don't see any other dependency, unless
Eric/Alexander think there is.

Kind regards
Uffe