Messages in this thread | | | Date | Fri, 18 Mar 2011 15:40:27 -0700 | From | Stephen Boyd <> | Subject | Re: [PATCHv3 0/4] Improve fallback LPJ calculation |
| |
On 03/10/2011 06:48 AM, Phil Carmody wrote: > Apologies for picking on you, Andrew, and sending this out of the blue, > but I didn't have much luck with my previous attempt, and I quite like > this patchset, so thought it was worth trying again. > (http://lkml.org/lkml/2010/9/28/121) > > The guts of this patchset are in patch 2/4. The motivation for that patch > is that currently our OMAP calibrates itself using the trial-and-error > binary chop fallback that some other architectures no longer need to > perform. This is a lengthy process, taking 0.2s in an environment where > boot time is of great interest. > > [snip] > 1/4 is simply cosmetic to prepare for 2/4. > 4/4 is simply to assist testing and not intended for integration. >
I tried this patch set out on an MSM7630.
Before:
Calibrating delay loop... 681.57 BogoMIPS (lpj=3407872)
After:
Calibrating delay loop... 680.75 BogoMIPS (lpj=3403776)
But the really good news is calibration time dropped from ~247ms to ~56ms. Sadly we won't be able to benefit from this should my udelay patches make it into ARM because we would be using calibrate_delay_direct() instead (at least on machines who choose to). Can we somehow reapply the logic behind this to calibrate_delay_direct()? That would be even better, but this is definitely a boot time improvement.
Or maybe we could just replace calibrate_delay_direct() with this fallback calculation? If __delay() is a thin wrapper around read_current_timer() it should work just as well (plus patch 3 makes it handle SMIs). I'll try that out.
You can add a
Tested-by: Stephen Boyd <sboyd@codeaurora.org>
to the first 3 patches.
-- Sent by an employee of the Qualcomm Innovation Center, Inc. The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.
| |