All of lore.kernel.org
 help / color / mirror / Atom feed
From: Daniel Lezcano <daniel.lezcano@linaro.org>
To: Jean Pihet <jean.pihet@newoldbits.com>
Cc: Kevin Hilman <khilman@ti.com>,
	linaro-dev@lists.linaro.org, linux-kernel@vger.kernel.org,
	linux-acpi@vger.kernel.org, linux-pm@lists.linux-foundation.org
Subject: Re: [RFC 1/4] cpuidle: define the enter function in the driver structure
Date: Wed, 13 Jun 2012 15:10:28 +0200	[thread overview]
Message-ID: <4FD89144.7000203@linaro.org> (raw)
In-Reply-To: <CAORVsuXEkyU_OkjqLDhe_OMq-uLEBaMLnz-pkJ1jtgnmcNxZpw@mail.gmail.com>

On 06/13/2012 02:44 PM, Jean Pihet wrote:
> Hi Daniel,
> 
> On Fri, Jun 8, 2012 at 11:34 PM, Daniel Lezcano
> <daniel.lezcano@linaro.org> wrote:
>> On 06/08/2012 07:33 PM, Deepthi Dharwar wrote:
>>> Hi Daniel,
>>
>> Hi Deepthi,
>>
>>> On 06/08/2012 09:32 PM, Daniel Lezcano wrote:
>>>
>>>> We have the state index passed as parameter to the 'enter' function.
>>>> Most of the drivers assign their 'enter' functions several times in
>>>> the cpuidle_state structure, as we have the index, we can delegate
>>>> to the driver to handle their own callback array.
>>>>
>>>> That will have the benefit of removing multiple lines of code in the
>>>> different drivers.
>>>>
>>>> In order to smoothly modify the driver, the 'enter' function are in
>>>> the driver structure and in the cpuidle state structure. That will
>>>> let the time to modify the different drivers one by one.
>>>> So the 'cpuidle_enter' function checks if the 'enter' callback is
>>>> assigned in the driver structure and use it, otherwise it invokes
>>>> the 'enter' assigned to the cpuidle_state.
>>>
>>>
>>> Currently, the backend driver initializes
>>> all the cpuidle states supported on the platform,
>>> and each state can have its own enter routine
>>> which can be unique This is a clean approach.
>>
>> Yes, I perfectly understood the purpose of this field but as clean it is
>> it does not make sense as it is not used in this way. If it is supposed
>> to be done in the way you are describing here, we should have the same
>> number of states and enter functions. Here it is how it is used:
>>
>>  --------------------------------------------------
>> | Arch             | nr states | nr enter function |
>>  --------------------------------------------------
>> | x86 (nehalem)    |    3      |         1         |
>>  --------------------------------------------------
>> | x86 (snb)        |    4      |         1         |
>>  --------------------------------------------------
>> | x86 (atom)       |    4      |         1         |
>>  --------------------------------------------------
>> | ARM tegra        |    1      |         1         |
>>  --------------------------------------------------
>> | ARM omap3        |    7      |         2         |
>>  --------------------------------------------------
>> | ARM omap4        |    3      |         1         |
>>  --------------------------------------------------
>> | ARM ux500        |    2      |         1         |
>>  --------------------------------------------------
>> | ARM shmobile     |    1      |         1         |
>>  --------------------------------------------------
>> | ARM davinci      |    2      |         1         |
>>  --------------------------------------------------
>> | ARM at91         |    2      |         1         |
>>  --------------------------------------------------
>> | ARM s3c64xx      |    1      |         1         |
>>  --------------------------------------------------
>> | ARM exynos       |    2      |         1         |
>>  --------------------------------------------------
>> | ARM kirkwood     |    2      |         1         |
>>  --------------------------------------------------
>> | SH               |    3      |         1         |
>>  --------------------------------------------------
>> | PPC              |    2      |         2         |
>>  --------------------------------------------------
>> |                  |           |                   |
>> | TOTAL            |    39     |        17         |
>> |                  |           |                   |
>>  --------------------------------------------------
>>
>>
>> As you can see most of the enter functions are only used as one.
>> The Omap3 cpuidle driver enter function for C2 calls the enter function
>> of C1. Other arch, already use a table of callbacks or the index.
> There is a plan to remove the extra enter function as part of an
> optimization, cf. [1]. The fix is planned to reach the 3.6 mainline
> kernel via Kevin's tree [2].
> 
> [1] http://marc.info/?l=linux-omap&m=133856365818099&w=2
> [2] http://git.kernel.org/?p=linux/kernel/git/khilman/linux-omap-pm.git;a=shortlog;h=refs/heads/for_3.6/pm/performance
> 
> The result is that there will be only one enter function for OMAP3.

