From: Miquel Raynal <miquel.raynal@bootlin.com>
To: Rob Herring <robh+dt@kernel.org>, <devicetree@vger.kernel.org>,
Alexandre Belloni <alexandre.belloni@bootlin.com>,
linux-i3c@lists.infradead.org
Cc: Miquel Raynal <miquel.raynal@bootlin.com>,
Rajeev Huralikoppi <rajeev.huralikoppi@silvaco.com>,
Conor Culhane <conor.culhane@silvaco.com>,
Thomas Petazzoni <thomas.petazzoni@bootlin.com>,
Nicolas Pitre <nico@fluxnic.net>
Subject: [PATCH v4 1/6] dt-bindings: i3c: Convert controller description to yaml
Date: Thu, 14 Jan 2021 18:55:53 +0100 [thread overview]
Message-ID: <20210114175558.17097-2-miquel.raynal@bootlin.com> (raw)
In-Reply-To: <20210114175558.17097-1-miquel.raynal@bootlin.com>
Attempting a conversion of the i3c.txt file to yaml schema with
minimal content changes.
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
---
Documentation/devicetree/bindings/i3c/i3c.txt | 140 -------------
.../devicetree/bindings/i3c/i3c.yaml | 186 ++++++++++++++++++
2 files changed, 186 insertions(+), 140 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/i3c/i3c.txt
create mode 100644 Documentation/devicetree/bindings/i3c/i3c.yaml
diff --git a/Documentation/devicetree/bindings/i3c/i3c.txt b/Documentation/devicetree/bindings/i3c/i3c.txt
deleted file mode 100644
index 4ffe059f0fec..000000000000
--- a/Documentation/devicetree/bindings/i3c/i3c.txt
+++ /dev/null
@@ -1,140 +0,0 @@
-Generic device tree bindings for I3C busses
-===========================================
-
-This document describes generic bindings that should be used to describe I3C
-busses in a device tree.
-
-Required properties
--------------------
-
-- #address-cells - should be <3>. Read more about addresses below.
-- #size-cells - should be <0>.
-- compatible - name of the I3C master controller driving the I3C bus
-
-For other required properties e.g. to describe register sets,
-clocks, etc. check the binding documentation of the specific driver.
-The node describing an I3C bus should be named i3c-master.
-
-Optional properties
--------------------
-
-These properties may not be supported by all I3C master drivers. Each I3C
-master bindings should specify which of them are supported.
-
-- i3c-scl-hz: frequency of the SCL signal used for I3C transfers.
- When undefined the core sets it to 12.5MHz.
-
-- i2c-scl-hz: frequency of the SCL signal used for I2C transfers.
- When undefined, the core looks at LVR (Legacy Virtual Register)
- values of I2C devices described in the device tree to determine
- the maximum I2C frequency.
-
-I2C devices
-===========
-
-Each I2C device connected to the bus should be described in a subnode. All
-properties described in Documentation/devicetree/bindings/i2c/i2c.txt are
-valid here, but several new properties have been added.
-
-New constraint on existing properties:
---------------------------------------
-- reg: contains 3 cells
- + first cell : still encoding the I2C address. 10 bit addressing is not
- supported. Devices with 10 bit address can't be properly passed through
- DEFSLVS command.
-
- + second cell: shall be 0
-
- + third cell: shall encode the I3C LVR (Legacy Virtual Register)
- bit[31:8]: unused/ignored
- bit[7:5]: I2C device index. Possible values
- * 0: I2C device has a 50 ns spike filter
- * 1: I2C device does not have a 50 ns spike filter but supports high
- frequency on SCL
- * 2: I2C device does not have a 50 ns spike filter and is not tolerant
- to high frequencies
- * 3-7: reserved
-
- bit[4]: tell whether the device operates in FM (Fast Mode) or FM+ mode
- * 0: FM+ mode
- * 1: FM mode
-
- bit[3:0]: device type
- * 0-15: reserved
-
-The I2C node unit-address should always match the first cell of the reg
-property: <device-type>@<i2c-address>.
-
-I3C devices
-===========
-
-All I3C devices are supposed to support DAA (Dynamic Address Assignment), and
-are thus discoverable. So, by default, I3C devices do not have to be described
-in the device tree.
-This being said, one might want to attach extra resources to these devices,
-and those resources may have to be described in the device tree, which in turn
-means we have to describe I3C devices.
-
-Another use case for describing an I3C device in the device tree is when this
-I3C device has a static I2C address and we want to assign it a specific I3C
-dynamic address before the DAA takes place (so that other devices on the bus
-can't take this dynamic address).
-
-The I3C device should be names <device-type>@<static-i2c-address>,<i3c-pid>,
-where device-type is describing the type of device connected on the bus
-(gpio-controller, sensor, ...).
-
-Required properties
--------------------
-- reg: contains 3 cells
- + first cell : encodes the static I2C address. Should be 0 if the device does
- not have one (0 is not a valid I2C address).
-
- + second and third cells: should encode the ProvisionalID. The second cell
- contains the manufacturer ID left-shifted by 1.
- The third cell contains ORing of the part ID
- left-shifted by 16, the instance ID left-shifted
- by 12 and the extra information. This encoding is
- following the PID definition provided by the I3C
- specification.
-
-Optional properties
--------------------
-- assigned-address: dynamic address to be assigned to this device. This
- property is only valid if the I3C device has a static
- address (first cell of the reg property != 0).
-
-
-Example:
-
- i3c-master@d040000 {
- compatible = "cdns,i3c-master";
- clocks = <&coreclock>, <&i3csysclock>;
- clock-names = "pclk", "sysclk";
- interrupts = <3 0>;
- reg = <0x0d040000 0x1000>;
- #address-cells = <3>;
- #size-cells = <0>;
- i2c-scl-hz = <100000>;
-
- /* I2C device. */
- nunchuk: nunchuk@52 {
- compatible = "nintendo,nunchuk";
- reg = <0x52 0x0 0x10>;
- };
-
- /* I3C device with a static I2C address. */
- thermal_sensor: sensor@68,39200144004 {
- reg = <0x68 0x392 0x144004>;
- assigned-address = <0xa>;
- };
-
- /*
- * I3C device without a static I2C address but requiring
- * resources described in the DT.
- */
- sensor@0,39200154004 {
- reg = <0x0 0x392 0x154004>;
- clocks = <&clock_provider 0>;
- };
- };
diff --git a/Documentation/devicetree/bindings/i3c/i3c.yaml b/Documentation/devicetree/bindings/i3c/i3c.yaml
new file mode 100644
index 000000000000..79df533ab094
--- /dev/null
+++ b/Documentation/devicetree/bindings/i3c/i3c.yaml
@@ -0,0 +1,186 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/i3c/i3c.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: I3C bus binding
+
+maintainers:
+ - Alexandre Belloni <alexandre.belloni@bootlin.com>
+ - Miquel Raynal <miquel.raynal@bootlin.com>
+
+description: |
+ I3C busses can be described with a node for the primary I3C controller device
+ and a set of child nodes for each I2C or I3C slave on the bus. Each of them
+ may, during the life of the bus, request mastership.
+
+properties:
+ $nodename:
+ pattern: "^i3c-master(@.*|-[0-9a-f])*$"
+
+ "#address-cells":
+ const: 3
+ description: |
+ Each I2C device connected to the bus should be described in a subnode.
+
+ All I3C devices are supposed to support DAA (Dynamic Address Assignment),
+ and are thus discoverable. So, by default, I3C devices do not have to be
+ described in the device tree. This being said, one might want to attach
+ extra resources to these devices, and those resources may have to be
+ described in the device tree, which in turn means we have to describe
+ I3C devices.
+
+ Another use case for describing an I3C device in the device tree is when
+ this I3C device has a static I2C address and we want to assign it a
+ specific I3C dynamic address before the DAA takes place (so that other
+ devices on the bus can't take this dynamic address).
+
+ "#size-cells":
+ const: 0
+
+ i3c-scl-hz:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description: |
+ Frequency of the SCL signal used for I3C transfers. When undefined, the
+ default value should be 12.5MHz.
+
+ May not be supported by all controllers.
+
+ i2c-scl-hz:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description: |
+ Frequency of the SCL signal used for I2C transfers. When undefined, the
+ default should be to look at LVR (Legacy Virtual Register) values of
+ I2C devices described in the device tree to determine the maximum I2C
+ frequency.
+
+ May not be supported by all controllers.
+
+required:
+ - "#address-cells"
+ - "#size-cells"
+
+patternProperties:
+ "^.*@[0-9a-f]+$":
+ type: object
+ description: |
+ I2C child, should be named: <device-type>@<i2c-address>
+
+ All properties described in Documentation/devicetree/bindings/i2c/i2c.txt
+ are valid here, except the reg property whose content is changed.
+
+ properties:
+ compatible:
+ description:
+ Compatible of the I2C device.
+
+ reg:
+ items:
+ - description: |
+ 1st cell
+ ========
+
+ I2C address. 10 bit addressing is not supported. Devices with
+ 10-bit address can't be properly passed through DEFSLVS command.
+
+ 2nd cell
+ ========
+
+ Should be 0.
+
+ 3rd cell
+ ========
+
+ Shall encode the I3C LVR (Legacy Virtual Register):
+ bit[31:8]: unused/ignored
+ bit[7:5]: I2C device index. Possible values:
+ * 0: I2C device has a 50 ns spike filter
+ * 1: I2C device does not have a 50 ns spike filter but supports
+ high frequency on SCL
+ * 2: I2C device does not have a 50 ns spike filter and is not
+ tolerant to high frequencies
+ * 3-7: reserved
+ bit[4]: tell whether the device operates in FM (Fast Mode) or
+ FM+ mode:
+ * 0: FM+ mode
+ * 1: FM mode
+ bit[3:0]: device type
+ * 0-15: reserved
+
+ required:
+ - compatible
+ - reg
+
+ "^.*@[0-9a-f]+,[0-9a-f]+$":
+ type: object
+ description: |
+ I3C child, should be named: <device-type>@<static-i2c-address>,<i3c-pid>
+
+ properties:
+ reg:
+ items:
+ - description: |
+ 1st cell
+ ========
+
+ Encodes the static I2C address. Should be 0 if the device does not
+ have one (0 is not a valid I2C address).
+
+ 2nd and 3rd cells
+ =================
+
+ ProvisionalID (following the PID definition provided by the I3C
+ specification).
+
+ Cell 2 contains the manufacturer ID left-shifted by 1. Cell 3
+ contains the ORing of the part ID left-shifted by 16, the instance
+ ID left-shifted by 12 and extra information.
+
+ assigned-address:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ minimum: 0x01
+ maximum: 0xFF
+ description: |
+ Dynamic address to be assigned to this device. This property is only
+ valid if the I3C device has a static address (first cell of the reg
+ property != 0).
+
+ required:
+ - reg
+
+additionalProperties: true
+
+examples:
+ - |
+ i3c-master@d040000 {
+ compatible = "cdns,i3c-master";
+ clocks = <&coreclock>, <&i3csysclock>;
+ clock-names = "pclk", "sysclk";
+ interrupts = <3 0>;
+ reg = <0x0d040000 0x1000>;
+ #address-cells = <3>;
+ #size-cells = <0>;
+ i2c-scl-hz = <100000>;
+
+ /* I2C device. */
+ nunchuk: nunchuk@52 {
+ compatible = "nintendo,nunchuk";
+ reg = <0x52 0x0 0x10>;
+ };
+
+ /* I3C device with a static I2C address. */
+ thermal_sensor: sensor@68,39200144004 {
+ reg = <0x68 0x392 0x144004>;
+ assigned-address = <0xa>;
+ };
+
+ /*
+ * I3C device without a static I2C address but requiring
+ * resources described in the DT.
+ */
+ sensor@0,39200154004 {
+ reg = <0x0 0x392 0x154004>;
+ clocks = <&clock_provider 0>;
+ };
+ };
--
2.20.1
--
linux-i3c mailing list
linux-i3c@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-i3c
next prev parent reply other threads:[~2021-01-14 17:56 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-01-14 17:55 [PATCH v4 0/6] Silvaco I3C master driver Miquel Raynal
2021-01-14 17:55 ` Miquel Raynal [this message]
2021-01-15 17:03 ` [PATCH v4 1/6] dt-bindings: i3c: Convert controller description to yaml Rob Herring
2021-01-18 15:25 ` Miquel Raynal
2021-01-18 17:21 ` Miquel Raynal
2021-01-14 17:55 ` [PATCH v4 2/6] dt-bindings: i3c: mipi-hci: Include the bus binding Miquel Raynal
2021-01-14 22:54 ` Rob Herring
2021-01-14 17:55 ` [PATCH v4 3/6] dt-bindings: Add vendor prefix for Silvaco Miquel Raynal
2021-01-14 17:55 ` [PATCH v4 4/6] dt-bindings: i3c: Describe Silvaco master binding Miquel Raynal
2021-01-15 17:08 ` Rob Herring
2021-01-14 17:55 ` [PATCH v4 5/6] i3c: master: svc: Add Silvaco I3C master driver Miquel Raynal
2021-01-14 17:55 ` [PATCH v4 6/6] MAINTAINERS: Add Silvaco I3C master Miquel Raynal
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20210114175558.17097-2-miquel.raynal@bootlin.com \
--to=miquel.raynal@bootlin.com \
--cc=alexandre.belloni@bootlin.com \
--cc=conor.culhane@silvaco.com \
--cc=devicetree@vger.kernel.org \
--cc=linux-i3c@lists.infradead.org \
--cc=nico@fluxnic.net \
--cc=rajeev.huralikoppi@silvaco.com \
--cc=robh+dt@kernel.org \
--cc=thomas.petazzoni@bootlin.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).