[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-id: <alpine.LFD.2.00.1010072107560.3107@xanadu.home>
Date: Thu, 07 Oct 2010 21:12:03 -0400 (EDT)
From: Nicolas Pitre <nico@...xnic.net>
To: Stephen Boyd <sboyd@...eaurora.org>
Cc: Daniel Walker <dwalker@...eaurora.org>,
Russell King <linux@....linux.org.uk>,
Kevin Hilman <khilman@...prootsystems.com>,
linux-arm-msm@...r.kernel.org, linux-kernel@...r.kernel.org,
Saravana Kannan <skannan@...eaurora.org>,
Santosh Shilimkar <santosh.shilimkar@...com>,
Colin Cross <ccross@...roid.com>,
linux-arm-kernel@...ts.infradead.org, linux-arch@...r.kernel.org
Subject: Re: [PATCH 1/3] [ARM] Translate delay.S into (mostly) C
On Thu, 7 Oct 2010, Stephen Boyd wrote:
> Why doesn't any other architecture use assembly for their lpj code? They
> may use headers with assembly in them or C code with assembly in them,
> but they don't write all of the delay code in assembly and rely on
> function interleaving. This leads me to believe other arches aren't
> concerned about compiler optimizations breaking lpj cmdline parameters,
> so why should ARM be concerned?
>
> I tested the theory out and scaled down the CPU frequency to 19.2 MHz
> and then called calibrate_delay(). Before and after applying this series
> I got the same results.
>
> Calibrating delay loop... 12.67 BogoMIPS (lpj=63360)
>
> Jumping up to 1.2 GHz and calling calibrate_delay() gives me the same
> before and after
>
> Calibrating delay loop... 792.98 BogoMIPS (lpj=3964928)
OK, fair enough.
> I don't have access to a machine capable of running slower than 19.2
> MHz. Maybe machines running in the KHz range would experience differences?
Don't worry, I doubt any ARM processor capable of running Linux ever was
that slow.
Nicolas
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists