Add the YAML documentation for Realtek DHC SoCs.
CC: Thomas Gleixner <[email protected]>
CC: Marc Zyngier <[email protected]>
CC: Rob Herring <[email protected]>
CC: Krzysztof Kozlowski <[email protected]>
CC: Conor Dooley <[email protected]>
CC: [email protected]
CC: [email protected]
Signed-off-by: James Tai <[email protected]>
---
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
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 <[email protected]>
+
+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 <[email protected]>
+
+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 <[email protected]>
+
+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 <[email protected]>
+
+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>;
+ };
+...
--
2.25.1
On Sat, 18 Nov 2023 00:27:04 +0800, James Tai wrote:
> Add the YAML documentation for Realtek DHC SoCs.
>
> CC: Thomas Gleixner <[email protected]>
> CC: Marc Zyngier <[email protected]>
> CC: Rob Herring <[email protected]>
> CC: Krzysztof Kozlowski <[email protected]>
> CC: Conor Dooley <[email protected]>
> CC: [email protected]
> CC: [email protected]
> Signed-off-by: James Tai <[email protected]>
> ---
> 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/[email protected]
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/[email protected]/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 <[email protected]>
| Closes: https://lore.kernel.org/oe-kbuild-all/[email protected]/
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#
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
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
>[email protected]
>
>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 <[email protected]>
> CC: Marc Zyngier <[email protected]>
> CC: Rob Herring <[email protected]>
> CC: Krzysztof Kozlowski <[email protected]>
> CC: Conor Dooley <[email protected]>
> CC: [email protected]
> CC: [email protected]
> Signed-off-by: James Tai <[email protected]>
> ---
> 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 <[email protected]>
> +
> +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 <[email protected]>
> +
> +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 <[email protected]>
> +
> +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 <[email protected]>
>> +
>> +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 <[email protected]>
>> +
>> +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 <[email protected]>
>>> +
>>> +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 <[email protected]>
>> +
>> +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