On Mon, Dec 09, 2013 at 01:16:45PM -0700, Stephen Warren wrote:
On 12/09/2013 12:52 PM, Andre Heider wrote:
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.
So, is the issue simply that this message needs longer than 100mS to execute? If so, do you know exactly how long? Perhaps we should just set the timeout to e.g. 1s rather than fixing it to the originally-intended 100ms?
Yeah, the power on calls just take that long, at least with the WAIT flag set. 500mS wasn't enough in my case for USB, 750mS works but I didn't check how close it is to hit it, so 1s sounds good to me.
On the other side, there's a "get timing" mbox call [0], which would allow us to use a dynamic timeout, so supposed to be fast mbox calls don't unnecessary wait for too long upon failing. You mentioned getting this patch into 2014.01, so maybe that's something for another day.
[0] https://github.com/raspberrypi/firmware/wiki/Mailbox-property-interface#get-...
Regards, Andre