<p><br>
在 2011-12-20 下午11:13，"Rob Herring" <<a href="mailto:robherring2@gmail.com">robherring2@gmail.com</a>>写道：<br>
><br>
> On 12/19/2011 07:59 PM, Richard Zhao wrote:<br>
> > On Mon, Dec 19, 2011 at 09:00:44AM -0600, Rob Herring wrote:<br>
> >> On 12/19/2011 08:39 AM, Jamie Iles wrote:<br>
> >>> On Mon, Dec 19, 2011 at 10:19:29PM +0800, Richard Zhao wrote:<br>
> >>>> On Mon, Dec 19, 2011 at 10:05:12AM +0000, Jamie Iles wrote:<br>
> >>>>> Hi Richard,<br>
> >>>>><br>
> >>>>> On Mon, Dec 19, 2011 at 11:21:40AM +0800, Richard Zhao wrote:<br>
> >>>>>> It support single core and multi-core ARM SoCs. But currently it assume<br>
> >>>>>> all cores share the same frequency and voltage.<br>
> >>>>>><br>
> >>>>>> Signed-off-by: Richard Zhao <<a href="mailto:richard.zhao@linaro.org">richard.zhao@linaro.org</a>><br>
> >>>>>> ---<br>
> >>>>>> .../devicetree/bindings/cpufreq/generic-cpufreq | 7 +<br>
> >>>>>> drivers/cpufreq/Kconfig | 8 +<br>
> >>>>>> drivers/cpufreq/Makefile | 2 +<br>
> >>>>>> drivers/cpufreq/generic-cpufreq.c | 251 ++++++++++++++++++++<br>
> >>>>>> 4 files changed, 268 insertions(+), 0 deletions(-)<br>
> >>>>>> create mode 100644 Documentation/devicetree/bindings/cpufreq/generic-cpufreq<br>
> >>>>>> create mode 100644 drivers/cpufreq/generic-cpufreq.c<br>
> >>>>>><br>
> >>>>>> diff --git a/Documentation/devicetree/bindings/cpufreq/generic-cpufreq b/Documentation/devicetree/bindings/cpufreq/generic-cpufreq<br>
> >>>>>> new file mode 100644<br>
> >>>>>> index 0000000..15dd780<br>
> >>>>>> --- /dev/null<br>
> >>>>>> +++ b/Documentation/devicetree/bindings/cpufreq/generic-cpufreq<br>
> >>>>>> @@ -0,0 +1,7 @@<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>
> Any of those. Of course, direct access to variables across modules is<br>
> discouraged, so it would probably be a function that checks a variable.<br>
why not use function pointer? arch that don't use this driver do not have to set it. if use function, everyone should define it.<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>
> But aren't you getting the operating points from the DT? Then you don't<br>
> want to put this code into each platform.<br>
the variable is mainly used to check whether some platform want to use this driver. getting ride of dt is side affect.<br>
><br>
> ><br>
> > - Drop module support. SoC call generic_clk_cpufreq_init as Jamie said.<br>
> ><br>
> >><br>
> >>>> It'll prevent the driver from being a kernel module.<br>
> >>><br>
> >>> Hmm, that's not very nice either! I guess you _could_ add an<br>
> >>> of_machine_is_compatible() check against a list of compatible machines<br>
> >>> in the driver but that feels a little gross. Hopefully Rob or Grant<br>
> >>> have a good alternative!<br>
> >>><br>
> >><br>
> >> What does cpufreq core do if multiple drivers are registered?<br>
> > current cpufreq core only support one cpufreq_driver. Others will fail<br>
> > except the first time.<br>
><br>
> Then whoever gets there first wins. Make your driver register late and<br>
> if someone doesn't want to use it they can register a custom driver earlier.<br>
this driver did<br>
><br>
> Rob<br>
><br>
> >> Perhaps a<br>
> >> ranking is needed and this would only get enabled if there are no other<br>
> >> drivers and other conditions like having the clock "cpu" present are met.<br>
> > We'd better keep cpufreq core simple. For this driver, register cpufreq_driver<br>
> > is the last thing after checking all conditions.<br>
> ><br>
> >><br>
> >> Rob<br>
> >><br>
> >>>> Hi Grant & Rob,<br>
> >>>><br>
> >>>> Could you comment?<br>
> >>>><br>
> >>>>><br>
> >>>>>> +- cpu-freqs : cpu frequency points it support<br>
> >>>>>> +- cpu-volts : cpu voltages required by the frequency point at the same index<br>
> >>>>>> +- trans-latency : transition_latency<br>
> >>>>>> diff --git a/drivers/cpufreq/Kconfig b/drivers/cpufreq/Kconfig<br>
> >>>>>> index e24a2a1..216eecd 100644<br>
> >>>>>> --- a/drivers/cpufreq/Kconfig<br>
> >>>>>> +++ b/drivers/cpufreq/Kconfig<br>
> >>>>>> @@ -179,6 +179,14 @@ config CPU_FREQ_GOV_CONSERVATIVE<br>
> >>>>>><br>
> >>>>>> If in doubt, say N.<br>
> >>>>>><br>
> >>>>>> +config GENERIC_CPUFREQ_DRIVER<br>
> >>>>>> + bool "Generic cpufreq driver using clock/regulator/devicetree"<br>
> >>>>>> + help<br>
> >>>>>> + This adds generic CPUFreq driver. It assumes all<br>
> >>>>>> + cores of the CPU share the same clock and voltage.<br>
> >>>>>> +<br>
> >>>>>> + If in doubt, say N.<br>
> >>>>><br>
> >>>>> I think this needs dependencies on HAVE_CLK, OF and REGULATOR.<br>
> >>>> right, Thanks. I can not check clk before generic clock framework<br>
> >>>> come in.<br>
> >>>> Added:<br>
> >>>> depends on OF && REGULATOR<br>
> >>>> select CPU_FREQ_TABLE<br>
> >>><br>
> >>> You can still use HAVE_CLK. That symbol has been around for ages and<br>
> >>> any platform implementing the clk API should select it so it's fine to<br>
> >>> depend on it even before there is a generic struct clk.<br>
> > You are right. Thanks.<br>
> ><br>
> > Richard<br>
> >>><br>
> >>> Jamie<br>
> >><br>
> >> _______________________________________________<br>
> >> linux-arm-kernel mailing list<br>
> >> <a href="mailto:linux-arm-kernel@lists.infradead.org">linux-arm-kernel@lists.infradead.org</a><br>
> >> <a href="http://lists.infradead.org/mailman/listinfo/linux-arm-kernel">http://lists.infradead.org/mailman/listinfo/linux-arm-kernel</a><br>
> >><br>
> ><br>
><br>
</p>