Eric Lee / smarc-fsl-linux-kernel

24 Mar, 2018

1 commit

  • b453f9d8c   cpufreq: longhaul: Revert transition_delay_us to 200 ms ... Browse Code »

    [ Upstream commit 1d0d064307cbfd8546841f6e9d94d02c55e45e1e ]

    The commit e948bc8fbee0 ("cpufreq: Cap the default transition delay
    value to 10 ms") caused a regression on EPIA-M min-ITX computer where
    shutdown or reboot hangs occasionally with a print message like:

    longhaul: Warning: Timeout while waiting for idle PCI bus
    cpufreq: __target_index: Failed to change cpu frequency: -16

    This probably happens because the cpufreq governor tries to change the
    frequency of the CPU faster than allowed by the hardware.

    Before the above commit, the default transition delay was set to 200 ms
    for a transition_latency of 200000 ns. Lets revert back to that
    transition delay value to fix it. Note that several other transition
    delay values were tested like 20 ms and 30 ms and none of them have
    resolved system hang issue completely.

    Fixes: e948bc8fbee0 (cpufreq: Cap the default transition delay value to 10 ms)
    Reported-by: Meelis Roos
    Suggested-by: Rafael J. Wysocki
    Signed-off-by: Viresh Kumar
    Signed-off-by: Rafael J. Wysocki
    Signed-off-by: Sasha Levin
    Signed-off-by: Greg Kroah-Hartman

    Viresh Kumar
     

22 Feb, 2018

1 commit

  • 325cbb04d   x86/cpu: Rename cpu_data.x86_mask to cpu_data.x86_stepping ... Browse Code »

    commit b399151cb48db30ad1e0e93dd40d68c6d007b637 upstream.

    x86_mask is a confusing name which is hard to associate with the
    processor's stepping.

    Additionally, correct an indent issue in lib/cpu.c.

    Signed-off-by: Jia Zhang
    [ Updated it to more recent kernels. ]
    Cc: Linus Torvalds
    Cc: Peter Zijlstra
    Cc: Thomas Gleixner
    Cc: bp@alien8.de
    Cc: tony.luck@intel.com
    Link: http://lkml.kernel.org/r/1514771530-70829-1-git-send-email-qianyue.zj@alibaba-inc.com
    Signed-off-by: Ingo Molnar
    Signed-off-by: Greg Kroah-Hartman

    Jia Zhang
     

17 May, 2016

1 commit

  • d57d39431   Merge tag 'pm-4.7-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm ... Browse Code »

    Pull power management updates from Rafael Wysocki:
    "The majority of changes go into the cpufreq subsystem this time.

    To me, quite obviously, the biggest ticket item is the new "schedutil"
    governor. Interestingly enough, it's the first new cpufreq governor
    since the beginning of the git era (except for some out-of-the-tree
    ones).

    There are two main differences between it and the existing governors.
    First, it uses the information provided by the scheduler directly for
    making its decisions, so it doesn't have to track anything by itself.
    Second, it can invoke drivers (supporting that feature) to adjust CPU
    performance right away without having to spawn work items to be
    executed in process context or similar. Currently, the acpi-cpufreq
    driver is the only one supporting that mode of operation, but then it
    is used on a large number of systems.

    The "schedutil" governor as included here is very simple and mostly
    regarded as a foundation for future work on the integration of the
    scheduler with CPU power management (in fact, there is work in
    progress on top of it already). Nevertheless it works and the
    preliminary results obtained with it are encouraging.

    There also is some consolidation of CPU frequency management for ARM
    platforms that can add their machine IDs the the new stub dt-platdev
    driver now and that will take care of creating the requisite platform
    device for cpufreq-dt, so it is not necessary to do that in platform
    code any more. Several ARM platforms are switched over to using this
    generic mechanism.

    In addition to that, the intel_pstate driver is now going to respect
    CPU frequency limits set by the platform firmware (or a BMC) and
    provided via the ACPI _PPC object.

    The devfreq subsystem is getting a new "passive" governor for SoCs
    subsystems that will depend on somebody else to manage their voltage
    rails and its support for Samsung Exynos SoCs is consolidated.

    The rest is support for new hardware (Intel Broxton support in
    intel_idle for one example), bug fixes, optimizations and cleanups in
    a number of places.

    Specifics:

    - New cpufreq "schedutil" governor (making decisions based on CPU
    utilization information provided by the scheduler and capable of
    switching CPU frequencies right away if the underlying driver
    supports that) and support for fast frequency switching in the
    acpi-cpufreq driver (Rafael Wysocki)

    - Consolidation of CPU frequency management on ARM platforms allowing
    them to get rid of some platform-specific boilerplate code if they
    are going to use the cpufreq-dt driver (Viresh Kumar, Finley Xiao,
    Marc Gonzalez)

    - Support for ACPI _PPC and CPU frequency limits in the intel_pstate
    driver (Srinivas Pandruvada)

    - Fixes and cleanups in the cpufreq core and generic governor code
    (Rafael Wysocki, Sai Gurrappadi)

    - intel_pstate driver optimizations and cleanups (Rafael Wysocki,
    Philippe Longepe, Chen Yu, Joe Perches)

    - cpufreq powernv driver fixes and cleanups (Akshay Adiga, Shilpasri
    Bhat)

    - cpufreq qoriq driver fixes and cleanups (Jia Hongtao)

    - ACPI cpufreq driver cleanups (Viresh Kumar)

    - Assorted cpufreq driver updates (Ashwin Chaugule, Geliang Tang,
    Javier Martinez Canillas, Paul Gortmaker, Sudeep Holla)

    - Assorted cpufreq fixes and cleanups (Joe Perches, Arnd Bergmann)

    - Fixes and cleanups in the OPP (Operating Performance Points)
    framework, mostly related to OPP sharing, and reorganization of
    OF-dependent code in it (Viresh Kumar, Arnd Bergmann, Sudeep Holla)

    - New "passive" governor for devfreq (for SoC subsystems that will
    rely on someone else for the management of their power resources)
    and consolidation of devfreq support for Exynos platforms, coding
    style and typo fixes for devfreq (Chanwoo Choi, MyungJoo Ham)

    - PM core fixes and cleanups, mostly to make it work better with the
    generic power domains (genpd) framework, and updates for that
    framework (Ulf Hansson, Thierry Reding, Colin Ian King)

    - Intel Broxton support for the intel_idle driver (Len Brown)

    - cpuidle core optimization and fix (Daniel Lezcano, Dave Gerlach)

    - ARM cpuidle cleanups (Jisheng Zhang)

    - Intel Kabylake support for the RAPL power capping driver (Jacob
    Pan)

    - AVS (Adaptive Voltage Switching) rockchip-io driver update (Heiko
    Stuebner)

    - Updates for the cpupower tool (Arjun Sreedharan, Colin Ian King,
    Mattia Dongili, Thomas Renninger)"

    * tag 'pm-4.7-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm: (112 commits)
    intel_pstate: Clean up get_target_pstate_use_performance()
    intel_pstate: Use sample.core_avg_perf in get_avg_pstate()
    intel_pstate: Clarify average performance computation
    intel_pstate: Avoid unnecessary synchronize_sched() during initialization
    cpufreq: schedutil: Make default depend on CONFIG_SMP
    cpufreq: powernv: del_timer_sync when global and local pstate are equal
    cpufreq: powernv: Move smp_call_function_any() out of irq safe block
    intel_pstate: Clean up intel_pstate_get()
    cpufreq: schedutil: Make it depend on CONFIG_SMP
    cpufreq: governor: Fix handling of special cases in dbs_update()
    PM / OPP: Move CONFIG_OF dependent code in a separate file
    cpufreq: intel_pstate: Ignore _PPC processing under HWP
    cpufreq: arm_big_little: use generic OPP functions for {init, free}_opp_table
    PM / OPP: add non-OF versions of dev_pm_opp_{cpumask_, }remove_table
    cpufreq: tango: Use generic platdev driver
    PM / OPP: pass cpumask by reference
    cpufreq: Fix GOV_LIMITS handling for the userspace governor
    cpupower: fix potential memory leak
    PM / devfreq: style/typo fixes
    PM / devfreq: exynos: Add the detailed correlation for Exynos5422 bus
    ..

    Linus Torvalds
     

13 Apr, 2016

1 commit

  • 93984fbd4   x86/cpufeature: Replace cpu_has_apic with boot_cpu_has() usage ... Browse Code »

    Signed-off-by: Borislav Petkov
    Cc: Andy Lutomirski
    Cc: Borislav Petkov
    Cc: Brian Gerst
    Cc: Denys Vlasenko
    Cc: H. Peter Anvin
    Cc: Linus Torvalds
    Cc: Peter Zijlstra
    Cc: Thomas Gleixner
    Cc: iommu@lists.linux-foundation.org
    Cc: linux-pm@vger.kernel.org
    Cc: oprofile-list@lists.sf.net
    Link: http://lkml.kernel.org/r/1459801503-15600-8-git-send-email-bp@alien8.de
    Signed-off-by: Ingo Molnar

    Borislav Petkov
     

09 Apr, 2016

2 commits

20 Dec, 2014

1 commit

  • d5e80b4b1   Update/Remove soon-to-be-dead email address ... Browse Code »

    I'm leaving Red Hat at the end of December 2014, so remove all
    references to my soon-to-be-dead address.

    (There are some references left in the tree, that need additional
    changes, I'll send those through the AGP maintainers).

    Signed-off-by: Dave Jones
    Signed-off-by: Linus Torvalds

    Dave Jones
     

01 May, 2014

1 commit

30 Apr, 2014

1 commit

29 Apr, 2014

1 commit

  • 7aa0557fa   cpufreq: longhaul: Fix double invocation of cpufreq_freq_transition_begin/end ... Browse Code »

    During frequency transitions, the cpufreq core takes the responsibility of
    invoking cpufreq_freq_transition_begin() and cpufreq_freq_transition_end()
    for those cpufreq drivers that define the ->target_index callback but don't
    set the ASYNC_NOTIFICATION flag.

    The longhaul cpufreq driver falls under this category, but this driver was
    invoking the _begin() and _end() APIs itself around frequency transitions,
    which led to double invocation of the _begin() API. The _begin API makes
    contending callers wait until the previous invocation is complete. Hence,
    the longhaul driver ended up waiting on itself, leading to system hangs
    during boot.

    Fix this by removing the calls to the _begin() and _end() APIs from the
    longhaul driver, since they rightly belong to the cpufreq core.

    (Note that during module_exit(), the longhaul driver sets the frequency
    without any help from the cpufreq core. So add explicit calls to the
    _begin() and _end() APIs around that frequency transition alone, to take
    care of that special case.)

    Fixes: 12478cf0c55e (cpufreq: Make sure frequency transitions are serialized)
    Reported-and-tested-by: Meelis Roos
    Signed-off-by: Srivatsa S. Bhat
    Signed-off-by: Rafael J. Wysocki

    Srivatsa S. Bhat
     

07 Apr, 2014

1 commit

  • 71508a1f4   cpufreq: use kzalloc() to allocate memory for cpufreq_frequency_table ... Browse Code »

    Few drivers are using kmalloc() to allocate memory for frequency
    tables and since we will have an additional field '.flags' in
    'struct cpufreq_frequency_table', these might become unstable.
    Better get these fixed by replacing kmalloc() by kzalloc() instead.

    Along with that we also remove use of .driver_data from SPEAr driver
    as it doesn't use it at all. Also, writing zero to .driver_data is not
    required for powernow-k8 as it is already zero.

    Reported-and-reviewed-by: Gautham R. Shenoy
    Signed-off-by: Viresh Kumar
    Signed-off-by: Rafael J. Wysocki

    Viresh Kumar
     

26 Mar, 2014

1 commit

12 Mar, 2014

1 commit

26 Oct, 2013

1 commit

  • 9c0ebcf78   cpufreq: Implement light weight ->target_index() routine ... Browse Code »

    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

2 commits

01 Oct, 2013

1 commit

10 Aug, 2013

1 commit

15 Jul, 2013

1 commit

  • 2760984f6   cpufreq: delete __cpuinit usage from all cpufreq files ... Browse Code »

    The __cpuinit type of throwaway sections might have made sense
    some time ago when RAM was more constrained, but now the savings
    do not offset the cost and complications. For example, the fix in
    commit 5e427ec2d0 ("x86: Fix bit corruption at CPU resume time")
    is a good example of the nasty type of bugs that can be created
    with improper use of the various __init prefixes.

    After a discussion on LKML[1] it was decided that cpuinit should go
    the way of devinit and be phased out. Once all the users are gone,
    we can then finally remove the macros themselves from linux/init.h.

    This removes all the drivers/cpufreq uses of the __cpuinit macros
    from all C files.

    [1] https://lkml.org/lkml/2013/5/20/589

    [v2: leave 2nd lines of args misaligned as requested by Viresh]
    Cc: "Rafael J. Wysocki"
    Cc: Viresh Kumar
    Cc: cpufreq@vger.kernel.org
    Cc: linux-pm@vger.kernel.org
    Acked-by: Dirk Brandewie
    Acked-by: Viresh Kumar
    Signed-off-by: Paul Gortmaker

    Paul Gortmaker
     

04 Jun, 2013

1 commit

  • 507015880   cpufreq: rename index as driver_data in cpufreq_frequency_table ... Browse Code »

    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

  • b43a7ffbf   cpufreq: Notify all policy->cpus in cpufreq_notify_transition() ... Browse Code »

    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
     

03 Jan, 2013

1 commit

  • b5811bc46   cpufreq / Longhaul: Disable driver by default ... Browse Code »

    This is only solution I can think of. User decides if he wants this
    driver on his machine. I don't have enough knowledge and time to find
    the reason why same code works on some machines and doesn't on others
    which use the same, or very similar, chipset and processor.

    Signed-off-by: Rafał Bilski
    Signed-off-by: Rafael J. Wysocki

    Rafał Bilski
     

21 Nov, 2012

2 commits

27 Jan, 2012

1 commit

  • fa8031aef   cpufreq: Add support for x86 cpuinfo auto loading v4 ... Browse Code »
    86

    This marks all the x86 cpuinfo tables to the CPU specific device drivers,
    to allow auto loading by udev. This should simplify the distribution
    startup scripts for this greatly.

    I didn't add MODULE_DEVICE_IDs to the centrino and p4-clockmod drivers,
    because those probably shouldn't be auto loaded and the acpi driver
    be used instead (not fully sure on that, would appreciate feedback)

    The old nforce drivers autoload based on the PCI ID.

    ACPI cpufreq is autoloaded in another patch.

    v3: Autoload gx based on PCI IDs only. Remove cpu check (Dave Jones)
    v4: Use newly introduce HW_PSTATE feature for powernow-k8 loading

    Cc: Dave Jones
    Cc: Kay Sievers
    Signed-off-by: Andi Kleen
    Signed-off-by: Thomas Renninger
    Acked-by: H. Peter Anvin
    Signed-off-by: Greg Kroah-Hartman

    Andi Kleen
     

20 May, 2011

1 commit