From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-9.0 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI, SIGNED_OFF_BY,SPF_PASS,URIBL_BLOCKED,USER_AGENT_GIT autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id E4710C4360F for ; Thu, 4 Apr 2019 09:32:48 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id B1E53205F4 for ; Thu, 4 Apr 2019 09:32:48 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1554370368; bh=4S+k0aX22ojcl54tAH6LapJtuvJOQgv9FRcxey5LG+Y=; h=From:To:Cc:Subject:Date:In-Reply-To:References:List-ID:From; b=pLZtLVbgGJaSWluizj7CAv+Rh4SaUglXLP8DzXr+33y2cn/QOGkVSt6Z3+UHmqf4T dXcq4ph1eYDYxwebD1kt7PE/jcvsDShxXO7E0WvoO5IDJBCpW4pZgaJ3WFoRyrgYG4 cGfuk5ZeyAE1SJSeOzBuIejX70dWp0eAaMU2nE+g= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1732860AbfDDJcr (ORCPT ); Thu, 4 Apr 2019 05:32:47 -0400 Received: from mail.kernel.org ([198.145.29.99]:47842 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1732692AbfDDJIn (ORCPT ); Thu, 4 Apr 2019 05:08:43 -0400 Received: from localhost (83-86-89-107.cable.dynamic.v4.ziggo.nl [83.86.89.107]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id EB43C214AF; Thu, 4 Apr 2019 09:08:41 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1554368922; bh=4S+k0aX22ojcl54tAH6LapJtuvJOQgv9FRcxey5LG+Y=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=P/Fx+dqL5h1WjUhMCFO3NKEihZJmFm1BxZ2Eg6DMLe1+1OCKZGL9pozSbVXNiuGkM +gIJwczmcffcHGRi+jYQ12NAsH+CDNk/641a6TPo0P0iAkQOvcfzj2TsceHU+blUKd 41/fvvY9Y5cuq34sHOsIJ0oeImTqVFJdh2NJrkHs= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Aaro Koskinen , Keerthy , Peter Ujfalusi , Russell King , Tony Lindgren , Grygorii Strashko , Linus Walleij , Sasha Levin Subject: [PATCH 5.0 015/246] gpio: gpio-omap: fix level interrupt idling Date: Thu, 4 Apr 2019 10:45:15 +0200 Message-Id: <20190404084619.718177210@linuxfoundation.org> X-Mailer: git-send-email 2.21.0 In-Reply-To: <20190404084619.236418459@linuxfoundation.org> References: <20190404084619.236418459@linuxfoundation.org> User-Agent: quilt/0.65 X-stable: review X-Patchwork-Hint: ignore MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 5.0-stable review patch. If anyone has any objections, please let me know. ------------------ [ Upstream commit d01849f7deba81f4959fd9e51bf20dbf46987d1c ] Tony notes that the GPIO module does not idle when level interrupts are in use, as the wakeup appears to get stuck. After extensive investigation, it appears that the wakeup will only be cleared if the interrupt status register is cleared while the interrupt is enabled. However, we are currently clearing it with the interrupt disabled for level-based interrupts. It is acknowledged that this observed behaviour conflicts with a statement in the TRM: CAUTION After servicing the interrupt, the status bit in the interrupt status register (GPIOi.GPIO_IRQSTATUS_0 or GPIOi.GPIO_IRQSTATUS_1) must be reset and the interrupt line released (by setting the corresponding bit of the interrupt status register to 1) before enabling an interrupt for the GPIO channel in the interrupt-enable register (GPIOi.GPIO_IRQSTATUS_SET_0 or GPIOi.GPIO_IRQSTATUS_SET_1) to prevent the occurrence of unexpected interrupts when enabling an interrupt for the GPIO channel. However, this does not appear to be a practical problem. Further, as reported by Grygorii Strashko , the TI Android kernel tree has an earlier similar patch as "GPIO: OMAP: Fix the sequence to clear the IRQ status" saying: if the status is cleared after disabling the IRQ then sWAKEUP will not be cleared and gates the module transition When we unmask the level interrupt after the interrupt has been handled, enable the interrupt and only then clear the interrupt. If the interrupt is still pending, the hardware will re-assert the interrupt status. Should the caution note in the TRM prove to be a problem, we could use a clear-enable-clear sequence instead. Cc: Aaro Koskinen Cc: Keerthy Cc: Peter Ujfalusi Signed-off-by: Russell King [tony@atomide.com: updated comments based on an earlier TI patch] Signed-off-by: Tony Lindgren Acked-by: Grygorii Strashko Signed-off-by: Linus Walleij Signed-off-by: Sasha Levin --- drivers/gpio/gpio-omap.c | 14 ++++++++------ 1 file changed, 8 insertions(+), 6 deletions(-) diff --git a/drivers/gpio/gpio-omap.c b/drivers/gpio/gpio-omap.c index f4e9921fa966..7f33024b6d83 100644 --- a/drivers/gpio/gpio-omap.c +++ b/drivers/gpio/gpio-omap.c @@ -883,14 +883,16 @@ static void omap_gpio_unmask_irq(struct irq_data *d) if (trigger) omap_set_gpio_triggering(bank, offset, trigger); - /* For level-triggered GPIOs, the clearing must be done after - * the HW source is cleared, thus after the handler has run */ - if (bank->level_mask & BIT(offset)) { - omap_set_gpio_irqenable(bank, offset, 0); + omap_set_gpio_irqenable(bank, offset, 1); + + /* + * For level-triggered GPIOs, clearing must be done after the source + * is cleared, thus after the handler has run. OMAP4 needs this done + * after enabing the interrupt to clear the wakeup status. + */ + if (bank->level_mask & BIT(offset)) omap_clear_gpio_irqstatus(bank, offset); - } - omap_set_gpio_irqenable(bank, offset, 1); raw_spin_unlock_irqrestore(&bank->lock, flags); } -- 2.19.1