On 10 September 2014 13:31, Dirk Brandewie wrote:
> On 09/10/2014 09:11 AM, Ashwin Chaugule wrote:
>> On 10 September 2014 11:44, Dirk Brandewie
>> With the current split I think you will still be able to maintain
>> Intel specific changes for the future in the backend driver. The PID
>> algorith
On 09/10/2014 09:11 AM, Ashwin Chaugule wrote:
On 10 September 2014 11:44, Dirk Brandewie wrote:
Hi Ashwin,
Hi Dirk,
I think the CPPC based driver should be a separate driver.
We made the conscious decision to not use any of the ACPI mechanisms
to enumerate or control P state selection.
On 10 September 2014 11:44, Dirk Brandewie wrote:
> Hi Ashwin,
Hi Dirk,
>
> I think the CPPC based driver should be a separate driver.
>
> We made the conscious decision to not use any of the ACPI mechanisms
> to enumerate or control P state selection. Experience over the years
> has shown that
Hi Ashwin,
I think the CPPC based driver should be a separate driver.
We made the conscious decision to not use any of the ACPI mechanisms
to enumerate or control P state selection. Experience over the years
has shown that the quality/accuracy of the BIOS/ACPI implementations
vary widely across
This patchset introduces CPPC(Collaborative Processor Performance Control) as a
backend
to the PID governor. The PID governor from intel_pstate.c maps cleanly onto
some CPPC
interfaces.
e.g. The CPU performance requests are made on a continuous scale as against
discrete pstate
levels. The CPU pe
5 matches
Mail list logo