Power: revert to "PM / QoS: Fix deadlock during PM QoS vote to default value"

Signed-off-by: LaboDJ <jacopolabardi@gmail.com>
genirq: Provide means to retrigger parent

Attempts to retrigger nested threaded IRQs currently fail because they
have no primary handler. In order to support retrigger of nested
IRQs, the parent IRQ needs to be retriggered.

To fix, when an IRQ needs to be resent, if the interrupt has a parent
IRQ and runs in the context of the parent IRQ, then resend the parent.

Also, handle_nested_irq() needs to clear the replay flag like the
other handlers, otherwise check_irq_resend() will set it and it will
never be cleared.  Without clearing, it results in the first resend
working fine, but check_irq_resend() returning early on subsequent
resends because the replay flag is still set.

Problem discovered on ARM/OMAP platforms where a nested IRQ that's
also a wakeup IRQ happens late in suspend and needed to be retriggered
during the resume process.

[khilman@ti.com: changelog edits, clear IRQS_REPLAY in handle_nested_irq()]

Reported-by: Kevin Hilman <khilman@ti.com>
Tested-by: Kevin Hilman <khilman@ti.com>
Cc: linux-arm-kernel@lists.infradead.org
Link: http://lkml.kernel.org/r/1350425269-11489-1-git-send-email-khilman@deeprootsystems.com
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Pranav Vashi <neobuddy89@gmail.com>
genirq: Set irq thread to RT priority on creation

When a threaded irq handler is installed the irq thread is initially
created on normal scheduling priority. Only after the irq thread is
woken up it sets its priority to RT_FIFO MAX_USER_RT_PRIO/2 itself.

This means that interrupts that occur directly after the irq handler
is installed will be handled on a normal scheduling priority instead
of the realtime priority that one would expect.

Fix this by setting the RT priority on creation of the irq_thread.

[neo: modified for linux 3.4.y]

Signed-off-by: Ivo Sieben <meltedpianoman@gmail.com>
Cc: Sebastian Andrzej Siewior  <bigeasy@linutronix.de>
Cc: Steven Rostedt <rostedt@goodmis.org>
Link: http://lkml.kernel.org/r/1370254322-17240-1-git-send-email-meltedpianoman@gmail.com
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Pranav Vashi <neobuddy89@gmail.com>
genirq: Set the irq thread policy without checking CAP_SYS_NICE

In commit ("genirq: Set irq thread to RT priority on creation")
we moved the assigment of the thread's priority from the
thread's function into __setup_irq(). That function may run in user
context for instance if the user opens an UART node and then driver
calls requests in the ->open() callback. That user may not have
CAP_SYS_NICE and so the irq thread won't run with the SCHED_OTHER
policy.

This patch uses sched_setscheduler_nocheck() so we omit the CAP_SYS_NICE
check which is otherwise required for the SCHED_OTHER policy.

[bigeasy: Rewrite the changelog]

Signed-off-by: Thomas Pfaff <tpfaff@pcs.com>
Cc: Ivo Sieben <meltedpianoman@gmail.com>
Cc: stable@vger.kernel.org
Link: http://lkml.kernel.org/r/1381489240-29626-1-git-send-email-bigeasy@linutronix.de
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Pranav Vashi <neobuddy89@gmail.com>
genirq: Prevent spurious detection for unconditionally polled interrupts

On a 68k platform a couple of interrupts are demultiplexed and
"polled" from a top level interrupt. Unfortunately there is no way to
determine which of the sub interrupts raised the top level interrupt,
so all of the demultiplexed interrupt handlers need to be
invoked. Given a high enough frequency this can trigger the spurious
interrupt detection mechanism, if one of the demultiplex interrupts
returns IRQ_NONE continuously. But this is a false positive as the
polling causes this behaviour and not buggy hardware/software.

Introduce IRQ_POLLED which can be set at interrupt chip setup time via
irq_set_status_flags(). The flag excludes the interrupt from the
spurious detector and from all core polling activities.

