From mboxrd@z Thu Jan 1 00:00:00 1970 From: Tomasz Figa Subject: Re: [PATCH 1/2] ARM: EXYNOS: Support Suspend-to-RAM on EXYNOS5420 Date: Fri, 20 Dec 2013 22:19:02 +0100 Message-ID: <346894265.CPBN0v9Elj@flatron> References: <1387195271-3613-1-git-send-email-a.kesavan@samsung.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7Bit Return-path: Received: from mail-ea0-f173.google.com ([209.85.215.173]:55158 "EHLO mail-ea0-f173.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751989Ab3LTVTG (ORCPT ); Fri, 20 Dec 2013 16:19:06 -0500 Received: by mail-ea0-f173.google.com with SMTP id o10so1293582eaj.32 for ; Fri, 20 Dec 2013 13:19:04 -0800 (PST) In-Reply-To: Sender: linux-samsung-soc-owner@vger.kernel.org List-Id: linux-samsung-soc@vger.kernel.org To: sunil joshi Cc: Abhilash Kesavan , abrestic@chromium.org, Bartlomiej Zolnierkiewicz , linux-arm-kernel , linux-samsung-soc , Douglas Anderson , Olof Johansson , Kukjin Kim Andrew Bresticker 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 > 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? Best regards, Tomasz From mboxrd@z Thu Jan 1 00:00:00 1970 From: tomasz.figa@gmail.com (Tomasz Figa) Date: Fri, 20 Dec 2013 22:19:02 +0100 Subject: [PATCH 1/2] ARM: EXYNOS: Support Suspend-to-RAM on EXYNOS5420 In-Reply-To: References: <1387195271-3613-1-git-send-email-a.kesavan@samsung.com> Message-ID: <346894265.CPBN0v9Elj@flatron> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org 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 > 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? Best regards, Tomasz