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
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 <[email protected]>
---
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
From: Alexander Aring <[email protected]>
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 <[email protected]>
Signed-off-by: Eric Anholt <[email protected]>
---
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 <[email protected]>
+ *
+ * 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 <[email protected]>
+ * Eric Anholt <[email protected]>
+ */
+
+#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 <[email protected]>");
+MODULE_AUTHOR("Eric Anholt <[email protected]>");
+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
From: Alexander Aring <[email protected]>
This patch adds devicetree tree bindings for the Raspberry Pi power
domain driver.
Signed-off-by: Alexander Aring <[email protected]>
Acked-by: Rob Herring <[email protected]>
Signed-off-by: Eric Anholt <[email protected]>
---
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
From: Alexander Aring <[email protected]>
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 <[email protected]>
Signed-off-by: Eric Anholt <[email protected]>
---
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
On 15/12/15 13:40, Eric Anholt wrote:
> From: Alexander Aring <[email protected]>
>
> 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 <[email protected]>
> Signed-off-by: Eric Anholt <[email protected]>
> ---
>
> 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
Florian Fainelli <[email protected]> writes:
> On 15/12/15 13:40, Eric Anholt wrote:
>> From: Alexander Aring <[email protected]>
>>
>> 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 <[email protected]>
>> Signed-off-by: Eric Anholt <[email protected]>
>> ---
>>
>> 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.
On 15/12/15 15:55, Eric Anholt wrote:
> Florian Fainelli <[email protected]> writes:
>
>> On 15/12/15 13:40, Eric Anholt wrote:
>>> From: Alexander Aring <[email protected]>
>>>
>>> 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 <[email protected]>
>>> Signed-off-by: Eric Anholt <[email protected]>
>>> ---
>>>
>>> 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
Florian Fainelli <[email protected]> writes:
> On 15/12/15 15:55, Eric Anholt wrote:
>> Florian Fainelli <[email protected]> writes:
>>
>>> On 15/12/15 13:40, Eric Anholt wrote:
>>>> From: Alexander Aring <[email protected]>
>>>>
>>>> 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 <[email protected]>
>>>> Signed-off-by: Eric Anholt <[email protected]>
>>>> ---
>>>>
>>>> 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.
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
2015-12-16 10:11 GMT+09:00 Sebastian Reichel <[email protected]>:
> 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
On 16 December 2015 at 02:27, Krzysztof Kozlowski
<[email protected]> wrote:
> 2015-12-16 10:11 GMT+09:00 Sebastian Reichel <[email protected]>:
>> 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
Ulf Hansson <[email protected]> writes:
> On 16 December 2015 at 02:27, Krzysztof Kozlowski
> <[email protected]> wrote:
>> 2015-12-16 10:11 GMT+09:00 Sebastian Reichel <[email protected]>:
>>> 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/.
On 15 December 2015 at 22:40, Eric Anholt <[email protected]> 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 <[email protected]>
Kind regards
Uffe
Ulf Hansson <[email protected]> writes:
> On 15 December 2015 at 22:40, Eric Anholt <[email protected]> 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 <[email protected]>
Would your tree be pulling the series (since it's power domains), or
should I (since it's SOC stuff)?
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 <[email protected]>
>
> 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
On 17 December 2015 at 21:11, Arnd Bergmann <[email protected]> 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 <[email protected]>
>>
>> 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