linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Daniel Lezcano <daniel.lezcano@linaro.org>
To: Preeti U Murthy <preeti@linux.vnet.ibm.com>
Cc: mingo@kernel.org, peterz@infradead.org, tglx@linutronix.de,
	rjw@rjwysocki.net, nicolas.pitre@linaro.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH 1/5] idle/cpuidle: Split cpuidle_idle_call main function into smaller functions
Date: Wed, 12 Feb 2014 13:37:55 +0100	[thread overview]
Message-ID: <52FB6B23.5090901@linaro.org> (raw)
In-Reply-To: <52FB4F1D.9030303@linux.vnet.ibm.com>

On 02/12/2014 11:38 AM, Preeti U Murthy wrote:
> Hi Daniel,
>
> On 02/11/2014 08:41 PM, Daniel Lezcano wrote:
>> In order to allow better integration between the cpuidle framework and the
>> scheduler, reducing the distance between these two sub-components will
>> facilitate this integration by moving part of the cpuidle code in the idle
>> task file and, because idle.c is in the sched directory, we have access to
>> the scheduler's private structures.
>>
>> This patch splits the cpuidle_idle_call main entry function into 3 calls
>> to a newly added API:
>>   1. select the idle state
>>   2. enter the idle state
>>   3. reflect the idle state
>>
>> The cpuidle_idle_call calls these three functions to implement the main
>> idle entry function.
>>
>> Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
>> ---
>>   drivers/cpuidle/cpuidle.c |  102 ++++++++++++++++++++++++++++++++-------------
>>   include/linux/cpuidle.h   |   14 +++++++
>>   2 files changed, 87 insertions(+), 29 deletions(-)
>>
>> diff --git a/drivers/cpuidle/cpuidle.c b/drivers/cpuidle/cpuidle.c
>> index a55e68f..172ab6a 100644
>> --- a/drivers/cpuidle/cpuidle.c
>> +++ b/drivers/cpuidle/cpuidle.c
>> @@ -108,6 +108,71 @@ int cpuidle_enter_state(struct cpuidle_device *dev, struct cpuidle_driver *drv,
>>   }
>>
>>   /**
>> + * cpuidle_select - ask the cpuidle framework to choose an idle state
>> + *
>> + * @drv: the cpuidle driver
>> + * @dev: the cpuidle device
>> + *
>> + * Returns the index of the idle state. On error it returns:
>> + * -NODEV : the cpuidle framework is not available
>> + * -EBUSY : the cpuidle framework is not initialized
>> + */
>> +int cpuidle_select(struct cpuidle_driver *drv, struct cpuidle_device *dev)
>> +{
>> +	if (off || !initialized)
>> +		return -ENODEV;
>> +
>> +	if (!drv || !dev || !dev->enabled)
>> +		return -EBUSY;
>
> I would suggest moving the above two conditions under another function,
> cpuidle_enabled() maybe? The reason is, cpuidle_select() indicates that,
> it is invoked to select an idle state. While you are expecting this
> function to return an idle state, it seems counter-intuitive to return a
> ENODEV/EBUSY. This function is expected to be a call into the governor
> specific code and the same function should not be used to verify if
> cpuidle is enabled/not IMHO.

Yes, I fully agree. I will fix that.

>> +
>> +	return cpuidle_curr_governor->select(drv, dev);
>> +}
>> +
>> +/**
>> + * cpuidle_enter - enter into the specified idle state
>> + *
>> + * @drv:   the cpuidle driver tied with the cpu
>> + * @dev:   the cpuidle device
>> + * @index: the index in the idle state table
>> + *
>> + * Returns the index in the idle state, < 0 in case of error.
>> + * The error code depends on the backend driver
>> + */
>> +int cpuidle_enter(struct cpuidle_driver *drv, struct cpuidle_device *dev,
>> +		  int index)
>> +{
>> +	int entered_state;
>> +	bool broadcast = !!(drv->states[index].flags & CPUIDLE_FLAG_TIMER_STOP);
>> +
>> +	if (broadcast)
>> +		clockevents_notify(CLOCK_EVT_NOTIFY_BROADCAST_ENTER, &dev->cpu);
>> +
>> +	if (cpuidle_state_is_coupled(dev, drv, index))
>> +		entered_state = cpuidle_enter_state_coupled(dev, drv, index);
>> +	else
>> +		entered_state = cpuidle_enter_state(dev, drv, index);
>> +
>> +	if (broadcast)
>> +		clockevents_notify(CLOCK_EVT_NOTIFY_BROADCAST_EXIT, &dev->cpu);
>
> The tip tree, timers/core branch has the patch,
> tick: Introduce hrtimer based broadcast. In the problem scenario that
> this patchset is addressing, the call to broadcast framework may return
> an error indicating that the idle state in question cannot be entered
> into. I wanted to bring it to your notice, so that early on you can take
> care of this. You will need to add code below in the invocation of
> cpuidle_enter() to verify if the idle state was entered into or not. If
> it was not, then you will need to skip tracing and reflecting of the
> idle state and directly exit the cpuidle loop with a failed status.

Ok.

Thanks !


-- 
  <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-02-12 12:37 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-02-11 15:11 [PATCH 1/5] idle/cpuidle: Split cpuidle_idle_call main function into smaller functions Daniel Lezcano
2014-02-11 15:11 ` [PATCH 2/5] cpuidle/idle: Move the cpuidle_idle_call function to idle.c Daniel Lezcano
2014-02-12 10:43   ` Preeti U Murthy
2014-02-12 12:35     ` Daniel Lezcano
2014-02-11 15:11 ` [PATCH 3/5] idle: Reorganize the idle loop Daniel Lezcano
2014-02-11 17:36   ` Nicolas Pitre
2014-02-12 11:00   ` Preeti U Murthy
2014-02-12 12:45     ` Daniel Lezcano
2014-02-11 15:11 ` [PATCH 4/5] idle: Move idle conditions in cpuidle_idle main function Daniel Lezcano
2014-02-11 15:11 ` [PATCH 5/5] idle: Add more comments to the code Daniel Lezcano
2014-02-11 17:51   ` Nicolas Pitre
2014-02-11 21:52     ` Daniel Lezcano
2014-02-11 17:27 ` [PATCH 1/5] idle/cpuidle: Split cpuidle_idle_call main function into smaller functions Nicolas Pitre
2014-02-12 10:38 ` Preeti U Murthy
2014-02-12 12:37   ` Daniel Lezcano [this message]

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=52FB6B23.5090901@linaro.org \
    --to=daniel.lezcano@linaro.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@kernel.org \
    --cc=nicolas.pitre@linaro.org \
    --cc=peterz@infradead.org \
    --cc=preeti@linux.vnet.ibm.com \
    --cc=rjw@rjwysocki.net \
    --cc=tglx@linutronix.de \
    /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).