diff mbox series

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

Message ID 20210506140026.31254-1-vigneshr@ti.com (mailing list archive)
State New, archived
Headers show
Series [v2] dt-bindings: i2c: Move i2c-omap.txt to YAML format | expand

Commit Message

Vignesh Raghavendra May 6, 2021, 2 p.m. UTC
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

Comments

Nishanth Menon May 6, 2021, 6:55 p.m. UTC | #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 :(
>  .../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])$"

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
>
Grygorii Strashko May 7, 2021, 6:54 a.m. UTC | #2
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.

> 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>;
> +         };
>
Vignesh Raghavendra May 7, 2021, 2:15 p.m. UTC | #3
On 5/7/21 12:24 PM, Grygorii Strashko wrote:
> 
> 
> 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.
> 

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

Regards
Vignesh
Andreas Kemnade May 7, 2021, 2:36 p.m. UTC | #4
On Fri, 7 May 2021 19:45:45 +0530
Vignesh Raghavendra <vigneshr@ti.com> wrote:

> On 5/7/21 12:24 PM, Grygorii Strashko wrote:
> > 
> > 
> > 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.
> >   
> 
> 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
Grygorii Strashko May 7, 2021, 5:24 p.m. UTC | #5
On 07/05/2021 17:36, Andreas Kemnade wrote:
> On Fri, 7 May 2021 19:45:45 +0530
> Vignesh Raghavendra <vigneshr@ti.com> wrote:
> 
>> On 5/7/21 12:24 PM, Grygorii Strashko wrote:
>>>
>>>
>>> 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.
>>>    
>>
>> 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.
Rob Herring (Arm) May 7, 2021, 9:19 p.m. UTC | #6
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


> 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

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
>
Rob Herring (Arm) May 7, 2021, 9:43 p.m. UTC | #7
On Fri, May 07, 2021 at 08:24:59PM +0300, Grygorii Strashko wrote:
> 
> 
> On 07/05/2021 17:36, Andreas Kemnade wrote:
> > On Fri, 7 May 2021 19:45:45 +0530
> > Vignesh Raghavendra <vigneshr@ti.com> wrote:
> > 
> > > On 5/7/21 12:24 PM, Grygorii Strashko wrote:
> > > > 
> > > > 
> > > > 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.
> > > 
> > > 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
Wolfram Sang May 7, 2021, 10:02 p.m. UTC | #8
> 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.
Vignesh Raghavendra May 10, 2021, 11:06 a.m. UTC | #9
Hi Tony,

On 5/7/21 10:54 PM, Grygorii Strashko wrote:
> 
> 
> On 07/05/2021 17:36, Andreas Kemnade wrote:
>> On Fri, 7 May 2021 19:45:45 +0530
>> Vignesh Raghavendra <vigneshr@ti.com> wrote:
>>
>>> On 5/7/21 12:24 PM, Grygorii Strashko wrote:
>>>>
>>>>
>>>> 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.
>>>>    
>>>
>>> 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
Tony Lindgren May 26, 2021, 6:52 a.m. UTC | #10
* Vignesh Raghavendra <vigneshr@ti.com> [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
diff mbox series

Patch

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>;
+         };