Reported-and-tested-by: Michael Schmitz <schmitzmic@gmail.com>
Cc: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: linux-m68k@vger.kernel.org
Link: http://lkml.kernel.org/r/alpine.DEB.2.02.1311061149250.23353@ionos.tec.linutronix.de

Signed-off-by: Pranav Vashi <neobuddy89@gmail.com>
genirq: Generic irq chip requires IRQ_DOMAIN

The generic_chip.c uses interfaces from irq_domain.c which is
controlled by the IRQ_DOMAIN config option, but there is no Kconfig
dependency so the build can fail:

linux/kernel/irq/generic-chip.c:400:11: error:
'irq_domain_xlate_onetwocell' undeclared here (not in a function)

Select IRQ_DOMAIN when GENERIC_IRQ_CHIP is selected.

Signed-off-by: Nitin A Kamble <nitin.a.kamble@intel.com>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Cc: stable@vger.kernel.org # 3.11+
Signed-off-by: Pranav Vashi <neobuddy89@gmail.com>
genirq: Add devm_request_any_context_irq()

Some drivers use request_any_context_irq() but there isn't a
devm_* function for it. Add one so that these drivers don't need
to explicitly free the irq on driver detach.

Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
Cc: linux-arm-kernel@lists.infradead.org
Cc: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Pranav Vashi <neobuddy89@gmail.com>
Revert "net: wireless: bcmdhd: Use powersuspend to prevent panic"

* Currently code is checking for deprecated early suspend
  which we don't have 3.4 onwards.
* So helper function is called for checking suspend status.
* This is causing race condition if screen is turned on and off
  rapidly.

Happy Case:
Screen Off -> Wifi Suspended -> Screen On -> Wifi Resumed

Race conditon:
Screen Off -> Wifi Suspended -> Screen On -> Wifi Resumed
-> Screen Off -> Screen On (rapid) -> Wifi Suspended!!

This causes watchdog bark / kernel panic as below:

[ 7217.522130] PM: noirq resume of devices complete after 4.327 msecs
[ 7217.527345] PM: early resume of devices complete after 2.901 msecs
[ 7217.549827] PM: resume of devices complete after 22.455 msecs
[ 7217.551660] Restarting tasks ... done.
[ 7217.558636] PM: suspend exit 2014-05-28 06:29:43.989676647 UTC
[ 7221.016418] [Touch] touch on
[ 7221.217701] mdss_dsi_panel_on
[ 7221.267290] lm3630_backlight_on
[ 7221.292473] dhd_set_suspend: Remove extra suspend setting
[ 7225.155909] lm3630_backlight_off
[ 7225.231024] [prevent_touchscreen_sleep]: payload = 10
[ 7225.383173] mdss_dsi_panel_off:
[ 7225.406145] [Touch] touch off
[ 7226.303258] [Touch] touch on
[ 7226.497452] mdss_dsi_panel_on
[ 7227.373713] [prevent_touchscreen_sleep]: payload = 10
[ 7227.525721] mdss_dsi_panel_off:
[ 7227.548667] [Touch] touch off
[ 7229.718552] [Touch] touch on
[ 7229.917659] mdss_dsi_panel_on
[ 7235.208821] dhd_set_suspend: force extra Suspend setting
[ 7235.220861] dhd_get_suspend_bcn_li_dtim beacon=100 bcn_li_dtim=3 DTIM=1 Listen=10
[ 7241.483289] Watchdog bark! Now = 7241.483285
[ 7241.483342] Watchdog last pet at 7220.296271
[ 7241.483428] cpu alive mask from last pet 0
[ 7241.483474] Causing a watchdog bite! IRQ = 35.

No errors detected
Boot info:
Last boot reason: wdog_bark

Let's use powersuspend driver replacing deprecated earlysuspend drivers.

CAUTION: Powersuspend driver shouldn't use screen on/off hooks else this
         patch is of no use!! If you really want screen on/off level of
         sensitivity, use LCD notifier for such drivers.

Signed-off-by: Pranav Vashi <neobuddy89@gmail.com> (reverted from commit d13aa29d11798d819892890a2dcfa16a123cb8a0)
Signed-off-by: LaboDJ <jacopolabardi@gmail.com>