Thread (40 messages) 40 messages, 5 authors, 2014-07-21

[PATCHv2 12/17] cpuidle: mvebu: make the cpuidle driver capable of handling multiple SoCs

From: arnd@arndb.de (Arnd Bergmann)
Date: 2014-07-21 11:16:22
Also in: linux-pm

On Monday 21 July 2014 12:59:33 Daniel Lezcano wrote:
On 07/09/2014 03:40 PM, Thomas Petazzoni wrote:
quoted
From: Gregory CLEMENT <redacted>

In order to prepare the add of new SoCs supports for this cpuidle
driver, this patch extends the platform_data understood by the
cpuidle-mvebu-v7 driver to contain a "type" identifying which specific
SoC the cpuidle driver is being probed for. It will be used by the
cpuidle driver to know the list of states for the current SoC.
It makes more sense to use/implement a 'soc_is_xxx' macro or 
'of_machine_is_compatible', like the other cpuidle drivers, no ?

Is there a good reason to implement a new way to check the board ?
In all other subsystems, we try to do this per-device: We have almost
killed off all soc_is_* macros, and we strongly discourage anybody
from using of_machine_is_compatible() in driver code, as this goes
against the goals of multiplatform kernels on which we treat every
device as a separate thing that may get reused on any number of
machines or SoCs.
It isn't possible to do:

if (of_machine_is_compatible("marvell,armada-370-xp-pmsu"))
        cpuidle_register(&armadaxp_cpuidle_driver, NULL);

?

That will prevent the creation of the new single-declaration header file.
It would be best to have a way to read a property (or multiple
properties) from DT instead, to identify the requirements of the
device individually. However, I guess that would also require
changing the DT representation in an incompatible way, which we
normally don't.

	Arnd
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help