[PATCH v4 7/8] ARM: Exynos: switch to using generic cpufreq-cpu0 driver
Rob Herring
robherring2 at gmail.com
Wed May 14 06:45:23 PDT 2014
On Wed, May 14, 2014 at 8:18 AM, Arnd Bergmann <arnd at arndb.de> wrote:
> On Wednesday 14 May 2014 18:44:46 Viresh Kumar wrote:
>> On 14 May 2014 18:41, Heiko Stübner <heiko at sntech.de> wrote:
>> > Am Mittwoch, 14. Mai 2014, 18:35:29 schrieb Viresh Kumar:
>> >> On 14 May 2014 18:20, Arnd Bergmann <arnd at arndb.de> wrote:
>> >> > Could we please come up with a way to probe this from DT in the
>> >> > cpufreq-cpu0 driver itself, so we don't have to add a device in every
>> >> > platform using it?
>>
>> >> Its followed that way because DT Maintainers had strong objections
>> >> to creating virtual device nodes and haven't allowed creation of nodes
>> >> for cpufreq drivers.. For which there is no physical device, as CPU already
>> >> has a separate node..
>> >
>> > as we already have the "enable-method" property for enabling/disabling cpus,
>> > would something like a "scaling-method" be feasible?
>
> Good idea to put it as a property into the CPU node.
We already have properties which indicate this driver can be used by a
platform: opp table and a clock for the cpu. If this information is
not sufficient to determine whether you can use this driver or not,
then you simply need to match against the platform. Perhaps the match
list should be a blacklist rather than a whitelist, so new platforms
work without a kernel change.
Alternatively, create a new OPP binding that addresses this and all
the other limitations in the current OPP binding.
>> Lets see what DT maintainers have to say on this, I would rather go for a
>> more straight forward name: "scaling-driver" ..
>
> Both sound fine to me.
The fact that linux needs a way to create a platform device to enable
a certain driver is not a DT problem. I proposed a solution for how to
get this out of the platform code [1], but evidently we want people to
open code the exceptions and adding boilerplate helpers will just
encourage the exceptions.
Rob
[1] https://lkml.org/lkml/2013/10/30/30
More information about the linux-arm-kernel
mailing list