On Tuesday 16 December 2014 11:18:18 Stephen Boyd wrote:

On 12/16/2014 06:38 AM, Arnd Bergmann wrote:

quoted

On Tuesday 16 December 2014 15:12:22 Daniel Lezcano wrote:

quoted

At the beginning, all that become from not including mach files from the 
drivers directory which make sense.

Perhaps it is time to write a similar mechanism for the cpuidle drivers 
where we can still separate the low level PM code from the generic 
cpuidle code.

That way you basically duplicate the same thing we already have, which
isn't much better.

In the example of drivers/soc/qcom/spm.c, just call cpuidle_register
from the spm_dev_probe() function and be done with it. You already
have a device that is responsible for handling this, don't try to
construct more than you already need.

I would assume that the same can be done for most other platforms.

There are probably cases where the same piece of hardware is responsible
for both cpuidle and cpufreq, but what that means is really that you
should have a single driver for it that does both things. Same for
SMP support: if you have one register block that does both the SMP
bringup and the cpuidle stuff, then have *one* driver for this block
that does it all. There are currently a few dependencies that require
doing SMP bringup early during boot, but we decided years ago that those
are all artificial dependencies and we should be able to boot secondary
CPUs much later than we currently do.

+1. The SPM harware is used for hotplug, suspend, cpuidle, as well as
provides a regulator for a CPU, so all these things should be done in a
single driver. Booting secondary CPUs early is not hard here either if
we move the smp ops into the same driver. The only downside then is that
it can't be a module, but I would guess that we can work on making that
possible by allowing smp ops to be inserted and removed at any time.

Right, I don't see modular SMP operations happening any time soon,
but it also doesn't seem like a fundamental restriction.

	Arnd