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 755B7C433F5 for ; Sun, 5 Dec 2021 22:28:05 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S239783AbhLEWba (ORCPT ); Sun, 5 Dec 2021 17:31:30 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:54932 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233833AbhLEWb3 (ORCPT ); Sun, 5 Dec 2021 17:31:29 -0500 Received: from mail-yb1-xb34.google.com (mail-yb1-xb34.google.com [IPv6:2607:f8b0:4864:20::b34]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 0B49FC061714; Sun, 5 Dec 2021 14:28:02 -0800 (PST) Received: by mail-yb1-xb34.google.com with SMTP id q74so25956833ybq.11; Sun, 05 Dec 2021 14:28:02 -0800 (PST) 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=SERoy8mNp8PYxIRCuBvgvbxWStiuaQfRrnBn5Hx8L44=; b=ZAB2QYa1bE06WOta7EStJ9OiY7PjwDFED+bNlLIZluIwP6gjM6awoHbEahTmMgA5dc HQWx11KjFFSXPPKkK3OxW5jNT6uuiYrHHiqxKSHbT+nvuYFFmOAUlkEucmtjzu/7PBfA WMmpqzcuUQOLo92F+KwsstQYHejFeRXsMPOOsHY0lGl1Qf6uHZnKPqiL+X8Yztd3CzWm xRltYjH23o6NniRHB2ElQSUCXcQg3xsf1dTHNR+1iiBqKmuyWE6HwD2K9KE4J2zjBE6Y uuqSa/pSX22iShV2EWwQLwOFAyoVgolx0Lr/VlIAjGtYeB38iu33X2wiqAtK+BHgBtdn Yo1A== 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=SERoy8mNp8PYxIRCuBvgvbxWStiuaQfRrnBn5Hx8L44=; b=An3TyTVkMCzp1HGwf4dX+998RlFLmwNguBf6KpzJTuzaL6FxDIGza3PySHDflWi+dp bfO8MuBqs4oTSQyMA6Fe32Ce/DVQCaFph2X8EJFFYRu6KuVighOiqWBP5h3pTgCTp/gq 2mB6Z7Ccd8RqmUbZHiJnz7OjTv2juo3m+bROLGAQFDoMGXKpIcptXj0uodrR0vrGdPzH nnaTNz4mL+mxeiUSZcQPWGG45khcsJeVY22RCULdSxw/oUKhVTGmMMQ9v2sO4cqfWAeO FMu2w8mwS1TNUK9Nh6fQ8d2i9zdazueSmngIGj9ggRvZkDVkdCl/EskC8lWdn2w4oLTK ZLSA== X-Gm-Message-State: AOAM532Xl1TksZrJr++AYMdvyhfbEZquxUpof5kjllQEzv5idpiWptvN zNXFyTbGCROeOyOqZW9oqIWNDd7sP+JM5FN8kaQ= X-Google-Smtp-Source: ABdhPJw8wBVGUsiIWvYc9nptkmzmP+1mUFLQzE3TzCw9HJcWQmc68r/GlOuu+n1pj2Y4yS1dU62GpC3GzX8Yue/mO+4= X-Received: by 2002:a25:dc4d:: with SMTP id y74mr36554837ybe.422.1638743281180; Sun, 05 Dec 2021 14:28:01 -0800 (PST) MIME-Version: 1.0 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> In-Reply-To: From: "Lad, Prabhakar" Date: Sun, 5 Dec 2021 22:27:35 +0000 Message-ID: Subject: Re: [PATCH] of/irq: Add a quirk for controllers with their own definition of interrupt-map To: Marc Zyngier , Rob Herring Cc: 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" Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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. > > 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. > [1] https://lore.kernel.org/lkml/20211110225808.16388-1-prabhakar.mahadev-lad.rj@bp.renesas.com/T/ > > Cheers, > Prabhakar