- 15 11月, 2012 5 次提交
-
-
由 Nishanth Menon 提交于
sscanf returns 0 when an invalid parameter like: echo -n "a">min_freq is attempted. Returning back the return result(0) will cause the command not to return back to command prompt. Instead, just return -EINVAL when sscanf does not return 1. This is done for min_freq, max_freq and polling_interval Signed-off-by: NNishanth Menon <nm@ti.com> Acked-by: NMyungJoo Ham <myungjoo.ham@samsung.com> Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
-
由 Nishanth Menon 提交于
Parameter documentation needs a ':' for scripts/kernel-doc to parse properly. Minor fixes for ones warned by: ./scripts/kernel-doc -text drivers/devfreq/devfreq.c>/dev/null Signed-off-by: NNishanth Menon <nm@ti.com> Acked-by: NRandy Dunlap <rdunlap@xenotime.net> Acked-by: NMyungJoo Ham <myungjoo.ham@samsung.com> Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
-
由 Rajagopal Venkat 提交于
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: NRajagopal Venkat <rajagopal.venkat@linaro.org> Acked-by: NMyungJoo Ham <myungjoo.ham@samsung.com> Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
-
由 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: NRajagopal Venkat <rajagopal.venkat@linaro.org> Acked-by: NMyungJoo Ham <myungjoo.ham@samsung.com> Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
-
由 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: NRajagopal Venkat <rajagopal.venkat@linaro.org> Acked-by: NMyungJoo Ham <myungjoo.ham@samsung.com> Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
-
- 22 8月, 2012 1 次提交
-
-
由 Tejun Heo 提交于
Initalizers for deferrable delayed_work are confused. * __DEFERRED_WORK_INITIALIZER() * DECLARE_DEFERRED_WORK() * INIT_DELAYED_WORK_DEFERRABLE() Rename them to * __DEFERRABLE_WORK_INITIALIZER() * DECLARE_DEFERRABLE_WORK() * INIT_DEFERRABLE_WORK() This patch doesn't cause any functional changes. Signed-off-by: NTejun Heo <tj@kernel.org>
-
- 18 3月, 2012 1 次提交
-
-
由 MyungJoo Ham 提交于
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: NMyungJoo Ham <myungjoo.ham@samsung.com> Signed-off-by: NKyungmin Park <kyungmin.park@samsung.com> Reviewed-by: NMike Turquette <mturquette@ti.com> Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
-
- 20 1月, 2012 1 次提交
-
-
由 MyungJoo Ham 提交于
The frequency requested to devfreq device driver from devfreq governors is restricted by min_freq and max_freq input. Signed-off-by: NMyungJoo Ham <myungjoo.ham@samsung.com> Signed-off-by: NKyungmin Park <kyungmin.park@samsung.com>
-
- 24 11月, 2011 1 次提交
-
-
由 Axel Lin 提交于
I think this change improves code readability. Signed-off-by: NAxel Lin <axel.lin@gmail.com> Acked-by: NMyungJoo Ham <myungjoo.ham@samsung.com> Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
-
- 15 11月, 2011 1 次提交
-
-
由 Axel Lin 提交于
In devfreq_remove_device, calling _remove_devfreq will also free devfreq. Don't dereference devfreq->governor->no_central_polling after _remove_devfreq. Signed-off-by: NAxel Lin <axel.lin@gmail.com> Acked-by: NMyungJoo Ham <myungjoo.ham@samsung.com> Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
-
- 10 11月, 2011 1 次提交
-
-
由 MyungJoo Ham 提交于
Added <linux/module.h> and <linux/stat.h> to avoid a compiler error because linux/irq.h no longer includes linux/module.h after Linux 3.2. Signed-off-by: NMyungJoo Ham <myungjoo.ham@samsung.com> Signed-off-by: NKyungmin Park <kyungmin.park@samsung.com> Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
-
- 02 10月, 2011 2 次提交
-
-
由 MyungJoo Ham 提交于
Device specific sysfs interface /sys/devices/.../power/devfreq_* - governor R: name of governor - cur_freq R: current frequency - polling_interval R: polling interval in ms given with devfreq profile W: update polling interval. - central_polling R: 1 if polling is managed by devfreq framework Signed-off-by: NMyungJoo Ham <myungjoo.ham@samsung.com> Signed-off-by: NKyungmin Park <kyungmin.park@samsung.com> Reviewed-by: NMike Turquette <mturquette@ti.com> Acked-by: NKevin Hilman <khilman@ti.com> Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl> -- Documentation/ABI/testing/sysfs-class-devfreq | 44 ++++++++++++++++ drivers/devfreq/devfreq.c | 69 ++++++++++++++++++++++++++ 2 files changed, 113 insertions(+) create mode 100644 Documentation/ABI/testing/sysfs-class-devfreq
-
由 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: NMyungJoo Ham <myungjoo.ham@samsung.com> Signed-off-by: NKyungmin Park <kyungmin.park@samsung.com> Reviewed-by: NMike Turquette <mturquette@ti.com> Acked-by: NKevin Hilman <khilman@ti.com> Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
-