Re: [PATCH 0/4] cpufreq-dt, platform_data based proposal

[Thomas Petazzoni <thomas.petazzoni@free-electrons.com>]

Arnd,

On Wed, 10 Sep 2014 12:19:41 +0200, Arnd Bergmann wrote:

> the driver for every new platform we want to support. It would
> be better to find a way that lets you add new platforms using just
> new dts files that work with the existing driver.

What do you call a "platform" ? A board or a SoC ? The top-level
compatible string contain both references to the board and the SoC, and
my idea was obviously that the cpufreq driver would match against the
SoC compatible string, not the board one. This definitely allows to
support additional boards by adding more dts without touching the code.

Of course, it however means that when a new SoC shows up, you'll need
to adjust the cpufreq driver. But you generally anyway need some kernel
changes to support a new SoC: .dtsi changes are rarely sufficient to
completely support a new chip.

> > In the mean time, would it be possible to realize that the existing
> > generic cpufreq driver simply isn't generic enough, and that we should
> > accept machine-specific cpufreq drivers for the time being?
> 
> That would work for me, to get things going for 3.18, but it's really
> up to the cpufreq maintainers. Your platform_data based patch set
> seems like a better solution to me than separate drivers, but I haven't
> looked at the details.

I personally don't really care: using platform_data, adding a
machine-specific driver, having two platform_driver for cpufreq-dt with
different names.

Viresh ?

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