Since Operating Performance Points (OPP) functions are specific
to device specific power management, be specific and rename opp.h
to pm_opp.h
Reported-by: NRandy Dunlap <rdunlap@infradead.org>
Signed-off-by: NNishanth Menon <nm@ti.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

Since Operating Performance Points (OPP) data structures are specific
to device specific power management, be specific and rename opp_* data
structures in OPP library with dev_pm_opp_* equivalent.

Affected structures are:
 struct opp
 enum opp_event

Minor checkpatch warning resulting of this change was fixed as well.
Reported-by: NRandy Dunlap <rdunlap@infradead.org>
Signed-off-by: NNishanth Menon <nm@ti.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

Since Operating Performance Points (OPP) functions are specific to
device specific power management, be specific and rename opp_*
accessors in OPP library with dev_pm_opp_* equivalent.

Affected functions are:
 opp_get_voltage
 opp_get_freq
 opp_get_opp_count
 opp_find_freq_exact
 opp_find_freq_floor
 opp_find_freq_ceil
 opp_add
 opp_enable
 opp_disable
 opp_get_notifier
 opp_init_cpufreq_table
 opp_free_cpufreq_table
Reported-by: NRandy Dunlap <rdunlap@infradead.org>
Signed-off-by: NNishanth Menon <nm@ti.com>
Acked-by: NViresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

Since the patch "cpufreq: cpufreq-cpu0: NULL is a valid regulator", cpu_reg
contains an error value if the regulator is not set, instead of NULL.
Accordingly, fix the remaining check for non-NULL cpu_reg.
Signed-off-by: NPhilipp Zabel <p.zabel@pengutronix.de>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

Commit f837a9b5 "cpufreq: cpufreq-cpu0:
remove device tree parsing for cpu nodes" assumed the pdev->dev is set to
cpu0 device in the platform code. But it actually points to the virtual
cpufreq-cpu0 platform device which is not present in the device tree.
Most of the information needed by cpufreq is stored in cpu0 DT node.
So cpu_dev must point to cpu0 device.

This patch fixes the wrong assignment to cpu_dev.
Reported-and-tested-by: NGuennadi Liakhovetski <g.liakhovetski@gmx.de>
Cc: Shawn Guo <shawn.guo@linaro.org>
Signed-off-by: NSudeep KarkadaNagesha <sudeep.karkadanagesha@arm.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

Now that the cpu device registration initialises the of_node(if available)
appropriately for all the cpus, parsing here is redundant.

This patch removes all DT parsing and uses cpu->of_node instead.
Acked-by: NShawn Guo <shawn.guo@linaro.org>
Acked-by: NRob Herring <rob.herring@calxeda.com>
Acked-by: NViresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: NSudeep KarkadaNagesha <sudeep.karkadanagesha@arm.com>

Since NULL could in theory be a valid regulator we ought to check for
IS_ERR() rather than for NULL. In practice this is unlikely to be an
issue but it's better for neatness.
Signed-off-by: NMark Brown <broonie@linaro.org>
Acked-by: NViresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

Since the cpufreq-cpu0 driver is capable of coping without a software
controllable regulator and would be confused by a dummy one it should
use devm_regulator_get_optional() to ensure no dummy is provided.
Signed-off-by: NMark Brown <broonie@linaro.org>

clk_set_rate() isn't supposed to accept approximate frequencies, instead
a supported frequency should be obtained from clk_round_rate() and then
used to set the clock.
Signed-off-by: NGuennadi Liakhovetski <g.liakhovetski@gmx.de>
Acked-by: NShawn Guo <shawn.guo@linaro.org>
Acked-by: NViresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

We are freeing parent node in success cases but not in failure cases.
Let's do it.
Signed-off-by: NViresh Kumar <viresh.kumar@linaro.org>
Acked-by: NShawn Guo <shawn.guo@linaro.org>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

With commit 1e4b545c, regulator_get will now return -EPROBE_DEFER
when the cpu0-supply node is present, but the regulator is not yet
registered.

It is possible for this to occur when the regulator registration
by itself might be defered due to some dependent interface not yet
instantiated. For example: an regulator which uses I2C and GPIO might
need both systems available before proceeding, in this case, the
regulator might defer it's registration.

However, the cpufreq-cpu0 driver assumes that any un-successful
return result is equivalent of failure.

When the regulator_get returns failure other than -EPROBE_DEFER, it
makes sense to assume that supply node is not present and proceed
with the assumption that only clock control is necessary in the
platform.

With this change, we can now handle the following conditions:
 a) cpu0-supply binding is not present, regulator_get will return
    appropriate error result, resulting in cpufreq-cpu0 driver
    controlling just the clock.
 b) cpu0-supply binding is present, regulator_get returns
    -EPROBE_DEFER, we retry resulting in cpufreq-cpu0 driver
    registering later once the regulator is available.
 c) cpu0-supply binding is present, regulator_get returns
    -EPROBE_DEFER, however, regulator never registers, we retry until
    cpufreq-cpu0 driver fails to register pointing at device tree
    information bug. However, in this case, the fact that
    cpufreq-cpu0 operates with clock only when the DT binding clearly
    indicates need of a supply is a bug of it's own.
 d) cpu0-supply gets an regulator at probe - cpufreq-cpu0 driver
    controls both the clock and regulator
