Adds a function that sets the pointer to dev_pm_domain in struct device
and that warns if the device has already finished probing. The reason
why we want to enforce that is because in the general case that can
cause problems and also that we can simplify code quite a bit if we can
always assume that.

This patch also changes all current code that directly sets the
dev.pm_domain pointer.
Signed-off-by: NTomeu Vizoso <tomeu.vizoso@collabora.com>
Reviewed-by: NUlf Hansson <ulf.hansson@linaro.org>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

There is a new notification BUS_NOTIFY_DRIVER_NOT_BOUND that is issued when
driver fails during binding. In such case pm_clk_notify(), when PM_CLK=n,
leaves clocks enabled. Undo operations that have been done in
BUS_NOTIFY_BIND_DRIVER case.
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

The documentation for detach() said attach.
Signed-off-by: NManuel Pégourié-Gonnard <mpg@elzevir.fr>
Acked-by: NPavel Machek <pavel@ucw.cz>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

Introduce a new runtime PM function, pm_runtime_get_if_in_use(),
that will increment the device's runtime PM usage counter and
return 1 if its status is RPM_ACTIVE and its usage counter
is greater than 0 at the same time (0 will be returned otherwise).

This is useful for things that should only be done if the device
is active (from the runtime PM perspective) and used by somebody
(as indicated by the usage counter) already and they are not worth
bothering otherwise.
Requested-by: NImre Deak <imre.deak@intel.com>
Reviewed-by: NUlf Hansson <ulf.hansson@linaro.org>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

It looks like these meant to be unreffing the
of_parse_phandle_with_args() node, since the error paths above it
don't do of_node_put.  That function returns a new ref in pd_args.np,
though, not a new ref on dev->of_node.  Also, it would have leaked the
ref in the success case.

Fixes "ERROR: Bad of_node_put()" on bcm2835 in the -EPROBE_DEFER case.

Fixes: aa42240a (PM / Domains: Add generic OF-based PM domain look-up)
Signed-off-by: NEric Anholt <eric@anholt.net>
Acked-by: NUlf Hansson <ulf.hansson@linaro.org>
Acked-by: NKevin Hilman <khilman@linaro.org>
Cc: 3.18+ <stable@vger.kernel.org> # 3.18+
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

Recently genpd removed the requirement of a having a driver bound for its
attached devices to allow genpd to power off. That change should also have
removed a corresponding validation in the governor, let's correct that.

Fixes: 298cd0f0 (PM / Domains: Remove dev->driver check for runtime)
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

There are two common expectations among several subsystems/drivers that
deploys runtime PM support, but which isn't met by the driver core.

Expectation 1)
At ->probe() the subsystem/driver expects the runtime PM status of the
device to be RPM_SUSPENDED, which is the initial status being assigned at
device registration.

This expectation is especially common among some of those subsystems/
drivers that manages devices with an attached PM domain, as those requires
the ->runtime_resume() callback at the PM domain level to be invoked
during ->probe().

Moreover these subsystems/drivers entirely relies on runtime PM resources
being managed at the PM domain level, thus don't implement their own set
of runtime PM callbacks.

These are two scenarios that suffers from this unmet expectation.

i) A failed ->probe() sequence requests probe deferral:

->probe()
  ...
  pm_runtime_enable()
  pm_runtime_get_sync()
  ...

err:
  pm_runtime_put()
  pm_runtime_disable()
  ...

As there are no guarantees that such sequence turns the runtime PM status
of the device into RPM_SUSPENDED, the re-trying ->probe() may start with
the status in RPM_ACTIVE.

In such case the runtime PM core won't invoke the ->runtime_resume()
callback because of a pm_runtime_get_sync(), as it considers the device to
be already runtime resumed.

ii) A driver re-bind sequence:

At driver unbind, the subsystem/driver's >remove() callback invokes a
sequence of runtime PM APIs, to undo actions during ->probe() and to put
the device into low power state.

->remove()
  ...
  pm_runtime_put()
  pm_runtime_disable()
  ...

Similar as in the failing ->probe() case, this sequence don't guarantee
the runtime PM status of the device to turn into RPM_SUSPENDED.

Trying to re-bind the driver thus causes the same issue as when re-trying
->probe(), in the probe deferral scenario.

Expectation 2)
Drivers that invokes the pm_runtime_irq_safe() API during ->probe(),
triggers the runtime PM core to increase the usage count for the device's
parent and permanently make it runtime resumed.

