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=-17.2 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER, INCLUDES_PATCH,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,USER_AGENT_GIT 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 5067AC11F66 for ; Tue, 29 Jun 2021 13:19:19 +0000 (UTC) Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 1FD7D61DCB for ; Tue, 29 Jun 2021 13:19:19 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 1FD7D61DCB Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=arm.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:MIME-Version:References:In-Reply-To: Message-Id:Date:Subject:Cc:To:From:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=hNWfMO5hVB7/sGVAy469PfHtEk0a8qzMJhhtWDWjrkw=; b=tK5e1nRrY+csn1 C3ZkKZqO9+zK6Ivz9aW0MxgGqG7jd2PKPaMe1TRWtCVg0BN4b5i8narScTlnzhyKtVxvOYohm9+a6 sDj3cmycOsQajysU2AJaNx6hwMGO9YUKQy1E3/LEci8E6ZAzjmHhPuKe9/4O4l06N2sJ8DTwRk0sR nO57nBKhde18ol/NvN1oDygxq5xAslU1aKAfSA2GcljVbzm+lxZGmXj6x0iC8GM9RnXkaOluGsZJr 6wTjxJOLFpjd4nlH4nmols3tc7YeH7o1MWiccaUlNSd5If6tJ9iUfBfAoQtpAMzmq6EjpfTVWcmED FwDZipqao/EAVhX/+1OA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1lyDbw-00AyeR-Rc; Tue, 29 Jun 2021 13:17:10 +0000 Received: from foss.arm.com ([217.140.110.172]) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1lyDCX-00AsyF-TI for linux-arm-kernel@lists.infradead.org; Tue, 29 Jun 2021 12:50:59 +0000 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 5DDA6139F; Tue, 29 Jun 2021 05:50:51 -0700 (PDT) Received: from e113632-lin.cambridge.arm.com (e113632-lin.cambridge.arm.com [10.1.194.46]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPA id 5CE313F718; Tue, 29 Jun 2021 05:50:50 -0700 (PDT) From: Valentin Schneider To: linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org Cc: Marc Zyngier , Thomas Gleixner , Lorenzo Pieralisi , Vincenzo Frascino Subject: [PATCH v3 04/13] genirq: Add handle_strict_flow_irq() flow handler Date: Tue, 29 Jun 2021 13:50:01 +0100 Message-Id: <20210629125010.458872-5-valentin.schneider@arm.com> X-Mailer: git-send-email 2.25.1 In-Reply-To: <20210629125010.458872-1-valentin.schneider@arm.com> References: <20210629125010.458872-1-valentin.schneider@arm.com> MIME-Version: 1.0 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20210629_055054_091143_7F83E269 X-CRM114-Status: GOOD ( 17.19 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org The GIC family of irqchips have been so far treated as "fasteoi" chips. As handle_fasteoi_irq() states, this implies: * Only a single callback will be issued to the chip: an ->eoi() * call when the interrupt has been serviced. However, the GICs have an operating mode (EOImode=1) which requires an additional chip interaction during the IRQ handling. Said operating mode already has some uses with virtualization, but could also be leveraged to slightly optimize ONESHOT IRQs. This extra interaction is currently hidden away in the drivers, but further exploiting its effects (see IRQD_IRQ_FLOW_MASKED) requires lifting it from the driver code into core code. It so happens that it fits the role of ->irq_ack(); unfortunately, the GICs require both callbacks to be strictly paired with one another: for a given IRQ activation, there must be a single ->irq_ack() followed by a single ->irq_eoi(). No more, no less, and in that order. Introduce a new flow handler which guarantees said ack / eoi pairing. Note that it is strikingly similar to handle_fasteoi_mask_irq() for now, but will be further modified in later patches Signed-off-by: Valentin Schneider --- include/linux/irq.h | 1 + kernel/irq/chip.c | 48 +++++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 49 insertions(+) diff --git a/include/linux/irq.h b/include/linux/irq.h index ef179245a642..37075929e329 100644 --- a/include/linux/irq.h +++ b/include/linux/irq.h @@ -663,6 +663,7 @@ extern void handle_edge_irq(struct irq_desc *desc); extern void handle_edge_eoi_irq(struct irq_desc *desc); extern void handle_simple_irq(struct irq_desc *desc); extern void handle_untracked_irq(struct irq_desc *desc); +extern void handle_strict_flow_irq(struct irq_desc *desc); extern void handle_percpu_irq(struct irq_desc *desc); extern void handle_percpu_devid_irq(struct irq_desc *desc); extern void handle_bad_irq(struct irq_desc *desc); diff --git a/kernel/irq/chip.c b/kernel/irq/chip.c index 4d3bde55c5d9..699e70b51aae 100644 --- a/kernel/irq/chip.c +++ b/kernel/irq/chip.c @@ -896,6 +896,54 @@ void handle_edge_eoi_irq(struct irq_desc *desc) } #endif +/** + * handle_strict_flow_irq - irq handler for strict controllers + * @desc: the interrupt description structure for this irq + * + * Ensures strict pairing of ->ack() and ->eoi() for any IRQ passing + * through here. The ->eoi() may be deferred to the tail of the IRQ thread + * for ONESHOT IRQs. + */ +void handle_strict_flow_irq(struct irq_desc *desc) +{ + struct irq_chip *chip = desc->irq_data.chip; + + raw_spin_lock(&desc->lock); + mask_ack_irq(desc); + + if (!irq_may_run(desc)) + goto out; + + desc->istate &= ~(IRQS_REPLAY | IRQS_WAITING); + + /* + * If it's disabled or no action available then keep it masked and + * get out of here: + */ + if (unlikely(!desc->action || irqd_irq_disabled(&desc->irq_data))) { + desc->istate |= IRQS_PENDING; + goto out; + } + + kstat_incr_irqs_this_cpu(desc); + + handle_irq_event(desc); + + cond_unmask_eoi_irq(desc, chip); + + raw_spin_unlock(&desc->lock); + return; +out: + /* + * XXX: this is where IRQCHIP_EOI_IF_HANDLED would be checked, but + * it's conceptually incompatible with this handler (it breaks the + * strict pairing) + */ + eoi_irq(desc); + raw_spin_unlock(&desc->lock); +} +EXPORT_SYMBOL_GPL(handle_strict_flow_irq); + /** * handle_percpu_irq - Per CPU local irq handler * @desc: the interrupt description structure for this irq -- 2.25.1 _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel