Benoit, On Fri, Aug 27, 2010 at 12:25 PM, Cousson, Benoit <b-cousson@xxxxxx> 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/state<n>/actual_latency >> /sys/devices/system/cpu/cpu0/cpuidle/state<n>/sleep_latency >> /sys/devices/system/cpu/cpu0/cpuidle/state<n>/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/state<n>/). 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 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
