All of lore.kernel.org
 help / color / mirror / Atom feed
From: Rob Herring <robh@kernel.org>
To: "Lad, Prabhakar" <prabhakar.csengg@gmail.com>
Cc: Marc Zyngier <maz@kernel.org>,
	Geert Uytterhoeven <geert@linux-m68k.org>,
	Prabhakar Mahadev Lad <prabhakar.mahadev-lad.rj@bp.renesas.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
	"kernel-team@android.com" <kernel-team@android.com>,
	John Crispin <john@phrozen.org>, Biwen Li <biwen.li@nxp.com>,
	Chris Brandt <Chris.Brandt@renesas.com>,
	"linux-renesas-soc@vger.kernel.org" 
	<linux-renesas-soc@vger.kernel.org>
Subject: Re: [PATCH] of/irq: Add a quirk for controllers with their own definition of interrupt-map
Date: Mon, 6 Dec 2021 12:59:48 -0600	[thread overview]
Message-ID: <CAL_JsqJd4tgTGGypA+Zj4VEoXthFksSHhmyc_MSEZzdTvHVT4A@mail.gmail.com> (raw)
In-Reply-To: <CA+V-a8spbEKtcWBgfrj9Lv2Jn+7CQe9Hz_JA9mms7CzyMeFDaA@mail.gmail.com>

On Mon, Dec 6, 2021 at 10:55 AM Lad, Prabhakar
<prabhakar.csengg@gmail.com> wrote:
>
> On Mon, Dec 6, 2021 at 10:26 AM Marc Zyngier <maz@kernel.org> wrote:
> >
> > On Sun, 05 Dec 2021 22:27:35 +0000,
> > "Lad, Prabhakar" <prabhakar.csengg@gmail.com> wrote:
> > >
> > > On Wed, Dec 1, 2021 at 4:16 PM Lad, Prabhakar
> > > <prabhakar.csengg@gmail.com> wrote:
> > > >
> > > > On Wed, Dec 1, 2021 at 2:36 PM Rob Herring <robh@kernel.org> wrote:
> > > > >
> > > > > On Wed, Dec 1, 2021 at 7:37 AM Lad, Prabhakar
> > > > > <prabhakar.csengg@gmail.com> wrote:
> > > > > >
> > > > > > Hi Marc/Rob,
> > > > > >
> > > > > > On Tue, Nov 30, 2021 at 6:37 PM Marc Zyngier <maz@kernel.org> wrote:
> > > > > > >
> > > > > > > On Tue, 30 Nov 2021 12:52:21 +0000,
> > > > > > > "Lad, Prabhakar" <prabhakar.csengg@gmail.com> wrote:
> > > > > > > >
> > > > > > > > On Mon, Nov 29, 2021 at 6:33 PM Rob Herring <robh@kernel.org> wrote:
> > > > > > > > >
> > > > > > > > > interrupts would work just fine here:
> > > > > > > > >
> > > > > > > > > interrupts = <GIC_SPI 4 IRQ_TYPE_LEVEL_HIGH>,
> > > > > > > > >   <GIC_SPI 5 IRQ_TYPE_LEVEL_HIGH>,
> > > > > > > > >   <GIC_SPI 6 IRQ_TYPE_LEVEL_HIGH>,
> > > > > > > > >   <GIC_SPI 7 IRQ_TYPE_LEVEL_HIGH>,
> > > > > > > > >   <GIC_SPI 8 IRQ_TYPE_LEVEL_HIGH>,
> > > > > > > > >   <GIC_SPI 9 IRQ_TYPE_LEVEL_HIGH>,
> > > > > > > > >   <GIC_SPI 10 IRQ_TYPE_LEVEL_HIGH>,
> > > > > > > > >   <GIC_SPI 11 IRQ_TYPE_LEVEL_HIGH>;
> > > > > > > > >
> > > > > > > > > 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 =
> > > > > >                       <GIC_SPI 0 IRQ_TYPE_LEVEL_HIGH>,
> > > > > >                       <GIC_SPI 1 IRQ_TYPE_LEVEL_HIGH>,
> > > > > >                       <GIC_SPI 2 IRQ_TYPE_LEVEL_HIGH>,
> > > > > >                       <GIC_SPI 3 IRQ_TYPE_LEVEL_HIGH>,
> > > > > >                       <GIC_SPI 4 IRQ_TYPE_LEVEL_HIGH>,
> > > > > >                       <GIC_SPI 5 IRQ_TYPE_LEVEL_HIGH>,
> > > > > >                       <GIC_SPI 6 IRQ_TYPE_LEVEL_HIGH>,
> > > > > >                       <GIC_SPI 7 IRQ_TYPE_LEVEL_HIGH>,
> > > > > >                       <GIC_SPI 8 IRQ_TYPE_LEVEL_HIGH>,
> > > > > >                       <GIC_SPI 444 IRQ_TYPE_LEVEL_HIGH>,
> > > > > >                       <GIC_SPI 445 IRQ_TYPE_LEVEL_HIGH>,
> > > > > >                       <GIC_SPI 446 IRQ_TYPE_LEVEL_HIGH>,
> > > > > >                       <GIC_SPI 447 IRQ_TYPE_LEVEL_HIGH>,
> > > > > >                       <GIC_SPI 448 IRQ_TYPE_LEVEL_HIGH>,
> > > > > >                       <GIC_SPI 449 IRQ_TYPE_LEVEL_HIGH>,
> > > > > >                       <GIC_SPI 450 IRQ_TYPE_LEVEL_HIGH>,
> > > > > >                       <GIC_SPI 451 IRQ_TYPE_LEVEL_HIGH>,
> > > > > >                       <GIC_SPI 452 IRQ_TYPE_LEVEL_HIGH>,
> > > > > >                       <GIC_SPI 453 IRQ_TYPE_LEVEL_HIGH>,
> > > > > >                       <GIC_SPI 454 IRQ_TYPE_LEVEL_HIGH>,
> > > > > >                       <GIC_SPI 455 IRQ_TYPE_LEVEL_HIGH>,
> > > > > >                       <GIC_SPI 456 IRQ_TYPE_LEVEL_HIGH>,
> > > > > >                       <GIC_SPI 457 IRQ_TYPE_LEVEL_HIGH>,
> > > > > >                       <GIC_SPI 458 IRQ_TYPE_LEVEL_HIGH>,
> > > > > >                       <GIC_SPI 459 IRQ_TYPE_LEVEL_HIGH>,
> > > > > >                       <GIC_SPI 460 IRQ_TYPE_LEVEL_HIGH>,
> > > > > >                       <GIC_SPI 461 IRQ_TYPE_LEVEL_HIGH>,
> > > > > >                       <GIC_SPI 462 IRQ_TYPE_LEVEL_HIGH>,
> > > > > >                       <GIC_SPI 463 IRQ_TYPE_LEVEL_HIGH>,
> > > > > >                       <GIC_SPI 464 IRQ_TYPE_LEVEL_HIGH>,
> > > > > >                       <GIC_SPI 465 IRQ_TYPE_LEVEL_HIGH>,
> > > > > >                       <GIC_SPI 466 IRQ_TYPE_LEVEL_HIGH>,
> > > > > >                       <GIC_SPI 467 IRQ_TYPE_LEVEL_HIGH>,
> > > > > >                       <GIC_SPI 468 IRQ_TYPE_LEVEL_HIGH>,
> > > > > >                       <GIC_SPI 469 IRQ_TYPE_LEVEL_HIGH>,
> > > > > >                       <GIC_SPI 470 IRQ_TYPE_LEVEL_HIGH>,
> > > > > >                       <GIC_SPI 471 IRQ_TYPE_LEVEL_HIGH>,
> > > > > >                       <GIC_SPI 472 IRQ_TYPE_LEVEL_HIGH>,
> > > > > >                       <GIC_SPI 473 IRQ_TYPE_LEVEL_HIGH>,
> > > > > >                       <GIC_SPI 474 IRQ_TYPE_LEVEL_HIGH>,
> > > > > >                      <GIC_SPI 475 IRQ_TYPE_LEVEL_HIGH>;
> > > > > >          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.
> >
> So maybe for now we go with your earlier suggestion of using
> "interrupt-range"? (And address the core DT in near future)
>
> Rob, is that OK with you?