The usage count is only dropped at device removal, which also allows it to
be runtime suspended again.

A re-trying ->probe() repeats the call to pm_runtime_irq_safe() and thus
once more triggers the usage count of the device's parent to be increased.

This leads to not only an imbalance issue of the usage count of the
device's parent, but also to keep it runtime resumed permanently even if
->probe() fails.

To address these issues, let's change the policy of the driver core to
meet these expectations. More precisely, at ->probe() failures and driver
unbind, restore the initial states of runtime PM.

Although to still allow subsystem's to control PM for devices that doesn't
->probe() successfully, don't restore the initial states unless runtime PM
is disabled.
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
Reviewed-by: NKevin Hilman <khilman@linaro.org>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

It is unsafe [1] if probing of devices will happen during suspend or
hibernation and system behavior will be unpredictable in this case.
So, let's prohibit device's probing in dpm_prepare() and defer their
probing instead. The normal behavior will be restored in
dpm_complete().

This patch introduces new DD core APIs:
 device_block_probing()
   It will disable probing of devices and defer their probes instead.
 device_unblock_probing()
   It will restore normal behavior and trigger re-probing of deferred
   devices.

[1] https://lkml.org/lkml/2015/9/11/554Signed-off-by: NGrygorii Strashko <grygorii.strashko@ti.com>
Acked-by: NPavel Machek <pavel@ucw.cz>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

Check that IRQ number passed to dev_pm_set_wake_irq() and
dev_pm_set_dedicated_wake_irq() is valid (not negative) before
accepting it.
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

_find_device_opp() should be called with rcu-read lock or
dev_opp_list_lock held. Add the opp_rcu_lockdep_assert() check to make
sure caller have taken appropriate locks.

Fix comment over the routine as well.
Suggested-by: NStephen Boyd <sboyd@codeaurora.org>
Signed-off-by: NViresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

Writers need to update OPP device and their list with dev_opp_list_lock
mutex held, which was missed at few places. Fix it.
Signed-off-by: NViresh Kumar <viresh.kumar@linaro.org>
Cc: 4.3 <stable@vger.kernel.org> # 4.3
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

dev_opp_list_lock is used everywhere to protect device and OPP lists,
but dev_pm_opp_set_sharing_cpus() is missed somehow. And instead we used
rcu-lock, which wouldn't help here as we are adding a new list_dev.

This also fixes a problem where we have called kzalloc(..., GFP_KERNEL)
from within rcu-lock, which isn't allowed as kzalloc can sleep when
called with GFP_KERNEL.

With CONFIG_DEBUG_ATOMIC_SLEEP set, we get following lockdep-splat:

include/linux/rcupdate.h:578 Illegal context switch in RCU read-side critical section!

other info that might help us debug this:

rcu_scheduler_active = 1, debug_locks = 0
5 locks held by swapper/0/1:
 #0:  (&dev->mutex){......}, at: [<c02f68f4>] __driver_attach+0x48/0x98
 #1:  (&dev->mutex){......}, at: [<c02f6904>] __driver_attach+0x58/0x98
 #2:  (cpu_hotplug.lock){++++++}, at: [<c00249d0>] get_online_cpus+0x40/0xb0
 #3:  (subsys mutex#5){+.+.+.}, at: [<c02f4f8c>] subsys_interface_register+0x44/0xdc
 #4:  (rcu_read_lock){......}, at: [<c0305c80>] dev_pm_opp_set_sharing_cpus+0x0/0x1e4

