https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=292615
Olivier Certner <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #267532|0 |1 is obsolete| | Assignee|[email protected] |[email protected] Status|Open |In Progress --- Comment #35 from Olivier Certner <[email protected]> --- Created attachment 267549 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=267549&action=edit Patch with candidate fix and more knobs This new patch (untested on real hardware) essentially does two things: 1. A potential fix for Martin's case, where the CPPC_CAPABILITY_1 was not filled up correctly after initialization (to 0). The original values of min and max performance in CPPC_REQUEST seem inconsistent (as the min value is lower than the max one; unless AMD's APM is wrong...), so the plan of leaving them untouched does not work (confirmed by Martin's experiments). When the min and max performance values in CPPC_CAPABILITY_1 are not sorted correctly or are equal (covers the above-mentioned case of staying at 0), use values as suggested by the ACPI spec for generic CPPC (0 for min, 255 for max). 2. I have added knobs to control the min, max and desired performance levels in the CPPC_REQUEST register. To follow, instructions on what to report. -- You are receiving this mail because: You are the assignee for the bug.
