Skip to contentSkip to conversation

ARM: bcm2835: add support for rpi power domain driver

PATCH Superseded Alexander Aring 5 participants 15 messages Nov 19, 2015 – Dec 4, 2015

Subsystems (10)
Device tree bindings Arm (32-bit) Arm sub-architectures Driver core +6 more subsystems

v1 of 2 Superseded Latest is v2 →

lore
Share & tools
lore

Alexander Aring

author
#0 lore raw

cover ARM: bcm2835: add support for rpi power domain driver

Hi,

this patch series contains at first a patch for the power domain subsystem which offers to uninit generic power domains when init was called before.

The RPi Power-Domains need to be enabled/disabled by interacting with the RPi firmware which can fail. To cleanup the probing we need to undo the power domains again which was registered before.

- Alex

changes since PATCH (was RFCv2 before):
- add WARN_ON_ONCE if there are still references from generic power domain inside the power domain subsystem when running pm_genpd_uninit.
- add mutex_destroy when running pm_genpd_uninit.
- split devicetree binding for rpi power domain driver into a separate patch.
- rename config RASPBERRY_POWER to RASPBERRYPI_POWER
- order list of <linux/...> includes alphabetical.
- use rpi_ prefix than raspberrypi_ prefix.
- rename _DT_BINDINGS_ARM_BCM2835_MBOX_POWER_H to _DT_BINDINGS_ARM_BCM2835_RPI_POWER_H

