[PATCH V2] davinci: da850: move input frequency to board specific files

Kevin Hilman khilman at ti.com
Tue Jun 7 12:23:59 EDT 2011


"Nori, Sekhar" <nsekhar at ti.com> writes:

> Hi Kevin,
>
> On Tue, Jun 07, 2011 at 04:14:59, Hilman, Kevin wrote:
>> Christian Riesch <christian.riesch at omicron.at> writes:
>> 
>> > From: Bob Dunlop <bob.dunlop at xyzzy.org.uk>
>> >
>> > Currently the input frequency of the SoC is hardcoded in the SoC specific
>> > da850.c file to 24 MHz. Since the SoC accepts input frequencies in a wide
>> > range from 12 to 50 MHz, boards with different oscillator/crystal
>> > frequencies may be built.
>> >
>> > This patch allows setting a different input frequency in the board
>> > specific files to support boards with oscillator/crystal frequencies other
>> > than 24 MHz.
>> >
>> > Signed-off-by: Bob Dunlop <bob.dunlop at xyzzy.org.uk>
>> > Signed-off-by: Christian Riesch <christian.riesch at omicron.at>
>> 
>> Why not allow board code to just do a clk_set_rate()?
>> 
>> Currently the ref_clk struct clk does not have a .set_rate method
>> implemented, but that should be easy enough to add.  
>> 
>> Then the default ref_clk.rate would stay the 24MHz, but any boards that
>> want to override that simply use clk_get(), clk_set_rate(), clk_put()
>
> That's certainly much more elegant, but this would mean the whole
> clock tree is traversed again on each boot.
>
> I am doing some measurements to see if there is any big difference
> in boot-time if this is done. Will get back with results.

I don't expect this to be a big boot-time impact.

However, some of the clock.c assumptions might need to be updated as it
currently is written from the perspective that the PLL clocks are the
"root" clocks.

Setting (and propagating) clock rates is what the clock framework is
for, so adding a new interface to set a custom clock rate just doesn't
seem right.  I understand that the reference oscillator might be
considered a special case, but if this can be done with the clock
framework, it is much preferred.

Kevin



More information about the linux-arm-kernel mailing list