From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1759406Ab2IFDFf (ORCPT ); Wed, 5 Sep 2012 23:05:35 -0400 Received: from cantor2.suse.de ([195.135.220.15]:56274 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755427Ab2IFDFd (ORCPT ); Wed, 5 Sep 2012 23:05:33 -0400 Date: Thu, 6 Sep 2012 13:05:10 +1000 From: NeilBrown To: "Shilimkar, Santosh" Cc: "Rafael J. Wysocki" , Tarun Kanti DebBarma , Kevin Hilman , Tony Lindgren , Cousson@suse.de, Benoit , Grant Likely , Felipe Balbi , linux-omap@vger.kernel.org, lkml , Jon Hunter Subject: Re: [PATCH] OMAP GPIO - don't wake from suspend unless requested. Message-ID: <20120906130510.32b0b877@notabene.brown> In-Reply-To: References: <20120825214459.7333a376@notabene.brown> <20120827085312.75957354@notabene.brown> X-Mailer: Claws Mail 3.7.10 (GTK+ 2.24.7; x86_64-suse-linux-gnu) Mime-Version: 1.0 Content-Type: multipart/signed; micalg=PGP-SHA1; boundary="Sig_/BcNgvYr3DD7qZgnaqKzwkwJ"; protocol="application/pgp-signature" Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org --Sig_/BcNgvYr3DD7qZgnaqKzwkwJ Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable On Mon, 3 Sep 2012 22:59:06 -0700 "Shilimkar, Santosh" wrote: > On Sun, Aug 26, 2012 at 6:29 PM, Shilimkar, Santosh > wrote: > > On Sun, Aug 26, 2012 at 3:53 PM, NeilBrown wrote: > >> > >> On Sun, 26 Aug 2012 09:47:50 +0530 "Shilimkar, Santosh" > >> wrote: > >> > >> > + Jon, > >> > > >> > On Sat, Aug 25, 2012 at 5:14 PM, NeilBrown wrote: > >> > > > >> > > > >> > > > >> > > Current kernel will wake from suspend on an event on any active > >> > > GPIO even if enable_irq_wake() wasn't called. > >> > > > >> > > There are two reasons that the hardware wake-enable bit should be = set: > >> > > > >> > > 1/ while non-suspended the CPU might go into a deep sleep (off_mod= e) > >> > > in which the wake-enable bit is needed for an interrupt to be > >> > > recognised. > >> > > 2/ while suspended the GPIO interrupt should wake from suspend if = and > >> > > only if irq_wake as been enabled. > >> > > > >> > > The code currently doesn't keep these two reasons separate so they= get > >> > > confused and sometimes the wakeup flags is set incorrectly. > >> > > > >> > > This patch reverts: > >> > > commit 9c4ed9e6c01e7a8bd9079da8267e1f03cb4761fc > >> > > gpio/omap: remove suspend/resume callbacks > >> > > and > >> > > commit 0aa2727399c0b78225021413022c164cb99fbc5e > >> > > gpio/omap: remove suspend_wakeup field from struct gpio_bank > >> > > > >> > > and makes some minor changes so that we have separate flags for "G= PIO > >> > > should wake from deep idle" and "GPIO should wake from suspend". > >> > > > >> > > With this patch, the GPIO from my touch screen doesn't wake my dev= ice > >> > > any more, which is what I want. > >> > > > >> > > Cc: Kevin Hilman > >> > > Cc: Tony Lindgren > >> > > Cc: Santosh Shilimkar > >> > > Cc: Cousson, Benoit > >> > > Cc: Grant Likely > >> > > Cc: Tarun Kanti DebBarma > >> > > Cc: Felipe Balbi > >> > > Cc: Govindraj.R > >> > > > >> > > Signed-off-by: NeilBrown > >> > > > >> > The patch doesn't seems to be correct. At least the 2/ gets > >> > fixed with a proper IRQCHIP flag. Can you try the patch at > >> > end of the email and see if it helps ? Am attaching it in case > >> > mailer damages it. > >> > > >> > Regards > >> > Santosh > >> > > >> > >From b8a38fc75e046f6462610e26c47c620cad850c24 Mon Sep 17 00:00:00 2= 001 > >> > From: Santosh Shilimkar > >> > Date: Sun, 26 Aug 2012 09:39:51 +0530 > >> > Subject: [PATCH] gpio: omap: Set IRQCHIP_MASK_ON_SUSPEND to mask all > >> > non-wakeup gpio wakeups. > >> > > >> > Set the irq chip flag IRQCHIP_MASK_ON_SUSPEND to cause the irq pm co= de > >> > to mask all non-wake gpios in suspend, which will ensure the wakeup > >> > enable > >> > bit is not set on non-wake gpios. > >> > > >> > Signed-off-by: Santosh Shilimkar > >> > --- > >> > drivers/gpio/gpio-omap.c | 1 + > >> > 1 file changed, 1 insertion(+) > >> > > >> > diff --git a/drivers/gpio/gpio-omap.c b/drivers/gpio/gpio-omap.c > >> > index e6efd77..50b4c18 100644 > >> > --- a/drivers/gpio/gpio-omap.c > >> > +++ b/drivers/gpio/gpio-omap.c > >> > @@ -779,6 +779,7 @@ static struct irq_chip gpio_irq_chip =3D { > >> > .irq_unmask =3D gpio_unmask_irq, > >> > .irq_set_type =3D gpio_irq_type, > >> > .irq_set_wake =3D gpio_wake_enable, > >> > + .flags =3D IRQCHIP_MASK_ON_SUSPEND; > >> > }; > >> > > >> > > >> > /*------------------------------------------------------------------= ---*/ > >> > >> > >> No obvious damage, unless the mailer is responsible or the ';' at the = end > >> of > >> the line, rather than ',' :-) > >> > > :-) That was typo. > > > >> The approach makes sense, but does actually work. Should be fixable > >> though. > >> > >> When I try this I get: > >> > >> > >> > >> [ 158.114440] Checking wakeup interrupts > >> [ 158.118408] Unhandled fault: external abort on non-linefetch (0x102= 8) > >> at 0xfb054040 > >> [ 158.126403] Internal error: : 1028 [#1] PREEMPT ARM > >> [ 158.131500] Modules linked in: ipv6 g_ether hso libertas_sdio liber= tas > >> cfg80211 > >> [ 158.139190] CPU: 0 Not tainted (3.5.0-gta04-debug+ #2) > >> [ 158.144927] PC is at _set_gpio_triggering+0x38/0x258 > >> [ 158.150115] LR is at gpio_mask_irq+0xac/0xc0 > >> [ 158.154602] pc : [] lr : [] psr: 60000193 > >> [ 158.154602] sp : db521e90 ip : 00000011 fp : beeecc2c > >> [ 158.166595] r10: c05c8ebc r9 : daa5a858 r8 : 00000003 > >> [ 158.172027] r7 : a0000193 r6 : 00000000 r5 : fb054000 r4 : ded44= e18 > >> [ 158.178863] r3 : 00000001 r2 : 00000000 r1 : ded30340 r0 : 00000= 040 > >> [ 158.185668] Flags: nZCv IRQs off FIQs on Mode SVC_32 ISA ARM > >> Segment use > >> > >> so it looks like runtime PM has turned off the iclk to the GPIO module= so > >> that > >> when we try to tell it to change settings, it is no longer listening to > >> us. > > From the crash logs it appears like that. > > > >> The "Checking wakeup interrupts" function happens very late in the sus= pend > >> cycle, after all the suspend_late and suspend_noirq functions have run. > >> Maybe it needs to be moved earlier... > >> > > No it shouldn't be moved and it is that point for lot many good > > reasons. Ofcourse > > this omap gpio driver crash needs to be addressed. Need to think bit > > more on this > > issue. > > > After thinking bit more on this, the problem seems to be coming > mainly because the gpio device is runtime suspended bit early than > it should be. Similar issue seen with i2c driver as well. The i2c issue > was discussed with Rafael at LPC last week. The idea is to move > the pm_runtime_enable/disable() calls entirely up to the > _late/_early stage of device suspend/resume. > Will update this thread once I have further update. This won't be late enough. IRQCHIP_MASK_ON_SUSPEND takes effect after all the _late callbacks have been called. I, too, spoke to Rafael about this in San Diego. He seemed to agree with me that the interrupt needs to be masked in the ->suspend callback. any later is too late. NeilBrown >=20 > Regards > Santosh --Sig_/BcNgvYr3DD7qZgnaqKzwkwJ Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (GNU/Linux) iQIVAwUBUEgS5jnsnt1WYoG5AQKH9w//eUyxB2ZPd9gIGdDsw4LLd5UMXgIgP/wk Pl/DjIUTBO7VQDJgZoirJiXj6UssVwK2bEszXefreUzxBXhFSxYDPlFsbgniWm4r RAFVbn6ylsdBaRpY/T+/XbuUqIjtIuWwZ2q0mDUgnZuf7fm17BBUaPK+juZGwG5O gajRAJ5cuSvRaP/Mr5NUkY839D4p9DVECTjZ6jmM2f5L3WqHbKPdyX0jrLcb+Cb5 qosYq/lP4MbVjglZFMjXUMAea140X9YnUUM4idqMqAiI1N9D+e/uefVVz3ID8Df/ X+Hvm64KV06z1wATQqdgfAkWVJFHxbQEXvyb8DIzAao+c+l57uWM/AaMPRKnXfHE l5DyBa9aNDI/Wm5/PrSh8cuPdHY+uPcvhOjLTd3zEJYOK8DeBIk9oQSLzyuyJBLs 0SqaFOTNOxk4Uu1+ZaVXtYKqzOTyG7o1O98ATGLs/cmflps3a/CPRQ3kvbcyOed7 /bDGjPsqgF9ld+EeaLE92hDW/1J20HMPpR2l4jl2tYRGr96OMyaUVUPGWuTkJeJ/ 5keLI7Adc37lp2DZBHcNW9QwAFYeAlE64Z86l9ZH/kI9paTfPD6qH3arei2lczn2 CpsEjXc1EyO9S4KEDgLtXg0668ouQah649fTSnizx1/UU/TFEcxcEkFJVlAiXKaM rfzD2SxUimM= =1Gxu -----END PGP SIGNATURE----- --Sig_/BcNgvYr3DD7qZgnaqKzwkwJ--