Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 48454C4332F for ; Mon, 6 Dec 2021 10:26:45 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S237721AbhLFKaM (ORCPT ); Mon, 6 Dec 2021 05:30:12 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:45070 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231287AbhLFKaK (ORCPT ); Mon, 6 Dec 2021 05:30:10 -0500 Received: from ams.source.kernel.org (ams.source.kernel.org [IPv6:2604:1380:4601:e00::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 5E20AC061746; Mon, 6 Dec 2021 02:26:42 -0800 (PST) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id AB46DB81059; Mon, 6 Dec 2021 10:26:40 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 5CA32C341C2; Mon, 6 Dec 2021 10:26:39 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1638786399; bh=vchL0exgypXeLVmbDjGhhC/0ASb7p1CByasQVsC649g=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=aqZuPg3VTYKEMfFlWFO80TQHKYaJtAEyqoNq64R155H4xfExmfaJnZwx9ff0Udc+6 MpqXfWIsKGGWHUhOZOmip3HHBgff2gKTlSqwwWx1lpczjkapo2gsavlJNjl9oQdMzB qjYHlcJZ5G55krvyE0uvP8XG5F3Q+EJ2NKwParUl/9S6JOSdg4tIS58qvMKqKID+Ap ypLupHJJVSVDAD85NLxRfcERdx9XR7X3NT+mDUTATQPKVTW4QpAbqer7UNEROXwic0 0pBjJ4FCGkbelA1xkehb727x91SeRJB+309xvnp+L1Prfth206gSo07vWYkeQPZBQR KasMdXycl6zAQ== Received: from sofa.misterjones.org ([185.219.108.64] helo=why.misterjones.org) by disco-boy.misterjones.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1muBCf-00A94d-BG; Mon, 06 Dec 2021 10:26:37 +0000 Date: Mon, 06 Dec 2021 10:26:37 +0000 Message-ID: <87y24y112a.wl-maz@kernel.org> From: Marc Zyngier To: "Lad, Prabhakar" Cc: Rob Herring , Geert Uytterhoeven , Prabhakar Mahadev Lad , "linux-kernel@vger.kernel.org" , "devicetree@vger.kernel.org" , "kernel-team@android.com" , John Crispin , Biwen Li , Chris Brandt , "linux-renesas-soc@vger.kernel.org" Subject: Re: [PATCH] of/irq: Add a quirk for controllers with their own definition of interrupt-map In-Reply-To: References: <20211122103032.517923-1-maz@kernel.org> <8735no70tt.wl-maz@kernel.org> <87tug3clvc.wl-maz@kernel.org> <87r1b7ck40.wl-maz@kernel.org> <87tufvmes9.wl-maz@kernel.org> <87bl21mqwk.wl-maz@kernel.org> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM-LB/1.14.9 (=?UTF-8?B?R29qxY0=?=) APEL-LB/10.8 EasyPG/1.0.0 Emacs/27.1 (x86_64-pc-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-SA-Exim-Connect-IP: 185.219.108.64 X-SA-Exim-Rcpt-To: prabhakar.csengg@gmail.com, robh@kernel.org, geert@linux-m68k.org, prabhakar.mahadev-lad.rj@bp.renesas.com, linux-kernel@vger.kernel.org, devicetree@vger.kernel.org, kernel-team@android.com, john@phrozen.org, biwen.li@nxp.com, Chris.Brandt@renesas.com, linux-renesas-soc@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 Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sun, 05 Dec 2021 22:27:35 +0000, "Lad, Prabhakar" wrote: > > On Wed, Dec 1, 2021 at 4:16 PM Lad, Prabhakar > wrote: > > > > On Wed, Dec 1, 2021 at 2:36 PM Rob Herring wrote: > > > > > > On Wed, Dec 1, 2021 at 7:37 AM Lad, Prabhakar > > > wrote: > > > > > > > > Hi Marc/Rob, > > > > > > > > On Tue, Nov 30, 2021 at 6:37 PM Marc Zyngier wrote: > > > > > > > > > > On Tue, 30 Nov 2021 12:52:21 +0000, > > > > > "Lad, Prabhakar" wrote: > > > > > > > > > > > > On Mon, Nov 29, 2021 at 6:33 PM Rob Herring wrote: > > > > > > > > > > > > > > interrupts would work just fine here: > > > > > > > > > > > > > > interrupts = , > > > > > > > , > > > > > > > , > > > > > > > , > > > > > > > , > > > > > > > , > > > > > > > , > > > > > > > ; > > > > > > > > > > > > > > We don't need a different solution for N:1 interrupts from N:M. Sure, > > > > > > > that could become unweldy if there are a lot of interrupts (just like > > > > > > > interrupt-map), but is that an immediate problem? > > > > > > > > > > > > > It's just that with this approach the driver will have to index the > > > > > > interrupts instead of reading from DT. > > > > > > > > > > > > Marc - is it OK with the above approach? > > > > > > > > > > Anything that uses standard properties in a standard way works for me. > > > > > > > > > I added interrupts property now instead of interrupt-map as below: > > > > > > > > irqc: interrupt-controller@110a0000 { > > > > compatible = "renesas,r9a07g044-irqc", "renesas,rzg2l-irqc"; > > > > #address-cells = <0>; > > > > interrupt-parent = <&gic>; > > > > interrupt-controller; > > > > reg = <0 0x110a0000 0 0x10000>; > > > > interrupts = > > > > , > > > > , > > > > , > > > > , > > > > , > > > > , > > > > , > > > > , > > > > , > > > > , > > > > , > > > > , > > > > , > > > > , > > > > , > > > > , > > > > , > > > > , > > > > , > > > > , > > > > , > > > > , > > > > , > > > > , > > > > , > > > > , > > > > , > > > > , > > > > , > > > > , > > > > , > > > > , > > > > , > > > > , > > > > , > > > > , > > > > , > > > > , > > > > , > > > > , > > > > ; > > > > clocks = <&cpg CPG_MOD R9A07G044_IA55_CLK>, > > > > <&cpg CPG_MOD R9A07G044_IA55_PCLK>; > > > > clock-names = "clk", "pclk"; > > > > power-domains = <&cpg>; > > > > resets = <&cpg R9A07G044_IA55_RESETN>; > > > > }; > > > > > > > > > > > > In the hierarchal interrupt code its parsed as below: > > > > on probe fetch the details: > > > > range = of_get_property(np, "interrupts", &len); > > > > if (!range) > > > > return -EINVAL; > > > > > > > > for (len /= sizeof(*range), j = 0; len >= 3; len -= 3) { > > > > if (j >= IRQC_NUM_IRQ) > > > > return -EINVAL; > > > > > > > > priv->map[j].args[0] = be32_to_cpu(*range++); > > > > priv->map[j].args[1] = be32_to_cpu(*range++); > > > > priv->map[j].args[2] = be32_to_cpu(*range++); > > > > priv->map[j].args_count = 3; > > > > j++; > > > > > > Not sure what's wrong, but you shouldn't be doing your own parsing. > > > The setup shouldn't look much different than a GPIO controller > > > interrupts except you have multiple parent interrupts. > > > > > Sorry does that mean the IRQ domain should be chained handler and not > > hierarchical? Or is it I have miss-understood. I guess the core DT code allocates the interrupts itself, as if the interrupt controller was the interrupt producer itself (which isn't the case here), bypassing the hierarchical setup altogether. We solved it on the MSI side by not using 'interrupts'. Either we adopt a similar solution for wired interrupts, or we fix the core DT code. > > > > If the IRQ domain has to be hierarchical how do we map to the parent? > > (based on the previous reviews Marc had suggested to implement as > > hierarchical [1]) > > > Gentle ping. Please move this discussion to the relevant thread. M. -- Without deviation from the norm, progress is not possible.