From: Rob Herring <robh@kernel.org>
To: Ryan Chen <ryan_chen@aspeedtech.com>
Cc: Thomas Gleixner <tglx@linutronix.de>,
Krzysztof Kozlowski <krzk+dt@kernel.org>,
Conor Dooley <conor+dt@kernel.org>, Joel Stanley <joel@jms.id.au>,
Andrew Jeffery <andrew@codeconstruct.com.au>,
"jk@codeconstruct.com.au" <jk@codeconstruct.com.au>,
Kevin Chen <kevin_chen@aspeedtech.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>,
"linux-aspeed@lists.ozlabs.org" <linux-aspeed@lists.ozlabs.org>
Subject: Re: [PATCH v5 1/3] dt-bindings: interrupt-controller: aspeed,ast2700: Add support for INTC hierarchy
Date: Fri, 24 Oct 2025 18:11:54 -0500 [thread overview]
Message-ID: <20251024231154.GA2962687-robh@kernel.org> (raw)
In-Reply-To: <TY2PPF5CB9A1BE674594566C13B8D8B2984F2F0A@TY2PPF5CB9A1BE6.apcprd06.prod.outlook.com>
On Thu, Oct 23, 2025 at 06:57:01AM +0000, Ryan Chen wrote:
> Hello Rob.
> Thank you for your detailed review and comments.
>
> > Subject: Re: [PATCH v5 1/3] dt-bindings: interrupt-controller: aspeed,ast2700:
> > Add support for INTC hierarchy
> >
> > On Wed, Oct 22, 2025 at 02:55:05PM +0800, Ryan Chen wrote:
> > > AST2700 contains two-level interrupt controllers (INTC0 and INTC1),
> > > each with its own register space and handling different sets of
> > > peripherals.
> >
> > This is a mess!
> >
> > How does this relate to the existing "aspeed,ast2700-intc-ic"? Its schema has a
> > block diagram of connections which I can understand. This does not.
> >
> > The use of child nodes here is questionable. A variable number of interrupt
> > banks is not a reason to have child nodes. I'm only guessing that's what's
> > happening here because you haven't explained it.
>
> Let me clarify the hardware structure and the purpose of these bindings.
>
> The AST2700 SoC includes two top-level interrupt controller modules,
> INTC0 and INTC1. (aspeed,ast2700-intc0, aspeed,ast2700-intc1)
> Each of them provides routing selection and register protection
> features.
> Within each INTCx block, there are multiple sub-blocks called
> intc-ic, each handling multi-interrupt sources.
> ("aspeed,ast2700-intc0-ic", "aspeed,ast2700-intc1-ic")
>
> Cascading occurs between the child banks:
> Level 1 : intc0-ic have multi-interrupts connect to GIC (root)
> Level 2 : multi Intc1-ic# connect to intc0-ic
> The parent intc0/1 nodes expose register regions for routing and
> protection control, serving as containers for their intc-ic children.
Being a 2nd vs. 3rd level interrupt controller is not a reason for
different compatibles. The programming model is obviously the same for
both as you essentially have 0 driver changes. Having N banks of 32
interrupts vs. 1 bank of 32 interrupts is not a reason to have multiple
intcN-ic nodes. That is a very common difference between instances of
the same interrupt controller such as the GIC.
What you need to do is simply extend your driver to support N banks of
32 interrupts. That's what almost every other irqchip driver with more
than 32 interrupts does. If you are lucky, then the offset to each
bank's registers is just hwirq/32 * <bank stride> and the number of
banks can be calculated from the length of 'reg'. If you are not
lucky, then you could put 1 'reg' entry for each bank.
AFAICT, the existing binding in aspeed,ast2700-intc.yaml should work for
you.
>
> The following simplified diagram shows the hierarchy:
>
>
> +----------+ +----------+
> | intc0 | | intc1 |
> - - - - - - - - - - - - - - - - -+---- -----+- - - +------ - -+
> +-----------------------+ | | | |
> | +-------+ +---------+ | | | | |
> | | | | | | | | | |
> | | PSP +-+ GIC | | | | | |
> | | | | | | | | | |
> | +-------+ | | | | | | |
> | | | | +----------+ | |
> | | 192~201 <-|------+ <-------+ intc1-ic |
> | +---------+ | | | | |
> +-----------------------+ | intc0-ic <-------+ intc1-ic |
> | | | |
> | <-------+ intc1-ic |
> +----------+ .....
You already match on intc0 and handle 32 interrupts. Now you are adding
intc0-ic to match on and handling the same 32 interrupts?
Rob
next prev parent reply other threads:[~2025-10-24 23:12 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-10-22 6:55 [PATCH v5 0/3] AST2700 interrupt controller hierarchy support Ryan Chen
2025-10-22 6:55 ` [PATCH v5 1/3] dt-bindings: interrupt-controller: aspeed,ast2700: Add support for INTC hierarchy Ryan Chen
2025-10-22 8:29 ` Rob Herring (Arm)
2025-10-22 13:51 ` Rob Herring
2025-10-23 6:57 ` Ryan Chen
2025-10-24 23:11 ` Rob Herring [this message]
2025-10-26 3:57 ` Ryan Chen
2025-10-22 6:55 ` [PATCH v5 2/3] Irqchip/ast2700-intc: add debugfs support for routing/protection display Ryan Chen
2025-10-22 16:37 ` Thomas Gleixner
2025-10-23 8:20 ` Ryan Chen
2025-10-22 6:55 ` [PATCH v5 3/3] irqchip: aspeed: add compatible strings for ast2700-intc0-ic and ast2700-intc1-ic Ryan Chen
2025-10-22 16:51 ` Thomas Gleixner
2025-10-23 8:29 ` Ryan Chen
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=20251024231154.GA2962687-robh@kernel.org \
--to=robh@kernel.org \
--cc=andrew@codeconstruct.com.au \
--cc=conor+dt@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=jk@codeconstruct.com.au \
--cc=joel@jms.id.au \
--cc=kevin_chen@aspeedtech.com \
--cc=krzk+dt@kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-aspeed@lists.ozlabs.org \
--cc=linux-kernel@vger.kernel.org \
--cc=ryan_chen@aspeedtech.com \
--cc=tglx@linutronix.de \
/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 NNTP newsgroup(s).