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

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(-)
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;

My original intention was to have a 100ms timeout. However, the timer operations used return values in ms not us, so we ended up with a 100s timeout instead. Fixing this exposes that some operations need longer to operate than 100ms, so bump the timeout up to a whole second.
Reported-by: Andre Heider a.heider@gmail.com Reviewed-by: Andre Heider a.heider@gmail.com Signed-off-by: Stephen Warren swarren@wwwdotorg.org --- arch/arm/cpu/arm1176/bcm2835/mbox.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/cpu/arm1176/bcm2835/mbox.c b/arch/arm/cpu/arm1176/bcm2835/mbox.c index 4daf1e4..3b17a31 100644 --- a/arch/arm/cpu/arm1176/bcm2835/mbox.c +++ b/arch/arm/cpu/arm1176/bcm2835/mbox.c @@ -8,7 +8,7 @@ #include <asm/io.h> #include <asm/arch/mbox.h>
-#define TIMEOUT (100 * 1000) /* 100mS in uS */ +#define TIMEOUT 1000 /* ms */
int bcm2835_mbox_call_raw(u32 chan, u32 send, u32 *recv) {

On Mon, Jan 13, 2014 at 07:50:12PM -0700, Stephen Warren wrote:
My original intention was to have a 100ms timeout. However, the timer operations used return values in ms not us, so we ended up with a 100s timeout instead. Fixing this exposes that some operations need longer to operate than 100ms, so bump the timeout up to a whole second.
Reported-by: Andre Heider a.heider@gmail.com Reviewed-by: Andre Heider a.heider@gmail.com Signed-off-by: Stephen Warren swarren@wwwdotorg.org
Applied to u-boot/master, thanks!

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,

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:-(

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!
participants (3)
-
Albert ARIBAUD
-
Stephen Warren
-
Tom Rini