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.
--
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
