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