PM / devfreq: Fix simple_ondemand crashing

Signed-off-by: Pranav Vashi <neobuddy89@gmail.com>
PM: devfreq: Fix show available freqs

Signed-off-by: Pranav Vashi <neobuddy89@gmail.com>
lib: devres: Introduce devm_ioremap_resource()

The devm_request_and_ioremap() function is very useful and helps avoid a
whole lot of boilerplate. However, one issue that keeps popping up is
its lack of a specific error code to determine which of the steps that
it performs failed. Furthermore, while the function gives an example and
suggests what error code to return on failure, a wide variety of error
codes are used throughout the tree.

In an attempt to fix these problems, this patch adds a new function that
drivers can transition to. The devm_ioremap_resource() returns a pointer
to the remapped I/O memory on success or an ERR_PTR() encoded error code
on failure. Callers can check for failure using IS_ERR() and determine
its cause by extracting the error code using PTR_ERR().

devm_request_and_ioremap() is implemented as a wrapper around the new
API and return NULL on failure as before. This ensures that backwards
compatibility is maintained until all users have been converted to the
new API, at which point the old devm_request_and_ioremap() function
should be removed.

A semantic patch is included which can be used to convert from the old
devm_request_and_ioremap() API to the new devm_ioremap_resource() API.
Some non-trivial cases may require manual intervention, though.

Signed-off-by: Thierry Reding <thierry.reding@avionic-design.de>
Cc: Arnd Bergmann <arnd@arndb.de>
Acked-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Dolev Raviv <draviv@codeaurora.org>
Signed-off-by: Pranav Vashi <neobuddy89@gmail.com>
lib: spinlock_debug: increase spin dump timeout

On certain targets the worst case console buffer draining time can
exceed the aggressive spin dump timeout value. Relax the timeout value
to cater to these scenarios.

Signed-off-by: Syed Rameez Mustafa <rameezmustafa@codeaurora.org>
Signed-off-by: Pranav Vashi <neobuddy89@gmail.com>
tracing/sched: add load balancer tracepoint

When doing performance analysis it can be useful to see exactly
what is going on with the load balancer - when it runs and why
exactly it may not be redistributing load.

This additional tracepoint will show the idle context of the
load balance operation (idle, not idle, newly idle), various
values from the load balancing operation, the final result,
and the new balance interval.

Signed-off-by: Steve Muckle <smuckle@codeaurora.org>
Signed-off-by: Pranav Vashi <neobuddy89@gmail.com>
block: deadline: Optimize for non-rotational

Signed-off-by: Pranav Vashi <neobuddy89@gmail.com>
deadline: Allow 0ms deadline latency, increase the read speed

Change a timer compare from after to after-equals, thus allowing
0 timeout and making deadline schedule FIFO.

Signed-off-by: xiaobing tu <xiaobing.tu@intel.com>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
Signed-off-by: Pranav Vashi <neobuddy89@gmail.com>
timekeeping: utilize the suspend-nonstop clocksource to count suspended time

There are some new processors whose TSC clocksource won't stop during
suspend. Currently, after system resumes, kernel will use persistent
clock or RTC to compensate the sleep time, but with these nonstop
clocksources, we could skip the special compensation from external
sources, and just use current clocksource for time recounting.

This can solve some time drift bugs caused by some not-so-accurate or
error-prone RTC devices.

The current way to count suspended time is first try to use the persistent
clock, and then try the RTC if persistent clock can't be used. This
patch will change the trying order to:
	suspend-nonstop clocksource -> persistent clock -> RTC

When counting the sleep time with nonstop clocksource, use an accurate way
suggested by Jason Gunthorpe to cover very large delta cycles.

Signed-off-by: Feng Tang <feng.tang@intel.com>
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
Signed-off-by: Pranav Vashi <neobuddy89@gmail.com>
clocksource: Add new feature flag CLOCK_SOURCE_SUSPEND_NONSTOP

Some x86 processors have a TSC clocksource, which continues to run
even when system is suspended. Also most OMAP platforms have a
32 KHz timer which has similar capability. Add a feature flag so that
it could be utilized.

Signed-off-by: Feng Tang <feng.tang@intel.com>
Signed-off-by: John Stultz <john.stultz@linaro.org>
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
Signed-off-by: Pranav Vashi <neobuddy89@gmail.com>
clocksource: arm_arch_timer: Use clocksource for suspend timekeeping

The ARM architected timers keep counting during suspend so we can
mark this clocksource with the CLOCK_SOURCE_SUSPEND_NONSTOP. This
flag will indicate that this clocksource can be used for
calculating suspend time and injecting sleep time into the
timekeeping core. This will usually be more accurate than using
an external RTC or architecture specific persistent clock.

Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
Signed-off-by: Pranav Vashi <neobuddy89@gmail.com>
msm: pm-8x60: Fix suspend time tracking

Calls to sched_clock() after syscore devices have been suspend
will return the same value until the syscored devices are
resumed. Furthermore, the value won't jump forward to account for
the time left in suspend so we can't use it to calculate how much
time we spent in suspend.

We could expose the hardware directly to the pm code but it's
better to use generic interfaces. Move to using the timekeeping
APIs to determine how long we were in suspend. Unfortunately, we
can't use the timekeeping APIs this early in the resume path, so
we must read the current time of day before we suspend the
timekeeping core and after we resume the timekeeping core. Move
the calls to the suspend_late() and wake() callbacks so we can
properly read the amount of suspend time.

Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
Signed-off-by: Pranav Vashi <neobuddy89@gmail.com>