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=-8.6 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,INCLUDES_PATCH,MAILING_LIST_MULTI,SIGNED_OFF_BY, SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_2 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 0C614C54FD0 for ; Mon, 23 Mar 2020 19:49:52 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id C584A20714 for ; Mon, 23 Mar 2020 19:49:51 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1584992991; bh=75fCAdyH4YV81OwXKG2GRQR18TAvhiNCXmFJeaAdyck=; h=Date:From:To:Cc:Subject:In-Reply-To:References:List-ID:From; b=vzwSTn+ZbyxGYVYPfLl5mefKi1R5D8l2PzTibftpV6feZdfvv5G4zHLmmfXK8Ei/T yp67Q4IvqXT7CShHoIYPMoh4Y4guf7HF02RblpnGoRn0uYx5Fl5GMyCjSt0WvbOhyp oeS7kxbVxVkl3dEvl72S38JfAyP3XA+oKs+7cxFI= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1725830AbgCWTtv (ORCPT ); Mon, 23 Mar 2020 15:49:51 -0400 Received: from mail.kernel.org ([198.145.29.99]:58770 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725776AbgCWTtv (ORCPT ); Mon, 23 Mar 2020 15:49:51 -0400 Received: from disco-boy.misterjones.org (disco-boy.misterjones.org [51.254.78.96]) (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 AD84C2070A; Mon, 23 Mar 2020 19:49:49 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1584992989; bh=75fCAdyH4YV81OwXKG2GRQR18TAvhiNCXmFJeaAdyck=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=y5vo+6AF3TQK2YW/tZA0Jy8AbEKmvv1Y6a4gi+YZPNOKWLQaJnYCs22QY5MeFL+Tq ob/MhXhtp/8mzVoBIOuORDQL0p9rf4ph2aXEvxZygJS63Rv1lL7LtA4jfE+nD3pfz8 sCBHKEfhQ71SriTplZAe4wRFHMKpKehZlwZ5yUaQ= Received: from 78.163-31-62.static.virginmediabusiness.co.uk ([62.31.163.78] helo=why) by disco-boy.misterjones.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1jGT51-00F3cy-U1; Mon, 23 Mar 2020 19:49:48 +0000 Date: Mon, 23 Mar 2020 19:49:46 +0000 From: Marc Zyngier To: Marek Vasut Cc: Linus Walleij , Alexandre Torgue , Thomas Gleixner , Jason Cooper , Linux ARM , linux-kernel@vger.kernel.org, "open list:GPIO SUBSYSTEM" Subject: Re: [PATCH v3 2/2] pinctrl: stm32: Add level interrupt support to gpio irq chip Message-ID: <20200323194946.26bdd003@why> In-Reply-To: <8e2795d8-4a8b-35a7-7d3f-e24d011878f6@denx.de> References: <20200219143229.18084-1-alexandre.torgue@st.com> <20200219143229.18084-3-alexandre.torgue@st.com> <8d6f6646-56e4-5218-9990-f0c96862dc83@denx.de> <20200323193157.038f36f9@why> <8e2795d8-4a8b-35a7-7d3f-e24d011878f6@denx.de> Organization: Approximate X-Mailer: Claws Mail 3.17.5 (GTK+ 2.24.32; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-SA-Exim-Connect-IP: 62.31.163.78 X-SA-Exim-Rcpt-To: marex@denx.de, linus.walleij@linaro.org, alexandre.torgue@st.com, tglx@linutronix.de, jason@lakedaemon.net, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, linux-gpio@vger.kernel.org X-SA-Exim-Mail-From: maz@kernel.org X-SA-Exim-Scanned: No (on disco-boy.misterjones.org); SAEximRunCond expanded to false Sender: linux-gpio-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-gpio@vger.kernel.org On Mon, 23 Mar 2020 20:37:54 +0100 Marek Vasut wrote: > On 3/23/20 8:31 PM, Marc Zyngier wrote: > > On Mon, 23 Mar 2020 20:19:39 +0100 > > Marek Vasut wrote: > > > >> On 3/23/20 8:04 PM, Marek Vasut wrote: > >>> On 2/20/20 10:17 AM, Marc Zyngier wrote: > >>>> On 2020-02-20 09:04, Linus Walleij wrote: > >>>>> On Wed, Feb 19, 2020 at 3:32 PM Alexandre Torgue > >>>>> wrote: > >>>>> > >>>>>> GPIO hardware block is directly linked to EXTI block but EXTI handles > >>>>>> external interrupts only on edge. To be able to handle GPIO interrupt on > >>>>>> level a "hack" is done in gpio irq chip: parent interrupt (exti irq > >>>>>> chip) > >>>>>> is retriggered following interrupt type and gpio line value. > >>>>>> > >>>>>> Signed-off-by: Alexandre Torgue > >>>>>> Tested-by: Marek Vasut > >>>>> > >>>>> Reviewed-by: Linus Walleij > >>>>> > >>>>> If Marc want to merge it with patch 1/2 go ahead! > >>>> > >>>> I'll queue the whole thing for 5.7. > >>> > >>> I have a feeling this doesn't work with threaded interrupts. > >>> > >>> If the interrupt handler runs in a thread context, the EOI will happen > >>> almost right away (while the IRQ handler runs) and so will the code > >>> handling the IRQ retriggering. But since the IRQ handler still runs and > >>> didn't return yet, the retriggering doesn't cause the IRQ handler to be > >>> called again once it finishes, even if the IRQ line is still asserted. > >>> And that could result in some of the retriggers now happening I think. > >>> Or am I doing something wrong ? > >> > >> The patch below makes my usecase work, but I don't know whether it's > >> correct. Basically once the threaded IRQ handler finishes and unmasks > >> the IRQ, check whether the line is asserted and retrigger if so. > >> > >> diff --git a/drivers/pinctrl/stm32/pinctrl-stm32.c > >> b/drivers/pinctrl/stm32/pinctrl-stm32.c > >> index 9ac9ecfc2f34..060dbcb7ae72 100644 > >> --- a/drivers/pinctrl/stm32/pinctrl-stm32.c > >> +++ b/drivers/pinctrl/stm32/pinctrl-stm32.c > >> @@ -371,12 +371,26 @@ static void > >> stm32_gpio_irq_release_resources(struct irq_data *irq_data) > >> gpiochip_unlock_as_irq(&bank->gpio_chip, irq_data->hwirq); > >> } > >> > >> +static void stm32_gpio_irq_unmask(struct irq_data *d) > >> +{ > >> + struct stm32_gpio_bank *bank = d->domain->host_data; > >> + int level; > >> + > >> + irq_chip_unmask_parent(d); > >> + > >> + /* If level interrupt type then retrig */ > >> + level = stm32_gpio_get(&bank->gpio_chip, d->hwirq); > >> + if ((level == 0 && bank->irq_type[d->hwirq] == > >> IRQ_TYPE_LEVEL_LOW) || > >> + (level == 1 && bank->irq_type[d->hwirq] == IRQ_TYPE_LEVEL_HIGH)) > >> + irq_chip_retrigger_hierarchy(d); > >> +} > >> + > >> static struct irq_chip stm32_gpio_irq_chip = { > >> .name = "stm32gpio", > >> .irq_eoi = stm32_gpio_irq_eoi, > >> .irq_ack = irq_chip_ack_parent, > >> .irq_mask = irq_chip_mask_parent, > >> - .irq_unmask = irq_chip_unmask_parent, > >> + .irq_unmask = stm32_gpio_irq_unmask, > >> .irq_set_type = stm32_gpio_set_type, > >> .irq_set_wake = irq_chip_set_wake_parent, > >> .irq_request_resources = stm32_gpio_irq_request_resources, > >> > > > > OK, I see your problem now. > > > > The usual flow is along the line of Ack+Eoi, and that's what the > > current code guarantees. > > > > Threaded interrupts do Ack+Mask+Eoi, followed by an Unmask once the > > thread finishes. This unmask needs to do the retrigger as well, as you > > found out. > > > > Can you please refactor the above so that we have the common code > > between unmask and eoi in a separate function, send a proper patch, and > > I'll apply it on top of the current irq/irqchip-5.7 branch. > > Sure, I can. Do we still need this retriggering in the irq_eoi too ? Absolutely, because that's what matters for the non-threaded case (there is no mask/unmask on that path). It is also never wrong to over-resample (it just slows things down). > Also, are there any other hidden details I might've missed ? Probably. But let's fix one bug at a time, shall we? ;-) And let's hope that ST doesn't take this as a excuse not to clean up their act in their next SoC! Thanks, M. -- Jazz is not dead. It just smells funny...