omap cpufreq driver in multi-platform kernels

[Paul Walmsley]

Hi

On Mon, 1 Apr 2013, Rob Herring wrote:

> On 03/30/2013 05:21 PM, Paul Walmsley wrote:
> > 
> > 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?
> 
> 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.

So sounds like DT is expected to be used in a Linux-specific way as a 
/etc/modules replacement.  Why not create a Linux-specific DT node that 
can be used to load any module?  Wouldn't that have the same effect, but 
avoid creating false device nodes that don't exist in the hardware?


- Paul