linux-pm.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Daniel Lezcano <daniel.lezcano@linaro.org>
To: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>,
	Arnd Bergmann <arnd@arndb.de>
Cc: linux-arm-kernel@lists.infradead.org,
	Lior Amsalem <alior@marvell.com>, Andrew Lunn <andrew@lunn.ch>,
	Jason Cooper <jason@lakedaemon.net>,
	Tawfik Bayouk <tawfik@marvell.com>,
	linux-pm@vger.kernel.org, "Rafael J. Wysocki" <rjw@rjwysocki.net>,
	Nadav Haklai <nadavh@marvell.com>,
	Ezequiel Garcia <ezequiel.garcia@free-electrons.com>,
	Gregory Clement <gregory.clement@free-electrons.com>,
	Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
Subject: Re: [PATCHv2 12/17] cpuidle: mvebu: make the cpuidle driver capable of handling multiple SoCs
Date: Mon, 21 Jul 2014 14:34:23 +0200	[thread overview]
Message-ID: <53CD08CF.6080900@linaro.org> (raw)
In-Reply-To: <20140721140917.16e71558@free-electrons.com>

On 07/21/2014 02:09 PM, Thomas Petazzoni wrote:
> Dear Arnd Bergmann,
>
> On Mon, 21 Jul 2014 14:00:22 +0200, Arnd Bergmann wrote:
>
>> I don't know, it really depends on what the differences are between
>> the SoCs, and I haven't looked at them.
>>
>> Using the compatible strings would make it work best if you have one
>> driver per variant, and then share some common code, as opposed to
>> having one shared driver with a number of exceptions.
>>
>> If the differences are just a few parameters, it might be better
>> to encode those parameters in DT properties instead.
>
> The differences are in the cpuidle states that are supported, see
> patches "cpuidle: mvebu: add Armada 370 support" and "cpuidle: mvebu:
> add Armada 38x support" in the series.
>
> I honestly believe that since cpuidle functionality is not described in
> the Device Tree and therefore probed using a statically defined
> platform_device, the good way to pass these informations is to simply
> use platform_data.

Ok, so for the record the cpuidle functionality described via DT is 
under discussion [1].

I understand you need several drivers for the different SoC because of 
the different latencies.

I admit passing an extra flag via the platform_data is a valid approach 
but I have been unifying the different drivers across the existing SoC 
and there is still a lot of things to do. So accepting this patch brings 
another way to discriminate the SoC variant I would like to avoid.

Due the different latencies, I don't think the DT property is enough and 
that may enter in conflict with Lorenzo's work.

So there are three solutions:

1. Pass the flag through the platform data, I am not really in favor of 
that as mentioned above

2. Use the compatible string like the cpuidle-big-little.c driver, but 
Arnd is not in favor of that

3. Register 3 platform drivers, in cpuidle-mvebu-v7.c, and let the 
registering of the cpuidle's platform device to enable the right one


[1] http://www.spinics.net/lists/arm-kernel/msg341541.html


-- 
  <http://www.linaro.org/> Linaro.org │ Open source software for ARM SoCs

Follow Linaro:  <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog


  reply	other threads:[~2014-07-21 12:34 UTC|newest]

