PM / Sleep: introduce dpm_for_each_dev

dpm_list and its pm lock provide a good way to iterate all
devices in system. Except this way, there is no other easy
way to iterate devices in system.

firmware loader need to cache firmware images for devices
before system sleep, so introduce the function to meet its
demand.

Reported-by: Fengguang Wu <fengguang.wu@intel.com>
Signed-off-by: Ming Lei <ming.lei@canonical.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
PM / Domains: Rename the always_on device flag to syscore

The always_on device flag is used to mark the devices (belonging to
a PM domain) that should never be turned off, except for the system
core (syscore) suspend/hibernation and resume stages.  Change name
of that flag to "syscore" to better reflect its purpose.

Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Acked-by: Magnus Damm <damm@opensource.se>
PM / Domains: Move syscore flag from subsys data to struct device

The syscore device PM flag is used to mark the devices (belonging to
a PM domain) that should never be turned off, except for the system
core (syscore) suspend/hibernation and resume stages.  That flag is
stored in the device's struct pm_subsys_data object whose address is
available from struct device.  However, in some situations it may be
convenient to set that flag before the device is added to a PM
domain, so it is better to move it directly to the "power" member of
struct device.  Then, it can be checked by the routines in
drivers/base/power/runtime.c and drivers/base/power/main.c, which is
more straightforward.

This also reduces the number of dev_gpd_data() invocations in the
generic PM domains framework, so the overhead related to the syscore
flag is slightly smaller.

Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Acked-by: Magnus Damm <damm@opensource.se>
PM: Move disabling/enabling runtime PM to late suspend/early resume

Currently, the PM core disables runtime PM for all devices right
after executing subsystem/driver .suspend() callbacks for them
and re-enables it right before executing subsystem/driver .resume()
callbacks for them.  This may lead to problems when there are
two devices such that the .suspend() callback executed for one of
them depends on runtime PM working for the other.  In that case,
if runtime PM has already been disabled for the second device,
the first one's .suspend() won't work correctly (and analogously
for resume).

To make those issues go away, make the PM core disable runtime PM
for devices right before executing subsystem/driver .suspend_late()
callbacks for them and enable runtime PM for them right after
executing subsystem/driver .resume_early() callbacks for them.  This
way the potential conflitcs between .suspend_late()/.resume_early()
and their runtime PM counterparts are still prevented from happening,
but the subtle ordering issues related to disabling/enabling runtime
PM for devices during system suspend/resume are much easier to avoid.

Reported-and-tested-by: Jan-Matthias Braun <jan_braun@gmx.net>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: Ulf Hansson <ulf.hansson@linaro.org>
Reviewed-by: Kevin Hilman <khilman@deeprootsystems.com>
Cc: 3.4+ <stable@vger.kernel.org>
PM / Runtime: Asyncronous idle|suspend devices at system resume

Use the asyncronous runtime PM API when returning the runtime
reference for the device after the system resume is completed.

By using the asyncronous runtime PM API we don't have to wait
for each an every device to become idle|suspended. Instead we
can move on and handle the next device in queue.

Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
PM: Add watchdog to catch lockup during device resume

Refactor the dpm suspend watchdog code and add watchdogs
on resume too. The dpm wachdog prints the stack trace and
reboots the system if a device takes more than 12 seconds
to suspend or resume.

Change-Id: If00c047a17b80bdc13a8426393c698bc450a7347
Signed-off-by: Benoit Goby <benoit@android.com>

Conflicts:
	drivers/base/power/main.c
genirq: Allow forcing cpu affinity of interrupts

The current implementation of irq_set_affinity() refuses rightfully to
route an interrupt to an offline cpu.

But there is a special case, where this is actually desired. Some of
the ARM SoCs have per cpu timers which require setting the affinity
during cpu startup where the cpu is not yet in the online mask.

If we can't do that, then the local timer interrupt for the about to
become online cpu is routed to some random online cpu.

The developers of the affected machines tried to work around that
issue, but that results in a massive mess in that timer code.

We have a yet unused argument in the set_affinity callbacks of the irq
chips, which I added back then for a similar reason. It was never
required so it got not used. But I'm happy that I never removed it.

That allows us to implement a sane handling of the above scenario. So
the affected SoC drivers can add the required force handling to their
interrupt chip, switch the timer code to irq_force_affinity() and
things just work.

This does not affect any existing user of irq_set_affinity().

Tagged for stable to allow a simple fix of the affected SoC clock
event drivers.

