07 Jan, 2020

1 commit

  • The cpufreq_reboot_notifier_evt() call cpufreq_cpu_get() to get the
    cpufreq policy of cpu0, meanwhile, it also increments the kobject
    reference count to mark it busy. However, a corresponding call of
    cpufreq_cpu_put() is ignored to decrement the kobject reference count
    back, which may lead to a potential stuck risk that the cpuhp thread
    deadly waits for dropping of kobject refcount when cpufreq policy free.

    With this patch, the cpuhp thread can be easily exercised by attempting
    to force an unbind of the CPUfreq driver.

    Signed-off-by: chenqiwu
    Signed-off-by: Viresh Kumar

    chenqiwu
     

18 Jul, 2019

1 commit

  • * pm-cpufreq:
    cpufreq: Make cpufreq_generic_init() return void
    cpufreq: imx-cpufreq-dt: Add i.MX8MN support
    cpufreq: Add QoS requests for userspace constraints
    cpufreq: intel_pstate: Reuse refresh_frequency_limits()
    cpufreq: Register notifiers with the PM QoS framework
    PM / QoS: Add support for MIN/MAX frequency constraints
    PM / QOS: Pass request type to dev_pm_qos_read_value()
    PM / QOS: Rename __dev_pm_qos_read_value() and dev_pm_qos_raw_read_value()
    PM / QOS: Pass request type to dev_pm_qos_{add|remove}_notifier()

    Rafael J. Wysocki
     

16 Jul, 2019

1 commit

  • It always returns 0 (success) and its return type should really be void.

    Over that, many drivers have added error handling code based on its
    return value, which is not required at all.

    Change its return type to void and update all the callers.

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

    Viresh Kumar
     

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
     

09 Feb, 2017

1 commit


19 Feb, 2015

1 commit

  • The two functions s3c2416_cpufreq_driver_init and s3c_cpufreq_register
    are marked init but are called from a context that might be run after
    the __init sections are discarded, as the compiler points out:

    WARNING: vmlinux.o(.data+0x1ad9dc): Section mismatch in reference from the variable s3c2416_cpufreq_driver to the function .init.text:s3c2416_cpufreq_driver_init()
    WARNING: drivers/built-in.o(.text+0x35b5dc): Section mismatch in reference from the function s3c2410a_cpufreq_add() to the function .init.text:s3c_cpufreq_register()

    This removes the __init markings.

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

    Arnd Bergmann
     

30 Apr, 2014

1 commit


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
     

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


10 Aug, 2013

1 commit


05 Jul, 2013

1 commit

  • Pull trivial tree updates from Jiri Kosina:
    "The usual stuff from trivial tree"

    * 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jikos/trivial: (34 commits)
    treewide: relase -> release
    Documentation/cgroups/memory.txt: fix stat file documentation
    sysctl/net.txt: delete reference to obsolete 2.4.x kernel
    spinlock_api_smp.h: fix preprocessor comments
    treewide: Fix typo in printk
    doc: device tree: clarify stuff in usage-model.txt.
    open firmware: "/aliasas" -> "/aliases"
    md: bcache: Fixed a typo with the word 'arithmetic'
    irq/generic-chip: fix a few kernel-doc entries
    frv: Convert use of typedef ctl_table to struct ctl_table
    sgi: xpc: Convert use of typedef ctl_table to struct ctl_table
    doc: clk: Fix incorrect wording
    Documentation/arm/IXP4xx fix a typo
    Documentation/networking/ieee802154 fix a typo
    Documentation/DocBook/media/v4l fix a typo
    Documentation/video4linux/si476x.txt fix a typo
    Documentation/virtual/kvm/api.txt fix a typo
    Documentation/early-userspace/README fix a typo
    Documentation/video4linux/soc-camera.txt fix a typo
    lguest: fix CONFIG_PAE -> CONFIG_x86_PAE in comment
    ...

    Linus Torvalds
     

28 Jun, 2013

1 commit

  • * pm-cpufreq-arm:
    cpufreq: tegra: call CPUFREQ_POSTCHANGE notfier in error cases
    cpufreq: s3c64xx: call CPUFREQ_POSTCHANGE notfier in error cases
    cpufreq: omap: call CPUFREQ_POSTCHANGE notfier in error cases
    cpufreq: imx6q: call CPUFREQ_POSTCHANGE notfier in error cases
    cpufreq: exynos: call CPUFREQ_POSTCHANGE notfier in error cases
    cpufreq: dbx500: call CPUFREQ_POSTCHANGE notfier in error cases
    cpufreq: davinci: call CPUFREQ_POSTCHANGE notfier in error cases
    cpufreq: arm-big-little: call CPUFREQ_POSTCHANGE notfier in error cases
    cpufreq: s3c2416: fix forgotten driver_data conversions

    Rafael J. Wysocki
     

24 Jun, 2013

1 commit


18 Jun, 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
     

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
     

20 Jul, 2012

1 commit


01 Mar, 2012

1 commit

  • The S3C2416/S3C2450 SoCs support two sources for the armclk.

    The first source is the so called armdiv which divides the msysclk down
    to provide necessary cpu rates. In this mode the core voltage must be
    always at 1.3V. The frequency from the armdiv is not allowed to be
    lower than the hclk frequency.

    In the second mode the armclk can be sourced directly from the hclk in
    the so called "dynamic voltags scaling" (dvs) mode. Here the armdiv
    isn't used at all. Also in this mode the core voltage may be lowered.
    Existing hardware and tests with it suggest 1.0V as sufficient.

    When changing the clock source to the armdiv from the hclk, the SoC
    shows stability issues if the new frequency is higher than the current
    hclk frequency. Hence the driver always forces the armdiv to the hclk
    frequency before the source change and lets the cpufreq issue another
    set_target call for higher frequencies.

    To mark the hclk frequency as lower as the corresponding armdiv
    frequency it is set 1MHz below the real frequency. This lets the cpufreq
    framework change between 133MHz based on hclk and 133MHz based on armdiv
    at will.

    Signed-off-by: Heiko Stuebner
    Tested-by: Andrey Gusakov
    Signed-off-by: Dave Jones

    Heiko Stübner