stack backtrace:
CPU: 1 PID: 1 Comm: swapper/0 Tainted: G        W       4.3.0-rc7-00047-g81f5932958a8 #59
Hardware name: SAMSUNG EXYNOS (Flattened Device Tree)
[<c0016874>] (unwind_backtrace) from [<c001355c>] (show_stack+0x10/0x14)
[<c001355c>] (show_stack) from [<c022553c>] (dump_stack+0x94/0xbc)
[<c022553c>] (dump_stack) from [<c004904c>] (___might_sleep+0x24c/0x298)
[<c004904c>] (___might_sleep) from [<c00f07e4>] (kmem_cache_alloc+0xe8/0x164)
[<c00f07e4>] (kmem_cache_alloc) from [<c0305354>] (_add_list_dev+0x30/0x58)
[<c0305354>] (_add_list_dev) from [<c0305d50>] (dev_pm_opp_set_sharing_cpus+0xd0/0x1e4)
[<c0305d50>] (dev_pm_opp_set_sharing_cpus) from [<c040eda4>] (cpufreq_init+0x4cc/0x62c)
[<c040eda4>] (cpufreq_init) from [<c040a964>] (cpufreq_online+0xbc/0x73c)
[<c040a964>] (cpufreq_online) from [<c02f4fe0>] (subsys_interface_register+0x98/0xdc)
[<c02f4fe0>] (subsys_interface_register) from [<c040a640>] (cpufreq_register_driver+0x110/0x17c)
[<c040a640>] (cpufreq_register_driver) from [<c040ef64>] (dt_cpufreq_probe+0x60/0x8c)
[<c040ef64>] (dt_cpufreq_probe) from [<c02f8084>] (platform_drv_probe+0x44/0xa4)
[<c02f8084>] (platform_drv_probe) from [<c02f67c0>] (driver_probe_device+0x208/0x2f4)
[<c02f67c0>] (driver_probe_device) from [<c02f6940>] (__driver_attach+0x94/0x98)
[<c02f6940>] (__driver_attach) from [<c02f4c1c>] (bus_for_each_dev+0x68/0x9c)
Reported-by: NMichael Turquette <mturquette@baylibre.com>
Reviewed-by: NStephen Boyd <sboyd@codeaurora.org>
Signed-off-by: NViresh Kumar <viresh.kumar@linaro.org>
Cc: 4.3 <stable@vger.kernel.org> # 4.3
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

We are returning 0 even in case of errors, fix it.

Fixes: 8d4d4e98 ("PM / OPP: Add helpers for initializing CPU OPPs")
Reported-by: NDan Carpenter <dan.carpenter@oracle.com>
Reviewed-by: NStephen Boyd <sboyd@codeaurora.org>
Signed-off-by: NViresh Kumar <viresh.kumar@linaro.org>
Cc: 4.3 <stable@vger.kernel.org> # 4.3
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

In preparation for supporting IRQ-safe domains, allocate domain data
outside the domain locks. These functions are not called in an atomic
context, so we can always allocate memory using GFP_KERNEL. By
allocating memory before the locks, we can safely lock the domain using
spinlocks instead of mutexes.
Reviewed-by: NKevin Hilman <khilman@linaro.org>
Acked-by: NUlf Hansson <ulf.hansson@linaro.org>
Signed-off-by: NLina Iyer <lina.iyer@linaro.org>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

Remove check for driver of a device, for runtime PM. Device may be
suspended without an explicit driver. This check seems to be vestigial
and incorrect in the current context.
Reviewed-by: NKrzysztof Kozlowski <k.kozlowski@samsung.com>
Acked-by: NUlf Hansson <ulf.hansson@linaro.org>
Signed-off-by: NKevin Hilman <khilman@linaro.org>
Signed-off-by: NLina Iyer <lina.iyer@linaro.org>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

Move all DT parsing for the power supplies to a single function, rather
than keeping them at separate places. This will help manage things
properly.
Signed-off-by: NViresh Kumar <viresh.kumar@linaro.org>
Reviewed-by: NStephen Boyd <sboyd@codeaurora.org>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

Clearly distinguish routines based on what version of bindings they
parse. We have already postfixed routines properly with _v2 for new
bindings. Postfix the older ones now with _v1.
Signed-off-by: NViresh Kumar <viresh.kumar@linaro.org>
Reviewed-by: NStephen Boyd <sboyd@codeaurora.org>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

To identify OPP core's print messages easily, prefix them with
KBUILD_MODNAME.
Signed-off-by: NViresh Kumar <viresh.kumar@linaro.org>
Reviewed-by: NStephen Boyd <sboyd@codeaurora.org>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

The OPP library is now used for power models to calculate the power
that a device would consume at a specific OPP.  To do that, we use a
simple power model which takes frequency and voltage as inputs.  We get
the voltage and frequency from the OPP library.

The devfreq cooling device for the thermal framework controls
temperature by disabling OPPs.  The power model needs to calculate the
power that would be consumed if we reenabled the OPP.  Therefore, let
dev_pm_opp_get_voltage() work for disabled OPPs.

Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net>
Acked-by: NViresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: NJavi Merino <javi.merino@arm.com>
Signed-off-by: NEduardo Valentin <edubezval@gmail.com>

