09 Jun, 2017
1 commit
-
In some platforms, accessing registers needs to make sure
power domain is enabled, such as for clock operations, power
domain needs to be enabled first before accessing clock
registers, so some clocks need to know its power domain's
status, it will need to get power domain structure by phandle,
expose the API to support this case.Signed-off-by: Anson Huang
23 Feb, 2017
1 commit
-
Since some driver which use power domain may use suspend_noirq/resume_noirq
we need implement it in power domain framework.Signed-off-by: Robin Gong
(cherry picked from commit f797469507178ddf7f41de913c79f3b709c72872)
12 Jan, 2017
1 commit
-
commit bed570307ed78f21b77cb04a1df781dee4a8f05a upstream.
I noticed some wakeirq flakeyness with consumer drivers not using
autosuspend. For drivers not using autosuspend, the wakeirq may never
get unmasked in rpm_suspend() because of irq desc->depth.We are configuring dedicated wakeirqs to start with IRQ_NOAUTOEN as we
naturally don't want them running until rpm_suspend() is called.However, when a consumer driver initially calls pm_runtime_get(), we
now wrongly start with disable_irq_nosync() call on the dedicated
wakeirq that is disabled to start with.This causes desc->depth to toggle between 1 and 2 instead of the usual
0 and 1. This can prevent enable_irq() from unmasking the wakeirq as
that only happens at desc->depth 1.This does not necessarily show up with drivers using autosuspend as
there is time for disable_irq_nosync() before rpm_suspend() gets called
after the autosuspend timeout.Let's fix the issue by adding wirq->status that lazily gets set on
the first rpm_suspend(). We also need PM runtime core private functions
for dev_pm_enable_wake_irq_check() and dev_pm_disable_wake_irq_check()
so we can enable the dedicated wakeirq on the first rpm_suspend().While at it, let's also fix the comments for dev_pm_enable_wake_irq()
and dev_pm_disable_wake_irq(). Those can still be used by the consumer
drivers as needed because the IRQ core manages the interrupt usecount
for us.Fixes: 4990d4fe327b (PM / Wakeirq: Add automated device wake IRQ handling)
Signed-off-by: Tony Lindgren
Signed-off-by: Rafael J. Wysocki
Signed-off-by: Greg Kroah-Hartman
06 Jan, 2017
2 commits
-
commit dc39d06fcd7a4a82d72eae7b71e94e888b96d29e upstream.
The OPP structure must not be used out of the rcu protected section.
Cache the values to be used in separate variables instead.Signed-off-by: Viresh Kumar
Reviewed-by: Stephen Boyd
Tested-by: Dave Gerlach
Signed-off-by: Rafael J. Wysocki
Signed-off-by: Greg Kroah-Hartman -
commit 91291d9ad92faa65a56a9a19d658d8049b78d3d4 upstream.
Joonyoung Shim reported an interesting problem on his ARM octa-core
Odoroid-XU3 platform. During system suspend, dev_pm_opp_put_regulator()
was failing for a struct device for which dev_pm_opp_set_regulator() is
called earlier.This happened because an earlier call to
dev_pm_opp_of_cpumask_remove_table() function (from cpufreq-dt.c file)
removed all the entries from opp_table->dev_list apart from the last CPU
device in the cpumask of CPUs sharing the OPP.But both dev_pm_opp_set_regulator() and dev_pm_opp_put_regulator()
routines get CPU device for the first CPU in the cpumask. And so the OPP
core failed to find the OPP table for the struct device.This patch attempts to fix this problem by returning a pointer to the
opp_table from dev_pm_opp_set_regulator() and using that as the
parameter to dev_pm_opp_put_regulator(). This ensures that the
dev_pm_opp_put_regulator() doesn't fail to find the opp table.Note that similar design problem also exists with other
dev_pm_opp_put_*() APIs, but those aren't used currently by anyone and
so we don't need to update them for now.Reported-by: Joonyoung Shim
Signed-off-by: Stephen Boyd
Signed-off-by: Viresh Kumar
[ Viresh: Wrote commit log and tested on exynos 5250 ]
Signed-off-by: Rafael J. Wysocki
Signed-off-by: Greg Kroah-Hartman
11 Nov, 2016
1 commit
-
Consider two devices, A and B, where B is a child of A, and B utilizes
asynchronous suspend (it does not matter whether A is sync or async). If
B fails to suspend_noirq() or suspend_late(), or is interrupted by a
wakeup (pm_wakeup_pending()), then it aborts and sets the async_error
variable. However, device A does not (immediately) check the async_error
variable; it may continue to run its own suspend_noirq()/suspend_late()
callback. This is bad.We can resolve this problem by doing our error and wakeup checking
(particularly, for the async_error flag) after waiting for children to
suspend, instead of before. This also helps align the logic for the noirq and
late suspend cases with the logic in __device_suspend().It's easy to observe this erroneous behavior by, for example, forcing a
device to sleep a bit in its suspend_noirq() (to ensure the parent is
waiting for the child to complete), then return an error, and watch the
parent suspend_noirq() still get called. (Or similarly, fake a wakeup
event at the right (or is it wrong?) time.)Fixes: de377b397272 (PM / sleep: Asynchronous threads for suspend_late)
Fixes: 28b6fd6e3779 (PM / sleep: Asynchronous threads for suspend_noirq)
Reported-by: Jeffy Chen
Signed-off-by: Brian Norris
Signed-off-by: Rafael J. Wysocki
02 Oct, 2016
2 commits
-
* pm-cpuidle:
ARM: cpuidle: Fix error return code* pm-opp:
PM / OPP: Don't support OPP if it provides supported-hw but platform does not
PM / OPP: avoid maybe-uninitialized warning* pm-avs:
PM / AVS: SmartReflex: Neaten logging -
* pm-domains:
PM / Domains: Rename pm_genpd_sync_poweron|poweroff()
PM / Domains: Don't measure latency of ->power_on|off() during system PM
PM / Domains: Remove redundant system PM callbacks
PM / Domains: Simplify detaching a device from its genpd
PM / Domains: Allow holes in genpd_data.domains array
PM / Domains: Add support for removing nested PM domains by provider
PM / Domains: Add support for removing PM domains
PM / Domains: Store the provider in the PM domain structure
PM / Domains: Prepare for adding support to remove PM domains
PM / Domains: Verify the PM domain is present when adding a provider
PM / Domains: Don't expose xlate and provider helper functions
PM / Domains: Don't expose generic_pm_domain structure to clients
staging: board: Remove calls to of_genpd_get_from_provider()
ARM: EXYNOS: Remove calls to of_genpd_get_from_provider()
PM / Domains: Add new helper functions for device-tree
PM / Domains: Always enable debugfs support if available
26 Sep, 2016
1 commit
-
The OPP framework allows each OPP to set a opp-supported-hw property
which provides values that are matched against supported_hw values
provided by the platform to limit support for certain OPPs on specific
hardware. Currently, if the platform does not set supported_hw values,
all OPPs are interpreted as supported, even if they have provided their
own opp-supported-hw values.If an OPP has provided opp-supported-hw, it is indicating that there is
some specific hardware configuration it is supported by. These constraints
should be honored, and if no supported_hw has been provided by the
platform, there is no way to determine if that OPP is actually supported,
so it should be marked as not supported.Signed-off-by: Dave Gerlach
Acked-by: Viresh Kumar
Signed-off-by: Rafael J. Wysocki
24 Sep, 2016
4 commits
-
These are internal static functions to genpd. Let's conform to the naming
rules, by dropping the "pm_" prefix from these.Signed-off-by: Ulf Hansson
Signed-off-by: Rafael J. Wysocki -
Measure latency does by itself contribute to an increased latency, thus we
should avoid it when it isn't needed.Currently genpd measures latencies in the system PM phase for the
->power_on|off() callbacks, except in the syscore case when it's not
allowed to use ktime_get() as timekeeping may be suspended.Since there should be plenty of occasions during runtime PM to perform
these measurements, let's rely on that and drop them from system PM. This
will also make it consistent for how measurements are done of the runtime
PM callbacks (as those may be invoked during system PM).Signed-off-by: Ulf Hansson
Signed-off-by: Rafael J. Wysocki -
In cases when the PM domain haven't assigned a system PM callback, the PM
core fall-backs to check for the callback at the driver level instead.
This makes it redundant to assign a pm_generic_* helper function to a
corresponding system PM callback at a PM domain level.Therefore, let's remove these assignments in pm_genpd_init().
Signed-off-by: Ulf Hansson
Signed-off-by: Rafael J. Wysocki -
There's no need to validate the PM domain by using genpd_lookup_dev() when
removing the device via genpd's genpd_dev_pm_detach() function. That's
because this function can't be called, unless there is a valid PM domain
for the device.To simplify the behaviour, let's move code from pm_genpd_remove_device()
into a new internal function, genpd_remove_device(), which is called from
pm_genpd_remove_device() and genpd_dev_pm_detach().Signed-off-by: Ulf Hansson
Reviewed-by: Lina Iyer
Signed-off-by: Rafael J. Wysocki
17 Sep, 2016
2 commits
-
When CONFIG_OPTIMIZE_INLINING is set and we are building with -Wmaybe-uninitialized
enabled, we can get a warning for the opp core driver:drivers/base/power/opp/core.c: In function 'dev_pm_opp_set_rate':
drivers/base/power/opp/core.c:560:8: warning: 'ou_volt_min' may be used uninitialized in this function [-Wmaybe-uninitialized]This has only now appeared as a result of commit 797da5598f3a ("PM / devfreq:
Add COMPILE_TEST for build coverage"), which makes the driver visible in
some configurations that didn't have it before.The warning is a false positive that I got with gcc-6.1.1, but there is
a simple workaround in removing the local variables that we get warnings
for (all three are affected depending on the configuration). This also
makes the code easier to read.Signed-off-by: Arnd Bergmann
Reviewed-by: Stephen Boyd
Acked-by: Viresh Kumar
Signed-off-by: Rafael J. Wysocki -
In platforms such as Rockchip's, the array of domains isn't always
filled without holes, as which domains are present depend on the
particular SoC revision.By allowing holes to be in the array, such SoCs can still use a single
set of constants to index the array of power domains.Fixes: 0159ec670763 (PM / Domains: Verify the PM domain is present when adding a provider)
Signed-off-by: Tomeu Vizoso
Acked-by: Jon Hunter
Acked-by: Ulf Hansson
Reviewed-by: Heiko Stuebner
Tested-by: Heiko Stuebner
Acked-by: Kevin Hilman
Signed-off-by: Rafael J. Wysocki
16 Sep, 2016
1 commit
-
Further testing with false negatives suppressed by commit 293e2421fe25
("rcu: Remove superfluous versions of rcu_read_lock_sched_held()")
identified a few more unprotected uses of RCU from the idle loop.
Because RCU actively ignores idle-loop code (for energy-efficiency
reasons, among other things), using RCU from the idle loop can result
in too-short grace periods, in turn resulting in arbitrary misbehavior.The affected function is rpm_suspend().
The resulting lockdep-RCU splat is as follows:
------------------------------------------------------------------------
Warning from omap3
===============================
[ INFO: suspicious RCU usage. ]
4.6.0-rc5-next-20160426+ #1112 Not tainted
-------------------------------
include/trace/events/rpm.h:63 suspicious rcu_dereference_check() usage!other info that might help us debug this:
RCU used illegally from idle CPU!
rcu_scheduler_active = 1, debug_locks = 0
RCU used illegally from extended quiescent state!
1 lock held by swapper/0/0:
#0: (&(&dev->power.lock)->rlock){-.-...}, at: [] __pm_runtime_suspend+0x54/0x84stack backtrace:
CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.6.0-rc5-next-20160426+ #1112
Hardware name: Generic OMAP36xx (Flattened Device Tree)
[] (unwind_backtrace) from [] (show_stack+0x10/0x14)
[] (show_stack) from [] (dump_stack+0xb0/0xe4)
[] (dump_stack) from [] (rpm_suspend+0x604/0x7e4)
[] (rpm_suspend) from [] (__pm_runtime_suspend+0x64/0x84)
[] (__pm_runtime_suspend) from [] (omap2_gpio_prepare_for_idle+0x5c/0x70)
[] (omap2_gpio_prepare_for_idle) from [] (omap_sram_idle+0x140/0x244)
[] (omap_sram_idle) from [] (omap3_enter_idle_bm+0xfc/0x1ec)
[] (omap3_enter_idle_bm) from [] (cpuidle_enter_state+0x80/0x3d4)
[] (cpuidle_enter_state) from [] (cpu_startup_entry+0x198/0x3a0)
[] (cpu_startup_entry) from [] (start_kernel+0x354/0x3c8)
[] (start_kernel) from [] (0x8000807c)------------------------------------------------------------------------
Reported-by: Tony Lindgren
Signed-off-by: Paul E. McKenney
Tested-by: Tony Lindgren
Tested-by: Guenter Roeck
[ rjw: Subject ]
Signed-off-by: Rafael J. Wysocki
13 Sep, 2016
8 commits
-
If a device supports PM domains that are subdomains of another PM
domain, then the PM domains should be removed in reverse order to
ensure that the subdomains are removed first. Furthermore, if there is
more than one provider, then there needs to be a way to remove the
domains in reverse order for a specific provider.Add the function of_genpd_remove_last() to remove the last PM domain
added by a given PM domain provider and return the generic_pm_domain
structure for the PM domain that was removed.Signed-off-by: Jon Hunter
Acked-by: Ulf Hansson
Signed-off-by: Rafael J. Wysocki -
The genpd framework allows users to add PM domains via the pm_genpd_init()
function, however, there is no corresponding function to remove a PM
domain. For most devices this may be fine as the PM domains are never
removed, however, for devices that wish to populate the PM domains from
within a driver, having the ability to remove a PM domain if the probing
of the device fails or the driver is unloaded is necessary.Add the function pm_genpd_remove() to remove a PM domain by referencing
it's generic_pm_domain structure. Note that the bulk of the code that
removes the PM domain is placed in a separate local function
genpd_remove() (which is called by pm_genpd_remove()). The code is
structured in this way to prepare for adding another function to remove
a PM domain by provider that will also call genpd_remove(). Note that
users of genpd_remove() must call this function with the mutex,
gpd_list_lock, held.PM domains can only be removed if the associated provider has been
removed, they are not a parent domain to another PM domain and have no
devices associated with them.Signed-off-by: Jon Hunter
Acked-by: Ulf Hansson
Signed-off-by: Rafael J. Wysocki -
It is possible that a device has more than one provider of PM domains
and to support the removal of a PM domain by provider, it is necessary
to store a reference to the provider in the PM domain structure.
Therefore, store a reference to the firmware node handle in the PM
domain structure and populate it when providers (only device-tree based
providers are currently supported by PM domains) are registered.Please note that when removing PM domains, it is necessary to verify
that the PM domain provider has been removed from the list of providers
before the PM domain can be removed. To do this add another member to
the PM domain structure that indicates if the provider is present and
set this member accordingly when providers are added and removed.Initialise the 'provider' and 'has_provider' members of the
generic_pm_domain structure when a PM domains is added by calling
pm_genpd_init().Signed-off-by: Jon Hunter
Acked-by: Ulf Hansson
Signed-off-by: Rafael J. Wysocki -
In order to remove PM domains safely from the list of PM domains,
it is necessary to adding locking for the PM domain list around any
places where devices or subdomains are added to a PM domain.There are places where a reference to a PM domain is obtained via
calling of_genpd_get_from_provider() before adding the device or the
subdomain. In these cases a lock for the PM domain list needs to be
held around the call to of_genpd_get_from_provider() and the call to
add the device/subdomain. To avoid deadlocks by multiple attempts to
obtain the PM domain list lock, add functions genpd_add_device() and
genpd_add_subdomain() which require the user to hold the PM domain
list lock when calling.Signed-off-by: Jon Hunter
Acked-by: Ulf Hansson
Signed-off-by: Rafael J. Wysocki -
When a PM domain provider is added, there is currently no way to tell if
any PM domains associated with the provider are present. Naturally, the
PM domain provider should not be registered if the PM domains have not
been added. Nonetheless, verify that the PM domain(s) associated with a
provider are present when registering the PM domain provider.This change adds a dependency on the function pm_genpd_present() when
CONFIG_PM_GENERIC_DOMAINS_OF is enabled and so ensure this function is
available when CONFIG_PM_GENERIC_DOMAINS_OF selected.Signed-off-by: Jon Hunter
Acked-by: Ulf Hansson
Signed-off-by: Rafael J. Wysocki -
Functions __of_genpd_xlate_simple(), __of_genpd_xlate_onecell() and
__of_genpd_add_provider() are not used outside of the core generic PM
domain code. Therefore, reduce the number of APIs exposed by making
these static. At the same time don't expose the typedef for
genpd_xlate_t either and make this a local definition as well.The functions are renamed to follow the naming conventions for static
functions in the generic PM domain core.Signed-off-by: Jon Hunter
Acked-by: Ulf Hansson
Signed-off-by: Rafael J. Wysocki -
There should be no need to expose the generic_pm_domain structure to
clients and this eliminates the need to implement reference counting for
any external reference to a PM domain. Therefore, make the functions
pm_genpd_lookup_dev() and of_genpd_get_from_provider() private to the
PM domain core. The functions are renamed in accordance with the naming
conventions for genpd static functions.Signed-off-by: Jon Hunter
Acked-by: Ulf Hansson
Signed-off-by: Rafael J. Wysocki -
Ideally, if we are returning a reference to a PM domain via a call to
of_genpd_get_from_provider(), then we should keep track of such
references via a reference count. The reference count could then be used
to determine if a PM domain can be safely removed. Alternatively, it is
possible to avoid such external references by providing APIs to access
the PM domain and hence, eliminate any calls to
of_genpd_get_from_provider().Add new helper functions for adding a device and a subdomain to a PM
domain when using device-tree, so that external calls to
of_genpd_get_from_provider() can be removed.Signed-off-by: Jon Hunter
Acked-by: Ulf Hansson
Signed-off-by: Rafael J. Wysocki
31 Aug, 2016
2 commits
-
This commit appends a few _rcuidle suffixes to fix the following
RCU-used-from-idle bug:> ===============================
> [ INFO: suspicious RCU usage. ]
> 4.6.0-rc5-next-20160426+ #1116 Not tainted
> -------------------------------
> include/trace/events/rpm.h:95 suspicious rcu_dereference_check() usage!
>
> other info that might help us debug this:
>
>
> RCU used illegally from idle CPU!
> rcu_scheduler_active = 1, debug_locks = 0
> RCU used illegally from extended quiescent state!
> 1 lock held by swapper/0/0:
> #0: (&(&dev->power.lock)->rlock){-.-...}, at: [] __rpm_callback+0x58/0x60
>
> stack backtrace:
> CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.6.0-rc5-next-20160426+ #1116
> Hardware name: Generic OMAP36xx (Flattened Device Tree)
> [] (unwind_backtrace) from [] (show_stack+0x10/0x14)
> [] (show_stack) from [] (dump_stack+0xb0/0xe4)
> [] (dump_stack) from [] (rpm_suspend+0x580/0x768)
> [] (rpm_suspend) from [] (__pm_runtime_suspend+0x64/0x84)
> [] (__pm_runtime_suspend) from [] (omap2_gpio_prepare_for_idle+0x5c/0x70)
> [] (omap2_gpio_prepare_for_idle) from [] (omap_sram_idle+0x140/0x244)
> [] (omap_sram_idle) from [] (omap3_enter_idle_bm+0xfc/0x1ec)
> [] (omap3_enter_idle_bm) from [] (cpuidle_enter_state+0x80/0x3d4)
> [] (cpuidle_enter_state) from [] (cpu_startup_entry+0x198/0x3a0)
> [] (cpu_startup_entry) from [] (start_kernel+0x354/0x3c8)
> [] (start_kernel) from [] (0x8000807c)In the immortal words of Steven Rostedt, "*Whack* *Whack* *Whack*!!!"
Reported-by: Tony Lindgren
Signed-off-by: Paul E. McKenney
Tested-by: Tony Lindgren
Tested-by: Guenter Roeck
WhACKED-by: Steven Rostedt
Signed-off-by: Rafael J. Wysocki -
This commit applies another _rcuidle suffix to fix an RCU use from
idle.> ===============================
> [ INFO: suspicious RCU usage. ]
> 4.6.0-rc5-next-20160426+ #1122 Not tainted
> -------------------------------
> include/trace/events/rpm.h:69 suspicious rcu_dereference_check() usage!
>
> other info that might help us debug this:
>
>
> RCU used illegally from idle CPU!
> rcu_scheduler_active = 1, debug_locks = 0
> RCU used illegally from extended quiescent state!
> 1 lock held by swapper/0/0:
> #0: (&(&dev->power.lock)->rlock){-.-...}, at: [] __pm_runtime_resume+0x3c/0x64
>
> stack backtrace:
> CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.6.0-rc5-next-20160426+ #1122
> Hardware name: Generic OMAP36xx (Flattened Device Tree)
> [] (unwind_backtrace) from [] (show_stack+0x10/0x14)
> [] (show_stack) from [] (dump_stack+0xb0/0xe4)
> [] (dump_stack) from [] (rpm_resume+0x5cc/0x7f4)
> [] (rpm_resume) from [] (__pm_runtime_resume+0x4c/0x64)
> [] (__pm_runtime_resume) from [] (omap2_gpio_resume_after_idle+0x54/0x68)
> [] (omap2_gpio_resume_after_idle) from [] (omap3_enter_idle_bm+0xfc/0x1ec)
> [] (omap3_enter_idle_bm) from [] (cpuidle_enter_state+0x80/0x3d4)
> [] (cpuidle_enter_state) from [] (cpu_startup_entry+0x198/0x3a0)
> [] (cpu_startup_entry) from [] (start_kernel+0x354/0x3c8)
> [] (start_kernel) from [] (0x8000807c)Reported-by: Tony Lindgren
Signed-off-by: Paul E. McKenney
Tested-by: Tony Lindgren
Tested-by: Guenter Roeck
Signed-off-by: Rafael J. Wysocki
12 Aug, 2016
1 commit
-
Debugfs support for PM domains is only enabled if both CONFIG_PM_DEBUG
and CONFIG_PM_ADVANCED_DEBUG are enabled. CONFIG_PM_ADVANCED_DEBUG is
described as "extra PM attributes in sysfs for low-level
debugging/testing" which does not seem related.Given that the debugfs for PM domains only allows users to view the
state of the PM domains, always enable debugfs support for PM domains
if PM domains and debugfs support is enabled.Signed-off-by: Jon Hunter
Acked-by: Geert Uytterhoeven
Signed-off-by: Rafael J. Wysocki
06 Aug, 2016
1 commit
-
Pull more power management updates from Rafael Wysocki:
"A few more fixes and cleanups in the x86-64 low-level hibernation
code, PM core, cpufreq (Kconfig and intel_pstate), and the operating
points framework.Specifics:
- Prevent the low-level assembly hibernate code on x86-64 from
referring to __PAGE_OFFSET directly as a symbol which doesn't work
when the kernel identity mapping base is randomized, in which case
__PAGE_OFFSET is a variable (Rafael Wysocki).- Avoid selecting CPU_FREQ_STAT by default as the statistics are not
required for proper cpufreq operation (Borislav Petkov).- Add Skylake-X and Broadwell-X IDs to the intel_pstate's list of
processors where out-of-band (OBB) control of P-states is possible
and if that is in use, intel_pstate should not attempt to manage
P-states (Srinivas Pandruvada).- Drop some unnecessary checks from the wakeup IRQ handling code in
the PM core (Markus Elfring).- Reduce the number operating performance point (OPP) lookups in one
of the OPP framework's helper functions (Jisheng Zhang)"* tag 'pm-extra-4.8-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm:
x86/power/64: Do not refer to __PAGE_OFFSET from assembly code
cpufreq: Do not default-yes CPU_FREQ_STAT
cpufreq: intel_pstate: Add more out-of-band IDs
PM / OPP: optimize dev_pm_opp_set_rate() performance a bit
PM-wakeup: Delete unnecessary checks before three function calls
05 Aug, 2016
2 commits
-
Pull RTC updates from Alexandre Belloni:
"RTC for 4.8Cleanups:
- huge cleanup of rtc-generic and char/genrtc this allowed to cleanup
rtc-cmos, rtc-sh, rtc-m68k, rtc-powerpc and rtc-parisc
- move mn10300 to rtc-cmosSubsystem:
- fix wakealarms after hibernate
- multiples fixes for rctest
- simplify implementations of .read_alarmNew drivers:
- Maxim MAX6916Drivers:
- ds1307: fix weekday
- m41t80: add wakeup support
- pcf85063: add support for PCF85063A variant
- rv8803: extend i2c fix and other fixes
- s35390a: fix alarm reading, this fixes instant reboot after
shutdown for QNAP TS-41x
- s3c: clock fixes"* tag 'rtc-4.8' of git://git.kernel.org/pub/scm/linux/kernel/git/abelloni/linux: (65 commits)
rtc: rv8803: Clear V1F when setting the time
rtc: rv8803: Stop the clock while setting the time
rtc: rv8803: Always apply the I²C workaround
rtc: rv8803: Fix read day of week
rtc: rv8803: Remove the check for valid time
rtc: rv8803: Kconfig: Indicate rx8900 support
rtc: asm9260: remove .owner field for driver
rtc: at91sam9: Fix missing spin_lock_init()
rtc: m41t80: add suspend handlers for alarm IRQ
rtc: m41t80: make it a real error message
rtc: pcf85063: Add support for the PCF85063A device
rtc: pcf85063: fix year range
rtc: hym8563: in .read_alarm set .tm_sec to 0 to signal minute accuracy
rtc: explicitly set tm_sec = 0 for drivers with minute accurancy
rtc: s3c: Add s3c_rtc_{enable/disable}_clk in s3c_rtc_setfreq()
rtc: s3c: Remove unnecessary call to disable already disabled clock
rtc: abx80x: use devm_add_action_or_reset()
rtc: m41t80: use devm_add_action_or_reset()
rtc: fix a typo and reduce three empty lines to one
rtc: s35390a: improve two comments in .set_alarm
... -
* pm-sleep:
x86/power/64: Do not refer to __PAGE_OFFSET from assembly code* pm-cpufreq:
cpufreq: Do not default-yes CPU_FREQ_STAT
cpufreq: intel_pstate: Add more out-of-band IDs* pm-core:
PM-wakeup: Delete unnecessary checks before three function calls* pm-opp:
PM / OPP: optimize dev_pm_opp_set_rate() performance a bit
29 Jul, 2016
2 commits
-
In dev_pm_opp_set_rate(), _find_opp_table() is called 4 times: once by
_get_opp_clk(), once by dev_pm_opp_set_rate() itself, and twice by
dev_pm_opp_find_freq_ceil(). If there are several opp_tables in the
system, three times of opp table finding is a big waste. This patch
reduced the call of _find_opp_table() to twice.Signed-off-by: Jisheng Zhang
Acked-by: Viresh Kumar
Signed-off-by: Rafael J. Wysocki -
The following functions test whether their argument is NULL
and then return immediately.
* dev_pm_arm_wake_irq
* dev_pm_disarm_wake_irq
* wakeup_source_unregisterThus the test around the calls is not needed.
This issue was detected by using the Coccinelle software.
Signed-off-by: Markus Elfring
Acked-by: Pavel Machek
[ rjw: Minor whitespace adjustments ]
Signed-off-by: Rafael J. Wysocki
25 Jul, 2016
1 commit
-
* pm-core:
PM / runtime: Asynchronous "idle" in pm_runtime_allow()
PM / runtime: print error when activating a child to unactive parent* pm-clk:
PM / clk: Add support for adding a specific clock from device-tree
PM / clk: export symbols for existing pm_clk_ API fcns* pm-domains:
PM / Domains: Convert pm_genpd_init() to return an error code
PM / Domains: Stop/start devices during system PM suspend/resume in genpd
PM / Domains: Allow runtime PM during system PM phases
PM / Runtime: Avoid resuming devices again in pm_runtime_force_resume()
PM / Domains: Remove redundant pm_request_idle() call in genpd
PM / Domains: Remove redundant wrapper functions for system PM
PM / Domains: Allow genpd to power on during system PM phases* pm-pci:
PCI / PM: check all fields in pci_set_platform_pm()
02 Jul, 2016
1 commit
-
Arjan reports that it takes a relatively long time to enable runtime
PM for multiple devices at system startup, because all writes to the
"control" attribute in sysfs are handled synchronously and if the
device is suspended as a result of the write, it will block until
that operation is complete.That may be avoided by passing the RPM_ASYNC flag to rpm_idle()
in pm_runtime_allow() which will make it execute the device's
"idle" callback asynchronously, so writes to "control" changing
it from "on" to "auto" will return without waiting.Reported-by: Arjan van de Ven
Signed-off-by: Rafael J. Wysocki
Acked-by: Alan Stern
Reviewed-by: Ulf Hansson
Reviewed-by: Kevin Hilman
29 Jun, 2016
1 commit
-
The are already cases when pm_genpd_init() can fail. Currently we hide the
failures instead of propagating an error code, which is a better method.Moreover, to prepare for future changes like moving away from using a
fixed array-size of the struct genpd_power_state, to instead dynamically
allocate data for it, the pm_genpd_init() API needs to be able to return
an error code, as allocation can fail.Current users of the pm_genpd_init() is thus requested to start dealing
with error codes. In the transition phase, users will have to live with
only error messages being printed to log.Signed-off-by: Ulf Hansson
Acked-by: Kevin Hilman
Signed-off-by: Rafael J. Wysocki
28 Jun, 2016
2 commits
-
Some drivers using the PM clocks framework need to add specific clocks
from device-tree using a name by calling the functions
of_clk_get_by_name() and then pm_clk_add_clk(). Rather than having
drivers call both functions, add a helper function of_pm_clk_add_clk()
that will call these functions so drivers can call a single function
to add a specific clock from device-tree.Signed-off-by: Jon Hunter
Signed-off-by: Rafael J. Wysocki -
The code currently silently bails out with -EBUSY if you try to
activate a child to an inactive parent.This typically happens when you have a runtime suspended parent
and runtime resume your child, but forgot to set .ignore_children
on the parent to true with pm_suspend_ignore_children(dev).Silently ignoring this error is not good as it gives rise to
other strange behaviour like double-resume of devices after
silently bailing out of the .runtime_resume() callback.Signed-off-by: Linus Walleij
Signed-off-by: Rafael J. Wysocki
18 Jun, 2016
1 commit
-
* pm-opp:
PM / OPP: Add 'UNKNOWN' status for shared_opp in struct opp_table* pm-cpufreq-fixes:
cpufreq: intel_pstate: Adjust _PSS[0] freqeuency if needed
16 Jun, 2016
2 commits
-
dev_pm_opp_get_sharing_cpus() returns 0 even in the case when the OPP
core doesn't know whether or not the table is shared. It works on the
majority of platforms, where the OPP table is never created before
invoking the function and then -ENODEV is returned by it.But in the case of one platform (Jetson TK1) at least, the situation
is a bit different. The OPP table has been created (somehow) before
dev_pm_opp_get_sharing_cpus() is called and it returns 0. Its caller
treats that as 'the CPUs don't share OPPs' and that leads to degraded
performance.Fix this by converting 'shared_opp' in struct opp_table to an enum
and making dev_pm_opp_get_sharing_cpus() return -EINVAL in case when
the value of that field is "access unknown", so that the caller can
handle it accordingly (cpufreq-dt considers that as 'all CPUs share
the table', for example).Fixes: 6f707daa3833 "PM / OPP: Add dev_pm_opp_get_sharing_cpus()"
Reported-and-tested-by: Alexandre Courbot
Signed-off-by: Viresh Kumar
[ rjw : Subject & changelog ]
Signed-off-by: Rafael J. Wysocki -
Not all subsystems/drivers that manages devices attached to a genpd
makes use of the pm_runtime_force_suspend|resume() helper functions
to deal with system PM suspend/resume.In cases like these and when genpd's ->stop|start() callbacks are
used for the device, invoke the pm_runtime_force_suspend|resume()
helper functions from genpd's "noirq" system PM callbacks. In this
way we make sure to "stop" the device on suspend and to "start" it
on resume.Signed-off-by: Ulf Hansson
Reviewed-by: Kevin Hilman
Signed-off-by: Rafael J. Wysocki