Difference between revisions of "ACPI"

Line 100:

The CPU power management is hardware specific. It is described in APCI specs and also in AMD BIOS and Kernel Developer guide. The rest of this section describes the AMD specific part. AMD needs ACPI objects which describes the similar info as the legacy PowerNow table. Check the BKDG for details.

The content of the tables must be generated runtime, which is a bit problem, because the ~~DSDT table~~ must

The content of the tables must be generated runtime, which is a bit problem, because the AML code must be generated or DSDT patched. There is an acpigen infrastructure to generate the AML code.

be patched ~~runtime during the POST~~. ~~The only board which is doing is this~~ is the ~~AMD/Pistachio/DBM690T~~.

The actual content for family 0fh revF and later can be generated by complex algorithm implemented in ~~the~~

The actual content for family 0fh revF and later P-States can be generated by complex algorithm implemented in amd_model_fxx_generate_powernow(). This function should be called in acpi_fill_ssdt_generator() callback.

~~acpi files of DBM690T.~~ Up to revE, all P state info must be hardcoded in tables.

Up to revE, all P state info must be hardcoded in tables (not supported).

~~Proposed change: The generic post revE algorithm must be moved to the amd-acpi.c as well we can put this info to~~

~~SSDT table instead, which can be generated runtime. The AML bytecode generator as well as a P state table generator~~

~~were submitted to mailing list.~~

~~For now, you must include your Pstate info yourself using the generator and including that file in DSDT code~~.

===== C States =====

Difference between revisions of "ACPI"

Revision as of 20:12, 12 April 2009

Navigation menu

@@ Line 100: / Line 100: @@
 The CPU power management is hardware specific. It is described in APCI specs and also in AMD BIOS and Kernel Developer guide. The rest of this section describes the AMD specific part. AMD needs ACPI objects which describes the similar info as the legacy PowerNow table. Check the BKDG for details.
-The content of the  tables must be generated runtime, which is a bit problem, because the DSDT table must
+The content of the  tables must be generated runtime, which is a bit problem, because the AML code must be generated or DSDT patched. There is an acpigen infrastructure to generate the AML code.
-be patched runtime during the POST. The only board which is doing is this is the AMD/Pistachio/DBM690T.
-The actual content for family 0fh revF and later can be generated by complex algorithm implemented in the
+The actual content for family 0fh revF and later P-States can be generated by complex algorithm implemented in amd_model_fxx_generate_powernow(). This function should be called in acpi_fill_ssdt_generator() callback.
-acpi files of DBM690T. Up to revE, all P state info must be hardcoded in tables.
+Up to revE, all P state info must be hardcoded in tables (not supported).
-Proposed change: The generic post revE algorithm must be moved to the amd-acpi.c as well we can put this info to
-SSDT table instead, which can be generated runtime. The AML bytecode generator as well as a P state table generator
-were submitted to mailing list.
-For now, you must include your Pstate info yourself using the generator and including that file in DSDT code.
 ===== C States =====

Difference between revisions of "ACPI"

Revision as of 20:12, 12 April 2009

Navigation menu

Search