Re: [RFC v1 0/6] CPPC as a PID backend

2014-09-10 Thread Ashwin Chaugule
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

Re: [RFC v1 0/6] CPPC as a PID backend

2014-09-10 Thread Dirk Brandewie
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.

Re: [RFC v1 0/6] CPPC as a PID backend

2014-09-10 Thread Ashwin Chaugule
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

Re: [RFC v1 0/6] CPPC as a PID backend

2014-09-10 Thread Dirk Brandewie
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

[RFC v1 0/6] CPPC as a PID backend

2014-09-09 Thread Ashwin Chaugule
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