[PATCH v2] dt-bindings: i2c: Move i2c-omap.txt to YAML format

Convert i2c-omap.txt to YAML schema for better checks and documentation.

Following properties were used in DT but were not documented in txt
bindings and has been included in YAML schema:
1. Include ti,am4372-i2c compatible
2. Include dmas property used in few OMAP dts files
3. Document clocks property

Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
---
v2:
Fix issues with make dt_bindings_check
Add description on usage of ti,hwmods

 .../devicetree/bindings/i2c/i2c-omap.txt      | 37 ---------
 .../devicetree/bindings/i2c/ti,omap4-i2c.yaml | 80 +++++++++++++++++++
 2 files changed, 80 insertions(+), 37 deletions(-)
 delete mode 100644 Documentation/devicetree/bindings/i2c/i2c-omap.txt
 create mode 100644 Documentation/devicetree/bindings/i2c/ti,omap4-i2c.yaml

diff --git a/Documentation/devicetree/bindings/i2c/i2c-omap.txt b/Documentation/devicetree/bindings/i2c/i2c-omap.txt
deleted file mode 100644
index a425b91af48f..000000000000
--- a/Documentation/devicetree/bindings/i2c/i2c-omap.txt
+++ /dev/null

@@ -1,37 +0,0 @@
-I2C for OMAP platforms
-
-Required properties :
-- compatible : Must be
-	"ti,omap2420-i2c" for OMAP2420 SoCs
-	"ti,omap2430-i2c" for OMAP2430 SoCs
-	"ti,omap3-i2c" for OMAP3 SoCs
-	"ti,omap4-i2c" for OMAP4+ SoCs
-	"ti,am654-i2c", "ti,omap4-i2c" for AM654 SoCs
-	"ti,j721e-i2c", "ti,omap4-i2c" for J721E SoCs
-	"ti,am64-i2c", "ti,omap4-i2c" for AM64 SoCs
-- ti,hwmods : Must be "i2c<n>", n being the instance number (1-based)
-- #address-cells = <1>;
-- #size-cells = <0>;
-
-Recommended properties :
-- clock-frequency : Desired I2C bus clock frequency in Hz. Otherwise
-  the default 100 kHz frequency will be used.
-
-Optional properties:
-- Child nodes conforming to i2c bus binding
-
-Note: Current implementation will fetch base address, irq and dma
-from omap hwmod data base during device registration.
-Future plan is to migrate hwmod data base contents into device tree
-blob so that, all the required data will be used from device tree dts
-file.
-
-Examples :
-
-i2c1: i2c@0 {
-    compatible = "ti,omap3-i2c";
-    #address-cells = <1>;
-    #size-cells = <0>;
-    ti,hwmods = "i2c1";
-    clock-frequency = <400000>;
-};

diff --git a/Documentation/devicetree/bindings/i2c/ti,omap4-i2c.yaml b/Documentation/devicetree/bindings/i2c/ti,omap4-i2c.yaml
new file mode 100644
index 000000000000..eb11e3025b37
--- /dev/null
+++ b/Documentation/devicetree/bindings/i2c/ti,omap4-i2c.yaml

@@ -0,0 +1,80 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/i2c/ti,omap4-i2c.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Bindings for I2C controllers on TI's OMAP and K3 SoCs
+
+maintainers:
+  - Vignesh Raghavendra <vigneshr@ti.com>
+
+allOf:
+  - $ref: /schemas/i2c/i2c-controller.yaml#
+
+properties:
+  compatible:
+    oneOf:
+      - const: ti,omap2420-i2c
+      - const: ti,omap2430-i2c
+      - const: ti,omap3-i2c
+      - const: ti,omap4-i2c
+      - items:
+          - enum:
+              - ti,am4372-i2c
+              - ti,am64-i2c
+              - ti,am654-i2c
+              - ti,j721e-i2c
+          - const: ti,omap4-i2c
+
+  ti,hwmods:
+    description:
+      (DEPRECATED) Must be "i2c<n>", n being the instance number (1-based).
+      This property is applicable only on legacy platforms mainly omap2/3
+      and ti81xx and should not be used on other platforms.
+    $ref: /schemas/types.yaml#/definitions/string
+    items:
+      - pattern: "^i2c([1-9])$"
+
+  dmas:
+    minItems: 1
+    maxItems: 2
+
+  dma-names:
+    items:
+      - const: tx
+      - const: rx
+
+  reg:
+    maxItems: 1
+
+  interrupts:
+    maxItems: 1
+
+  clocks:
+    maxItems: 1
+
+  clock-names:
+    const: fck
+
+  clock-frequency: true
+
+required:
+  - compatible
+  - reg
+  - interrupts
+
+unevaluatedProperties: false
+
+examples:
+  - |
+    #include <dt-bindings/interrupt-controller/irq.h>
+    #include <dt-bindings/interrupt-controller/arm-gic.h>
+
+    main_i2c0: i2c@2000000 {
+            compatible = "ti,j721e-i2c", "ti,omap4-i2c";
+            reg = <0x2000000 0x100>;
+            interrupts = <GIC_SPI 200 IRQ_TYPE_LEVEL_HIGH>;
+            #address-cells = <1>;
+            #size-cells = <0>;
+         };

