
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...
For what it worth, you can find some useful informations about CPU frequencies for SoCs 6180, 6192 and 6282. Please, note that this driver has never been submitted nor reviewed (because I realized it was almost useless).
As a (more reliable ?) alternative, you could take a look at the cpufreq driver provided by the Marvell LSP.
As a side note, for U-Boot, you can probably assume that the "powersave mode" is always disabled and then only deal with the high frequencies.
Regards,
Simon