lkml.org 
[lkml]   [2014]   [Oct]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH RFC 2/2] cpufreq: arm_big_little: provide cpu capacity
    On Wed, Oct 08, 2014 at 07:26:12AM +0100, Mike Turquette wrote:
    > Move the cpu capacity bits out of arch/arm/ and into the CPUfreq driver.
    > Not all ARM devices will use CPUfreq and it is unsafe to assume as such
    > in topology.c.
    >
    > Instead, use the new capacity_ops introduced into CFS. If this code is
    > generic enough then it could be factored and shared via a header to make
    > it easier for other CPUfreq drivers to take advantage of it.
    >
    > Signed-off-by: Mike Turquette <mturquette@linaro.org>
    > ---
    > This approach simply builds on top of Morten's series. I am not sure
    > that the per-cpu method is the best way to go in the future. And if so I
    > imagine that the CPUfreq core could provide everything except for the
    > cpu_eff part.
    >
    > In general I think that the overlap between CPUfreq drivers and
    > arch/arm/kernel/topology.c is something that needs to addresssed soon,
    > as both pieces of code are re-inventing parts of each other.

    I think it would be easier to deal with the capacity scaling if we split
    it into two scaling factors (like Vincent proposed by using the existing
    arch_scale_{cpu,freq}_capacity() functions). Then whatever handles
    frequency scaling doesn't have to coordinate with uarch scaling. Both
    would be factors in the range 0..1024. We would just multiply the two
    scaling factors in fair.c when needed (and shift as necessary).

    Wouldn't that make it simple enough that we can implement it in a
    generic way in arch/*/topology.c with a bit of help from the cpufreq
    framework without involving any drivers directly? Or is that just
    wishful thinking? :)


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