Add cpufreq support

I'm throwing this out there to ask:
Is this the right way to enable cpufreq on my platform?
---

arch/arm/mach-tango/setup.c +5 -0

@@ -23,6 +24,11 @@ static void tango_l2c_write(unsigned long val, unsigned int reg)
 		tango_set_l2_control(val);
 }
 
+static void __init tango_init_late(void)
+{
+	platform_device_register_simple("cpufreq-dt", -1, NULL, 0);
+}
+
 static const char *const tango_dt_compat[] = { "sigma,tango4", NULL };
 
 DT_MACHINE_START(TANGO_DT, "Sigma Tango DT")

We no longer call platform_device_register_simple() from platform code, at least for new platforms, and we should probably remove the code from the existing platforms that still do it. I forget what the replacement was, but I'm not going to take this version. Viresh should be able to help you do it the right way.

Quoted 5 lines · Arnd Bergmann

We no longer call platform_device_register_simple() from platform code, at least for new platforms, and we should probably remove the code from the existing platforms that still do it. I forget what the replacement was, but I'm not going to take this version. Viresh should be able to help you do it the right way.

We thought initially that opp-v2's compatible string can be used to probe the drivers, but that was denied later and all we do today is add platform devices for cpufreq.

What do you have in mind Arnd ?

Whatever you want to do in drivers/cpufreq that keeps this out of arch/arm/

As I have said numerous times, there is absolutely no point in having a platform device for this, but if you insist on having one

just write one
file that has an early_initcall() function and move all the code creating those devices in there for platforms using DT, e.g. by matching on the root compatible string the same way the platform code does today.

For new platforms, please come up with a way to not need that and create a generic binding that anyone can follow.

Quoted 4 lines · Arnd Bergmann

Whatever you want to do in drivers/cpufreq that keeps this out of arch/arm/

As I have said numerous times, there is absolutely no point in having a platform device for this, but if you insist on having one

No, I don't insist on that. I just hate it.

But the problem was that we never agreed to a way, by which we could have probed cpufreq-dt. We were talking about compatible string from 'opp-v2' earlier, but that was soon discarded.

Quoted 5 lines

just write one
file that has an early_initcall() function and move all the code creating those devices in there for platforms using DT, e.g. by matching on the root compatible string the same way the platform code does today.

Quoted 2 lines

For new platforms, please come up with a way to not need that and create a generic binding that anyone can follow.

Do you have any suggestions ?
- We aren't allowed to (re)use opp-v2 compatibility string
- We can't add a DT node for virtual device - cpufreq

What else can be done ?

Maybe add a opp-v3 compatible string?

I really don't care what you
match on, as long we don't need any code in arch/arm/ to create a device we don't need.

Don't add the device to DT, we really don't want that.

If there
is too much opposition to looking at the cpus nodes in the initcall,

start with a whitelist for known machines, that at least keeps the existing behavior.

Quoted 1 line · Arnd Bergmann

Maybe add a opp-v3 compatible string?

How will that help?

The problem was that the compatibility string of "opp-v2" specifies the way we need to parse the bindings and shouldn't be (ab)used to probe a driver like cpufreq-dt. And so we got stuck.

Quoted 3 lines

I really don't care what you
match on, as long we don't need any code in arch/arm/ to create a device we don't need.

Sure.

Quoted 1 line

Don't add the device to DT, we really don't want that.

I agree.

Quoted 2 lines

If there
is too much opposition to looking at the cpus nodes in the initcall,

I didn't get this one, what can we do by looking at CPUs nodes ?

Quoted 2 lines

start with a whitelist for known machines, that at least keeps the existing behavior.

That can be a valid solution I would say, but that separate driver (cpufreq-dt-device.c) needs to be changed for every new platform.

I don't remember the exact discussion, but the compatible string is exactly meant to do one thing: it tells you what you can or cannot do with one device.

I had not realized that we don't even have a compatible string for opp-v2, so if we are missing that, we obviously can't compare against that string.

I thought there was a compatible property in there that told us whether the operating-points-v2/cooling-min-level/#cooling-cells/... properties were considered valid.

Quoted 3 lines · Arnd Bergmann

I don't remember the exact discussion, but the compatible string is exactly meant to do one thing: it tells you what you can or cannot do with one device.

Yeah, and many people argued that we can't add two values to that string like: "cpufreq-dt" and "cpufreq-big-little" for same kind of OPP bindings, as a different compatible string should be required only if there is a difference in the bindings.

For example, if a platform (like ST did recently) adds more platform-specific properties, then they can define a new value of those strings.

Quoted 3 lines

I had not realized that we don't even have a compatible string for opp-v2, so if we are missing that, we obviously can't compare against that string.

The binding says that we can have a string, but its not compulsory yet. Its only used by STM as they have some specific properties of their own.

Quoted 3 lines

I thought there was a compatible property in there that told us whether the operating-points-v2/cooling-min-level/#cooling-cells/... properties were considered valid.

Yeah, "OPP-v2" DT node can have a compatible string, which isn't compulsory as of now, but because of the reasons mentioned earlier, we can't use it to differentiate between drivers that use exactly same version of bindings.

That's why I said we could introduce a 'v3' with the meaning it should have had to start with: compatible means actually compatible with the driver.