From mboxrd@z Thu Jan 1 00:00:00 1970 From: Eduardo Valentin Subject: Re: omap cpufreq driver in multi-platform kernels Date: Mon, 1 Apr 2013 13:20:58 -0400 Message-ID: <5159C1FA.8090000@ti.com> References: <5152503C.2050503@gmail.com> <20130327133220.GA30868@kahuna> <5153207A.4050109@gmail.com> <20130327170221.GA32231@kahuna> <87d2uk91ai.fsf@linaro.org> <20130327175621.GA32693@kahuna> Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit Return-path: Received: from arroyo.ext.ti.com ([192.94.94.40]:34392 "EHLO arroyo.ext.ti.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756294Ab3DARVR (ORCPT ); Mon, 1 Apr 2013 13:21:17 -0400 In-Reply-To: Sender: linux-pm-owner@vger.kernel.org List-Id: linux-pm@vger.kernel.org To: Paul Walmsley Cc: Nishanth Menon , Kevin Hilman , Mark Langsdorf , Shawn Guo , Rob Herring , Tony Lindgren , "linux-arm-kernel@lists.infradead.org" , linux-pm@vger.kernel.org, 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 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 > >