Re: RFC on cpufreq implementation

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


On 4 February 2015 at 05:37, Mason <> 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?


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


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


> 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.
To unsubscribe from this list: send the line "unsubscribe cpufreq" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at

[Index of Archives]     [Linux Kernel Devel]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite Forum]     [Linux SCSI]

  Powered by Linux