From: sudeep.holla@arm.com (Sudeep Holla)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v7 4/6] cpuidle: introduce HAVE_GENERIC_CPUIDLE_ENTER for ARM{32,64} platforms
Date: Thu, 7 Jul 2016 16:48:10 +0100 [thread overview]
Message-ID: <577E79BA.6000706@arm.com> (raw)
In-Reply-To: <3343646.556h6ef0ix@vostro.rjw.lan>
On 07/07/16 15:49, Rafael J. Wysocki wrote:
> On Thursday, July 07, 2016 02:34:36 PM Sudeep Holla wrote:
>>
>> On 07/07/16 14:21, Rafael J. Wysocki wrote:
>>> On Tuesday, June 28, 2016 02:55:50 PM Sudeep Holla wrote:
>>>> The function arm_enter_idle_state is exactly the same in both generic
>>>> ARM{32,64} CPUIdle driver and will be the same even on ARM64 backend
>>>> for ACPI processor idle driver. So we can unify it and move it as
>>>> generic_cpuidle_enter by introducing HAVE_GENERIC_CPUIDLE_ENTER and
>>>> enabling the same on both ARM{32,64}.
>>>>
>>>> This is in preparation of reuse of the generic cpuidle entry function
>>>> for ACPI LPI support on ARM64.
>>>>
>>>> Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net>
>>>> Cc: Daniel Lezcano <daniel.lezcano@linaro.org>
>>>> Cc: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
>>>> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
>>>> ---
>>>> arch/arm/Kconfig | 1 +
>>>> arch/arm/kernel/cpuidle.c | 4 ++--
>>>> arch/arm64/Kconfig | 1 +
>>>> arch/arm64/kernel/cpuidle.c | 6 +++---
>>>> drivers/cpuidle/Kconfig | 3 +++
>>>> drivers/cpuidle/cpuidle-arm.c | 21 +--------------------
>>>> drivers/cpuidle/cpuidle.c | 35 +++++++++++++++++++++++++++++++++++
>>>> include/linux/cpuidle.h | 8 ++++++++
>>>> 8 files changed, 54 insertions(+), 25 deletions(-)
>>>>
>>>> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
>>>> index 90542db1220d..52b3dca0381c 100644
>>>> --- a/arch/arm/Kconfig
>>>> +++ b/arch/arm/Kconfig
>>>> @@ -54,6 +54,7 @@ config ARM
>>>> select HAVE_FTRACE_MCOUNT_RECORD if (!XIP_KERNEL)
>>>> select HAVE_FUNCTION_GRAPH_TRACER if (!THUMB2_KERNEL)
>>>> select HAVE_FUNCTION_TRACER if (!XIP_KERNEL)
>>>> + select HAVE_GENERIC_CPUIDLE_ENTER
>>>
>>> That "generic" part in the name concerns me a bit, because the thing is not
>>> really generic. It is "common on ARM" rather.
>>>
>>
>> I agree and that's exactly what I told Daniel. It's rather just
>> *ARM Generic*. Any preference on the name ? I had it header file under
>> include/linu/cpuidle-arm.h in the previous version. Do you prefer that ?
>
> Well, I got confused by these names which probably means that they really
> are confusing. :-)
>
I know and I am all for getting rid of that.
> So the underlying observation is that ->enter() callbacks in some ARM code
> tend to do the same thing, ie. wrap the cpu_pm_enter()/exit() pair around
> the actual "low-level enter" routine, so the idea is to move the wrapping
> to the core and add the symbol plus standard header for the "low-level enter"
> thing.
>
> But then ->enter has to point to the wrapper and that just invokes a static
> function defined somewhere.
>
> So in fact what you want is to avoid code duplication in the source, but not
> in the binary.
>
> For that, I'd use a macro like this:
>
> #define CPU_IDLE_ENTER_WRAPPED(low_level_idle_enter, idx) \
> ({ \
> int __ret; \
> \
> if (!idx) { \
> cpu_do_idle(); \
> return idx; \
> } \
> \
> __ret = cpu_pm_enter(); \
> if (!__ret) { \
> __ret = low_level_idle_enter(idx); \
> cpu_pm_exit(); \
> } \
> \
> __ret ? -1 : idx; \
> })
>
> and then, whoever want's to generate a "wrapped" callback, will need to
> define the low_level_idle_enter thing, say my_low_level_idle_enter() and
> then do
>
> int idle_enter(int idx)
> {
> return CPU_IDLE_ENTER_WRAPPED(my_low_level_idle_enter, idx);
> }
>
> and point the ->enter callback to idle_enter().
>
> No need for extra symbols, confusing function names and similar.
>
> And the macro can go into cpuidle.h if you want.
>
Sounds good. Thanks for the suggestion. I will respin the series with
this change then.
--
Regards,
Sudeep
next prev parent reply other threads:[~2016-07-07 15:48 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-06-28 13:55 [PATCH v7 0/6] ACPI / processor_idle: Add ACPI v6.0 LPI support Sudeep Holla
2016-06-28 13:55 ` [PATCH v7 1/6] ACPI / processor_idle: introduce ACPI_PROCESSOR_CSTATE Sudeep Holla
2016-06-28 13:55 ` [PATCH v7 2/6] ACPI / processor_idle: Add support for Low Power Idle(LPI) states Sudeep Holla
2016-07-01 13:07 ` Daniel Lezcano
2016-07-04 13:00 ` Sudeep Holla
2016-07-04 13:17 ` Rafael J. Wysocki
2016-07-04 13:42 ` Sudeep Holla
2016-07-04 14:11 ` Rafael J. Wysocki
2016-06-28 13:55 ` [PATCH v7 3/6] arm64: cpuidle: drop __init section marker to arm_cpuidle_init Sudeep Holla
2016-06-28 13:55 ` [PATCH v7 4/6] cpuidle: introduce HAVE_GENERIC_CPUIDLE_ENTER for ARM{32, 64} platforms Sudeep Holla
2016-07-07 13:21 ` Rafael J. Wysocki
2016-07-07 13:34 ` [PATCH v7 4/6] cpuidle: introduce HAVE_GENERIC_CPUIDLE_ENTER for ARM{32,64} platforms Sudeep Holla
2016-07-07 14:49 ` [PATCH v7 4/6] cpuidle: introduce HAVE_GENERIC_CPUIDLE_ENTER for ARM{32, 64} platforms Rafael J. Wysocki
2016-07-07 15:48 ` Sudeep Holla [this message]
2016-06-28 13:55 ` [PATCH v7 5/6] arm64: add support for ACPI Low Power Idle(LPI) Sudeep Holla
2016-06-28 13:55 ` [PATCH v7 6/6] ACPI : enable ACPI_PROCESSOR_IDLE on ARM64 Sudeep Holla
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=577E79BA.6000706@arm.com \
--to=sudeep.holla@arm.com \
--cc=linux-arm-kernel@lists.infradead.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 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).