[U-Boot] [PATCH REPOST] ARM: rpi_b: power on SDHCI and USB HW modules

[Andre Heider <a.heider@gmail.com>]

On Fri, Dec 06, 2013 at 09:50:24PM -0700, Stephen Warren wrote:
> On 12/06/2013 06:37 AM, Andre Heider wrote:
> > Hi Stephen,
> > 
> > On Tue, Dec 03, 2013 at 09:01:55PM -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.
> > 
> > I didn't test this patch yet, but from skimming over it it looks similar to
> > what I tried with barebox a while back.
> > 
> > What I did notice with the "set power" mbox call is that it takes way longer
> > than 100ms (the current mbox call timeout) to finish on a cold boot. You
> > don't seem to bump the timeout here, and with 100ms I always hit it and
> > hence the mbox call failed for me. Don't you get these huge delays?
> 
> I have firmware commit b38194c "kernel: Bump version to 3.10.19", and
> I'm seeing a valid non-error response to both the SD and USB set_power
> requests, with no timeouts.

This patch indeed works and does not trigger the timeout, but after a
bit of digging and cross checking it seems that's because the used
timeout is using the wrong unit ;)

get_timer() returns mS, while arch/arm/cpu/arm1176/bcm2835/mbox.c uses:
#define TIMEOUT (100 * 1000) /* 100mS in uS */

Hacking the mbox call to run into that timeout confirms its waiting 100s
instead of 100mS.

And fixing this to:
#define TIMEOUT (100) /* 100mS */

then triggers the timeout I was seeing with barebox. While I ported your
mbox driver over I didn't notice this, I just went by the comment and used
100mS there ;)

Regards,
Andre