On 4 February 2015 at 05:37, Mason <mpeg.blue@xxxxxxx> 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. -- To unsubscribe from this list: send the line "unsubscribe cpufreq" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
