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
WARNING: multiple messages have this Message-ID (diff)
From: daniel.lezcano@linaro.org (Daniel Lezcano)
To: linux-arm-kernel@lists.infradead.org
Subject: [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: 80+ 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 ` 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 ` 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 ` 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 ` 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 ` 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 ` 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 ` 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 ` 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 ` Thomas Petazzoni
2014-07-09 13:40 ` [PATCHv2 09/17] ARM: mvebu: export the SCU address Thomas Petazzoni
2014-07-09 13:40 ` 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 ` 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-09 13:40 ` Thomas Petazzoni
2014-07-21 9:59 ` Daniel Lezcano
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-09 13:40 ` Thomas Petazzoni
2014-07-21 10:59 ` Daniel Lezcano
2014-07-21 10:59 ` Daniel Lezcano
2014-07-21 11:12 ` Thomas Petazzoni
2014-07-21 11:12 ` Thomas Petazzoni
2014-07-21 11:16 ` Arnd Bergmann
2014-07-21 11:16 ` Arnd Bergmann
2014-07-21 11:19 ` Thomas Petazzoni
2014-07-21 11:19 ` Thomas Petazzoni
2014-07-21 11:30 ` Arnd Bergmann
2014-07-21 11:30 ` Arnd Bergmann
2014-07-21 11:35 ` Thomas Petazzoni
2014-07-21 11:35 ` Thomas Petazzoni
2014-07-21 12:00 ` Arnd Bergmann
2014-07-21 12:00 ` Arnd Bergmann
2014-07-21 12:09 ` Thomas Petazzoni
2014-07-21 12:09 ` Thomas Petazzoni
2014-07-21 12:34 ` Daniel Lezcano [this message]
2014-07-21 12:34 ` Daniel Lezcano
2014-07-21 12:38 ` Thomas Petazzoni
2014-07-21 12:38 ` Thomas Petazzoni
2014-07-21 12:51 ` Arnd Bergmann
2014-07-21 12:51 ` Arnd Bergmann
2014-07-21 13:12 ` Daniel Lezcano
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 ` Thomas Petazzoni
2014-07-09 13:40 ` [PATCHv2 14/17] cpuidle: mvebu: add Armada 38x support Thomas Petazzoni
2014-07-09 13:40 ` 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 ` 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 ` Thomas Petazzoni
2014-07-09 13:40 ` [PATCHv2 17/17] ARM: mvebu: defconfig: enable cpuidle support in mvebu_v7_defconfig Thomas Petazzoni
2014-07-09 13:40 ` Thomas Petazzoni
2014-07-13 22:22 ` [PATCHv2 00/17] cpuidle for Marvell Armada 370 and 38x Jason Cooper
2014-07-13 22:22 ` Jason Cooper
2014-07-16 12:45 ` Jason Cooper
2014-07-16 12:45 ` Jason Cooper
2014-07-16 12:59 ` Thomas Petazzoni
2014-07-16 12:59 ` Thomas Petazzoni
2014-07-16 13:10 ` Jason Cooper
2014-07-16 13:10 ` Jason Cooper
2014-07-16 13:16 ` Jason Cooper
2014-07-16 13:16 ` Jason Cooper
2014-07-16 13:19 ` Thomas Petazzoni
2014-07-16 13:19 ` Thomas Petazzoni
2014-07-16 13:27 ` Jason Cooper
2014-07-16 13:27 ` Jason Cooper
2014-07-16 13:28 ` Thomas Petazzoni
2014-07-16 13:28 ` Thomas Petazzoni
2014-07-16 22:18 ` Rafael J. Wysocki
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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.