Signed-off-by: NNishanth Menon <nm@ti.com>
Acked-by: NShawn Guo <shawn.guo@linaro.org>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

Parent node must be put after using it to balance its usage count. This was
missing in cpufreq-cpu0 driver. Fix it.
Signed-off-by: NViresh Kumar <viresh.kumar@linaro.org>
Acked-by: NShawn Guo <shawn.guo@linaro.org>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

policy->cpus contains all online cpus that have single shared clock line. And
their frequencies are always updated together.

Many SMP system's cpufreq drivers take care of this in individual drivers but
the best place for this code is in cpufreq core.

This patch modifies cpufreq_notify_transition() to notify frequency change for
all cpus in policy->cpus and hence updates all users of this API.
Signed-off-by: NViresh Kumar <viresh.kumar@linaro.org>
Acked-by: NStephen Warren <swarren@nvidia.com>
Tested-by: NStephen Warren <swarren@nvidia.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

Currently we are simply returning from target() if we encounter some error after
broadcasting CPUFREQ_PRECHANGE notifier. Which looks to be wrong as others might
depend on POSTCHANGE notifier for their functioning.

So, better broadcast CPUFREQ_POSTCHANGE notifier for these failure cases too,
but with old frequency.
Signed-off-by: NViresh Kumar <viresh.kumar@linaro.org>
Acked-by: NShawn Guo <shawn.guo@linaro.org>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

It is not possible for init() to be called for any cpu other than cpu0. During
bootup whatever cpu is used to boot system will be assigned as cpu0. And later
on policy->cpu can only change if we hotunplug all cpus first and then hotplug
them back in different order, which isn't possible (system requires atleast one
cpu to be up always :)).

Though I can see one situation where policy->cpu can be different then zero.
- Hot-unplug cpu 0.
- rmmod cpufreq-cpu0 module
- insmod it back
- hotplug cpu 0 again.

Here, policy->cpu would be different. But the driver doesn't have any dependency
on cpu0 as such. We don't mind which cpu of a system is policy->cpu and so this
check is just not required.

Remove it.
Signed-off-by: NViresh Kumar <viresh.kumar@linaro.org>
Acked-by: NShawn Guo <shawn.guo@linaro.org>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

Check for the presence of the '/cpus' OF node before dereferencing it
blindly:

