diff for duplicates of <1375316635.30721.122@snotra> diff --git a/a/1.txt b/N1/1.txt index 9a3b94c..2e00975 100644 --- a/a/1.txt +++ b/N1/1.txt @@ -1,16 +1,16 @@ On 07/31/2013 01:30:06 AM, Wang Dongsheng-B40534 wrote: -> -> +>=20 +>=20 > > -----Original Message----- > > From: Wood Scott-B07421 > > Sent: Wednesday, July 31, 2013 3:38 AM > > To: Wang Dongsheng-B40534 -> > Cc: rjw@sisk.pl; daniel.lezcano@linaro.org; +> > Cc: rjw@sisk.pl; daniel.lezcano@linaro.org; =20 > benh@kernel.crashing.org; Li -> > Yang-R58472; Zhao Chenhui-B35336; linux-pm@vger.kernel.org; +> > Yang-R58472; Zhao Chenhui-B35336; linux-pm@vger.kernel.org; =20 > linuxppc- > > dev@lists.ozlabs.org -> > Subject: Re: [PATCH] cpuidle: add freescale e500 family porcessors +> > Subject: Re: [PATCH] cpuidle: add freescale e500 family porcessors =20 > idle > > support > > @@ -27,53 +27,53 @@ On 07/31/2013 01:30:06 AM, Wang Dongsheng-B40534 wrote: > > Could you explain what the cpuidle framework does for us that the > > current idle code doesn't? > > -> -> The current idle code, Only a state of low power can make the core +>=20 +> The current idle code, Only a state of low power can make the core =20 > idle. > The core can't get into more low power state. -> +>=20 > > In particular, what scenario do you see where we would require a > > software > > governor to choose between idle states, and how much power is saved > > compared to a simpler approach? There is timer that can be used to > > automatically enter PW20 after a certain amount of time in PW10. -> -> Yes, the hardware can automatically enter PW20 state. But this is +>=20 +> Yes, the hardware can automatically enter PW20 state. But this is =20 > hardware -> feature, we need to software to manage it. Only for PW20 state, we +> feature, we need to software to manage it. Only for PW20 state, we =20 > can drop -> this cpuidle and using the hardware to control it. But if we need to +> this cpuidle and using the hardware to control it. But if we need to =20 > support > PH10/PH15/PH20/PH30, the current idle code cannot support them. -PH30 wasn't really meant as idle state, but rather a CPU hotplug -state. This isn't just about enter/exit latency (and complexity) but +PH30 wasn't really meant as idle state, but rather a CPU hotplug =20 +state. This isn't just about enter/exit latency (and complexity) but =20 also about wakeup events. -PH15 and PH20 were mainly intended as intermediate states on the way to -PH30 or debug halt. It looks like PH15 is the deepest PH state in +PH15 and PH20 were mainly intended as intermediate states on the way to =20 +PH30 or debug halt. It looks like PH15 is the deepest PH state in =20 which core timers continue to run. The intended idle states on e6500 are PW10 and PW20. -> > How much better results do you get from a software governor? Do we +> > How much better results do you get from a software governor? Do we =20 > even -> > have the right data to characterize each state so that a software +> > have the right data to characterize each state so that a software =20 > governor -> > could make good decisions? Is cpuidle capable of governing the +> > could make good decisions? Is cpuidle capable of governing the =20 > interval > > of such a timer, rather than directly governing states? > > -> >From now on we did not benchmark these data, because we only have +> >From now on we did not benchmark these data, because we only have =20 > PW10 state. -> +>=20 > I can do support doze/nap for e6500. To get some data to show you. -> -> > As for doze/nap, why would we want to use those on newer cores? Do +>=20 +> > As for doze/nap, why would we want to use those on newer cores? Do =20 > you > > have numbers for how much power each mode saves? > > -> The PH state is plan to support, if the core can make into more low +> The PH state is plan to support, if the core can make into more low =20 > power state, > why not to do this. @@ -81,26 +81,26 @@ We don't do things just to do them. We do things to make things better. > PH10(doze)/PH15(nap)/PH20/PH30, These states can save more CPU power. -If you have evidence that PH15 saves more power than PW20, please +If you have evidence that PH15 saves more power than PW20, please =20 provide it. -> > Active governors may be useful on older cores that only have +> > Active governors may be useful on older cores that only have =20 > doze/nap, > > to > > select between them, but if that's the use case then why start with > > pw10? -> Pw10 is supported on E500MC/E5500/E6500. And we plan to support PW20 +> Pw10 is supported on E500MC/E5500/E6500. And we plan to support PW20 =20 > for E65OO core. > I will take doze/nap up a bit later. By "older cores" I meant before e500mc. -> > And I'd want to see numbers for how much power nap saves versus +> > And I'd want to see numbers for how much power nap saves versus =20 > doze. > > > > > Signed-off-by: Wang Dongsheng <dongsheng.wang@freescale.com> > > > --- -> > > This patch keep using cpuidle_register_device(), because we need +> > > This patch keep using cpuidle_register_device(), because we need =20 > to > > > support cpu > > > hotplug. I will fix "device" issue in this driver, after @@ -122,14 +122,14 @@ That's a totally different patch. > > > + * > > > + * This program is free software; you can redistribute it and/or > > > modify -> > > + * it under the terms of the GNU General Public License version +> > > + * it under the terms of the GNU General Public License version =20 > 2 as > > > + * published by the Free Software Foundation. > > > + * > > > + * Author: Wang Dongsheng <dongsheng.wang@freescale.com> > > > + */ > > -> > Is this derived from some other file? It looks like it... Where's +> > Is this derived from some other file? It looks like it... Where's =20 > the > > attribution? > > @@ -158,14 +158,14 @@ But the code isn't. I can't parse this. -> > > +static struct cpuidle_state fsl_pw_idle_states[] = { +> > > +static struct cpuidle_state fsl_pw_idle_states[] =3D { > > > + { -> > > + .name = "pw10", -> > > + .desc = "pw10", -> > > + .flags = CPUIDLE_FLAG_TIME_VALID, -> > > + .exit_latency = 0, -> > > + .target_residency = 0, -> > > + .enter = &pw10_enter +> > > + .name =3D "pw10", +> > > + .desc =3D "pw10", +> > > + .flags =3D CPUIDLE_FLAG_TIME_VALID, +> > > + .exit_latency =3D 0, +> > > + .target_residency =3D 0, +> > > + .enter =3D &pw10_enter > > > > Where is pw10_enter defined? > > @@ -175,17 +175,17 @@ OK, I see it now -- sorry about that. > > > +static int cpu_is_feature(unsigned long feature) > > > +{ -> > > + return (cur_cpu_spec->cpu_features == feature); +> > > + return (cur_cpu_spec->cpu_features =3D=3D feature); > > > +} > > > + > > > +static int __init e500_idle_init(void) > > > +{ -> > > + struct cpuidle_state *cpuidle_state_table = NULL; -> > > + struct cpuidle_driver *drv = &e500_idle_driver; +> > > + struct cpuidle_state *cpuidle_state_table =3D NULL; +> > > + struct cpuidle_driver *drv =3D &e500_idle_driver; > > > + int err; -> > > + unsigned int max_idle_state = 0; +> > > + unsigned int max_idle_state =3D 0; > > > + -> > > + if (cpuidle_disable != IDLE_NO_OVERRIDE) +> > > + if (cpuidle_disable !=3D IDLE_NO_OVERRIDE) > > > + return -ENODEV; > > > + > > > + if (cpu_is_feature(CPU_FTRS_E500MC) || @@ -199,9 +199,9 @@ OK, I see it now -- sorry about that. > > > Here is the type of the core. E500MC,E5500,E6500 do wait. -There's no guarantee that a CPU with the same set of features is the +There's no guarantee that a CPU with the same set of features is the =20 exact same CPU. The CPU feature mechanism is for checking *features*, not identity. --Scott +-Scott= diff --git a/a/content_digest b/N1/content_digest index 1a7ec59..a67583d 100644 --- a/a/content_digest +++ b/N1/content_digest @@ -4,28 +4,27 @@ "Date\0Wed, 31 Jul 2013 19:23:55 -0500\0" "To\0Wang Dongsheng-B40534 <B40534@freescale.com>\0" "Cc\0Wood Scott-B07421 <B07421@freescale.com>" - rjw@sisk.pl <rjw@sisk.pl> - daniel.lezcano@linaro.org <daniel.lezcano@linaro.org> - benh@kernel.crashing.org <benh@kernel.crashing.org> Li Yang-R58472 <r58472@freescale.com> Zhao Chenhui-B35336 <B35336@freescale.com> linux-pm@vger.kernel.org <linux-pm@vger.kernel.org> + daniel.lezcano@linaro.org <daniel.lezcano@linaro.org> + rjw@sisk.pl <rjw@sisk.pl> " linuxppc-dev@lists.ozlabs.org <linuxppc-dev@lists.ozlabs.org>\0" "\00:1\0" "b\0" "On 07/31/2013 01:30:06 AM, Wang Dongsheng-B40534 wrote:\n" - "> \n" - "> \n" + ">=20\n" + ">=20\n" "> > -----Original Message-----\n" "> > From: Wood Scott-B07421\n" "> > Sent: Wednesday, July 31, 2013 3:38 AM\n" "> > To: Wang Dongsheng-B40534\n" - "> > Cc: rjw@sisk.pl; daniel.lezcano@linaro.org; \n" + "> > Cc: rjw@sisk.pl; daniel.lezcano@linaro.org; =20\n" "> benh@kernel.crashing.org; Li\n" - "> > Yang-R58472; Zhao Chenhui-B35336; linux-pm@vger.kernel.org; \n" + "> > Yang-R58472; Zhao Chenhui-B35336; linux-pm@vger.kernel.org; =20\n" "> linuxppc-\n" "> > dev@lists.ozlabs.org\n" - "> > Subject: Re: [PATCH] cpuidle: add freescale e500 family porcessors \n" + "> > Subject: Re: [PATCH] cpuidle: add freescale e500 family porcessors =20\n" "> idle\n" "> > support\n" "> >\n" @@ -42,53 +41,53 @@ "> > Could you explain what the cpuidle framework does for us that the\n" "> > current idle code doesn't?\n" "> >\n" - "> \n" - "> The current idle code, Only a state of low power can make the core \n" + ">=20\n" + "> The current idle code, Only a state of low power can make the core =20\n" "> idle.\n" "> The core can't get into more low power state.\n" - "> \n" + ">=20\n" "> > In particular, what scenario do you see where we would require a\n" "> > software\n" "> > governor to choose between idle states, and how much power is saved\n" "> > compared to a simpler approach? There is timer that can be used to\n" "> > automatically enter PW20 after a certain amount of time in PW10.\n" - "> \n" - "> Yes, the hardware can automatically enter PW20 state. But this is \n" + ">=20\n" + "> Yes, the hardware can automatically enter PW20 state. But this is =20\n" "> hardware\n" - "> feature, we need to software to manage it. Only for PW20 state, we \n" + "> feature, we need to software to manage it. Only for PW20 state, we =20\n" "> can drop\n" - "> this cpuidle and using the hardware to control it. But if we need to \n" + "> this cpuidle and using the hardware to control it. But if we need to =20\n" "> support\n" "> PH10/PH15/PH20/PH30, the current idle code cannot support them.\n" "\n" - "PH30 wasn't really meant as idle state, but rather a CPU hotplug \n" - "state. This isn't just about enter/exit latency (and complexity) but \n" + "PH30 wasn't really meant as idle state, but rather a CPU hotplug =20\n" + "state. This isn't just about enter/exit latency (and complexity) but =20\n" "also about wakeup events.\n" "\n" - "PH15 and PH20 were mainly intended as intermediate states on the way to \n" - "PH30 or debug halt. It looks like PH15 is the deepest PH state in \n" + "PH15 and PH20 were mainly intended as intermediate states on the way to =20\n" + "PH30 or debug halt. It looks like PH15 is the deepest PH state in =20\n" "which core timers continue to run.\n" "\n" "The intended idle states on e6500 are PW10 and PW20.\n" "\n" - "> > How much better results do you get from a software governor? Do we \n" + "> > How much better results do you get from a software governor? Do we =20\n" "> even\n" - "> > have the right data to characterize each state so that a software \n" + "> > have the right data to characterize each state so that a software =20\n" "> governor\n" - "> > could make good decisions? Is cpuidle capable of governing the \n" + "> > could make good decisions? Is cpuidle capable of governing the =20\n" "> interval\n" "> > of such a timer, rather than directly governing states?\n" "> >\n" - "> >From now on we did not benchmark these data, because we only have \n" + "> >From now on we did not benchmark these data, because we only have =20\n" "> PW10 state.\n" - "> \n" + ">=20\n" "> I can do support doze/nap for e6500. To get some data to show you.\n" - "> \n" - "> > As for doze/nap, why would we want to use those on newer cores? Do \n" + ">=20\n" + "> > As for doze/nap, why would we want to use those on newer cores? Do =20\n" "> you\n" "> > have numbers for how much power each mode saves?\n" "> >\n" - "> The PH state is plan to support, if the core can make into more low \n" + "> The PH state is plan to support, if the core can make into more low =20\n" "> power state,\n" "> why not to do this.\n" "\n" @@ -96,26 +95,26 @@ "\n" "> PH10(doze)/PH15(nap)/PH20/PH30, These states can save more CPU power.\n" "\n" - "If you have evidence that PH15 saves more power than PW20, please \n" + "If you have evidence that PH15 saves more power than PW20, please =20\n" "provide it.\n" "\n" - "> > Active governors may be useful on older cores that only have \n" + "> > Active governors may be useful on older cores that only have =20\n" "> doze/nap,\n" "> > to\n" "> > select between them, but if that's the use case then why start with\n" "> > pw10?\n" - "> Pw10 is supported on E500MC/E5500/E6500. And we plan to support PW20 \n" + "> Pw10 is supported on E500MC/E5500/E6500. And we plan to support PW20 =20\n" "> for E65OO core.\n" "> I will take doze/nap up a bit later.\n" "\n" "By \"older cores\" I meant before e500mc.\n" "\n" - "> > And I'd want to see numbers for how much power nap saves versus \n" + "> > And I'd want to see numbers for how much power nap saves versus =20\n" "> doze.\n" "> >\n" "> > > Signed-off-by: Wang Dongsheng <dongsheng.wang@freescale.com>\n" "> > > ---\n" - "> > > This patch keep using cpuidle_register_device(), because we need \n" + "> > > This patch keep using cpuidle_register_device(), because we need =20\n" "> to\n" "> > > support cpu\n" "> > > hotplug. I will fix \"device\" issue in this driver, after\n" @@ -137,14 +136,14 @@ "> > > + *\n" "> > > + * This program is free software; you can redistribute it and/or\n" "> > > modify\n" - "> > > + * it under the terms of the GNU General Public License version \n" + "> > > + * it under the terms of the GNU General Public License version =20\n" "> 2 as\n" "> > > + * published by the Free Software Foundation.\n" "> > > + *\n" "> > > + * Author: Wang Dongsheng <dongsheng.wang@freescale.com>\n" "> > > + */\n" "> >\n" - "> > Is this derived from some other file? It looks like it... Where's \n" + "> > Is this derived from some other file? It looks like it... Where's =20\n" "> the\n" "> > attribution?\n" "> >\n" @@ -173,14 +172,14 @@ "\n" "I can't parse this.\n" "\n" - "> > > +static struct cpuidle_state fsl_pw_idle_states[] = {\n" + "> > > +static struct cpuidle_state fsl_pw_idle_states[] =3D {\n" "> > > +\t{\n" - "> > > +\t\t.name = \"pw10\",\n" - "> > > +\t\t.desc = \"pw10\",\n" - "> > > +\t\t.flags = CPUIDLE_FLAG_TIME_VALID,\n" - "> > > +\t\t.exit_latency = 0,\n" - "> > > +\t\t.target_residency = 0,\n" - "> > > +\t\t.enter = &pw10_enter\n" + "> > > +\t\t.name =3D \"pw10\",\n" + "> > > +\t\t.desc =3D \"pw10\",\n" + "> > > +\t\t.flags =3D CPUIDLE_FLAG_TIME_VALID,\n" + "> > > +\t\t.exit_latency =3D 0,\n" + "> > > +\t\t.target_residency =3D 0,\n" + "> > > +\t\t.enter =3D &pw10_enter\n" "> >\n" "> > Where is pw10_enter defined?\n" "> >\n" @@ -190,17 +189,17 @@ "\n" "> > > +static int cpu_is_feature(unsigned long feature)\n" "> > > +{\n" - "> > > +\treturn (cur_cpu_spec->cpu_features == feature);\n" + "> > > +\treturn (cur_cpu_spec->cpu_features =3D=3D feature);\n" "> > > +}\n" "> > > +\n" "> > > +static int __init e500_idle_init(void)\n" "> > > +{\n" - "> > > +\tstruct cpuidle_state *cpuidle_state_table = NULL;\n" - "> > > +\tstruct cpuidle_driver *drv = &e500_idle_driver;\n" + "> > > +\tstruct cpuidle_state *cpuidle_state_table =3D NULL;\n" + "> > > +\tstruct cpuidle_driver *drv =3D &e500_idle_driver;\n" "> > > +\tint err;\n" - "> > > +\tunsigned int max_idle_state = 0;\n" + "> > > +\tunsigned int max_idle_state =3D 0;\n" "> > > +\n" - "> > > +\tif (cpuidle_disable != IDLE_NO_OVERRIDE)\n" + "> > > +\tif (cpuidle_disable !=3D IDLE_NO_OVERRIDE)\n" "> > > +\t\treturn -ENODEV;\n" "> > > +\n" "> > > +\tif (cpu_is_feature(CPU_FTRS_E500MC) ||\n" @@ -214,11 +213,11 @@ "> >\n" "> Here is the type of the core. E500MC,E5500,E6500 do wait.\n" "\n" - "There's no guarantee that a CPU with the same set of features is the \n" + "There's no guarantee that a CPU with the same set of features is the =20\n" "exact same CPU.\n" "\n" "The CPU feature mechanism is for checking *features*, not identity.\n" "\n" - -Scott + -Scott= -b714b3624f46c7e1b54b35493408ab48c8a91599571c824d258484325a7ef13d +e5070deb85f2cf98552e5ce546811a76e692f2913d9e4118ee420c6cbb6a784a
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.