19 Jun, 2019

1 commit

  • Based on 2 normalized pattern(s):

    this program is free software you can redistribute it and or modify
    it under the terms of the gnu general public license version 2 as
    published by the free software foundation

    this program is free software you can redistribute it and or modify
    it under the terms of the gnu general public license version 2 as
    published by the free software foundation #

    extracted by the scancode license scanner the SPDX license identifier

    GPL-2.0-only

    has been chosen to replace the boilerplate/reference in 4122 file(s).

    Signed-off-by: Thomas Gleixner
    Reviewed-by: Enrico Weigelt
    Reviewed-by: Kate Stewart
    Reviewed-by: Allison Randal
    Cc: linux-spdx@vger.kernel.org
    Link: https://lkml.kernel.org/r/20190604081206.933168790@linutronix.de
    Signed-off-by: Greg Kroah-Hartman

    Thomas Gleixner
     

04 Mar, 2019

1 commit

  • * pm-opp:
    cpufreq: OMAP: Register an Energy Model
    cpufreq: imx6q: Register an Energy Model
    opp: no need to check return value of debugfs_create functions
    cpufreq: mediatek: Register an Energy Model
    cpufreq: scmi: Register an Energy Model
    cpufreq: arm_big_little: Register an Energy Model
    cpufreq: scpi: Register an Energy Model
    cpufreq: dt: Register an Energy Model

    Rafael J. Wysocki
     

13 Feb, 2019

1 commit


07 Feb, 2019

1 commit

  • Now that PM_OPP provides a helper function to estimate the power
    consumed by CPUs, make sure to try and register an Energy Model (EM)
    from cpufreq-dt, hence ensuring interested subsystems (the task
    scheduler, for example) can make use of that information when available.

    Signed-off-by: Quentin Perret
    Signed-off-by: Viresh Kumar

    Quentin Perret
     

31 Jan, 2019

1 commit


04 Oct, 2018

1 commit

  • We can not call dev_pm_opp_of_cpumask_remove_table() freely anymore
    since the latest OPP core updates as that uses reference counting to
    free resources. There are cases where no static OPPs are added (using
    DT) for a platform and trying to remove the OPP table may end up
    decrementing refcount which is already zero and hence generating
    warnings.

    Lets track if we were able to add static OPPs or not and then only
    remove the table based on that. Some reshuffling of code is also done to
    do that.

    Reported-by: Niklas Cassel
    Tested-by: Niklas Cassel
    Signed-off-by: Viresh Kumar

    Viresh Kumar
     

10 May, 2018

1 commit


20 Mar, 2018

1 commit

  • The cpufreq core is already validating the CPU frequency table after
    calling the ->init() callback of the cpufreq drivers and the drivers
    don't need to do the same anymore. Though they need to set the
    policy->freq_table field directly from the ->init() callback now.

    Stop validating the frequency table from cpufreq-dt driver.

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

    Viresh Kumar
     

08 Dec, 2017

2 commits

  • of_cpufreq_cooling_register() isn't used by anyone and so can be
    removed, but then we would be left with two routines:
    cpufreq_cooling_register() and of_cpufreq_power_cooling_register() that
    would look odd.

    Remove current implementation of of_cpufreq_cooling_register() and
    rename of_cpufreq_power_cooling_register() as
    of_cpufreq_cooling_register(). This simplifies lots of stuff.

    Acked-by: Eduardo Valentin
    Signed-off-by: Viresh Kumar
    Signed-off-by: Rafael J. Wysocki

    Viresh Kumar
     
  • All the callers of of_cpufreq_power_cooling_register() have almost
    identical code and it makes more sense to move that code into the helper
    as its all about reading DT properties.

    This got rid of lot of redundant code.

    Acked-by: Eduardo Valentin
    Signed-off-by: Viresh Kumar
    Signed-off-by: Rafael J. Wysocki

    Viresh Kumar
     

03 Oct, 2017

1 commit


01 Aug, 2017

