.../interrupt-controller/xlnx,intc.yaml | 95 +++++++++++++++++++ 1 file changed, 95 insertions(+) create mode 100644 Documentation/devicetree/bindings/interrupt-controller/xlnx,intc.yaml
Add description for AMD/Xilinx interrupt controller.
IP acts as primary interrupt controller on Microblaze systems or can be
used as secondary interrupt controller on ARM based systems like Zynq,
ZynqMP, Versal or Versal Gen 2. Also as secondary interrupt controller on
Microblaze-V (Risc-V) systems.
Over the years IP exists in multiple variants based on attached bus as OPB,
PLB or AXI that's why generic filename is used.
Signed-off-by: Michal Simek <michal.simek@amd.com>
---
https://docs.amd.com/v/u/en-US/pg099-axi-intc
---
.../interrupt-controller/xlnx,intc.yaml | 95 +++++++++++++++++++
1 file changed, 95 insertions(+)
create mode 100644 Documentation/devicetree/bindings/interrupt-controller/xlnx,intc.yaml
diff --git a/Documentation/devicetree/bindings/interrupt-controller/xlnx,intc.yaml b/Documentation/devicetree/bindings/interrupt-controller/xlnx,intc.yaml
new file mode 100644
index 000000000000..816f78d4e8c4
--- /dev/null
+++ b/Documentation/devicetree/bindings/interrupt-controller/xlnx,intc.yaml
@@ -0,0 +1,95 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/interrupt-controller/xlnx,intc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Xilinx Interrupt Controller
+
+maintainers:
+ - Michal Simek <michal.simek@amd.com>
+
+description:
+ The controller is a soft IP core that is configured at build time for the
+ number of interrupts and the type of each interrupt. These details cannot
+ be changed at run time.
+
+properties:
+ compatible:
+ const: xlnx,xps-intc-1.00.a
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ maxItems: 1
+
+ power-domains:
+ maxItems: 1
+
+ resets:
+ maxItems: 1
+
+ "#interrupt-cells":
+ const: 2
+ description:
+ Specifies the number of cells needed to encode an interrupt source.
+ The value shall be a minimum of 1. The Xilinx device trees typically
+ use 2 but the 2nd value is not used.
+
+ interrupt-controller: true
+
+ interrupts:
+ maxItems: 1
+ description:
+ Specifies the interrupt of the parent controller from which it is chained.
+
+ xlnx,kind-of-intr:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description:
+ A 32 bit value specifying the interrupt type for each possible interrupt
+ (1 = edge, 0 = level). The interrupt type typically comes in thru
+ the device tree node of the interrupt generating device, but in this case
+ the interrupt type is determined by the interrupt controller based on how
+ it was implemented.
+
+ xlnx,num-intr-inputs:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description:
+ Specifies the number of interrupts supported by the specific
+ implementation of the controller (1-32).
+
+required:
+ - reg
+ - "#interrupt-cells"
+ - interrupt-controller
+ - xlnx,kind-of-intr
+ - xlnx,num-intr-inputs
+
+additionalProperties: false
+
+examples:
+ - |
+ interrupt-controller@41800000 {
+ compatible = "xlnx,xps-intc-1.00.a";
+ reg = <0x41800000 0x10000>;
+ #interrupt-cells = <2>;
+ interrupt-controller;
+ xlnx,kind-of-intr = <0x1>;
+ xlnx,num-intr-inputs = <0x1>;
+ };
+
+ - |
+ /*
+ * Chained Example - The interrupt is chained to hardware
+ * interrupt 61 (29 + 32) of the GIC for Zynq.
+ */
+ interrupt-controller@41800000 {
+ compatible = "xlnx,xps-intc-1.00.a";
+ reg = <0x41800000 0x10000>;
+ #interrupt-cells = <2>;
+ interrupt-controller;
+ interrupts = <0 29 4>;
+ xlnx,kind-of-intr = <0x1>;
+ xlnx,num-intr-inputs = <0x1>;
+ };
--
2.43.0On Tue, Jul 22, 2025 at 08:49:42AM +0200, Michal Simek wrote:
> + "#interrupt-cells":
> + const: 2
> + description:
> + Specifies the number of cells needed to encode an interrupt source.
> + The value shall be a minimum of 1. The Xilinx device trees typically
> + use 2 but the 2nd value is not used.
> +
> + interrupt-controller: true
> +
> + interrupts:
> + maxItems: 1
> + description:
> + Specifies the interrupt of the parent controller from which it is chained.
> +
> + xlnx,kind-of-intr:
> + $ref: /schemas/types.yaml#/definitions/uint32
> + description:
> + A 32 bit value specifying the interrupt type for each possible interrupt
> + (1 = edge, 0 = level). The interrupt type typically comes in thru
> + the device tree node of the interrupt generating device, but in this case
> + the interrupt type is determined by the interrupt controller based on how
> + it was implemented.
enum: [ 0, 1 ]
> +
> + xlnx,num-intr-inputs:
> + $ref: /schemas/types.yaml#/definitions/uint32
> + description:
> + Specifies the number of interrupts supported by the specific
> + implementation of the controller (1-32).
minimum:
maximum:
> +
> +required:
> + - reg
> + - "#interrupt-cells"
> + - interrupt-controller
> + - xlnx,kind-of-intr
> + - xlnx,num-intr-inputs
> +
> +additionalProperties: false
> +
> +examples:
> + - |
> + interrupt-controller@41800000 {
> + compatible = "xlnx,xps-intc-1.00.a";
> + reg = <0x41800000 0x10000>;
> + #interrupt-cells = <2>;
> + interrupt-controller;
> + xlnx,kind-of-intr = <0x1>;
> + xlnx,num-intr-inputs = <0x1>;
This should be decimal, we (humans) count in decimal. xlnx,kind-of-intr
probably as well, for consistency and simplicity.
> + };
> +
> + - |
> + /*
> + * Chained Example - The interrupt is chained to hardware
> + * interrupt 61 (29 + 32) of the GIC for Zynq.
> + */
> + interrupt-controller@41800000 {
> + compatible = "xlnx,xps-intc-1.00.a";
> + reg = <0x41800000 0x10000>;
> + #interrupt-cells = <2>;
> + interrupt-controller;
> + interrupts = <0 29 4>;
Use defines for standard flags. Or drop the example, difference in one
property usually is not worth documenting.
Best regards,
Krzysztof
On 7/22/25 09:40, Krzysztof Kozlowski wrote: > On Tue, Jul 22, 2025 at 08:49:42AM +0200, Michal Simek wrote: >> + "#interrupt-cells": >> + const: 2 >> + description: >> + Specifies the number of cells needed to encode an interrupt source. >> + The value shall be a minimum of 1. The Xilinx device trees typically >> + use 2 but the 2nd value is not used. >> + >> + interrupt-controller: true >> + >> + interrupts: >> + maxItems: 1 >> + description: >> + Specifies the interrupt of the parent controller from which it is chained. >> + >> + xlnx,kind-of-intr: >> + $ref: /schemas/types.yaml#/definitions/uint32 >> + description: >> + A 32 bit value specifying the interrupt type for each possible interrupt >> + (1 = edge, 0 = level). The interrupt type typically comes in thru >> + the device tree node of the interrupt generating device, but in this case >> + the interrupt type is determined by the interrupt controller based on how >> + it was implemented. > > enum: [ 0, 1 ] It is hex value for all interrupts together. And bit position correspond to interrupt line. And you can mix edge or level interrupts together and this is the property which distinguish them. I know that separate cell is normally used but it has never been converted to be like that but interrupt-cells is 2 that binding allows using this description too. Thanks, Michal
On 22/07/2025 08:49, Michal Simek wrote: > Add description for AMD/Xilinx interrupt controller. > IP acts as primary interrupt controller on Microblaze systems or can be > used as secondary interrupt controller on ARM based systems like Zynq, > ZynqMP, Versal or Versal Gen 2. Also as secondary interrupt controller on > Microblaze-V (Risc-V) systems. > > Over the years IP exists in multiple variants based on attached bus as OPB, > PLB or AXI that's why generic filename is used. > > Signed-off-by: Michal Simek <michal.simek@amd.com> > --- > > https://docs.amd.com/v/u/en-US/pg099-axi-intc We usually do not take bindings without users, that's why bindings patch is always part of some other patchset. Commit msg also did not clarify the usecase here (or exception). Best regards, Krzysztof
On 7/22/25 09:17, Krzysztof Kozlowski wrote: > On 22/07/2025 08:49, Michal Simek wrote: >> Add description for AMD/Xilinx interrupt controller. >> IP acts as primary interrupt controller on Microblaze systems or can be >> used as secondary interrupt controller on ARM based systems like Zynq, >> ZynqMP, Versal or Versal Gen 2. Also as secondary interrupt controller on >> Microblaze-V (Risc-V) systems. >> >> Over the years IP exists in multiple variants based on attached bus as OPB, >> PLB or AXI that's why generic filename is used. >> >> Signed-off-by: Michal Simek <michal.simek@amd.com> >> --- >> >> https://docs.amd.com/v/u/en-US/pg099-axi-intc > > > We usually do not take bindings without users, that's why bindings patch > is always part of some other patchset. Commit msg also did not clarify > the usecase here (or exception). Example DT is already the part of arch/microblaze/. https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/microblaze/boot/dts/system.dts?h=v6.16-rc7#n338 DT has been added in 2014 before dt bindings that's why it was never documented. Thanks, Michal
On Tue, Jul 22, 2025 at 09:32:58AM +0200, Michal Simek wrote: > > > On 7/22/25 09:17, Krzysztof Kozlowski wrote: > > On 22/07/2025 08:49, Michal Simek wrote: > > > Add description for AMD/Xilinx interrupt controller. > > > IP acts as primary interrupt controller on Microblaze systems or can be > > > used as secondary interrupt controller on ARM based systems like Zynq, > > > ZynqMP, Versal or Versal Gen 2. Also as secondary interrupt controller on > > > Microblaze-V (Risc-V) systems. > > > > > > Over the years IP exists in multiple variants based on attached bus as OPB, > > > PLB or AXI that's why generic filename is used. > > > > > > Signed-off-by: Michal Simek <michal.simek@amd.com> > > > --- > > > > > > https://docs.amd.com/v/u/en-US/pg099-axi-intc > > > > > > We usually do not take bindings without users, that's why bindings patch > > is always part of some other patchset. Commit msg also did not clarify > > the usecase here (or exception). > > Example DT is already the part of arch/microblaze/. > > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/microblaze/boot/dts/system.dts?h=v6.16-rc7#n338 > > DT has been added in 2014 before dt bindings that's why it was never documented. OK, this must be in commit msg, because that's the reason why you are doing it. You are not adding new device. You are documenting missing binding, already used. Best regards, Krzysztof
© 2016 - 2025 Red Hat, Inc.