Re: omap cpufreq driver in multi-platform kernels

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Eduardo,

On Mon, 1 Apr 2013, Eduardo Valentin wrote:

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

That might be the case for some or all of what's in mainline for the 
thermal framework.  But I've seen at least one Linux BSP for an ARM SoC 
implement a thermal "cooling device" that isn't directly backed by any 
hardware IP block.  

Anyway, this is kind of a tangent.


- 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




[Index of Archives]     [Linux Kernel Devel]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite Forum]     [Linux SCSI]

  Powered by Linux