From: Daniel Lezcano <daniel.lezcano-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
To: Len Brown <lenb-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
Cc: Lists Linaro-dev
<linaro-dev-cunTk1MwBs8s++Sfvej+rw@public.gmane.org>,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-pm-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Subject: Re: [PATCH 1/4] intel_idle: stop using driver_data for static flags
Date: Sat, 02 Feb 2013 10:44:17 +0100 [thread overview]
Message-ID: <510CDFF1.80408@linaro.org> (raw)
In-Reply-To: <510C7708.4080707-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
On 02/02/2013 03:16 AM, Len Brown wrote:
>
>>> intel_idle already uses a driver-specific flag:
>>>
>>> #define CPUIDLE_FLAG_TLB_FLUSHED 0x10000
>>>
>>> This patch just uses 4 more bits along with that one.
>>
>> Ok. In this case it would make sense to move this flag out of the
>> generic core code to the intel_idle.c file ?
>
> This flag is already local to intel_idle.c.
> If another architecture finds it useful,
> then yes, it would make sense to move it to the shared header.
Oh, right. Sorry I puzzled myself with the name. I was convinced it was
in the shared header.
>> and move the [dec/en]coding
>> macro flags_2_MWAIT_EAX and MWAIT_EAX_2_flags (with a more appropriate
>> name for a generic code) to the cpuidle.h file ?
>
> I think that a driver's private flag definitions
> should remain local to the driver. It makes no sense
> to pollute the name space of other drivers for stuff
> that doesn't mean anything to them. MWAIT is pretty
> specific to x86 -- and re-naming it to something 'generic'
> isn't going to make the code easier to read.
Ok, let me rephrase it because I think how it was presented was not clear.
As we want to use the half of the state flags for private purpose, I
suggested to add the encoding/decoding function in the shared header file.
The mwait eax flags are not encoded and the CPUIDLE_FLAG_TLB_FLUSHED is
encoded.
I suggested to unify both and to use an encoding function from the
shared header file.
#define CPUIDLE_PRIVATE_FLAGS(_flags_) \
((_flags_) << 16) & CPUIDLE_DRIVER_FLAGS_MASK
For example:
#define FLAG_TLB_FLUSHED CPUIDLE_PRIVATE_FLAGS(0x1)
#define FLAG_MWAIT_C1 CPUIDLE_PRIVATE_FLAGS(0x0)
#define FLAG_MWAIT_C2 CPUIDLE_PRIVATE_FLAGS(0x10)
#define FLAG_MWAIT_C3 CPUIDLE_PRIVATE_FLAGS(0x20)
#define FLAG_MWAIT_C4 CPUIDLE_PRIVATE_FLAGS(0x30)
#define FLAG_MWAIT_C5 CPUIDLE_PRIVATE_FLAGS(0x40)
#define FLAG_MWAIT_C6 CPUIDLE_PRIVATE_FLAGS(0x52)
And then:
...
.flags = FLAG_TLB_FLUSHED | FLAG_MWAIT_C2 | CPUIDLE_FLAG_TIME_VALID
...
But in the idle function, you need to retrieve the 'value' of the EAX
not a flag, so there is the need for an extra macro conversion and mask
the TLB flag.
Well, this is a detail, so feel free to ignore this suggestion :)
Thanks
-- 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
_______________________________________________
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
WARNING: multiple messages have this Message-ID (diff)
From: Daniel Lezcano <daniel.lezcano@linaro.org>
To: Len Brown <lenb@kernel.org>
Cc: linux-pm@vger.kernel.org, linux-kernel@vger.kernel.org,
Lists Linaro-dev <linaro-dev@lists.linaro.org>
Subject: Re: [PATCH 1/4] intel_idle: stop using driver_data for static flags
Date: Sat, 02 Feb 2013 10:44:17 +0100 [thread overview]
Message-ID: <510CDFF1.80408@linaro.org> (raw)
In-Reply-To: <510C7708.4080707@kernel.org>
On 02/02/2013 03:16 AM, Len Brown wrote:
>
>>> intel_idle already uses a driver-specific flag:
>>>
>>> #define CPUIDLE_FLAG_TLB_FLUSHED 0x10000
>>>
>>> This patch just uses 4 more bits along with that one.
>>
>> Ok. In this case it would make sense to move this flag out of the
>> generic core code to the intel_idle.c file ?
>
> This flag is already local to intel_idle.c.
> If another architecture finds it useful,
> then yes, it would make sense to move it to the shared header.
Oh, right. Sorry I puzzled myself with the name. I was convinced it was
in the shared header.
>> and move the [dec/en]coding
>> macro flags_2_MWAIT_EAX and MWAIT_EAX_2_flags (with a more appropriate
>> name for a generic code) to the cpuidle.h file ?
>
> I think that a driver's private flag definitions
> should remain local to the driver. It makes no sense
> to pollute the name space of other drivers for stuff
> that doesn't mean anything to them. MWAIT is pretty
> specific to x86 -- and re-naming it to something 'generic'
> isn't going to make the code easier to read.
Ok, let me rephrase it because I think how it was presented was not clear.
As we want to use the half of the state flags for private purpose, I
suggested to add the encoding/decoding function in the shared header file.
The mwait eax flags are not encoded and the CPUIDLE_FLAG_TLB_FLUSHED is
encoded.
I suggested to unify both and to use an encoding function from the
shared header file.
#define CPUIDLE_PRIVATE_FLAGS(_flags_) \
((_flags_) << 16) & CPUIDLE_DRIVER_FLAGS_MASK
For example:
#define FLAG_TLB_FLUSHED CPUIDLE_PRIVATE_FLAGS(0x1)
#define FLAG_MWAIT_C1 CPUIDLE_PRIVATE_FLAGS(0x0)
#define FLAG_MWAIT_C2 CPUIDLE_PRIVATE_FLAGS(0x10)
#define FLAG_MWAIT_C3 CPUIDLE_PRIVATE_FLAGS(0x20)
#define FLAG_MWAIT_C4 CPUIDLE_PRIVATE_FLAGS(0x30)
#define FLAG_MWAIT_C5 CPUIDLE_PRIVATE_FLAGS(0x40)
#define FLAG_MWAIT_C6 CPUIDLE_PRIVATE_FLAGS(0x52)
And then:
...
.flags = FLAG_TLB_FLUSHED | FLAG_MWAIT_C2 | CPUIDLE_FLAG_TIME_VALID
...
But in the idle function, you need to retrieve the 'value' of the EAX
not a flag, so there is the need for an extra macro conversion and mask
the TLB flag.
Well, this is a detail, so feel free to ignore this suggestion :)
Thanks
-- 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
next prev parent reply other threads:[~2013-02-02 9:44 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-02-01 4:11 intel_idle and turbostat patches supporting Haswell Len Brown
2013-02-01 4:11 ` [PATCH 1/4] intel_idle: stop using driver_data for static flags Len Brown
2013-02-01 4:11 ` [PATCH 2/4] tools/power turbostat: support HSW Len Brown
2013-02-01 4:11 ` [PATCH 3/4] tools/power turbostat: decode MSR_IA32_POWER_CTL Len Brown
2013-02-01 4:11 ` [PATCH 4/4] intel_idle: initial HSW support Len Brown
2013-02-01 8:44 ` [PATCH 1/4] intel_idle: stop using driver_data for static flags Daniel Lezcano
2013-02-01 18:40 ` Len Brown
2013-02-01 22:16 ` Daniel Lezcano
2013-02-02 2:16 ` Len Brown
[not found] ` <510C7708.4080707-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
2013-02-02 9:44 ` Daniel Lezcano [this message]
2013-02-02 9:44 ` Daniel Lezcano
2013-02-02 20:18 ` Len Brown
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=510CDFF1.80408@linaro.org \
--to=daniel.lezcano-qsej5fyqhm4dnm+yrofe0a@public.gmane.org \
--cc=lenb-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org \
--cc=linaro-dev-cunTk1MwBs8s++Sfvej+rw@public.gmane.org \
--cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=linux-pm-u79uwXL29TY76Z2rM5mHXA@public.gmane.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.