>-----Original Message----- >From: Youquan,Song [mailto:youquan.song@xxxxxxxxxxxxxxx] >Sent: Monday, December 14, 2009 5:13 AM >To: linux@xxxxxxxxxxxxxxxxxxxx >Cc: Dominik Brodowski; lenb@xxxxxxxxxx; Pallipadi, Venkatesh; >Liu, Kent; Guo, Chaohong; Song, Youquan; linux-acpi@xxxxxxxxxxxxxxx >Subject: Re: [PATCH]acpi c-states: Fix ACPI C3 is wrongly mapped to C2 > >> > Yes, but what happens if there are two states of type C2? >The whole concept >> > of "type C<number>" and "state C<number>" was broken from >the beginning... >> >> Sorry. In my mind, there is no two states of ACPI C2. If processor C3 >> above are mapped to ACPI C3, so processor C1 is mapped to ACPI C1, >> processor C2 is mapped to ACPI C2. >> Len Brown, Am I right? >> >> If I am wrong, I will file another patches for it. > >This patch handle the ACPI C2 invlidation on some platform. >Another patch "acpi c-states: Fix multiply C-states name >disturbance" will unify multiply C-states name. > I assume this patch is not needed with your other patch "acpi c-states: Fix multiply C-states name disturbance". I don't like /proc/acpi/processor/CPUx/power C1: type[C1] promotion[--] demotion[--] C2: <not supported> C3: type[C3] promotion[--] demotion[--] Because there are systems with more than one ACPI C3 C-state and this change will not help such systems. Also, this has potential to break applications like powertop that depend on current output format. Thanks, Venki-- 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