1 commit

  • On many platforms, CPUs can do DVFS across cpufreq policies. i.e CPU
    from policy-A can change frequency of CPUs belonging to policy-B.

    This is quite common in case of ARM platforms where we don't
    configure any per-cpu register.

    Add a flag to identify such platforms and update
    cpufreq_can_do_remote_dvfs() to allow remote callbacks if this flag is
    set.

    Also enable the flag for cpufreq-dt driver which is used only on ARM
    platforms currently.

    Signed-off-by: Viresh Kumar
    Acked-by: Saravana Kannan
    Acked-by: Peter Zijlstra (Intel)
    Signed-off-by: Rafael J. Wysocki

    Viresh Kumar
     

28 May, 2017

1 commit

  • The CPU cooling driver uses the cpufreq policy, to get clip_cpus, the
    frequency table, etc. Most of the callers of CPU cooling driver's
    registration routines have the cpufreq policy with them, but they only
    pass the policy->related_cpus cpumask. The __cpufreq_cooling_register()
    routine then gets the policy by itself and uses it.

    It would be much better if the callers can pass the policy instead
    directly. This also fixes a basic design flaw, where the policy can be
    freed while the CPU cooling driver is still active.

    Signed-off-by: Viresh Kumar
    Reviewed-by: Lukasz Luba
    Tested-by: Lukasz Luba
    Signed-off-by: Eduardo Valentin

    Viresh Kumar
     

27 Jan, 2017

1 commit


06 Dec, 2016

1 commit


01 Dec, 2016

1 commit

  • Joonyoung Shim reported an interesting problem on his ARM octa-core
    Odoroid-XU3 platform. During system suspend, dev_pm_opp_put_regulator()
    was failing for a struct device for which dev_pm_opp_set_regulator() is
    called earlier.

    This happened because an earlier call to
    dev_pm_opp_of_cpumask_remove_table() function (from cpufreq-dt.c file)
    removed all the entries from opp_table->dev_list apart from the last CPU
    device in the cpumask of CPUs sharing the OPP.

    But both dev_pm_opp_set_regulator() and dev_pm_opp_put_regulator()
    routines get CPU device for the first CPU in the cpumask. And so the OPP
    core failed to find the OPP table for the struct device.

    This patch attempts to fix this problem by returning a pointer to the
    opp_table from dev_pm_opp_set_regulator() and using that as the
    parameter to dev_pm_opp_put_regulator(). This ensures that the
    dev_pm_opp_put_regulator() doesn't fail to find the opp table.

    Note that similar design problem also exists with other
    dev_pm_opp_put_*() APIs, but those aren't used currently by anyone and
    so we don't need to update them for now.

    Cc: 4.4+ # 4.4+
    Reported-by: Joonyoung Shim
    Signed-off-by: Stephen Boyd
    Signed-off-by: Viresh Kumar
    [ Viresh: Wrote commit log and tested on exynos 5250 ]
    Signed-off-by: Rafael J. Wysocki

    Stephen Boyd
     

13 Sep, 2016

2 commits

  • The cpufreq-dt driver is also used for systems with multiple
    clock/voltage domains for CPUs, i.e. multiple cpufreq policies in a
    system.

    And in such cases the platform users may want to enable "governor
    tunables per policy". Support that via platform data, as not all users
    of the driver would want that behavior.

    Reported-by: Juri Lelli
    Signed-off-by: Viresh Kumar
    Signed-off-by: Rafael J. Wysocki

    Viresh Kumar
     
  • This is leftover from an earlier patch which removed the usage of
    platform data but forgot to remove this line. Remove it now.

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

    Viresh Kumar
     

28 Apr, 2016

