On Mon, Aug 01, 2011 at 04:01:19PM +0000, Simon Guinot wrote:
On Mon, Aug 01, 2011 at 10:52:11AM -0400, Jason wrote:
On Mon, Aug 01, 2011 at 12:20:12PM +0000, Simon Guinot wrote:
Hi Jason,
On Mon, Aug 01, 2011 at 01:04:27AM +0000, Jason Cooper wrote:
If CONFIG_DISPLAY_CPUINFO is enabled on kirkwood SoCs, this will print the speeds of the various components.
Signed-off-by: Jason Cooper u-boot@lakedaemon.net
Changes since v1:
- optimized macros to remove one-timers
- reduced switch/case to if/else since it operates on one bit.
- remove RFC
arch/arm/cpu/arm926ejs/kirkwood/cpu.c | 41 ++++++++++++++++++++++++++++++ arch/arm/include/asm/arch-kirkwood/cpu.h | 1 + 2 files changed, 42 insertions(+), 0 deletions(-)
... snip ...
- tmp = readl(MPP_SAMPLE_AT_RESET);
- cpu_clk = MSAR_CPUCLCK_EXTRACT(tmp);
- if (cpu_clk == 0x9)
cpu_clk = 1200;I suspect this code to be broken. Here you get a clock selector (which is only relevant for 6281 and 6191 SoCs) from the reset at sample register.
Ok, I'll filter on devid, then switch/case on it.
Which clock frequency do you pick if the selector is not 0x9 ?
Good question. This was originally dreamplug specific code I got from globalscale. I'm cleaning it up as best I can.
You should probably use a convertion array from selector to CPU frequency. Here is a such array valid for 6281 and 6191 SoCs:
u32 kw_6281_cpu_clk[] = { 0, 0, 0, 0, 600000000, 0, 800000000, 1000000000, 0, 1200000000, 0, 0, 1500000000, 0, 0, 0 };
Thanks, I'll integrate this with the above approach.
Note that I don't know if this array is valid for 6282 and 6283 SoCs.
I'll address it as unhandled in the code.
But for sure, the clock selector for a 6180 SoC is given by differents bits in the reset at sample register: [4:2] against [4:3],[22],[1]. The conversion array is different too...
If you have the values handy, or a pointer to them, I'll add that as well.
Some time ago, I wrote a cpufreq driver for Linux:
http://git.lacie-nas.org/?p=linux-lacie.git;a=commitdiff;h=d14f36361340d40da...
Thanks for the pointer. That fills in a lot of holes.
thx,
Jason.