03 Jun, 2013

1 commit


02 Apr, 2013

1 commit


26 Nov, 2012

1 commit


20 Nov, 2012

4 commits

  • Allow devfreq drivers to register a preferred governor name
    and when the devfreq governor loads itself at a later point
    required drivers are managed appropriately, at the time of
    unload of a devfreq governor, stop managing those drivers
    as well.

    Since the governor structures do not need to be exposed
    anymore, remove the definitions and make them static

    NOTE: devfreq_list_lock is now used to protect governor
    start and stop - as this allows us to protect governors and
    devfreq with the proper dependencies as needed.

    As part of this change, change the registration of exynos
    bus driver to request for ondemand using the governor name.

    Cc: Rajagopal Venkat
    Cc: MyungJoo Ham
    Cc: Kyungmin Park
    Cc: "Rafael J. Wysocki"
    Cc: Kevin Hilman
    Cc: linux-pm@vger.kernel.org
    Cc: linux-kernel@vger.kernel.org

    Signed-off-by: Nishanth Menon
    [Merge conflict resolved by MyungJoo Ham]
    Signed-off-by: MyungJoo Ham

    Nishanth Menon
     
  • Add devfreq_add_governor and devfreq_remove_governor which
    can be invoked by governors to register with devfreq.

    This sets up the stage to dynamically switch governors and
    allow governors to be dynamically loaded as well.

    Cc: Rajagopal Venkat
    Cc: MyungJoo Ham
    Cc: Kyungmin Park
    Cc: "Rafael J. Wysocki"
    Cc: Kevin Hilman
    Cc: linux-pm@vger.kernel.org
    Cc: linux-kernel@vger.kernel.org

    Signed-off-by: Nishanth Menon
    Acked-by: MyungJoo Ham

    Nishanth Menon
     
  • This patch adds sysfs node which can be used to get information of frequency
    transition. It represents transition table which contains total number of transition of
    each freqeuncy state and time spent. It is inspired CPUFREQ's status driver.

    Signed-off-by: Jonghwa Lee
    [Added Documentation/ABI entry, updated kernel-doc, and resolved merge conflict]
    Signed-off-by: MyungJoo Ham

    Jonghwa Lee
     
  • struct parameters need to have ':' in documentation for
    scripts/kernel-doc to parse appropriately.

    Fix the errors reported by:
    ./scripts/kernel-doc include/linux/devfreq.h >/dev/null

    Cc: Rajagopal Venkat
    Cc: MyungJoo Ham
    Cc: Kyungmin Park
    Cc: "Rafael J. Wysocki"
    Cc: Kevin Hilman
    Cc: linux-pm@vger.kernel.org
    Cc: linux-kernel@vger.kernel.org

    Signed-off-by: Nishanth Menon
    Acked-by: Randy Dunlap
    Acked-by: MyungJoo Ham
    Signed-off-by: MyungJoo Ham

    Nishanth Menon
     

15 Nov, 2012

3 commits

  • Devfreq returns governor predicted frequency as current frequency
    via sysfs interface. But device may not support all frequencies
    that governor predicts. So add a callback in device profile to get
    current freq from driver. Also add a new sysfs node to expose
    governor predicted next target frequency.

    Signed-off-by: Rajagopal Venkat
    Acked-by: MyungJoo Ham
    Signed-off-by: Rafael J. Wysocki

    Rajagopal Venkat
     
  • Add devfreq suspend/resume apis for devfreq users. This patch
    supports suspend and resume of devfreq load monitoring, required
    for devices which can idle.

    Signed-off-by: Rajagopal Venkat
    Acked-by: MyungJoo Ham
    Signed-off-by: Rafael J. Wysocki

    Rajagopal Venkat
     
  • Prepare devfreq core framework to support devices which
    can idle. When device idleness is detected perhaps through
    runtime-pm, need some mechanism to suspend devfreq load
    monitoring and resume back when device is online. Present
    code continues monitoring unless device is removed from
    devfreq core.

    This patch introduces following design changes,

    - use per device work instead of global work to monitor device
    load. This enables suspend/resume of device devfreq and
    reduces monitoring code complexity.
    - decouple delayed work based load monitoring logic from core
    by introducing helpers functions to be used by governors. This
    provides flexibility for governors either to use delayed work
    based monitoring functions or to implement their own mechanism.
    - devfreq core interacts with governors via events to perform
    specific actions. These events include start/stop devfreq.
    This sets ground for adding suspend/resume events.

    The devfreq apis are not modified and are kept intact.

    Signed-off-by: Rajagopal Venkat
    Acked-by: MyungJoo Ham
    Signed-off-by: Rafael J. Wysocki

    Rajagopal Venkat
     