Measure latency does by itself contribute to an increased latency, thus we
should avoid it when it isn't needed.

By merging the latency measurements for the ->save_state() and the
->stop() callbacks, we get one measurement instead of two and we get one
value to store instead of two. Let's also apply the likewise change for
the ->start() and ->restore_state() callbacks.
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
Reviewed-by: NLina Iyer <lina.iyer@linaro.org>
Acked-by: NKevin Hilman <khilman@linaro.org>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

Measure latency does by itself contribute to an increased latency, thus we
should avoid it when it isn't needed.

Genpd measures latencies in the system PM phase for the ->start|stop()
callbacks and is thus affecting the system PM suspend/resume time.
Moreover these latencies are validated only at runtime PM suspend/resume.

To this reasoning, let's decide to leave these measurements out of the
system PM phase. There should be plenty of occasions during runtime PM to
perform these measurements anyway.
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
Reviewed-by: NLina Iyer <lina.iyer@linaro.org>
Acked-by: NKevin Hilman <khilman@linaro.org>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

If an architecture's main Kconfig file doesn't include
kernel/power/Kconfig, but CONFIG_PM=y and HAVE_CLK=y (e.g. m68knommu
allmodconfig):

    drivers/base/power/clock_ops.c: In function ‘__pm_clk_add’:
    drivers/base/power/clock_ops.c:106: error: ‘struct pm_subsys_data’ has no member named ‘clock_list’
    drivers/base/power/clock_ops.c: At top level:
    drivers/base/power/clock_ops.c:120: error: redefinition of ‘pm_clk_add’
    include/linux/pm_clock.h:64: error: previous definition of ‘pm_clk_add’ was here
    drivers/base/power/clock_ops.c:135: error: redefinition of ‘pm_clk_add_clk’
    include/linux/pm_clock.h:69: error: previous definition of ‘pm_clk_add_clk’ was here
    drivers/base/power/clock_ops.c:171: error: redefinition of ‘pm_clk_remove’
    include/linux/pm_clock.h:73: error: previous definition of ‘pm_clk_remove’ was here
    drivers/base/power/clock_ops.c: In function ‘pm_clk_remove’:
    drivers/base/power/clock_ops.c:180: error: ‘struct pm_subsys_data’ has no member named ‘clock_list’
    drivers/base/power/clock_ops.c:180: error: ‘struct pm_subsys_data’ has no member named ‘clock_list’
    drivers/base/power/clock_ops.c: At top level:
    drivers/base/power/clock_ops.c:207: error: redefinition of ‘pm_clk_init’
    include/linux/pm_clock.h:54: error: previous definition of ‘pm_clk_init’ was here
    drivers/base/power/clock_ops.c: In function ‘pm_clk_init’:
    drivers/base/power/clock_ops.c:210: error: ‘struct pm_subsys_data’ has no member named ‘clock_list’
    drivers/base/power/clock_ops.c: At top level:
    drivers/base/power/clock_ops.c:221: error: redefinition of ‘pm_clk_create’
    include/linux/pm_clock.h:57: error: previous definition of ‘pm_clk_create’ was here
    drivers/base/power/clock_ops.c:234: error: redefinition of ‘pm_clk_destroy’
    include/linux/pm_clock.h:61: error: previous definition of ‘pm_clk_destroy’ was here
    drivers/base/power/clock_ops.c: In function ‘pm_clk_destroy’:
    drivers/base/power/clock_ops.c:246: error: ‘struct pm_subsys_data’ has no member named ‘clock_list’
    drivers/base/power/clock_ops.c:246: error: ‘struct pm_subsys_data’ has no member named ‘clock_list’
    drivers/base/power/clock_ops.c: At top level:
    drivers/base/power/clock_ops.c:263: error: expected identifier or ‘(’ before ‘void’
    drivers/base/power/clock_ops.c:263: error: expected ‘)’ before numeric constant
    drivers/base/power/clock_ops.c:293: error: expected identifier or ‘(’ before ‘void’
    drivers/base/power/clock_ops.c:293: error: expected ‘)’ before numeric constant
    drivers/base/power/clock_ops.c: In function ‘pm_clk_runtime_suspend’:
    drivers/base/power/clock_ops.c:384: error: called object ‘0u’ is not a function
    drivers/base/power/clock_ops.c: In function ‘pm_clk_runtime_resume’:
    drivers/base/power/clock_ops.c:400: error: called object ‘0u’ is not a function

