rpi: add support to enable usb power domain

RFC In review Alexander Aring 3 participants 6 messages Oct 28, 2015 – Nov 17, 2015

Subsystems (3)

Device tree bindings Broadcom BCM2711/BCM2835 Arm architecture Broadcom BCM281XX/BCM11XXX/BCM216XX Arm architecture

lore

Share & tools

lore

Alexander Aring

author

2015-10-28 20:40 UTC #0 lore raw

RFC 1/1 rpi: add support to enable usb power domain

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

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

Cc Andy Whitcroft <[email protected]>

Cc Joe Perches <[email protected]>

Signed-off-by Alexander Aring <[email protected]>

---
First:
I cc'ed Andy Whitcroft and Joe Perches here, because this patch will generate a false positive for checkpatch and checkpatch told me to cc checkpatch maintainers if this occurs:

ERROR: Macros with complex values should be enclosed in parentheses #191: FILE: drivers/firmware/raspberrypi.c:26:
+#define RPI_POWER_DOMAIN(_domain, _name) \
+ [_domain] = \
+ { \
...

Second:
This patch based on linus/master and requires the rpi-firmware patch.

Third:
The barebox regulator doesn't support right now to enable/disable regulators at runtime but I want to bring this mainline in the next days. So you can't check yourself if the above scripts working right now. I describe it here to show you what exactly I tested.

changes since Eric Anholts "power domain" patch:
- add for me all known power domains of the RPi, it contains the domains 0 - 9.
- Add devicetree documentation.
- move implementation to drivers/firmware/... (also Kconfig dependencies)
- add macro RPI_POWER_DOMAIN.
- add function "raspberrypi_firmware_power_is_on" to get the initial value for a "power domain", which can be assign over the "is_off" parameter, while power domain init.
- Put generic_pm_domain on the heap with amount of entries which comes from ARRAY_SIZE(rpi_power_domains). So we don't need to care about both arrays anymore. But only works so far rpi_power_domains has not empty entries in the middle. I added a note about that, if it's too ugly I will remove it or accept other solutions. Maybe make rpi_power_domains as double pointer (and care about NULL entries, anyway. It should working and I think there are no other domains and if there are other domains and we have missing entries then something is wrong.

Notes:

I wonder myself when I disable domain 0 (SDHC) I can still access the card, as well uart is also still working after turn off power.

 .../arm/bcm/raspberrypi,bcm2835-firmware.txt       |  15 +++
 arch/arm/boot/dts/bcm2835-rpi.dtsi                 |   6 +
 arch/arm/boot/dts/bcm2835.dtsi                     |   2 +-
 drivers/firmware/Kconfig                           |   2 +
 drivers/firmware/raspberrypi.c                     | 133 +++++++++++++++++++++
 .../dt-bindings/arm/raspberrypi-firmware-power.h   |  23 ++++
 6 files changed, 180 insertions(+), 1 deletion(-)
 create mode 100644 include/dt-bindings/arm/raspberrypi-firmware-power.h

Documentation/devicetree/bindings/arm/bcm/raspberrypi,bcm2835-firmware.txt +15 -0

index 6824b31..2727ca16 100644
@@ -5,10 +5,25 @@ Required properties:
 - compatible:		Should be "raspberrypi,bcm2835-firmware"
 - mboxes:		Phandle to the firmware device's Mailbox.
 			  (See: ../mailbox/mailbox.txt for more information)
+- #power-domain-cells:	Should be <1>, we providing multiple power domains.
+
+The valid defines for power domain are:
+
+ RPI_POWER_DOMAIN_SDCARD, RPI_POWER_DOMAIN_UART0, RPI_POWER_DOMAIN_UART1,
+ RPI_POWER_DOMAIN_USB, RPI_POWER_DOMAIN_I2C0, RPI_POWER_DOMAIN_I2C1,
+ RPI_POWER_DOMAIN_I2C2, RPI_POWER_DOMAIN_SPI, RPI_POWER_DOMAIN_CCP2TX,
+ RPI_POWER_DOMAIN_DSI
 
 Example:
 
 firmware {
 	compatible = "raspberrypi,bcm2835-firmware";
 	mboxes = <&mailbox>;
+	#power-domain-cells = <1>;
+};
+
+Example for using power domain:
+
+&usb {
+       power-domains = <&firmware RPI_POWER_DOMAIN_USB>;
 };

arch/arm/boot/dts/bcm2835-rpi.dtsi +6 -0

index ab5474e..7f19352 100644
@@ -1,3 +1,4 @@
+#include <dt-bindings/arm/raspberrypi-firmware-power.h>
 #include "bcm2835.dtsi"
 
 / {

@@ -19,6 +20,7 @@
 		firmware: firmware {
 			compatible = "raspberrypi,bcm2835-firmware";
 			mboxes = <&mailbox>;
+			#power-domain-cells = <1>;
 		};
 	};
 };

@@ -56,3 +58,7 @@
 	status = "okay";
 	bus-width = <4>;
 };
