| Message ID | 20231117162709.1096585-2-james.tai@realtek.com |
|---|---|
| State | Changes Requested |
| Headers | show |
| Series | Initial support for the Realtek interrupt controller | expand |
| Context | Check | Description |
|---|---|---|
| robh/checkpatch | success | |
| robh/patch-applied | success | |
| robh/dt-meta-schema | fail | build log |
On Sat, 18 Nov 2023 00:27:04 +0800, James Tai wrote: > Add the YAML documentation for Realtek DHC SoCs. > > CC: Thomas Gleixner <tglx@linutronix.de> > CC: Marc Zyngier <maz@kernel.org> > CC: Rob Herring <robh+dt@kernel.org> > CC: Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org> > CC: Conor Dooley <conor+dt@kernel.org> > CC: linux-kernel@vger.kernel.org > CC: devicetree@vger.kernel.org > Signed-off-by: James Tai <james.tai@realtek.com> > --- > v1 to v2 change: > - Tested the bindings using 'make dt_binding_check' > - Fixed code style issues > > .../realtek,rtd1319-intc.yaml | 79 +++++++++++++++++++ > .../realtek,rtd1319d-intc.yaml | 79 +++++++++++++++++++ > .../realtek,rtd1325-intc.yaml | 79 +++++++++++++++++++ > .../realtek,rtd1619b-intc.yaml | 78 ++++++++++++++++++ > 4 files changed, 315 insertions(+) > create mode 100644 Documentation/devicetree/bindings/interrupt-controller/realtek,rtd1319-intc.yaml > create mode 100644 Documentation/devicetree/bindings/interrupt-controller/realtek,rtd1319d-intc.yaml > create mode 100644 Documentation/devicetree/bindings/interrupt-controller/realtek,rtd1325-intc.yaml > create mode 100644 Documentation/devicetree/bindings/interrupt-controller/realtek,rtd1619b-intc.yaml > My bot found errors running 'make DT_CHECKER_FLAGS=-m dt_binding_check' on your patch (DT_CHECKER_FLAGS is new in v5.13): yamllint warnings/errors: dtschema/dtc warnings/errors: /builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/interrupt-controller/realtek,rtd1319d-intc.yaml: title: 'Realtek DHC RTD1319D Interrupt Controller Device Tree Bindings' should not be valid under {'pattern': '([Bb]inding| [Ss]chema)'} hint: Everything is a binding/schema, no need to say it. Describe what hardware the binding is for. from schema $id: http://devicetree.org/meta-schemas/base.yaml# /builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/interrupt-controller/realtek,rtd1325-intc.yaml: title: 'Realtek DHC RTD1325 Interrupt Controller Device Tree Bindings' should not be valid under {'pattern': '([Bb]inding| [Ss]chema)'} hint: Everything is a binding/schema, no need to say it. Describe what hardware the binding is for. from schema $id: http://devicetree.org/meta-schemas/base.yaml# /builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/interrupt-controller/realtek,rtd1619b-intc.yaml: title: 'Realtek DHC RTD1619B Interrupt Controller Device Tree Bindings' should not be valid under {'pattern': '([Bb]inding| [Ss]chema)'} hint: Everything is a binding/schema, no need to say it. Describe what hardware the binding is for. from schema $id: http://devicetree.org/meta-schemas/base.yaml# /builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/interrupt-controller/realtek,rtd1319-intc.yaml: title: 'Realtek DHC RTD1319 Interrupt Controller Device Tree Bindings' should not be valid under {'pattern': '([Bb]inding| [Ss]chema)'} hint: Everything is a binding/schema, no need to say it. Describe what hardware the binding is for. from schema $id: http://devicetree.org/meta-schemas/base.yaml# doc reference errors (make refcheckdocs): See https://patchwork.ozlabs.org/project/devicetree-bindings/patch/20231117162709.1096585-2-james.tai@realtek.com The base for the series is generally the latest rc1. A different dependency should be noted in *this* patch. If you already ran 'make dt_binding_check' and didn't see the above error(s), then make sure 'yamllint' is installed and dt-schema is up to date: pip3 install dtschema --upgrade Please check and re-submit after running the above command yourself. Note that DT_SCHEMA_FILES can be set to your schema file to speed up checking your schema. However, it must be unset to test all examples with your schema.
Hi James, kernel test robot noticed the following build warnings: [auto build test WARNING on tip/irq/core] [also build test WARNING on robh/for-next linus/master v6.7-rc1 next-20231117] [If your patch is applied to the wrong git tree, kindly drop us a note. And when submitting patch, we suggest to use '--base' as documented in https://git-scm.com/docs/git-format-patch#_base_tree_information] url: https://github.com/intel-lab-lkp/linux/commits/James-Tai/dt-bindings-interrupt-controller-Add-support-for-Realtek-DHC-SoCs/20231118-003036 base: tip/irq/core patch link: https://lore.kernel.org/r/20231117162709.1096585-2-james.tai%40realtek.com patch subject: [PATCH v2 1/6] dt-bindings: interrupt-controller: Add support for Realtek DHC SoCs compiler: loongarch64-linux-gcc (GCC) 13.2.0 reproduce: (https://download.01.org/0day-ci/archive/20231118/202311180921.ayKhiFHL-lkp@intel.com/reproduce) If you fix the issue in a separate patch/commit (i.e. not just a new version of the same patch/commit), kindly add following tags | Reported-by: kernel test robot <lkp@intel.com> | Closes: https://lore.kernel.org/oe-kbuild-all/202311180921.ayKhiFHL-lkp@intel.com/ dtcheck warnings: (new ones prefixed by >>) >> Documentation/devicetree/bindings/interrupt-controller/realtek,rtd1619b-intc.yaml: title: 'Realtek DHC RTD1619B Interrupt Controller Device Tree Bindings' should not be valid under {'pattern': '([Bb]inding| [Ss]chema)'} hint: Everything is a binding/schema, no need to say it. Describe what hardware the binding is for. from schema $id: http://devicetree.org/meta-schemas/base.yaml# >> Documentation/devicetree/bindings/interrupt-controller/realtek,rtd1319-intc.yaml: title: 'Realtek DHC RTD1319 Interrupt Controller Device Tree Bindings' should not be valid under {'pattern': '([Bb]inding| [Ss]chema)'} hint: Everything is a binding/schema, no need to say it. Describe what hardware the binding is for. from schema $id: http://devicetree.org/meta-schemas/base.yaml# >> Documentation/devicetree/bindings/interrupt-controller/realtek,rtd1319d-intc.yaml: title: 'Realtek DHC RTD1319D Interrupt Controller Device Tree Bindings' should not be valid under {'pattern': '([Bb]inding| [Ss]chema)'} hint: Everything is a binding/schema, no need to say it. Describe what hardware the binding is for. from schema $id: http://devicetree.org/meta-schemas/base.yaml# >> Documentation/devicetree/bindings/interrupt-controller/realtek,rtd1325-intc.yaml: title: 'Realtek DHC RTD1325 Interrupt Controller Device Tree Bindings' should not be valid under {'pattern': '([Bb]inding| [Ss]chema)'} hint: Everything is a binding/schema, no need to say it. Describe what hardware the binding is for. from schema $id: http://devicetree.org/meta-schemas/base.yaml#
Hi Rob, >yamllint warnings/errors: > >dtschema/dtc warnings/errors: >/builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/inter >rupt-controller/realtek,rtd1319d-intc.yaml: title: 'Realtek DHC RTD1319D >Interrupt Controller Device Tree Bindings' should not be valid under {'pattern': >'([Bb]inding| [Ss]chema)'} > hint: Everything is a binding/schema, no need to say it. Describe what >hardware the binding is for. > from schema $id: http://devicetree.org/meta-schemas/base.yaml# >/builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/inter >rupt-controller/realtek,rtd1325-intc.yaml: title: 'Realtek DHC RTD1325 Interrupt >Controller Device Tree Bindings' should not be valid under {'pattern': >'([Bb]inding| [Ss]chema)'} > hint: Everything is a binding/schema, no need to say it. Describe what >hardware the binding is for. > from schema $id: http://devicetree.org/meta-schemas/base.yaml# >/builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/inter >rupt-controller/realtek,rtd1619b-intc.yaml: title: 'Realtek DHC RTD1619B >Interrupt Controller Device Tree Bindings' should not be valid under {'pattern': >'([Bb]inding| [Ss]chema)'} > hint: Everything is a binding/schema, no need to say it. Describe what >hardware the binding is for. > from schema $id: http://devicetree.org/meta-schemas/base.yaml# >/builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/inter >rupt-controller/realtek,rtd1319-intc.yaml: title: 'Realtek DHC RTD1319 Interrupt >Controller Device Tree Bindings' should not be valid under {'pattern': >'([Bb]inding| [Ss]chema)'} > hint: Everything is a binding/schema, no need to say it. Describe what >hardware the binding is for. > from schema $id: http://devicetree.org/meta-schemas/base.yaml# > >doc reference errors (make refcheckdocs): > >See >https://patchwork.ozlabs.org/project/devicetree-bindings/patch/202311171627 >09.1096585-2-james.tai@realtek.com > >The base for the series is generally the latest rc1. A different dependency should >be noted in *this* patch. > >If you already ran 'make dt_binding_check' and didn't see the above error(s), >then make sure 'yamllint' is installed and dt-schema is up to >date: > >pip3 install dtschema --upgrade > >Please check and re-submit after running the above command yourself. Note >that DT_SCHEMA_FILES can be set to your schema file to speed up checking >your schema. However, it must be unset to test all examples with your schema. OK. I will update the dtschema and rerun 'make dt_binding_check'. Thank you for your feedback. Regards, James
On 17/11/2023 17:27, James Tai wrote: > Add the YAML documentation for Realtek DHC SoCs. > > CC: Thomas Gleixner <tglx@linutronix.de> > CC: Marc Zyngier <maz@kernel.org> > CC: Rob Herring <robh+dt@kernel.org> > CC: Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org> > CC: Conor Dooley <conor+dt@kernel.org> > CC: linux-kernel@vger.kernel.org > CC: devicetree@vger.kernel.org > Signed-off-by: James Tai <james.tai@realtek.com> > --- > v1 to v2 change: > - Tested the bindings using 'make dt_binding_check' I doubt it. And bot prooves it. > - Fixed code style issues Be specific - what code style issues did you fix? > > .../realtek,rtd1319-intc.yaml | 79 +++++++++++++++++++ > .../realtek,rtd1319d-intc.yaml | 79 +++++++++++++++++++ > .../realtek,rtd1325-intc.yaml | 79 +++++++++++++++++++ > .../realtek,rtd1619b-intc.yaml | 78 ++++++++++++++++++ > 4 files changed, 315 insertions(+) > create mode 100644 Documentation/devicetree/bindings/interrupt-controller/realtek,rtd1319-intc.yaml > create mode 100644 Documentation/devicetree/bindings/interrupt-controller/realtek,rtd1319d-intc.yaml > create mode 100644 Documentation/devicetree/bindings/interrupt-controller/realtek,rtd1325-intc.yaml > create mode 100644 Documentation/devicetree/bindings/interrupt-controller/realtek,rtd1619b-intc.yaml Why do you have four bindings for the same? Please explain me the differences. > > diff --git a/Documentation/devicetree/bindings/interrupt-controller/realtek,rtd1319-intc.yaml b/Documentation/devicetree/bindings/interrupt-controller/realtek,rtd1319-intc.yaml > new file mode 100644 > index 000000000000..b88f3ac07cd9 > --- /dev/null > +++ b/Documentation/devicetree/bindings/interrupt-controller/realtek,rtd1319-intc.yaml > @@ -0,0 +1,79 @@ > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) > +%YAML 1.2 > +--- > +$id: http://devicetree.org/schemas/interrupt-controller/realtek,rtd1319-intc.yaml# > +$schema: http://devicetree.org/meta-schemas/core.yaml# > + > +title: Realtek DHC RTD1319 Interrupt Controller Device Tree Bindings > + > +description: > + This interrupt controller is a component of Realtek DHC RTD1319 and > + is designed to receive interrupts from peripheral devices. > + > + Each DHC SoC has two sets of interrupt controllers, each capable of > + handling up to 32 interrupts. > + > +maintainers: > + - James Tai <james.tai@realtek.com> > + > +allOf: > + - $ref: /schemas/interrupt-controller.yaml# > + > +properties: > + "#interrupt-cells": > + const: 1 compatible is first, put the cells next to other interrupt controller properties. > + > + compatible: > + enum: > + - realtek,rtd1319-intc-iso > + - realtek,rtd1319-intc-misc > + > + "#address-cells": > + const: 0 > + > + interrupt-controller: true > + > + interrupts-extended: interrupts instead. Anyway, you must describe the items. Why this is not fixed but flexible? Hardware has different number of pins? That's unlikely. > + minItems: 1 > + maxItems: 4 > + > + reg: > + maxItems: 1 > + > +required: > + - "#interrupt-cells" > + - "#address-cells" > + - compatible > + - interrupt-controller > + - interrupts-extended > + - reg > + > +additionalProperties: false > + > +examples: > + - | > + #include <dt-bindings/interrupt-controller/irq.h> > + #include <dt-bindings/interrupt-controller/arm-gic.h> > + > + rtd1319_iso_irq: interrupt-controller@40 { > + compatible = "realtek,rtd1319-intc-iso"; > + reg = <0x00 0x40>; > + interrupts-extended = <&gic GIC_SPI 41 IRQ_TYPE_LEVEL_HIGH>, > + <&gic GIC_SPI 0 IRQ_TYPE_LEVEL_HIGH>; > + interrupt-controller; > + #address-cells = <0>; > + #interrupt-cells = <1>; > + }; > + > + rtd1319_misc_irq: interrupt-controller@80 { > + compatible = "realtek,rtd1319-intc-misc"; Drop, one example is enough. This is the same as previous. > + reg = <0x00 0x80>; > + interrupts-extended = <&gic GIC_SPI 40 IRQ_TYPE_LEVEL_HIGH>, > + <&gic GIC_SPI 89 IRQ_TYPE_LEVEL_HIGH>, > + <&gic GIC_SPI 90 IRQ_TYPE_LEVEL_HIGH>, > + <&gic GIC_SPI 39 IRQ_TYPE_LEVEL_HIGH>; > + interrupt-controller; > + #address-cells = <0>; > + #interrupt-cells = <1>; > + }; > +... > diff --git a/Documentation/devicetree/bindings/interrupt-controller/realtek,rtd1319d-intc.yaml b/Documentation/devicetree/bindings/interrupt-controller/realtek,rtd1319d-intc.yaml > new file mode 100644 > index 000000000000..75aba448baf7 > --- /dev/null > +++ b/Documentation/devicetree/bindings/interrupt-controller/realtek,rtd1319d-intc.yaml > @@ -0,0 +1,79 @@ > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) > +%YAML 1.2 > +--- > +$id: http://devicetree.org/schemas/interrupt-controller/realtek,rtd1319d-intc.yaml# > +$schema: http://devicetree.org/meta-schemas/core.yaml# > + > +title: Realtek DHC RTD1319D Interrupt Controller Device Tree Bindings > + > +description: > + This interrupt controller is a component of Realtek DHC RTD1319D and > + is designed to receive interrupts from peripheral devices. > + > + Each DHC SoC has two sets of interrupt controllers, each capable of > + handling up to 32 interrupts. > + > +maintainers: > + - James Tai <james.tai@realtek.com> > + > +allOf: > + - $ref: /schemas/interrupt-controller.yaml# > + > +properties: > + "#interrupt-cells": > + const: 1 > + > + compatible: > + enum: > + - realtek,rtd1319d-intc-iso > + - realtek,rtd1319d-intc-misc So this is the same as the other one? Why it cannot be part of that one? ... > + > +maintainers: > + - James Tai <james.tai@realtek.com> > + > +allOf: > + - $ref: /schemas/interrupt-controller.yaml# > + > +properties: > + "#interrupt-cells": > + const: 1 > + > + compatible: > + enum: > + - realtek,rtd1325-intc-iso > + - realtek,rtd1325-intc-misc All my comments apply to all your bindings... Best regards, Krzysztof
Hi Krzysztof, >I doubt it. > >And bot prooves it. My 'dtschema' is outdated, and I encountered errors after updating it. I will fix it in next patches. >> - Fixed code style issues > >Be specific - what code style issues did you fix? > I fixed the code style issue related to the license declaration. >> >> .../realtek,rtd1319-intc.yaml | 79 >+++++++++++++++++++ >> .../realtek,rtd1319d-intc.yaml | 79 >+++++++++++++++++++ >> .../realtek,rtd1325-intc.yaml | 79 >+++++++++++++++++++ >> .../realtek,rtd1619b-intc.yaml | 78 ++++++++++++++++++ >> 4 files changed, 315 insertions(+) >> create mode 100644 >> Documentation/devicetree/bindings/interrupt-controller/realtek,rtd1319 >> -intc.yaml create mode 100644 >> Documentation/devicetree/bindings/interrupt-controller/realtek,rtd1319 >> d-intc.yaml create mode 100644 >> Documentation/devicetree/bindings/interrupt-controller/realtek,rtd1325 >> -intc.yaml create mode 100644 >> Documentation/devicetree/bindings/interrupt-controller/realtek,rtd1619 >> b-intc.yaml > >Why do you have four bindings for the same? Please explain me the differences. > If the bindings can be shared, I will consolidate it into one. >> >> diff --git >> a/Documentation/devicetree/bindings/interrupt-controller/realtek,rtd13 >> 19-intc.yaml >> b/Documentation/devicetree/bindings/interrupt-controller/realtek,rtd13 >> 19-intc.yaml >> new file mode 100644 >> index 000000000000..b88f3ac07cd9 >> --- /dev/null >> +++ b/Documentation/devicetree/bindings/interrupt-controller/realtek,r >> +++ td1319-intc.yaml >> @@ -0,0 +1,79 @@ >> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) %YAML 1.2 >> +--- >> +$id: >> +http://devicetree.org/schemas/interrupt-controller/realtek,rtd1319-in >> +tc.yaml# >> +$schema: http://devicetree.org/meta-schemas/core.yaml# >> + >> +title: Realtek DHC RTD1319 Interrupt Controller Device Tree Bindings >> + >> +description: >> + This interrupt controller is a component of Realtek DHC RTD1319 and >> + is designed to receive interrupts from peripheral devices. >> + >> + Each DHC SoC has two sets of interrupt controllers, each capable of >> + handling up to 32 interrupts. >> + >> +maintainers: >> + - James Tai <james.tai@realtek.com> >> + >> +allOf: >> + - $ref: /schemas/interrupt-controller.yaml# >> + >> +properties: >> + "#interrupt-cells": >> + const: 1 > > >compatible is first, put the cells next to other interrupt controller properties. > I will fix it in next patches. >> + >> + compatible: >> + enum: >> + - realtek,rtd1319-intc-iso >> + - realtek,rtd1319-intc-misc >> + >> + "#address-cells": >> + const: 0 >> + >> + interrupt-controller: true >> + >> + interrupts-extended: > >interrupts instead. > >Anyway, you must describe the items. Why this is not fixed but flexible? >Hardware has different number of pins? That's unlikely. > I will replace it with 'interrupts'. Since our Interrupt controller architecture doesn't involve multiple interrupt sources, using 'interrupts' should suffice. >> + minItems: 1 >> + maxItems: 4 >> + >> + reg: >> + maxItems: 1 >> + >> +required: >> + - "#interrupt-cells" >> + - "#address-cells" >> + - compatible >> + - interrupt-controller >> + - interrupts-extended >> + - reg >> + >> +additionalProperties: false >> + >> +examples: >> + - | >> + #include <dt-bindings/interrupt-controller/irq.h> >> + #include <dt-bindings/interrupt-controller/arm-gic.h> >> + >> + rtd1319_iso_irq: interrupt-controller@40 { >> + compatible = "realtek,rtd1319-intc-iso"; >> + reg = <0x00 0x40>; >> + interrupts-extended = <&gic GIC_SPI 41 IRQ_TYPE_LEVEL_HIGH>, >> + <&gic GIC_SPI 0 IRQ_TYPE_LEVEL_HIGH>; >> + interrupt-controller; >> + #address-cells = <0>; >> + #interrupt-cells = <1>; >> + }; >> + >> + rtd1319_misc_irq: interrupt-controller@80 { >> + compatible = "realtek,rtd1319-intc-misc"; > >Drop, one example is enough. This is the same as previous. > I will fix it in next patches. >> + reg = <0x00 0x80>; >> + interrupts-extended = <&gic GIC_SPI 40 IRQ_TYPE_LEVEL_HIGH>, >> + <&gic GIC_SPI 89 >IRQ_TYPE_LEVEL_HIGH>, >> + <&gic GIC_SPI 90 >IRQ_TYPE_LEVEL_HIGH>, >> + <&gic GIC_SPI 39 >IRQ_TYPE_LEVEL_HIGH>; >> + interrupt-controller; >> + #address-cells = <0>; >> + #interrupt-cells = <1>; >> + }; >> +... >> diff --git >> a/Documentation/devicetree/bindings/interrupt-controller/realtek,rtd13 >> 19d-intc.yaml >> b/Documentation/devicetree/bindings/interrupt-controller/realtek,rtd13 >> 19d-intc.yaml >> new file mode 100644 >> index 000000000000..75aba448baf7 >> --- /dev/null >> +++ b/Documentation/devicetree/bindings/interrupt-controller/realtek,r >> +++ td1319d-intc.yaml >> @@ -0,0 +1,79 @@ >> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) %YAML 1.2 >> +--- >> +$id: >> +http://devicetree.org/schemas/interrupt-controller/realtek,rtd1319d-i >> +ntc.yaml# >> +$schema: http://devicetree.org/meta-schemas/core.yaml# >> + >> +title: Realtek DHC RTD1319D Interrupt Controller Device Tree Bindings >> + >> +description: >> + This interrupt controller is a component of Realtek DHC RTD1319D >> +and >> + is designed to receive interrupts from peripheral devices. >> + >> + Each DHC SoC has two sets of interrupt controllers, each capable of >> + handling up to 32 interrupts. >> + >> +maintainers: >> + - James Tai <james.tai@realtek.com> >> + >> +allOf: >> + - $ref: /schemas/interrupt-controller.yaml# >> + >> +properties: >> + "#interrupt-cells": >> + const: 1 >> + >> + compatible: >> + enum: >> + - realtek,rtd1319d-intc-iso >> + - realtek,rtd1319d-intc-misc > >So this is the same as the other one? Why it cannot be part of that one? I will consolidate these parts into a single file. Thank you for your feedback. Regards, James
Hi Krzysztof, >>> + >>> + compatible: >>> + enum: >>> + - realtek,rtd1319-intc-iso >>> + - realtek,rtd1319-intc-misc >>> + >>> + "#address-cells": >>> + const: 0 >>> + >>> + interrupt-controller: true >>> + >>> + interrupts-extended: >> >>interrupts instead. >> >>Anyway, you must describe the items. Why this is not fixed but flexible? >>Hardware has different number of pins? That's unlikely. >> >I will replace it with 'interrupts'. Since our Interrupt controller architecture >doesn't involve multiple interrupt sources, using 'interrupts' should suffice. > Due to changes in hardware design, some peripheral interrupts pin initially connected to the Realtek interrupt controller were redirected to the GIC. However, the associated fields and statuses in the Realtek interrupt controller registers were not removed. As a result, these interrupts cannot be cleared by peripheral register, and their status clearing is still needing the Realtek interrupt controller driver to manage. That's why flexibility is necessary. Regards, James
Hi Krzysztof, >>> diff --git >>> a/Documentation/devicetree/bindings/interrupt-controller/realtek,rtd1 >>> 3 >>> 19d-intc.yaml >>> b/Documentation/devicetree/bindings/interrupt-controller/realtek,rtd1 >>> 3 >>> 19d-intc.yaml >>> new file mode 100644 >>> index 000000000000..75aba448baf7 >>> --- /dev/null >>> +++ b/Documentation/devicetree/bindings/interrupt-controller/realtek, >>> +++ r >>> +++ td1319d-intc.yaml >>> @@ -0,0 +1,79 @@ >>> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) %YAML 1.2 >>> +--- >>> +$id: >>> +http://devicetree.org/schemas/interrupt-controller/realtek,rtd1319d- >>> +i >>> +ntc.yaml# >>> +$schema: http://devicetree.org/meta-schemas/core.yaml# >>> + >>> +title: Realtek DHC RTD1319D Interrupt Controller Device Tree >>> +Bindings >>> + >>> +description: >>> + This interrupt controller is a component of Realtek DHC RTD1319D >>> +and >>> + is designed to receive interrupts from peripheral devices. >>> + >>> + Each DHC SoC has two sets of interrupt controllers, each capable >>> + of handling up to 32 interrupts. >>> + >>> +maintainers: >>> + - James Tai <james.tai@realtek.com> >>> + >>> +allOf: >>> + - $ref: /schemas/interrupt-controller.yaml# >>> + >>> +properties: >>> + "#interrupt-cells": >>> + const: 1 >>> + >>> + compatible: >>> + enum: >>> + - realtek,rtd1319d-intc-iso >>> + - realtek,rtd1319d-intc-misc >> >>So this is the same as the other one? Why it cannot be part of that one? > >I will consolidate these parts into a single file. > I initially believed that each platform needed its YAML file for documentation and specific configurations. However, it appears that this isn't the case. Regards, James
Hi Krzysztof, >> + >> +maintainers: >> + - James Tai <james.tai@realtek.com> >> + >> +allOf: >> + - $ref: /schemas/interrupt-controller.yaml# >> + >> +properties: >> + "#interrupt-cells": >> + const: 1 >> + >> + compatible: >> + enum: >> + - realtek,rtd1325-intc-iso >> + - realtek,rtd1325-intc-misc > >All my comments apply to all your bindings... > Okay, I will apply to all My bindings. Regards, James
On 02/12/2023 17:18, James Tai [戴志峰] wrote: > Hi Krzysztof, > >>>> + >>>> + compatible: >>>> + enum: >>>> + - realtek,rtd1319-intc-iso >>>> + - realtek,rtd1319-intc-misc >>>> + >>>> + "#address-cells": >>>> + const: 0 >>>> + >>>> + interrupt-controller: true >>>> + >>>> + interrupts-extended: >>> >>> interrupts instead. >>> >>> Anyway, you must describe the items. Why this is not fixed but flexible? >>> Hardware has different number of pins? That's unlikely. >>> >> I will replace it with 'interrupts'. Since our Interrupt controller architecture >> doesn't involve multiple interrupt sources, using 'interrupts' should suffice. >> > > Due to changes in hardware design, some peripheral interrupts pin initially connected to the Realtek interrupt controller were redirected to the GIC. > However, the associated fields and statuses in the Realtek interrupt controller registers were not removed. > As a result, these interrupts cannot be cleared by peripheral register, and their status clearing is still needing the Realtek interrupt controller driver to manage. > > That's why flexibility is necessary. This does not explain why this is not fixed per variant. Best regards, Krzysztof
Hi Krzysztof, >>>>> + >>>>> + compatible: >>>>> + enum: >>>>> + - realtek,rtd1319-intc-iso >>>>> + - realtek,rtd1319-intc-misc >>>>> + >>>>> + "#address-cells": >>>>> + const: 0 >>>>> + >>>>> + interrupt-controller: true >>>>> + >>>>> + interrupts-extended: >>>> >>>> interrupts instead. >>>> >>>> Anyway, you must describe the items. Why this is not fixed but flexible? >>>> Hardware has different number of pins? That's unlikely. >>>> >>> I will replace it with 'interrupts'. Since our Interrupt controller >>> architecture doesn't involve multiple interrupt sources, using 'interrupts' >should suffice. >>> >> >> Due to changes in hardware design, some peripheral interrupts pin initially >connected to the Realtek interrupt controller were redirected to the GIC. >> However, the associated fields and statuses in the Realtek interrupt controller >registers were not removed. >> As a result, these interrupts cannot be cleared by peripheral register, and their >status clearing is still needing the Realtek interrupt controller driver to manage. >> >> That's why flexibility is necessary. > >This does not explain why this is not fixed per variant. > Does the definition of "fixed" you mentioned refer to fixed interrupt pins? If not, could you please give me an example and let me know what you mean by "fixed"? Thank you for your feedback. Regards, James
On 03/12/2023 16:56, James Tai [戴志峰] wrote: >>>>>> + interrupts-extended: >>>>> >>>>> interrupts instead. >>>>> >>>>> Anyway, you must describe the items. Why this is not fixed but flexible? >>>>> Hardware has different number of pins? That's unlikely. >>>>> >>>> I will replace it with 'interrupts'. Since our Interrupt controller >>>> architecture doesn't involve multiple interrupt sources, using 'interrupts' >> should suffice. >>>> >>> >>> Due to changes in hardware design, some peripheral interrupts pin initially >> connected to the Realtek interrupt controller were redirected to the GIC. >>> However, the associated fields and statuses in the Realtek interrupt controller >> registers were not removed. >>> As a result, these interrupts cannot be cleared by peripheral register, and their >> status clearing is still needing the Realtek interrupt controller driver to manage. >>> >>> That's why flexibility is necessary. >> >> This does not explain why this is not fixed per variant. >> > > Does the definition of "fixed" you mentioned refer to fixed interrupt pins? If not, could you please give me an example and let me know what you mean by "fixed"? Number of the interrupts per each device or variant should be strictly defined, not variable. Please wrap your emails according to mail netiquette. Best regards, Krzysztof
Hi Krzysztof, >>>>>>> + interrupts-extended: >>>>>> >>>>>> interrupts instead. >>>>>> >>>>>> Anyway, you must describe the items. Why this is not fixed but flexible? >>>>>> Hardware has different number of pins? That's unlikely. >>>>>> >>>>> I will replace it with 'interrupts'. Since our Interrupt controller >>>>> architecture doesn't involve multiple interrupt sources, using 'interrupts' >>> should suffice. >>>>> >>>> >>>> Due to changes in hardware design, some peripheral interrupts pin >>>> initially >>> connected to the Realtek interrupt controller were redirected to the GIC. >>>> However, the associated fields and statuses in the Realtek interrupt >>>> controller >>> registers were not removed. >>>> As a result, these interrupts cannot be cleared by peripheral >>>> register, and their >>> status clearing is still needing the Realtek interrupt controller driver to >manage. >>>> >>>> That's why flexibility is necessary. >>> >>> This does not explain why this is not fixed per variant. >>> >> >> Does the definition of "fixed" you mentioned refer to fixed interrupt pins? If >> not, could you please give me an example and let me know what you mean by >> "fixed"? > >Number of the interrupts per each device or variant should be strictly defined, >not variable. Thank you for your explanation. The DHC platforms contain two interrupt controllers, each handling peripheral device interrupts in the two power domains. While each has a fixed IRQ numbers, the specific IRQ varies depending on the platform. >Please wrap your emails according to mail netiquette. I apologize for my rude way of asking the question. I will improve my expression. Thank for your feedback. Regards, James
On 05/12/2023 09:43, James Tai [戴志峰] wrote: > Hi Krzysztof, > >>>>>>>> + interrupts-extended: >>>>>>> >>>>>>> interrupts instead. >>>>>>> >>>>>>> Anyway, you must describe the items. Why this is not fixed but flexible? >>>>>>> Hardware has different number of pins? That's unlikely. >>>>>>> >>>>>> I will replace it with 'interrupts'. Since our Interrupt controller >>>>>> architecture doesn't involve multiple interrupt sources, using 'interrupts' >>>> should suffice. >>>>>> >>>>> >>>>> Due to changes in hardware design, some peripheral interrupts pin >>>>> initially >>>> connected to the Realtek interrupt controller were redirected to the GIC. >>>>> However, the associated fields and statuses in the Realtek interrupt >>>>> controller >>>> registers were not removed. >>>>> As a result, these interrupts cannot be cleared by peripheral >>>>> register, and their >>>> status clearing is still needing the Realtek interrupt controller driver to >> manage. >>>>> >>>>> That's why flexibility is necessary. >>>> >>>> This does not explain why this is not fixed per variant. >>>> >>> >>> Does the definition of "fixed" you mentioned refer to fixed interrupt pins? If >>> not, could you please give me an example and let me know what you mean by >>> "fixed"? >> >> Number of the interrupts per each device or variant should be strictly defined, >> not variable. > > Thank you for your explanation. > > The DHC platforms contain two interrupt controllers, each handling peripheral device interrupts in the two power domains. > While each has a fixed IRQ numbers, the specific IRQ varies depending on the platform. Srsly, what "specific IRQ" has anything to do with "number of interrupts per each device or variant"? Look at all other bindings covering multiple devices and their clocks/interrupts/interconnects/reg etc. Best regards, Krzysztof
Hi Krzysztof, >>>>>>>>> + interrupts-extended: >>>>>>>> >>>>>>>> interrupts instead. >>>>>>>> >>>>>>>> Anyway, you must describe the items. Why this is not fixed but >flexible? >>>>>>>> Hardware has different number of pins? That's unlikely. >>>>>>>> >>>>>>> I will replace it with 'interrupts'. Since our Interrupt >>>>>>> controller architecture doesn't involve multiple interrupt sources, using >'interrupts' >>>>> should suffice. >>>>>>> >>>>>> >>>>>> Due to changes in hardware design, some peripheral interrupts pin >>>>>> initially >>>>> connected to the Realtek interrupt controller were redirected to the GIC. >>>>>> However, the associated fields and statuses in the Realtek >>>>>> interrupt controller >>>>> registers were not removed. >>>>>> As a result, these interrupts cannot be cleared by peripheral >>>>>> register, and their >>>>> status clearing is still needing the Realtek interrupt controller >>>>> driver to >>> manage. >>>>>> >>>>>> That's why flexibility is necessary. >>>>> >>>>> This does not explain why this is not fixed per variant. >>>>> >>>> >>>> Does the definition of "fixed" you mentioned refer to fixed >>>> interrupt pins? If not, could you please give me an example and let >>>> me know what you mean by "fixed"? >>> >>> Number of the interrupts per each device or variant should be >>> strictly defined, not variable. >> >> Thank you for your explanation. >> >> The DHC platforms contain two interrupt controllers, each handling peripheral >device interrupts in the two power domains. >> While each has a fixed IRQ numbers, the specific IRQ varies depending on the >>platform. > >Srsly, what "specific IRQ" has anything to do with "number of interrupts per >each device or variant"? Each Realtek interrupt controller is assigned a fixed IRQ, which gathers interrupts from peripheral devices such as i2c, spi, ethernet phy, timer, uart, watchdog, rtc, pwm, etc. Due to modifications in the hardware circuit, certain peripheral device interrupts including watchdog, rtc, uart1, and uart2 are now redirected to the GIC. Consequently, these devices cannot clear interrupt statuses through their own registers. To resolve this, we manage their interrupts through the Realtek interrupt controller. This results in a variation in the number of IRQs registered by the interrupt controllers of ISO (isolation) and MSIC (miscellaneous). In the DTS examples provided in the initial patch release, IRQs 41 and 42 are assigned to the Realtek interrupt controller. As watchdog, rtc, uart1, and uart2 interrupts no longer use IRQs 41 or 42, their IRQs (0, 39, 89, 90) are assigned to be registered by the Realtek interrupt controller. Fixed IRQs: - 41: peripheral devices (iso power domain) - 42: peripheral devices (misc power domain) Specific IRQs: - 0: watchdog (iso power domain) - 39: rtc (misc power domain) - 89: uart1 (misc power domain) - 90: uart2 (misc power domain) Examples(v1 patches): iso_irq_mux: iso_irq_mux@40 { compatible = "realtek,rtd1319-intc-iso"; reg = <0x00 0x40>; interrupts-extended = <&gic GIC_SPI 41 IRQ_TYPE_LEVEL_HIGH>, <&gic GIC_SPI 39 IRQ_TYPE_LEVEL_HIGH>; interrupt-controller; #address-cells = <0>; #interrupt-cells = <1>; }; misc_irq_mux: misc_irq_mux@80 { compatible = "realtek,rtd1319-intc-misc"; reg = <0x00 0x80>; interrupts-extended = <&gic GIC_SPI 40 IRQ_TYPE_LEVEL_HIGH>, <&gic GIC_SPI 0 IRQ_TYPE_LEVEL_HIGH>, <&gic GIC_SPI 89 IRQ_TYPE_LEVEL_HIGH>, <&gic GIC_SPI 90 IRQ_TYPE_LEVEL_HIGH>; interrupt-controller; #address-cells = <0>; #interrupt-cells = <1>; }; iso_irq_mux: iso_irq_mux@40 { compatible = "realtek,rtd1319d-intc-iso"; reg = <0x00 0x40>; interrupts-extended = <&gic GIC_SPI 41 IRQ_TYPE_LEVEL_HIGH>, <&gic GIC_SPI 0 IRQ_TYPE_LEVEL_HIGH>; interrupt-controller; #address-cells = <0>; #interrupt-cells = <1>; }; misc_irq_mux: misc_irq_mux@80 { compatible = "realtek,rtd1319d-intc-misc"; reg = <0x00 0x80>; interrupts-extended = <&gic GIC_SPI 40 IRQ_TYPE_LEVEL_HIGH>, <&gic GIC_SPI 89 IRQ_TYPE_LEVEL_HIGH>, <&gic GIC_SPI 90 IRQ_TYPE_LEVEL_HIGH>, <&gic GIC_SPI 39 IRQ_TYPE_LEVEL_HIGH>; interrupt-controller; #address-cells = <0>; #interrupt-cells = <1>; }; iso_irq_mux: iso_irq_mux@40 { compatible = "realtek,rtd1325-intc-iso"; reg = <0x00 0x40>; interrupts-extended = <&gic GIC_SPI 41 IRQ_TYPE_LEVEL_HIGH>, <&gic GIC_SPI 0 IRQ_TYPE_LEVEL_HIGH>; interrupt-controller; #address-cells = <0>; #interrupt-cells = <1>; }; misc_irq_mux: misc_irq_mux@80 { compatible = "realtek,rtd1325-intc-misc"; reg = <0x00 0x80>; interrupts-extended = <&gic GIC_SPI 40 IRQ_TYPE_LEVEL_HIGH>, <&gic GIC_SPI 89 IRQ_TYPE_LEVEL_HIGH>, <&gic GIC_SPI 90 IRQ_TYPE_LEVEL_HIGH>, <&gic GIC_SPI 39 IRQ_TYPE_LEVEL_HIGH>; interrupt-controller; #address-cells = <0>; #interrupt-cells = <1>; }; iso_irq_mux: iso_irq_mux@40 { compatible = "realtek,rtd1619b-intc-iso"; reg = <0x00 0x40>; interrupts-extended = <&gic GIC_SPI 41 IRQ_TYPE_LEVEL_HIGH>, <&gic GIC_SPI 0 IRQ_TYPE_LEVEL_HIGH>; interrupt-controller; #address-cells = <0>; #interrupt-cells = <1>; }; misc_irq_mux: misc_irq_mux@80 { compatible = "realtek,rtd1619b-intc-misc"; reg = <0x00 0x80>; interrupts-extended = <&gic GIC_SPI 40 IRQ_TYPE_LEVEL_HIGH>, <&gic GIC_SPI 89 IRQ_TYPE_LEVEL_HIGH>, <&gic GIC_SPI 90 IRQ_TYPE_LEVEL_HIGH>, interrupt-controller; #address-cells = <0>; #interrupt-cells = <1>; }; > >Look at all other bindings covering multiple devices and their >clocks/interrupts/interconnects/reg etc. May I adopt the approach used in this YAML for my case? https://www.kernel.org/doc/Documentation/devicetree/bindings/timer/allwinner%2Csun4i-a10-timer.yaml Thank you for your feedback. Regards, James
On 06/12/2023 16:07, James Tai [戴志峰] wrote: > > misc_irq_mux: misc_irq_mux@80 { > compatible = "realtek,rtd1619b-intc-misc"; > reg = <0x00 0x80>; > interrupts-extended = <&gic GIC_SPI 40 IRQ_TYPE_LEVEL_HIGH>, > <&gic GIC_SPI 89 IRQ_TYPE_LEVEL_HIGH>, > <&gic GIC_SPI 90 IRQ_TYPE_LEVEL_HIGH>, > interrupt-controller; > #address-cells = <0>; > #interrupt-cells = <1>; > }; So you have strictly defined number of interrupts and the actual interrupts per variant. > >> >> Look at all other bindings covering multiple devices and their >> clocks/interrupts/interconnects/reg etc. > > May I adopt the approach used in this YAML for my case? > https://www.kernel.org/doc/Documentation/devicetree/bindings/timer/allwinner%2Csun4i-a10-timer.yaml I am asking for this since few emails. Look: "Anyway, you must describe the items. Why this is not fixed but flexible? Hardware has different number of pins? That's unlikely." Best regards, Krzysztof
Hi Krzysztof, >> >> misc_irq_mux: misc_irq_mux@80 { >> compatible = "realtek,rtd1619b-intc-misc"; >> reg = <0x00 0x80>; >> interrupts-extended = <&gic GIC_SPI 40 IRQ_TYPE_LEVEL_HIGH>, >> <&gic GIC_SPI 89 IRQ_TYPE_LEVEL_HIGH>, >> <&gic GIC_SPI 90 IRQ_TYPE_LEVEL_HIGH>, >> interrupt-controller; >> #address-cells = <0>; >> #interrupt-cells = <1>; >> }; > >So you have strictly defined number of interrupts and the actual interrupts per >variant. > Yes, I have defined them. >> >>> >>> Look at all other bindings covering multiple devices and their >>> clocks/interrupts/interconnects/reg etc. >> >> May I adopt the approach used in this YAML for my case? >> https://www.kernel.org/doc/Documentation/devicetree/bindings/timer/all >> winner%2Csun4i-a10-timer.yaml > > >I am asking for this since few emails. > >Look: >"Anyway, you must describe the items. Why this is not fixed but flexible? >Hardware has different number of pins? That's unlikely." > It is fixed, and the hardware has the same number of pins. Regards, James
diff --git a/Documentation/devicetree/bindings/interrupt-controller/realtek,rtd1319-intc.yaml b/Documentation/devicetree/bindings/interrupt-controller/realtek,rtd1319-intc.yaml new file mode 100644 index 000000000000..b88f3ac07cd9 --- /dev/null +++ b/Documentation/devicetree/bindings/interrupt-controller/realtek,rtd1319-intc.yaml @@ -0,0 +1,79 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/interrupt-controller/realtek,rtd1319-intc.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Realtek DHC RTD1319 Interrupt Controller Device Tree Bindings + +description: + This interrupt controller is a component of Realtek DHC RTD1319 and + is designed to receive interrupts from peripheral devices. + + Each DHC SoC has two sets of interrupt controllers, each capable of + handling up to 32 interrupts. + +maintainers: + - James Tai <james.tai@realtek.com> + +allOf: + - $ref: /schemas/interrupt-controller.yaml# + +properties: + "#interrupt-cells": + const: 1 + + compatible: + enum: + - realtek,rtd1319-intc-iso + - realtek,rtd1319-intc-misc + + "#address-cells": + const: 0 + + interrupt-controller: true + + interrupts-extended: + minItems: 1 + maxItems: 4 + + reg: + maxItems: 1 + +required: + - "#interrupt-cells" + - "#address-cells" + - compatible + - interrupt-controller + - interrupts-extended + - reg + +additionalProperties: false + +examples: + - | + #include <dt-bindings/interrupt-controller/irq.h> + #include <dt-bindings/interrupt-controller/arm-gic.h> + + rtd1319_iso_irq: interrupt-controller@40 { + compatible = "realtek,rtd1319-intc-iso"; + reg = <0x00 0x40>; + interrupts-extended = <&gic GIC_SPI 41 IRQ_TYPE_LEVEL_HIGH>, + <&gic GIC_SPI 0 IRQ_TYPE_LEVEL_HIGH>; + interrupt-controller; + #address-cells = <0>; + #interrupt-cells = <1>; + }; + + rtd1319_misc_irq: interrupt-controller@80 { + compatible = "realtek,rtd1319-intc-misc"; + reg = <0x00 0x80>; + interrupts-extended = <&gic GIC_SPI 40 IRQ_TYPE_LEVEL_HIGH>, + <&gic GIC_SPI 89 IRQ_TYPE_LEVEL_HIGH>, + <&gic GIC_SPI 90 IRQ_TYPE_LEVEL_HIGH>, + <&gic GIC_SPI 39 IRQ_TYPE_LEVEL_HIGH>; + interrupt-controller; + #address-cells = <0>; + #interrupt-cells = <1>; + }; +... diff --git a/Documentation/devicetree/bindings/interrupt-controller/realtek,rtd1319d-intc.yaml b/Documentation/devicetree/bindings/interrupt-controller/realtek,rtd1319d-intc.yaml new file mode 100644 index 000000000000..75aba448baf7 --- /dev/null +++ b/Documentation/devicetree/bindings/interrupt-controller/realtek,rtd1319d-intc.yaml @@ -0,0 +1,79 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/interrupt-controller/realtek,rtd1319d-intc.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Realtek DHC RTD1319D Interrupt Controller Device Tree Bindings + +description: + This interrupt controller is a component of Realtek DHC RTD1319D and + is designed to receive interrupts from peripheral devices. + + Each DHC SoC has two sets of interrupt controllers, each capable of + handling up to 32 interrupts. + +maintainers: + - James Tai <james.tai@realtek.com> + +allOf: + - $ref: /schemas/interrupt-controller.yaml# + +properties: + "#interrupt-cells": + const: 1 + + compatible: + enum: + - realtek,rtd1319d-intc-iso + - realtek,rtd1319d-intc-misc + + "#address-cells": + const: 0 + + interrupt-controller: true + + interrupts-extended: + minItems: 1 + maxItems: 4 + + reg: + maxItems: 1 + +required: + - "#interrupt-cells" + - "#address-cells" + - compatible + - interrupt-controller + - interrupts-extended + - reg + +additionalProperties: false + +examples: + - | + #include <dt-bindings/interrupt-controller/irq.h> + #include <dt-bindings/interrupt-controller/arm-gic.h> + + rtd1319d_iso_irq: interrupt-controller@40 { + compatible = "realtek,rtd1319d-intc-iso"; + reg = <0x00 0x40>; + interrupts-extended = <&gic GIC_SPI 41 IRQ_TYPE_LEVEL_HIGH>, + <&gic GIC_SPI 0 IRQ_TYPE_LEVEL_HIGH>; + interrupt-controller; + #address-cells = <0>; + #interrupt-cells = <1>; + }; + + rtd1319d_misc_irq: interrupt-controller@80 { + compatible = "realtek,rtd1319d-intc-misc"; + reg = <0x00 0x80>; + interrupts-extended = <&gic GIC_SPI 40 IRQ_TYPE_LEVEL_HIGH>, + <&gic GIC_SPI 89 IRQ_TYPE_LEVEL_HIGH>, + <&gic GIC_SPI 90 IRQ_TYPE_LEVEL_HIGH>, + <&gic GIC_SPI 39 IRQ_TYPE_LEVEL_HIGH>; + interrupt-controller; + #address-cells = <0>; + #interrupt-cells = <1>; + }; +... diff --git a/Documentation/devicetree/bindings/interrupt-controller/realtek,rtd1325-intc.yaml b/Documentation/devicetree/bindings/interrupt-controller/realtek,rtd1325-intc.yaml new file mode 100644 index 000000000000..49e71d17390a --- /dev/null +++ b/Documentation/devicetree/bindings/interrupt-controller/realtek,rtd1325-intc.yaml @@ -0,0 +1,79 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/interrupt-controller/realtek,rtd1325-intc.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Realtek DHC RTD1325 Interrupt Controller Device Tree Bindings + +description: + This interrupt controller is a component of Realtek DHC RTD1325 and + is designed to receive interrupts from peripheral devices. + + Each DHC SoC has two sets of interrupt controllers, each capable of + handling up to 32 interrupts. + +maintainers: + - James Tai <james.tai@realtek.com> + +allOf: + - $ref: /schemas/interrupt-controller.yaml# + +properties: + "#interrupt-cells": + const: 1 + + compatible: + enum: + - realtek,rtd1325-intc-iso + - realtek,rtd1325-intc-misc + + "#address-cells": + const: 0 + + interrupt-controller: true + + interrupts-extended: + minItems: 1 + maxItems: 4 + + reg: + maxItems: 1 + +required: + - "#interrupt-cells" + - "#address-cells" + - compatible + - interrupt-controller + - interrupts-extended + - reg + +additionalProperties: false + +examples: + - | + #include <dt-bindings/interrupt-controller/irq.h> + #include <dt-bindings/interrupt-controller/arm-gic.h> + + rtd1325_iso_irq: interrupt-controller@40 { + compatible = "realtek,rtd1325-intc-iso"; + reg = <0x00 0x40>; + interrupts-extended = <&gic GIC_SPI 41 IRQ_TYPE_LEVEL_HIGH>, + <&gic GIC_SPI 0 IRQ_TYPE_LEVEL_HIGH>; + interrupt-controller; + #address-cells = <0>; + #interrupt-cells = <1>; + }; + + rtd1325_misc_irq: interrupt-controller@80 { + compatible = "realtek,rtd1325-intc-misc"; + reg = <0x00 0x80>; + interrupts-extended = <&gic GIC_SPI 40 IRQ_TYPE_LEVEL_HIGH>, + <&gic GIC_SPI 89 IRQ_TYPE_LEVEL_HIGH>, + <&gic GIC_SPI 90 IRQ_TYPE_LEVEL_HIGH>, + <&gic GIC_SPI 39 IRQ_TYPE_LEVEL_HIGH>; + interrupt-controller; + #address-cells = <0>; + #interrupt-cells = <1>; + }; +... diff --git a/Documentation/devicetree/bindings/interrupt-controller/realtek,rtd1619b-intc.yaml b/Documentation/devicetree/bindings/interrupt-controller/realtek,rtd1619b-intc.yaml new file mode 100644 index 000000000000..79d855d15893 --- /dev/null +++ b/Documentation/devicetree/bindings/interrupt-controller/realtek,rtd1619b-intc.yaml @@ -0,0 +1,78 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/interrupt-controller/realtek,rtd1619b-intc.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Realtek DHC RTD1619B Interrupt Controller Device Tree Bindings + +description: + This interrupt controller is a component of Realtek DHC RTD1619B and + is designed to receive interrupts from peripheral devices. + + Each DHC SoC has two sets of interrupt controllers, each capable of + handling up to 32 interrupts. + +maintainers: + - James Tai <james.tai@realtek.com> + +allOf: + - $ref: /schemas/interrupt-controller.yaml# + +properties: + "#interrupt-cells": + const: 1 + + compatible: + enum: + - realtek,rtd1619b-intc-iso + - realtek,rtd1619b-intc-misc + + "#address-cells": + const: 0 + + interrupt-controller: true + + interrupts-extended: + minItems: 1 + maxItems: 4 + + reg: + maxItems: 1 + +required: + - "#interrupt-cells" + - "#address-cells" + - compatible + - interrupt-controller + - interrupts-extended + - reg + +additionalProperties: false + +examples: + - | + #include <dt-bindings/interrupt-controller/irq.h> + #include <dt-bindings/interrupt-controller/arm-gic.h> + + rtd1619b_iso_irq: interrupt-controller@40 { + compatible = "realtek,rtd1619b-intc-iso"; + reg = <0x00 0x40>; + interrupts-extended = <&gic GIC_SPI 41 IRQ_TYPE_LEVEL_HIGH>, + <&gic GIC_SPI 0 IRQ_TYPE_LEVEL_HIGH>; + interrupt-controller; + #address-cells = <0>; + #interrupt-cells = <1>; + }; + + rtd1619b_misc_irq: interrupt-controller@80 { + compatible = "realtek,rtd1619b-intc-misc"; + reg = <0x00 0x80>; + interrupts-extended = <&gic GIC_SPI 40 IRQ_TYPE_LEVEL_HIGH>, + <&gic GIC_SPI 89 IRQ_TYPE_LEVEL_HIGH>, + <&gic GIC_SPI 90 IRQ_TYPE_LEVEL_HIGH>; + interrupt-controller; + #address-cells = <0>; + #interrupt-cells = <1>; + }; +...
Add the YAML documentation for Realtek DHC SoCs. CC: Thomas Gleixner <tglx@linutronix.de> CC: Marc Zyngier <maz@kernel.org> CC: Rob Herring <robh+dt@kernel.org> CC: Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org> CC: Conor Dooley <conor+dt@kernel.org> CC: linux-kernel@vger.kernel.org CC: devicetree@vger.kernel.org Signed-off-by: James Tai <james.tai@realtek.com> --- v1 to v2 change: - Tested the bindings using 'make dt_binding_check' - Fixed code style issues .../realtek,rtd1319-intc.yaml | 79 +++++++++++++++++++ .../realtek,rtd1319d-intc.yaml | 79 +++++++++++++++++++ .../realtek,rtd1325-intc.yaml | 79 +++++++++++++++++++ .../realtek,rtd1619b-intc.yaml | 78 ++++++++++++++++++ 4 files changed, 315 insertions(+) create mode 100644 Documentation/devicetree/bindings/interrupt-controller/realtek,rtd1319-intc.yaml create mode 100644 Documentation/devicetree/bindings/interrupt-controller/realtek,rtd1319d-intc.yaml create mode 100644 Documentation/devicetree/bindings/interrupt-controller/realtek,rtd1325-intc.yaml create mode 100644 Documentation/devicetree/bindings/interrupt-controller/realtek,rtd1619b-intc.yaml