Raspberry Pi firmware driver

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

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

Documentation/devicetree/bindings/arm/bcm/raspberrypi,firmware.txt new file +0 -0

new file mode 100644
index 0000000..a74c966

Documentation/devicetree/bindings/arm/bcm/raspberrypi,firmware.txt new file +6 -0

+Example:
+
+firmware {
+	compatible = "rasbperrypi,firmware";
+	mboxes = <&mailbox 0>
+};

This gives us a function for making mailbox property channel requests of the firmware, and uses it to control the 3 power domains provided by the firmware.

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

---
 arch/arm/mach-bcm/Kconfig                          |   2 +
 arch/arm/mach-bcm/Makefile                         |   1 +
 arch/arm/mach-bcm/raspberrypi-firmware.c           | 285 +++++++++++++++++++++

include/soc/bcm2835/raspberrypi-mailbox-property.h new file +5 -0

new file mode 100644
index 0000000..787bd75
@@ -0,0 +1,110 @@
+/*
+ *  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

include/soc/bcm2835/raspberrypi-mailbox-property.h new file +7 -0

+struct raspberrypi_firmware_property_tag_header {
+	/* One of enum_mbox_property_tag. */
+	u32 tag;
+
+	/* The number of bytes in the value buffer following this
+	 * struct.
+	 */

include/soc/bcm2835/raspberrypi-mailbox-property.h new file +4 -0

