omap cpufreq driver in multi-platform kernels

[robherring2@gmail.com (Rob Herring)]

On 03/30/2013 05:21 PM, Paul Walmsley wrote:
> Hi folks,
> 
> On Wed, 27 Mar 2013, Nishanth Menon wrote:
> 
>> On 10:53-20130327, Kevin Hilman wrote:
>>> Nishanth Menon <nm@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.

It's not really a cpu device, but rather a virtual device. We could have
multiple devices. cpuidle drivers have the same issue.

> Wouldn't it be best to just make them modules?

Then module auto loading doesn't work AFAIK. We will want them to be
built as modules in multi-platform kernels to reduce the kernel size,
but you don't want to just shift the problem to the OS to decide what
modules a given platform needs.

> 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?

DT describes the h/w. Creating DT nodes that match the cpufreq drivers
is not describing the h/w, but what Linux wants currently. Cpufreq
drivers either touch parts of multiple h/w blocks, a single shared h/w
block or don't touch h/w directly. The cpufreq-cpu0 driver is the last
case and does use DT. Perhaps we will get to the point that all
low-level interfaces are abstracted and we can have a single cpufreq driver.

I think platform drivers are the right way to go, but I'd like to come
up with a better way to instantiate the devices. The only idea I've come
up with is to do some sort of automatic device creation based machine
compatible property matching.

Rob