Re: [PATCH v4 7/8] ARM: Exynos: switch to using generic cpufreq-cpu0 driver

On Wed, May 14, 2014 at 8:18 AM, Arnd Bergmann [off-list ref] wrote:

On Wednesday 14 May 2014 18:44:46 Viresh Kumar wrote:

quoted

On 14 May 2014 18:41, Heiko Stübner [off-list ref] wrote:

quoted

Am Mittwoch, 14. Mai 2014, 18:35:29 schrieb Viresh Kumar:

quoted

On 14 May 2014 18:20, Arnd Bergmann [off-list ref] wrote:

quoted

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?

quoted

quoted

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.

quoted

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