Received: by 2002:a5d:9c59:0:0:0:0:0 with SMTP id 25csp1724801iof; Tue, 7 Jun 2022 10:19:47 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzZhfNGjjuEngfUzAMVt5nSFUFx+ubyBq2hctkHUw4bIH0XaBb/ETjg7AGIN5PsI9DjlQz6 X-Received: by 2002:a17:902:6b08:b0:165:fd6:6abd with SMTP id o8-20020a1709026b0800b001650fd66abdmr29942280plk.152.1654622387633; Tue, 07 Jun 2022 10:19:47 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1654622387; cv=none; d=google.com; s=arc-20160816; b=jKWHMjwPAG/vl4bXI5rVNvGAVBosghTWvxhqpdIARuo7grQhaW9sP6w35BB5ZTWKp5 9pGiMlVTHpBahVCkJlQg5LsVColGa/IFVy5gMiF+V2hnCN/THUdHpdAaQD/+0xk9Vllh puD+Nc65W67uygX2S8LXRT8JPu09c7nZp5utULGC/sUHSFluV1uILYVFuuoE7hpPOAAz ghDPR8CGZ+iM6rgVhAH8bpb9ki3Ik142HoyO1OF0Fg66TeWcV7Q0PQYOrTiW6Nrn0et9 Ncv2fh+ltYwlT0W+QGN5FGHRi0xJ7TBJ7Y7o/m5F1YR9Ipo4sqxnQLJoFY0DDP4lhBpC LQmg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:dkim-signature; bh=imu3RAy17O3xYzLzj29191Uurx3QbXXQ67LBoXgR1Ss=; b=Y171xLv4N5Wpfns+QOS+fr1VQr8Tg2bMsR60srFtzDf9Q+RnUyoBm9lAlhl6n0Hel7 nyaSEQdWU0dnkUmmcAPe2DoCzpZr6wyKgx41hDdStnFnoA6khlgaQQYZNZSqWIFYTPqZ cIdZRkmCIuJfWEtyBw+U7sDWhx0NZCh5XBe98sT5Dm0pa50kcczYZb/xmhqstL/ESRpP IMq4ec2LrOAXT5d7k1BZfHiNdbNaFDlR+0/vDLz9j4FdD3fIbgag5XHExCfo+4T2DHiw Xa2OxX05ZNHDX2Ak7TAvfHB8xgWf6n0orw6oEk2nHCHmzaSr8QHjmKJxelq+nNjm7/RA SaTw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20210112 header.b=GYjKq01x; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id t5-20020a654085000000b003fc522899e6si25566773pgp.258.2022.06.07.10.19.34; Tue, 07 Jun 2022 10:19:47 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20210112 header.b=GYjKq01x; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S244025AbiFGMlr (ORCPT + 99 others); Tue, 7 Jun 2022 08:41:47 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:45470 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S244024AbiFGMlp (ORCPT ); Tue, 7 Jun 2022 08:41:45 -0400 Received: from mail-yw1-x1129.google.com (mail-yw1-x1129.google.com [IPv6:2607:f8b0:4864:20::1129]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id DF45A63B2; Tue, 7 Jun 2022 05:41:43 -0700 (PDT) Received: by mail-yw1-x1129.google.com with SMTP id 00721157ae682-3135519f95fso3833747b3.6; Tue, 07 Jun 2022 05:41:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=imu3RAy17O3xYzLzj29191Uurx3QbXXQ67LBoXgR1Ss=; b=GYjKq01x7+sad07xx8Ceb64jKJzc+op9gTL5tI/tHOFKpwr2FveRdU2xCwrgCtW8aM ZWxVLWwI219sDRARMit+S0FpI/ZkHohtZbY3jv5LNZWrWq+B4q9gwd1Yw3sfMV1Os3I6 U71+WxuNQlEPL3uhtZyJEQNo3mifSD8qaKdwfZnzM0hS3MxnG3mvEV61F6eU/zaH89OG f4yD+KYcPXaiRSn5QRTVRzJ26UQoUhFN7vCBVNI+mIr6tH0LeVF3criKWWp3aYww8flI B7/HzeDPnzZRPgUR6UohXs8NSHwiPksJtYwarMfSHMv5cBjAx5rEuc3zChWGZBcbyig4 47Sg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=imu3RAy17O3xYzLzj29191Uurx3QbXXQ67LBoXgR1Ss=; b=4Kte6ucXwbHDJ0Dt8mg6WFgg6Yw0NCEbZffFASerXy86EzrYayWquvjIIumewP24p1 tI5WWj2McBz6hjLiZTXXLKUQ7LE6CyKpmEmdM84rSz5DX+oo3+WSS122yJkyuzdY/vpe k/dGS8jP5qX/uSEMpIyB67yFtC/+PIcVl5/HbVM3cs9R+jx0a8oBB2M55lstU/XdIpAy 6upaJEC2uf3LrsEUMK7KS8epPamg50Ja0HkcbEaT0rB7g4PMc9skq5VG0AWd47ukW0Cv DCp1sBYwip5fTEHmAbx+7wXini+VM9NOZQYNQ8/8P2HsrZdJAUVoVRTlTtDtPvVlppF4 neiw== X-Gm-Message-State: AOAM531SBjt9fxMRgDnrmsLVILWnPZARX/4az6wO3v9DmypRelCVMRlK wUkTlUfYDfFcHRrD/DKEmdHS00/CxfZejXL9wY0= X-Received: by 2002:a81:6d89:0:b0:313:43b6:e9aa with SMTP id i131-20020a816d89000000b0031343b6e9aamr2418963ywc.119.1654605702912; Tue, 07 Jun 2022 05:41:42 -0700 (PDT) MIME-Version: 1.0 References: <20220524172214.5104-1-prabhakar.mahadev-lad.rj@bp.renesas.com> <20220524172214.5104-3-prabhakar.mahadev-lad.rj@bp.renesas.com> <87r1414x5f.wl-maz@kernel.org> In-Reply-To: <87r1414x5f.wl-maz@kernel.org> From: "Lad, Prabhakar" Date: Tue, 7 Jun 2022 13:41:16 +0100 Message-ID: Subject: Re: [PATCH RFC 2/2] irqchip/sifive-plic: Add support for Renesas RZ/Five SoC To: Marc Zyngier Cc: Geert Uytterhoeven , Lad Prabhakar , Thomas Gleixner , Rob Herring , Krzysztof Kozlowski , Palmer Dabbelt , Paul Walmsley , Sagar Kadam , "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" , linux-riscv , LKML , Linux-Renesas , Phil Edworthy , Biju Das Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM, RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Marc, On Mon, Jun 6, 2022 at 4:41 PM Marc Zyngier wrote: > > On Fri, 27 May 2022 12:05:38 +0100, > "Lad, Prabhakar" wrote: > > > > Hi, > > > > On Tue, May 24, 2022 at 6:22 PM Lad Prabhakar > > wrote: > > > > > > The Renesas RZ/Five SoC has a RISC-V AX45MP AndesCore with NCEPLIC100. The > > > NCEPLIC100 supports both edge-triggered and level-triggered interrupts. In > > > case of edge-triggered interrupts NCEPLIC100 ignores the next interrupt > > > edge until the previous completion message has been received and > > > NCEPLIC100 doesn't support pending interrupt counter, hence losing the > > > interrupts if not acknowledged in time. > > > > > > So the workaround for edge-triggered interrupts to be handled correctly > > > and without losing is that it needs to be acknowledged first and then > > > handler must be run so that we don't miss on the next edge-triggered > > > interrupt. > > > > > > This patch adds a new compatible string for Renesas RZ/Five SoC and adds > > > support to change interrupt flow based on the interrupt type. It also > > > implements irq_ack and irq_set_type callbacks. > > > > > > Signed-off-by: Lad Prabhakar > > > --- > > > drivers/irqchip/Kconfig | 1 + > > > drivers/irqchip/irq-sifive-plic.c | 71 ++++++++++++++++++++++++++++++- > > > 2 files changed, 70 insertions(+), 2 deletions(-) > > > > > > diff --git a/drivers/irqchip/Kconfig b/drivers/irqchip/Kconfig > > > index f3d071422f3b..aea0e4e7e547 100644 > > > --- a/drivers/irqchip/Kconfig > > > +++ b/drivers/irqchip/Kconfig > > > @@ -537,6 +537,7 @@ config SIFIVE_PLIC > > > bool "SiFive Platform-Level Interrupt Controller" > > > depends on RISCV > > > select IRQ_DOMAIN_HIERARCHY > > > + select IRQ_FASTEOI_HIERARCHY_HANDLERS > > > help > > > This enables support for the PLIC chip found in SiFive (and > > > potentially other) RISC-V systems. The PLIC controls devices > > > diff --git a/drivers/irqchip/irq-sifive-plic.c b/drivers/irqchip/irq-sifive-plic.c > > > index bb87e4c3b88e..abffce48e69c 100644 > > > --- a/drivers/irqchip/irq-sifive-plic.c > > > +++ b/drivers/irqchip/irq-sifive-plic.c > > > @@ -60,10 +60,13 @@ > > > #define PLIC_DISABLE_THRESHOLD 0x7 > > > #define PLIC_ENABLE_THRESHOLD 0 > > > > > > +#define RENESAS_R9A07G043_PLIC 1 > > > + > > > struct plic_priv { > > > struct cpumask lmask; > > > struct irq_domain *irqdomain; > > > void __iomem *regs; > > > + u8 of_data; > > > }; > > > > > > struct plic_handler { > > > @@ -163,10 +166,31 @@ static int plic_set_affinity(struct irq_data *d, > > > } > > > #endif > > > > > > +static void plic_irq_ack(struct irq_data *d) > > > +{ > > > + struct plic_handler *handler = this_cpu_ptr(&plic_handlers); > > > + > > > + if (irqd_irq_masked(d)) { > > > + plic_irq_unmask(d); > > > + writel(d->hwirq, handler->hart_base + CONTEXT_CLAIM); > > > + plic_irq_mask(d); > > > + } else { > > > + writel(d->hwirq, handler->hart_base + CONTEXT_CLAIM); > > > + } > > > +} > > > + > > I sometimes still see an interrupt miss! > > > > As per [0], we first need to claim the interrupt by reading the claim > > register which needs to be done in the ack callback (which should be > > doable) for edge interrupts, but the problem arises in the chained > > handler callback where it does claim the interrupt by reading the > > claim register. > > > > static void plic_handle_irq(struct irq_desc *desc) > > { > > struct plic_handler *handler = this_cpu_ptr(&plic_handlers); > > struct irq_chip *chip = irq_desc_get_chip(desc); > > void __iomem *claim = handler->hart_base + CONTEXT_CLAIM; > > irq_hw_number_t hwirq; > > > > WARN_ON_ONCE(!handler->present); > > > > chained_irq_enter(chip, desc); > > > > while ((hwirq = readl(claim))) { > > int err = generic_handle_domain_irq(handler->priv->irqdomain, > > hwirq); > > if (unlikely(err)) > > pr_warn_ratelimited("can't find mapping for hwirq %lu\n", > > hwirq); > > } > > > > chained_irq_exit(chip, desc); > > } > > > > I was thinking I would get around by getting the irqdata in > > plic_handle_irq() callback using the irq_desc (struct irq_data *d = > > &desc->irq_data;) and check the d->hwirq but this will be always 9. > > > > plic: interrupt-controller@12c00000 { > > compatible = "renesas-r9a07g043-plic"; > > #interrupt-cells = <2>; > > #address-cells = <0>; > > riscv,ndev = <543>; > > interrupt-controller; > > reg = <0x0 0x12c00000 0 0x400000>; > > clocks = <&cpg CPG_MOD R9A07G043_NCEPLIC_ACLK>; > > clock-names = "plic100ss"; > > power-domains = <&cpg>; > > resets = <&cpg R9A07G043_NCEPLIC_ARESETN>; > > interrupts-extended = <&cpu0_intc 11 &cpu0_intc 9>; > > }; > > > > Any pointers on how this could be done sanely. > > Why doesn't the chained interrupt also get the ack-aware irq_chip? > Sorry for being naive, could you please elaborate on this. Cheers, Prabhakar > M. > > -- > Without deviation from the norm, progress is not possible.