Hi Rob,
On 9/6/25 01:40, Rob Herring wrote:
On Fri, Sep 05, 2025 at 05:07:39PM +0530, Manikanta Guntupalli wrote:
Add device tree binding documentation for the AMD I3C master controller.
Signed-off-by: Manikanta Guntupalli <[email protected]>
---
Changes for V2:
Updated commit subject and description.
Moved allOf to after required.
Removed xlnx,num-targets property.
Changes for V3:
Updated commit description.
Corrected the order of properties and removed resets property.
Added compatible to required list.
Added interrupts to example.
Changes for V4:
Added h/w documentation details.
---
.../devicetree/bindings/i3c/xlnx,axi-i3c.yaml | 55 +++++++++++++++++++
1 file changed, 55 insertions(+)
create mode 100644 Documentation/devicetree/bindings/i3c/xlnx,axi-i3c.yaml
diff --git a/Documentation/devicetree/bindings/i3c/xlnx,axi-i3c.yaml
b/Documentation/devicetree/bindings/i3c/xlnx,axi-i3c.yaml
new file mode 100644
index 000000000000..1daeb20205ac
--- /dev/null
+++ b/Documentation/devicetree/bindings/i3c/xlnx,axi-i3c.yaml
@@ -0,0 +1,55 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/i3c/xlnx,axi-i3c.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: AMD I3C master
+
+maintainers:
+ - Manikanta Guntupalli <[email protected]>
+
+description:
+ The AXI-I3C IP is an I3C Controller with an AXI4-Lite interface, compatible
+ with the MIPI I3C Specification v1.1.1. The design includes bidirectional I/O
+ buffers that implement open collector drivers for the SDA and SCL signals.
+ External pull-up resistors are required to properly hold the bus at a Logic-1
+ level when the drivers are released.
+
+ For more details, please see https://docs.amd.com/r/en-US/pg439-axi-i3c
+
+properties:
+ compatible:
+ const: xlnx,axi-i3c-1.0
I'm still wondering where 1.0 comes from? From the link the only
versions I could see are Vivado tool versions which appear to be year
based. If the IP is bundled with the tool, then use the tool version
(oldest version you tested with) if there is no other versioning. A 1.0
version really just sounds like you made it up.
Something like bindings/sifive/sifive,blocks-ip-versioning.yaml is what
I'm looking for.
This is what I have found in public space talking about it.
https://www.amd.com/en/products/adaptive-socs-and-fpgas/intellectual-property/vivado-ip-versioning.html
https://docs.amd.com/r/en-US/ug1118-vivado-creating-packaging-custom-ip/Versioning-and-Revision-Control
https://docs.amd.com/r/en-US/ug896-vivado-ip/Upgrading-IP
In past structure was slightly different.
There was also alphabet suffix.
You can see it for example here
Documentation/devicetree/bindings/timer/xlnx,xps-timer.yaml
This is for example change log based on Vivado version to give you an idea how
it is tracked and described.
Thanks,
Michal
2025.1:
* Version 1.0 (Rev. 4)
* New Feature: Dynamic addressing feature updated to handle dynamic address
register update within the IP.
* New Feature: Updated IP Catalog taxonomy structure. This change has no
impact to the IP.
* Revision change in one or more subcores
2024.2.2:
* Version 1.0 (Rev. 3)
* No changes
2024.2.1:
* Version 1.0 (Rev. 3)
* Revision change in one or more subcores
2024.2:
* Version 1.0 (Rev. 2)
* New Feature: Support for Target added
* Revision change in one or more subcores
2024.1.2:
* Version 1.0 (Rev. 1)
* No changes
2024.1.1:
* Version 1.0 (Rev. 1)
* Revision change in one or more subcores
2024.1:
* Version 1.0
* General: Initial release
