RFC on cpufreq implementation

[Mason]

On 30/01/2015 02:15, Viresh Kumar wrote:

> What do you want to do with this driver? If you want to get it reviewed,
> please send it properly with git-send-email instead of attachments..
> 
> If its just an internal one, then sorry, the lists aren't for such reviews.

The long-term goal is to mainline the whole port, but it's rather
overwhelming, and I haven't found a way to divide-and-conquer, yet.
I've been reading guides and documentation for weeks, but nothing
has made my brain click.

Everything seems to involve DeviceTree, and AFAIU, going down that
rabbit-hole means making lots of changes all over. (But I probably
misunderstood that part too.)

Right now, all I have is this cleaned up cpufreq driver. And I don't
even know where to put it!

I see some platforms have it in their machine-specific folder, others
are in drivers/cpufreq. (When to use mach vs plat?)

If it's supposed to go in drivers/cpufreq, I suppose there are naming
conventions to follow?

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?

Two months ago, Arnd wrote:
> I meant the IO_ADDRESS stuff. Modern code uses ioremap() instead
> since the IO_ADDRESS was platform specific, and drivers can no longer
> use platform headers on CONFIG_ARCH_MULTIPLATFORM, which is used
> for all new code now.

Regards.