changes since RFCv2:
- add pm_genpd_uninit to handle probing failure.
- move power domain drive to his own driver in arch/arm/mach-bcm/ Also add own devicetree node for this driver, "raspberrypi,bcm2835-power".
- Removing all power domains which might exists for the firmware API but we currently have no use-case for it. I tried to keep the same domain numbering in generic power domains subsystem like they are offered from the firmware API. This works, all power_domains which are NULL inside the array of genpd_onecell_data.domains[#] will be ignored.
- Adding Eric Anholt and me to the authors.
- Creating devicetree documentation for the power domain driver.
- fix error handling in raspberrypi_firmware_set_power.
- Remove comment about mapping between power domains array, this is not necessary anymore. I add a "enabled" attribute to raspberrypi_power_domain which indicates if a domain should be registered or not (zeroed values does not indicate such handling, but enabled is false then).
- remove "goto mbox" not necessary anymore because an own driver implementation.
- Update devicetrees for changes in v2.

Alexander Aring (3):
power: domain: add pm_genpd_uninit
ARM: bcm2835: add rpi power domain driver
devicetree: add rpi power domain driver bindings

 .../bindings/arm/bcm/raspberrypi,bcm2835-power.txt |  25 +++
 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              | 180 +++++++++++++++++++++
 drivers/base/power/domain.c                        |  22 +++
 include/dt-bindings/arm/raspberrypi-power.h        |  14 ++
 include/linux/pm_domain.h                          |   4 +
 9 files changed, 268 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
Signature · 1 line
2.6.1
author
#1 lore raw

PATCH 1/3 power: domain: add pm_genpd_uninit

This patch adds function pm_genpd_uninit for undo a pm_genpd_init. This is useful for multiple power domains while probing. If the probing fails after one pm_genpd_init was called we need to undo all previous registrations of generic pm domains inside the gpd_list list.

There is a check on IS_ERR_OR_NULL(genpd) which is useful to check again registered power domains and not registered domains, the driver can use this mechanism to have an array with registered and non-registered power domains, where non-registered power domains are NULL.

Cc Rafael J. Wysocki <[email protected]>
Cc Kevin Hilman <[email protected]>
Cc Ulf Hansson <[email protected]>
Cc Pavel Machek <[email protected]>
Cc Len Brown <[email protected]>
Cc Greg Kroah-Hartman <[email protected]>
Signed-off-by Alexander Aring <[email protected]>
---
 drivers/base/power/domain.c | 22 ++++++++++++++++++++++
 include/linux/pm_domain.h   |  4 ++++
 2 files changed, 26 insertions(+)
drivers/base/power/domain.c +22 -0
index e03b1ad..24f54b8 100644
@@ -1509,6 +1509,28 @@ void pm_genpd_init(struct generic_pm_domain *genpd,
 }
 EXPORT_SYMBOL_GPL(pm_genpd_init);
 
+/**
+ * pm_genpd_uninit - Uninitialize a generic I/O PM domain object.
+ * @genpd: PM domain object to initialize.
+ */
+void pm_genpd_uninit(struct generic_pm_domain *genpd)
+{
+	if (IS_ERR_OR_NULL(genpd))
+		return;
+
+	/* check if domain is still in registered inside the pm subsystem */
+	WARN_ON_ONCE(!list_empty(&genpd->master_links) ||
+		     !list_empty(&genpd->slave_links) ||
+		     !list_empty(&genpd->dev_list));
+
+	mutex_lock(&gpd_list_lock);
+	list_del(&genpd->gpd_list_node);
+	mutex_unlock(&gpd_list_lock);
+
+	mutex_destroy(&genpd->lock);
+}
+EXPORT_SYMBOL_GPL(pm_genpd_uninit);
+
 #ifdef CONFIG_PM_GENERIC_DOMAINS_OF
 /*
  * Device Tree based PM domain providers.
include/linux/pm_domain.h +4 -0
index ba4ced3..df84a45 100644
@@ -123,6 +123,7 @@ extern int pm_genpd_remove_subdomain(struct generic_pm_domain *genpd,
 				     struct generic_pm_domain *target);
 extern void pm_genpd_init(struct generic_pm_domain *genpd,
 			  struct dev_power_governor *gov, bool is_off);
+extern void pm_genpd_uninit(struct generic_pm_domain *genpd);
 
 extern struct dev_power_governor simple_qos_governor;
 extern struct dev_power_governor pm_domain_always_on_gov;

@@ -161,6 +162,9 @@ static inline void pm_genpd_init(struct generic_pm_domain *genpd,
 				 struct dev_power_governor *gov, bool is_off)
 {
 }
+static inline void pm_genpd_uninit(struct generic_pm_domain *genpd)
+{
+}
 #endif
 
 static inline int pm_genpd_add_device(struct generic_pm_domain *genpd,
Signature · 1 line
2.6.1
#2 lore raw

PATCH 1/3 power: domain: add pm_genpd_uninit

Quoted 34 lines · Alexander Aring

This patch adds function pm_genpd_uninit for undo a pm_genpd_init. This is useful for multiple power domains while probing. If the probing fails after one pm_genpd_init was called we need to undo all previous registrations of generic pm domains inside the gpd_list list.

There is a check on IS_ERR_OR_NULL(genpd) which is useful to check again registered power domains and not registered domains, the driver can use this mechanism to have an array with registered and non-registered power domains, where non-registered power domains are NULL.

Cc Rafael J. Wysocki <[email protected]>
Cc Kevin Hilman <[email protected]>
Cc Ulf Hansson <[email protected]>
Cc Pavel Machek <[email protected]>
Cc Len Brown <[email protected]>
Cc Greg Kroah-Hartman <[email protected]>
Signed-off-by Alexander Aring <[email protected]>
---
 drivers/base/power/domain.c | 22 ++++++++++++++++++++++
 include/linux/pm_domain.h   |  4 ++++
 2 files changed, 26 insertions(+)
drivers/base/power/domain.c +4 -0
index e03b1ad..24f54b8 100644
@@ -1509,6 +1509,28 @@ void pm_genpd_init(struct generic_pm_domain *genpd,
 }
 EXPORT_SYMBOL_GPL(pm_genpd_init);
 
+/**
+ * pm_genpd_uninit - Uninitialize a generic I/O PM domain object.
+ * @genpd: PM domain object to initialize.
+ */

drivers/base/power/domain.c void pm_genpd_init(struct generic_pm_domain *genpd, · line 1525

Quoted 10 lines
drivers/base/power/domain.c +10 -0
+void pm_genpd_uninit(struct generic_pm_domain *genpd)
+{
+       if (IS_ERR_OR_NULL(genpd))
+               return;
+
+       /* check if domain is still in registered inside the pm subsystem */
+       WARN_ON_ONCE(!list_empty(&genpd->master_links) ||
+                    !list_empty(&genpd->slave_links) ||
+                    !list_empty(&genpd->dev_list));
+

We did discuss about verifying that the genpd mustn't have a corresponding DT provider. I do realize that it becomes a bit complex to verify that, unless we decide to add some handle to it within the genpd struct.

Anyway, perhaps this minimal effort is good enough as is. Especially since we won't be able to handle the error cases, besides giving a WARN.

Quoted 34 lines
drivers/base/power/domain.c +8 -0
+       mutex_lock(&gpd_list_lock);
+       list_del(&genpd->gpd_list_node);
+       mutex_unlock(&gpd_list_lock);
+
+       mutex_destroy(&genpd->lock);
+}
+EXPORT_SYMBOL_GPL(pm_genpd_uninit);
+
 #ifdef CONFIG_PM_GENERIC_DOMAINS_OF
 /*
  * Device Tree based PM domain providers.
include/linux/pm_domain.h +4 -1
index ba4ced3..df84a45 100644
@@ -123,6 +123,7 @@ extern int pm_genpd_remove_subdomain(struct generic_pm_domain *genpd,
                                     struct generic_pm_domain *target);
 extern void pm_genpd_init(struct generic_pm_domain *genpd,
                          struct dev_power_governor *gov, bool is_off);
+extern void pm_genpd_uninit(struct generic_pm_domain *genpd);
 
 extern struct dev_power_governor simple_qos_governor;
 extern struct dev_power_governor pm_domain_always_on_gov;

@@ -161,6 +162,9 @@ static inline void pm_genpd_init(struct generic_pm_domain *genpd,
                                 struct dev_power_governor *gov, bool is_off)
 {
 }
+static inline void pm_genpd_uninit(struct generic_pm_domain *genpd)
+{
+}
 #endif
 
 static inline int pm_genpd_add_device(struct generic_pm_domain *genpd,
--
Quoted 2 lines

2.6.1

So, I am fine with this, but let's see if other people have objections.

Acked-by Ulf Hansson <[email protected]>

Kind regards
Uffe

#3 lore raw

PATCH 1/3 power: domain: add pm_genpd_uninit

In reply to Alexander Aring
Quoted 33 lines · Alexander Aring

This patch adds function pm_genpd_uninit for undo a pm_genpd_init. This is useful for multiple power domains while probing. If the probing fails after one pm_genpd_init was called we need to undo all previous registrations of generic pm domains inside the gpd_list list.

There is a check on IS_ERR_OR_NULL(genpd) which is useful to check again registered power domains and not registered domains, the driver can use this mechanism to have an array with registered and non-registered power domains, where non-registered power domains are NULL.

Cc Rafael J. Wysocki <[email protected]>
Cc Kevin Hilman <[email protected]>
Cc Ulf Hansson <[email protected]>
Cc Pavel Machek <[email protected]>
Cc Len Brown <[email protected]>
Cc Greg Kroah-Hartman <[email protected]>
Signed-off-by Alexander Aring <[email protected]>
---
 drivers/base/power/domain.c | 22 ++++++++++++++++++++++
 include/linux/pm_domain.h   |  4 ++++
 2 files changed, 26 insertions(+)
drivers/base/power/domain.c +3 -0
index e03b1ad..24f54b8 100644
@@ -1509,6 +1509,28 @@ void pm_genpd_init(struct generic_pm_domain *genpd,
 }
 EXPORT_SYMBOL_GPL(pm_genpd_init);
 
+/**
+ * pm_genpd_uninit - Uninitialize a generic I/O PM domain object.
+ * @genpd: PM domain object to initialize.

drivers/base/power/domain.c void pm_genpd_init(struct generic_pm_domain *genpd, · line 1524

Quoted 10 lines
drivers/base/power/domain.c +10 -0
+ */
+void pm_genpd_uninit(struct generic_pm_domain *genpd)
+{
+	if (IS_ERR_OR_NULL(genpd))
+		return;
+
+	/* check if domain is still in registered inside the pm subsystem */
+	WARN_ON_ONCE(!list_empty(&genpd->master_links) ||
+		     !list_empty(&genpd->slave_links) ||
+		     !list_empty(&genpd->dev_list));

So we WARN if there are parents/children/devices, but shouldn't this return an error instead of continuing to remove/uninit the genpd?

The caller of _uninit should probably also be removing any parents/children and removing devices before calling _uninit, no?

drivers/base/power/domain.c void pm_genpd_init(struct generic_pm_domain *genpd, · line 1532

Quoted 7 lines
drivers/base/power/domain.c +7 -0
+	mutex_lock(&gpd_list_lock);
+	list_del(&genpd->gpd_list_node);
+	mutex_unlock(&gpd_list_lock);
+
+	mutex_destroy(&genpd->lock);
+}
+EXPORT_SYMBOL_GPL(pm_genpd_uninit);

Kevin

author
#4 lore raw

PATCH 2/3 ARM: bcm2835: add rpi power domain driver

In reply to Alexander Aring

This patch adds support for RPi several Power Domains and enable support to enable the USB Power Domain when it's not enabled before.

This patch based on Eric Anholt's patch to support Power Domains. He had an issue about -EPROBE_DEFER inside the power domain subsystem, this issue was solved by commit <311fa6a> ("PM / Domains: Return -EPROBE_DEFER if we fail to init or turn-on domain").

It was tested with barebox and the following scripts before booting linux:

/env/a_off:

 # cat /env/a_off
 #turn off which are enabled by default
 regulator -n bcm2835_mci0 -s disable
 regulator -n uart0-pl0110 -s disable

/env/a_on:

 # cat /env/a_on
 #turn off which are enabled by default
 regulator -n bcm2835_mci0 -s disable
 regulator -n uart0-pl0110 -s disable

regulator -n bcm2835_mci0 -s enable
regulator -n uart0-pl0110 -s enable
regulator -n uart0-pl0111 -s enable
regulator -n bcm2835_usb -s enable
regulator -n bcm2835_i2c0 -s enable
regulator -n bcm2835_i2c1 -s enable
regulator -n bcm2835_i2c2 -s enable
regulator -n bcm2835_spi -s enable
regulator -n bcm2835_ccp2tx -s enable
regulator -n bcm2835_dsi -s enable

/env/b:

 # cat /env/b
 sh /env/a_on

regulator -n bcm2835_mci0 -s disable
regulator -n uart0-pl0110 -s disable
regulator -n uart0-pl0111 -s disable
regulator -n bcm2835_usb -s disable
regulator -n bcm2835_i2c0 -s disable
regulator -n bcm2835_i2c1 -s disable
regulator -n bcm2835_i2c2 -s disable
regulator -n bcm2835_spi -s disable
regulator -n bcm2835_ccp2tx -s disable
regulator -n bcm2835_dsi -s disable

/env/c:

 # cat /env/c
 sh ./env/b

regulator -n bcm2835_mci0 -s enable
regulator -n uart0-pl0110 -s enable
regulator -n uart0-pl0111 -s enable
regulator -n bcm2835_usb -s enable
regulator -n bcm2835_i2c0 -s enable
regulator -n bcm2835_i2c1 -s enable
regulator -n bcm2835_i2c2 -s enable
regulator -n bcm2835_spi -s enable
regulator -n bcm2835_ccp2tx -s enable
regulator -n bcm2835_dsi -s enable

These scripts enables/disable all regulators inside the bootloader. It was running with a "hard" and "soft" reset without any issues. These testcases should fit to Stephen Warren suggestions:

"(a) before having explicitly turned the power domain on or off at all (b) after having turned it on (c) after having turned it off, and for all power domains."

Cc Stephen Warren <[email protected]>
Cc Lee Jones <[email protected]>
Cc Eric Anholt <[email protected]>
Signed-off-by Alexander Aring <[email protected]>
---
 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       | 180 ++++++++++++++++++++++++++++
 include/dt-bindings/arm/raspberrypi-power.h |  14 +++
 6 files changed, 217 insertions(+), 1 deletion(-)
 create mode 100644 arch/arm/mach-bcm/raspberrypi-power.c
 create mode 100644 include/dt-bindings/arm/raspberrypi-power.h
arch/arm/boot/dts/bcm2835-rpi.dtsi +11 -0
index 3572f03..f828202 100644
@@ -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>;
+};
arch/arm/boot/dts/bcm2835.dtsi +1 -1
index aef64de..6d62af0 100644
@@ -177,7 +177,7 @@
 			status = "disabled";
 		};
 
-		usb at 7e980000 {
+		usb: usb at 7e980000 {
 			compatible = "brcm,bcm2835-usb";
 			reg = <0x7e980000 0x10000>;
 			interrupts = <1 9>;
arch/arm/mach-bcm/Kconfig +10 -0
index 8c53c55..20479d7 100644
@@ -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
+	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
arch/arm/mach-bcm/Makefile +1 -0
index 892261f..fec2d6b 100644
@@ -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
arch/arm/mach-bcm/raspberrypi-power.c new file +180 -0

180 lines not on this page · raw message

include/dt-bindings/arm/raspberrypi-power.h new file +14 -0
new file mode 100644
index 0000000..c2ffbebc
@@ -0,0 +1,14 @@
+/*
+ *  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
+
+#define RPI_POWER_DOMAIN_USB	3
+
+#endif /* _DT_BINDINGS_ARM_BCM2835_RPI_POWER_H */
Signature · 1 line
2.6.1
#5 lore raw

PATCH 2/3 ARM: bcm2835: add rpi power domain driver

[...]

arch/arm/mach-bcm/Kconfig config ARCH_BCM2835 · line 137

Quoted 9 lines
arch/arm/mach-bcm/Kconfig +1 -0
index 8c53c55..20479d7 100644
@@ -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

You don't need a new Kconfig option I think. If you fold in the below "select" under ARCH_BCM2835, that should work as well, right?

select PM_GENERIC_DOMAINS if (RASPBERRYPI_FIRMWARE && PM && OF)

Quoted 17 lines
arch/arm/mach-bcm/Kconfig +9 -0
+       bool "Raspberry Pi power domain driver"
+       depends on ARCH_BCM2835
+       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
arch/arm/mach-bcm/Makefile +0 -0
index 892261f..fec2d6b 100644

arch/arm/mach-bcm/Makefile endif · line 39

Quoted 4 lines
arch/arm/mach-bcm/Makefile +1 -0
@@ -36,6 +36,7 @@ endif
 
 # BCM2835
 obj-$(CONFIG_ARCH_BCM2835)     += board_bcm2835.o
+obj-$(CONFIG_RASPBERRYPI_POWER)        += raspberrypi-power.o

According to above, then this should become:

obj-$(CONFIG_PM_GENERIC_DOMAINS) += raspberrypi-power.o

[...]

Kind regards
Uffe

author
#6 lore raw

PATCH 2/3 ARM: bcm2835: add rpi power domain driver

Hi,

Quoted 10 lines · Ulf Hansson

[...]

Quoted 8 lines
arch/arm/mach-bcm/Kconfig +0 -0
index 8c53c55..20479d7 100644
@@ -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.
Quoted 7 lines

arch/arm/mach-bcm/Kconfig config ARCH_BCM2835 · line 137

Quoted 1 line
arch/arm/mach-bcm/Kconfig +1 -0
+config RASPBERRYPI_POWER

You don't need a new Kconfig option I think. If you fold in the below "select" under ARCH_BCM2835, that should work as well, right?

select PM_GENERIC_DOMAINS if (RASPBERRYPI_FIRMWARE && PM && OF)

I think this depends on what the maintainers like to have here.

The raspberrypi firmware isn't BCM2835 specific, when some SoC which is BCM2835 and enabled the RASPBERRYPI_FIRMWARE (for what reason ever) it will enable also the power domain driver for the RPi.

When some BCM2835 enable it, then it will do nothing because the devicetree entries should not match then.

Quoted 18 lines
Quoted 18 lines
arch/arm/mach-bcm/Kconfig +9 -0
+       bool "Raspberry Pi power domain driver"
+       depends on ARCH_BCM2835
+       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
arch/arm/mach-bcm/Makefile +0 -0
index 892261f..fec2d6b 100644
@@ -36,6 +36,7 @@ endif
Quoted 8 lines

arch/arm/mach-bcm/Makefile endif · line 39

Quoted 3 lines
arch/arm/mach-bcm/Makefile +1 -0
 # BCM2835
 obj-$(CONFIG_ARCH_BCM2835)     += board_bcm2835.o
+obj-$(CONFIG_RASPBERRYPI_POWER)        += raspberrypi-power.o

According to above, then this should become:

obj-$(CONFIG_PM_GENERIC_DOMAINS) += raspberrypi-power.o

What about other BCM$FOOBAR arch's which might select/enables CONFIG_PM_GENERIC_DOMAINS somehow?

Like ARCH_BCM_63XX.

Possible other solution would be to make the CONFIG_RASPBERRYPI_POWER as a hidden entry inside Kconfig without a prompt.

Then it should look like this:

config RASPBERRYPI_POWER
bool
select PM_GENERIC_DOMAINS
select PM_GENERIC_DOMAINS_OF

config ARCH_BCM2835

	...
	select RASPBERRYPI_POWER if (RASPBERRYPI_FIRMWARE && PM && OF)
	...

and leave the Makefile as it is.

- Alex

#7 lore raw

PATCH 2/3 ARM: bcm2835: add rpi power domain driver

Quoted 21 lines · Alexander Aring

Hi,

Quoted 10 lines · Ulf Hansson

[...]

Quoted 8 lines
arch/arm/mach-bcm/Kconfig +0 -0
index 8c53c55..20479d7 100644
@@ -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.
Quoted 7 lines

arch/arm/mach-bcm/Kconfig config ARCH_BCM2835 · line 137

Quoted 1 line
arch/arm/mach-bcm/Kconfig +1 -0
+config RASPBERRYPI_POWER

You don't need a new Kconfig option I think. If you fold in the below "select" under ARCH_BCM2835, that should work as well, right?

select PM_GENERIC_DOMAINS if (RASPBERRYPI_FIRMWARE && PM && OF)

Quoted 8 lines

I think this depends on what the maintainers like to have here.

The raspberrypi firmware isn't BCM2835 specific, when some SoC which is BCM2835 and enabled the RASPBERRYPI_FIRMWARE (for what reason ever) it will enable also the power domain driver for the RPi.

When some BCM2835 enable it, then it will do nothing because the devicetree entries should not match then.

As far as I'm concerned, using the firmware is a stopgap to get other
drivers working, until we can get a native power domain driver written.
I think it makes sense for this code to be under its own menu entry, so
it can be flipped back off when we get the real thing in place.
-------------- 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/20151125/5a5f0a62/attachment.sig>

#8 lore raw

PATCH 2/3 ARM: bcm2835: add rpi power domain driver

In reply to Alexander Aring
Quoted 7 lines · Alexander Aring

This patch adds support for RPi several Power Domains and enable support to enable the USB Power Domain when it's not enabled before.

This patch based on Eric Anholt's patch to support Power Domains. He had an issue about -EPROBE_DEFER inside the power domain subsystem, this issue was solved by commit <311fa6a> ("PM / Domains: Return -EPROBE_DEFER if we fail to init or turn-on domain").

Glad to see you pick this up!

Quoted 60 lines

It was tested with barebox and the following scripts before booting linux:

/env/a_off:

 # cat /env/a_off
 #turn off which are enabled by default
 regulator -n bcm2835_mci0 -s disable
 regulator -n uart0-pl0110 -s disable

/env/a_on:

 # cat /env/a_on
 #turn off which are enabled by default
 regulator -n bcm2835_mci0 -s disable
 regulator -n uart0-pl0110 -s disable

regulator -n bcm2835_mci0 -s enable
regulator -n uart0-pl0110 -s enable
regulator -n uart0-pl0111 -s enable
regulator -n bcm2835_usb -s enable
regulator -n bcm2835_i2c0 -s enable
regulator -n bcm2835_i2c1 -s enable
regulator -n bcm2835_i2c2 -s enable
regulator -n bcm2835_spi -s enable
regulator -n bcm2835_ccp2tx -s enable
regulator -n bcm2835_dsi -s enable

/env/b:

 # cat /env/b
 sh /env/a_on

regulator -n bcm2835_mci0 -s disable
regulator -n uart0-pl0110 -s disable
regulator -n uart0-pl0111 -s disable
regulator -n bcm2835_usb -s disable
regulator -n bcm2835_i2c0 -s disable
regulator -n bcm2835_i2c1 -s disable
regulator -n bcm2835_i2c2 -s disable
regulator -n bcm2835_spi -s disable
regulator -n bcm2835_ccp2tx -s disable
regulator -n bcm2835_dsi -s disable

/env/c:

 # cat /env/c
 sh ./env/b

regulator -n bcm2835_mci0 -s enable
regulator -n uart0-pl0110 -s enable
regulator -n uart0-pl0111 -s enable
regulator -n bcm2835_usb -s enable
regulator -n bcm2835_i2c0 -s enable
regulator -n bcm2835_i2c1 -s enable
regulator -n bcm2835_i2c2 -s enable
regulator -n bcm2835_spi -s enable
regulator -n bcm2835_ccp2tx -s enable
regulator -n bcm2835_dsi -s enable

Quoted 7 lines

These scripts enables/disable all regulators inside the bootloader. It was running with a "hard" and "soft" reset without any issues. These testcases should fit to Stephen Warren suggestions:

"(a) before having explicitly turned the power domain on or off at all (b) after having turned it on (c) after having turned it off, and for all power domains."

I would drop this whole block from the commit message. It doesn't seem worth keeping associated with this code (though thanks for testing it!).

Quoted 4 lines
Cc Stephen Warren <[email protected]>
Cc Lee Jones <[email protected]>
Cc Eric Anholt <[email protected]>
Signed-off-by Alexander Aring <[email protected]>

If I'm going to be credited as an author, we should probably keep my:

Signed-off-by Eric Anholt <[email protected]>

It looks like you've mostly rewritten things, and there's not a whole lot of meat to this driver so I don't care about getting credit myself, but best not to give people reasons to be suspicious.

Quoted 10 lines
---
 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       | 180 ++++++++++++++++++++++++++++
 include/dt-bindings/arm/raspberrypi-power.h |  14 +++
 6 files changed, 217 insertions(+), 1 deletion(-)
 create mode 100644 arch/arm/mach-bcm/raspberrypi-power.c
 create mode 100644 include/dt-bindings/arm/raspberrypi-power.h

To merge the patch, the .dtsi changes need to be in a separate commit which I would pick up in the dt branch. I'm hoping Ulf or another PM domains maintainer would be able to pick up the Kconfig/Makefile/.c patch in their tree, so it can be queued after the uninit function change. If they won't, then it would go through my tree, but still on a different branch from DT changes.

This is the only thing I see needing to change before I can Ack.

Quoted 11 lines
arch/arm/mach-bcm/Kconfig +3 -0
index 8c53c55..20479d7 100644
@@ -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

arch/arm/mach-bcm/Kconfig config ARCH_BCM2835 · line 149

Quoted 10 lines
arch/arm/mach-bcm/Kconfig +7 -0
+	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

I'd love to have this be "depends on ARCH_BCM2835 || COMPILE_TEST" --
that gets us better coverage from automated builders in -next.
-------------- 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/20151124/eecdb336/attachment.sig>

#9 lore raw

PATCH 2/3 ARM: bcm2835: add rpi power domain driver

In reply to Alexander Aring
Quoted 7 lines · Alexander Aring

This patch adds support for RPi several Power Domains and enable support to enable the USB Power Domain when it's not enabled before.

This patch based on Eric Anholt's patch to support Power Domains. He had an issue about -EPROBE_DEFER inside the power domain subsystem, this issue was solved by commit <311fa6a> ("PM / Domains: Return -EPROBE_DEFER if we fail to init or turn-on domain").

[...]

arch/arm/mach-bcm/raspberrypi-power.c line 19

Quoted 2 lines
arch/arm/mach-bcm/raspberrypi-power.c new file +2 -0
+#define RPI_POWER_DOMAIN(_domain, _name)			\
+	[_domain] = {						\

Using _domain as the array index is going to create a sparsely filled
array here, wasting memory. I'm not sure what the other domain numbers
are for other domains to know if this is a big waste or not, but it's still a bit wasteful.

In any case, AFAICT, it doesn't look like you need to have the array index match the domain number anyways since you're using container_of().

So I suggest just removing this array index part, and just creating them in arrary order. Then your _probe function isn't going to try to setup 3 non-enabled domains before it finally hits the USB domain.

Kevin

author
#10 lore raw

PATCH 2/3 ARM: bcm2835: add rpi power domain driver

Hi,

Quoted 20 lines · Kevin Hilman
Quoted 7 lines · Alexander Aring

This patch adds support for RPi several Power Domains and enable support to enable the USB Power Domain when it's not enabled before.

This patch based on Eric Anholt's patch to support Power Domains. He had an issue about -EPROBE_DEFER inside the power domain subsystem, this issue was solved by commit <311fa6a> ("PM / Domains: Return -EPROBE_DEFER if we fail to init or turn-on domain").

[...]

arch/arm/mach-bcm/raspberrypi-power.c line 19

Quoted 2 lines
arch/arm/mach-bcm/raspberrypi-power.c new file +2 -0
+#define RPI_POWER_DOMAIN(_domain, _name)			\
+	[_domain] = {						\

Using _domain as the array index is going to create a sparsely filled
array here, wasting memory. I'm not sure what the other domain numbers
are for other domains to know if this is a big waste or not, but it's still a bit wasteful.

Quoted 7 lines

In any case, AFAICT, it doesn't look like you need to have the array index match the domain number anyways since you're using container_of().

So I suggest just removing this array index part, and just creating them in arrary order. Then your _probe function isn't going to try to setup 3 non-enabled domains before it finally hits the USB domain.

The idea is here to keeping the _same_ power domains indexes for device-tree power domain API like the RPi firmware provides it.

If somebody dumps the devicetree and see the power domain index, if he/she does then a firmware API power domain index mapping it is wrong. Because we need then a separate mapping:

$ARRAY_DEFINED_INDEX <-> $RPI_FIRMWARE_POWER_DOMAIN_API_INDEX

With the current solution to make a 1:1 mapping it there is no confusing anymore, because:

$ARRAY_DEFINED_INDEX == $RPI_FIRMWARE_POWER_DOMAIN_API_INDEX

Also there exists power domains 1-10 (so far I know), 1-2 are currently not used (and dummy-calls inside the rpi firmware implementation). So later they should be provided anyway.

There exists a little improvement to let the for (i = 0; i < num_domains ...) start@"i = 1", the entry with index "0" will be a waste of memory then and it's not provided by the firmware API as a power domain.

These are my arguments to keeping the current way of registering power domains, if you still want that I should change it then I will do it or maybe I show here some "good" arguments here to keeping this behaviour.

Please let me know. Thanks.

- Alex

#11 lore raw

PATCH 2/3 ARM: bcm2835: add rpi power domain driver

Quoted 38 lines · Alexander Aring

Hi,

Quoted 20 lines · Kevin Hilman
Quoted 7 lines · Alexander Aring

This patch adds support for RPi several Power Domains and enable support to enable the USB Power Domain when it's not enabled before.

This patch based on Eric Anholt's patch to support Power Domains. He had an issue about -EPROBE_DEFER inside the power domain subsystem, this issue was solved by commit <311fa6a> ("PM / Domains: Return -EPROBE_DEFER if we fail to init or turn-on domain").

[...]

arch/arm/mach-bcm/raspberrypi-power.c line 19

Quoted 2 lines
arch/arm/mach-bcm/raspberrypi-power.c new file +2 -0
+#define RPI_POWER_DOMAIN(_domain, _name)			\
+	[_domain] = {						\

Using _domain as the array index is going to create a sparsely filled
array here, wasting memory. I'm not sure what the other domain numbers
are for other domains to know if this is a big waste or not, but it's still a bit wasteful.

Quoted 7 lines

In any case, AFAICT, it doesn't look like you need to have the array index match the domain number anyways since you're using container_of().

So I suggest just removing this array index part, and just creating them in arrary order. Then your _probe function isn't going to try to setup 3 non-enabled domains before it finally hits the USB domain.

The idea is here to keeping the _same_ power domains indexes for device-tree power domain API like the RPi firmware provides it.

If somebody dumps the devicetree and see the power domain index, if he/she does then a firmware API power domain index mapping it is wrong. Because we need then a separate mapping:

Quoted 6 lines

$ARRAY_DEFINED_INDEX <-> $RPI_FIRMWARE_POWER_DOMAIN_API_INDEX

With the current solution to make a 1:1 mapping it there is no confusing anymore, because:

$ARRAY_DEFINED_INDEX == $RPI_FIRMWARE_POWER_DOMAIN_API_INDEX

I'm not proposing to change the DT numbers or the firmware numbers. All I'm proposing is that those numbers don't need to be mapped to the array index. IOW, in your structure definition macro:

+#define RPI_POWER_DOMAIN(_domain, _name) \
+ [_domain] = { \
+ .domain = _domain, \
[...]

just drop the " [_domain] = { " line.

Quoted 3 lines

Also there exists power domains 1-10 (so far I know), 1-2 are currently not used (and dummy-calls inside the rpi firmware implementation). So later they should be provided anyway.

They could then be added in any order in the struture.

Quoted 3 lines

There exists a little improvement to let the for (i = 0; i < num_domains ...) start at "i = 1", the entry with index "0" will be a waste of memory then and it's not provided by the firmware API as a power domain.

Even index 0 will not be wasted with the above approach.

Kevin

author
#12 lore raw

PATCH 2/3 ARM: bcm2835: add rpi power domain driver

Hi,

Meanwhile there exists a new RPi firmware with a new interface to setup power domains. Eric Anholt already did some work to access new interface and old one based on this patch.

The next days he want to sent this new driver mainline, I will stop the work now.

I will add some review notes anyway, maybe Eric Anholt can pick them up.

Quoted 56 lines · Kevin Hilman
Quoted 38 lines · Alexander Aring

Hi,

Quoted 20 lines · Kevin Hilman
Quoted 7 lines · Alexander Aring

This patch adds support for RPi several Power Domains and enable support to enable the USB Power Domain when it's not enabled before.

This patch based on Eric Anholt's patch to support Power Domains. He had an issue about -EPROBE_DEFER inside the power domain subsystem, this issue was solved by commit <311fa6a> ("PM / Domains: Return -EPROBE_DEFER if we fail to init or turn-on domain").

[...]

arch/arm/mach-bcm/raspberrypi-power.c line 19

Quoted 2 lines
arch/arm/mach-bcm/raspberrypi-power.c new file +2 -0
+#define RPI_POWER_DOMAIN(_domain, _name)			\
+	[_domain] = {						\

Using _domain as the array index is going to create a sparsely filled
array here, wasting memory. I'm not sure what the other domain numbers
are for other domains to know if this is a big waste or not, but it's still a bit wasteful.

Quoted 7 lines

In any case, AFAICT, it doesn't look like you need to have the array index match the domain number anyways since you're using container_of().

So I suggest just removing this array index part, and just creating them in arrary order. Then your _probe function isn't going to try to setup 3 non-enabled domains before it finally hits the USB domain.

The idea is here to keeping the _same_ power domains indexes for device-tree power domain API like the RPi firmware provides it.

If somebody dumps the devicetree and see the power domain index, if he/she does then a firmware API power domain index mapping it is wrong. Because we need then a separate mapping:

Quoted 6 lines

$ARRAY_DEFINED_INDEX <-> $RPI_FIRMWARE_POWER_DOMAIN_API_INDEX

With the current solution to make a 1:1 mapping it there is no confusing anymore, because:

$ARRAY_DEFINED_INDEX == $RPI_FIRMWARE_POWER_DOMAIN_API_INDEX

I'm not proposing to change the DT numbers or the firmware numbers. All I'm proposing is that those numbers don't need to be mapped to the array index. IOW, in your structure definition macro:

arch/arm/mach-bcm/raspberrypi-power.c new file +3 -0
+#define RPI_POWER_DOMAIN(_domain, _name)			\
+	[_domain] = {						\
+		.domain = _domain,				\
[...]
Quoted 2 lines

just drop the " [_domain] = { " line.

This requires additional changes. We need to know the "maximum" registered index value of RPi power domain.

Because the dynamic allocating array of (linux) power domains, which we determine by:

... num_domains = ARRAY_SIZE(rpi_power_domains);

The RPi power domain defines are also used by devicetree. Usually I would change it to an enum with a MAX_ATTR entry, which is not possible because devicetree compiler can't deal with enums.

Anyway we could determine the max registered RPi power domain index by doing something like:

num_domains = 0;

for (i = 0; i < ARRAY_SIZE(rpi_power_domains); i++)

	max(num_domains, array[i].domain);

- Alex

author
#13 lore raw

PATCH 3/3 devicetree: add rpi power domain driver bindings

In reply to Alexander Aring

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

Signed-off-by Alexander Aring <[email protected]>
---
 .../bindings/arm/bcm/raspberrypi,bcm2835-power.txt | 25 ++++++++++++++++++++++
 1 file changed, 25 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/arm/bcm/raspberrypi,bcm2835-power.txt
Documentation/devicetree/bindings/arm/bcm/raspberrypi,bcm2835-power.txt new file +25 -0
new file mode 100644
index 0000000..c3abc24
@@ -0,0 +1,25 @@
+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_USB
+
+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>;
+};
Signature · 1 line
2.6.1
maintainer
#14 lore raw

PATCH 3/3 devicetree: add rpi power domain driver bindings

Quoted 4 lines · Alexander Aring

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]>
Quoted 39 lines
---
 .../bindings/arm/bcm/raspberrypi,bcm2835-power.txt | 25 ++++++++++++++++++++++
 1 file changed, 25 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/arm/bcm/raspberrypi,bcm2835-power.txt
Documentation/devicetree/bindings/arm/bcm/raspberrypi,bcm2835-power.txt new file +25 -0
new file mode 100644
index 0000000..c3abc24
@@ -0,0 +1,25 @@
+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_USB
+
+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>;
+};
Signature · 1 line
2.6.1