+enum raspberrypi_firmware_property_tag {
+	raspberrypi_firmware_property_end = 0,
+	raspberrypi_firmware_get_firmware_revision =                  0x00000001,
+

Quoted 4 lines · On Monday 27 April 2015 16:14:08 Eric Anholt wrote:

This gives us a function for making mailbox property channel requests of the firmware, and uses it to control the 3 power domains provided by the firmware.

Quoted 5 lines

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

---
 arch/arm/mach-bcm/Kconfig                          |   2 +
 arch/arm/mach-bcm/Makefile                         |   1 +
 arch/arm/mach-bcm/raspberrypi-firmware.c           | 285 +++++++++++++++++++++

drivers/firmware maybe?

Is this firmware the same one on the Roku 2? If so, it might need a better name.

Quoted 15 lines

include/soc/bcm2835/raspberrypi-mailbox-property.h new file +9 -0

new file mode 100644
index 0000000..787bd75
@@ -0,0 +1,110 @@
+/*
+ *  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.
+ */
+
+#include <linux/types.h>

include/soc/bcm2835/raspberrypi-mailbox-property.h line 15

Quoted 6 lines

include/soc/bcm2835/raspberrypi-mailbox-property.h new file +6 -0

+
+enum raspberrypi_firmware_property_status {
+	raspberrypi_firmware_status_request = 0,
+	raspberrypi_firmware_status_success = 0x80000000,
+	raspberrypi_firmware_status_error =   0x80000001,
+};

We tend to use ALL_CAPS for constants, even when they are in an enum.

Quoted 13 lines

include/soc/bcm2835/raspberrypi-mailbox-property.h new file +13 -0

+struct raspberrypi_firmware_property_tag_header {
+	/* One of enum_mbox_property_tag. */
+	u32 tag;
+
+	/* The number of bytes in the value buffer following this
+	 * struct.
+	 */
+	u32 buf_size;
+
+	/*
+	 * On submit, the length of the request (though it doesn't
+	 * appear to be currently used by the firmware).  On return,
+	 * the length of the response (always 4 byte aligned), with

include/soc/bcm2835/raspberrypi-mailbox-property.h line 33

Quoted 4 lines

include/soc/bcm2835/raspberrypi-mailbox-property.h new file +4 -0

+	 * the low bit set.
+	 */
+	u32 req_resp_size;
+};

If I read your code right, this structure is only used inside of the driver and not passed in from a device driver, so better move it inside of the firmware code.

It might be best to do the same with the return codes above as well, and convert them into standard Linux calling conventions as well.

Quoted 9 lines

include/soc/bcm2835/raspberrypi-mailbox-property.h new file +9 -0

+enum raspberrypi_firmware_property_tag {
+	raspberrypi_firmware_property_end = 0,
+	raspberrypi_firmware_get_firmware_revision =                  0x00000001,
+
+	raspberrypi_firmware_set_cursor_info =                        0x00008010,
+	raspberrypi_firmware_set_cursor_state =                       0x00008011,
+
+	raspberrypi_firmware_get_board_model =                        0x00010001,
+	raspberrypi_firmware_get_board_revision =                     0x00010002,

include/soc/bcm2835/raspberrypi-mailbox-property.h line 48

Quoted 5 lines

include/soc/bcm2835/raspberrypi-mailbox-property.h new file +5 -0

+	raspberrypi_firmware_get_board_mac_address =                  0x00010003,
+	raspberrypi_firmware_get_board_serial =                       0x00010004,
+	raspberrypi_firmware_get_arm_memory =                         0x00010005,
+	raspberrypi_firmware_get_vc_memory =                          0x00010006,
+	raspberrypi_firmware_get_clocks =                             0x00010007,

How stable are these interfaces? Does the firmware guarantee to keep the ABI working, or might we need to version these?

This gives us a function for making mailbox property channel requests of the firmware, and uses it to control the 3 power domains provided by the firmware.

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

---
 arch/arm/mach-bcm/Kconfig                          |   2 +
 arch/arm/mach-bcm/Makefile                         |   1 +
 arch/arm/mach-bcm/raspberrypi-firmware.c           | 285 +++++++++++++++++++++

 .../dt-bindings/arm/raspberrypi-firmware-power.h   |  16 ++
 include/soc/bcm2835/raspberrypi-mailbox-property.h | 110 ++++++++
 5 files changed, 414 insertions(+)
 create mode 100644 arch/arm/mach-bcm/raspberrypi-firmware.c
 create mode 100644 include/dt-bindings/arm/raspberrypi-firmware-power.h
 create mode 100644 include/soc/bcm2835/raspberrypi-mailbox-property.h

This gives us a function for making mailbox property channel requests of the firmware, and uses it to control the 3 power domains provided by the firmware.

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

---
 arch/arm/mach-bcm/Kconfig                          |   2 +
 arch/arm/mach-bcm/Makefile                         |   1 +
 arch/arm/mach-bcm/raspberrypi-firmware.c           | 285 +++++++++++++++++++++
 .../dt-bindings/arm/raspberrypi-firmware-power.h   |  16 ++
 include/soc/bcm2835/raspberrypi-mailbox-property.h | 110 ++++++++
 5 files changed, 414 insertions(+)
 create mode 100644 arch/arm/mach-bcm/raspberrypi-firmware.c
 create mode 100644 include/dt-bindings/arm/raspberrypi-firmware-power.h
 create mode 100644 include/soc/bcm2835/raspberrypi-mailbox-property.h

This gives us a function for making mailbox property channel requests of the firmware, and uses it to control the 3 power domains provided by the firmware.

arch/arm/mach-bcm/raspberrypi-firmware.c +7 -0

 
+/*
+ * Submits a set of concatenated tags to the VPU firmware through the
+ * mailbox property interface.
+ *
+ * The buffer header and the ending tag are added by this function and
+ * don't need to be supplied, just the actual tags for your operation.
+ * See struct raspberrypi_firmware_property_tag_header for the per-tag structure.

+static int raspberrypi_firmware_probe(struct platform_device *pdev)

arch/arm/mach-bcm/raspberrypi-firmware.c line 231

Quoted 11 lines · Eric Anholt

arch/arm/mach-bcm/raspberrypi-firmware.c new file +11 -0

+     firmware->chan = mbox_request_channel(&firmware->cl, 0);
+     if (IS_ERR(firmware->chan)) {
+             ret = PTR_ERR(firmware->chan);
+             /* An -EBUSY from the core means it couldn't find our
+              * channel, because the mailbox driver hadn't
+              * registered yet.
+              */
+             if (ret == -EBUSY)
+                     ret = -EPROBE_DEFER;
+             else
+                     dev_err(dev, "Failed to get mbox channel: %d\n", ret);

I would have hoped that mbox_request_channel() returned -EPROBE_DEFER itself. It really should...

Quoted 14 lines · Stephen Warren

Quoted 11 lines · Eric Anholt

arch/arm/mach-bcm/raspberrypi-firmware.c new file +11 -0

+     firmware->chan = mbox_request_channel(&firmware->cl, 0);
+     if (IS_ERR(firmware->chan)) {
+             ret = PTR_ERR(firmware->chan);
+             /* An -EBUSY from the core means it couldn't find our
+              * channel, because the mailbox driver hadn't
+              * registered yet.
+              */
+             if (ret == -EBUSY)
+                     ret = -EPROBE_DEFER;
+             else
+                     dev_err(dev, "Failed to get mbox channel: %d\n", ret);

Quoted 3 lines

I would have hoped that mbox_request_channel() returned -EPROBE_DEFER itself. It really should...

Yes, it should. Let me look into it.

Quoted 13 lines · Eric Anholt

This gives us a function for making mailbox property channel requests of the firmware, and uses it to control the 3 power domains provided by the firmware.

arch/arm/mach-bcm/raspberrypi-firmware.c +7 -0

 
+/*
+ * Submits a set of concatenated tags to the VPU firmware through the
+ * mailbox property interface.
+ *
+ * The buffer header and the ending tag are added by this function and
+ * don't need to be supplied, just the actual tags for your operation.
+ * See struct raspberrypi_firmware_property_tag_header for the per-tag structure.

arch/arm/mach-bcm/raspberrypi-firmware.c line 88

Quoted 10 lines

arch/arm/mach-bcm/raspberrypi-firmware.c +10 -0

+ */
+int raspberrypi_firmware_property(void *data, size_t tag_size)
+{
+	size_t size = tag_size + 12;
+	u32 *buf;
+	dma_addr_t bus_addr;
+	int ret = 0;
+
+	if (!firmware)
+		return -EPROBE_DEFER;

I think it'd make more sense if the clients looked up the firmware driver via phandle at their probe time. This would mean:

* No need for global "firmware", since clients could pass the firmware driver handle into this function.

* Clients resolve deferred probe at their probe time. That way, they won't register themselves with subsystems asserting they can provide services, but find out they can't yet provide the service at that time.

Quoted 1 line

+static int raspberrypi_firmware_probe(struct platform_device *pdev)

BTW if you wanted, a s/raspberrypi/rpi/ in all symbols and filenames seems reasonable. I'm not really bothered either way.

I would have hoped that mbox_request_channel() returned -EPROBE_DEFER itself. It really should...

arch/arm/mach-bcm/raspberrypi-firmware.c line 261

Quoted 6 lines

arch/arm/mach-bcm/raspberrypi-firmware.c +6 -0

+static int raspberrypi_firmware_remove(struct platform_device *pdev)
+{
+	struct device *dev = &pdev->dev;
+
+	of_genpd_del_provider(dev->of_node);
+	mbox_free_channel(firmware->chan);

firmware = NULL; ?

Quoted 28 lines · Stephen Warren

Quoted 13 lines · Eric Anholt

This gives us a function for making mailbox property channel requests of the firmware, and uses it to control the 3 power domains provided by the firmware.

arch/arm/mach-bcm/raspberrypi-firmware.c +7 -0

 
+/*
+ * Submits a set of concatenated tags to the VPU firmware through the
+ * mailbox property interface.
+ *
+ * The buffer header and the ending tag are added by this function and
+ * don't need to be supplied, just the actual tags for your operation.
+ * See struct raspberrypi_firmware_property_tag_header for the per-tag structure.

arch/arm/mach-bcm/raspberrypi-firmware.c line 88

Quoted 10 lines

arch/arm/mach-bcm/raspberrypi-firmware.c +10 -0

+ */
+int raspberrypi_firmware_property(void *data, size_t tag_size)
+{
+	size_t size = tag_size + 12;
+	u32 *buf;
+	dma_addr_t bus_addr;
+	int ret = 0;
+
+	if (!firmware)
+		return -EPROBE_DEFER;

I think it'd make more sense if the clients looked up the firmware driver via phandle at their probe time. This would mean:

Quoted 6 lines

* No need for global "firmware", since clients could pass the firmware driver handle into this function.

* Clients resolve deferred probe at their probe time. That way, they won't register themselves with subsystems asserting they can provide services, but find out they can't yet provide the service at that time.

The one client so far (vc4) was resolving deferred probe at its probe time, but not taking a reference on the firmware driver. I figure I'll have it do the phandle lookup and refcount -- do you still want the struct platform_device passed in here? If we de-global firmware, it's going to mean some faffing in the power domain side of things to find the device again, it seems.

Quoted 37 lines · Eric Anholt

Quoted 28 lines · Stephen Warren

Quoted 13 lines · Eric Anholt

This gives us a function for making mailbox property channel requests of the firmware, and uses it to control the 3 power domains provided by the firmware.

arch/arm/mach-bcm/raspberrypi-firmware.c +7 -0

 
+/*
+ * Submits a set of concatenated tags to the VPU firmware through the
+ * mailbox property interface.
+ *
+ * The buffer header and the ending tag are added by this function and
+ * don't need to be supplied, just the actual tags for your operation.
+ * See struct raspberrypi_firmware_property_tag_header for the per-tag structure.

arch/arm/mach-bcm/raspberrypi-firmware.c line 88

Quoted 10 lines

arch/arm/mach-bcm/raspberrypi-firmware.c +10 -0

+ */
+int raspberrypi_firmware_property(void *data, size_t tag_size)
+{
+	size_t size = tag_size + 12;
+	u32 *buf;
+	dma_addr_t bus_addr;
+	int ret = 0;
+
+	if (!firmware)
+		return -EPROBE_DEFER;

I think it'd make more sense if the clients looked up the firmware driver via phandle at their probe time. This would mean:

Quoted 6 lines

* No need for global "firmware", since clients could pass the firmware driver handle into this function.

* Clients resolve deferred probe at their probe time. That way, they won't register themselves with subsystems asserting they can provide services, but find out they can't yet provide the service at that time.

Quoted 6 lines

The one client so far (vc4) was resolving deferred probe at its probe time, but not taking a reference on the firmware driver. I figure I'll have it do the phandle lookup and refcount -- do you still want the struct platform_device passed in here? If we de-global firmware, it's going to mean some faffing in the power domain side of things to find the device again, it seems.

I think I'd expect the API in the firmware driver to require the client to pass the client DT node pointer plus a property name, and do all the lookup itself. That's what most DT resource lookup APIs in the kernel do now.

Quoted 45 lines · Stephen Warren

Quoted 37 lines · Eric Anholt

Quoted 28 lines · Stephen Warren

Quoted 13 lines · Eric Anholt

This gives us a function for making mailbox property channel requests of the firmware, and uses it to control the 3 power domains provided by the firmware.

arch/arm/mach-bcm/raspberrypi-firmware.c +7 -0

 
+/*
+ * Submits a set of concatenated tags to the VPU firmware through the
+ * mailbox property interface.
+ *
+ * The buffer header and the ending tag are added by this function and
+ * don't need to be supplied, just the actual tags for your operation.
+ * See struct raspberrypi_firmware_property_tag_header for the per-tag structure.

arch/arm/mach-bcm/raspberrypi-firmware.c line 88

Quoted 10 lines

arch/arm/mach-bcm/raspberrypi-firmware.c +10 -0

+ */
+int raspberrypi_firmware_property(void *data, size_t tag_size)
+{
+	size_t size = tag_size + 12;
+	u32 *buf;
+	dma_addr_t bus_addr;
+	int ret = 0;
+
+	if (!firmware)
+		return -EPROBE_DEFER;

I think it'd make more sense if the clients looked up the firmware driver via phandle at their probe time. This would mean:

Quoted 6 lines

* No need for global "firmware", since clients could pass the firmware driver handle into this function.

* Clients resolve deferred probe at their probe time. That way, they won't register themselves with subsystems asserting they can provide services, but find out they can't yet provide the service at that time.

Quoted 6 lines

The one client so far (vc4) was resolving deferred probe at its probe time, but not taking a reference on the firmware driver. I figure I'll have it do the phandle lookup and refcount -- do you still want the struct platform_device passed in here? If we de-global firmware, it's going to mean some faffing in the power domain side of things to find the device again, it seems.

Quoted 4 lines

I think I'd expect the API in the firmware driver to require the client to pass the client DT node pointer plus a property name, and do all the lookup itself. That's what most DT resource lookup APIs in the kernel do now.

I've made this change, but it's not great -- the client has to know some details of how this driver is structured (that it sets the drvdata) in order to figure out whether the driver is loaded or not and return -EPROBE_DEFERRED. I couldn't find any other existing solutions than that in the tree.

Quoted 52 lines · Eric Anholt

Quoted 45 lines · Stephen Warren

Quoted 37 lines · Eric Anholt

Quoted 28 lines · Stephen Warren

Quoted 13 lines · Eric Anholt

This gives us a function for making mailbox property channel requests of the firmware, and uses it to control the 3 power domains provided by the firmware.

arch/arm/mach-bcm/raspberrypi-firmware.c +7 -0

 
+/*
+ * Submits a set of concatenated tags to the VPU firmware through the
+ * mailbox property interface.
+ *
+ * The buffer header and the ending tag are added by this function and
+ * don't need to be supplied, just the actual tags for your operation.
+ * See struct raspberrypi_firmware_property_tag_header for the per-tag structure.

arch/arm/mach-bcm/raspberrypi-firmware.c line 88

Quoted 10 lines

arch/arm/mach-bcm/raspberrypi-firmware.c +10 -0

+ */
+int raspberrypi_firmware_property(void *data, size_t tag_size)
+{
+	size_t size = tag_size + 12;
+	u32 *buf;
+	dma_addr_t bus_addr;
+	int ret = 0;
+
+	if (!firmware)
+		return -EPROBE_DEFER;

I think it'd make more sense if the clients looked up the firmware driver via phandle at their probe time. This would mean:

Quoted 6 lines

* No need for global "firmware", since clients could pass the firmware driver handle into this function.

* Clients resolve deferred probe at their probe time. That way, they won't register themselves with subsystems asserting they can provide services, but find out they can't yet provide the service at that time.

Quoted 6 lines

The one client so far (vc4) was resolving deferred probe at its probe time, but not taking a reference on the firmware driver. I figure I'll have it do the phandle lookup and refcount -- do you still want the struct platform_device passed in here? If we de-global firmware, it's going to mean some faffing in the power domain side of things to find the device again, it seems.

Quoted 4 lines

I think I'd expect the API in the firmware driver to require the client to pass the client DT node pointer plus a property name, and do all the lookup itself. That's what most DT resource lookup APIs in the kernel do now.

Quoted 5 lines

I've made this change, but it's not great -- the client has to know some details of how this driver is structured (that it sets the drvdata) in order to figure out whether the driver is loaded or not and return -EPROBE_DEFERRED. I couldn't find any other existing solutions than that in the tree.

The client shouldn't need to know that.

I'd expect the client to pass a DT node pointer to the provider's driver, and that provider driver would know and isolate all the details about its own internals. The provider could return some kind of handler/... to the provider device if required.

I would expect any subsystem that supports client->provider references in DT would have an example of this (e.g. IRQs, GPIOs, regulators, ...). However, the code for those can be rather complex to dive into for the first time. For a fairly simple standalone example, check out:

Provider:
drivers/amba/tegra-ahb.c
tegra_ahb_enable_smmu()

Consumer:
drivers/iommu/tegra-smmu.c
tegra_smmu_ahb_enable()
(called from tegra_smmu_probe() in the same file)

Quoted 75 lines · Stephen Warren

Quoted 52 lines · Eric Anholt

Quoted 45 lines · Stephen Warren

Quoted 37 lines · Eric Anholt

Quoted 28 lines · Stephen Warren

Quoted 13 lines · Eric Anholt

This gives us a function for making mailbox property channel requests of the firmware, and uses it to control the 3 power domains provided by the firmware.

arch/arm/mach-bcm/raspberrypi-firmware.c +7 -0

 
+/*
+ * Submits a set of concatenated tags to the VPU firmware through the
+ * mailbox property interface.
+ *
+ * The buffer header and the ending tag are added by this function and
+ * don't need to be supplied, just the actual tags for your operation.
+ * See struct raspberrypi_firmware_property_tag_header for the per-tag structure.

arch/arm/mach-bcm/raspberrypi-firmware.c

Quoted 10 lines

arch/arm/mach-bcm/raspberrypi-firmware.c +10 -0

+ */
+int raspberrypi_firmware_property(void *data, size_t tag_size)
+{
+	size_t size = tag_size + 12;
+	u32 *buf;
+	dma_addr_t bus_addr;
+	int ret = 0;
+
+	if (!firmware)
+		return -EPROBE_DEFER;

I think it'd make more sense if the clients looked up the firmware driver via phandle at their probe time. This would mean:

Quoted 6 lines

* No need for global "firmware", since clients could pass the firmware driver handle into this function.

* Clients resolve deferred probe at their probe time. That way, they won't register themselves with subsystems asserting they can provide services, but find out they can't yet provide the service at that time.

Quoted 6 lines

The one client so far (vc4) was resolving deferred probe at its probe time, but not taking a reference on the firmware driver. I figure I'll have it do the phandle lookup and refcount -- do you still want the struct platform_device passed in here? If we de-global firmware, it's going to mean some faffing in the power domain side of things to find the device again, it seems.

Quoted 4 lines

I think I'd expect the API in the firmware driver to require the client to pass the client DT node pointer plus a property name, and do all the lookup itself. That's what most DT resource lookup APIs in the kernel do now.

Quoted 5 lines

I've made this change, but it's not great -- the client has to know some details of how this driver is structured (that it sets the drvdata) in order to figure out whether the driver is loaded or not and return -EPROBE_DEFERRED. I couldn't find any other existing solutions than that in the tree.

The client shouldn't need to know that.

I'd expect the client to pass a DT node pointer to the provider's driver, and that provider driver would know and isolate all the details about its own internals. The provider could return some kind of handler/... to the provider device if required.

I would expect any subsystem that supports client->provider references in DT would have an example of this (e.g. IRQs, GPIOs, regulators, ...). However, the code for those can be rather complex to dive into for the first time. For a fairly simple standalone example, check out:

Provider:
drivers/amba/tegra-ahb.c
tegra_ahb_enable_smmu()

Quoted 4 lines

Consumer:
drivers/iommu/tegra-smmu.c
tegra_smmu_ahb_enable()
(called from tegra_smmu_probe() in the same file)

It's somewhat suspicious to me as an example of how -EPROBE_DEFER ought to work, that tegra_ahb_enable_smmu()'s return value isn't being checked by tegra_smmu_ahb_enable().

That said, this looks like this is "Yeah, just call into the producer driver to do setup, and if it returns -EPROBE_DEFER, then bail out and return -EPROBE_DEFER, yourself." That's what I was doing in this function and its consumers, that you commented on, only I wasn't passing in the dt node. Is that all you wanted changed?

This gets the USB power domain turned on so that DWC2 can probe, even if the bootloader didn't turn it on for us (which is the case if you use the RPi firmware without chainloading U-Boot).

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

---
 arch/arm/boot/dts/bcm2835-rpi.dtsi | 13 +++++++++++++
 arch/arm/boot/dts/bcm2835.dtsi     |  2 +-
 2 files changed, 14 insertions(+), 1 deletion(-)

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

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

@@ -14,6 +15,14 @@
 			linux,default-trigger = "heartbeat";
 		};
 	};
+
+	soc {
+		firmware: firmware {
+			compatible = "raspberrypi,firmware";
+			mboxes = <&mailbox 0>;
+			#power-domain-cells = <1>;
+		};
+	};
 };
 
 &gpio {

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

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

index 664aa25..5734650 100644
@@ -148,7 +148,7 @@
 			status = "disabled";
 		};
 
-		usb at 7e980000 {
+		usb: usb at 7e980000 {
 			compatible = "brcm,bcm2835-usb";
 			reg = <0x7e980000 0x10000>;
 			interrupts = <1 9>;

Quoted 5 lines · Eric Anholt

This gets the USB power domain turned on so that DWC2 can probe, even if the bootloader didn't turn it on for us (which is the case if you use the RPi firmware without chainloading U-Boot).

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

arch/arm/boot/dts/bcm2835-rpi.dtsi line 64

Quoted 3 lines

+&usb {

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

+	power-domains = <&firmware POWER_DOMAIN_USB>;
+};

That property doesn't seem to be documented in Documentation/devicetree/bindings/usb/dwc2.txt (which defines compatible = "brcm,bcm2835-usb"). Is it implemented?

Quoted 7 lines · Stephen Warren

Quoted 5 lines · Eric Anholt

This gets the USB power domain turned on so that DWC2 can probe, even if the bootloader didn't turn it on for us (which is the case if you use the RPi firmware without chainloading U-Boot).

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

Quoted 7 lines

arch/arm/boot/dts/bcm2835-rpi.dtsi line 64

Quoted 3 lines

+&usb {

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

+	power-domains = <&firmware POWER_DOMAIN_USB>;
+};

That property doesn't seem to be documented in Documentation/devicetree/bindings/usb/dwc2.txt (which defines compatible = "brcm,bcm2835-usb"). Is it implemented?

power-domains is a generic property that's parsed by drivers/base/power/domain.c. See also Documentation/devicetree/bindings/power/power_domain.txt&