Reported-and-tested-by: Krzysztof Kozlowski <k.kozlowski@samsung.com>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Cc: Kyungmin Park <kyungmin.park@samsung.com>
Cc: Marek Szyprowski <m.szyprowski@samsung.com>
Cc: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
Cc: Tomasz Figa <t.figa@samsung.com>,
Cc: Daniel Lezcano <daniel.lezcano@linaro.org>,
Cc: Kukjin Kim <kgene.kim@samsung.com>
Cc: linux-arm-kernel@lists.infradead.org,
Link: http://lkml.kernel.org/r/20140416143315.717251504@linutronix.de
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Kamal Mostafa <kamal@canonical.com>
Signed-off-by: Pranav Vashi <neobuddy89@gmail.com>
ARM: 8133/1: use irq_set_affinity with force=false when migrating irqs

Since commit 1dbfa187dad ("ARM: irq migration: force migration off CPU
going down") the ARM interrupt migration code on cpu offline calls
irqchip.irq_set_affinity() with the argument force=true. At the point
of this change the argument had no effect because it was not used by
any interrupt chip driver and there was no semantics defined.

This changed with commit 01f8fa4f01d8 ("genirq: Allow forcing cpu
affinity of interrupts") which made the force argument useful to route
interrupts to not yet online cpus without checking the target cpu
against the cpu online mask. The following commit ffde1de64012
("irqchip: gic: Support forced affinity setting") implemented this for
the GIC interrupt controller.

As a consequence the ARM cpu offline irq migration fails if CPU0 is
offlined, because CPU0 is still set in the affinity mask and the
validataion against cpu online mask is skipped to the force argument
being true. The following first_cpu(mask) selection always selects
CPU0 as the target.

Solve the issue by calling irq_set_affinity() with force=false from
the CPU offline irq migration code so the GIC driver validates the
affinity mask against CPU online mask and therefore removes CPU0 from
the possible target candidates.

Tested on TC2 hotpluging CPU0 in and out. Without this patch the system
locks up as the IRQs are not migrated away from CPU0.

Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
Acked-by: Thomas Gleixner <tglx@linutronix.de>
Acked-by: Mark Rutland <mark.rutland@arm.com>
Cc: <stable@vger.kernel.org> # 3.10.x
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Signed-off-by: Pranav Vashi <neobuddy89@gmail.com>
kernel/smp.c: quit unconditionally enabling irqs in on_each_cpu_mask().

As in commit f21afc25f9ed ("smp.h: Use local_irq_{save,restore}() in
!SMP version of on_each_cpu()"), we don't want to enable irqs if they
are not already enabled.

I don't know of any bugs currently caused by this unconditional
local_irq_enable(), but I want to use this function in MIPS/OCTEON early
boot (when we have early_boot_irqs_disabled).  This also makes this
function have similar semantics to on_each_cpu() which is good in
itself.

Signed-off-by: David Daney <david.daney@cavium.com>
Cc: Gilad Ben-Yossef <gilad@benyossef.com>
Cc: Christoph Lameter <cl@linux.com>
Cc: Chris Metcalf <cmetcalf@tilera.com>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Pranav Vashi <neobuddy89@gmail.com>
arch: arm: TLB invalidate if power collapse gets aborted

Invalidate entire local TLB in non sharable mode when
power collapse is aborted due to pending interrupt.

Signed-off-by: Anji Jonnala <anjir@codeaurora.org>
Signed-off-by: Venkat Devarasetty <vdevaras@codeaurora.org>
Signed-off-by: Pranav Vashi <neobuddy89@gmail.com>
fix export merge
fixup pm.h
ARM: cleanup undefined instruction entry code

We don't need to keep reloading the thread into into r10 - we can do
this once and keep the value cached in the register.  Also, schedule
some instructions better so that the pipeline doesn't stall after a
load in the neon code.

Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
ARM: mm: Remove unnecessary CMO in Cortex A15 startup

Cortex-A15 flush L2 cache after reset, there is no need to do this
in software, if L2 is already invalidated in bootloader and
cache is disabled. For secondary startup, there is no reason to
flush L2 as well.

This change assumes the setup code is always entered as the result
of CPU reset.

Change-Id: I6d58f8b4a638b70acfb35b97c87a09266aceef41
Signed-off-by: Bo Yan <byan@nvidia.com>
Reviewed-on: http://git-master/r/170563
Reviewed-by: Mrutyunjay Sawant <msawant@nvidia.com>
Tested-by: Mrutyunjay Sawant <msawant@nvidia.com>
ARM: mm: Skip I-cache invalidate for Cortex-A15 boot

This is not required since cache is invalidated by HW in the reset
sequence. Bootloader is supposed to do the same before it hands
over control to kernel.

Change-Id: I0991de3ba1015a32f2c49a0333fd0b17a51a4f31
Signed-off-by: Bo Yan <byan@nvidia.com>
Reviewed-on: http://git-master/r/197028
(cherry picked from commit 9c49ffd08d6da03caa820711db83f561d9333aee)
Reviewed-on: http://git-master/r/200854
GVS: Gerrit_Virtual_Submit
Reviewed-by: Seshendra Gadagottu <sgadagottu@nvidia.com>
Reviewed-by: Yu-Huan Hsu <yhsu@nvidia.com>
ARM: remove unnecessary dcache_clean_area

Cortex-A9 has PIPT D-cache which do not require clean the cache
on creating page table.

Original-Change-Id: I42d528be83ea8def96045c7e575c7b3ed95f5980
Reviewed-on: http://git-master/r/40505
Reviewed-by: Heechul Yun <hyun@nvidia.com>
Tested-by: Heechul Yun <hyun@nvidia.com>
Reviewed-by: Krishna Reddy <vdumpa@nvidia.com>
Reviewed-by: Scott Williams <scwilliams@nvidia.com>

Rebase-Id: R214ce4b138abb18e1cfe79465087c39ead248d72
ARM: LPAE: Invalidate the TLB for module addresses during translation fault

During the free_pgtables() call all user and modules/pkmap entries are
removed. If a translation fault for the modules/pkmap area occurs before
we switched away from the current pgd, do_translation_fault() would copy
the init_mm pud into the user pud.

There is a small window between pud_clear() and pmd_free_tlb() in
free_pmd_range() where the pud entry was cleared but the TLB has not
been invalidated yet and the CPU may have cached the original (valid)
pud entry in the TLB. A scenario like below would get stuck in
continuous prefetch abort:

1. Current process exiting. The modules pmd entries not populated
2. exit_mmap() -> ... -> pmd_free_tlb()
3. pud_clear() for the 1GB pud containing user stack and modules (no TLB
   invalidation yet)
4. Interrupt -> module interrupt routine
5. Level 2 (pmd) translation fault occurs when executing the module
   interrupt routine. The CPU previously cached (TLB) the old valid pud
   value for the modules area, so we don't get a level 1 translation
   fault
6. do_translation fault() copies the pud_k into the pud
7. Linux returns to the faulty instruction. Goes back to 5

At point 7, since the CPU still has the old pud value, it goes back to
point 5 and never gets out of this loop. With this patch, the stale pud
TLB entry is invalidated after point 6 and the subsequent prefetch abort
doesn't occur.

Reported-by: Tony Thompson <Anthony.Thompson@arm.com>
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
(cherry picked from commit bb2c1f205618083611d044a461e019c26468a231)

Rebase-Id: R9afbe63e26001dc849f8c55d5f34d6f5e70cfc47
ARM: mm: cache-l2x0: Implement outer_clean_all()

There is already implemented full outer clean routine in
arch/arm/mm/cache-l2x0.c.

Make it possible to use it through outer_cache interface,
like other outer maintenance functions.

bug 983964

Change-Id: I47f1fad536c151c255e6a42d6517114c334ddfef
Reviewed-on: http://git-master/r/116074
Reviewed-by: Automatic_Commit_Validation_User
Reviewed-by: Kirill Artamonov <kartamonov@nvidia.com>
Tested-by: Kirill Artamonov <kartamonov@nvidia.com>
Reviewed-by: Krishna Reddy <vdumpa@nvidia.com>
Reviewed-by: Justin Paver <jpaver@nvidia.com>
Reviewed-by: Bharat Nihalani <bnihalani@nvidia.com>

Rebase-Id: Rf769958fea9fd10058a4805eeafe08f5f0e895dd

Conflicts:
	arch/arm/mm/cache-l2x0.c
ARM: dma: Drop GFP_COMP for DMA-IOMMU memory allocations

dma_alloc_coherent wants to split pages after allocation in order to
reduce the memory footprint. This does not work well with GFP_COMP
pages, so drop this flag before allocation.

This patch is ported from arch/avr32
(commit 3611553ef985ef7c5863c8a94641738addd04cff).

Change-Id: I67eb2b15807c36c6a3ade95ee35bf5856d8e0e11
Signed-off-by: Hiroshi Doyu <hdoyu@nvidia.com>

Rebase-Id: Rf13a569ebe836d341cf4d9287ff4b4711dde85cc
ARM: cache-l2x0: get size of outer cache

Implement interface for getting size of outer cache.

bug 983964

Change-Id: If855f32d3eaa4c673c132b1964a46fe1c15b4dfe
Signed-off-by: Kirill Artamonov <kartamonov@nvidia.com>
Reviewed-on: http://git-master/r/140024
Reviewed-by: Automatic_Commit_Validation_User
GVS: Gerrit_Virtual_Submit
Reviewed-by: Peter De Schrijver <pdeschrijver@nvidia.com>
Reviewed-by: Sachin Nikam <snikam@nvidia.com>
Reviewed-by: Juha Tukkinen <jtukkinen@nvidia.com>

Rebase-Id: R11f28e4f625d2626a7a9270265a485e9b07c473f

Conflicts:
	arch/arm/mm/cache-l2x0.c