lkml.org 
[lkml]   [2014]   [Sep]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
SubjectRe: [RFC v1 0/6] CPPC as a PID backend
From
On 10 September 2014 11:44, Dirk Brandewie <dirk.brandewie@gmail.com> 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 the quality/accuracy of the BIOS/ACPI implementations
> vary widely across OEM's and platform types from a single OEM. Features
> that always work on a server platform from a given OEM may not work or
> provide bad information on client platforms for example.
>
> Another reason for doing intel_pstate was to be able to land intel specific
> features and fixes without breaking other architectures as the power
> management capabilities of the platform evolve. As processors that support
> Hardware P states (HWP) as described in section 14.4 of the current SDM
> come into the market intel_pstate will change to not doing much other
> than enabling HWP and providing an interface to forward user configuration
> requests to the processor if the user chooses to enable HWP otherwise the
> current mechanisms will be used. This is why the intel_pstate sysfs
> interface is the way it is to be able to map cleanly to HWP and provide
> an abstract interface going forward.
>
> Having separate drivers allows the system integrator/user to select the
> most appropriate mechanism for their system.
>
> --Dirk

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
algorithm seems platform independent anyway and the PID knobs are
exported to userspace for platform specific tuning. The Intel backend
driver should be unaffected by the CPPC (ACPI) backend. We can also
make them mutually exclusive at runtime.

Or are you suggesting using PID + CPPC as another driver? IIUC, that
would lead to a lot of redundancy.

Cheers,
Ashwin


\
 
 \ /
  Last update: 2014-09-10 18:41    [W:0.072 / U:0.672 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site