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