For this system... On DC: OS C3 = HW C4 On AC: OS C3 = HW C3 This is a common BIOS implementation choice. The reasoning is that on AC you are more interested in lower latency than you are interested in increased power savings. They could have equally decided to expose 4 C-states no matter AC or DC, but a popular binary OS would just ignore C3 in that case and use only C4. On AC/DC events, _CST is re-evaluated and the BIOS gives the OS a different answer. We don't print out the IO address used to enter the state, but if we did, you'd find that it changes along with the reported latency. > AC: > C3: type[C3] promotion[--] demotion[C2] >latency[017] usage[02945663] >active state: C3 >max_cstate: C8 >bus master activity: 00000000 >states: > C1: type[C1] promotion[C2] demotion[--] >latency[000] usage[00000010] > C2: type[C2] promotion[C3] demotion[C1] >latency[001] usage[04745508] > *C3: type[C3] promotion[--] demotion[C2] >latency[017] usage[05832946] > >battery: >daniel-mobile% cat /proc/acpi/processor/*/power >active state: C2 >max_cstate: C8 >bus master activity: ffffff40 >states: > C1: type[C1] promotion[C2] demotion[--] >latency[000] usage[00000010] > *C2: type[C2] promotion[C3] demotion[C1] >latency[001] usage[00000119] > C3: type[C3] promotion[--] demotion[C2] >latency[057] usage[00000000] >active state: C2 >max_cstate: C8 >bus master activity: ffffffec The reason you are not entering OS C3 when on DC is because of bus master activity. To ignore it, do this: # echo 0 > /sys/module/processor/parameters/bm_history cheers, -Len >states: > C1: type[C1] promotion[C2] demotion[--] >latency[000] usage[00000010] > *C2: type[C2] promotion[C3] demotion[C1] >latency[001] usage[00000158] > C3: type[C3] promotion[--] demotion[C2] >latency[057] usage[00000000] - To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