This happens because:
  - drivers/base/power/clock_ops.c depends on CONFIG_HAVE_CLK,
  - the failing code inside clock_ops.c additionally depends on
    CONFIG_PM,
  - the forward declarations and other definitions in <linux/pm_clock.h>
    depend on CONFIG_PM_CLK,
  - CONFIG_PM_CLK is defined as PM && HAVE_CLK in kernel/power/Kconfig,
    but it is not included on all architectures.

Fix this by protecting the failing code inside clock_ops.c by
CONFIG_PM_CLK instead of CONFIG_PM, so it matches <linux/pm_clock.h>.
Signed-off-by: NGeert Uytterhoeven <geert@linux-m68k.org>
Acked-by: NPavel Machek <pavel@ucw.cz>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

Commit ba2bbfbf (PM / Domains: Remove intermediate states from the
power off sequence) changed the power off sequence in genpd. That also
required some updates regarding the validation of latency constraints in
the genpd governor. Unfortunate that wasn't covered, so let's fix this.

From a runtime PM and latency point of view, we need to consider the worst
case scenario while validating latency constraints. That's typically when
a call to pm_runtime_get_sync() needs to wait for a ongoing runtime
suspend operation to be carried out, as it then also needs to wait for the
device to be runtime resumed again.

The above mentioned commit made the genpd governor's ->stop_ok() callback
responsible of validating genpd's device's runtime suspend/resume latency.
In other words, the constraint needs to be validated towards the relevant
latencies present in genpd's ->runtime_suspend|resume() callbacks.

Earlier, that included latencies from the ->stop|start() callbacks, but as
->save|restore_state() are now also being invoked from genpd's
->runtime_suspend|resume() and to comply with the worst case scenario,
let's take also those latencies into account.

Fixes: ba2bbfbf (PM / Domains: Remove intermediate states from the power off sequence)
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

This is another step to get consistent names of functions in genpd. Let's
rename the internal *pm_genpd_poweron|poweroff() into
*genpd_poweron|poweroff().
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

There is a concern that if the platform firmware was involved in
the system resume that's being completed,  some devices might have
been reset by it and if those devices had the power.direct_complete
flag set during the preceding suspend transition, they may stay
in a reset-power-on state indefinitely (until they are runtime-resumed
and then suspended again).  That may not be a big deal from the
individual device's perspective, but if the system is an SoC, it may
be prevented from entering deep SoC-wide low-power states on idle
because of that.

The devices that are most likely to be affected by this issue are
PCI devices and ACPI-enumerated devices using the general ACPI PM
domain, so to prevent it from happening for those devices, force a
runtime resume for them if they have their power.direct_complete
flags set and the platform firmware was involved in the resume
transition currently in progress.
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

The pm_request_idle() in pm_generic_complete() is pointless as it is
called with the runtime PM usage counter different from zero (bumped
up by the core during the prepare phase of system suspend) and the
core calls pm_runtime_put() for all devices after executing their
complete callbacks, so drop it.

This allows the PCI PM layer to use pm_generic_complete() too.
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: NUlf Hansson <ulf.hansson@linaro.org>

Once genpd could be configured to be built with CONFIG_PM_RUNTIME unset
(nowadays CONFIG_PM), the pm_genpd_poweron() API served a purpose, since
it allowed users to power on a PM domain.

As such configuration no longer is supported, users shall solely rely on
using some of the runtime PM APIs to power on a PM domain.
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

As the last user of the pm_genpd_poweroff_unused() API has moved into
relying on genpd to deal with this internally from a late_initcall, let's
remove the API.
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

Commit ba2bbfbf ("PM / Domains: Remove intermediate states..") changed
the power off sequence (pm_genpd_poweroff()), which from locking point of
view means the genpd mutex is held throughout the sequence.

The above change means the in_progress counter can't be updated while
pm_genpd_poweroff() is executing, which allows us to remove the counter.

Instead we inform pm_genpd_poweroff() via a bool parameter, to indicate
whether we call it from the scheduled work or from the ->runtime_suspend()
callback, since that all that matters.
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
Reviewed-by: NLina Iyer <lina.iyer@linaro.org>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