2 commits

  • There are no more users of platform-data for cpufreq-dt driver, get rid
    of it.

    Signed-off-by: Viresh Kumar
    Reviewed-by: Stephen Boyd
    Acked-by: Arnd Bergmann
    Signed-off-by: Rafael J. Wysocki

    Viresh Kumar
     
  • Existing platforms, which do not support operating-points-v2, can
    explicitly tell the opp core that some of the CPUs share opp tables,
    with help of dev_pm_opp_set_sharing_cpus().

    For such platforms, explicitly ask the opp core to provide list of CPUs
    sharing the opp table with current cpu device, before falling back to
    platform data.

    Signed-off-by: Viresh Kumar
    Acked-by: Arnd Bergmann
    Signed-off-by: Rafael J. Wysocki

    Viresh Kumar
     

05 Apr, 2016

1 commit


11 Feb, 2016

9 commits


28 Jan, 2016

1 commit

  • gcc warns quite a bit about values returned from allocate_resources()
    in cpufreq-dt.c:

    cpufreq-dt.c: In function 'cpufreq_init':
    cpufreq-dt.c:327:6: error: 'cpu_dev' may be used uninitialized in this function [-Werror=maybe-uninitialized]
    cpufreq-dt.c:197:17: note: 'cpu_dev' was declared here
    cpufreq-dt.c:376:2: error: 'cpu_clk' may be used uninitialized in this function [-Werror=maybe-uninitialized]
    cpufreq-dt.c:199:14: note: 'cpu_clk' was declared here
    cpufreq-dt.c: In function 'dt_cpufreq_probe':
    cpufreq-dt.c:461:2: error: 'cpu_clk' may be used uninitialized in this function [-Werror=maybe-uninitialized]
    cpufreq-dt.c:447:14: note: 'cpu_clk' was declared here

    The problem is that it's slightly hard for gcc to follow return
    codes across PTR_ERR() calls.

    This patch uses explicit assignments to the "ret" variable to make
    it easier for gcc to verify that the code is actually correct,
    without the need to add a bogus initialization.

    Signed-off-by: Arnd Bergmann
    Acked-by: Viresh Kumar
    Signed-off-by: Rafael J. Wysocki

    Arnd Bergmann
     

05 Jan, 2016

1 commit

  • The function can return negative values so it should be assigned
    to signed type.

    The problem has been detected using proposed semantic patch
    scripts/coccinelle/tests/unsigned_lesser_than_zero.cocci.

    Link: http://permalink.gmane.org/gmane.linux.kernel/2038576
    Signed-off-by: Andrzej Hajda
    Acked-by: Viresh Kumar
    Signed-off-by: Rafael J. Wysocki

    Andrzej Hajda
     

10 Dec, 2015

1 commit


15 Sep, 2015

2 commits


09 Sep, 2015

1 commit


03 Sep, 2015

3 commits

  • Tolerance applies on both sides of the target voltage, i.e. both min and
    max sides. But while checking if a voltage is supported by the regulator
    or not, we haven't taken care of tolerance on the lower side. Fix that.

    Cc: Lucas Stach
    Fixes: 045ee45c4ff2 ("cpufreq: cpufreq-dt: disable unsupported OPPs")
    Signed-off-by: Viresh Kumar
    Reviewed-by: Lucas Stach
    Signed-off-by: Rafael J. Wysocki

    Viresh Kumar
     
  • We need to explicitly mark OPPs as shared, when they are not defined
    with OPP-v2 bindings. This operation can potentially fail, and in that
    case we should at least print an error message.

    Fixes: 2e02d8723edf ("cpufreq: dt: Add support for operating-points-v2 bindings")
    Signed-off-by: Viresh Kumar
    Signed-off-by: Rafael J. Wysocki

    Viresh Kumar
     
  • We need to explicitly mark OPPs as shared, when they are not defined
    with OPP-v2 bindings. But this isn't required to be done if we failed to
    initialize OPP table.

    Reorder code to verify OPP count before marking them shared.

    Fixes: 2e02d8723edf ("cpufreq: dt: Add support for operating-points-v2 bindings")
    Signed-off-by: Viresh Kumar
    Signed-off-by: Rafael J. Wysocki

    Viresh Kumar
     

08 Aug, 2015

1 commit