On Tuesday 13 May 2014 18:13:30 Grant Grundler wrote:
On Wed, May 7, 2014 at 1:35 AM, Ulf Hansson ulf.hans...@linaro.org wrote:
On 7 May 2014 03:52, Nick Sanders nsand...@chromium.org wrote:
This patch removes an unneccesary 1ms mdelay in the HS200 tuning
loop, called 40 times per retuning.
Arnd,
On Wed, May 14, 2014 at 5:18 AM, Arnd Bergmann a...@arndb.de wrote:
I just stumbled over this thread. Looking at the callers of the
execute_tuning() function, I see that all three come from non-atomic
context. How about an add-on patch to turn the mdelay(1) into an
msleep(1)? That would
On Wed, May 7, 2014 at 1:35 AM, Ulf Hansson ulf.hans...@linaro.org wrote:
On 7 May 2014 03:52, Nick Sanders nsand...@chromium.org wrote:
This patch removes an unneccesary 1ms mdelay in the HS200 tuning
loop, called 40 times per retuning. Currently this causes a latency
of 40ms on any emmc
Hi,
On Wed, May 14 2014, Grant Grundler wrote:
The delay is left in place for SD Cards, which use
MMC_SEND_TUNING_BLOCK rather than MMC_SEND_TUNING_BLOCK_HS200.
I'm not able to find evidence that this is required for SD in the
specs I have access to, however this delay has been present from
On 7 May 2014 03:52, Nick Sanders nsand...@chromium.org wrote:
This patch removes an unneccesary 1ms mdelay in the HS200 tuning
loop, called 40 times per retuning. Currently this causes a latency
of 40ms on any emmc accesses triggering wake from runtime PM,
which can occur for a significant
On Wed, May 7, 2014 at 1:35 AM, Ulf Hansson ulf.hans...@linaro.org wrote:
Aha, so you are actually using MMC_CAP_RUNTIME_RESUME here - cool :-).
I suppose those patches that enables the cap has not reached
mainline yet. Any plans on sending them?
I am actually running 3.10, so
This patch removes an unneccesary 1ms mdelay in the HS200 tuning
loop, called 40 times per retuning. Currently this causes a latency
of 40ms on any emmc accesses triggering wake from runtime PM,
which can occur for a significant portion of reads on a mostly idle system.
The delay is left in place
