[PATCH V3 4/7] cpufreq: add generic cpufreq driver

[Richard Zhao]

在 2011-12-20 下午11:22，"Arnd Bergmann" <arnd at arndb.de>写道：
>
> On Tuesday 20 December 2011, Richard Zhao wrote:
> > > >>>> +Generic cpufreq driver
> > > >>>> +
> > > >>>> +Required properties in /cpus/cpu at 0:
> > > >>>> +- compatible : "generic-cpufreq"
> > > >>>
> > > >>> I'm not convinced this is the best way to do this.  By requiring a
> > > >>> generic-cpufreq compatible string we're encoding Linux driver
> > > >>> information into the hardware description.  The only way I can
see to
> > > >>> avoid this is to provide a generic_clk_cpufreq_init() function
that
> > > >>> platforms can call in their machine init code to use the driver.
> > >
> > > Agreed on the compatible string.
> > Assume you reject to use compatible string.
> > > It's putting Linux specifics into DT.
> > >
> > > You could flip this around and have the module make a call into the
> > > kernel to determine whether to initialize or not. Then platforms could
> > > set a flag to indicate this.
> > Could you make it more clear? kernel global variable, macro, or
function?
> >
> > - Following your idea, I think, we can add in driver/cpufreq/cpufreq.c:
> > int (*clk_reg_cpufreq_get_op_table) (struct op_table *tbl, int *size);
> > SoC code set the callback. If it's NULL, driver will exit. We can get
rid
> > of DT. It'll make cpufreq core dirty, but it's the only file built-in.
> >
> > - Drop module support. SoC call generic_clk_cpufreq_init as Jamie said.
>
> I think you don't actually need a "compatible" property here, as long as
we
> ensure that the "cpu-freqs", "cpu-volts" and "trans-latency" properties
are
> present in the cpu node if and only if the machine works with this driver
> (why else would you put them there?).
It is more easy for me.
Rob, agree?

Richard
>
> CPUs are special in the device trees in a number of ways, so I think we
> can treat this as a logical extension. This way, you can still make the
> generic cpufreq driver a loadable module. You don't get module autoloading
> with this structure, but that is already the case because the cpu nodes
> in the device tree are not translated into linux devices.
>
>        Arnd
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ozlabs.org/pipermail/devicetree-discuss/attachments/20111220/0ed7bdf8/attachment.html>