01 Sep, 2014
7 commits
-
Currently we suspend wakeup interrupts by lazy disabling them and
check later whether the interrupt has fired, but that's not sufficient
for suspend to idle as there is no way to check that once we
transitioned into the CPU idle state.So we change the mechanism in the following way:
1) Leave the wakeup interrupts enabled across suspend
2) Add a check to irq_may_run() which is called at the beginning of
each flow handler whether the interrupt is an armed wakeup source.This check is basically free as it just extends the existing check
for IRQD_IRQ_INPROGRESS. So no new conditional in the hot path.If the IRQD_WAKEUP_ARMED flag is set, then the interrupt is
disabled, marked as pending/suspended and the pm core is notified
about the wakeup event.Signed-off-by: Thomas Gleixner
[ rjw: syscore.c and put irq_pm_check_wakeup() into pm.c ]
Signed-off-by: Rafael J. Wysocki -
This allows us to utilize this information in the irq_may_run() check
without adding another conditional to the fast path.Signed-off-by: Thomas Gleixner
Signed-off-by: Rafael J. Wysocki -
We can synchronize the suspended interrupts right away. No need for an
extra loop.Signed-off-by: Thomas Gleixner
Signed-off-by: Rafael J. Wysocki -
There is no reason why we should delay the masking of interrupts whose
interrupt chip requests MASK_ON_SUSPEND to the point where we check
the wakeup interrupts. We can do it right at the point where we mark
the interrupt as suspended.Signed-off-by: Thomas Gleixner
Signed-off-by: Rafael J. Wysocki -
Use the accounting fields which got introduced for snity checking for
the various PM options.Signed-off-by: Thomas Gleixner
Signed-off-by: Rafael J. Wysocki -
Account the IRQF_NO_SUSPEND and IRQF_RESUME_EARLY actions on shared
interrupt lines and yell loudly if there is a mismatch.Signed-off-by: Thomas Gleixner
Signed-off-by: Rafael J. Wysocki -
No functional change. Preparatory patch for cleaning up the suspend
abort functionality. Update the comments while at it.Signed-off-by: Thomas Gleixner
Signed-off-by: Rafael J. Wysocki
26 Nov, 2013
1 commit
-
When the system enters suspend, it disables all interrupts in
suspend_device_irqs(), including the interrupts marked EARLY_RESUME.On the resume side things are different. The EARLY_RESUME interrupts
are reenabled in sys_core_ops->resume and the non EARLY_RESUME
interrupts are reenabled in the normal system resume path.When suspend_noirq() failed or suspend is aborted for any other
reason, we might omit the resume side call to sys_core_ops->resume()
and therefor the interrupts marked EARLY_RESUME are not reenabled and
stay disabled forever.To solve this, enable all irqs unconditionally in irq_resume()
regardless whether interrupts marked EARLY_RESUMEhave been already
enabled or not.This might try to reenable already enabled interrupts in the non
failure case, but the only affected platform is XEN and it has been
confirmed that it does not cause any side effects.[ tglx: Massaged changelog. ]
Signed-off-by: Laxman Dewangan
Acked-by-and-tested-by: Konrad Rzeszutek Wilk
Acked-by: Heiko Stuebner
Reviewed-by: Pavel Machek
Cc:
Cc:
Cc:
Cc:
Cc: stable@vger.kernel.org
Link: http://lkml.kernel.org/r/1385388587-16442-1-git-send-email-ldewangan@nvidia.com
Signed-off-by: Thomas Gleixner
05 May, 2012
1 commit
-
If an wakeup interrupt has been disabled before the suspend code
disables all interrupts then we have to ignore the pending flag.Otherwise we would abort suspend over and over as nothing clears the
pending flag because the interrupt is disabled.Signed-off-by: Thomas Gleixner
Cc: NeilBrown
17 Oct, 2011
1 commit
-
This adds a mechanism to resume selected IRQs during syscore_resume
instead of dpm_resume_noirq.Under Xen we need to resume IRQs associated with IPIs early enough
that the resched IPI is unmasked and we can therefore schedule
ourselves out of the stop_machine where the suspend/resume takes
place.This issue was introduced by 676dc3cf5bc3 "xen: Use IRQF_FORCE_RESUME".
Signed-off-by: Ian Campbell
Cc: Rafael J. Wysocki
Cc: Jeremy Fitzhardinge
Cc: xen-devel
Cc: Konrad Rzeszutek Wilk
Link: http://lkml.kernel.org/r/1318713254.11016.52.camel@dagon.hellion.org.uk
Cc: stable@kernel.org (at least to 2.6.32.y)
Signed-off-by: Thomas Gleixner
12 Mar, 2011
1 commit
-
On suspend we disable all interrupts in the core code, but this does
not mask the interrupt line in the default implementation as we use a
lazy disable approach. That means we mark the interrupt disabled, but
leave the hardware unmasked. That's an optimization because we avoid
the hardware access for the common case where no interrupt happens
after we marked it disabled. If an interrupt happens, then the
interrupt flow handler masks the line at the hardware level and marks
it pending.Suspend makes use of this delayed disable as it "disables" all
interrupts when preparing the suspend transition. Right before the
system goes into hardware suspend state it checks whether one of the
interrupts which is marked as a wakeup interrupt came in after
disabling it.Most interrupt chips have a separate register which selects the
interrupts which can wake up the system from suspend, so we don't have
to mask any on the non wakeup interrupts.But now we have to deal with brilliant designed hardware which lacks
such a wakeup configuration facility. For such hardware it's necessary
to mask all non wakeup interrupts before going into suspend in order
to avoid the wakeup from random interrupts.Rather than working around this in the affected interrupt chip
implementations we can solve this elegant in the core code itself.Add a flag IRQCHIP_MASK_ON_SUSPEND which can be set by the irq chip
implementation to indicate, that the interrupts which are not selected
as wakeup sources must be masked in the suspend path. Mask them in the
loop which checks the wakeup interrupts pending flag.Signed-off-by: Thomas Gleixner
Reviewed-by: Abhijeet Dharmapurikar
LKML-Reference:
19 Feb, 2011
4 commits
-
Some irq_chips need to know the state of wakeup mode for
setting the trigger type etc. Reflect it in irq_data state.Signed-off-by: Thomas Gleixner
-
No users outside of core.
Signed-off-by: Thomas Gleixner
-
No users outside of core.
Signed-off-by: Thomas Gleixner
-
Keep status in sync until all users are fixed.
Signed-off-by: Thomas Gleixner
08 Feb, 2011
1 commit
-
Xen needs to reenable interrupts which are marked IRQF_NO_SUSPEND in the
resume path. Add a flag to force the reenabling in the resume code.Tested-and-acked-by: Ian Campbell
Signed-off-by: Thomas Gleixner
15 Dec, 2009
1 commit
-
Convert locks which cannot be sleeping locks in preempt-rt to
raw_spinlocks.Signed-off-by: Thomas Gleixner
Acked-by: Peter Zijlstra
Acked-by: Ingo Molnar
05 Jul, 2009
1 commit
-
The kerneldoc comment describing suspend_device_irqs() is currently
misleading, because generally the function doesn't really disable
interrupt lines at the chip level. Replace it with a more accurate
one.Signed-off-by: Rafael J. Wysocki
LKML-Reference:
Signed-off-by: Thomas Gleixner
31 Mar, 2009
1 commit
-
Introduce helper functions allowing us to prevent device drivers from
getting any interrupts (without disabling interrupts on the CPU)
during suspend (or hibernation) and to make them start to receive
interrupts again during the subsequent resume. These functions make it
possible to keep timer interrupts enabled while the "late" suspend and
"early" resume callbacks provided by device drivers are being
executed. In turn, this allows device drivers' "late" suspend and
"early" resume callbacks to sleep, execute ACPI callbacks etc.The functions introduced here will be used to rework the handling of
interrupts during suspend (hibernation) and resume. Namely,
interrupts will only be disabled on the CPU right before suspending
sysdevs, while device drivers will be prevented from receiving
interrupts, with the help of the new helper function, before their
"late" suspend callbacks run (and analogously during resume).Signed-off-by: Rafael J. Wysocki
Acked-by: Ingo Molnar