+cpufreq list as it seems most appropriate discussion forum. discussion thread: http://marc.info/?t=136434901900001&r=1&w=2 On Mon, Apr 1, 2013 at 12:20 PM, Eduardo Valentin <eduardo.valentin@xxxxxx> wrote: > Hey Paul, > > > On 30-03-2013 18:21, Paul Walmsley wrote: >> >> Hi folks, >> >> On Wed, 27 Mar 2013, Nishanth Menon wrote: >> >>> On 10:53-20130327, Kevin Hilman wrote: >>>> >>>> Nishanth Menon <nm@xxxxxx> writes: >>>>> >>>>> On 11:38-20130327, Rob Herring wrote: >>>>>> >>>>>> On 03/27/2013 08:32 AM, Nishanth Menon wrote: >>>>>>> >>>>>>> On 02:23-20130327, Paul Walmsley wrote: >>>>>>>> >>>>>>>> On Tue, 26 Mar 2013, Rob Herring wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>> Converting the driver to a platform driver would be another option. >>>> >>>> >>>> I think the platform_device conversion is the way to go. I think you >>>> should do that instead of PATCH 8/8 of your OMAP conversion to the >>>> generic driver[1]. >>> >>> >>> Yep, thinking about this over lunch, I came to the same conclusion that >>> instead of checking on DT node existance, platform_device conversion >>> will solve both parts of the puzzle. >> >> >> Looked at this a little today. I see that the platform_driver CPUFreq >> driver approach was taken with several SoCs in mainline. Could someone >> explain the theory behind making the CPUFreq drivers platform_drivers, >> rather than just modules? >> >> The part that doesn't make sense to me is that the existing CPUFreq >> drivers don't represent an actual hardware block. Conceptually, they >> aren't drivers for the CPU, nor are they drivers for a CPU frequency >> scaling IP block. One might as well bind a CPUIdle driver or a CPU >> throttling thermal driver to the CPU device. > > > I do agree with your point. On the other hand, I'd like to make a > clarification here. > > CPU throttling feature not really done as a driver. The feature is exported > to be used by policies built by other code. Check > drivers/thermal/cpu_cooling.c. > > Thermal drivers are in fact drivers, as they are bound to an actual hardware > block, a bandgap, a thermal sensor or a thermistor. > > > > >> >> Wouldn't it be best to just make them modules? > > > Thermal policies are built as modules. > > >> >> Also, noticed that the Highbank CPUFreq driver creates a virtual device in >> its code. That also doesn't seem right. Isn't device creation better >> left to DT/ACPI/whatever? >> Regards, Nishanth Menon -- 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
