Eric Lee / smarc-fsl-linux-kernel

20 Mar, 2018

1 commit

  • 31f4b7a86   cpufreq: sparc: Don't validate the frequency table twice ... Browse Code »

    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 sparc driver.

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

    Viresh Kumar
     

15 Apr, 2017

1 commit

  • 9fe24c4e9   cpufreq/sparc-us3: Replace racy task affinity logic ... Browse Code »

    The access to the safari config register in the CPU frequency functions
    must be executed on the target CPU. This is achieved by temporarily setting
    the affinity of the calling user space thread to the requested CPU and
    reset it to the original affinity afterwards.

    That's racy vs. CPU hotplug and concurrent affinity settings for that
    thread resulting in code executing on the wrong CPU and overwriting the
    new affinity setting.

    Replace it by a straight forward smp function call.

    Signed-off-by: Thomas Gleixner
    Acked-by: Viresh Kumar
    Cc: Fenghua Yu
    Cc: Tony Luck
    Cc: Herbert Xu
    Cc: "Rafael J. Wysocki"
    Cc: Peter Zijlstra
    Cc: Benjamin Herrenschmidt
    Cc: Sebastian Siewior
    Cc: linux-pm@vger.kernel.org
    Cc: Lai Jiangshan
    Cc: Michael Ellerman
    Cc: Tejun Heo
    Cc: "David S. Miller"
    Cc: Len Brown
    Link: http://lkml.kernel.org/r/20170412201043.047558840@linutronix.de
    Signed-off-by: Thomas Gleixner

    Thomas Gleixner
     

02 Mar, 2017

1 commit

  • 0c98d344f   sched/core: Remove the tsk_cpus_allowed() wrapper ... Browse Code »

    So the original intention of tsk_cpus_allowed() was to 'future-proof'
    the field - but it's pretty ineffectual at that, because half of
    the code uses ->cpus_allowed directly ...

    Also, the wrapper makes the code longer than the original expression!

    So just get rid of it. This also shrinks a bit.

    Acked-by: Linus Torvalds
    Cc: Mike Galbraith
    Cc: Peter Zijlstra
    Cc: Thomas Gleixner
    Cc: linux-kernel@vger.kernel.org
    Signed-off-by: Ingo Molnar

    Ingo Molnar
     

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
     

16 Oct, 2013

1 commit

  • 7a1874a06   cpufreq: sparc: 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 sparc driver.

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

    Viresh Kumar
     

01 Oct, 2013

2 commits

10 Aug, 2013

1 commit

08 Aug, 2013

1 commit

  • d5b73cd87   cpufreq: Use sizeof(*ptr) convetion for computing sizes ... Browse Code »

    Chapter 14 of Documentation/CodingStyle says:

    The preferred form for passing a size of a struct is the following:

    p = kmalloc(sizeof(*p), ...);

    The alternative form where struct name is spelled out hurts
    readability and introduces an opportunity for a bug when the pointer
    variable type is changed but the corresponding sizeof that is passed
    to a memory allocator is not.

    This wasn't followed consistently in drivers/cpufreq, let's make it
    more consistent by always following this rule.

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

    Viresh Kumar
     

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
     

10 Apr, 2013

1 commit