diff mbox

[U-Boot,REPOST4,1/2] ARM: rpi_b: power on SDHCI and USB HW modules

Message ID 1389667812-8066-1-git-send-email-swarren@wwwdotorg.org
State Accepted
Delegated to: Tom Rini
Headers show

Commit Message

Stephen Warren Jan. 14, 2014, 2:50 a.m. UTC
Send RPC commands to the VideoCore to turn on the SDHCI and USB modules.
For SDHCI this isn't needed in practice, since the firmware already
turned on the power in order to load U-Boot. However, it's best to be
explicit. For USB, this is necessary, since the module isn't powered
otherwise. This will allow the kernel USB driver to work.

Signed-off-by: Stephen Warren <swarren@wwwdotorg.org>
---
Could this please be applied for v2014.01? I know I did first post it
after the merge window closed (by just a few hours...) but there's always
plenty of other stuff that's accepted under similar timing.

 arch/arm/include/asm/arch-bcm2835/mbox.h | 48 ++++++++++++++++++++++++++++++++
 board/raspberrypi/rpi_b/rpi_b.c          | 34 +++++++++++++++++++++-
 2 files changed, 81 insertions(+), 1 deletion(-)

Comments

Albert ARIBAUD Jan. 14, 2014, 7:20 a.m. UTC | #1
Hi Stephen,

On Mon, 13 Jan 2014 19:50:11 -0700, Stephen Warren
<swarren@wwwdotorg.org> wrote:

> Send RPC commands to the VideoCore to turn on the SDHCI and USB modules.
> For SDHCI this isn't needed in practice, since the firmware already
> turned on the power in order to load U-Boot. However, it's best to be
> explicit. For USB, this is necessary, since the module isn't powered
> otherwise. This will allow the kernel USB driver to work.
> 
> Signed-off-by: Stephen Warren <swarren@wwwdotorg.org>
> ---
> Could this please be applied for v2014.01? I know I did first post it
> after the merge window closed (by just a few hours...) but there's always
> plenty of other stuff that's accepted under similar timing.

I'm not against taking this in as this affects only a single board (and
provided Tom is OK too).

Also, I'd really like to know whether the three reposts are actually
versions (in which case I'd have liked a version history, even limited
to "vN: rebase" if such is the case) or pings (in which case I'd prefer
"ping?" replies, as these replies do not create patch entries in
patchwork).

Amicalement,
Stephen Warren Jan. 20, 2014, 9:06 p.m. UTC | #2
On 01/13/2014 07:50 PM, Stephen Warren wrote:
> Send RPC commands to the VideoCore to turn on the SDHCI and USB modules.
> For SDHCI this isn't needed in practice, since the firmware already
> turned on the power in order to load U-Boot. However, it's best to be
> explicit. For USB, this is necessary, since the module isn't powered
> otherwise. This will allow the kernel USB driver to work.
> 
> Signed-off-by: Stephen Warren <swarren@wwwdotorg.org>
> ---
> Could this please be applied for v2014.01? I know I did first post it
> after the merge window closed (by just a few hours...) but there's always
> plenty of other stuff that's accepted under similar timing.

Albert, sorry for responding to the patch rather than your mail, but for
some reason I didn't get your response on Jan 14 where you wrote:

> I'm not against taking this in as this affects only a single board (and
> provided Tom is OK too).

Tom, is this patch OK?

> Also, I'd really like to know whether the three reposts are actually
> versions (in which case I'd have liked a version history, even limited
> to "vN: rebase" if such is the case) or pings (in which case I'd prefer
> "ping?" replies, as these replies do not create patch entries in
> patchwork).

It's the same patch, with no changes. I reposted since there was no
response, so figured it must have been lost.

In other cases where I sent pings in replies to the patch, I was asked
to repost the patch instead. Admittedly the particular case I'm thinking
of here was Linux kernel patches, but the process ought to be the same;
it's hard on submitters to have to remember some table of
maintainer/project -> ping/repost style and similar things:-(
Tom Rini Jan. 20, 2014, 10:58 p.m. UTC | #3
On Mon, Jan 13, 2014 at 07:50:11PM -0700, Stephen Warren wrote:

> Send RPC commands to the VideoCore to turn on the SDHCI and USB modules.
> For SDHCI this isn't needed in practice, since the firmware already
> turned on the power in order to load U-Boot. However, it's best to be
> explicit. For USB, this is necessary, since the module isn't powered
> otherwise. This will allow the kernel USB driver to work.
> 
> Signed-off-by: Stephen Warren <swarren@wwwdotorg.org>

Applied to u-boot/master, thanks!
diff mbox

Patch

diff --git a/arch/arm/include/asm/arch-bcm2835/mbox.h b/arch/arm/include/asm/arch-bcm2835/mbox.h
index 6b806ec..38cb42a 100644
--- a/arch/arm/include/asm/arch-bcm2835/mbox.h
+++ b/arch/arm/include/asm/arch-bcm2835/mbox.h
@@ -133,6 +133,54 @@  struct bcm2835_mbox_tag_get_arm_mem {
 	} body;
 };
 
