Re: RFC on cpufreq implementation

[Viresh Kumar <viresh.kumar@linaro.org>]

On 4 February 2015 at 05:37, Mason <mpeg.blue@free.fr> wrote:
> All of them?
>
> ~/linux-3.19-rc7$ wc drivers/cpufreq/*
>  31542  95730 813482 total
>
> Are there perhaps 1 or 2 "golden standard" drivers that are well-written
> and up-to-date with respect to current conventions?

cpufreq-dt.c

> Like Samsung did with include/dt-bindings/clock/exynos*.h ?

Yeah.

> Are you saying that use of DeviceTree is mandatory for new ARM ports?

Yes.

> In other words, ports using "board files" will not be accepted into
> mainline, nor will drivers not using DT?

It wouldn't be good for you as well, that's all I can say.

> If that is correct, then my proposed cpufreq driver has exactly 0%
> chance of being mainlined as-is, right?

:)

> I took a look at cpufreq-dt.c but I think it doesn't quite fit my use-case.
> In my driver, I define "clock dividers" (typically 1,2,3,5,9) and these are
> used to divide some baseline frequency that the cpufreq code doesn't need to
> know. The baseline frequency is set by the boot loader, and Linux is not
> supposed to change that, only apply the dividers if necessary.
>
> What do you think of this use-case?

You need to write a backend clock driver for this. Most of the other platforms
are doing this. cpufreq-dt driver does clk_get(), clk_get_rate(), clk_set_rate()
and your backend driver should handle these to change the frequencies.