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>

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>

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>

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>

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>

Performance and powersave governor's get_target_freq
is not called if driver chooses one of these two governors.
Add init function in governor profile to call update_devfreq
which will call get_target_freq subsequently.
Signed-off-by: NXiaoguang Chen <chenxg@marvell.com>
Acked-by: NMyungJoo Ham <myungjoo.ham@samsung.com>
Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>

Correct spelling typo in various Kconfig file.
Signed-off-by: NMasanari Iida <standby24x7@gmail.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

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>

In the commit, "PM / devfreq: update the name of EXYNOS clock register"
ommitted one register.
Signed-off-by: NMyungJoo Ham <myungjoo.ham@samsung.com>
Signed-off-by: NKukjin Kim <kgene.kim@samsung.com>

According to replacing the name of EXYNOS clock registers,
this patch updates exynos4_bus.c file where it is used.
Acked-by: NMyungJoo Ham <myungjoo.ham@samsung.com>
Cc: Kyungmin Park <kyungmin.park@samsung.com>
Signed-off-by: NKukjin Kim <kgene.kim@samsung.com>

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>

This driver can only be built-in, it does not make sense to add modalias for
it (in addition to being incorrect, the platform modalias needs to be prefixed
with "platform:").
Signed-off-by: NAxel Lin <axel.lin@gmail.com>
Signed-off-by: NMyungJoo Ham <myungjoo.ham@samsung.com>

Signed-off-by: NAxel Lin <axel.lin@gmail.com>
Signed-off-by: NMyungJoo Ham <myungjoo.ham@samsung.com>

Exynos4-bus device devfreq driver add DVFS capability for
Exynos4210/4212/4412-Bus (memory). The driver monitors PPMU counters of memory
controllers and adjusts operating frequencies and voltages with OPP.
For Exynos4210, vdd_int is controlled. For exynos4412/4212, vdd_mif and
vdd_int are controlled.

Dependency (CONFIG_EXYNOS_ASV):
Exynos4 ASV driver has been posted in the mailing list; however, it
si not yet upstreamed. Although the current revision of Exynos4 ASV
patch does not contain "CONFIG_EXYNOS_ASV", we have added the symbol
to hide the dependent from compilers for now. As soon as Exynos4 ASV
drivers are merged, the #ifdef statement will be removed or the
name will be changed.

However, enabling ASV is essential in most Exynos4 chips to reduce
the power consumption of Exynos4210 because without ASV, this Devfreq
driver assumes the worst case scenario, which consumes more power.
Signed-off-by: NMyungJoo Ham <myungjoo.ham@samsung.com>
Signed-off-by: NKyungmin Park <kyungmin.park@samsung.com>

---
Changes from v1
- Support 4212 and 4412 as well as 4210.

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>

Devfreq does not depend on OPP. The dependency is removed.
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>

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>

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>

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: 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>

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

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>