linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: tomasz.figa@gmail.com (Tomasz Figa)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 1/2] ARM: EXYNOS: Support Suspend-to-RAM on EXYNOS5420
Date: Fri, 20 Dec 2013 22:53:13 +0100	[thread overview]
Message-ID: <4034332.29qpdhiElM@flatron> (raw)
In-Reply-To: <CAOesGMi7cGZyHLBMpc7UTBbQkiRBij6rDyuA+E+9tUmsb131zw@mail.gmail.com>

On Friday 20 of December 2013 13:37:36 Olof Johansson wrote:
> On Fri, Dec 20, 2013 at 1:19 PM, Tomasz Figa <tomasz.figa@gmail.com> wrote:
> > Hi,
> >
> > On Friday 20 of December 2013 15:56:38 sunil joshi wrote:
> >> Hi Abhilash,
> >> I saw another patch in chrome tree ..by Andrew Bresticker
> >> which may be relevant here ..
> >>
> >> Just wondering if you missed adding this ? or this is not needed ?
> >> You did not face any issue in getting core to suspend ?
> >>
> >> ------------------------------------------------------------------------------------------
> >> commit 95402d816b9f1a05ce633f7ff64b4c939c142482
> >> Author: Andrew Bresticker <abrestic@chromium.org>
> >> Date:   Mon Jul 15 13:14:36 2013 -0700
> >>
> >>     arm: exynos: disable all interrupts on Exynos5420 before suspend
> >>
> >>     Disable all interrupts from the GIC before entering suspend on
> >>     Exynos5420 as is done on Exynos5250.  If interrupts are enabled, we
> >>     may receive an interrupt after entering WFI but before the PMU has
> >>     suspended the system, causing suspend to fail.
> >>
> >>     BUG=chrome-os-partner:20523
> >>     TEST=Run suspend_stress_test on Pit and observe that entering suspend
> >>     no longer occasionally fails with the "Failed to suspend the system"
> >>     error in exynos_cpu_suspend().
> >
> > A question about this for Chromium and LSI guys:
> >
> > If you find out that there is already a pending interrupt before you enter
> > the sleep mode, isn't it more reasonable to cancel the process ASAP and
> > handle the event instead of entering the sleep just to leave it?
> >
> > I believe this should be both more efficient with respect to power usage
> > and latency, because sleep-wakeup transition takes time and power.
> >
> > Do you have any reason to think the opposite?
> 
> If it's expected to be a rare or very rare event, it's not a given
> that the added complexity of dealing with the aborted suspend that
> late is worth it.

I think that the code to support this is already in place, just printing
an unfortunate message about "suspend failures". It doesn't add any
significant complexity too.

I'm not sure about the frequency of such events, though, and any real
effect of this or the other behavior in such case and so there is my
question about this.

Best regards,
Tomasz

  reply	other threads:[~2013-12-20 21:53 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-12-16 12:01 [PATCH 1/2] ARM: EXYNOS: Support Suspend-to-RAM on EXYNOS5420 Abhilash Kesavan
2013-12-16 12:01 ` [PATCH 2/2] ARM: dts: Add node for GPIO keys on SMDK5420 Abhilash Kesavan
2013-12-16 12:48 ` [PATCH 1/2] ARM: EXYNOS: Support Suspend-to-RAM on EXYNOS5420 Bartlomiej Zolnierkiewicz
2013-12-17  3:10   ` Abhilash Kesavan
2013-12-20 10:26     ` sunil joshi
2013-12-20 11:38       ` Abhilash Kesavan
2013-12-20 11:53         ` sunil joshi
2013-12-20 21:22         ` Olof Johansson
2013-12-20 21:23           ` Tomasz Figa
2013-12-20 21:25             ` Olof Johansson
2013-12-20 21:25               ` Tomasz Figa
2013-12-21  7:06           ` Abhilash Kesavan
2013-12-20 21:19       ` Tomasz Figa
2013-12-20 21:37         ` Olof Johansson
2013-12-20 21:53           ` Tomasz Figa [this message]
2013-12-21  7:40             ` Abhilash Kesavan
2013-12-21  1:15         ` Doug Anderson
     [not found]           ` <CAPQV+nO=Xe=z669QxCJSerrm-xP0b=WtyPveyh2uTcM2B3i5KQ@mail.gmail.com>
2014-01-18  2:44             ` Abhilash Kesavan
2013-12-16 13:27 ` Vaibhav Bedia
2013-12-16 16:15   ` Tomasz Figa
2013-12-20 21:37 ` Tomasz Figa
2013-12-21  7:18   ` Abhilash Kesavan

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4034332.29qpdhiElM@flatron \
    --to=tomasz.figa@gmail.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).