18 Mar, 2012

1 commit

  • The semantics of "target frequency" given to devfreq driver from
    devfreq framework has always been interpretted as "at least" or GLB
    (greatest lower bound). However, the framework might want the
    device driver to limit its max frequency (LUB: least upper bound),
    especially if it is given by thermal framework (it's too hot).

    Thus, the target fuction should have another parameter to express
    whether the framework wants GLB or LUB. And, the additional parameter,
    "u32 flags", does it.

    With the update, devfreq_recommended_opp() is also updated.

    Signed-off-by: MyungJoo Ham
    Signed-off-by: Kyungmin Park
    Reviewed-by: Mike Turquette
    Signed-off-by: Rafael J. Wysocki

    MyungJoo Ham
     

20 Jan, 2012

2 commits


08 Nov, 2011

1 commit

  • The "private_date" field in struct devfreq_dev_status almost certainly
    wants to be "private_data"; since there are no in-tree users of this
    functionality, now seems like an easy time to make the fix.

    Signed-off-by: Jonathan Corbet
    Signed-off-by: Rafael J. Wysocki

    Jonathan Corbet
     

02 Oct, 2011

2 commits

  • Four cpufreq-like governors are provided as examples.

    powersave: use the lowest frequency possible. The user (device) should
    set the polling_ms as 0 because polling is useless for this governor.

    performance: use the highest freqeuncy possible. The user (device)
    should set the polling_ms as 0 because polling is useless for this
    governor.

    userspace: use the user specified frequency stored at
    devfreq.user_set_freq. With sysfs support in the following patch, a user
    may set the value with the sysfs interface.

    simple_ondemand: simplified version of cpufreq's ondemand governor.

    When a user updates OPP entries (enable/disable/add), OPP framework
    automatically notifies devfreq to update operating frequency
    accordingly. Thus, devfreq users (device drivers) do not need to update
    devfreq manually with OPP entry updates or set polling_ms for powersave
    , performance, userspace, or any other "static" governors.

    Note that these are given only as basic examples for governors and any
    devices with devfreq may implement their own governors with the drivers
    and use them.

    Signed-off-by: MyungJoo Ham
    Signed-off-by: Kyungmin Park
    Reviewed-by: Mike Turquette
    Acked-by: Kevin Hilman
    Signed-off-by: Rafael J. Wysocki

    MyungJoo Ham
     
  • With OPPs, a device may have multiple operable frequency and voltage
    sets. However, there can be multiple possible operable sets and a system
    will need to choose one from them. In order to reduce the power
    consumption (by reducing frequency and voltage) without affecting the
    performance too much, a Dynamic Voltage and Frequency Scaling (DVFS)
    scheme may be used.

    This patch introduces the DVFS capability to non-CPU devices with OPPs.
    DVFS is a techique whereby the frequency and supplied voltage of a
    device is adjusted on-the-fly. DVFS usually sets the frequency as low
    as possible with given conditions (such as QoS assurance) and adjusts
    voltage according to the chosen frequency in order to reduce power
    consumption and heat dissipation.

    The generic DVFS for devices, devfreq, may appear quite similar with
    /drivers/cpufreq. However, cpufreq does not allow to have multiple
    devices registered and is not suitable to have multiple heterogenous
    devices with different (but simple) governors.

    Normally, DVFS mechanism controls frequency based on the demand for
    the device, and then, chooses voltage based on the chosen frequency.
    devfreq also controls the frequency based on the governor's frequency
    recommendation and let OPP pick up the pair of frequency and voltage
    based on the recommended frequency. Then, the chosen OPP is passed to
    device driver's "target" callback.

    When PM QoS is going to be used with the devfreq device, the device
    driver should enable OPPs that are appropriate with the current PM QoS
    requests. In order to do so, the device driver may call opp_enable and
    opp_disable at the notifier callback of PM QoS so that PM QoS's
    update_target() call enables the appropriate OPPs. Note that at least
    one of OPPs should be enabled at any time; be careful when there is a
    transition.

    Signed-off-by: MyungJoo Ham
    Signed-off-by: Kyungmin Park
    Reviewed-by: Mike Turquette
    Acked-by: Kevin Hilman
    Signed-off-by: Rafael J. Wysocki

    MyungJoo Ham