| Message ID | 1386992926-17895-1-git-send-email-swarren@wwwdotorg.org |
|---|---|
| State | Superseded |
| Delegated to: | Albert ARIBAUD |
| Headers | show |
On Fri, Dec 13, 2013 at 08:48:46PM -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> > Signed-off-by: Stephen Warren <swarren@wwwdotorg.org> Reviewed-by: Andre Heider <a.heider@gmail.com> Btw, the "get timing" mbox call I mentioned the other day is not what I thought it is. I tried it and it doesn't describe how long the "power on" call would take. I get "1" for every device except UART, for which 40000 was returned iirc. Thanks, Andre
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) {
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> Signed-off-by: Stephen Warren <swarren@wwwdotorg.org> --- Albert, I believe this implies that my "ARM: rpi_b: power on SDHCI and USB HW modules" can be applied now. arch/arm/cpu/arm1176/bcm2835/mbox.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)