[    4.181793] Unable to handle kernel NULL pointer dereference at virtual address 0000001c
[    4.181793] pgd = c0004000
[    4.181823] [0000001c] *pgd=00000000
[    4.181823] Internal error: Oops: 5 [#1] SMP ARM
[    4.181823] Modules linked in:
[    4.181823] CPU: 1    Tainted: G        W     (3.8.0-15-generic #25~hbankD)
[    4.181854] PC is at of_get_next_child+0x64/0x70
[    4.181854] LR is at of_get_next_child+0x24/0x70
[    4.181854] pc : [<c04fda18>]    lr : [<c04fd9d8>]    psr: 60000113
[    4.181854] sp : ed891ec0  ip : ed891ec0  fp : ed891ed4
[    4.181884] r10: c04dafd0  r9 : c098690c  r8 : c0936208
[    4.181884] r7 : ed890000  r6 : c0a63d00  r5 : 00000000  r4 : 00000000
[    4.181884] r3 : 00000000  r2 : 00000000  r1 : 00000000  r0 : c0b2acc8
[    4.181884] Flags: nZCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment kernel
[    4.181884] Control: 10c5387d  Table: adcb804a  DAC: 00000015
[    4.181915] Process swapper/0 (pid: 1, stack limit = 0xed890238)
[    4.181915] Stack: (0xed891ec0 to 0xed892000)
[    4.181915] 1ec0: c09b7b70 00000007 ed891efc ed891ed8 c04daff4 c04fd9c0 00000000 c09b7b70
[    4.181915] 1ee0: 00000007 c0a63d00 ed890000 c0936208 ed891f54 ed891f00 c00088e0 c04dafdc
[    4.181945] 1f00: ed891f54 ed891f10 c006e940 00000000 00000000 00000007 00000007 c08a4914
[    4.181945] 1f20: 00000000 c07dbd30 c0a63d00 c09b7b70 00000007 c0a63d00 000000bc c0936208
[    4.181945] 1f40: c098690c c0986914 ed891f94 ed891f58 c0936a40 c00087bc 00000007 00000007
[    4.181976] 1f60: c0936208 be8bda20 b6eea010 c0a63d00 c064547c 00000000 00000000 00000000
[    4.181976] 1f80: 00000000 00000000 ed891fac ed891f98 c0645498 c09368c8 00000000 00000000
[    4.181976] 1fa0: 00000000 ed891fb0 c0014658 c0645488 00000000 00000000 00000000 00000000
[    4.182006] 1fc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
[    4.182006] 1fe0: 00000000 00000000 00000000 00000000 00000013 00000000 00000000 00000000
[    4.182037] [<c04fda18>] (of_get_next_child+0x64/0x70) from [<c04daff4>] (cpu0_cpufreq_driver_init+0x24/0x284)
[    4.182067] [<c04daff4>] (cpu0_cpufreq_driver_init+0x24/0x284) from [<c00088e0>] (do_one_initcall+0x130/0x1b0)
[    4.182067] [<c00088e0>] (do_one_initcall+0x130/0x1b0) from [<c0936a40>] (kernel_init_freeable+0x184/0x24c)
[    4.182098] [<c0936a40>] (kernel_init_freeable+0x184/0x24c) from [<c0645498>] (kernel_init+0x1c/0xf4)
[    4.182128] [<c0645498>] (kernel_init+0x1c/0xf4) from [<c0014658>] (ret_from_fork+0x14/0x20)
[    4.182128] Code: f57ff04f e320f004 e89da830 e89da830 (e595001c)
[    4.182128] ---[ end trace 634903a22e8609cb ]---
[    4.182189] Kernel panic - not syncing: Attempted to kill init!  exitcode=0x0000000b
[    4.182189]
[    4.642395] CPU0: stopping

[rjw: Changelog]
Signed-off-by: NPaolo Pisati <paolo.pisati@canonical.com>
Acked-by: NViresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

clk_round_rate() returns singed value which was assigned to an unsigned
variable.
So it can't be checked for negative.
Signed-off-by: NJonghwan Choi <jhbird.choi@samsung.com>
Acked-by: NShawn Guo <shawn.guo@linaro.org>
Acked-by: NViresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

policy->shared_type field was added only for SoCs with ACPI support:

commit 3b2d9942
Author: Venkatesh Pallipadi <venkatesh.pallipadi@intel.com>
Date:   Wed Dec 14 15:05:00 2005 -0500

    P-state software coordination for ACPI core

    http://bugzilla.kernel.org/show_bug.cgi?id=5737

Many non-ACPI systems are filling this field by mistake, which makes its usage
confusing. Lets clean it.
Signed-off-by: NViresh Kumar <viresh.kumar@linaro.org>
Acked-by: NSantosh Shilimkar <santosh.shilimkar@ti.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

As multiplatform build is being adopted by more and more ARM platforms,
initcall function should be used very carefully.  For example, when
GENERIC_CPUFREQ_CPU0 is built in the kernel, cpu0_cpufreq_driver_init()
will be called on all the platforms to initialize cpufreq-cpu0 driver.

To eliminate this undesired the effect, the patch changes cpufreq-cpu0
driver to have it instantiated as a platform_driver.  Then it will only
run on platforms that create the platform_device "cpufreq-cpu0".

Along with the change, it also changes cpu_dev to be &pdev->dev,
so that managed functions can start working, and module build gets
supported too.

The highbank-cpufreq driver is also updated accordingly to adapt the
changes on cpufreq-cpu0.
Signed-off-by: NShawn Guo <shawn.guo@linaro.org>
Reviewed-by: NViresh Kumar <viresh.kumar@linaro.org>
Acked-by: NMark Langsdorf <mark.langsdorf@calxeda.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

Highbank processors depend on the external ECME to perform voltage
management based on a requested frequency. Communication between the
A9 cores and the ECME happens over the pl320 IPC channel.
Signed-off-by: NMark Langsdorf <mark.langsdorf@calxeda.com>
Reviewed-by: NShawn Guo <shawn.guo@linaro.org>
Reviewed-by: NMike Turquette <mturquette@linaro.org>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

OPP pointer is RCU protected, hence after finding it, de-reference
also should be protected with the same RCU context else the OPP
pointer may become invalid.
Reported-by: NJack Mitchell <jack@embed.me.uk>
Tested-by: NAlexander Holler <holler@ahsoftware.de>
Tested-by: NJack Mitchell <jack@embed.me.uk>
Acked-by: NAlexander Holler <holler@ahsoftware.de>
Signed-off-by: NNishanth Menon <nm@ti.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

CONFIG_HOTPLUG is going away as an option so __devinit is no longer
needed.
Signed-off-by: NBill Pemberton <wfp5p@virginia.edu>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

It adds a generic cpufreq driver for CPU0 frequency management based on
clk, regulator, OPP and device tree support.  It can support both
uniprocessor (UP) and those symmetric multiprocessor (SMP) systems which
share clock and voltage across all CPUs.
Signed-off-by: NShawn Guo <shawn.guo@linaro.org>
Acked-by: NSantosh Shilimkar <santosh.shilimkar@ti.com>
Tested-by: NAnilKumar Ch <anilkumar@ti.com>
Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>