Eric Lee / smarc-fsl-linux-kernel

26 Jul, 2017

1 commit

  • fe829ed8e   cpufreq: Add CPUFREQ_NO_AUTO_DYNAMIC_SWITCHING cpufreq driver flag ... Browse Code »

    The policy->transition_latency field is used for multiple purposes
    today and its not straight forward at all. This is how it is used:

    A. Set the correct transition_latency value.

    B. Set it to CPUFREQ_ETERNAL because:
    1. We don't want automatic dynamic switching (with
    ondemand/conservative) to happen at all.
    2. We don't know the transition latency.

    This patch handles the B.1. case in a more readable way. A new flag for
    the cpufreq drivers is added to disallow use of cpufreq governors which
    have dynamic_switching flag set.

    All the current cpufreq drivers which are setting transition_latency
    unconditionally to CPUFREQ_ETERNAL are updated to use it. They don't
    need to set transition_latency anymore.

    There shouldn't be any functional change after this patch.

    Signed-off-by: Viresh Kumar
    Reviewed-by: Dominik Brodowski
    Signed-off-by: Rafael J. Wysocki

    Viresh Kumar
     

22 Apr, 2014

1 commit

07 Apr, 2014

1 commit

  • b4ddad950   cpufreq: unicore32: fix typo issue for 'clk' ... Browse Code »

    Need use 'clk' instead of 'mclk', which is the original removed local
    variable.

    The related original commit:

    "652ed95 cpufreq: introduce cpufreq_generic_get() routine"

    The related error with allmodconfig for unicore32:

    CC drivers/cpufreq/unicore2-cpufreq.o
    drivers/cpufreq/unicore2-cpufreq.c: In function ‘ucv2_target’:
    drivers/cpufreq/unicore2-cpufreq.c:48: error: ‘struct cpufreq_policy’ has no member named ‘mclk’
    make[2]: *** [drivers/cpufreq/unicore2-cpufreq.o] Error 1
    make[1]: *** [drivers/cpufreq] Error 2
    make: *** [drivers] Error 2

    Fixes: 652ed95d5fa6 (cpufreq: introduce cpufreq_generic_get() routine)
    Signed-off-by: Chen Gang
    Acked-by: Viresh Kumar
    Cc: 3.14+ # 3.14+
    Signed-off-by: Rafael J. Wysocki

    Chen Gang
     

26 Mar, 2014

1 commit

17 Jan, 2014

1 commit

  • 652ed95d5   cpufreq: introduce cpufreq_generic_get() routine ... Browse Code »

    CPUFreq drivers that use clock frameworks interface,i.e. clk_get_rate(),
    to get CPUs clk rate, have similar sort of code used in most of them.

    This patch adds a generic ->get() which will do the same thing for them.
    All those drivers are required to now is to set .get to cpufreq_generic_get()
    and set their clk pointer in policy->clk during ->init().

    Acked-by: Hans-Christian Egtvedt
    Acked-by: Shawn Guo
    Acked-by: Linus Walleij
    Acked-by: Shawn Guo
    Acked-by: Stephen Warren
    Signed-off-by: Viresh Kumar
    Signed-off-by: Rafael J. Wysocki

    Viresh Kumar
     

06 Jan, 2014

1 commit

  • ab1b1c4e8   cpufreq: send new set of notification for transition failures ... Browse Code »

    In the current code, if we fail during a frequency transition, we
    simply send the POSTCHANGE notification with the old frequency. This
    isn't enough.

    One of the core users of these notifications is the code responsible
    for keeping loops_per_jiffy aligned with frequency changes. And mostly
    it is written as:

    if ((val == CPUFREQ_PRECHANGE && freq->old < freq->new) ||
    (val == CPUFREQ_POSTCHANGE && freq->old > freq->new)) {
    update-loops-per-jiffy...
    }

    So, suppose we are changing to a higher frequency and failed during
    transition, then following will happen:
    - CPUFREQ_PRECHANGE notification with freq-new > freq-old
    - CPUFREQ_POSTCHANGE notification with freq-new == freq-old

    The first one will update loops_per_jiffy and second one will do
    nothing. Even if we send the 2nd notification by exchanging values of
    freq-new and old, some users of these notifications might get
    unstable.

    This can be fixed by simply calling cpufreq_notify_post_transition()
    with error code and this routine will take care of sending
    notifications in the correct order.

    Signed-off-by: Viresh Kumar
    [rjw: Folded 3 patches into one, rebased unicore2 changes]
    Signed-off-by: Rafael J. Wysocki

    Viresh Kumar
     

16 Oct, 2013

2 commits

  • 9909aa1e3   cpufreq: unicore2: 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().

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

    Viresh Kumar
     
  • be49e3465   cpufreq: add new routine cpufreq_verify_within_cpu_limits() ... Browse Code »

    Most of the users of cpufreq_verify_within_limits() calls it for
    limiting with min/max from policy->cpuinfo. We can make that code
    simple by introducing another routine which will do this for them
    automatically.

    This patch adds another routine cpufreq_verify_within_cpu_limits()
    and updates others to use it.

    Signed-off-by: Viresh Kumar
    Acked-by: Dirk Brandewie
    Signed-off-by: Rafael J. Wysocki

    Viresh Kumar
     

15 Aug, 2013

1 commit

  • 0e25246fb   cpufreq: unicore2: Staticize local symbol ... Browse Code »

    This local symbol is used only in this file.
    Fix the following sparse warnings:

    drivers/cpufreq/unicore2-cpufreq.c:27:5: warning: symbol 'ucv2_verify_speed' was not declared. Should it be static?

    Signed-off-by: Jingoo Han
    Acked-by: Viresh Kumar
    Signed-off-by: Rafael J. Wysocki

    Jingoo Han
     

10 Apr, 2013

1 commit