From patchwork Thu Jun 16 13:12:20 2011 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Sanjeev Premi X-Patchwork-Id: 887372 Received: from merlin.infradead.org (merlin.infradead.org [205.233.59.134]) by demeter2.kernel.org (8.14.4/8.14.4) with ESMTP id p5GDCxA7005329 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 16 Jun 2011 13:13:20 GMT Received: from canuck.infradead.org ([2001:4978:20e::1]) by merlin.infradead.org with esmtps (Exim 4.76 #1 (Red Hat Linux)) id 1QXCNG-0006Px-Bf; Thu, 16 Jun 2011 13:12:42 +0000 Received: from localhost ([127.0.0.1] helo=canuck.infradead.org) by canuck.infradead.org with esmtp (Exim 4.76 #1 (Red Hat Linux)) id 1QXCNG-0007ju-00; Thu, 16 Jun 2011 13:12:42 +0000 Received: from bear.ext.ti.com ([192.94.94.41]) by canuck.infradead.org with esmtps (Exim 4.76 #1 (Red Hat Linux)) id 1QXCNC-0007ja-Cu for linux-arm-kernel@lists.infradead.org; Thu, 16 Jun 2011 13:12:39 +0000 Received: from dbdp20.itg.ti.com ([172.24.170.38]) by bear.ext.ti.com (8.13.7/8.13.7) with ESMTP id p5GDCXUn002553 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 16 Jun 2011 08:12:35 -0500 Received: from dbde70.ent.ti.com (localhost [127.0.0.1]) by dbdp20.itg.ti.com (8.13.8/8.13.8) with ESMTP id p5GDCVJh027861; Thu, 16 Jun 2011 18:42:32 +0530 (IST) Received: from dbdp31.itg.ti.com (172.24.170.98) by DBDE70.ent.ti.com (172.24.170.148) with Microsoft SMTP Server id 8.3.106.1; Thu, 16 Jun 2011 18:42:31 +0530 Received: from psplinux050.india.ti.com (dbdp20.itg.ti.com [172.24.170.38]) by dbdp31.itg.ti.com (8.13.8/8.13.8) with ESMTP id p5GDCQdV011629; Thu, 16 Jun 2011 18:42:28 +0530 (IST) From: Sanjeev Premi To: , Subject: [PATCH] omap3: pm: Downgrade WARN for no wakeup source Date: Thu, 16 Jun 2011 18:42:20 +0530 Message-ID: <1308229940-27025-1-git-send-email-premi@ti.com> X-Mailer: git-send-email 1.7.2.2 MIME-Version: 1.0 X-CRM114-Version: 20090807-BlameThorstenAndJenny ( TRE 0.7.6 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20110616_091238_598625_974B0464 X-CRM114-Status: GOOD ( 15.75 ) X-Spam-Score: -2.3 (--) X-Spam-Report: SpamAssassin version 3.3.1 on canuck.infradead.org summary: Content analysis details: (-2.3 points) pts rule name description ---- ---------------------- -------------------------------------------------- -0.0 T_RP_MATCHES_RCVD Envelope sender domain matches handover relay domain -2.3 RCVD_IN_DNSWL_MED RBL: Sender listed at http://www.dnswl.org/, medium trust [192.94.94.41 listed in list.dnswl.org] Cc: Sanjeev Premi X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: linux-arm-kernel-bounces@lists.infradead.org Errors-To: linux-arm-kernel-bounces+patchwork-linux-arm=patchwork.kernel.org@lists.infradead.org X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.2.6 (demeter2.kernel.org [140.211.167.43]); Thu, 16 Jun 2011 13:13:20 +0000 (UTC) When multiple wakeup sources are defined in a system, there is a small window, when more than one source can trigger wakeup interrupt. In the current implementation, the do-while() loop can handle all wakeup sources that are recorded when probing the status register in prcm_interrupt_handler(). When the ISR executes due to next queued wakeup, it there is nothing to be handled and value of "c" is 0. The comment in the code, attributing this behavior to race with IVA2 along with WARN (and associated text) makes this condition appear as an error condition - while it isn't. Though the problem was found in kernel version 2.6.32 running on AM3703 (no IVA2), it is still relevant. This patch also fixes the comment that attributes current behavior to race with interrupt handler on IVA2. Quoting specific instances, on entry into the ISR, the PM_WKST_WKUP read either 0x00010101 or 0x00010001 Where, Bit 0 : ST_GPT1 - GPTIMER wakeup occurred Bit 8 : ST_IO_EN - IO pad wakeup occurred Bit 16 : ST_IO_CHAIN - The I/O wake-up scheme is enabled This time value of "c" is 2 (or 3), but then on next and immediate entry, value of "c" is 0 leading to WARN(). Another approach I considered was to keep track of the number of wakeup sources handled in previous execution of ISR, but it fails when status register indicates 3 wakeup sources. Downgrading the WARN seemed to be the simplest solution. Signed-off-by: Sanjeev Premi --- History: v1: Original RFC posted: http://marc.info/?l=linux-omap&m=130754890807333&w=2 arch/arm/mach-omap2/pm34xx.c | 9 +++++---- 1 files changed, 5 insertions(+), 4 deletions(-) diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c index c155c9d..d24942b 100644 --- a/arch/arm/mach-omap2/pm34xx.c +++ b/arch/arm/mach-omap2/pm34xx.c @@ -289,11 +289,12 @@ static irqreturn_t prcm_interrupt_handler (int irq, void *dev_id) c = _prcm_int_handle_wakeup(); /* - * Is the MPU PRCM interrupt handler racing with the - * IVA2 PRCM interrupt handler ? + * If multiple wakeup events get handled in certain + * execution through this do-while, value of "c" will + * be returned as 0. */ - WARN(c == 0, "prcm: WARNING: PRCM indicated MPU wakeup " - "but no wakeup sources are marked\n"); + if (c == 0) + pr_debug ("prcm: no more wakeup event to handle") ; } else { /* XXX we need to expand our PRCM interrupt handler */ WARN(1, "prcm: WARNING: PRCM interrupt received, but "