Re: [PATCH] OMAP3 clock: fix omap2_clk_wait_ready for OMAP3430ES2 DSS

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


Op 22 jun 2008, om 14:51 heeft Woodruff, Richard het volgende geschreven:


PowerTOP version 1.10      (C) 2007 Intel Corporation

Cn                Avg residency       P-states (frequencies)
C0 (cpu running)        ( 0.0%)
C0                0.0ms ( 0.0%)
C1              188.9ms (0.7%)*
C2              2036.1ms (8.0%)*
C3              23285.1ms (91.3%)*

Wakeups-from-idle per second : 61.7     interval: 3.0s

Top causes for wakeups:
  44.9% ( 57.7)       <interrupt> : musb_hdrc.0
  17.9% ( 23.0)       <interrupt> : gp timer
  14.3% ( 18.3)   USB device 2-1.2 : LCD2USB Interface (Till Harbaum)
   9.9% ( 12.7)         lcd4linux : do_nanosleep (hrtimer_wakeup)
   7.5% (  9.7)   USB device 2-1.4 : Linksys USB2.0 Network Adapter
(USB)
   3.9% (  5.0)            Xfbdev : fbcon_add_cursor_timer
(cursor_timer_handler)
0.5% ( 0.7) hald : schedule_timeout (process_timeout)
   0.3% (  0.3)          dropbear : sk_reset_timer (tcp_write_timer)
   0.3% (  0.3)     <kernel core> : neigh_table_init_no_netlink
(neigh_periodic_timer)
0.3% ( 0.3) pulseaudio : schedule_timeout (process_timeout) 0.3% ( 0.3) init : schedule_timeout (process_timeout)

The dispc crashes are gone and I get fewer wakeups per second :)

regards,

Koen


* There's a bug in powertop 1.10 that reports percentages wrong, so
the percentages  where approximated by hand.

C0 (cpu running)        ( 0.0%)
C0                0.0ms ( 0.0%)
C1              176.5ms ( 4.7%)
C2              3601.7ms (4090.7%)
C3              17956.3ms (92938.0%)

Those C-State residency times are clearly wrong also.

If you try hard with a minimal kernel the maximum sleep you can get is like 1.5 seconds. The kernel has some hard coded timers with 1 to 2 second periods (like slab cache reaper threads).

For our non-edge kernel code these things report about right. As long as you have a 99.9% duty cycle of OFF to ON you get pretty good savings.

The wake up information should be about right. Your USB Networking with MUSB will probably assure you of never getting ultra low power numbers but probably good for development.

What is that USB2LCD device?

http://www.harbaum.org/till/lcd2usb/index.shtml driven by the lcd4linux app, which is quite x86 oriented, so not very powersaving friendly, I did save ~100 wake-ups/s by using libusb1+libusbcompat over libusb.

regards,

Koen

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)

iD8DBQFIXlHkMkyGM64RGpERAozNAJwJZy+hqtqAlnEOk4WvZ4zrTkK4uACfbA7x
XQ5GgY6n3vI7cabyVLvQfOY=
=ZheC
-----END PGP SIGNATURE-----
--
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

[Index of Archives]     [Linux Arm (vger)]     [ARM Kernel]     [ARM MSM]     [Linux Tegra]     [Linux WPAN Networking]     [Linux Wireless Networking]     [Maemo Users]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite Trails]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux