20 Oct, 2014

1 commit


03 Sep, 2014

1 commit

  • The powersave clock acts like a multiplexer for the cpu, selecting
    either the clock signal derived from the cpu pll or from the ddr clock.
    This patch changes powersave from a gate clock to a mux clock to better
    reflect this behavior.

    This is a cleaner approach whereby the frequency of the cpu always
    matches the rate of powersave_clk. The cpufreq driver for the kirkwood
    platform no longer must parse this behavior out of various calls to
    clk_enable and clk_disable, but can instead simply select the parent cpu
    it wants when changing rate. Likewise when requesting the cpu rate we
    need only query powersave_clk's rate through the usual call to
    clk_get_rate.

    The new clock data and corresponding changes to the cpufreq driver are
    combined into this single commit to avoid a git bisect issue where this
    cpufreq driver fails to work properly between the commit that updates
    the kirkwood clock driver and the commit that changes how the cpufreq
    driver uses that clock.

    Cc: Tomeu Vizoso
    Cc: Rafael J. Wysocki
    Tested-by: Andrew Lunn
    Acked-by: Viresh Kumar
    Signed-off-by: Mike Turquette

    Mike Turquette
     

07 Apr, 2014

1 commit

  • Currently cpufreq frequency table has two fields: frequency and driver_data.
    driver_data is only for drivers' internal use and cpufreq core shouldn't use
    it at all. But with the introduction of BOOST frequencies, this assumption
    was broken and we started using it as a flag instead.

    There are two problems due to this:
    - It is against the description of this field, as driver's data is used by
    the core now.
    - if drivers fill it with -3 for any frequency, then those frequencies are
    never considered by cpufreq core as it is exactly same as value of
    CPUFREQ_BOOST_FREQ, i.e. ~2.

    The best way to get this fixed is by creating another field flags which
    will be used for such flags. This patch does that. Along with that various
    drivers need modifications due to the change of struct cpufreq_frequency_table.

    Reviewed-by: Gautham R Shenoy
    Signed-off-by: Viresh Kumar
    Signed-off-by: Rafael J. Wysocki

    Viresh Kumar
     

12 Mar, 2014

1 commit


06 Jan, 2014

1 commit

  • Sometimes boot loaders set CPU frequency to a value outside of frequency table
    present with cpufreq core. In such cases CPU might be unstable if it has to run
    on that frequency for long duration of time and so its better to set it to a
    frequency which is specified in frequency table.

    On some systems we can't really say what frequency we're running at the moment
    and so for these we shouldn't check if we are running at a frequency present in
    frequency table. And so we really can't force this for all the cpufreq drivers.

    Hence we are created another flag here: CPUFREQ_NEED_INITIAL_FREQ_CHECK that
    will be marked by platforms which want to go for this check at boot time.

    Initially this is done for all ARM platforms but others may follow if required.

    Signed-off-by: Viresh Kumar
    Signed-off-by: Rafael J. Wysocki

    Viresh Kumar
     

31 Oct, 2013

1 commit

  • Most of the drivers do following in their ->target_index() routines:

    struct cpufreq_freqs freqs;
    freqs.old = old freq...
    freqs.new = new freq...

    cpufreq_notify_transition(policy, &freqs, CPUFREQ_PRECHANGE);

    /* Change rate here */

    cpufreq_notify_transition(policy, &freqs, CPUFREQ_POSTCHANGE);

    This is replicated over all cpufreq drivers today and there doesn't exists a
    good enough reason why this shouldn't be moved to cpufreq core instead.

    There are few special cases though, like exynos5440, which doesn't do everything
    on the call to ->target_index() routine and call some kind of bottom halves for
    doing this work, work/tasklet/etc..

    They may continue doing notification from their own code as flag:
    CPUFREQ_ASYNC_NOTIFICATION is already set for them.

    All drivers are also modified in this patch to avoid breaking 'git bisect', as
    double notification would happen otherwise.

    Acked-by: Hans-Christian Egtvedt
    Acked-by: Jesper Nilsson
    Acked-by: Linus Walleij
    Acked-by: Russell King
    Acked-by: Stephen Warren
    Tested-by: Andrew Lunn
    Tested-by: Nicolas Pitre
    Reviewed-by: Lan Tianyu
    Signed-off-by: Viresh Kumar
    Signed-off-by: Rafael J. Wysocki

    Viresh Kumar
     

26 Oct, 2013

1 commit

  • Currently, the prototype of cpufreq_drivers target routines is:

    int target(struct cpufreq_policy *policy, unsigned int target_freq,
    unsigned int relation);

    And most of the drivers call cpufreq_frequency_table_target() to get a valid
    index of their frequency table which is closest to the target_freq. And they
    don't use target_freq and relation after that.

    So, it makes sense to just do this work in cpufreq core before calling
    cpufreq_frequency_table_target() and simply pass index instead. But this can be
    done only with drivers which expose their frequency table with cpufreq core. For
    others we need to stick with the old prototype of target() until those drivers
    are converted to expose frequency tables.

    This patch implements the new light weight prototype for target_index() routine.
    It looks like this:

    int target_index(struct cpufreq_policy *policy, unsigned int index);

    CPUFreq core will call cpufreq_frequency_table_target() before calling this
    routine and pass index to it. Because CPUFreq core now requires to call routines
    present in freq_table.c CONFIG_CPU_FREQ_TABLE must be enabled all the time.

    This also marks target() interface as deprecated. So, that new drivers avoid
    using it. And Documentation is updated accordingly.

    It also converts existing .target() to newly defined light weight
    .target_index() routine for many driver.

    Acked-by: Hans-Christian Egtvedt
    Acked-by: Jesper Nilsson
    Acked-by: Linus Walleij
    Acked-by: Russell King
    Acked-by: David S. Miller
    Tested-by: Andrew Lunn
    Signed-off-by: Viresh Kumar
    Signed-off-by: Rafael J. Wysocki

    Viresh Kumar
     

16 Oct, 2013

3 commits


01 Oct, 2013

1 commit


23 Aug, 2013

1 commit

  • Pull DT/core/cpufreq cpu_ofnode updates for v3.12 from Sudeep KarkadaNagesha.

    * 'cpu_of_node' of git://linux-arm.org/linux-skn:
    cpufreq: pmac32-cpufreq: remove device tree parsing for cpu nodes
    cpufreq: pmac64-cpufreq: remove device tree parsing for cpu nodes
    cpufreq: maple-cpufreq: remove device tree parsing for cpu nodes
    cpufreq: arm_big_little: remove device tree parsing for cpu nodes
    cpufreq: kirkwood-cpufreq: remove device tree parsing for cpu nodes
    cpufreq: spear-cpufreq: remove device tree parsing for cpu nodes
    cpufreq: highbank-cpufreq: remove device tree parsing for cpu nodes
    cpufreq: cpufreq-cpu0: remove device tree parsing for cpu nodes
    cpufreq: imx6q-cpufreq: remove device tree parsing for cpu nodes
    drivers/bus: arm-cci: avoid parsing DT for cpu device nodes
    ARM: mvebu: remove device tree parsing for cpu nodes
    ARM: topology: remove hwid/MPIDR dependency from cpu_capacity
    of/device: add helper to get cpu device node from logical cpu index
    driver/core: cpu: initialize of_node in cpu's device struture
    ARM: DT/kernel: define ARM specific arch_match_cpu_phys_id
    of: move of_get_cpu_node implementation to DT core library
    powerpc: refactor of_get_cpu_node to support other architectures
    openrisc: remove undefined of_get_cpu_node declaration
    microblaze: remove undefined of_get_cpu_node declaration

    Rafael J. Wysocki
     

21 Aug, 2013

1 commit


10 Aug, 2013

1 commit


04 Jun, 2013

1 commit

  • The "index" field of struct cpufreq_frequency_table was never an
    index and isn't used at all by the cpufreq core. It only is useful
    for cpufreq drivers for their internal purposes.

    Many people nowadays blindly set it in ascending order with the
    assumption that the core will use it, which is a mistake.

    Rename it to "driver_data" as that's what its purpose is. All of its
    users are updated accordingly.

    [rjw: Changelog]
    Signed-off-by: Viresh Kumar
    Acked-by: Simon Horman
    Signed-off-by: Rafael J. Wysocki

    Viresh Kumar
     

12 May, 2013

1 commit


02 Apr, 2013

1 commit

  • policy->cpus contains all online cpus that have single shared clock line. And
    their frequencies are always updated together.

    Many SMP system's cpufreq drivers take care of this in individual drivers but
    the best place for this code is in cpufreq core.

    This patch modifies cpufreq_notify_transition() to notify frequency change for
    all cpus in policy->cpus and hence updates all users of this API.

    Signed-off-by: Viresh Kumar
    Acked-by: Stephen Warren
    Tested-by: Stephen Warren
    Signed-off-by: Rafael J. Wysocki

    Viresh Kumar
     

01 Apr, 2013

1 commit

  • Convert all uses of devm_request_and_ioremap() to the newly introduced
    devm_ioremap_resource() which provides more consistent error handling.

    devm_ioremap_resource() provides its own error messages so all explicit
    error messages can be removed from the failure code paths.

    Signed-off-by: Silviu-Mihai Popescu
    Acked-by: Viresh Kumar
    Signed-off-by: Rafael J. Wysocki

    Silviu-Mihai Popescu
     

09 Feb, 2013

1 commit