Re: RFC on cpufreq implementation

[Mason <mpeg.blue@free.fr>]

Viresh Kumar wrote:

> Mason wrote:
>
>> If it's supposed to go in drivers/cpufreq, I suppose there are naming
>> conventions to follow?
>
> You can check existing drivers.

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?

>> Also, if it's in drivers/cpufreq, we are not supposed to include
>> any machine-specific includes? And I'm back to my original question
>> where am I supposed to store machine-specific information, such as
>> register descriptions and MMIO addresses and offsets?
>
> Define registers/etc in your driver only or somewhere in include/ .

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

> Also, try to see if you can reuse cpufreq-dt.c, your driver wouldn't make
> it to the kernel otherwise.

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?

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?

Regards.