Another argument in favor of moving this field to the driver structure.

Thanks Jean for the information.

  -- Daniel


-- 
 <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

_______________________________________________
linux-pm mailing list
linux-pm@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/linux-pm

WARNING: multiple messages have this Message-ID (diff)
From: Daniel Lezcano <daniel.lezcano@linaro.org>
To: Jean Pihet <jean.pihet@newoldbits.com>
Cc: Deepthi Dharwar <deepthi@linux.vnet.ibm.com>,
	linux-acpi@vger.kernel.org, linux-pm@lists.linux-foundation.org,
	linaro-dev@lists.linaro.org, linux-kernel@vger.kernel.org,
	Kevin Hilman <khilman@ti.com>
Subject: Re: [linux-pm] [RFC 1/4] cpuidle: define the enter function in the driver structure
Date: Wed, 13 Jun 2012 15:10:28 +0200	[thread overview]
Message-ID: <4FD89144.7000203@linaro.org> (raw)
In-Reply-To: <CAORVsuXEkyU_OkjqLDhe_OMq-uLEBaMLnz-pkJ1jtgnmcNxZpw@mail.gmail.com>

On 06/13/2012 02:44 PM, Jean Pihet wrote:
> Hi Daniel,
> 
> On Fri, Jun 8, 2012 at 11:34 PM, Daniel Lezcano
> <daniel.lezcano@linaro.org> wrote:
>> On 06/08/2012 07:33 PM, Deepthi Dharwar wrote:
>>> Hi Daniel,
>>
>> Hi Deepthi,
>>
>>> On 06/08/2012 09:32 PM, Daniel Lezcano wrote:
>>>
>>>> We have the state index passed as parameter to the 'enter' function.
>>>> Most of the drivers assign their 'enter' functions several times in
>>>> the cpuidle_state structure, as we have the index, we can delegate
>>>> to the driver to handle their own callback array.
>>>>
>>>> That will have the benefit of removing multiple lines of code in the
>>>> different drivers.
>>>>
>>>> In order to smoothly modify the driver, the 'enter' function are in
>>>> the driver structure and in the cpuidle state structure. That will
>>>> let the time to modify the different drivers one by one.
>>>> So the 'cpuidle_enter' function checks if the 'enter' callback is
>>>> assigned in the driver structure and use it, otherwise it invokes
>>>> the 'enter' assigned to the cpuidle_state.
>>>
>>>
>>> Currently, the backend driver initializes
>>> all the cpuidle states supported on the platform,
>>> and each state can have its own enter routine
>>> which can be unique This is a clean approach.
>>
>> Yes, I perfectly understood the purpose of this field but as clean it is
>> it does not make sense as it is not used in this way. If it is supposed
>> to be done in the way you are describing here, we should have the same
>> number of states and enter functions. Here it is how it is used:
>>
>>  --------------------------------------------------
>> | Arch             | nr states | nr enter function |
>>  --------------------------------------------------
>> | x86 (nehalem)    |    3      |         1         |
>>  --------------------------------------------------
>> | x86 (snb)        |    4      |         1         |
>>  --------------------------------------------------
>> | x86 (atom)       |    4      |         1         |
>>  --------------------------------------------------
>> | ARM tegra        |    1      |         1         |
>>  --------------------------------------------------
>> | ARM omap3        |    7      |         2         |
>>  --------------------------------------------------
>> | ARM omap4        |    3      |         1         |
>>  --------------------------------------------------
>> | ARM ux500        |    2      |         1         |
>>  --------------------------------------------------
>> | ARM shmobile     |    1      |         1         |
>>  --------------------------------------------------
>> | ARM davinci      |    2      |         1         |
>>  --------------------------------------------------
>> | ARM at91         |    2      |         1         |
>>  --------------------------------------------------
>> | ARM s3c64xx      |    1      |         1         |
>>  --------------------------------------------------
>> | ARM exynos       |    2      |         1         |
>>  --------------------------------------------------
>> | ARM kirkwood     |    2      |         1         |
>>  --------------------------------------------------
>> | SH               |    3      |         1         |
>>  --------------------------------------------------
>> | PPC              |    2      |         2         |
>>  --------------------------------------------------
>> |                  |           |                   |
>> | TOTAL            |    39     |        17         |
>> |                  |           |                   |
>>  --------------------------------------------------
>>
>>
>> As you can see most of the enter functions are only used as one.
>> The Omap3 cpuidle driver enter function for C2 calls the enter function
>> of C1. Other arch, already use a table of callbacks or the index.
> There is a plan to remove the extra enter function as part of an
> optimization, cf. [1]. The fix is planned to reach the 3.6 mainline
> kernel via Kevin's tree [2].
> 
> [1] http://marc.info/?l=linux-omap&m=133856365818099&w=2
> [2] http://git.kernel.org/?p=linux/kernel/git/khilman/linux-omap-pm.git;a=shortlog;h=refs/heads/for_3.6/pm/performance
> 
> The result is that there will be only one enter function for OMAP3.

