[PATCH 2/8] cpufreq: add driver for Armada XP

[thomas.petazzoni@free-electrons.com (Thomas Petazzoni)]

Dear Viresh Kumar,

Thanks for your feedback!

On Fri, 4 Jul 2014 15:25:35 +0530, Viresh Kumar wrote:
> On 4 July 2014 15:14, Thomas Petazzoni
> <thomas.petazzoni@free-electrons.com> wrote:
> > This commit adds a simple cpufreq driver for the Armada XP SoC, which
> > has one separately controllable clock for each CPU. For this reason,
> > the existing cpufreq-cpu0 generic driver cannot be used because it
> > currently assumes that there is only one clock controlling the
> > frequency of all CPUs.
> >
> > There are on-going discussions on extending the cpufreq-cpu0 to cover
> > the case of having one clock for each CPU, but there are still some
> > unresolved issues to get this extended cpufreq-cpu0 driver merged.
> 
> Exactly, and those changes would get merged in one form or the other.
> Surely in 3.17 atleast, if not 3.16 as we are already reaching rc4..
> 
> So, it would be great if you can test on top of those changes to see if
> something isn't solved for your platform yet?
> 
> git://git.linaro.org/people/viresh.kumar/linux.git cpufreq/cpu0-krait-v3

One other problem with cpufreq-cpu0 is that it assumes the Device Tree
can contain a static OPP table, with the frequency/voltage points.
Unfortunately, in the case of the Armada XP platform, this is not
possible, because we cannot hardcode into the Device Tree the possible
CPU frequencies.

The nominal CPU frequency is selected by Sample on Reset pins (i.e pins
of the CPUs that are sampled during the reset sequence) and can
therefore change from one board to the other, and they can also be
changed via special U-Boot commands. And the frequencies supported by
cpufreq are the nominal frequency of the CPU as determined by the
sample at reset pins, and half of this frequency.

That's why the proposed armadaxp-cpufreq driver does not hardcode the
possible frequencies, but instead creates the frequency table by using
the current CPU frequency (nominal frequency) and half of it.

This doesn't work very well with the idea of having the OPP table
statically encoded in to the Device Tree. Options are:

 - Improve the cpufreq-cpu0 driver so that the OPP table can be passed
   through platform_data, and therefore built dynamically by the
   platform code and passed when registering the cpufreq
   platform_device.

 - Dynamically build/update the OPP table in the Device Tree.

Which option do you think is appropriate here?

Thanks,

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com