From: Anup Patel <apatel@ventanamicro.com>
To: Conor Dooley <conor@kernel.org>
Cc: Palmer Dabbelt <palmer@dabbelt.com>,
Paul Walmsley <paul.walmsley@sifive.com>,
Thomas Gleixner <tglx@linutronix.de>,
Marc Zyngier <maz@kernel.org>, Rob Herring <robh+dt@kernel.org>,
Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>,
Robin Murphy <robin.murphy@arm.com>,
Joerg Roedel <joro@8bytes.org>, Will Deacon <will@kernel.org>,
Frank Rowand <frowand.list@gmail.com>,
Atish Patra <atishp@atishpatra.org>,
Andrew Jones <ajones@ventanamicro.com>,
Anup Patel <anup@brainfault.org>,
linux-riscv@lists.infradead.org, linux-kernel@vger.kernel.org,
devicetree@vger.kernel.org, iommu@lists.linux.dev
Subject: Re: [PATCH v3 08/11] dt-bindings: interrupt-controller: Add RISC-V advanced PLIC
Date: Tue, 13 Jun 2023 16:07:11 +0530 [thread overview]
Message-ID: <CAK9=C2W1=DAME7uYKu82qcpfn=V5N=4tZ4NTa2EygR+HDQCsmQ@mail.gmail.com> (raw)
In-Reply-To: <20230510-retry-paced-644f5a95ba3f@spud>
On Wed, May 10, 2023 at 9:11 PM Conor Dooley <conor@kernel.org> wrote:
>
> Hey Anup,
>
> On Mon, May 08, 2023 at 07:58:39PM +0530, Anup Patel wrote:
> > + interrupts-extended:
> > + minItems: 1
> > + maxItems: 16384
> > + description:
> > + Given APLIC domain directly injects external interrupts to a set of
> > + RISC-V HARTS (or CPUs). Each node pointed to should be a riscv,cpu-intc
> > + node, which has a riscv node (i.e. RISC-V HART) as parent.
>
> Same nit here, s/riscv node/cpu node/?
Okay, I will update.
>
> > +
> > + msi-parent:
> > + description:
> > + Given APLIC domain forwards wired interrupts as MSIs to a AIA incoming
> > + message signaled interrupt controller (IMSIC). If both "msi-parent" and
> > + "interrupts-extended" properties are present then it means the APLIC
> > + domain supports both MSI mode and Direct mode in HW. In this case, the
> > + APLIC driver has to choose between MSI mode or Direct mode.
> > +
> > + riscv,num-sources:
> > + $ref: /schemas/types.yaml#/definitions/uint32
> > + minimum: 1
> > + maximum: 1023
> > + description:
> > + Specifies the number of wired interrupt sources supported by this
> > + APLIC domain.
>
> Rob asked:
> | We don't normally need to how many interrupts, why here?
>
> But I do not see an answer to that on lore.
The APLIC spec defines maximum interrupt sources to be 1023.
>
> > +
> > + riscv,children:
> > + $ref: /schemas/types.yaml#/definitions/phandle-array
> > + minItems: 1
> > + maxItems: 1024
> > + items:
> > + maxItems: 1
> > + description:
> > + A list of child APLIC domains for the given APLIC domain. Each child
> > + APLIC domain is assigned a child index in increasing order, with the
> > + first child APLIC domain assigned child index 0. The APLIC domain child
> > + index is used by firmware to delegate interrupts from the given APLIC
> > + domain to a particular child APLIC domain.
> > +
> > + riscv,delegate:
> > + $ref: /schemas/types.yaml#/definitions/phandle-array
> > + minItems: 1
> > + maxItems: 1024
> > + items:
> > + items:
> > + - description: child APLIC domain phandle
> > + - description: first interrupt number of this APLIC domain (inclusive)
> > + - description: last interrupt number of this APLIC domain (inclusive)
> > + description:
> > + A interrupt delegation list where each entry is a triple consisting of
> > + child APLIC domain phandle, first interrupt number of this APLIC domain,
> > + and last interrupt number of this APLIC domain. Firmware must configure
> > + interrupt delegation registers based on interrupt delegation list.
>
> I read back Rob's comments on this from last time. He said:
> | The node's domain it delegating its interrupts to the child domain or
> | the other way around? The interrupt numbers here are this domain's or
> | the child's?
The node's domain is delegating its interrupts to the child domain.
>
> IMO it's ambiguous from the binding description whether the numbers
> refer to the "first interrupt in the parent domain that is delegated
> to the child" or to numbering of the interrupts within the child domain.
> "This" can be quite an ambiguous word, and it's not totally obvious
> whether the "this" refers to the "child domain" earlier in the sentence.
>
> I also do not not think you have answered his question about the
> directionality of the delegation either (it should just be a copy-paste
> from riscv,children, no?).
For APLIC, the interrupt delegation is always from parent domain
to the child domain.
I will add a statement about this in the description.
>
> > +
> > +required:
> > + - compatible
> > + - reg
> > + - interrupt-controller
> > + - "#interrupt-cells"
> > + - riscv,num-sources
>
> btw, do we need something like:
>
> anyOf:
> - required:
> - interrupts-extended
> - required:
> - msi-parent
Okay, I will update.
>
> & hopefully I didn't previously ask this one:
> dependencies:
> riscv,delegate: [ riscv,children ]
>
> As an aside, I still think "riscv,delegate" looks strange here alongside
> "riscv,children" since "delegate" is singular and "children" is plural.
> The plural would be "delegates", but "delegation" would also fit better
> than "delegate".
Okay, I will rename it to "riscv,delegation".
>
> Cheers,
> Conor.
Regards,
Anup
next prev parent reply other threads:[~2023-06-13 10:37 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-05-08 14:28 [PATCH v3 00/11] Linux RISC-V AIA Support Anup Patel
2023-05-08 14:28 ` [PATCH v3 01/11] RISC-V: Add riscv_fw_parent_hartid() function Anup Patel
2023-05-10 12:45 ` Conor Dooley
2023-06-13 8:05 ` Anup Patel
2023-05-08 14:28 ` [PATCH v3 02/11] of/irq: Set FWNODE_FLAG_BEST_EFFORT for the interrupt controller DT nodes Anup Patel
2023-06-08 18:28 ` Rob Herring
2023-06-08 20:04 ` Saravana Kannan
2023-06-09 11:40 ` Anup Patel
2023-06-09 21:17 ` Saravana Kannan
2023-06-13 4:42 ` Anup Patel
2023-05-08 14:28 ` [PATCH v3 03/11] irqchip/riscv-intc: Add support for RISC-V AIA Anup Patel
2023-05-08 14:28 ` [PATCH v3 04/11] dt-bindings: interrupt-controller: Add RISC-V incoming MSI controller Anup Patel
2023-05-10 12:16 ` Conor Dooley
2023-06-13 8:18 ` Anup Patel
2023-05-11 9:49 ` Krzysztof Kozlowski
2023-05-08 14:28 ` [PATCH v3 05/11] irqchip: Add RISC-V incoming MSI controller driver Anup Patel
2023-05-08 14:28 ` [PATCH v3 06/11] irqchip/riscv-imsic: Add support for PCI MSI irqdomain Anup Patel
2023-05-08 14:28 ` [PATCH v3 07/11] irqchip/riscv-imsic: Improve IOMMU DMA support Anup Patel
2023-05-10 10:48 ` Robin Murphy
2023-05-10 15:12 ` Anup Patel
2023-05-15 12:53 ` Jason Gunthorpe
2023-06-13 7:55 ` Anup Patel
2023-05-08 14:28 ` [PATCH v3 08/11] dt-bindings: interrupt-controller: Add RISC-V advanced PLIC Anup Patel
2023-05-10 15:41 ` Conor Dooley
2023-06-13 10:37 ` Anup Patel [this message]
2023-05-08 14:28 ` [PATCH v3 09/11] irqchip: Add RISC-V advanced PLIC driver Anup Patel
2023-05-08 14:28 ` [PATCH v3 10/11] RISC-V: Select APLIC and IMSIC drivers Anup Patel
2023-05-10 12:20 ` Conor Dooley
2023-05-08 14:28 ` [PATCH v3 11/11] MAINTAINERS: Add entry for RISC-V AIA drivers Anup Patel
2023-05-10 10:24 ` [PATCH v3 00/11] Linux RISC-V AIA Support Conor Dooley
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='CAK9=C2W1=DAME7uYKu82qcpfn=V5N=4tZ4NTa2EygR+HDQCsmQ@mail.gmail.com' \
--to=apatel@ventanamicro.com \
--cc=ajones@ventanamicro.com \
--cc=anup@brainfault.org \
--cc=atishp@atishpatra.org \
--cc=conor@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=frowand.list@gmail.com \
--cc=iommu@lists.linux.dev \
--cc=joro@8bytes.org \
--cc=krzysztof.kozlowski+dt@linaro.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-riscv@lists.infradead.org \
--cc=maz@kernel.org \
--cc=palmer@dabbelt.com \
--cc=paul.walmsley@sifive.com \
--cc=robh+dt@kernel.org \
--cc=robin.murphy@arm.com \
--cc=tglx@linutronix.de \
--cc=will@kernel.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).