+
+&usb {
+	power-domains = <&firmware RPI_POWER_DOMAIN_USB>;
+};

arch/arm/boot/dts/bcm2835.dtsi +1 -1

index 301c73f..3c899b3 100644
@@ -149,7 +149,7 @@
 			status = "disabled";
 		};
 
-		usb at 7e980000 {
+		usb: usb at 7e980000 {
 			compatible = "brcm,bcm2835-usb";
 			reg = <0x7e980000 0x10000>;
 			interrupts = <1 9>;

drivers/firmware/Kconfig +2 -0

index 7181126..8981599 100644
@@ -150,6 +150,8 @@ config QCOM_SCM_64
 config RASPBERRYPI_FIRMWARE
 	tristate "Raspberry Pi Firmware Driver"
 	depends on BCM2835_MBOX
+	select PM_GENERIC_DOMAINS if PM
+	select PM_GENERIC_DOMAINS_OF if PM
 	help
 	  This option enables support for communicating with the firmware on the
 	  Raspberry Pi.

drivers/firmware/raspberrypi.c +133 -0

183 lines not on this page · raw message

include/dt-bindings/arm/raspberrypi-firmware-power.h new file +23 -0

new file mode 100644
index 0000000..c363a1f
@@ -0,0 +1,23 @@
+/*
+ *  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_MBOX_POWER_H
+#define _DT_BINDINGS_ARM_BCM2835_MBOX_POWER_H
+
+#define RPI_POWER_DOMAIN_SDCARD	0
+#define RPI_POWER_DOMAIN_UART0	1
+#define RPI_POWER_DOMAIN_UART1	2
+#define RPI_POWER_DOMAIN_USB	3
+#define RPI_POWER_DOMAIN_I2C0	4
+#define RPI_POWER_DOMAIN_I2C1	5
+#define RPI_POWER_DOMAIN_I2C2	6
+#define RPI_POWER_DOMAIN_SPI	7
+#define RPI_POWER_DOMAIN_CCP2TX	8
+#define RPI_POWER_DOMAIN_DSI	9
+
+#endif /* _DT_BINDINGS_ARM_BCM2835_MBOX_POWER_H */

Signature · 1 line

2.6.1

Stephen Warren

2015-10-29 04:32 UTC #1 lore raw

Quoted 9 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").

Documentation/devicetree/bindings/arm/bcm/raspberrypi,bcm2835-firmware.txt Required properties: · line 23

Quoted 6 lines

Documentation/devicetree/bindings/arm/bcm/raspberrypi,bcm2835-firmware.txt +2 -0
 
 firmware {
 	compatible = "raspberrypi,bcm2835-firmware";
 	mboxes = <&mailbox>;
+	#power-domain-cells = <1>;
+};

I would have expected a separate DT node for the power domains driver that referenced the firmware node by phandle. I believe that's why the firmware node exports mailboxes to other drivers. If the firmware driver was going to implement all the features directly, it wouldn't need to act as a mailbox provider, since all the mailbox programming would be internal.

drivers/firmware/raspberrypi.c line 28

Quoted 5 lines

drivers/firmware/raspberrypi.c +3 -0

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

I'd expect { wrapped onto the previous line.

drivers/firmware/raspberrypi.c rpi_firmware_print_firmware_revision(struct rpi_firmware *fw) · line 226

Quoted 8 lines

drivers/firmware/raspberrypi.c +7 -0

+static int raspberrypi_firmware_set_power(struct rpi_firmware *fw,
+					  u32 domain, bool on)
 
+	packet.on = on;
+	ret = rpi_firmware_property(fw, RPI_FIRMWARE_SET_POWER_STATE, &packet,
+				    sizeof(packet));
+	if (!ret && !packet.on)
+		ret = -EINVAL;

The error is only reported for power off requests?

drivers/firmware/raspberrypi.c rpi_firmware_print_firmware_revision(struct rpi_firmware *fw) · line 242

Quoted 9 lines

drivers/firmware/raspberrypi.c +8 -0

+/* Asks the firmware to if power is on for a specific power domain. */
+static int raspberrypi_firmware_power_is_on(struct rpi_firmware *fw,
+					    u32 domain)
 
+	packet.domain = domain;
+	ret = rpi_firmware_property(fw, RPI_FIRMWARE_GET_POWER_STATE, &packet,
+				    sizeof(packet));
+	if (ret < 0)
+		return ret;

Hmm. If rpi_firmware_property() returns <0 on error, I'm confused what the test I commented on above is intended to do.

Quoted 5 lines

+/*
+ * IMPORTANT: be sure this array has no entries which are not specified
+ * between others by RPI_POWER_DOMAIN, otherwise mapping between
+ * generic_pm_domain array doesn't work anymore.
+ */

"has no entries which are not specified between others by RPI_POWER_DOMAIN" might be better phrased as "is contiguous" or "contains only contiguous entries".

drivers/firmware/raspberrypi.c static int rpi_firmware_probe(struct platform_device *pdev) · line 322

Quoted 12 lines

drivers/firmware/raspberrypi.c +10 -0

@@ -208,15 +312,44 @@ static int rpi_firmware_probe(struct platform_device *pdev)
 
+	for (i = 0; i < num_domains; i++) {
+		bool is_off;
+
+		rpi_power_domains[i].fw = fw;
+		power_domains[i] = &rpi_power_domains[i].base;
+
+		/* get the initial state */
+		ret = raspberrypi_firmware_power_is_on(fw, i);
+		if (ret < 0)
+			goto mbox;

The label name "mbox" doesn't give a clue that it's an error handler. "free_mbox" might be better.

drivers/firmware/raspberrypi.c static int rpi_firmware_probe(struct platform_device *pdev) · line 345

Quoted 4 lines

drivers/firmware/raspberrypi.c +3 -0
+mbox:
+	mbox_free_channel(fw->chan);
+	return ret;
 }

Does the pm_genpd_init() call for all the power domains need to be undone at all?

Alexander Aring

author

2015-11-02 09:02 UTC #2 lore raw

Quoted 11 lines · Stephen Warren

Quoted 9 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").
Documentation/devicetree/bindings/arm/bcm/raspberrypi,bcm2835-firmware.txt +0 -0

Quoted 13 lines

Documentation/devicetree/bindings/arm/bcm/raspberrypi,bcm2835-firmware.txt Required properties: · line 23
Quoted 5 lines
firmware {
Documentation/devicetree/bindings/arm/bcm/raspberrypi,bcm2835-firmware.txt +2 -0
 	compatible = "raspberrypi,bcm2835-firmware";
 	mboxes = <&mailbox>;
+	#power-domain-cells = <1>;
+};
I would have expected a separate DT node for the power domains driver that referenced the firmware node by phandle. I believe that's why the firmware node exports mailboxes to other drivers. If the firmware driver was going to implement all the features directly, it wouldn't need to act as a mailbox provider, since all the mailbox programming would be internal.

ok.

Quoted 8 lines

drivers/firmware/raspberrypi.c line 28
Quoted 5 lines
drivers/firmware/raspberrypi.c +3 -0
 
+#define RPI_POWER_DOMAIN(_domain, _name)			\
+	[_domain] =						\
+	{							\
I'd expect { wrapped onto the previous line.

ok.

Quoted 11 lines

drivers/firmware/raspberrypi.c rpi_firmware_print_firmware_revision(struct rpi_firmware *fw) · line 226
Quoted 8 lines
drivers/firmware/raspberrypi.c +7 -0
+static int raspberrypi_firmware_set_power(struct rpi_firmware *fw,
+					  u32 domain, bool on)
 
+	packet.on = on;
+	ret = rpi_firmware_property(fw, RPI_FIRMWARE_SET_POWER_STATE, &packet,
+				    sizeof(packet));
+	if (!ret && !packet.on)
+		ret = -EINVAL;
The error is only reported for power off requests?

grab it from old patch. I will fix that, I suppose it should something like:

if (!ret && packet.on != on)

	ret = -EINVAL;

to confirm if packet.on is set or unset afterwards. I don't know if this is a valid error reporting mechanism from firmware.

I will drop such checking here.

Quoted 4 lines

Quoted 3 lines

drivers/firmware/raspberrypi.c +3 -0

+/* Asks the firmware to if power is on for a specific power domain. */
+static int raspberrypi_firmware_power_is_on(struct rpi_firmware *fw,
+					    u32 domain)

Quoted 9 lines

drivers/firmware/raspberrypi.c rpi_firmware_print_firmware_revision(struct rpi_firmware *fw) · line 242
Quoted 5 lines
drivers/firmware/raspberrypi.c +5 -0
+	packet.domain = domain;
+	ret = rpi_firmware_property(fw, RPI_FIRMWARE_GET_POWER_STATE, &packet,
+				    sizeof(packet));
+	if (ret < 0)
+		return ret;
Hmm. If rpi_firmware_property() returns <0 on error, I'm confused what the test I commented on above is intended to do.

yes, I will fix it.

Quoted 10 lines

Quoted 5 lines
+/*
+ * IMPORTANT: be sure this array has no entries which are not specified
+ * between others by RPI_POWER_DOMAIN, otherwise mapping between
+ * generic_pm_domain array doesn't work anymore.
+ */
"has no entries which are not specified between others by RPI_POWER_DOMAIN" might be better phrased as "is contiguous" or "contains only contiguous entries".

Okay, Eric Anholt told me to support the power domains which he had in his patch only. I would add add the power domains only which has an use-case -> "USB".

Quoted 16 lines

drivers/firmware/raspberrypi.c static int rpi_firmware_probe(struct platform_device *pdev) · line 322
Quoted 12 lines
drivers/firmware/raspberrypi.c +10 -0
@@ -208,15 +312,44 @@ static int rpi_firmware_probe(struct platform_device *pdev)
 
+	for (i = 0; i < num_domains; i++) {
+		bool is_off;
+
+		rpi_power_domains[i].fw = fw;
+		power_domains[i] = &rpi_power_domains[i].base;
+
+		/* get the initial state */
+		ret = raspberrypi_firmware_power_is_on(fw, i);
+		if (ret < 0)
+			goto mbox;
The label name "mbox" doesn't give a clue that it's an error handler. "free_mbox" might be better.

ok.

Quoted 7 lines

drivers/firmware/raspberrypi.c static int rpi_firmware_probe(struct platform_device *pdev) · line 345
Quoted 4 lines
drivers/firmware/raspberrypi.c +3 -0
+mbox:
+	mbox_free_channel(fw->chan);
+	return ret;
 }
Does the pm_genpd_init() call for all the power domains need to be undone at all?

I would say yes. The function will call:

list_add(&genpd->gpd_list_node, &gpd_list);

And gpd_list is a _static_ list inside the generic power domain subsystem. If probing fails we need to delete these entries from gpd_list again.

I searched the whole file about "gpd_list_node" and can't find a list_del on it. :-( Seems such handling isn't supported, but I think "normally" it should be cleanuped then.

- Alex

Eric Anholt

2015-10-29 19:02 UTC #3 lore raw

In reply to Alexander Aring

Quoted 104 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").
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]>
Cc Andy Whitcroft <[email protected]>
Cc Joe Perches <[email protected]>
Signed-off-by Alexander Aring <[email protected]>
---
First:
I cc'ed Andy Whitcroft and Joe Perches here, because this patch will generate a false positive for checkpatch and checkpatch told me to cc checkpatch maintainers if this occurs:
ERROR: Macros with complex values should be enclosed in parentheses #191: FILE: drivers/firmware/raspberrypi.c:26:
drivers/firmware/raspberrypi.c +3 -0
+#define RPI_POWER_DOMAIN(_domain, _name)			\
+	[_domain] =						\
+	{							\
...
Second:
This patch based on linus/master and requires the rpi-firmware patch.
Third:
The barebox regulator doesn't support right now to enable/disable regulators at runtime but I want to bring this mainline in the next days. So you can't check yourself if the above scripts working right now. I describe it here to show you what exactly I tested.

Quoted 3 lines

changes since Eric Anholts "power domain" patch:
- add for me all known power domains of the RPi, it contains the domains 0 - 9.

Note: None of the power domain enums other than the ones I'd had in my
patch are actually connected to anything in the firmware. I don't think
we should be adding them, given that.
-------------- 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/20151029/433f6e15/attachment.sig>

Alexander Aring

author

2015-11-02 08:46 UTC #4 lore raw

Hi,

Quoted 11 lines · Eric Anholt

Quoted 9 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").
It was tested with barebox and the following scripts before booting

...

Quoted 6 lines

Quoted 6 lines
Third:
The barebox regulator doesn't support right now to enable/disable regulators at runtime but I want to bring this mainline in the next days. So you can't check yourself if the above scripts working right now. I describe it here to show you what exactly I tested.

Quoted 7 lines

Quoted 3 lines
changes since Eric Anholts "power domain" patch:
- add for me all known power domains of the RPi, it contains the domains 0 - 9.
Note: None of the power domain enums other than the ones I'd had in my patch are actually connected to anything in the firmware. I don't think we should be adding them, given that.

Okay. Then it makes sense that I still accessing UART and SDHC when I turn off the power.

In you patch you had SDHC, USB, DSI. Are you sure that SDHC power domain has any effect, because I don't see any effect and can still access the sd card.

I using "... firmware from 2015-10-28 17:06".

I would add the power-domains where we have currently an use-case for it and this USB at the moment. Is this okay for you?

- Alex

Eric Anholt

2015-11-17 21:46 UTC #5 lore raw

Quoted 29 lines · Alexander Aring

Hi,
Quoted 11 lines · Eric Anholt
Quoted 9 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").
It was tested with barebox and the following scripts before booting
...
Quoted 6 lines
Quoted 6 lines
Third:
The barebox regulator doesn't support right now to enable/disable regulators at runtime but I want to bring this mainline in the next days. So you can't check yourself if the above scripts working right now. I describe it here to show you what exactly I tested.
Quoted 7 lines
Quoted 3 lines
changes since Eric Anholts "power domain" patch:
- add for me all known power domains of the RPi, it contains the domains 0 - 9.
Note: None of the power domain enums other than the ones I'd had in my patch are actually connected to anything in the firmware. I don't think we should be adding them, given that.

Quoted 6 lines

Okay. Then it makes sense that I still accessing UART and SDHC when I turn off the power.
In you patch you had SDHC, USB, DSI. Are you sure that SDHC power domain has any effect, because I don't see any effect and can still access the sd card.

It looks like the SDCARD domain is kept always on, even if we ask for it off. We can clear the always-on flag by setting domain 29 in MBOX_CHAN_POWER. It's not accessible from the property channel, unless I've misread the logic.

Yet another reason I'm hoping to write a native power domain driver.

Quoted 2 lines

I would add the power-domains where we have currently an use-case for it and this USB at the moment. Is this okay for you?

Sounds good to me. I'll probably extend that for V3D.
-------------- 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/20151117/1e23e8ec/attachment.sig>