omap cpufreq driver in multi-platform kernels

[Paul Walmsley]

Hi folks,

On Wed, 27 Mar 2013, Nishanth Menon wrote:

> On 10:53-20130327, Kevin Hilman wrote:
> > Nishanth Menon <nm at ti.com> 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.

Wouldn't it be best to just make them 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,

- Paul