From: Gautham R Shenoy <ego@linux.vnet.ibm.com>
To: Pratik Rajesh Sampat <psampat@linux.ibm.com>
Cc: ego@linux.vnet.ibm.com, mikey@neuling.org,
pratik.r.sampat@gmail.com, vaidy@linux.ibm.com,
linux-kernel@vger.kernel.org, npiggin@gmail.com,
linuxppc-dev@ozlabs.org, oohall@gmail.com,
skiboot@lists.ozlabs.org
Subject: Re: [RFC] Support stop state version quirk and firmware enabled stop
Date: Wed, 8 Apr 2020 15:20:33 +0530 [thread overview]
Message-ID: <20200408095033.GC950@in.ibm.com> (raw)
In-Reply-To: <20200304155648.11501-1-psampat@linux.ibm.com>
Hi Pratik,
On Wed, Mar 04, 2020 at 09:26:48PM +0530, Pratik Rajesh Sampat wrote:
> A concept patch in Skiboot to illustrate the case wherein handling of
> stop states for different DD versions of a CPU can be achieved by a
> simple modification in the list of cpu_features.
> As an example idle-stop1 is defined which uses P9_CPU_DD1 to define the
> cpu feature.
>
> Along with that, an implementation is being worked upon the LE OPAL
> series which helps OPAL handle the stop state entry and exit.
>
> This patch advertises this capability of the firmware which can be
> availed if the quirk-version-setting is not cognizable.
>
> The firmware-enabled stop is being worked by Abhishek Goel
> <huntbag@linux.vnet.ibm.com> building upon the LE OPAL series.
>
> Signed-off-by: Pratik Rajesh Sampat <psampat@linux.ibm.com>
> ---
> core/cpufeatures.c | 22 ++++++++++++++++++++++
> 1 file changed, 22 insertions(+)
>
> diff --git a/core/cpufeatures.c b/core/cpufeatures.c
> index ec30c975..b9875e7b 100644
> --- a/core/cpufeatures.c
> +++ b/core/cpufeatures.c
> @@ -510,6 +510,25 @@ static const struct cpu_feature cpu_features_table[] = {
> -1, -1, -1,
> NULL, },
>
> + /*
> + * QUIRK for ISAv3.0B stop idle instructions and registers
> + * Helps us determine if there are any quirks
> + * XXX: Same of idle-stop
> + */
> + { "idle-stop-v1",
> + CPU_P9_DD1,
> + ISA_V3_0B, USABLE_HV|USABLE_OS,
> + HV_CUSTOM, OS_CUSTOM,
> + -1, -1, -1,
> + NULL, },
So, at this point, we don't need any such quirk for any of the DD
version right ? This is to demonstrate that if say P9_DD1 had a quirk
w.r.t stop-state handling, then this is how we would advertise it to
the kernel.
> +
> + { "firmware-stop-supported",
> + CPU_P9,
> + ISA_V3_0B, USABLE_HV|USABLE_OS,
> + HV_CUSTOM, OS_CUSTOM,
> + -1, -1, -1,
> + NULL, },
> +
I suppose this is for the opal-cpuidle driver support posted here:
https://lists.ozlabs.org/pipermail/skiboot/2020-April/016726.html
> /*
> * ISAv3.0B Hypervisor Virtualization Interrupt
> * Also associated system registers, LPCR EE, HEIC, HVICE,
> @@ -883,6 +902,9 @@ static void add_cpufeatures(struct dt_node *cpus,
> const struct cpu_feature *f = &cpu_features_table[i];
>
> if (f->cpus_supported & cpu_feature_cpu) {
> + if (!strcmp(f->name, "firmware-stop-supported") &&
> + HAVE_BIG_ENDIAN)
> + continue;
In OPAL do we have an macro defining BIG_ENDIAN ? If yes, you could
wrap the "firmware-stop-supported" in cpu_features_table[] within
#ifndef BIG_ENDIAN. That way you won't need a special case here.
> DBG(" '%s'\n", f->name);
> add_cpu_feature_nodeps(features, f);
> }
> --
> 2.24.1
>
--
Thanks and Regards
gautham.
WARNING: multiple messages have this Message-ID (diff)
From: Gautham R Shenoy <ego@linux.vnet.ibm.com>
To: Pratik Rajesh Sampat <psampat@linux.ibm.com>
Cc: skiboot@lists.ozlabs.org, oohall@gmail.com, mikey@neuling.org,
npiggin@gmail.com, vaidy@linux.ibm.com, ego@linux.vnet.ibm.com,
linuxppc-dev@ozlabs.org, linux-kernel@vger.kernel.org,
mpe@ellerman.id.au, pratik.r.sampat@gmail.com
Subject: Re: [RFC] Support stop state version quirk and firmware enabled stop
Date: Wed, 8 Apr 2020 15:20:33 +0530 [thread overview]
Message-ID: <20200408095033.GC950@in.ibm.com> (raw)
In-Reply-To: <20200304155648.11501-1-psampat@linux.ibm.com>
Hi Pratik,
On Wed, Mar 04, 2020 at 09:26:48PM +0530, Pratik Rajesh Sampat wrote:
> A concept patch in Skiboot to illustrate the case wherein handling of
> stop states for different DD versions of a CPU can be achieved by a
> simple modification in the list of cpu_features.
> As an example idle-stop1 is defined which uses P9_CPU_DD1 to define the
> cpu feature.
>
> Along with that, an implementation is being worked upon the LE OPAL
> series which helps OPAL handle the stop state entry and exit.
>
> This patch advertises this capability of the firmware which can be
> availed if the quirk-version-setting is not cognizable.
>
> The firmware-enabled stop is being worked by Abhishek Goel
> <huntbag@linux.vnet.ibm.com> building upon the LE OPAL series.
>
> Signed-off-by: Pratik Rajesh Sampat <psampat@linux.ibm.com>
> ---
> core/cpufeatures.c | 22 ++++++++++++++++++++++
> 1 file changed, 22 insertions(+)
>
> diff --git a/core/cpufeatures.c b/core/cpufeatures.c
> index ec30c975..b9875e7b 100644
> --- a/core/cpufeatures.c
> +++ b/core/cpufeatures.c
> @@ -510,6 +510,25 @@ static const struct cpu_feature cpu_features_table[] = {
> -1, -1, -1,
> NULL, },
>
> + /*
> + * QUIRK for ISAv3.0B stop idle instructions and registers
> + * Helps us determine if there are any quirks
> + * XXX: Same of idle-stop
> + */
> + { "idle-stop-v1",
> + CPU_P9_DD1,
> + ISA_V3_0B, USABLE_HV|USABLE_OS,
> + HV_CUSTOM, OS_CUSTOM,
> + -1, -1, -1,
> + NULL, },
So, at this point, we don't need any such quirk for any of the DD
version right ? This is to demonstrate that if say P9_DD1 had a quirk
w.r.t stop-state handling, then this is how we would advertise it to
the kernel.
> +
> + { "firmware-stop-supported",
> + CPU_P9,
> + ISA_V3_0B, USABLE_HV|USABLE_OS,
> + HV_CUSTOM, OS_CUSTOM,
> + -1, -1, -1,
> + NULL, },
> +
I suppose this is for the opal-cpuidle driver support posted here:
https://lists.ozlabs.org/pipermail/skiboot/2020-April/016726.html
> /*
> * ISAv3.0B Hypervisor Virtualization Interrupt
> * Also associated system registers, LPCR EE, HEIC, HVICE,
> @@ -883,6 +902,9 @@ static void add_cpufeatures(struct dt_node *cpus,
> const struct cpu_feature *f = &cpu_features_table[i];
>
> if (f->cpus_supported & cpu_feature_cpu) {
> + if (!strcmp(f->name, "firmware-stop-supported") &&
> + HAVE_BIG_ENDIAN)
> + continue;
In OPAL do we have an macro defining BIG_ENDIAN ? If yes, you could
wrap the "firmware-stop-supported" in cpu_features_table[] within
#ifndef BIG_ENDIAN. That way you won't need a special case here.
> DBG(" '%s'\n", f->name);
> add_cpu_feature_nodeps(features, f);
> }
> --
> 2.24.1
>
--
Thanks and Regards
gautham.
next prev parent reply other threads:[~2020-04-08 9:53 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-03-04 15:56 [RFC] Support stop state version quirk and firmware enabled stop Pratik Rajesh Sampat
2020-04-08 9:50 ` Gautham R Shenoy [this message]
2020-04-08 9:50 ` Gautham R Shenoy
2020-04-12 12:06 ` Pratik Sampat
2020-04-12 12:06 ` Pratik Sampat
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=20200408095033.GC950@in.ibm.com \
--to=ego@linux.vnet.ibm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linuxppc-dev@ozlabs.org \
--cc=mikey@neuling.org \
--cc=npiggin@gmail.com \
--cc=oohall@gmail.com \
--cc=pratik.r.sampat@gmail.com \
--cc=psampat@linux.ibm.com \
--cc=skiboot@lists.ozlabs.org \
--cc=vaidy@linux.ibm.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.