• Prashanth Prakash's avatar
    cpufreq / CPPC: Set platform specific transition_delay_us · d4f3388a
    Prashanth Prakash authored
    Add support to specify platform specific transition_delay_us instead
    of using the transition delay derived from PCC.
    
    With commit 3d41386d (cpufreq: CPPC: Use transition_delay_us
    depending transition_latency) we are setting transition_delay_us
    directly and not applying the LATENCY_MULTIPLIER. Because of that,
    on Qualcomm Centriq we can end up with a very high rate of frequency
    change requests when using the schedutil governor (default
    rate_limit_us=10 compared to an earlier value of 10000).
    
    The PCC subspace describes the rate at which the platform can accept
    commands on the CPPC's PCC channel. This includes read and write
    command on the PCC channel that can be used for reasons other than
    frequency transitions. Moreover the same PCC subspace can be used by
    multiple freq domains and deriving transition_delay_us from it as we
    do now can be sub-optimal.
    
    Moreover if a platform does not use PCC for desired_perf register then
    there is no way to compute the transition latency or the delay_us.
    
    CPPC does not have a standard defined mechanism to get the transition
    rate or the latency at the moment.
    
    Given the above limitations, it is simpler to have a platform specific
    transition_delay_us and rely on PCC derived value only if a platform
    specific value is not available.
    Signed-off-by: default avatarPrashanth Prakash <[email protected]>
    Cc: 4.14+ <[email protected]> # 4.14+
    Fixes: 3d41386d (cpufreq: CPPC: Use transition_delay_us depending transition_latency)
    Signed-off-by: default avatarRafael J. Wysocki <[email protected]>
    d4f3388a
cppc_cpufreq.c 7.9 KB