Eric Lee / smarc-fsl-linux-kernel

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
     

09 Apr, 2016

2 commits

01 May, 2014

1 commit

  • dec102aa9   cpufreq: Make linux-pm@vger.kernel.org official mailing list ... Browse Code »

    There has been confusion all the time about which mailing list to follow
    for cpufreq activities, linux-pm@vger.kernel.org or cpufreq@vger.kernel.org.

    Since patches sent to cpufreq@vger.kernel.org don't go to Patchwork
    which is a maintenance workflow problem, make linux-pm@vger.kernel.org
    the official mailing list for cpufreq stuff and remove all references
    of cpufreq@vger.kernel.org from kernel source.

    Later, we can request that the list be dropped entirely.

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

    Viresh Kumar
     

12 Mar, 2014

1 commit

  • e0b3165ba   cpufreq: add 'freq_table' in struct cpufreq_policy ... Browse Code »

    freq table is not per CPU but per policy, so it makes more sense to
    keep it within struct cpufreq_policy instead of a per-cpu variable.

    This patch does it. Over that, there is no need to set policy->freq_table
    to NULL in ->exit(), as policy structure is going to be freed soon.

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

    Viresh Kumar
     

31 Oct, 2013

1 commit

  • d4019f0a9   cpufreq: move freq change notifications to cpufreq core ... Browse Code »

    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

  • 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
     

17 Oct, 2013

1 commit

16 Oct, 2013

2 commits

  • 4b1576832   cpufreq: speedstep: don't initialize part of policy set by core ... Browse Code »

    Many common initializations of struct policy are moved to core now and hence
    this driver doesn't need to do it. This patch removes such code.

    Most recent of those changes is to call ->get() in the core after calling
    ->init().

    Cc: David S. Miller
    Signed-off-by: Viresh Kumar
    Signed-off-by: Rafael J. Wysocki

    Viresh Kumar
     
  • 3be1394a6   cpufreq: speedstep: Use generic cpufreq routines ... Browse Code »

    Most of the CPUFreq drivers do similar things in .exit() and .verify() routines
    and .attr. So its better if we have generic routines for them which can be used
    by cpufreq drivers then.

    This patch uses these generic routines in the speedstep driver.

    Cc: David S. Miller
    Signed-off-by: Viresh Kumar
    Signed-off-by: Rafael J. Wysocki

    Viresh Kumar
     

01 Oct, 2013

1 commit

10 Aug, 2013

1 commit

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

2 commits

  • e9f51837c   cpufreq: Don't check if cpu is online/offline for cpufreq callbacks ... Browse Code »

    cpufreq layer doesn't call cpufreq driver's callback for any offline
    CPU and so checking that isn't useful.

    Lets get rid of it.

    Signed-off-by: Viresh Kumar
    Acked-by: David S. Miller
    Signed-off-by: Rafael J. Wysocki

    Viresh Kumar
     
  • 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
     

27 Jan, 2012

1 commit

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

    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