Doug / smarc-fsl-linux-kernel

08 Aug, 2013

1 commit

  • 5ff0a2680   cpufreq: Clean up header files included in the core ... Browse Code »

    This patch addresses the following issues in the header files in the
    cpufreq core:
    - Include headers in ascending order, so that we don't add same
    many times by mistake.
    - must be included after , so that they override
    whatever they need to.
    - Remove unnecessary includes.
    - Don't include files already included by cpufreq.h or
    cpufreq_governor.h.

    [rjw: Changelog]
    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
     

09 Feb, 2013

1 commit

02 Feb, 2013

1 commit

  • b8eed8af9   cpufreq: Simplify __cpufreq_remove_dev() ... Browse Code »

    __cpufreq_remove_dev() is called on multiple occasions: cpufreq_driver
    unregister and cpu removals.

    Current implementation of this routine is overly complex without much need. If
    the cpu to be removed is the policy->cpu, we remove the policy first and add all
    other cpus again from policy->cpus and then finally call __cpufreq_remove_dev()
    again to remove the cpu to be deleted. Haahhhh..

    There exist a simple solution to removal of a cpu:
    - Simply use the old policy structure
    - update its fields like: policy->cpu, etc.
    - notify any users of cpufreq, which depend on changing policy->cpu

    Hence this patch, which tries to implement the above theory. It is tested well
    by myself on ARM big.LITTLE TC2 SoC, which has 5 cores (2 A15 and 3 A7). Both
    A15's share same struct policy and all A7's share same policy structure.

    Signed-off-by: Viresh Kumar
    Tested-by: Shawn Guo
    Signed-off-by: Rafael J. Wysocki

    Viresh Kumar
     

15 Nov, 2012

1 commit

04 May, 2011

1 commit

  • 2d06d8c49   [CPUFREQ] use dynamic debug instead of custom infrastructure ... Browse Code »

    With dynamic debug having gained the capability to report debug messages
    also during the boot process, it offers a far superior interface for
    debug messages than the custom cpufreq infrastructure. As a first step,
    remove the old cpufreq_debug_printk() function and replace it with a call
    to the generic pr_debug() function.

    How can dynamic debug be used on cpufreq? You need a kernel which has
    CONFIG_DYNAMIC_DEBUG enabled.

    To enabled debugging during runtime, mount debugfs and

    $ echo -n 'module cpufreq +p' > /sys/kernel/debug/dynamic_debug/control

    for debugging the complete "cpufreq" module. To achieve the same goal during
    boot, append

    ddebug_query="module cpufreq +p"

    as a boot parameter to the kernel of your choice.

    For more detailled instructions, please see
    Documentation/dynamic-debug-howto.txt

    Signed-off-by: Dominik Brodowski
    Signed-off-by: Dave Jones

    Dominik Brodowski
     

29 Oct, 2009

1 commit

  • f16250669   percpu: make percpu symbols in cpufreq unique ... Browse Code »

    This patch updates percpu related symbols in cpufreq such that percpu
    symbols are unique and don't clash with local symbols. This serves
    two purposes of decreasing the possibility of global percpu symbol
    collision and allowing dropping per_cpu__ prefix from percpu symbols.

    * drivers/cpufreq/cpufreq.c: s/policy_cpu/cpufreq_policy_cpu/
    * drivers/cpufreq/freq_table.c: s/show_table/cpufreq_show_table/
    * arch/x86/kernel/cpu/cpufreq/acpi-cpufreq.c: s/drv_data/acfreq_data/
    s/old_perf/acfreq_old_perf/

    Partly based on Rusty Russell's "alloc_percpu: rename percpu vars
    which cause name clashes" patch.

    Signed-off-by: Tejun Heo
    Cc: Rusty Russell

    Tejun Heo
     

25 Feb, 2009

1 commit

22 Jul, 2008

1 commit

23 May, 2008

1 commit

20 May, 2008

1 commit

  • 7a6aedfac   [CPUFREQ] change cpu freq arrays to per_cpu variables ... Browse Code »

    Change cpufreq_policy and cpufreq_governor pointer tables
    from arrays to per_cpu variables in the cpufreq subsystem.

    Also some minor complaints from checkpatch.pl fixed.

    Based on:
    git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
    git://git.kernel.org/pub/scm/linux/kernel/git/x86/linux-2.6-x86.git

    Signed-off-by: Mike Travis
    Signed-off-by: Dave Jones

    Mike Travis
     

07 Feb, 2008

1 commit

12 Jul, 2007

1 commit

  • 7b595756e   sysfs: kill unnecessary attribute->owner ... Browse Code »

    sysfs is now completely out of driver/module lifetime game. After
    deletion, a sysfs node doesn't access anything outside sysfs proper,
    so there's no reason to hold onto the attribute owners. Note that
    often the wrong modules were accounted for as owners leading to
    accessing removed modules.

    This patch kills now unnecessary attribute->owner. Note that with
    this change, userland holding a sysfs node does not prevent the
    backing module from being unloaded.

    For more info regarding lifetime rule cleanup, please read the
    following message.

    http://article.gmane.org/gmane.linux.kernel/510293

    (tweaked by Greg to not delete the field just yet, to make it easier to
    merge things properly.)

    Signed-off-by: Tejun Heo
    Cc: Cornelia Huck
    Cc: Andrew Morton
    Signed-off-by: Greg Kroah-Hartman

    Tejun Heo
     

07 Nov, 2006

1 commit

31 May, 2006

3 commits

28 Feb, 2006

1 commit

17 Apr, 2005

1 commit

  • 1da177e4c   Linux-2.6.12-rc2 ... Browse Code »

    Initial git repository build. I'm not bothering with the full history,
    even though we have it. We can create a separate "historical" git
    archive of that later if we want to, and in the meantime it's about
    3.2GB when imported into git - space that would just make the early
    git days unnecessarily complicated, when we don't have a lot of good
    infrastructure for it.

    Let it rip!

    Linus Torvalds