Eric Lee / smarc-fsl-linux-kernel

25 Nov, 2009

1 commit

  • e2f74f355   [ACPI/CPUFREQ] Introduce bios_limit per cpu cpufreq sysfs interface ... Browse Code »

    This interface is mainly intended (and implemented) for ACPI _PPC BIOS
    frequency limitations, but other cpufreq drivers can also use it for
    similar use-cases.

    Why is this needed:

    Currently it's not obvious why cpufreq got limited.
    People see cpufreq/scaling_max_freq reduced, but this could have
    happened by:
    - any userspace prog writing to scaling_max_freq
    - thermal limitations
    - hardware (_PPC in ACPI case) limitiations

    Therefore export bios_limit (in kHz) to:
    - Point the user that it's the BIOS (broken or intended) which limits
    frequency
    - Export it as a sysfs interface for userspace progs.
    While this was a rarely used feature on laptops, there will appear
    more and more server implemenations providing "Green IT" features like
    allowing the service processor to limit the frequency. People want
    to know about HW/BIOS frequency limitations.

    All ACPI P-state driven cpufreq drivers are covered with this patch:
    - powernow-k8
    - powernow-k7
    - acpi-cpufreq

    Tested with a patched DSDT which limits the first two cores (_PPC returns 1)
    via _PPC, exposed by bios_limit:
    # echo 2200000 >cpu2/cpufreq/scaling_max_freq
    # cat cpu*/cpufreq/scaling_max_freq
    2600000
    2600000
    2200000
    2200000
    # #scaling_max_freq shows general user/thermal/BIOS limitations

    # cat cpu*/cpufreq/bios_limit
    2600000
    2600000
    2800000
    2800000
    # #bios_limit only shows the HW/BIOS limitation

    CC: Pallipadi Venkatesh
    CC: Len Brown
    CC: davej@codemonkey.org.uk
    CC: linux@dominikbrodowski.net

    Signed-off-by: Thomas Renninger
    Signed-off-by: Dave Jones

    Thomas Renninger
     

02 Sep, 2009

1 commit

  • da470db16   [CPUFREQ] update Doc for cpuinfo_cur_freq and scaling_cur_freq ... Browse Code »

    I think the way "cpuinfo_cur_info" and "scaling_cur_info" are defined under
    ./Documentation/cpu-freq/user-guide.txt can be enhanced. Currently, they are
    both defined the same way: "Current speed/frequency" of the CPU, in KHz".

    Below is a patch that distinguishes one from the other.

    Regards,
    - naga -

    -----------------------------------------
    Update description for "cpuinfo_cur_freq" and "scaling_cur_freq".

    Some of the wording is drawn from comments found in
    ./drivers/cpufreq/cpufreq.c: cpufreq_out_of_sync():

    * @old_freq: CPU frequency the kernel thinks the CPU runs at
    * @new_freq: CPU frequency the CPU actually runs at

    Signed-off-by: Naga Chumbalkar
    Signed-off-by: Dave Jones

    Naga Chumbalkar
     

15 Jun, 2009

1 commit

25 Feb, 2009

1 commit

  • ed1297845   [CPUFREQ] Introduce /sys/devices/system/cpu/cpu*/cpufreq/cpuinfo_transition_latency ... Browse Code »

    It's not only useful for the ondemand and conservative governors, but
    also for userspace daemons to know about the HW transition latency of
    the CPU.
    It is especially useful for userspace to know about this value when
    the ondemand or conservative governors are run. The sampling rate
    control value depends on it and for userspace being able to set sane
    tuning values there it has to know about the transition latency.

    Signed-off-by: Thomas Renninger
    Signed-off-by: Dave Jones

    Thomas Renninger
     

04 Feb, 2009

1 commit

22 Dec, 2008

1 commit

26 Nov, 2008

1 commit

29 Apr, 2008

1 commit

26 Jan, 2008

1 commit

01 Aug, 2006

1 commit

  • 9c9a43ed2   [CPUFREQ] return error when failing to set minfreq ... Browse Code »

    I just stumbled on this bug/feature, this is how to reproduce it:

    # echo 450000 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_min_freq
    # echo 450000 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq
    # echo powersave > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
    # cpufreq-info -p
    450000 450000 powersave
    # echo 1800000 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_min_freq ; echo $?
    0
    # cpufreq-info -p
    450000 450000 powersave

    Here it is. The kernel refuses to set a min_freq higher than the
    max_freq but it allows a max_freq lower than min_freq (lowering min_freq
    also).

    This behaviour is pretty straightforward (but undocumented) and it
    doesn't return an error altough failing to accomplish the requested
    action (set min_freq).
    The problem (IMO) is basically that userspace is not allowed to set a
    full policy atomically while the kernel always does that thus it must
    enforce an ordering on operations.

    The attached patch returns -EINVAL if trying to increase frequencies
    starting from scaling_min_freq and documents the correct ordering of writes.

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

    --

    Mattia Dongili
     

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