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.2 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, INCLUDES_PATCH,MAILING_LIST_MULTI,SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED,USER_AGENT_SANE_1 autolearn=unavailable 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 88341C3F2CD for ; Mon, 23 Mar 2020 19:38:02 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 6A94F2051A for ; Mon, 23 Mar 2020 19:38:02 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1725899AbgCWTiB (ORCPT ); Mon, 23 Mar 2020 15:38:01 -0400 Received: from mail-out.m-online.net ([212.18.0.10]:48132 "EHLO mail-out.m-online.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725710AbgCWTiA (ORCPT ); Mon, 23 Mar 2020 15:38:00 -0400 Received: from frontend01.mail.m-online.net (unknown [192.168.8.182]) by mail-out.m-online.net (Postfix) with ESMTP id 48mPmh58Qkz1rrKb; Mon, 23 Mar 2020 20:37:56 +0100 (CET) Received: from localhost (dynscan1.mnet-online.de [192.168.6.70]) by mail.m-online.net (Postfix) with ESMTP id 48mPmh3dmXz1qyDd; Mon, 23 Mar 2020 20:37:56 +0100 (CET) X-Virus-Scanned: amavisd-new at mnet-online.de Received: from mail.mnet-online.de ([192.168.8.182]) by localhost (dynscan1.mail.m-online.net [192.168.6.70]) (amavisd-new, port 10024) with ESMTP id la4VWb-ZJ090; Mon, 23 Mar 2020 20:37:55 +0100 (CET) X-Auth-Info: 2HAWIBbYvus5V2XKLd5HdN0JKCCAwwqp/nMJ0D/R/6c= Received: from [IPv6:::1] (unknown [195.140.253.167]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.mnet-online.de (Postfix) with ESMTPSA; Mon, 23 Mar 2020 20:37:55 +0100 (CET) Subject: Re: [PATCH v3 2/2] pinctrl: stm32: Add level interrupt support to gpio irq chip To: Marc Zyngier Cc: Linus Walleij , Alexandre Torgue , Thomas Gleixner , Jason Cooper , Linux ARM , linux-kernel@vger.kernel.org, "open list:GPIO SUBSYSTEM" 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> From: Marek Vasut Message-ID: <8e2795d8-4a8b-35a7-7d3f-e24d011878f6@denx.de> Date: Mon, 23 Mar 2020 20:37:54 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.5.0 MIME-Version: 1.0 In-Reply-To: <20200323193157.038f36f9@why> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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 ? Also, are there any other hidden details I might've missed ?