[RFC,1/5] dt-bindings: interrupt-controller: renesas,rzg2l-irqc: Document RZ/G2UL SoC
Message ID | 20221107175305.63975-2-prabhakar.mahadev-lad.rj@bp.renesas.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a5d:6687:0:0:0:0:0 with SMTP id l7csp2201781wru; Mon, 7 Nov 2022 09:56:24 -0800 (PST) X-Google-Smtp-Source: AMsMyM6z1ws4eOFwChQbgvwEIjn5S2ZVD0o/07AGodHvQcscQsccbfZPzDD/zeb2FH22FRuTFtEu X-Received: by 2002:a63:5606:0:b0:46f:714d:96ed with SMTP id k6-20020a635606000000b0046f714d96edmr43668505pgb.492.1667843783864; Mon, 07 Nov 2022 09:56:23 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1667843783; cv=none; d=google.com; s=arc-20160816; b=XVOPF8jvt94O5Up7eSNpDg+jzugo/6QGq+tm6HXQOGG9TkhtoD78QzJF2yRVIUBlLe ckVtT/1mo4x88PjYo9Taow8p+NRYIBKU2Rn9Kg84b5BEHT2FIZ04I7TJVL1cgRXtK7Mi 8EfJh990nws4RX7MhZE8a+j/1a/CKF3EMJfFffWJqOyBVoyethvDJ7qHB6cnS00BTP/z NG7+tvowffI0uoN5LfVCqlz7yPMHMABmI0wcr5DV5TdpCAhGX0SHM1kfvxvQh40uWJZB tCVDwFpdjXvV460WEsPadYaGw5z0aFQUvQzQjKoSd8ur1ajwQgIof3qxvaunphX7078h 49HQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from :dkim-signature; bh=fZ1erY58kBlhlkmhk9QjyKuuzmHiyGJEgyZd797XqYk=; b=w5+/T3/24Fgy1C4FurZYPcmQfnYvVLul4vyyUfS95Zs4SaL5THK0x92GyDcYVIiQCT VksLr3T6GZFHiWnORi3MWmpUF1/x8uRNvTPB+hKb0oW6p0lM0vBvX8LHAAxCj9Kl68dK TIkpy1EmbxYi0sBzUzk+QJxn5wxZe7p9gHOsJ/zTmW3WHaLojNHe4KHXOum06PErd2rF Z0ptOX4WiSHPwEPB4O4XUf2xK9t0J3dUcuiPb5bCiMXnRaVkyvDMsn31ayTXCskddStp zKd/fznDqb2bOjyWwO5gxndjjTg6tP08fGO2GfivuMhB86g8VbwQvZeJWBIMBu9mhCr7 XnkQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20210112 header.b=eyrR2GZI; 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: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id l15-20020a170903120f00b00186b3cb49basi4674122plh.202.2022.11.07.09.56.11; Mon, 07 Nov 2022 09:56:23 -0800 (PST) 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=eyrR2GZI; 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 S232076AbiKGRzH (ORCPT <rfc822;hjfbswb@gmail.com> + 99 others); Mon, 7 Nov 2022 12:55:07 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:59236 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232544AbiKGRyN (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Mon, 7 Nov 2022 12:54:13 -0500 Received: from mail-wr1-x42f.google.com (mail-wr1-x42f.google.com [IPv6:2a00:1450:4864:20::42f]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 1D78A2496D; Mon, 7 Nov 2022 09:53:19 -0800 (PST) Received: by mail-wr1-x42f.google.com with SMTP id a14so17403962wru.5; Mon, 07 Nov 2022 09:53:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=fZ1erY58kBlhlkmhk9QjyKuuzmHiyGJEgyZd797XqYk=; b=eyrR2GZIXjzm6iz1blmbSY//jE433W7wwwq2lG3UhlpeoKyc4FvX4tFcR1kQbKyZcA u+Ihdrjp6a2igl3uDxUCDm9QDuGFYXrlf47mAJf2xNSdHQbV3pXOUQKALB0kJEUCSpPz RoHjJR98iRDJE5RDMJCr4zeXP6pQ/EHDhlG7DXz6NS8RRIx9kHz6lVDSEUVWI5qidF9V D2JJaazfYsnjnig902R8l6htT3UgRON2KyxicuqtcN/aK9i3Ri5qfMFgSHARLCl8AfT2 KD45M1FgwaMqfgmfm7wHBhI8EQdxkxiT+jS5zxa5bMO3GcRJoBXdjTYBQtoeed3IXsXb zToQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=fZ1erY58kBlhlkmhk9QjyKuuzmHiyGJEgyZd797XqYk=; b=2fh9QUtC40hUETPDLpz9e9G+aStpzTwyOq9JoBvBs5Jzx9a+IWSmUuX71qFicccZTF GpAFk0h/MzM8Qtg11Or0QJXrTCTXhgYQvo+4Lq5KwN6iWM9VO94/0p6I4eGGc1tYvNgK RIDTPW86oFV4BHr3DXzaITxSUO/4El+An5mvuASqE+tHHxu8UmLrmabuHyquWrwCRotF x97IECGfPtmoZ8i9VPsr15m88oKOj8cAaPw6kedaDqBqzsTP42m9tAIU8c0LBCZzOqNN pLDbqrTdDI84ZEEmy6BoZvs7vHt+OgeQi63yg8A4ujmD2CCvGhP1ldyGDZYCq56LvOdF KCHA== X-Gm-Message-State: ACrzQf0acmkjXoIg2rexpyENOOb3d1PyHESeyi/jmgI+NFxvwnNcSOYI PLed348cs2mNTWaIShN15b0= X-Received: by 2002:a05:6000:10c6:b0:236:6613:a7bd with SMTP id b6-20020a05600010c600b002366613a7bdmr33617622wrx.570.1667843597649; Mon, 07 Nov 2022 09:53:17 -0800 (PST) Received: from prasmi.home ([2a00:23c8:2501:c701:9c45:7ed3:c12e:e25b]) by smtp.gmail.com with ESMTPSA id v4-20020a5d4a44000000b002365254ea42sm8072454wrs.1.2022.11.07.09.53.16 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 07 Nov 2022 09:53:17 -0800 (PST) From: Prabhakar <prabhakar.csengg@gmail.com> X-Google-Original-From: Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com> To: Thomas Gleixner <tglx@linutronix.de>, Marc Zyngier <maz@kernel.org>, Rob Herring <robh+dt@kernel.org>, Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>, Geert Uytterhoeven <geert+renesas@glider.be>, Magnus Damm <magnus.damm@gmail.com>, Linus Walleij <linus.walleij@linaro.org> Cc: linux-gpio@vger.kernel.org, linux-renesas-soc@vger.kernel.org, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, Prabhakar <prabhakar.csengg@gmail.com>, Biju Das <biju.das.jz@bp.renesas.com>, Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com> Subject: [PATCH RFC 1/5] dt-bindings: interrupt-controller: renesas,rzg2l-irqc: Document RZ/G2UL SoC Date: Mon, 7 Nov 2022 17:53:01 +0000 Message-Id: <20221107175305.63975-2-prabhakar.mahadev-lad.rj@bp.renesas.com> X-Mailer: git-send-email 2.25.1 In-Reply-To: <20221107175305.63975-1-prabhakar.mahadev-lad.rj@bp.renesas.com> References: <20221107175305.63975-1-prabhakar.mahadev-lad.rj@bp.renesas.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit 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 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: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1748860963796252901?= X-GMAIL-MSGID: =?utf-8?q?1748860963796252901?= |
Series |
Add IRQC support to RZ/G2UL SoC
|
|
Commit Message
Lad, Prabhakar
Nov. 7, 2022, 5:53 p.m. UTC
From: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com> Document RZ/G2UL (R9A07G043) IRQC bindings. The RZ/G2UL IRQC block is identical to one found on the RZ/G2L SoC. No driver changes are required as generic compatible string "renesas,rzg2l-irqc" will be used as a fallback. Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com> --- Note, renesas,r9a07g043u-irqc is added we have slight difference's compared to RZ/Five - G2UL IRQCHIP (hierarchical IRQ domain) -> GIC where as on RZ/Five we have PLIC (chained interrupt domain) -> RISCV INTC - On the RZ/Five we have additional registers for IRQC block - On the RZ/Five we have BUS_ERR_INT which needs to be handled by IRQC --- .../bindings/interrupt-controller/renesas,rzg2l-irqc.yaml | 1 + 1 file changed, 1 insertion(+)
Comments
On 07/11/2022 18:53, Prabhakar wrote: > From: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com> > > Document RZ/G2UL (R9A07G043) IRQC bindings. The RZ/G2UL IRQC block is > identical to one found on the RZ/G2L SoC. No driver changes are > required as generic compatible string "renesas,rzg2l-irqc" will be > used as a fallback. > > Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com> > --- Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Best regards, Krzysztof
Hi Prabhakar, On Mon, Nov 7, 2022 at 6:53 PM Prabhakar <prabhakar.csengg@gmail.com> wrote: > From: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com> > > Document RZ/G2UL (R9A07G043) IRQC bindings. The RZ/G2UL IRQC block is > identical to one found on the RZ/G2L SoC. No driver changes are > required as generic compatible string "renesas,rzg2l-irqc" will be > used as a fallback. > > Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com> Thanks for your patch! > --- > Note, renesas,r9a07g043u-irqc is added we have slight difference's compared to RZ/Five > - G2UL IRQCHIP (hierarchical IRQ domain) -> GIC where as on RZ/Five we have PLIC (chained interrupt > domain) -> RISCV INTC I think this difference is purely a software difference, and abstracted in DTS through the interrupt hierarchy. Does it have any impact on the bindings? > - On the RZ/Five we have additional registers for IRQC block Indeed, the NMI/IRQ/TINT "Interruput" Mask Control Registers, thus warranting separate compatible values. > - On the RZ/Five we have BUS_ERR_INT which needs to be handled by IRQC Can you please elaborate? I may have missed something, but to me it looks like that is exactly the same on RZ/G2UL and on RZ/Five. > --- a/Documentation/devicetree/bindings/interrupt-controller/renesas,rzg2l-irqc.yaml > +++ b/Documentation/devicetree/bindings/interrupt-controller/renesas,rzg2l-irqc.yaml > @@ -26,6 +26,7 @@ properties: > compatible: > items: > - enum: > + - renesas,r9a07g043u-irqc # RZ/G2UL > - renesas,r9a07g044-irqc # RZ/G2{L,LC} > - renesas,r9a07g054-irqc # RZ/V2L > - const: renesas,rzg2l-irqc Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds
Hi Geert, Thank you for the review. On Thu, Nov 17, 2022 at 10:54 AM Geert Uytterhoeven <geert@linux-m68k.org> wrote: > > Hi Prabhakar, > > On Mon, Nov 7, 2022 at 6:53 PM Prabhakar <prabhakar.csengg@gmail.com> wrote: > > From: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com> > > > > Document RZ/G2UL (R9A07G043) IRQC bindings. The RZ/G2UL IRQC block is > > identical to one found on the RZ/G2L SoC. No driver changes are > > required as generic compatible string "renesas,rzg2l-irqc" will be > > used as a fallback. > > > > Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com> > > Thanks for your patch! > > > --- > > Note, renesas,r9a07g043u-irqc is added we have slight difference's compared to RZ/Five > > - G2UL IRQCHIP (hierarchical IRQ domain) -> GIC where as on RZ/Five we have PLIC (chained interrupt > > domain) -> RISCV INTC > > I think this difference is purely a software difference, and abstracted > in DTS through the interrupt hierarchy. > Does it have any impact on the bindings? > For now I dont know for sure, as I havent started looking into it yet. > > - On the RZ/Five we have additional registers for IRQC block > > Indeed, the NMI/IRQ/TINT "Interruput" Mask Control Registers, thus > warranting separate compatible values. > \o/ > > - On the RZ/Five we have BUS_ERR_INT which needs to be handled by IRQC > > Can you please elaborate? I may have missed something, but to me it > looks like that is exactly the same on RZ/G2UL and on RZ/Five. > I completely missed rz/g2ul had this interrupt too. Cheers, Prabhakar
Hi Geert, On Thu, Nov 17, 2022 at 10:54 AM Geert Uytterhoeven <geert@linux-m68k.org> wrote: > > Hi Prabhakar, > > On Mon, Nov 7, 2022 at 6:53 PM Prabhakar <prabhakar.csengg@gmail.com> wrote: > > From: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com> > > > > Document RZ/G2UL (R9A07G043) IRQC bindings. The RZ/G2UL IRQC block is > > identical to one found on the RZ/G2L SoC. No driver changes are > > required as generic compatible string "renesas,rzg2l-irqc" will be > > used as a fallback. > > > > Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com> > > Thanks for your patch! > > > --- > > Note, renesas,r9a07g043u-irqc is added we have slight difference's compared to RZ/Five > > - G2UL IRQCHIP (hierarchical IRQ domain) -> GIC where as on RZ/Five we have PLIC (chained interrupt > > domain) -> RISCV INTC > > I think this difference is purely a software difference, and abstracted > in DTS through the interrupt hierarchy. > Does it have any impact on the bindings? > > > - On the RZ/Five we have additional registers for IRQC block > > Indeed, the NMI/IRQ/TINT "Interruput" Mask Control Registers, thus > warranting separate compatible values. > > > - On the RZ/Five we have BUS_ERR_INT which needs to be handled by IRQC > > Can you please elaborate? I may have missed something, but to me it > looks like that is exactly the same on RZ/G2UL and on RZ/Five. > Now that we have to update the binding doc with the BUS_ERR_INT too, do you think it would make sense to add interrupt-names too? BUS_ERR_INT will have to be handled IRQC itself (i.e. IRQC will register a handler for it). Cheers, Prabhakar
Hi Geert, On Fri, Nov 18, 2022 at 12:29 PM Lad, Prabhakar <prabhakar.csengg@gmail.com> wrote: > > Hi Geert, > > On Thu, Nov 17, 2022 at 10:54 AM Geert Uytterhoeven > <geert@linux-m68k.org> wrote: > > > > Hi Prabhakar, > > > > On Mon, Nov 7, 2022 at 6:53 PM Prabhakar <prabhakar.csengg@gmail.com> wrote: > > > From: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com> > > > > > > Document RZ/G2UL (R9A07G043) IRQC bindings. The RZ/G2UL IRQC block is > > > identical to one found on the RZ/G2L SoC. No driver changes are > > > required as generic compatible string "renesas,rzg2l-irqc" will be > > > used as a fallback. > > > > > > Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com> > > > > Thanks for your patch! > > > > > --- > > > Note, renesas,r9a07g043u-irqc is added we have slight difference's compared to RZ/Five > > > - G2UL IRQCHIP (hierarchical IRQ domain) -> GIC where as on RZ/Five we have PLIC (chained interrupt > > > domain) -> RISCV INTC > > > > I think this difference is purely a software difference, and abstracted > > in DTS through the interrupt hierarchy. > > Does it have any impact on the bindings? > > > > > - On the RZ/Five we have additional registers for IRQC block > > > > Indeed, the NMI/IRQ/TINT "Interruput" Mask Control Registers, thus > > warranting separate compatible values. > > > > > - On the RZ/Five we have BUS_ERR_INT which needs to be handled by IRQC > > > > Can you please elaborate? I may have missed something, but to me it > > looks like that is exactly the same on RZ/G2UL and on RZ/Five. > > > Now that we have to update the binding doc with the BUS_ERR_INT too, > do you think it would make sense to add interrupt-names too? > > BUS_ERR_INT will have to be handled IRQC itself (i.e. IRQC will > register a handler for it). > Gentle ping. Cheers, Prabhakar
Hi Prabhakar, On Mon, Dec 19, 2022 at 1:57 PM Lad, Prabhakar <prabhakar.csengg@gmail.com> wrote: > On Fri, Nov 18, 2022 at 12:29 PM Lad, Prabhakar > <prabhakar.csengg@gmail.com> wrote: > > On Thu, Nov 17, 2022 at 10:54 AM Geert Uytterhoeven > > <geert@linux-m68k.org> wrote: > > > On Mon, Nov 7, 2022 at 6:53 PM Prabhakar <prabhakar.csengg@gmail.com> wrote: > > > > From: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com> > > > > > > > > Document RZ/G2UL (R9A07G043) IRQC bindings. The RZ/G2UL IRQC block is > > > > identical to one found on the RZ/G2L SoC. No driver changes are > > > > required as generic compatible string "renesas,rzg2l-irqc" will be > > > > used as a fallback. > > > > > > > > Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com> > > > > Note, renesas,r9a07g043u-irqc is added we have slight difference's compared to RZ/Five > > > > - G2UL IRQCHIP (hierarchical IRQ domain) -> GIC where as on RZ/Five we have PLIC (chained interrupt > > > > domain) -> RISCV INTC > > > > > > I think this difference is purely a software difference, and abstracted > > > in DTS through the interrupt hierarchy. > > > Does it have any impact on the bindings? > > > > > > > - On the RZ/Five we have additional registers for IRQC block > > > > > > Indeed, the NMI/IRQ/TINT "Interruput" Mask Control Registers, thus > > > warranting separate compatible values. > > > > > > > - On the RZ/Five we have BUS_ERR_INT which needs to be handled by IRQC > > > > > > Can you please elaborate? I may have missed something, but to me it > > > looks like that is exactly the same on RZ/G2UL and on RZ/Five. > > > > > Now that we have to update the binding doc with the BUS_ERR_INT too, > > do you think it would make sense to add interrupt-names too? > Gentle ping. Thanks for the ping, I had missed you were waiting on input from me. Sorry for that... As there are three different groups of parent interrupts, adding interrupt-names makes sense. However, as this binding is already in active use since v6.1, you probably need to keep on supporting the ack of interrupt-names. Or do you think there are no real users yet, and we can drop support for that? > > BUS_ERR_INT will have to be handled IRQC itself (i.e. IRQC will > > register a handler for it). Do you mean you will need a fourth parent type for that? Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds
Hi Geert, On Mon, Dec 19, 2022 at 1:50 PM Geert Uytterhoeven <geert@linux-m68k.org> wrote: > > Hi Prabhakar, > > On Mon, Dec 19, 2022 at 1:57 PM Lad, Prabhakar > <prabhakar.csengg@gmail.com> wrote: > > On Fri, Nov 18, 2022 at 12:29 PM Lad, Prabhakar > > <prabhakar.csengg@gmail.com> wrote: > > > On Thu, Nov 17, 2022 at 10:54 AM Geert Uytterhoeven > > > <geert@linux-m68k.org> wrote: > > > > On Mon, Nov 7, 2022 at 6:53 PM Prabhakar <prabhakar.csengg@gmail.com> wrote: > > > > > From: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com> > > > > > > > > > > Document RZ/G2UL (R9A07G043) IRQC bindings. The RZ/G2UL IRQC block is > > > > > identical to one found on the RZ/G2L SoC. No driver changes are > > > > > required as generic compatible string "renesas,rzg2l-irqc" will be > > > > > used as a fallback. > > > > > > > > > > Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com> > > > > > > Note, renesas,r9a07g043u-irqc is added we have slight difference's compared to RZ/Five > > > > > - G2UL IRQCHIP (hierarchical IRQ domain) -> GIC where as on RZ/Five we have PLIC (chained interrupt > > > > > domain) -> RISCV INTC > > > > > > > > I think this difference is purely a software difference, and abstracted > > > > in DTS through the interrupt hierarchy. > > > > Does it have any impact on the bindings? > > > > > > > > > - On the RZ/Five we have additional registers for IRQC block > > > > > > > > Indeed, the NMI/IRQ/TINT "Interruput" Mask Control Registers, thus > > > > warranting separate compatible values. > > > > > > > > > - On the RZ/Five we have BUS_ERR_INT which needs to be handled by IRQC > > > > > > > > Can you please elaborate? I may have missed something, but to me it > > > > looks like that is exactly the same on RZ/G2UL and on RZ/Five. > > > > > > > Now that we have to update the binding doc with the BUS_ERR_INT too, > > > do you think it would make sense to add interrupt-names too? > > > Gentle ping. > > Thanks for the ping, I had missed you were waiting on input from me. > Sorry for that... > No worries. > As there are three different groups of parent interrupts, adding > interrupt-names makes sense. Ok. > However, as this binding is already in active use since v6.1, you > probably need to keep on supporting the > ack of interrupt-names. Or do you think there are no real users yet, > and we can drop support for that? > Sorry can you please elaborate on "ack of interrupt-names". So moving forward the driver will first check for interrupt-names property and if that exists it will map the IRQ0-7 and GPIO-TINIT interrupts (based on the names it will create a hierarchy domain) and for the NMI and BUS_ERR_INT we request the IRQ numbers and register the IRQ handler in IRQC driver itself. And for backward compatibility we parse the IRQ numbers based on indexes i.e. 0 = NMI, 1-8 = IRQ 0-7 and 9-41 GPIO TINT interrupts. > > > BUS_ERR_INT will have to be handled IRQC itself (i.e. IRQC will > > > register a handler for it). > > Do you mean you will need a fourth parent type for that? > No something like what we have for NMI we can add something similar below for bus error interrupts: interrupts = .... <GIC_SPI 57 IRQ_TYPE_EDGE_RISING>; interrupt-names = ...., "bus-error-int"; As the registers to handle the NMI and BUS_ERR_INT are present on the IRQC block, the interrupt handler will have to be registered by the IRQC block itself by requesting the IRQ. So we will have to skip mapping of BUS_ERR_INT as we do for the NMI case. Does that make sense? Cheers, Prabhakar
Hi Prabhakar, On Mon, Dec 19, 2022 at 3:26 PM Lad, Prabhakar <prabhakar.csengg@gmail.com> wrote: > On Mon, Dec 19, 2022 at 1:50 PM Geert Uytterhoeven <geert@linux-m68k.org> wrote: > > On Mon, Dec 19, 2022 at 1:57 PM Lad, Prabhakar > > <prabhakar.csengg@gmail.com> wrote: > > > On Fri, Nov 18, 2022 at 12:29 PM Lad, Prabhakar > > > <prabhakar.csengg@gmail.com> wrote: > > > > On Thu, Nov 17, 2022 at 10:54 AM Geert Uytterhoeven > > > > <geert@linux-m68k.org> wrote: > > > > > On Mon, Nov 7, 2022 at 6:53 PM Prabhakar <prabhakar.csengg@gmail.com> wrote: > > > > > > From: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com> > > > > > > > > > > > > Document RZ/G2UL (R9A07G043) IRQC bindings. The RZ/G2UL IRQC block is > > > > > > identical to one found on the RZ/G2L SoC. No driver changes are > > > > > > required as generic compatible string "renesas,rzg2l-irqc" will be > > > > > > used as a fallback. > > > > > > > > > > > > Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com> > > > > > > > > Note, renesas,r9a07g043u-irqc is added we have slight difference's compared to RZ/Five > > > > > > - G2UL IRQCHIP (hierarchical IRQ domain) -> GIC where as on RZ/Five we have PLIC (chained interrupt > > > > > > domain) -> RISCV INTC > > > > > > > > > > I think this difference is purely a software difference, and abstracted > > > > > in DTS through the interrupt hierarchy. > > > > > Does it have any impact on the bindings? > > > > > > > > > > > - On the RZ/Five we have additional registers for IRQC block > > > > > > > > > > Indeed, the NMI/IRQ/TINT "Interruput" Mask Control Registers, thus > > > > > warranting separate compatible values. > > > > > > > > > > > - On the RZ/Five we have BUS_ERR_INT which needs to be handled by IRQC > > > > > > > > > > Can you please elaborate? I may have missed something, but to me it > > > > > looks like that is exactly the same on RZ/G2UL and on RZ/Five. > > > > > > > > > Now that we have to update the binding doc with the BUS_ERR_INT too, > > > > do you think it would make sense to add interrupt-names too? > > > > > Gentle ping. > > > > Thanks for the ping, I had missed you were waiting on input from me. > > Sorry for that... > > > No worries. > > > As there are three different groups of parent interrupts, adding > > interrupt-names makes sense. > Ok. > > > However, as this binding is already in active use since v6.1, you > > probably need to keep on supporting the > > ack of interrupt-names. Or do you think there are no real users yet, > > and we can drop support for that? > > > Sorry can you please elaborate on "ack of interrupt-names". Oops, s/ack/lack/. I.e. what you described below. > So moving forward the driver will first check for interrupt-names > property and if that exists it will map the IRQ0-7 and GPIO-TINIT > interrupts (based on the names it will create a hierarchy domain) and > for the NMI and BUS_ERR_INT we request the IRQ numbers and register > the IRQ handler in IRQC driver itself. > > And for backward compatibility we parse the IRQ numbers based on > indexes i.e. 0 = NMI, 1-8 = IRQ 0-7 and 9-41 GPIO TINT interrupts. Exactly. > > > > BUS_ERR_INT will have to be handled IRQC itself (i.e. IRQC will > > > > register a handler for it). > > > > Do you mean you will need a fourth parent type for that? > > > No something like what we have for NMI we can add something similar > below for bus error interrupts: > interrupts = .... > <GIC_SPI 57 IRQ_TYPE_EDGE_RISING>; > interrupt-names = ...., > "bus-error-int"; Hence a fourth name? 1. legacy index 0 -> "nmi" 2. legacy indices 1-8 -> "irq%u" (0-7) 3. legacy indices 9-41 -> "tint%u" (0-31) 4. (not supported) -> "bus-error-int" (or "bus-err"?) > As the registers to handle the NMI and BUS_ERR_INT are present on the > IRQC block, the interrupt handler will have to be registered by the > IRQC block itself by requesting the IRQ. So we will have to skip > mapping of BUS_ERR_INT as we do for the NMI case. Does that make > sense? OK. BTW, that means RZG2L_NMI from <dt-bindings/interrupt-controller/irqc-rzg2l.h> will never be used? Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds
Hi Geert, On Mon, Dec 19, 2022 at 2:47 PM Geert Uytterhoeven <geert@linux-m68k.org> wrote: > > Hi Prabhakar, > > On Mon, Dec 19, 2022 at 3:26 PM Lad, Prabhakar > <prabhakar.csengg@gmail.com> wrote: > > On Mon, Dec 19, 2022 at 1:50 PM Geert Uytterhoeven <geert@linux-m68k.org> wrote: > > > On Mon, Dec 19, 2022 at 1:57 PM Lad, Prabhakar > > > <prabhakar.csengg@gmail.com> wrote: > > > > On Fri, Nov 18, 2022 at 12:29 PM Lad, Prabhakar > > > > <prabhakar.csengg@gmail.com> wrote: > > > > > On Thu, Nov 17, 2022 at 10:54 AM Geert Uytterhoeven > > > > > <geert@linux-m68k.org> wrote: > > > > > > On Mon, Nov 7, 2022 at 6:53 PM Prabhakar <prabhakar.csengg@gmail.com> wrote: > > > > > > > From: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com> > > > > > > > > > > > > > > Document RZ/G2UL (R9A07G043) IRQC bindings. The RZ/G2UL IRQC block is > > > > > > > identical to one found on the RZ/G2L SoC. No driver changes are > > > > > > > required as generic compatible string "renesas,rzg2l-irqc" will be > > > > > > > used as a fallback. > > > > > > > > > > > > > > Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com> > > > > > > > > > > Note, renesas,r9a07g043u-irqc is added we have slight difference's compared to RZ/Five > > > > > > > - G2UL IRQCHIP (hierarchical IRQ domain) -> GIC where as on RZ/Five we have PLIC (chained interrupt > > > > > > > domain) -> RISCV INTC > > > > > > > > > > > > I think this difference is purely a software difference, and abstracted > > > > > > in DTS through the interrupt hierarchy. > > > > > > Does it have any impact on the bindings? > > > > > > > > > > > > > - On the RZ/Five we have additional registers for IRQC block > > > > > > > > > > > > Indeed, the NMI/IRQ/TINT "Interruput" Mask Control Registers, thus > > > > > > warranting separate compatible values. > > > > > > > > > > > > > - On the RZ/Five we have BUS_ERR_INT which needs to be handled by IRQC > > > > > > > > > > > > Can you please elaborate? I may have missed something, but to me it > > > > > > looks like that is exactly the same on RZ/G2UL and on RZ/Five. > > > > > > > > > > > Now that we have to update the binding doc with the BUS_ERR_INT too, > > > > > do you think it would make sense to add interrupt-names too? > > > > > > > Gentle ping. > > > > > > Thanks for the ping, I had missed you were waiting on input from me. > > > Sorry for that... > > > > > No worries. > > > > > As there are three different groups of parent interrupts, adding > > > interrupt-names makes sense. > > Ok. > > > > > However, as this binding is already in active use since v6.1, you > > > probably need to keep on supporting the > > > ack of interrupt-names. Or do you think there are no real users yet, > > > and we can drop support for that? > > > > > Sorry can you please elaborate on "ack of interrupt-names". > > Oops, s/ack/lack/. I.e. what you described below. > Got that. > > So moving forward the driver will first check for interrupt-names > > property and if that exists it will map the IRQ0-7 and GPIO-TINIT > > interrupts (based on the names it will create a hierarchy domain) and > > for the NMI and BUS_ERR_INT we request the IRQ numbers and register > > the IRQ handler in IRQC driver itself. > > > > And for backward compatibility we parse the IRQ numbers based on > > indexes i.e. 0 = NMI, 1-8 = IRQ 0-7 and 9-41 GPIO TINT interrupts. > > Exactly. > > > > > > BUS_ERR_INT will have to be handled IRQC itself (i.e. IRQC will > > > > > register a handler for it). > > > > > > Do you mean you will need a fourth parent type for that? > > > > > No something like what we have for NMI we can add something similar > > below for bus error interrupts: > > interrupts = .... > > <GIC_SPI 57 IRQ_TYPE_EDGE_RISING>; > > interrupt-names = ...., > > "bus-error-int"; > > Hence a fourth name? > Agreed. > 1. legacy index 0 -> "nmi" > 2. legacy indices 1-8 -> "irq%u" (0-7) > 3. legacy indices 9-41 -> "tint%u" (0-31) > 4. (not supported) -> "bus-error-int" (or "bus-err"?) > "bus-err" I think based on previous experience ;) While I am at it I'll expand the interrupts property with descriptions. > > As the registers to handle the NMI and BUS_ERR_INT are present on the > > IRQC block, the interrupt handler will have to be registered by the > > IRQC block itself by requesting the IRQ. So we will have to skip > > mapping of BUS_ERR_INT as we do for the NMI case. Does that make > > sense? > > OK. > > BTW, that means RZG2L_NMI from <dt-bindings/interrupt-controller/irqc-rzg2l.h> > will never be used? > Agreed, that needs to be dropped. Cheers, Prabhakar
diff --git a/Documentation/devicetree/bindings/interrupt-controller/renesas,rzg2l-irqc.yaml b/Documentation/devicetree/bindings/interrupt-controller/renesas,rzg2l-irqc.yaml index 33b90e975e33..8f3678a82ba4 100644 --- a/Documentation/devicetree/bindings/interrupt-controller/renesas,rzg2l-irqc.yaml +++ b/Documentation/devicetree/bindings/interrupt-controller/renesas,rzg2l-irqc.yaml @@ -26,6 +26,7 @@ properties: compatible: items: - enum: + - renesas,r9a07g043u-irqc # RZ/G2UL - renesas,r9a07g044-irqc # RZ/G2{L,LC} - renesas,r9a07g054-irqc # RZ/V2L - const: renesas,rzg2l-irqc