No. The existing bindings are sufficient for describing what you need
to describe. If the kernel can't handle that, that's no reason for a
new binding.

The core code needs to handle all this whether it's 'interrupts' or
'interrupt-range' you are parsing. Sorry, but I really don't
understand the hierarchical stuff to provide better guidance.

Rob

  reply	other threads:[~2021-12-06 19:00 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-11-22 10:30 [PATCH] of/irq: Add a quirk for controllers with their own definition of interrupt-map Marc Zyngier
2021-11-22 13:10 ` Geert Uytterhoeven
2021-11-22 13:54   ` Marc Zyngier
2021-11-22 16:58     ` Geert Uytterhoeven
2021-11-23  7:57       ` Geert Uytterhoeven
2021-11-23  8:33         ` Marc Zyngier
2021-11-23  8:44           ` Geert Uytterhoeven
2021-11-23  9:11             ` Marc Zyngier
2021-11-24  7:54               ` Geert Uytterhoeven
2021-11-24 11:14                 ` Marc Zyngier
2021-11-27  0:42               ` Prabhakar Mahadev Lad
2021-11-29 10:34                 ` Marc Zyngier
2021-11-29 12:13                   ` Lad, Prabhakar
2021-11-29 18:33                     ` Rob Herring
2021-11-30 12:52                       ` Lad, Prabhakar
2021-11-30 18:36                         ` Marc Zyngier
2021-12-01 13:36                           ` Lad, Prabhakar
2021-12-01 14:35                             ` Rob Herring
2021-12-01 16:16                               ` Lad, Prabhakar
2021-12-05 22:27                                 ` Lad, Prabhakar
2021-12-06 10:26                                   ` Marc Zyngier
2021-12-06 16:55                                     ` Lad, Prabhakar
2021-12-06 18:59                                       ` Rob Herring [this message]
2021-11-23 11:02           ` Geert Uytterhoeven
2021-11-23  8:40 ` Sander Vanheule
2021-11-23  9:12   ` Marc Zyngier
2021-11-29 19:15 ` Rob Herring
2021-11-29 19:31   ` Marc Zyngier
2021-11-29 19:40     ` Rob Herring

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAL_JsqJd4tgTGGypA+Zj4VEoXthFksSHhmyc_MSEZzdTvHVT4A@mail.gmail.com \
    --to=robh@kernel.org \
    --cc=Chris.Brandt@renesas.com \
    --cc=biwen.li@nxp.com \
    --cc=devicetree@vger.kernel.org \
    --cc=geert@linux-m68k.org \
    --cc=john@phrozen.org \
    --cc=kernel-team@android.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-renesas-soc@vger.kernel.org \
    --cc=maz@kernel.org \
    --cc=prabhakar.csengg@gmail.com \
    --cc=prabhakar.mahadev-lad.rj@bp.renesas.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.