On Wed, Jul 23, 2014 at 01:55:57PM +0530, Viresh Kumar wrote:

On 23 July 2014 12:54, Thierry Reding [off-list ref] wrote:

quoted

ARM_TEGRA_CPUFREQ is still optional, so the select only applies when the
Tegra cpufreq driver is enabled. This is mostly just out of convenience,
though. The Tegra cpufreq driver uses the generic CPU0 cpufreq driver so
a select will automatically pull in the necessary dependency. With a

Not necessarily. cpufreq-cpu0 can have few unmet dependency. And so
there are chances that tegra driver is compiled but cpufreq-cpu0 isn't as
we didn't mention it as a *hard* dependency.

And so at boot, there wouldn't be any cpufreq support even when tegra's
cpufreq driver is available.

Though, menuconfig may give some warnings no such situations.

quoted

"depends on" the Tegra cpufreq driver only becomes available after
you've selected GENERIC_CPUFREQ_CPU0, which is somewhat unintuitive.

To illustrate with an example: as a user, I want to enable CPU frequency
scaling on Tegra. So I use menuconfig to navigate to the "CPU Frequency
scaling" menu (enable it if not available yet) and look for an entry
that says "Tegra". But I can't find it because it's hidden due to the
lack of GENERIC_CPUFREQ_CPU0. That the Tegra CPU frequency driver uses a
generic driver is an implementation detail that users shouldn't have to
be aware of.

Don't know, the guy compiling out stuff should be knowledgeable enough to
have a look why tegra cpufreq entry isn't shown in menu. As, probably the
above problem I mentioned looks to be of more significance than this one,
atleast to me :)

And, another thing to mention is that CONFIG_TEGRA_CPUFREQ is valid
for earlier platforms as well and so a select/depends wouldn't be valid for
earlier platforms. We probably need another Kconfig entry here.

Yes, sounds like a new Kconfig entry for this specific driver would be a
better approach and should remove all the above concerns.

Thierry