Eric Lee / smarc-ti-linux-kernel

01 Oct, 2014

1 commit

07 Jun, 2014

1 commit

  • 906fe0331   cpufreq: ppc-corenet-cpu-freq: do_div use quotient ... Browse Code »

    Commit 6712d2931933 (cpufreq: ppc-corenet-cpufreq: Fix __udivdi3 modpost
    error) used the remainder from do_div instead of the quotient. Fix that
    and add one to ensure minimum is met.

    Fixes: 6712d2931933 (cpufreq: ppc-corenet-cpufreq: Fix __udivdi3 modpost error)
    Signed-off-by: Ed Swarthout
    Cc: 3.15+ # 3.15+
    Signed-off-by: Rafael J. Wysocki

    Ed Swarthout
     

29 Apr, 2014

1 commit

  • 6712d2931   cpufreq: ppc-corenet-cpufreq: Fix __udivdi3 modpost error ... Browse Code »
    26

    bfa709bc823fc32ee8dd5220d1711b46078235d8 (cpufreq: powerpc: add cpufreq
    transition latency for FSL e500mc SoCs) introduced a modpost error:

    ERROR: "__udivdi3" [drivers/cpufreq/ppc-corenet-cpufreq.ko] undefined!
    make[1]: *** [__modpost] Error 1

    Fix this by avoiding 64 bit integer division.

    gcc version 4.8.2

    Fixes: bfa709bc823f (cpufreq: powerpc: add cpufreq transition latency for FSL e500mc SoCs)
    Signed-off-by: Tim Gardner
    Signed-off-by: Rafael J. Wysocki

    Tim Gardner
     

22 Apr, 2014

1 commit

  • 1612343a2   cpufreq: ppc: Fix integer overflow in expression ... Browse Code »
    13

    On 32-bit, "12 * NSEC_PER_SEC" doesn't fit in "unsigned long"
    (NSEC_PER_SEC is a "long" constant), causing an integer overflow:

    drivers/cpufreq/ppc-corenet-cpufreq.c: In function 'corenet_cpufreq_cpu_init':
    drivers/cpufreq/ppc-corenet-cpufreq.c:211:9: warning: integer overflow in expression [-Woverflow]

    Force the intermediate to be 64-bit by adding an "ULL" suffix to the
    constant multiplier to fix this.

    Signed-off-by: Geert Uytterhoeven
    Acked-by: Viresh Kumar
    Signed-off-by: Rafael J. Wysocki

    Geert Uytterhoeven
     

08 Apr, 2014

1 commit

20 Mar, 2014

1 commit

  • bfa709bc8   cpufreq: powerpc: add cpufreq transition latency for FSL e500mc SoCs ... Browse Code »
    28

    According to the data provided by HW Team, at least 12 internal platform
    clock cycles are required to stabilize a DFS clock switch on FSL e500mc Socs.
    This patch replaces the CPUFREQ_ETERNAL with appropriate HW clock transition
    latency to make DFS governors work normally on Freescale e500mc boards.

    Signed-off-by: Zhuoyu Zhang
    Acked-by: Viresh Kumar
    Signed-off-by: Rafael J. Wysocki

    Zhuoyu Zhang
     

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
     

17 Jan, 2014

1 commit

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

    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
     

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

2 commits

  • 0bcc9d9a3   cpufreq: ppc: 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
     
  • dc2398d7f   cpufreq: ppc-corenet: 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 ppc-corenet driver.

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

    Viresh Kumar
     

01 Oct, 2013

1 commit

10 Aug, 2013

1 commit

05 Jun, 2013

1 commit