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
next prev parent 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).