On Sat, Jan 26, 2013 at 7:25 PM, Shawn Guo <shawn.guo@xxxxxxxxxx> wrote: > As multiplatform build is being adopted by more and more ARM platforms, > initcall function should be used very carefully. For example, when > GENERIC_CPUFREQ_CPU0 is built in the kernel, cpu0_cpufreq_driver_init() > will be called on all the platforms to initialize cpufreq-cpu0 driver. > > To eliminate this undesired the effect, the patch changes cpufreq-cpu0 > driver to have it instantiated as a platform_driver. Then it will only > run on platforms that create the platform_device "cpufreq-cpu0". > > Along with the change, it also changes cpu_dev to be &pdev->dev, > so that managed functions can start working, and module build gets > supported too. > > Signed-off-by: Shawn Guo <shawn.guo@xxxxxxxxxx> > --- > Rafael, > > The patch depends patch "power: export opp cpufreq functions". > https://patchwork.kernel.org/patch/1847261/ > > AnilKumar, > > Unfortunately, the change will require some platform level adoption > to have cpufreq-cpu0 driver continue working for am33xx. But it should > be as simple as something like below. > > struct platform_device_info devinfo = { .name = "cpufreq-cpu0", }; > platform_device_register_full(&devinfo); Something similar was being discussed with Andrew (cc'd) on his patch for kikwood cpufreq driver. We shouldn't encourage addition of above as we are moving towards DT. So, i would except an compatible array too in your patch and then driver can be probed based on compatible string being present in cpu node. What do you say? -- viresh -- To unsubscribe from this list: send the line "unsubscribe cpufreq" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
