[patch] Support for asymetrical per-cpu Cx states

[Stephane E. Potvin]

Stephane E. Potvin wrote:
> What started as a quick check why my laptop was not giving me Cx states
> higher than C1 turned out in a major rework of the way the acpi_cpu
> driver works.
> 
> The attached patch makes the following modifications to the driver:
> 
> - Support for asymetrical and per-cpu Cx states. This is done by parsing
> the _CST packages for each cpu and tracking all the states individually,
> on a per-cpu basis.
> 
> - Support to revert to generic FADT/P_BLK based Cx control if the _CST
> package are not present on all cpus. In that case, the new driver will
> still support per-cpu Cx state handling. The driver will determine the
> highest Cx level that can be supported by all the cpus and configure the
> available Cx state based on that.
> 
> - Fixed the case where multiple cpus in the system share the same
> registers for Cx state handling. To do that, I added a new flag
> parameter to the acpi_PkgGas and acpi_bus_alloc_gas functions that
> enable the caller to add the RF_SHAREABLE flag. This will probably fix
> the case where enabling the HT core would remove all Cx states (except
> C1), but I have no mean to check it at this time. I've not added this
> flag to the other callers in the tree but I guess that some of them
> could use this flag when multiple cpus are present.
> 
> - I also found out that for Core Duo cpus, both cores seems to be taken
> out of C3 state when any one of the cores need to transition out. This
> broke the short sleep detection logic. I disabled it if there are more
> than one cpu in the system for now as it fixed it in my case. I guess
> that proper quirks handling will be required to fix this for known non
> working systems.
> 
> - Added support to control cx_lowest on a per-cpu basis. I also
> implemented a generic cx_lowest to enable changing cx_lowest for all
> cpus with a single sysctl and for backward compatibility. The value
> returned on read is kind of meaningless (is there an easy way to have a
> write-only sysctl?) I've not done the same for the cx_supported case as
> I was not sure which way to handle it in case all supported Cx states
> were not symmetrical. Sample output for the new sysctl:
> 
> hw.acpi.cpu.0.cx_supported: C1/1 C2/1 C3/57
> hw.acpi.cpu.0.cx_lowest: C3
> hw.acpi.cpu.0.cx_usage: 0.00% 43.16% 56.83%
> hw.acpi.cpu.1.cx_supported: C1/1 C2/1 C3/57
> hw.acpi.cpu.1.cx_lowest: C3
> hw.acpi.cpu.1.cx_usage: 0.00% 45.65% 54.34%
> hw.acpi.cpu.cx_lowest: C3
> 
> I would appreciate any feedback, positive or negative, on this :)

I inadvertently attached a version of the patch that still has some
debugging cruft in my previous message. Here's an updated version that
should be more clean.

Steph
-------------- next part --------------
A non-text attachment was scrubbed...
Name: acpi_cpu.diff
Type: text/x-patch
Size: 30948 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-acpi/attachments/20060608/871305b3/acpi_cpu.bin