Another argument in favor of moving this field to the driver structure.

Thanks Jean for the information.

  -- Daniel


-- 
 <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:[~2012-06-13 13:10 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-06-08 16:02 [RFC 1/4] cpuidle: define the enter function in the driver structure Daniel Lezcano
2012-06-08 16:02 ` [RFC 2/4] cpuidle: move enter_dead to " Daniel Lezcano
2012-06-08 16:02   ` Daniel Lezcano
2012-06-08 16:02 ` [RFC 3/4] cpuidle : move tlb flag to the cpuidle header Daniel Lezcano
     [not found] ` <1339171365-4098-1-git-send-email-daniel.lezcano-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
2012-06-08 16:02   ` [RFC 4/4] cpuidle: replace the 'disable' field by a flag Daniel Lezcano
2012-06-08 16:02     ` Daniel Lezcano
2012-06-08 17:33 ` [linux-pm] [RFC 1/4] cpuidle: define the enter function in the driver structure Deepthi Dharwar
2012-06-08 21:34   ` Daniel Lezcano
2012-06-08 21:34     ` [linux-pm] " Daniel Lezcano
     [not found]     ` <4FD27000.7000208-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
2012-06-13 12:44       ` Jean Pihet
2012-06-13 12:44         ` Jean Pihet
2012-06-13 13:10         ` Daniel Lezcano [this message]
2012-06-13 13:10           ` Daniel Lezcano
2012-06-14  7:49 ` Namhyung Kim
2012-06-14  8:16   ` Daniel Lezcano
2012-06-14  8:16     ` Daniel Lezcano

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=4FD89144.7000203@linaro.org \
    --to=daniel.lezcano@linaro.org \
    --cc=jean.pihet@newoldbits.com \
    --cc=khilman@ti.com \
    --cc=linaro-dev@lists.linaro.org \
    --cc=linux-acpi@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pm@lists.linux-foundation.org \
    /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.