From: Rob Herring <robh@kernel.org>
To: Sander Vanheule <sander@svanheule.net>
Cc: linux-kernel@vger.kernel.org, devicetree@vger.kernel.org,
Thomas Gleixner <tglx@linutronix.de>,
Marc Zyngier <maz@kernel.org>,
Birger Koblitz <mail@birger-koblitz.de>,
Bert Vermeulen <bert@biot.com>, John Crispin <john@phrozen.org>
Subject: Re: [PATCH v3 4/6] dt-bindings: interrupt-controller: realtek,rtl-intc: require parents
Date: Fri, 21 Jan 2022 16:56:52 -0600 [thread overview]
Message-ID: <Yes6NFgUmcIcc5mm@robh.at.kernel.org> (raw)
In-Reply-To: <e043a9faa4a8f71efdf8b7849ec7911f16207fb0.1641739718.git.sander@svanheule.net>
On Sun, Jan 09, 2022 at 03:54:35PM +0100, Sander Vanheule wrote:
> The interrupt router has 32 inputs and up to 15 outputs, and the way
> these are mapped to each other is runtime configurable. The outputs of
> this interrupt router on the other hand, are connected to a fixed set of
> parent interrupts. This means that "interrupt-map" is inappropriate, and
> rather a list of parent interrupts should be specified.
I'm not sure why interrupt-map is not appropriate. It is not appropriate
if you have to touch the interrupt router h/w in servicing the
interrupts. If you just need one time configuration of the mapping, then
it should be fine to use I think.
> Two-part compatibles are introduced to be able to require "interrupts"
> for new devicetrees. The relevant descriptions are extended or added to
> more clearly describe the inputs and outputs of this router. The old
> compatible, "interrupt-map" and "#address-cells", is deprecated.
> Interrupt specifiers for new compatibles will require two cells, to
> indicate the output selection.
>
> To prevent spurious changes when more SoCs are added, "allOf" is used
> with one "if", and the compatible enum only has one item.
>
> The example is updated to provide a correct example for RTL8380 SoCs.
>
> Signed-off-by: Sander Vanheule <sander@svanheule.net>
> ---
> .../realtek,rtl-intc.yaml | 78 ++++++++++++++-----
> 1 file changed, 58 insertions(+), 20 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/interrupt-controller/realtek,rtl-intc.yaml b/Documentation/devicetree/bindings/interrupt-controller/realtek,rtl-intc.yaml
> index 9e76fff20323..aab8d44010af 100644
> --- a/Documentation/devicetree/bindings/interrupt-controller/realtek,rtl-intc.yaml
> +++ b/Documentation/devicetree/bindings/interrupt-controller/realtek,rtl-intc.yaml
> @@ -6,6 +6,10 @@ $schema: http://devicetree.org/meta-schemas/core.yaml#
>
> title: Realtek RTL SoC interrupt controller devicetree bindings
>
> +description:
> + Interrupt router for Realtek MIPS SoCs, allowing each SoC interrupt to be
> + routed to one parent interrupt, or left disconnected.
> +
> maintainers:
> - Birger Koblitz <mail@birger-koblitz.de>
> - Bert Vermeulen <bert@biot.com>
> @@ -13,45 +17,79 @@ maintainers:
>
> properties:
> compatible:
> - const: realtek,rtl-intc
> + oneOf:
> + - items:
> + - enum:
> + - realtek,rtl8380-intc
> + - const: realtek,rtl-intc
> + - const: realtek,rtl-intc
> + deprecated: true
>
> - "#interrupt-cells":
> - const: 1
> + "#interrupt-cells": true
>
> reg:
> maxItems: 1
>
> interrupts:
> - maxItems: 1
> + minItems: 1
> + maxItems: 15
> + description:
> + List of parent interrupts, in the order that they are connected to this
> + interrupt router's outputs.
>
> interrupt-controller: true
>
> - "#address-cells":
> - const: 0
> -
> - interrupt-map:
> - description: Describes mapping from SoC interrupts to CPU interrupts
> -
> required:
> - compatible
> - reg
> - "#interrupt-cells"
> - interrupt-controller
> - - "#address-cells"
> - - interrupt-map
> +
> +allOf:
> + - if:
> + properties:
> + compatible:
> + const: realtek,rtl-intc
> + then:
> + properties:
> + "#interrupt-cells":
> + const: 1
> +
> + "#address-cells":
> + const: 0
> +
> + interrupt-map: true
> + required:
> + - "#address-cells"
> + - interrupt-map
> + else:
> + properties:
> + "#interrupt-cells":
> + description:
> + Two cells to specify which line to connect to, and which output it should
> + be routed to. Both cells use a zero-based index.
Picking the index picks the priority? Which is higher priority?
> + const: 2
> + required:
> + - interrupts
>
> additionalProperties: false
>
> examples:
> - |
> intc: interrupt-controller@3000 {
> - compatible = "realtek,rtl-intc";
> - #interrupt-cells = <1>;
> + compatible = "realtek,rtl8380-intc", "realtek,rtl-intc";
> + #interrupt-cells = <2>;
> interrupt-controller;
> - reg = <0x3000 0x20>;
> - #address-cells = <0>;
> - interrupt-map =
> - <31 &cpuintc 2>,
> - <30 &cpuintc 1>,
> - <29 &cpuintc 5>;
> + reg = <0x3000 0x18>;
> +
> + interrupt-parent = <&cpuintc>;
> + interrupts = <2>, <3>, <4>, <5>, <6>;
> + };
> +
> + irq-consumer@0 {
> + reg = <0 4>;
> + interrupt-parent = <&intc>;
> + interrupts =
> + <19 3>, /* IRQ 19, routed to output 3 (cpuintc 5) */
> + <18 4>; /* IRQ 18, routed to output 4 (cpuintc 6) */
> };
> --
> 2.33.1
>
>
next prev parent reply other threads:[~2022-01-21 22:56 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-01-09 14:54 [PATCH v3 0/6] Rework realtek-rtl IRQ driver Sander Vanheule
2022-01-09 14:54 ` [PATCH v3 1/6] irqchip/realtek-rtl: map control data to virq Sander Vanheule
2022-01-09 14:54 ` [PATCH v3 2/6] irqchip/realtek-rtl: fix off-by-one in routing Sander Vanheule
2022-01-09 14:54 ` [PATCH v3 3/6] irqchip/realtek-rtl: clear all pending interrupts Sander Vanheule
2022-01-09 14:54 ` [PATCH v3 4/6] dt-bindings: interrupt-controller: realtek,rtl-intc: require parents Sander Vanheule
2022-01-21 22:56 ` Rob Herring [this message]
2022-01-22 12:49 ` Sander Vanheule
2022-02-05 2:08 ` Rob Herring
2022-01-09 14:54 ` [PATCH v3 5/6] irqchip/realtek-rtl: use parent interrupts Sander Vanheule
2022-01-09 14:54 ` [PATCH v3 6/6] irqchip/realtek-rtl: use per-parent domains Sander Vanheule
2022-01-17 12:21 ` [PATCH v3 0/6] Rework realtek-rtl IRQ driver Marc Zyngier
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=Yes6NFgUmcIcc5mm@robh.at.kernel.org \
--to=robh@kernel.org \
--cc=bert@biot.com \
--cc=devicetree@vger.kernel.org \
--cc=john@phrozen.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mail@birger-koblitz.de \
--cc=maz@kernel.org \
--cc=sander@svanheule.net \
--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 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.