Re: [PATCH] dt-bindings: soc: Add new board description for MicroBlaze V
From: Michal Simek
Date: Tue Nov 07 2023 - 07:12:53 EST
On 11/7/23 12:27, Krzysztof Kozlowski wrote:
On 07/11/2023 12:09, Michal Simek wrote:
On 11/6/23 18:07, Conor Dooley wrote:
On Mon, Nov 06, 2023 at 12:53:40PM +0100, Michal Simek wrote:
MicroBlaze V is new AMD/Xilinx soft-core 32bit RISC-V processor IP.
It is hardware compatible with classic MicroBlaze processor. Processor can
be used with standard AMD/Xilinx IPs including interrupt controller and
timer.
Signed-off-by: Michal Simek <michal.simek@xxxxxxx>
---
.../devicetree/bindings/soc/amd/amd.yaml | 26 +++++++++++++++++++
Bindings for SoCs (and by extension boards with them) usually go to in
$arch/$vendor.yaml not into soc/$vendor/$vendor.yaml. Why is this any
different?
I actually found it based on tracking renesas.yaml which describes one of risc-v
board. No problem to move it under bindings/riscv/
1 file changed, 26 insertions(+)
create mode 100644 Documentation/devicetree/bindings/soc/amd/amd.yaml
diff --git a/Documentation/devicetree/bindings/soc/amd/amd.yaml b/Documentation/devicetree/bindings/soc/amd/amd.yaml
new file mode 100644
index 000000000000..21adf28756fa
--- /dev/null
+++ b/Documentation/devicetree/bindings/soc/amd/amd.yaml
@@ -0,0 +1,26 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/soc/amd/amd.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: AMD Platforms
+
+maintainers:
+ - Michal Simek <michal.simek@xxxxxxx>
+
+description: |
+ AMD boards with MicroBlaze V SOC
+
+properties:
+ $nodename:
+ const: '/'
+ compatible:
+ oneOf:
+ - description: AMD MicroBlaze V
+ items:
+ - const: amd,mbv
You don't actually list any boards here, but instead permit having only
the SoC compatible and no board one. The SoC compatible is also
incredibly generic. Personally I don't think this binding makes any
sense as it appears to exist as a catch all for anything using your
new cores in any combination.
I think I need to define any string for compatibility because it is standard
property. Because this is soft core it can be added to any board with AMD/Xilinx
chip. I don't have really an option to list all boards.
Why? Either there is a product with this soft-core or there is not. It
cannot be both.
I am doing basic enablement. I am not making product. Product will be done by
our customers using this core.
There will be thousands of different configurations done by customers which will
have products with it. Also there could be hundreds configurations done on the
same board.
Does it make sense to have board related compatible string like this if this
evaluation board is used by a lot of customers?
"amd,kcu105-mbv-ABC-vXYZ", "amd,kcu105-mbv", "amd,mbv"
Or I can define qemu one.
"amd,qemu-mbv", "amd,mbv"
I think customers should be adding their compatible string in front of generic one.
Years ago I have done the same thing with Microblaze where compatible is defined
as xlnx,microblaze only. When customer take this soft core, put IPs around and
create a product they should extend it to be for example like this.
"xyz,my-product-1.0", "xlnx,microblaze";
And over all of years I have never seen any single customer to try to push dt
description for any Microblaze based product.
I am happy to change it to something else but not sure to what.
Alone this compatible does not bring you anything.
I don't agree with it. It is standard property and I have to define it somehow.
If not, I get an error.
.../xilinx-mbv32.dtb: /: 'compatible' is a required property
And it tells me that this risc-v compatible core runs on AMD fpga and it is
compatible with it.
Thanks,
Michal