From mboxrd@z Thu Jan  1 00:00:00 1970
From: Andre Heider <a.heider@gmail.com>
Date: Mon, 9 Dec 2013 20:52:59 +0100
Subject: [U-Boot] [PATCH REPOST] ARM: rpi_b: power on SDHCI and USB HW
 modules
In-Reply-To: <52A2A910.8060002@wwwdotorg.org>
References: <1386129715-5820-1-git-send-email-swarren@wwwdotorg.org>
	<20131206133738.GA50279@localhost> <52A2A910.8060002@wwwdotorg.org>
Message-ID: <20131209195258.GA4884@localhost>
List-Id: <u-boot.lists.denx.de>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
To: u-boot@lists.denx.de

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