On Thu, Sep 2, 2021 at 6:04 AM Rob Herring [off-list ref] wrote:

On Wed, Sep 1, 2021 at 6:56 AM Anup Patel [off-list ref] wrote:

quoted

On Wed, Sep 1, 2021 at 6:54 AM Rob Herring [off-list ref] wrote:

quoted

On Mon, Aug 30, 2021 at 09:47:23AM +0530, Anup Patel wrote:

quoted

We add DT bindings documentation for the ACLINT MSWI and SSWI
devices found on RISC-V SOCs.

Signed-off-by: Anup Patel <redacted>
Reviewed-by: Bin Meng <redacted>
---
 .../riscv,aclint-swi.yaml                     | 95 +++++++++++++++++++
 1 file changed, 95 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/interrupt-controller/riscv,aclint-swi.yaml

diff --git a/Documentation/devicetree/bindings/interrupt-controller/riscv,aclint-swi.yaml b/Documentation/devicetree/bindings/interrupt-controller/riscv,aclint-swi.yaml
new file mode 100644
index 000000000000..68563259ae24
--- /dev/null
+++ b/Documentation/devicetree/bindings/interrupt-controller/riscv,aclint-swi.yaml

@@ -0,0 +1,95 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/interrupt-controller/riscv,aclint-swi.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: RISC-V ACLINT Software Interrupt Devices
+
+maintainers:
+  - Anup Patel <anup.patel@wdc.com>
+
+description:
+  RISC-V SOCs include an implementation of the M-level software interrupt
+  (MSWI) device and the S-level software interrupt (SSWI) device defined
+  in the RISC-V Advanced Core Local Interruptor (ACLINT) specification.
+
+  The ACLINT MSWI and SSWI devices are documented in the RISC-V ACLINT
+  specification located at
+  https://github.com/riscv/riscv-aclint/blob/main/riscv-aclint.adoc.
+
+  The ACLINT MSWI and SSWI devices directly connect to the M-level and
+  S-level software interrupt lines of various HARTs (or CPUs) respectively
+  so the RISC-V per-HART (or per-CPU) local interrupt controller is the
+  parent interrupt controller for the ACLINT MSWI and SSWI devices.
+
+allOf:
+  - $ref: /schemas/interrupt-controller.yaml#
+
+properties:
+  compatible:
+    oneOf:
+      - items:
+        - enum:
+          - riscv,aclint-mswi
+
+      - items:
+        - enum:
+          - riscv,aclint-sswi

All this can be just:

enum:
  - riscv,aclint-mswi
  - riscv,aclint-sswi

However...

quoted

+
+    description:
+      For ACLINT MSWI devices, it should be "riscv,aclint-mswi" OR
+      "<vendor>,<chip>-aclint-mswi".
+      For ACLINT SSWI devices, it should be "riscv,aclint-sswi" OR
+      "<vendor>,<chip>-aclint-sswi".

s/OR/AND/

There must be a compatible for the implementation. Unless RiscV
implementations of specs are complete describing all clocks, power
domains, resets, etc. and are quirk free.

But don't write free form constraints...

It is possible that quite a few implementations (QEMU, FPGAs, and
other simulators) will not require implementation specific compatible
strings. Should we still mandate implementation specific compatible
strings in DTS for such cases?

No, but the schema says you only have those cases. Are there not any
actual implementations?

All existing RISC-V boards have SiFive CLINT and ACLINT is backward
compatible with SiFive CLINT so we do have actual implementations.

None of the existing RISC-V boards have special clocks, power domain,
resets etc for these devices.

Minimally make "<vendor>,<chip>-aclint-mswi" into a schema pattern for
the first entry and perhaps a note to replace with actual strings when
there are some. It's ultimately up to the RiscV maintainers to require
SoC specific compatibles here. Allowing a generic one alone makes that
harder because the schema can't enforce it.

Can we have a common compatible string for QEMU, FPGAs, etc ?

For example,
compatible = "riscv,generic-aclint-mswi", "riscv,aclint-mswi";

Regards,
Anup

Rob

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv