Re: PowerTOP kernel patch
Hi Nicolas, As we talked on IRC, I created a bundle file which contains three commits for powertop kernel patch. Please review. Thanks Yong On Thu, Aug 26, 2010 at 2:30 PM, Yong Shen yong.s...@linaro.org wrote: Hi Nicolas, Thanks for your suggestion.s I am going to follow this. Yong On Thu, Aug 26, 2010 at 3:05 AM, Nicolas Pitre nicolas.pi...@linaro.orgwrote: Those patches don't apply as is, and I prefer not venturing into merge conflict attempts. What I'd suggest is: 1) get the stable linaro tree from git:// git.linaro.org/kernel/linux-linaro-2.6.35.git 2) cherry-pick the upstream patch with 'git cherry-pick -x 8d4b9d1bf' 3) fix the conflicts, then commit 4) apply and commit the other patches on top 5) test _this_ resulting tree 6) put the result somewhere for me to pull. On Wed, 25 Aug 2010, Amit Kucheria wrote: Hi John/Yong, Could you work with the Ubuntu kernel team to get these patches merged into their tree? Regards, Amit On Mon, Aug 23, 2010 at 6:25 AM, Yong Shen yong.s...@linaro.org wrote: only one patch, linux-2.6.35-rc4-annotate-device-pm.patch is involved in 2.6.36, at 8d4b9d1bfef117862a2889dec4dac227068544c9. So we may still need the rest two. On Sat, Aug 21, 2010 at 2:28 AM, Nicolas Pitre nicolas.pi...@linaro.org wrote: On Fri, 20 Aug 2010, Yong Shen wrote: Hi there, Power management WG is invistigating on a tool named PowerTOP, which can spit out real time data on various aspects of a running system, in terms of power related information. However, occasionally some PowerTOP features need kernel patch. We'd like users to be able to use these latest features without having to wait up to 3 months for Linus to make a release with the kernel portion -- as the original patch developer(s) said. There are totally 3 patches which I had already enclosed them in the attachment. Except vfs.patch, the rest two are original and can be applied on linaro kernel without any changes. vfs.patch is changed a little from original one to adapt current linaro kernel. Hope John would give it a thought to merge these patch in Linaro kernel. I would be interested in them too! If I'm not mistaken, John is getting my kernel and adding the necessary packaging to it. So those patches would probably make more sense being carried into the base Linaro repository that John is using. Nicolas ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev powerpop_kernel_patch.bundle Description: Binary data ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: How to involve into the linaro development
Hi, On Fri, Aug 27, 2010 at 12:34:37AM +0200, Loïc Minier wrote: - testing our linux-linaro-2.6.35 kernel and u-boot-linaro bootloader and reporting any missing features / bugs when compared to other distros - measuring boot time of the various pieces (x-loader, u-boot, kernel, userspace) perhaps breaking each piece open and seeing where time is spent in the kernel init; how does NAND boot versus MMC boot compare with your MMC? Note that just testing things as they are might not give the fanciest results :-) For example, we have an i.MX35 @ 532 MHz booting from NAND, and it takes 336 ms from the first user-changable assembler instruction (after the ROM bootloader) up to /sbin/init is started (we toggle a GPIO in both places). However, achieving that needed some funny parallelization hacks in Barebox, plus a creative block size of the Linux kernel. If you configure it with the off-the-shelf configuration, it will surely need longer. - creating a barebox package building a beagleboard version; does it have regression over u-boot? (perhaps some fixes which went into u-boot are missing?) Note that Michael Grzeschik m...@pengutronix.de recently worked on bringing Barebox support for the beagle board up to date, the results didn't hit the Barebox mainline yet. We are working on a step-by-step documentation for the elinux.org wiki. rsc -- Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0| Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- | ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: How to involve into the linaro development
On Fri, Aug 27, 2010 at 4:00 PM, nvhariha...@gmail.com wrote: Hi, Thanks for allowing me to start my contributions. I have downloaded 23/08/10 daily packages and put the binaries into MMC and boot the system. It was hanging in the U-Boot after I2C ready console print. My beagle board is Rev C4. Could you try holding down the USER and RESET white switches together? They are next to the EHCI USB port. That should force the board to boot from MMC. Cheers, Amit ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: How to involve into the linaro development
On Fri, Aug 27, 2010 at 8:00 AM, nvhariha...@gmail.com wrote: Hi, Thanks for allowing me to start my contributions. I have downloaded 23/08/10 daily packages and put the binaries into MMC and boot the system. It was hanging in the U-Boot after I2C ready console print. My beagle board is Rev C4. Common problem with upgrading to X-loader 1.4.4ss and u-boot 2010-03+ Your board has an older X-loader installed (factory 1.4.2 probally), with MLO and u-boot.bin on the fat partition you need to hold down the user button to get to u-boot prompt.. Once there reflash the MLO and u-boot.bin.. U-boot Commands: http://elinux.org/BeagleBoardUbuntu#Manual_Run Regards, -- Robert Nelson http://www.rcn-ee.com/ ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
RE: [PATCH] OMAP CPUIDLE: CPU Idle latency measurement
Benoit, -Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- ow...@vger.kernel.org] On Behalf Of Cousson, Benoit Sent: Friday, August 27, 2010 3:56 PM To: vishwanath.sripa...@linaro.org; Sripathy, Vishwanath Cc: linux-o...@vger.kernel.org; linaro-dev@lists.linaro.org; Jean Pihet; Chalhoub, Nicole; Bour, Vincent Subject: Re: [PATCH] OMAP CPUIDLE: CPU Idle latency measurement Hi Vishwa, On 8/28/2010 12:08 AM, vishwanath.sripa...@linaro.org wrote: From: Vishwanath BSvishwanath.sripa...@linaro.org This patch has instrumentation code for measuring latencies for various CPUIdle C states for OMAP. Idea here is to capture the timestamp at various phases of CPU Idle and then compute the sw latency for various c states. For OMAP, 32k clock is chosen as reference clock this as is an always on clock. wkup domain memory (scratchpad memory) is used for storing timestamps. One can see the worstcase latencies in below sysfs entries (after enabling CONFIG_CPU_IDLE_PROF in .config). This information can be used to correctly configure cpu idle latencies for various C states after adding HW latencies for each of these sw latencies. /sys/devices/system/cpu/cpu0/cpuidle/staten/actual_latency /sys/devices/system/cpu/cpu0/cpuidle/staten/sleep_latency /sys/devices/system/cpu/cpu0/cpuidle/staten/wkup_latency FYI, Jean is currently working on using standard Linux probes in order to instrument CPUIdle / CPUfreq. I'm not sure it is doable, but it might better to use standard method to do that instead of purely OMAP3 specific stuff. This code will not scale easily on OMAP4. Just discussed how to scale this for all OMAPs. Firstly we need to get this code to common place instead of tying it to OMAP3/OMAP4 specific low level code. Since on OMAP3, we can push C-functions on SRAM and for OMAP4 we don't have any limitation, all this code can be converted to C. Vishwa is planning to attempt that in next version. Regards, santosh ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Hardware pack questions
[ resending with the correct address ] On Fri, 27 Aug 2010 14:03:32 -0400, James Westby james.wes...@canonical.com wrote: On Fri, 20 Aug 2010 16:26:46 -0400, James Westby james.wes...@linaro.org wrote: There is also one larger question, which is that I disagree that we shouldn't provide anything that will go in a hardware pack in the linaro images. I think that having the images be useful by themselves has lots of benefits. - Being able to quickly spin up an image in QEMU makes for easier testing. - Requiring a hardware pack for every operation will make some things more tedious. - If everything in a hardware pack becomes more consolidated then hardware packs probably become less useful. - Not having a flag day where suddenly our images aren't installable and hwpack-install has to work well, and before that date we can't test hwpack-install on the images we produce. Having not had anyone convince me that stripping our images is the right thing to do I have carried on attempting to write the spec without requiring this. There will be a few issues, such as ensuring that the kernel we want is the one that boots, but we have that problem on hwpack upgrades anyway, so it doesn't go away by stripping the images. I have https://wiki.linaro.org/Platform/UserPlatforms/Specs/10.11/HardwarePacks to a state where I am happy to start implementation now. Feedback on the spec is still welcome, and things will still be subject to change. In particular there are still a number of TODOs in the spec where I don't know how to proceed, but I believe that none of those block us starting implementation of other parts. Is the current status quo to create specs under the linaro project on Launchpad? I'll create a spec for this so that we can track work items for it. Thanks, James ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH] OMAP CPUIDLE: CPU Idle latency measurement
Benoit, On Fri, Aug 27, 2010 at 12:25 PM, Cousson, Benoit b-cous...@ti.com wrote: This patch has instrumentation code for measuring latencies for various CPUIdle C states for OMAP. Idea here is to capture the timestamp at various phases of CPU Idle and then compute the sw latency for various c states. For OMAP, 32k clock is chosen as reference clock this as is an always on clock. wkup domain memory (scratchpad memory) is used for storing timestamps. One can see the worstcase latencies in below sysfs entries (after enabling CONFIG_CPU_IDLE_PROF in .config). This information can be used to correctly configure cpu idle latencies for various C states after adding HW latencies for each of these sw latencies. /sys/devices/system/cpu/cpu0/cpuidle/staten/actual_latency /sys/devices/system/cpu/cpu0/cpuidle/staten/sleep_latency /sys/devices/system/cpu/cpu0/cpuidle/staten/wkup_latency FYI, Jean is currently working on using standard Linux probes in order to instrument CPUIdle / CPUfreq. I'm not sure it is doable, but it might better to use standard method to do that instead of purely OMAP3 specific stuff. This code will not scale easily on OMAP4. The proposed code looks OK to me since it is exporting the cpuidle latency figures through the generic cpuidle driver (in drivers/cpuidle/sysfs.c, via /sys/devices/system/cpu/cpu0/cpuidle/staten/). Once that code gets approved I can (and will) add some trace points in it, so that all PM related events can be traced vs time. Do you have a dump of the latency you measured do far? Jean ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH] OMAP CPUIDLE: CPU Idle latency measurement
Hi,
On Sat, Aug 28, 2010 at 12:08 AM, vishwanath.sripa...@linaro.org wrote:
From: Vishwanath BS vishwanath.sripa...@linaro.org
This patch has instrumentation code for measuring latencies for
various CPUIdle C states for OMAP. Idea here is to capture the
timestamp at various phases of CPU Idle and then compute the sw
latency for various c states. For OMAP, 32k clock is chosen as
reference clock this as is an always on clock. wkup domain memory
(scratchpad memory) is used for storing timestamps. One can see the
worstcase latencies in below sysfs entries (after enabling
CONFIG_CPU_IDLE_PROF
in .config). This information can be used to correctly configure cpu idle
latencies for various C states after adding HW latencies for each of
these sw latencies.
/sys/devices/system/cpu/cpu0/cpuidle/staten/actual_latency
/sys/devices/system/cpu/cpu0/cpuidle/staten/sleep_latency
/sys/devices/system/cpu/cpu0/cpuidle/staten/wkup_latency
THis patch is tested on OMAP ZOOM3 using kevin's pm branch.
Signed-off-by: Vishwanath BS vishwanath.sripa...@linaro.org
Cc: linaro-dev@lists.linaro.org
---
...
+#ifdef CONFIG_CPU_IDLE_PROF
+ sleep_time = omap3_sram_get_sleep_time();
+ wkup_time = omap3_sram_get_wkup_time();
+
+ /* take care of overflow */
+ if (postidle_time preidle_time)
+ postidle_time += (u32) 0x;
+ if (wkup_time sleep_time)
+ wkup_time += (u32) 0x;
+
+ idle_time = postidle_time - preidle_time;
+ total_sleep_time = wkup_time - sleep_time;
+ latency = idle_time - total_sleep_time;
+ sleep_time = omap3_sram_get_sleep_time();
+ wkup_time = omap3_sram_get_wkup_time();
Is it needed to re-read the sleep_time and wkup_time values from the scratchpad?
What about the 32k timer overflow? Could that cause the sleep_latency
and/or wkup_latency to be 0?
+
+ /* calculate average latency after ignoring sprious ones */
+ if ((total_sleep_time 0) (latency state-actual_latency)
+ (latency = 0)) {
+ state-actual_latency = CONVERT_32K_USEC(latency);
+ latency = (sleep_time - preidle_time);
Risk of overflow?
+ state-sleep_latency = CONVERT_32K_USEC(latency);
+ latency = postidle_time - wkup_time;
Risk of overflow?
+ state-wkup_latency = CONVERT_32K_USEC(latency);
+ }
+#endif
+
return ts_idle.tv_nsec / NSEC_PER_USEC + ts_idle.tv_sec * USEC_PER_SEC;
}
Jean
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH] OMAP CPUIDLE: CPU Idle latency measurement
Hi Vishwa,
On 8/28/2010 12:08 AM, vishwanath.sripa...@linaro.org wrote:
From: Vishwanath BSvishwanath.sripa...@linaro.org
This patch has instrumentation code for measuring latencies for
various CPUIdle C states for OMAP. Idea here is to capture the
timestamp at various phases of CPU Idle and then compute the sw
latency for various c states. For OMAP, 32k clock is chosen as
reference clock this as is an always on clock. wkup domain memory
(scratchpad memory) is used for storing timestamps. One can see the
worstcase latencies in below sysfs entries (after enabling
CONFIG_CPU_IDLE_PROF
in .config). This information can be used to correctly configure cpu idle
latencies for various C states after adding HW latencies for each of
these sw latencies.
/sys/devices/system/cpu/cpu0/cpuidle/staten/actual_latency
/sys/devices/system/cpu/cpu0/cpuidle/staten/sleep_latency
/sys/devices/system/cpu/cpu0/cpuidle/staten/wkup_latency
FYI, Jean is currently working on using standard Linux probes in order
to instrument CPUIdle / CPUfreq. I'm not sure it is doable, but it might
better to use standard method to do that instead of purely OMAP3
specific stuff. This code will not scale easily on OMAP4.
Do you have a dump of the latency you measured do far?
THis patch is tested on OMAP ZOOM3 using kevin's pm branch.
Signed-off-by: Vishwanath BSvishwanath.sripa...@linaro.org
Cc: linaro-dev@lists.linaro.org
---
arch/arm/mach-omap2/cpuidle34xx.c | 58 --
arch/arm/mach-omap2/pm.h |5 ++
arch/arm/mach-omap2/sleep34xx.S | 121
+
drivers/cpuidle/Kconfig |5 ++
drivers/cpuidle/sysfs.c | 16 +-
include/linux/cpuidle.h |3 +
6 files changed, 202 insertions(+), 6 deletions(-)
diff --git a/arch/arm/mach-omap2/cpuidle34xx.c
b/arch/arm/mach-omap2/cpuidle34xx.c
index 3d3d035..398bef8
--- a/arch/arm/mach-omap2/cpuidle34xx.c
+++ b/arch/arm/mach-omap2/cpuidle34xx.c
@@ -25,6 +25,7 @@
#includelinux/sched.h
#includelinux/cpuidle.h
+#includelinux/clk.h
#includeplat/prcm.h
#includeplat/irqs.h
#includeplat/powerdomain.h
@@ -86,6 +87,11 @@ static struct cpuidle_params cpuidle_params_table[] = {
{1, 1, 3, 30},
};
+#ifdef CONFIG_CPU_IDLE_PROF
Cannot you use _PROFILING instead? _PROF does not sound very meaningful
for my point of view.
+static struct clk *clk_32k;
+#define CONVERT_32K_USEC(lat) (lat * (USEC_PER_SEC/clk_get_rate(clk_32k)))
+#endif
+
static int omap3_idle_bm_check(void)
{
if (!omap3_can_sleep())
@@ -115,21 +121,28 @@ static int _cpuidle_deny_idle(struct powerdomain *pwrdm,
* Called from the CPUidle framework to program the device to the
* specified target state selected by the governor.
*/
+
static int omap3_enter_idle(struct cpuidle_device *dev,
struct cpuidle_state *state)
{
struct omap3_processor_cx *cx = cpuidle_get_statedata(state);
struct timespec ts_preidle, ts_postidle, ts_idle;
u32 mpu_state = cx-mpu_state, core_state = cx-core_state;
+#ifdef CONFIG_CPU_IDLE_PROF
+ int idle_time, latency;
+ long sleep_time, wkup_time, total_sleep_time;
+ long preidle_time, postidle_time;
+#endif
current_cx_state = *cx;
- /* Used to keep track of the total time in idle */
- getnstimeofday(ts_preidle);
-
local_irq_disable();
local_fiq_disable();
-
+ /* Used to keep track of the total time in idle */
+ getnstimeofday(ts_preidle);
+#ifdef CONFIG_CPU_IDLE_PROF
+ preidle_time = omap3_sram_get_32k_tick();
+#endif
pwrdm_set_next_pwrst(mpu_pd, mpu_state);
pwrdm_set_next_pwrst(core_pd, core_state);
@@ -153,9 +166,39 @@ return_sleep_time:
getnstimeofday(ts_postidle);
ts_idle = timespec_sub(ts_postidle, ts_preidle);
+#ifdef CONFIG_CPU_IDLE_PROF
+ postidle_time = omap3_sram_get_32k_tick();
+#endif
local_irq_enable();
local_fiq_enable();
+#ifdef CONFIG_CPU_IDLE_PROF
+ sleep_time = omap3_sram_get_sleep_time();
+ wkup_time = omap3_sram_get_wkup_time();
+
+ /* take care of overflow */
+ if (postidle_time preidle_time)
+ postidle_time += (u32) 0x;
+ if (wkup_time sleep_time)
+ wkup_time += (u32) 0x;
+
+ idle_time = postidle_time - preidle_time;
+ total_sleep_time = wkup_time - sleep_time;
+ latency = idle_time - total_sleep_time;
+ sleep_time = omap3_sram_get_sleep_time();
+ wkup_time = omap3_sram_get_wkup_time();
+
+ /* calculate average latency after ignoring sprious ones */
+ if ((total_sleep_time 0) (latency state-actual_latency)
+ (latency= 0)) {
+ state-actual_latency = CONVERT_32K_USEC(latency);
+ latency = (sleep_time -
Re: [PATCH] OMAP CPUIDLE: CPU Idle latency measurement
g 28, 2010 at 3:38 AM, vishwanath.sripa...@linaro.org wrote:
From: Vishwanath BS vishwanath.sripa...@linaro.org
This patch has instrumentation code for measuring latencies for
various CPUIdle C states for OMAP. Idea here is to capture the
timestamp at various phases of CPU Idle and then compute the sw
latency for various c states. For OMAP, 32k clock is chosen as
reference clock this as is an always on clock. wkup domain memory
(scratchpad memory) is used for storing timestamps. One can see the
worstcase latencies in below sysfs entries (after enabling
CONFIG_CPU_IDLE_PROF
in .config). This information can be used to correctly configure cpu idle
latencies for various C states after adding HW latencies for each of
these sw latencies.
/sys/devices/system/cpu/cpu0/cpuidle/staten/actual_latency
/sys/devices/system/cpu/cpu0/cpuidle/staten/sleep_latency
/sys/devices/system/cpu/cpu0/cpuidle/staten/wkup_latency
THis patch is tested on OMAP ZOOM3 using kevin's pm branch.
Signed-off-by: Vishwanath BS vishwanath.sripa...@linaro.org
Cc: linaro-dev@lists.linaro.org
---
arch/arm/mach-omap2/cpuidle34xx.c | 58 --
arch/arm/mach-omap2/pm.h | 5 ++
arch/arm/mach-omap2/sleep34xx.S | 121
+
drivers/cpuidle/Kconfig | 5 ++
drivers/cpuidle/sysfs.c | 16 +-
include/linux/cpuidle.h | 3 +
6 files changed, 202 insertions(+), 6 deletions(-)
diff --git a/arch/arm/mach-omap2/cpuidle34xx.c
b/arch/arm/mach-omap2/cpuidle34xx.c
index 3d3d035..398bef8
--- a/arch/arm/mach-omap2/cpuidle34xx.c
+++ b/arch/arm/mach-omap2/cpuidle34xx.c
@@ -25,6 +25,7 @@
#include linux/sched.h
#include linux/cpuidle.h
+#include linux/clk.h
#include plat/prcm.h
#include plat/irqs.h
#include plat/powerdomain.h
@@ -86,6 +87,11 @@ static struct cpuidle_params cpuidle_params_table[] = {
{1, 1, 3, 30},
};
+#ifdef CONFIG_CPU_IDLE_PROF
+static struct clk *clk_32k;
+#define CONVERT_32K_USEC(lat) (lat * (USEC_PER_SEC/clk_get_rate(clk_32k)))
+#endif
+
static int omap3_idle_bm_check(void)
{
if (!omap3_can_sleep())
@@ -115,21 +121,28 @@ static int _cpuidle_deny_idle(struct powerdomain *pwrdm,
* Called from the CPUidle framework to program the device to the
* specified target state selected by the governor.
*/
+
static int omap3_enter_idle(struct cpuidle_device *dev,
struct cpuidle_state *state)
{
struct omap3_processor_cx *cx = cpuidle_get_statedata(state);
struct timespec ts_preidle, ts_postidle, ts_idle;
u32 mpu_state = cx-mpu_state, core_state = cx-core_state;
+#ifdef CONFIG_CPU_IDLE_PROF
+ int idle_time, latency;
+ long sleep_time, wkup_time, total_sleep_time;
+ long preidle_time, postidle_time;
+#endif
current_cx_state = *cx;
- /* Used to keep track of the total time in idle */
- getnstimeofday(ts_preidle);
-
local_irq_disable();
local_fiq_disable();
-
+ /* Used to keep track of the total time in idle */
+ getnstimeofday(ts_preidle);
+#ifdef CONFIG_CPU_IDLE_PROF
+ preidle_time = omap3_sram_get_32k_tick();
+#endif
pwrdm_set_next_pwrst(mpu_pd, mpu_state);
pwrdm_set_next_pwrst(core_pd, core_state);
@@ -153,9 +166,39 @@ return_sleep_time:
getnstimeofday(ts_postidle);
ts_idle = timespec_sub(ts_postidle, ts_preidle);
+#ifdef CONFIG_CPU_IDLE_PROF
+ postidle_time = omap3_sram_get_32k_tick();
+#endif
local_irq_enable();
local_fiq_enable();
+#ifdef CONFIG_CPU_IDLE_PROF
+ sleep_time = omap3_sram_get_sleep_time();
+ wkup_time = omap3_sram_get_wkup_time();
+
+ /* take care of overflow */
+ if (postidle_time preidle_time)
+ postidle_time += (u32) 0x;
+ if (wkup_time sleep_time)
+ wkup_time += (u32) 0x;
+
+ idle_time = postidle_time - preidle_time;
+ total_sleep_time = wkup_time - sleep_time;
+ latency = idle_time - total_sleep_time;
+ sleep_time = omap3_sram_get_sleep_time();
+ wkup_time = omap3_sram_get_wkup_time();
+
+ /* calculate average latency after ignoring sprious ones */
+ if ((total_sleep_time 0) (latency state-actual_latency)
+ (latency = 0)) {
+ state-actual_latency = CONVERT_32K_USEC(latency);
+ latency = (sleep_time - preidle_time);
+ state-sleep_latency = CONVERT_32K_USEC(latency);
+ latency = postidle_time - wkup_time;
+ state-wkup_latency = CONVERT_32K_USEC(latency);
+ }
+#endif
+
return ts_idle.tv_nsec / NSEC_PER_USEC + ts_idle.tv_sec * USEC_PER_SEC;
}
@@ -423,7 +466,9 @@ int __init omap3_idle_init(void)
struct omap3_processor_cx *cx;
struct cpuidle_state *state;
struct cpuidle_device
Re: Hardware pack questions
On Fri, Aug 27, 2010 at 02:05:30PM -0400, James Westby wrote: https://wiki.linaro.org/Platform/UserPlatforms/Specs/10.11/HardwarePacks to a state where I am happy to start implementation now. Feedback on the spec is still welcome, and things will still be subject to change. In particular there are still a number of TODOs in the spec where I don't know how to proceed, but I believe that none of those block us starting implementation of other parts. Is the current status quo to create specs under the linaro project on Launchpad? I'll create a spec for this so that we can track work items for it. Yes. Scott B. or Ian may have a linaro-infrastructure project or project group in the wings to which we should move it later if so, but don't let yourself get blocked for lack of a place to put it ;-) Thanks very much for the help with this, James. -- Christian Robottom Reis | [+55] 16 9112 6430 | http://launchpad.net/~kiko Linaro Engineering VP | [ +1] 612 216 4935 | http://async.com.br/~kiko ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Hardware pack questions
On 27 Aug 2010, at 19:05, James Westby wrote: On Fri, 27 Aug 2010 14:03:32 -0400, James Westby james.wes...@canonical.com wrote: On Fri, 20 Aug 2010 16:26:46 -0400, James Westby james.wes...@linaro.org wrote: Is the current status quo to create specs under the linaro project on Launchpad? I'll create a spec for this so that we can track work items for it. Yes. The Ubuntu project was chosen for the initial blueprints for a number of reasons, all of which were not really valid (we had a lot of discussions about this) but from now on, unless your blueprint is a working group blueprint, please target at the Linaro project. Thanks, James Regards, Jamie. ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH] OMAP CPUIDLE: CPU Idle latency measurement
On 10 Aug 28, vishwanath.sripa...@linaro.org wrote: From: Vishwanath BS vishwanath.sripa...@linaro.org This patch has instrumentation code for measuring latencies for various CPUIdle C states for OMAP. Idea here is to capture the timestamp at various phases of CPU Idle and then compute the sw latency for various c states. For OMAP, 32k clock is chosen as reference clock this as is an always on clock. wkup domain memory (scratchpad memory) is used for storing timestamps. One can see the worstcase latencies in below sysfs entries (after enabling CONFIG_CPU_IDLE_PROF in .config). This information can be used to correctly configure cpu idle latencies for various C states after adding HW latencies for each of these sw latencies. /sys/devices/system/cpu/cpu0/cpuidle/staten/actual_latency /sys/devices/system/cpu/cpu0/cpuidle/staten/sleep_latency /sys/devices/system/cpu/cpu0/cpuidle/staten/wkup_latency THis patch is tested on OMAP ZOOM3 using kevin's pm branch. Signed-off-by: Vishwanath BS vishwanath.sripa...@linaro.org Cc: linaro-dev@lists.linaro.org --- arch/arm/mach-omap2/cpuidle34xx.c | 58 -- arch/arm/mach-omap2/pm.h |5 ++ arch/arm/mach-omap2/sleep34xx.S | 121 + drivers/cpuidle/Kconfig |5 ++ drivers/cpuidle/sysfs.c | 16 +- include/linux/cpuidle.h |3 + 6 files changed, 202 insertions(+), 6 deletions(-) Vishwa, You should perhaps cc Len Brown and LKML for V2 to get acceptance for the new counters in cpuidle Regards, Amit ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH] OMAP CPUIDLE: CPU Idle latency measurement
Amit Kucheria amit.kuche...@linaro.org writes: On 10 Aug 28, vishwanath.sripa...@linaro.org wrote: From: Vishwanath BS vishwanath.sripa...@linaro.org This patch has instrumentation code for measuring latencies for various CPUIdle C states for OMAP. Idea here is to capture the timestamp at various phases of CPU Idle and then compute the sw latency for various c states. For OMAP, 32k clock is chosen as reference clock this as is an always on clock. wkup domain memory (scratchpad memory) is used for storing timestamps. One can see the worstcase latencies in below sysfs entries (after enabling CONFIG_CPU_IDLE_PROF in .config). This information can be used to correctly configure cpu idle latencies for various C states after adding HW latencies for each of these sw latencies. /sys/devices/system/cpu/cpu0/cpuidle/staten/actual_latency /sys/devices/system/cpu/cpu0/cpuidle/staten/sleep_latency /sys/devices/system/cpu/cpu0/cpuidle/staten/wkup_latency THis patch is tested on OMAP ZOOM3 using kevin's pm branch. Signed-off-by: Vishwanath BS vishwanath.sripa...@linaro.org Cc: linaro-dev@lists.linaro.org --- arch/arm/mach-omap2/cpuidle34xx.c | 58 -- arch/arm/mach-omap2/pm.h |5 ++ arch/arm/mach-omap2/sleep34xx.S | 121 + drivers/cpuidle/Kconfig |5 ++ drivers/cpuidle/sysfs.c | 16 +- include/linux/cpuidle.h |3 + 6 files changed, 202 insertions(+), 6 deletions(-) You should perhaps cc Len Brown and LKML for V2 to get acceptance for the new counters in cpuidle Before a v2, we need to have some discussions about the general direction of how to best do PM instrumentation. As I said in my review of this patch[1], I am not a fan of the current approach. Kevin [1] http://marc.info/?l=linux-omapm=128293652216542w=2 NOTE: This post may not have made it to linaro-dev since it's moderated, an I wasn't subscribed when I posted this, but am now. ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH] OMAP CPUIDLE: CPU Idle latency measurement
vishwanath.sripa...@linaro.org writes: From: Vishwanath BS vishwanath.sripa...@linaro.org This patch has instrumentation code for measuring latencies for various CPUIdle C states for OMAP. Idea here is to capture the timestamp at various phases of CPU Idle and then compute the sw latency for various c states. For OMAP, 32k clock is chosen as reference clock this as is an always on clock. wkup domain memory (scratchpad memory) is used for storing timestamps. One can see the worstcase latencies in below sysfs entries (after enabling CONFIG_CPU_IDLE_PROF in .config). This information can be used to correctly configure cpu idle latencies for various C states after adding HW latencies for each of these sw latencies. /sys/devices/system/cpu/cpu0/cpuidle/staten/actual_latency /sys/devices/system/cpu/cpu0/cpuidle/staten/sleep_latency /sys/devices/system/cpu/cpu0/cpuidle/staten/wkup_latency THis patch is tested on OMAP ZOOM3 using kevin's pm branch. Signed-off-by: Vishwanath BS vishwanath.sripa...@linaro.org Cc: linaro-dev@lists.linaro.org While I have many problems with the implementation details, I won't go into them because in general this is the wrong direction for kernel instrumentation. This approach adds quite a bit overhead to the idle path itself. With all the reads/writes from/to the scratchpad(?) and all the multiplications and divides in every idle path, as well as the wait-for-idlest in both the sleep and resume paths. The additional overhead added is non trivial. Basically, I'd like get away from custom instrumentation and measurement coded inside the kernel itself. This kind of code never stops growing and morphing into ugliness, and rarely scales well when new SoCs are added. With ftrace/perf, we can add tracepoints at specific points and use external tools to extract and analyze the delays, latencys etc. The point is to keep the minimum possible in the kernel: just the tracepoints we're interested in. The rest (calculations, averages, analysis, etc.) does not need to be in the kernel and can be done easier and with more powerful tools outside the kernel. Kevin ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
