On Mon, Nov 24, 2014 at 11:29 AM, Andrew Bresticker <abrestic@xxxxxxxxxx> wrote:
>> diff --git a/arch/mips/bmips/setup.c b/arch/mips/bmips/setup.c
>
>> +void __init plat_time_init(void)
>> +{
>> + struct device_node *np;
>> + u32 freq;
>> +
>> + np = of_find_node_by_name(NULL, "cpus");
>> + if (!np)
>> + panic("missing 'cpus' DT node");
>> + if (of_property_read_u32(np, "mips-hpt-frequency", &freq) < 0)
>> + panic("missing 'mips-hpt-frequency' property");
>> + of_node_put(np);
>> +
>> + mips_hpt_frequency = freq;
>> +}
>
> Could you use common clock framework for this? Isn't the HPT just a
> fixed factor of the CPU clock? I'm planning on doing something very
> similar for ImgTec MIPS SoCs, so perhaps this could go in a common
> place, like the r4k clocksource driver?
Jonas and I had tossed some ideas around earlier, and I included a few
random thoughts in the cover letter.
One concern is that this currently has to be set pretty early in the
boot process (prior to jiffies calibration IIRC), so it might still
need to be handled as a special case.
Regarding the "fixed factor" question: that is true on all of the
chips I've seen, with a few additional caveats:
- Most MIPS cores use cpu_clk/2, but BMIPS5000 uses cpu_clk/8.
- Some MIPS cores scale the CP0 counter frequency when the cpu_clk is
changed, but others do not. Sometimes this depends on the core rev
(e.g. 65nm BMIPS438x cores do scale, but 40nm BMIPS438x cores do not).
- We might not necessarily have a good way to determine cpu_clk on
every platform, either.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
