[lkml]   [2012]   [Apr]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [RFC PATCH] cpuidle: allow per cpu latencies
    On Fri, Apr 06, 2012 at 05:35:46PM +0200, Daniel Lezcano wrote:
    > On 04/06/2012 12:32 PM, Shilimkar, Santosh wrote:
    > > Peter,
    > >
    > > On Thu, Apr 5, 2012 at 7:07 PM, Arjan van de Ven<> wrote:
    > >> On 4/5/2012 2:53 AM, Peter De Schrijver wrote:
    > >>> This patch doesn't update all cpuidle device registrations. I will do that
    > >>
    > >> question is if you want to do per cpu latencies, or if you want to have
    > >> both types of C state in one big table, and have each of the tegra cpyu
    > >> types pick half of them...
    > >>
    > >>
    > > Indeed !! That should work.
    > > I thought the C-states are always per CPU based and during the
    > > cpuidle registration you can register C-state accordingly based on the
    > > specific CPU types with different latencies if needed.
    > >
    > > Am I missing something ?
    > That was the case before the cpuidle_state were moved from the
    > cpuidle_device to the cpuidle_driver structure [1].
    > That had the benefit of using a single latencies array instead of
    > multiple copy of the same array, which was the case until today.
    > I looked at the white paper for the tegra3 and understand this is no
    > longer true because of the 4-plus-1 architecture [2].

    The reason is not so much 4-plus-1, but in 4 CPU mode, only CPUs 1 - 3 can
    be powergated individually. To turn off CPU0, the external regulator for
    the entire cluster is turned off. This means latencies for CPU0 are different
    from the other CPUs.

    > With the increasing number of SoCs, we have a lot of new cpuidle drivers
    > and each time we modify something in the cpuidle core, that impacts all
    > the cpuidle drivers.
    > My feeling is we are going back and forth when patching the cpuidle core
    > and may be it is time to define a clear semantic before patching again
    > the cpuidle, no ?
    > What could nice is to have:
    > * in case of the same latencies for all cpus, use a single array
    > * in case of different latencies, group the same latencies into a
    > single array (I assume this is the case for 4-plus-1, right ?)
    > May be we can move the cpuidle_state to a per_cpu pointer like
    > cpuidle_devices in cpuidle.c and then add:
    > register_latencies(struct cpuidle_latencies l, int cpu);
    > If we have the same latencies for all the cpus, then we can register the
    > same array, which is only a pointer.

    Maybe we also want to make the 'disabled' flag per CPU then or provide some
    other way the number of C states can be different per CPU?



     \ /
      Last update: 2012-04-10 12:33    [W:0.025 / U:62.780 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site