[Intel-gfx] [RFC] drm/i915: Add a new modparam for customized ring multiplier

[Sagar Arun Kamble]

Since ring frequency programming needs consideration of both IA and GT 
frequency requests I think keeping the logic
to program the ring frequency table in driver that monitors both IA/GT 
busyness and power budgets like intel_ips
will be more appropriate. intel_ips is relying on global load derived 
from all CPUs.
I understand that power awareness and busyness based policy might be 
trickier but having that as tunable will give better flexibility.

On 1/3/2018 11:51 PM, Yaodong Li wrote:
>
>>>> You are thinking of plugging into intel_pstate to make it smarter 
>>>> for ia freq transitions?
>> Yep. This seems a correct step to give some automatic support instead 
>> of parameter/hardcoded multiplier.
>>
> Does this mean we should use cpufreq/intel_pstate based approach 
> instead of the current modparam solution for Gen9?
>
> Some concerns and questions about intel_pstate approach:
> a) Currently, we cannot get the accurate pstate/target freq value from 
> cpufreq in intel_pstate active mode since
>      these values won't be exported to cpufreq layer, so if we won't 
> change intel_pstate code then we only can get
>      the max cpu freq of a new policy.
> b) intel_pstate policy is attached to each logic cpu, which means we 
> will receive policy/freq transition notification
>     for each logic cpu freq change. One question is how we are going 
> to decide the freq of the ring? just use the max
>     cpu freq reported?
> c) With the intel_pstate approach we may still run into thermal 
> throttling, in this case, can a certain cooling device
>     be triggered to lower the cpu freq?
>
> Thanks and Regards,
> -Jackie
>