aboutsummaryrefslogtreecommitdiff
path: root/arch/arm/mach-omap2/omap_hwmod.c
diff options
context:
space:
mode:
authorKevin Hilman <khilman@deeprootsystems.com>2010-01-26 20:13:02 -0700
committerPaul Walmsley <paul@pwsan.com>2010-01-26 20:13:02 -0700
commit9799aca2032ad53418ff4bc0d1a6f2cb4f79b6c0 (patch)
treef8cd85a140eb5d1bf77fff3dbec78ae93f6be183 /arch/arm/mach-omap2/omap_hwmod.c
parentf0271d65f9ac511d2e3e1fdbcd7418a5a7df0769 (diff)
OMAP: omap_device: optionally auto-adjust device activate/deactivate latencies
First, this patch adds new worst-case latency values to the omap_device_pm_latency struct. Here the worst-case measured latencies for the activate and deactivate hooks are stored. In addition, add an option to auto-adjust the latency values used for device activate/deactivate. By setting a new 'OMAP_DEVICE_LATENCY_AUTO_ADJUST' flag in the omap_device_pm_latency struct, the omap_device layer automatically adjusts the activate/deactivate latencies to the worst-case measured values. Anytime a new worst-case value is found, it is printed to the console. Here is an example log during boot using UART2 s an example. After boot, the OPP is manually changed to the 125MHz OPP: [...] Freeing init memory: 128K omap_device: serial8250.2: new worst case deactivate latency 0: 30517 omap_device: serial8250.2: new worst case activate latency 0: 30517 omap_device: serial8250.2: new worst case activate latency 0: 218139648 omap_device: serial8250.2: new worst case deactivate latency 0: 61035 omap_device: serial8250.2: new worst case activate latency 0: 278076171 omap_device: serial8250.2: new worst case activate latency 0: 298614501 omap_device: serial8250.2: new worst case activate latency 0: 327331542 / # echo 125000 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_setspeed omap_device: serial8250.2: new worst case deactivate latency 0: 91552 Motivation: this can be used as a technique to automatically determine the worst case latency values. The current method of printing a warning on every violation is too noisy to actually interact the console in order to set low OPP to discover latencies. Another motivation for this patch is that the activate/deactivate latenices can vary depending on the idlemode of the device. While working on the UARTs, I noticed that when using no-idle, the activate latencies were as high as several hundred msecs as shown above. When the UARTs are in smart-idle, the max latency is well under 100 usecs. Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com> Signed-off-by: Paul Walmsley <paul@pwsan.com>
Diffstat (limited to 'arch/arm/mach-omap2/omap_hwmod.c')
0 files changed, 0 insertions, 0 deletions