Re: omap cpufreq driver in multi-platform kernels

[Eduardo Valentin <eduardo.valentin@ti.com>]

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@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.

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,
>
> - Paul
> --
> To unsubscribe from this list: send the line "unsubscribe linux-pm" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>
>