-- 
2.31.1

On 19:30-20210506, Vignesh Raghavendra wrote:

Convert i2c-omap.txt to YAML schema for better checks and documentation.

Following properties were used in DT but were not documented in txt
bindings and has been included in YAML schema:
1. Include ti,am4372-i2c compatible
2. Include dmas property used in few OMAP dts files
3. Document clocks property

Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
---
v2:
Fix issues with make dt_bindings_check
Add description on usage of ti,hwmods

please add a link to V1 to be nice to folks like me coming in for a
review at the point on v2 patch ;)


https://lore.kernel.org/linux-arm-kernel/?q=i2c-omap was'nt too helpful
either :(

https://lore.kernel.org/linux-devicetree/YJJGsGXBz56Nhe8z@atomide.com/
Can we control it with if?

+
+  dmas:
+    minItems: 1
+    maxItems: 2
+
+  dma-names:
+    items:
+      - const: tx
+      - const: rx
+
+  reg:
+    maxItems: 1
+
+  interrupts:
+    maxItems: 1
+
+  clocks:
+    maxItems: 1
+
+  clock-names:
+    const: fck
+
+  clock-frequency: true
+
+required:
+  - compatible
+  - reg
+  - interrupts
+
+unevaluatedProperties: false

I wonder if we should go with additionalProperties: false instead of
unevaluatedProperties..

For example:

+
+examples:
+  - |
+    #include <dt-bindings/interrupt-controller/irq.h>
+    #include <dt-bindings/interrupt-controller/arm-gic.h>
+
+    main_i2c0: i2c@2000000 {
+            compatible = "ti,j721e-i2c", "ti,omap4-i2c";
+            reg = <0x2000000 0x100>;
+            interrupts = <GIC_SPI 200 IRQ_TYPE_LEVEL_HIGH>;

If I add a ridiculous property system-controller; -> no problems what so
	ever..

+            #address-cells = <1>;
+            #size-cells = <0>;
+         };
-- 
2.31.1

-- 
Regards,
Nishanth Menon
Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3  1A34 DDB5 849D 1736 249D

On 06/05/2021 17:00, Vignesh Raghavendra wrote:

Convert i2c-omap.txt to YAML schema for better checks and documentation.

Following properties were used in DT but were not documented in txt
bindings and has been included in YAML schema:
1. Include ti,am4372-i2c compatible
2. Include dmas property used in few OMAP dts files

The DMA is not supported by i2c-omap driver, so wouldn't be better to just drop dmas from DTBs to avoid confusions?
It can be added later.

-- 
Best regards,
grygorii

On 5/7/21 12:24 PM, Grygorii Strashko wrote:

On 06/05/2021 17:00, Vignesh Raghavendra wrote:

quoted

Convert i2c-omap.txt to YAML schema for better checks and documentation.

Following properties were used in DT but were not documented in txt
bindings and has been included in YAML schema:
1. Include ti,am4372-i2c compatible
2. Include dmas property used in few OMAP dts files

The DMA is not supported by i2c-omap driver, so wouldn't be better to
just drop dmas from DTBs to avoid confusions?
It can be added later.

Will do.. I will also send patches dropping dmas from dts that currently
have them populated.

Regards
Vignesh

On Fri, 7 May 2021 19:45:45 +0530
Vignesh Raghavendra [off-list ref] wrote:

On 5/7/21 12:24 PM, Grygorii Strashko wrote:

quoted

On 06/05/2021 17:00, Vignesh Raghavendra wrote:  

quoted

Convert i2c-omap.txt to YAML schema for better checks and documentation.

Following properties were used in DT but were not documented in txt
bindings and has been included in YAML schema:
1. Include ti,am4372-i2c compatible
2. Include dmas property used in few OMAP dts files  

The DMA is not supported by i2c-omap driver, so wouldn't be better to
just drop dmas from DTBs to avoid confusions?
It can be added later.
  

Will do.. I will also send patches dropping dmas from dts that currently
have them populated.

hmm, we have
- DO attempt to make bindings complete even if a driver doesn't support some
  features. For example, if a device has an interrupt, then include the
  'interrupts' property even if the driver is only polled mode.

in Documentation/devicetree/bindings/writing-bindings.rst
Shouln't the dma stay there if the hardware supports it? Devicetree
should describe the hardware not the driver if I understood things
right.

Regards,
Andreas

On 07/05/2021 17:36, Andreas Kemnade wrote:

On Fri, 7 May 2021 19:45:45 +0530
Vignesh Raghavendra [off-list ref] wrote:

quoted

On 5/7/21 12:24 PM, Grygorii Strashko wrote:

quoted

On 06/05/2021 17:00, Vignesh Raghavendra wrote:

quoted

Convert i2c-omap.txt to YAML schema for better checks and documentation.

Following properties were used in DT but were not documented in txt
bindings and has been included in YAML schema:
1. Include ti,am4372-i2c compatible
2. Include dmas property used in few OMAP dts files

The DMA is not supported by i2c-omap driver, so wouldn't be better to
just drop dmas from DTBs to avoid confusions?
It can be added later.
   

Will do.. I will also send patches dropping dmas from dts that currently
have them populated.

hmm, we have
- DO attempt to make bindings complete even if a driver doesn't support some
   features. For example, if a device has an interrupt, then include the
   'interrupts' property even if the driver is only polled mode.

in Documentation/devicetree/bindings/writing-bindings.rst
Shouln't the dma stay there if the hardware supports it? Devicetree
should describe the hardware not the driver if I understood things
right.

True.  But my above statement is also valid - it introduces confusion from user point of view.
More over, 'dmas' is not part of original binding and were randomly added to some SoCs.
And it's much more easy to extend binding (in the future) then remove something after.

I leave it to Vignesh, Tony to decide.

-- 
Best regards,
grygorii

On Fri, May 07, 2021 at 08:24:59PM +0300, Grygorii Strashko wrote:

On 07/05/2021 17:36, Andreas Kemnade wrote:

quoted

On Fri, 7 May 2021 19:45:45 +0530
Vignesh Raghavendra [off-list ref] wrote:

quoted

On 5/7/21 12:24 PM, Grygorii Strashko wrote:

quoted

On 06/05/2021 17:00, Vignesh Raghavendra wrote:

quoted

Convert i2c-omap.txt to YAML schema for better checks and documentation.

Following properties were used in DT but were not documented in txt
bindings and has been included in YAML schema:
1. Include ti,am4372-i2c compatible
2. Include dmas property used in few OMAP dts files

The DMA is not supported by i2c-omap driver, so wouldn't be better to
just drop dmas from DTBs to avoid confusions?
It can be added later.

Will do.. I will also send patches dropping dmas from dts that currently
have them populated.

hmm, we have
- DO attempt to make bindings complete even if a driver doesn't support some
   features. For example, if a device has an interrupt, then include the
   'interrupts' property even if the driver is only polled mode.

in Documentation/devicetree/bindings/writing-bindings.rst
Shouln't the dma stay there if the hardware supports it? Devicetree
should describe the hardware not the driver if I understood things
right.

True.  But my above statement is also valid - it introduces confusion from user point of view.

In my OS, 'robOS', the driver supports DMA.

More over, 'dmas' is not part of original binding and were randomly added to some SoCs.
And it's much more easy to extend binding (in the future) then remove something after.

In this case, probably given that how it would be extended is already 
known, but it depends how you extend a binding. My above statement was 
born out of incomplete MFD and system controller bindings for the most 
part.

I leave it to Vignesh, Tony to decide.

Fine with me.

Actually, for DMA with I2C I'd like to see someone show a usecase 
and data where it's actually beneficial. 

Rob

Actually, for DMA with I2C I'd like to see someone show a usecase 
and data where it's actually beneficial. 

The usecase I mostly hear is transferring firmware from/to the i2c
client. Something up to 1MB sent in 64KB chunks. Haven't had this myself
on the desk, though.

Hi Tony,

On 5/7/21 10:54 PM, Grygorii Strashko wrote:

On 07/05/2021 17:36, Andreas Kemnade wrote:

quoted

On Fri, 7 May 2021 19:45:45 +0530
Vignesh Raghavendra [off-list ref] wrote:

quoted

On 5/7/21 12:24 PM, Grygorii Strashko wrote:

quoted

On 06/05/2021 17:00, Vignesh Raghavendra wrote:

quoted

Convert i2c-omap.txt to YAML schema for better checks and
documentation.

Following properties were used in DT but were not documented in txt
bindings and has been included in YAML schema:
1. Include ti,am4372-i2c compatible
2. Include dmas property used in few OMAP dts files

The DMA is not supported by i2c-omap driver, so wouldn't be better to
just drop dmas from DTBs to avoid confusions?
It can be added later.
   

Will do.. I will also send patches dropping dmas from dts that currently
have them populated.

hmm, we have
- DO attempt to make bindings complete even if a driver doesn't
support some
   features. For example, if a device has an interrupt, then include the
   'interrupts' property even if the driver is only polled mode.

in Documentation/devicetree/bindings/writing-bindings.rst
Shouln't the dma stay there if the hardware supports it? Devicetree
should describe the hardware not the driver if I understood things
right.

True.  But my above statement is also valid - it introduces confusion
from user point of view.
More over, 'dmas' is not part of original binding and were randomly
added to some SoCs.
And it's much more easy to extend binding (in the future) then remove
something after.

I leave it to Vignesh, Tony to decide.

What do you prefer here? Removing dmas from schema would mean I would
have to delete dmas property from omap2/3 dtsi files that list dmas
property today? Note that driver does not support DMA mode today.


Regards
Vignesh

* Vignesh Raghavendra [off-list ref] [210510 11:06]:

What do you prefer here? Removing dmas from schema would mean I would
have to delete dmas property from omap2/3 dtsi files that list dmas
property today? Note that driver does not support DMA mode today.

If the dma channels are not used by the driver, and not in the binding,
it's unlikely they will ever get used. Sure the dma channels describe
the hardware, and there's a slim chance some other OS needs them, but I
doubt it.

It seems weird we stop describing hardware in the devicetree to avoid
binding check warnings though. Up to you to figure out what you want
to do as far as I'm concerned.

Regards,

Tony

On Thu, May 06, 2021 at 07:30:26PM +0530, Vignesh Raghavendra wrote:

Convert i2c-omap.txt to YAML schema for better checks and documentation.

Following properties were used in DT but were not documented in txt
bindings and has been included in YAML schema:
1. Include ti,am4372-i2c compatible
2. Include dmas property used in few OMAP dts files
3. Document clocks property

Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
---
v2:
Fix issues with make dt_bindings_check
Add description on usage of ti,hwmods

 .../devicetree/bindings/i2c/i2c-omap.txt      | 37 ---------
 .../devicetree/bindings/i2c/ti,omap4-i2c.yaml | 80 +++++++++++++++++++
 2 files changed, 80 insertions(+), 37 deletions(-)
 delete mode 100644 Documentation/devicetree/bindings/i2c/i2c-omap.txt
 create mode 100644 Documentation/devicetree/bindings/i2c/ti,omap4-i2c.yaml

These 4 can be a single 'enum'.

+      - items:
+          - enum:
+              - ti,am4372-i2c
+              - ti,am64-i2c
+              - ti,am654-i2c
+              - ti,j721e-i2c
+          - const: ti,omap4-i2c
+
+  ti,hwmods:
+    description:
+      (DEPRECATED) Must be "i2c<n>", n being the instance number (1-based).

There's a keyword to mark things deprecated. It's 'deprecated'.

+      This property is applicable only on legacy platforms mainly omap2/3
+      and ti81xx and should not be used on other platforms.
+    $ref: /schemas/types.yaml#/definitions/string
+    items:
+      - pattern: "^i2c([1-9])$"
+
+  dmas:
+    minItems: 1
+    maxItems: 2
+
+  dma-names:
+    items:
+      - const: tx
+      - const: rx
+
+  reg:
+    maxItems: 1
+
+  interrupts:
+    maxItems: 1
+
+  clocks:
+    maxItems: 1
+
+  clock-names:
+    const: fck
+
+  clock-frequency: true
+
+required:
+  - compatible
+  - reg
+  - interrupts
+
+unevaluatedProperties: false
+
+examples:
+  - |
+    #include <dt-bindings/interrupt-controller/irq.h>
+    #include <dt-bindings/interrupt-controller/arm-gic.h>
+
+    main_i2c0: i2c@2000000 {
+            compatible = "ti,j721e-i2c", "ti,omap4-i2c";
+            reg = <0x2000000 0x100>;
+            interrupts = <GIC_SPI 200 IRQ_TYPE_LEVEL_HIGH>;
+            #address-cells = <1>;
+            #size-cells = <0>;
+         };
-- 
2.31.1