[PATCH] cpufreq: intel_pstate: Clarify effective CPU frequency

From: Srinivas Pandruvada
Date: Wed Oct 04 2017 - 18:46:31 EST

Add section for resultant frequency during GPU workloads.

Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@xxxxxxxxxxxxxxx>
Documentation/admin-guide/pm/intel_pstate.rst | 19 +++++++++++++++++++
1 file changed, 19 insertions(+)

diff --git a/Documentation/admin-guide/pm/intel_pstate.rst b/Documentation/admin-guide/pm/intel_pstate.rst
index d2b6fda..a7c6308 100644
--- a/Documentation/admin-guide/pm/intel_pstate.rst
+++ b/Documentation/admin-guide/pm/intel_pstate.rst
@@ -482,6 +482,25 @@ on the following rules, regardless of the current operation mode of the driver:

3. The global and per-policy limits can be set independently.

+One important point to note is that all the above limit controls including
+``no_turbo``, only limits the P-state requests by the intel_pstate driver. The
+actual performance delivered by the processor is also influenced by GPU
+(Graphics processing unit) for GPU bound workloads. So, it is possible
+that, while GPU is requesting higher frequencies, the resultant P-state
+(CPU frequency) can be higher than the limits set via sysfs.
+Equivalent limits must, therefore, also be set for the GPU.
+An example where an Intel i915 GPU is used:
+#cat /sys/kernel/debug/dri/0/i915_ring_freq_table
+displays effective CPU frequency for a GPU frequency. To limit
+a CPU frequency, a corresponding GPU frequency limit must also be placed:
+/sys/class/drm/card0/gt_max_freq_mhz and
If the `HWP feature is enabled in the processor <Active Mode With HWP_>`_, the
resulting effective values are written into its registers whenever the limits
change in order to request its internal P-state selection logic to always set