ARM: rpi_b: power on SDHCI and USB HW modules
Subsystems (3)
PATCH 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.
---
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(-)
arch/arm/include/asm/arch-bcm2835/mbox.h +48 -0
@@ -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
board/raspberrypi/rpi_b/rpi_b.c +33 -1
@@ -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 ;
Signature · 1 line
1.8.3.2
PATCH 1/2 ARM: rpi_b: power on SDHCI and USB HW modules
Quoted 11 lines · Stephen Warren
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 <[email protected]>---
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
Quoted 2 lines · 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?
Quoted 5 lines
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:-(
PATCH 1/2 ARM: rpi_b: power on SDHCI and USB HW modules
In reply to Stephen WarrenHi Stephen,
Quoted 11 lines · Stephen Warren
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 <[email protected]>---
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,
Signature · 1 line
Albert.
PATCH 2/2 ARM: bcm2835: fix mailbox timeout
In reply to Stephen WarrenMy 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.
--- arch/arm/cpu/arm1176/bcm2835/mbox.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
arch/arm/cpu/arm1176/bcm2835/mbox.c +1 -1
@@ -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) {
Signature · 1 line
1.8.3.2
PATCH 2/2 ARM: bcm2835: fix mailbox timeout
Quoted 8 lines · Stephen Warren
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 <[email protected]>Reviewed-by Andre Heider <[email protected]>Signed-off-by Stephen Warren <[email protected]>
Applied to u-boot/master, thanks!
Signature · 8 lines
Tom -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 836 bytes Desc: Digital signature URL: <http://lists.denx.de/pipermail/u-boot/attachments/20140120/80194013/attachment.pgp>
PATCH 1/2 ARM: rpi_b: power on SDHCI and USB HW modules
In reply to Stephen WarrenQuoted 7 lines · Stephen Warren
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 <[email protected]>
Applied to u-boot/master, thanks!
Signature · 8 lines
Tom -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 836 bytes Desc: Digital signature URL: <http://lists.denx.de/pipermail/u-boot/attachments/20140120/1717ccee/attachment.pgp>