+#define BCM2835_MBOX_POWER_DEVID_SDHCI		0
+#define BCM2835_MBOX_POWER_DEVID_UART0		1
+#define BCM2835_MBOX_POWER_DEVID_UART1		2
+#define BCM2835_MBOX_POWER_DEVID_USB_HCD	3
+#define BCM2835_MBOX_POWER_DEVID_I2C0		4
+#define BCM2835_MBOX_POWER_DEVID_I2C1		5
+#define BCM2835_MBOX_POWER_DEVID_I2C2		6
+#define BCM2835_MBOX_POWER_DEVID_SPI		7
+#define BCM2835_MBOX_POWER_DEVID_CCP2TX		8
+
+#define BCM2835_MBOX_POWER_STATE_RESP_ON	(1 << 1)
+/* Device doesn't exist */
+#define BCM2835_MBOX_POWER_STATE_RESP_NODEV	(1 << 1)
+
+#define BCM2835_MBOX_TAG_GET_POWER_STATE	0x00020001
+
+struct bcm2835_mbox_tag_get_power_state {
+	struct bcm2835_mbox_tag_hdr tag_hdr;
+	union {
+		struct {
+			u32 device_id;
+		} req;
+		struct {
+			u32 device_id;
+			u32 state;
+		} resp;
+	} body;
+};
+
+#define BCM2835_MBOX_TAG_SET_POWER_STATE	0x00028001
+
+#define BCM2835_MBOX_SET_POWER_STATE_REQ_ON	(1 << 0)
+#define BCM2835_MBOX_SET_POWER_STATE_REQ_WAIT	(1 << 1)
+
+struct bcm2835_mbox_tag_set_power_state {
+	struct bcm2835_mbox_tag_hdr tag_hdr;
+	union {
+		struct {
+			u32 device_id;
+			u32 state;
+		} req;
+		struct {
+			u32 device_id;
+			u32 state;
+		} resp;
+	} body;
+};
+
 #define BCM2835_MBOX_TAG_GET_CLOCK_RATE	0x00030002
 
 #define BCM2835_MBOX_CLOCK_ID_EMMC	1
diff --git a/board/raspberrypi/rpi_b/rpi_b.c b/board/raspberrypi/rpi_b/rpi_b.c
index 16d442a..f33fae9 100644
--- a/board/raspberrypi/rpi_b/rpi_b.c
+++ b/board/raspberrypi/rpi_b/rpi_b.c
@@ -29,6 +29,12 @@  struct msg_get_arm_mem {
 	u32 end_tag;
 };
 
+struct msg_set_power_state {
+	struct bcm2835_mbox_hdr hdr;
+	struct bcm2835_mbox_tag_set_power_state set_power_state;
+	u32 end_tag;
+};
+
 struct msg_get_clock_rate {
 	struct bcm2835_mbox_hdr hdr;
 	struct bcm2835_mbox_tag_get_clock_rate get_clock_rate;
@@ -54,11 +60,35 @@  int dram_init(void)
 	return 0;
 }
 
+static int power_on_module(u32 module)
+{
+	ALLOC_ALIGN_BUFFER(struct msg_set_power_state, msg_pwr, 1, 16);
+	int ret;
+
+	BCM2835_MBOX_INIT_HDR(msg_pwr);
+	BCM2835_MBOX_INIT_TAG(&msg_pwr->set_power_state,
+			      SET_POWER_STATE);
+	msg_pwr->set_power_state.body.req.device_id = module;
+	msg_pwr->set_power_state.body.req.state =
+		BCM2835_MBOX_SET_POWER_STATE_REQ_ON |
+		BCM2835_MBOX_SET_POWER_STATE_REQ_WAIT;
+
+	ret = bcm2835_mbox_call_prop(BCM2835_MBOX_PROP_CHAN,
+				     &msg_pwr->hdr);
+	if (ret) {
+		printf("bcm2835: Could not set module %u power state\n",
+		       module);
+		return -1;
+	}
+
+	return 0;
+}
+
 int board_init(void)
 {
 	gd->bd->bi_boot_params = 0x100;
 
-	return 0;
+	return power_on_module(BCM2835_MBOX_POWER_DEVID_USB_HCD);
 }
 
 int board_mmc_init(void)
@@ -66,6 +96,8 @@  int board_mmc_init(void)
 	ALLOC_ALIGN_BUFFER(struct msg_get_clock_rate, msg_clk, 1, 16);
 	int ret;
 
+	power_on_module(BCM2835_MBOX_POWER_DEVID_SDHCI);
+
 	BCM2835_MBOX_INIT_HDR(msg_clk);
 	BCM2835_MBOX_INIT_TAG(&msg_clk->get_clock_rate, GET_CLOCK_RATE);
 	msg_clk->get_clock_rate.body.req.clock_id = BCM2835_MBOX_CLOCK_ID_EMMC;