Thread overview: 40+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-07-09 13:40 [PATCHv2 00/17] cpuidle for Marvell Armada 370 and 38x Thomas Petazzoni
2014-07-09 13:40 ` [PATCHv2 01/17] ARM: mvebu: split again armada_370_xp_pmsu_idle_enter() in PMSU code Thomas Petazzoni
2014-07-09 13:40 ` [PATCHv2 02/17] ARM: mvebu: sort the #include of pmsu.c in alphabetic order Thomas Petazzoni
2014-07-09 13:40 ` [PATCHv2 03/17] ARM: mvebu: add a common function for the boot address work around Thomas Petazzoni
2014-07-09 13:40 ` [PATCHv2 04/17] ARM: mvebu: use the common function for Armada 375 SMP workaround Thomas Petazzoni
2014-07-09 13:40 ` [PATCHv2 05/17] ARM: mvebu: rename the armada_370_xp symbols to mvebu_v7 in pmsu.c Thomas Petazzoni
2014-07-09 13:40 ` [PATCHv2 06/17] ARM: mvebu: make the cpuidle initialization more generic Thomas Petazzoni
2014-07-09 13:40 ` [PATCHv2 07/17] ARM: mvebu: use a local variable to store the resume address Thomas Petazzoni
2014-07-09 13:40 ` [PATCHv2 08/17] ARM: mvebu: make the snoop disabling optional in mvebu_v7_pmsu_idle_prepare() Thomas Petazzoni
2014-07-09 13:40 ` [PATCHv2 09/17] ARM: mvebu: export the SCU address Thomas Petazzoni
2014-07-09 13:40 ` [PATCHv2 10/17] ARM: mvebu: add CA9 MPcore SoC Controller node Thomas Petazzoni
2014-07-09 13:40 ` [PATCHv2 11/17] cpuidle: mvebu: rename the driver from armada-370-xp to mvebu-v7 Thomas Petazzoni
2014-07-21  9:59   ` Daniel Lezcano
2014-07-09 13:40 ` [PATCHv2 12/17] cpuidle: mvebu: make the cpuidle driver capable of handling multiple SoCs Thomas Petazzoni
2014-07-21 10:59   ` Daniel Lezcano
2014-07-21 11:12     ` Thomas Petazzoni
2014-07-21 11:16     ` Arnd Bergmann
2014-07-21 11:19       ` Thomas Petazzoni
2014-07-21 11:30         ` Arnd Bergmann
2014-07-21 11:35           ` Thomas Petazzoni
2014-07-21 12:00             ` Arnd Bergmann
2014-07-21 12:09               ` Thomas Petazzoni
2014-07-21 12:34                 ` Daniel Lezcano [this message]
2014-07-21 12:38                   ` Thomas Petazzoni
2014-07-21 12:51                     ` Arnd Bergmann
2014-07-21 13:12                     ` Daniel Lezcano
2014-07-09 13:40 ` [PATCHv2 13/17] cpuidle: mvebu: add Armada 370 support Thomas Petazzoni
2014-07-09 13:40 ` [PATCHv2 14/17] cpuidle: mvebu: add Armada 38x support Thomas Petazzoni
2014-07-09 13:40 ` [PATCHv2 15/17] ARM: mvebu: add cpuidle support for Armada 370 Thomas Petazzoni
2014-07-09 13:40 ` [PATCHv2 16/17] ARM: mvebu: add cpuidle support for Armada 38x Thomas Petazzoni
2014-07-09 13:40 ` [PATCHv2 17/17] ARM: mvebu: defconfig: enable cpuidle support in mvebu_v7_defconfig Thomas Petazzoni
2014-07-13 22:22 ` [PATCHv2 00/17] cpuidle for Marvell Armada 370 and 38x Jason Cooper
2014-07-16 12:45   ` Jason Cooper
2014-07-16 12:59     ` Thomas Petazzoni
2014-07-16 13:10       ` Jason Cooper
2014-07-16 13:16       ` Jason Cooper
2014-07-16 13:19         ` Thomas Petazzoni
2014-07-16 13:27           ` Jason Cooper
2014-07-16 13:28             ` Thomas Petazzoni
2014-07-16 22:18   ` Rafael J. Wysocki

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=53CD08CF.6080900@linaro.org \
    --to=daniel.lezcano@linaro.org \
    --cc=alior@marvell.com \
    --cc=andrew@lunn.ch \
    --cc=arnd@arndb.de \
    --cc=ezequiel.garcia@free-electrons.com \
    --cc=gregory.clement@free-electrons.com \
    --cc=jason@lakedaemon.net \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-pm@vger.kernel.org \
    --cc=nadavh@marvell.com \
    --cc=rjw@rjwysocki.net \
    --cc=sebastian.hesselbarth@gmail.com \
    --cc=tawfik@marvell.com \
    --cc=thomas.petazzoni@free-electrons.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).