The code was using PTR_ERR(NULL) which causes a static checker warning.
I have fixed up the printks and changed the return to -ENOENT.
Signed-off-by: NDan Carpenter <dan.carpenter@oracle.com>
Acked-by: NViresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

Export these symbols so they can be used in loadable kernel
modules.

Cc: Rob Clark <robdclark@gmail.com>
Cc: Rajendra Nayak <rnayak@codeaurora.org>
Cc: Kevin Hilman <khilman@kernel.org>
Cc: Ulf Hansson <ulf.hansson@linaro.org>
Acked-by: NRafael J. Wysocki <rjw@rjwysocki.net>
Signed-off-by: NStephen Boyd <sboyd@codeaurora.org>

Clock references are on a per-user basis now, so they are not supposed
to be refcounted by itself anymore. Therefore multiple cascaded get and
put calls will fail.

When a clock reference gets passed into pm_clk_add_clk we can assume
that the pm clock handling will take control of the clock reference,
so after this functions returns the caller should've given up control
of that handle.

So remove the additional call to __clk_get() in __pm_clk_add().

The only current user of pm_clk_add_clk is drivers/clk/shmobile/clk-mstp.c
which already follows this paradigm by only getting the clock but not
puting it after passing the reference into pm_clk_add_clk.

In the error case the caller is expected to clean up the clock, as it
may very well try to do something different if pm_clk_add_clk() fails.
Signed-off-by: NStephen Boyd <sboyd@codeaurora.org>
[add commit-message]
Signed-off-by: NHeiko Stuebner <heiko@sntech.de>
Acked-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

Drop the "out" label in __pm_genpd_poweron() that's not used any more.
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

The power domains code allows to tie a cpuidle state with a power domain.

Preventing the cpuidle framework to enter a specific idle state by disabling
from the power domain framework is a good idea. Unfortunately, the current
implementation has some gaps with a SMP system and a complex cpuidle
implementation. Enabling a power domain wakes up all the cpus even if a cpu
does not belong to the power domain.

There is some work to do a logical representation with the power domains of
the hardware dependencies (eg. a cpu belongs to a power domains, these power
domains belong to a higher power domain for a cluster, etc ...). A new code
relying on the genpd hierarchy to disable the idle states would make more
sense.

As the unique user of this code has been removed, let's wipe out this code
to prevent new user and to have a clean place to put a new implementation.
Signed-off-by: NDaniel Lezcano <daniel.lezcano@linaro.org>
Acked-by: NKevin Hilman <khilman@linaro.org>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

As all users of the named based APIs now have converted to the non-named
based APIs, the time has come to remove them.
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
Acked-by: NGeert Uytterhoeven <geert+renesas@glider.be>
Acked-by: NKevin Hilman <khilman@linaro.org>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

Reported-by: NViresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: NStephen Boyd <sboyd@codeaurora.org>
Acked-by: NViresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

of_property_count_u32_elems() will never return 0, but a -ve error value
of a positive count. And so the current !count check is wrong.

Also, a missing "opp-microvolt" property isn't a problem and so we need
to do of_find_property() separately to confirm that.

Fixes: 27465902 (PM / OPP: Add support to parse "operating-points-v2" bindings)
Signed-off-by: NViresh Kumar <viresh.kumar@linaro.org>
Reviewed-by: NStephen Boyd <sboyd@codeaurora.org>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

Using kstrdup_const allows us to save a little runtime memory (and a
string copy) in the common case where name is a string literal.
Signed-off-by: NRasmus Villemoes <linux@rasmusvillemoes.dk>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

Add a sysfs attribute, /sys/power/pm_wakeup_irq, reporting the IRQ
number of the first wakeup interrupt (that is, the first interrupt
from an IRQ line armed for system wakeup) seen by the kernel during
the most recent system suspend/resume cycle.

This feature will be useful for system wakeup diagnostics of
spurious wakeup interrupts.
Signed-off-by: NAlexandra Yates <alexandra.yates@linux.intel.com>
[ rjw: Fixed up pm_wakeup_irq definition ]
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

Move cpu device specific code out of generic opp library, and add it to
cpu.c.

Along with that, create a core-internal opp.h header, which will be used
to share structures and function prototypes within opp core.
Reviewed-by: NStephen Boyd <sboyd@codeaurora.org>
Signed-off-by: NViresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>