diff mbox series

[v2,1/4] dt-bindings: media: csi2dc: add bindings for microchip csi2dc

Message ID 20200703074416.55272-2-eugen.hristev@microchip.com
State Changes Requested, archived
Headers show
Series media: introduce microchip csi2dc driver | expand

Checks

Context Check Description
robh/checkpatch warning total: 0 errors, 1 warnings, 185 lines checked
robh/dt-meta-schema success

Commit Message

Eugen Hristev July 3, 2020, 7:44 a.m. UTC
Add bindings documentation for microchip CSI2 Demultiplexer controller.

CSI2DC is a demultiplexer from Synopsys IDI interface specification to
parallel interface connection or direct memory access.

Signed-off-by: Eugen Hristev <eugen.hristev@microchip.com>
---
Changes in v2:
- fixed warnings reported by dt_binding_check


 .../bindings/media/microchip,csi2dc.yaml      | 185 ++++++++++++++++++
 1 file changed, 185 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/media/microchip,csi2dc.yaml

Comments

Rob Herring (Arm) July 14, 2020, 2:55 a.m. UTC | #1
On Fri, Jul 03, 2020 at 10:44:13AM +0300, Eugen Hristev wrote:
> Add bindings documentation for microchip CSI2 Demultiplexer controller.
> 
> CSI2DC is a demultiplexer from Synopsys IDI interface specification to
> parallel interface connection or direct memory access.
> 
> Signed-off-by: Eugen Hristev <eugen.hristev@microchip.com>
> ---
> Changes in v2:
> - fixed warnings reported by dt_binding_check
> 
> 
>  .../bindings/media/microchip,csi2dc.yaml      | 185 ++++++++++++++++++
>  1 file changed, 185 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/media/microchip,csi2dc.yaml
> 
> diff --git a/Documentation/devicetree/bindings/media/microchip,csi2dc.yaml b/Documentation/devicetree/bindings/media/microchip,csi2dc.yaml
> new file mode 100644
> index 000000000000..b7c46f7ad2a4
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/media/microchip,csi2dc.yaml
> @@ -0,0 +1,185 @@
> +# SPDX-License-Identifier: GPL-2.0-only

New bindings should be:

(GPL-2.0-only OR BSD-2-Clause)

> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/media/microchip,csi2dc.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Microchip CSI2 Demux Controller (CSI2DC)
> +
> +maintainers:
> +  - Eugen Hristev <eugen.hristev@microchip.com>
> +
> +description:
> +  CSI2DC - Camera Serial Interface 2 Demux Controller
> +
> +  CSI2DC is a hardware block that receives incoming data from an IDI interface
> +  and filters packets based on their data type and virtual channel identifier,
> +  then converts the byte stream into a cross clock domain to a pixel stream
> +  to a parallel interface that can be read by a sensor controller.
> +
> +  CSI2DC provides two pipes, one video pipe and one data pipe. Video pipe
> +  is connected to a sensor controller and the data pipe is accessible
> +  as a DMA slave port to a DMA controller.
> +
> +  CSI2DC supports a single 'port' node as a source pad with Synopsys 32-bit
> +  IDI interface. The connected endpoint must be a IDI interface compatible
> +  device (like Synopsys CSI2HOST) , that can provide 32-bit IDI interface
> +  connection as sink pad.
> +  It should contain one 'port' child node with one child 'endpoint' node.
> +  This node should always have the 'reg' property as 0, being the first child
> +  node.

This information should be expressed as a schema.

> +  For media entity and endpoints please refer to the bindings defined in
> +  Documentation/devicetree/bindings/media/video-interfaces.txt.
> +  For Synopsys IDI interface please refer to
> +  Documentation/devicetree/bindings/media/snps,dw-csi-plat.txt
> +

> +  CSI2DC supports one 'port' node as sink pad with parallel interface. This is
> +  called video pipe.
> +  The reg property inside this 'port' node must have the 'reg' property as 1,
> +  being the second child node.
> +  This node must have one 'endpoint', and this 'endpoint' is related to the
> +  virtual channel identifier.
> +  The 'reg' property inside this 'endpoint' represents the CSI2 virtual channel
> +  identifier.
> +  This 'endpoint' can then be used as a source pad for another controller
> +  (next in pipeline).
> +  Please refer to the bindings defined in
> +  Documentation/devicetree/bindings/media/video-interfaces.txt.

And all this.

> +
> +  CSI2DC must have two clocks to function correctly. One clock is the
> +  peripheral clock for the inside functionality of the hardware block.
> +  This is named 'pclk'. The second clock must be the cross domain clock,
> +  in which CSI2DC will perform clock crossing. This clock must be fed
> +  by the next controller in pipeline, which usually is a sensor controller.
> +  Normally this clock should be given by this sensor controller who
> +  is also a clock source. This clock is named 'scck', sensor controller clock.

Better to be part of 'clocks'.

> +
> +  CSI2DC also supports direct access to the data through AHB, via DMA channel,
> +  called data pipe.
> +  Because of this, the sink 'port' child node (second) is not mandatory.
> +  If the sink 'port' child node is missing, only data pipe is available.
> +
> +properties:
> +  compatible:
> +    const: microchip,sama7g5-csi2dc
> +
> +  reg:
> +    description:
> +      Physical base address and length of the registers set for the device.

That is every 'reg' prop. Drop.

> +    maxItems: 1
> +
> +  clocks:
> +    maxItems: 2
> +
> +  clock-names:
> +    items:
> +      - const: pclk
> +      - const: scck
> +
> +  microchip,clk-gated:
> +    type: boolean
> +    description:
> +      If present, indicates that the clock is gated.
> +      Otherwise, the clock is free-running.
> +
> +  microchip,inter-line-delay:
> +    allOf:
> +    - $ref: /schemas/types.yaml#/definitions/uint32
> +    - minimum: 1
> +    - maximum: 16
> +    default: 16
> +    description:
> +      Indicates how many clock cycles should be introduced between each line.
> +
> +  port@0:
> +    type: object
> +    description:
> +      Input port node, single endpoint describing the input pad.
> +
> +    properties:
> +      reg:
> +        const: 0
> +
> +      endpoint:
> +        type: object
> +
> +        properties:
> +          remote-endpoint: true
> +
> +        required:
> +          - remote-endpoint
> +
> +        additionalProperties: false
> +
> +    additionalProperties: false
> +
> +  port@1:
> +    type: object
> +    description:
> +      Output port node, single endpoint, describing the output pad.
> +
> +    properties:
> +      '#address-cells':
> +        const: 1
> +
> +      '#size-cells':
> +        const: 0
> +
> +      reg:
> +        const: 1
> +
> +    patternProperties:
> +      "^endpoint@[0-9a-f]$":

Looks like only [0-3] is valid.

> +        type: object
> +
> +        properties:
> +          reg:
> +            enum: [0, 1, 2, 3]
> +            description: virtual channel for the endpoint
> +
> +          remote-endpoint: true
> +
> +        required:
> +          - remote-endpoint
> +          - reg
> +
> +        additionalProperties: false
> +
> +    additionalProperties: false
> +
> +required:
> +  - compatible
> +  - reg
> +  - clocks
> +  - clock-names
> +  - port@0
> +
> +examples:
> +  - |
> +    csi2dc@e1404000 {
> +        compatible = "microchip,sama7g5-csi2dc";
> +        #address-cells = <1>;
> +        #size-cells = <0>;
> +        reg = <0xe1404000 0x500>;
> +        clocks = <&pclk>, <&scck>;
> +        clock-names = "pclk", "scck";
> +
> +        port@0 {
> +               reg = <0>; /* must be 0, first child port */
> +               csi2dc_in: endpoint { /* input from IDI interface */
> +                     remote-endpoint = <&csi2host_out>;
> +               };
> +        };
> +
> +        port@1 {
> +                #address-cells = <1>;
> +                #size-cells = <0>;
> +                reg = <1>; /* must be 1, second child port */
> +                csi2dc_out: endpoint@2 {
> +                        reg = <2>;  /* virtual channel identifier */
> +                        remote-endpoint = <&xisc_in>; /* output to sensor controller */
> +                };
> +        };
> +    };
> +
> +...
> -- 
> 2.25.1
>
Sakari Ailus Aug. 13, 2020, 10:46 p.m. UTC | #2
Hi Eugen,

On Fri, Jul 03, 2020 at 10:44:13AM +0300, Eugen Hristev wrote:
> Add bindings documentation for microchip CSI2 Demultiplexer controller.

...

> +  port@1:
> +    type: object
> +    description:
> +      Output port node, single endpoint, describing the output pad.
> +
> +    properties:
> +      '#address-cells':
> +        const: 1
> +
> +      '#size-cells':
> +        const: 0
> +
> +      reg:
> +        const: 1
> +
> +    patternProperties:
> +      "^endpoint@[0-9a-f]$":
> +        type: object
> +
> +        properties:
> +          reg:
> +            enum: [0, 1, 2, 3]
> +            description: virtual channel for the endpoint

Unless you need this right now I'd just hard code this to zero in the
driver. You can't have more endpoints for active devices anyway, can you?
Eugen Hristev Aug. 19, 2020, 12:45 p.m. UTC | #3
On 14.08.2020 01:46, Sakari Ailus wrote:
> Hi Eugen,
> 
> On Fri, Jul 03, 2020 at 10:44:13AM +0300, Eugen Hristev wrote:
>> Add bindings documentation for microchip CSI2 Demultiplexer controller.
> 
> ...
> 
>> +  port@1:
>> +    type: object
>> +    description:
>> +      Output port node, single endpoint, describing the output pad.
>> +
>> +    properties:
>> +      '#address-cells':
>> +        const: 1
>> +
>> +      '#size-cells':
>> +        const: 0
>> +
>> +      reg:
>> +        const: 1
>> +
>> +    patternProperties:
>> +      "^endpoint@[0-9a-f]$":
>> +        type: object
>> +
>> +        properties:
>> +          reg:
>> +            enum: [0, 1, 2, 3]
>> +            description: virtual channel for the endpoint
> 
> Unless you need this right now I'd just hard code this to zero in the
> driver. You can't have more endpoints for active devices anyway, can you?

Hello Sakari,

You are right, but, the virtual ID must be written in hardware 
registers. So I can take the virtual ID from this property.
Otherwise, if I hardcode this in the driver, another virtual ID would be 
impossible to use without changing the driver. And if the binding is 
accepted without this property, it will be 'set in stone' and difficult 
to change afterwards.

What do you think ?

Eugen
> 
> --
> Sakari Ailus
>
Eugen Hristev Aug. 19, 2020, 12:47 p.m. UTC | #4
On 14.07.2020 05:55, Rob Herring wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
> 
> On Fri, Jul 03, 2020 at 10:44:13AM +0300, Eugen Hristev wrote:
>> Add bindings documentation for microchip CSI2 Demultiplexer controller.
>>
>> CSI2DC is a demultiplexer from Synopsys IDI interface specification to
>> parallel interface connection or direct memory access.
>>
>> Signed-off-by: Eugen Hristev <eugen.hristev@microchip.com>
>> ---
>> Changes in v2:
>> - fixed warnings reported by dt_binding_check
>>
>>
>>   .../bindings/media/microchip,csi2dc.yaml      | 185 ++++++++++++++++++
>>   1 file changed, 185 insertions(+)
>>   create mode 100644 Documentation/devicetree/bindings/media/microchip,csi2dc.yaml
>>
>> diff --git a/Documentation/devicetree/bindings/media/microchip,csi2dc.yaml b/Documentation/devicetree/bindings/media/microchip,csi2dc.yaml
>> new file mode 100644
>> index 000000000000..b7c46f7ad2a4
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/media/microchip,csi2dc.yaml
>> @@ -0,0 +1,185 @@
>> +# SPDX-License-Identifier: GPL-2.0-only
> 
> New bindings should be:
> 
> (GPL-2.0-only OR BSD-2-Clause)
> 
>> +%YAML 1.2
>> +---
>> +$id: http://devicetree.org/schemas/media/microchip,csi2dc.yaml#
>> +$schema: http://devicetree.org/meta-schemas/core.yaml#
>> +
>> +title: Microchip CSI2 Demux Controller (CSI2DC)
>> +
>> +maintainers:
>> +  - Eugen Hristev <eugen.hristev@microchip.com>
>> +
>> +description:
>> +  CSI2DC - Camera Serial Interface 2 Demux Controller
>> +
>> +  CSI2DC is a hardware block that receives incoming data from an IDI interface
>> +  and filters packets based on their data type and virtual channel identifier,
>> +  then converts the byte stream into a cross clock domain to a pixel stream
>> +  to a parallel interface that can be read by a sensor controller.
>> +
>> +  CSI2DC provides two pipes, one video pipe and one data pipe. Video pipe
>> +  is connected to a sensor controller and the data pipe is accessible
>> +  as a DMA slave port to a DMA controller.
>> +
>> +  CSI2DC supports a single 'port' node as a source pad with Synopsys 32-bit
>> +  IDI interface. The connected endpoint must be a IDI interface compatible
>> +  device (like Synopsys CSI2HOST) , that can provide 32-bit IDI interface
>> +  connection as sink pad.
>> +  It should contain one 'port' child node with one child 'endpoint' node.
>> +  This node should always have the 'reg' property as 0, being the first child
>> +  node.
> 
> This information should be expressed as a schema.

Hello Rob,

Do you mean that I should add these explanations inside the schema 
properties description ?
Or I should enforce these in some other way ? The schema already 
includes what is written here (for example, const reg 0 for the child 
node, etc.)
Or maybe you wanted to tell me something else ?

Thanks,
Eugen

> 
>> +  For media entity and endpoints please refer to the bindings defined in
>> +  Documentation/devicetree/bindings/media/video-interfaces.txt.
>> +  For Synopsys IDI interface please refer to
>> +  Documentation/devicetree/bindings/media/snps,dw-csi-plat.txt
>> +
> 
>> +  CSI2DC supports one 'port' node as sink pad with parallel interface. This is
>> +  called video pipe.
>> +  The reg property inside this 'port' node must have the 'reg' property as 1,
>> +  being the second child node.
>> +  This node must have one 'endpoint', and this 'endpoint' is related to the
>> +  virtual channel identifier.
>> +  The 'reg' property inside this 'endpoint' represents the CSI2 virtual channel
>> +  identifier.
>> +  This 'endpoint' can then be used as a source pad for another controller
>> +  (next in pipeline).
>> +  Please refer to the bindings defined in
>> +  Documentation/devicetree/bindings/media/video-interfaces.txt.
> 
> And all this.
> 
>> +
>> +  CSI2DC must have two clocks to function correctly. One clock is the
>> +  peripheral clock for the inside functionality of the hardware block.
>> +  This is named 'pclk'. The second clock must be the cross domain clock,
>> +  in which CSI2DC will perform clock crossing. This clock must be fed
>> +  by the next controller in pipeline, which usually is a sensor controller.
>> +  Normally this clock should be given by this sensor controller who
>> +  is also a clock source. This clock is named 'scck', sensor controller clock.
> 
> Better to be part of 'clocks'.
> 
>> +
>> +  CSI2DC also supports direct access to the data through AHB, via DMA channel,
>> +  called data pipe.
>> +  Because of this, the sink 'port' child node (second) is not mandatory.
>> +  If the sink 'port' child node is missing, only data pipe is available.
>> +
>> +properties:
>> +  compatible:
>> +    const: microchip,sama7g5-csi2dc
>> +
>> +  reg:
>> +    description:
>> +      Physical base address and length of the registers set for the device.
> 
> That is every 'reg' prop. Drop.
> 
>> +    maxItems: 1
>> +
>> +  clocks:
>> +    maxItems: 2
>> +
>> +  clock-names:
>> +    items:
>> +      - const: pclk
>> +      - const: scck
>> +
>> +  microchip,clk-gated:
>> +    type: boolean
>> +    description:
>> +      If present, indicates that the clock is gated.
>> +      Otherwise, the clock is free-running.
>> +
>> +  microchip,inter-line-delay:
>> +    allOf:
>> +    - $ref: /schemas/types.yaml#/definitions/uint32
>> +    - minimum: 1
>> +    - maximum: 16
>> +    default: 16
>> +    description:
>> +      Indicates how many clock cycles should be introduced between each line.
>> +
>> +  port@0:
>> +    type: object
>> +    description:
>> +      Input port node, single endpoint describing the input pad.
>> +
>> +    properties:
>> +      reg:
>> +        const: 0
>> +
>> +      endpoint:
>> +        type: object
>> +
>> +        properties:
>> +          remote-endpoint: true
>> +
>> +        required:
>> +          - remote-endpoint
>> +
>> +        additionalProperties: false
>> +
>> +    additionalProperties: false
>> +
>> +  port@1:
>> +    type: object
>> +    description:
>> +      Output port node, single endpoint, describing the output pad.
>> +
>> +    properties:
>> +      '#address-cells':
>> +        const: 1
>> +
>> +      '#size-cells':
>> +        const: 0
>> +
>> +      reg:
>> +        const: 1
>> +
>> +    patternProperties:
>> +      "^endpoint@[0-9a-f]$":
> 
> Looks like only [0-3] is valid.
> 
>> +        type: object
>> +
>> +        properties:
>> +          reg:
>> +            enum: [0, 1, 2, 3]
>> +            description: virtual channel for the endpoint
>> +
>> +          remote-endpoint: true
>> +
>> +        required:
>> +          - remote-endpoint
>> +          - reg
>> +
>> +        additionalProperties: false
>> +
>> +    additionalProperties: false
>> +
>> +required:
>> +  - compatible
>> +  - reg
>> +  - clocks
>> +  - clock-names
>> +  - port@0
>> +
>> +examples:
>> +  - |
>> +    csi2dc@e1404000 {
>> +        compatible = "microchip,sama7g5-csi2dc";
>> +        #address-cells = <1>;
>> +        #size-cells = <0>;
>> +        reg = <0xe1404000 0x500>;
>> +        clocks = <&pclk>, <&scck>;
>> +        clock-names = "pclk", "scck";
>> +
>> +        port@0 {
>> +               reg = <0>; /* must be 0, first child port */
>> +               csi2dc_in: endpoint { /* input from IDI interface */
>> +                     remote-endpoint = <&csi2host_out>;
>> +               };
>> +        };
>> +
>> +        port@1 {
>> +                #address-cells = <1>;
>> +                #size-cells = <0>;
>> +                reg = <1>; /* must be 1, second child port */
>> +                csi2dc_out: endpoint@2 {
>> +                        reg = <2>;  /* virtual channel identifier */
>> +                        remote-endpoint = <&xisc_in>; /* output to sensor controller */
>> +                };
>> +        };
>> +    };
>> +
>> +...
>> --
>> 2.25.1
>>
Eugen Hristev Aug. 19, 2020, 12:59 p.m. UTC | #5
On 03.07.2020 10:44, Eugen Hristev wrote:
> Add bindings documentation for microchip CSI2 Demultiplexer controller.
> 
> CSI2DC is a demultiplexer from Synopsys IDI interface specification to
> parallel interface connection or direct memory access.
> 
> Signed-off-by: Eugen Hristev <eugen.hristev@microchip.com>
> ---
> Changes in v2:
> - fixed warnings reported by dt_binding_check
> 
> 
>   .../bindings/media/microchip,csi2dc.yaml      | 185 ++++++++++++++++++
>   1 file changed, 185 insertions(+)
>   create mode 100644 Documentation/devicetree/bindings/media/microchip,csi2dc.yaml
> 
> diff --git a/Documentation/devicetree/bindings/media/microchip,csi2dc.yaml b/Documentation/devicetree/bindings/media/microchip,csi2dc.yaml
> new file mode 100644
> index 000000000000..b7c46f7ad2a4
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/media/microchip,csi2dc.yaml
> @@ -0,0 +1,185 @@
> +# SPDX-License-Identifier: GPL-2.0-only
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/media/microchip,csi2dc.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Microchip CSI2 Demux Controller (CSI2DC)
> +
> +maintainers:
> +  - Eugen Hristev <eugen.hristev@microchip.com>
> +
> +description:
> +  CSI2DC - Camera Serial Interface 2 Demux Controller
> +
> +  CSI2DC is a hardware block that receives incoming data from an IDI interface
> +  and filters packets based on their data type and virtual channel identifier,
> +  then converts the byte stream into a cross clock domain to a pixel stream
> +  to a parallel interface that can be read by a sensor controller.
> +
> +  CSI2DC provides two pipes, one video pipe and one data pipe. Video pipe
> +  is connected to a sensor controller and the data pipe is accessible
> +  as a DMA slave port to a DMA controller.
> +
> +  CSI2DC supports a single 'port' node as a source pad with Synopsys 32-bit
> +  IDI interface. The connected endpoint must be a IDI interface compatible
> +  device (like Synopsys CSI2HOST) , that can provide 32-bit IDI interface
> +  connection as sink pad.

Hello Sakari,

Could you have a look at my binding, especially this paragraph above. 
This controller that we have requires the Synopsys IDI interface as 
source pad. As this interface is not yet in kernel, do you think it's 
fine to mention it here ? Or how should I proceed ?

In my tests and the example at the end of this binding, I just use the 
port and endpoints without any specific properties.
The CSI2DC will actually wait an async completion (with a notifier) for 
that device to be registered, and then use it as a subdevice. In turn, 
CSI2DC registers a subdev for the next port in pipeline, towards the 
upper level ( the image sensor controller)

However, the connection with the subdevice in this case will likely 
default to parallel, and not be at all in any of the cases in the 
video-interfaces.txt :
- bus-type: data bus type. Possible values are: 

   1 - MIPI CSI-2 C-PHY 

   2 - MIPI CSI1 

   3 - CCP2 

   4 - MIPI CSI-2 D-PHY 

   5 - Parallel 

   6 - Bt.656

as this interface type is actually Synopsys IDI.
Do you think this is fine ?

Thanks,
Eugen

> +  It should contain one 'port' child node with one child 'endpoint' node.
> +  This node should always have the 'reg' property as 0, being the first child
> +  node.
> +  For media entity and endpoints please refer to the bindings defined in
> +  Documentation/devicetree/bindings/media/video-interfaces.txt.
> +  For Synopsys IDI interface please refer to
> +  Documentation/devicetree/bindings/media/snps,dw-csi-plat.txt
> +
> +  CSI2DC supports one 'port' node as sink pad with parallel interface. This is
> +  called video pipe.
> +  The reg property inside this 'port' node must have the 'reg' property as 1,
> +  being the second child node.
> +  This node must have one 'endpoint', and this 'endpoint' is related to the
> +  virtual channel identifier.
> +  The 'reg' property inside this 'endpoint' represents the CSI2 virtual channel
> +  identifier.
> +  This 'endpoint' can then be used as a source pad for another controller
> +  (next in pipeline).
> +  Please refer to the bindings defined in
> +  Documentation/devicetree/bindings/media/video-interfaces.txt.
> +
> +  CSI2DC must have two clocks to function correctly. One clock is the
> +  peripheral clock for the inside functionality of the hardware block.
> +  This is named 'pclk'. The second clock must be the cross domain clock,
> +  in which CSI2DC will perform clock crossing. This clock must be fed
> +  by the next controller in pipeline, which usually is a sensor controller.
> +  Normally this clock should be given by this sensor controller who
> +  is also a clock source. This clock is named 'scck', sensor controller clock.
> +
> +  CSI2DC also supports direct access to the data through AHB, via DMA channel,
> +  called data pipe.
> +  Because of this, the sink 'port' child node (second) is not mandatory.
> +  If the sink 'port' child node is missing, only data pipe is available.
> +
> +properties:
> +  compatible:
> +    const: microchip,sama7g5-csi2dc
> +
> +  reg:
> +    description:
> +      Physical base address and length of the registers set for the device.
> +    maxItems: 1
> +
> +  clocks:
> +    maxItems: 2
> +
> +  clock-names:
> +    items:
> +      - const: pclk
> +      - const: scck
> +
> +  microchip,clk-gated:
> +    type: boolean
> +    description:
> +      If present, indicates that the clock is gated.
> +      Otherwise, the clock is free-running.
> +
> +  microchip,inter-line-delay:
> +    allOf:
> +    - $ref: /schemas/types.yaml#/definitions/uint32
> +    - minimum: 1
> +    - maximum: 16
> +    default: 16
> +    description:
> +      Indicates how many clock cycles should be introduced between each line.
> +
> +  port@0:
> +    type: object
> +    description:
> +      Input port node, single endpoint describing the input pad.
> +
> +    properties:
> +      reg:
> +        const: 0
> +
> +      endpoint:
> +        type: object
> +
> +        properties:
> +          remote-endpoint: true
> +
> +        required:
> +          - remote-endpoint
> +
> +        additionalProperties: false
> +
> +    additionalProperties: false
> +
> +  port@1:
> +    type: object
> +    description:
> +      Output port node, single endpoint, describing the output pad.
> +
> +    properties:
> +      '#address-cells':
> +        const: 1
> +
> +      '#size-cells':
> +        const: 0
> +
> +      reg:
> +        const: 1
> +
> +    patternProperties:
> +      "^endpoint@[0-9a-f]$":
> +        type: object
> +
> +        properties:
> +          reg:
> +            enum: [0, 1, 2, 3]
> +            description: virtual channel for the endpoint
> +
> +          remote-endpoint: true
> +
> +        required:
> +          - remote-endpoint
> +          - reg
> +
> +        additionalProperties: false
> +
> +    additionalProperties: false
> +
> +required:
> +  - compatible
> +  - reg
> +  - clocks
> +  - clock-names
> +  - port@0
> +
> +examples:
> +  - |
> +    csi2dc@e1404000 {
> +        compatible = "microchip,sama7g5-csi2dc";
> +        #address-cells = <1>;
> +        #size-cells = <0>;
> +        reg = <0xe1404000 0x500>;
> +        clocks = <&pclk>, <&scck>;
> +        clock-names = "pclk", "scck";
> +
> +        port@0 {
> +               reg = <0>; /* must be 0, first child port */
> +               csi2dc_in: endpoint { /* input from IDI interface */
> +                     remote-endpoint = <&csi2host_out>;
> +               };
> +        };
> +
> +        port@1 {
> +                #address-cells = <1>;
> +                #size-cells = <0>;
> +                reg = <1>; /* must be 1, second child port */
> +                csi2dc_out: endpoint@2 {
> +                        reg = <2>;  /* virtual channel identifier */
> +                        remote-endpoint = <&xisc_in>; /* output to sensor controller */
> +                };
> +        };
> +    };
> +
> +...
>
diff mbox series

Patch

diff --git a/Documentation/devicetree/bindings/media/microchip,csi2dc.yaml b/Documentation/devicetree/bindings/media/microchip,csi2dc.yaml
new file mode 100644
index 000000000000..b7c46f7ad2a4
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/microchip,csi2dc.yaml
@@ -0,0 +1,185 @@ 
+# SPDX-License-Identifier: GPL-2.0-only
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/media/microchip,csi2dc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Microchip CSI2 Demux Controller (CSI2DC)
+
+maintainers:
+  - Eugen Hristev <eugen.hristev@microchip.com>
+
+description:
+  CSI2DC - Camera Serial Interface 2 Demux Controller
+
+  CSI2DC is a hardware block that receives incoming data from an IDI interface
+  and filters packets based on their data type and virtual channel identifier,
+  then converts the byte stream into a cross clock domain to a pixel stream
+  to a parallel interface that can be read by a sensor controller.
+
+  CSI2DC provides two pipes, one video pipe and one data pipe. Video pipe
+  is connected to a sensor controller and the data pipe is accessible
+  as a DMA slave port to a DMA controller.
+
+  CSI2DC supports a single 'port' node as a source pad with Synopsys 32-bit
+  IDI interface. The connected endpoint must be a IDI interface compatible
+  device (like Synopsys CSI2HOST) , that can provide 32-bit IDI interface
+  connection as sink pad.
+  It should contain one 'port' child node with one child 'endpoint' node.
+  This node should always have the 'reg' property as 0, being the first child
+  node.
+  For media entity and endpoints please refer to the bindings defined in
+  Documentation/devicetree/bindings/media/video-interfaces.txt.
+  For Synopsys IDI interface please refer to
+  Documentation/devicetree/bindings/media/snps,dw-csi-plat.txt
+
+  CSI2DC supports one 'port' node as sink pad with parallel interface. This is
+  called video pipe.
+  The reg property inside this 'port' node must have the 'reg' property as 1,
+  being the second child node.
+  This node must have one 'endpoint', and this 'endpoint' is related to the
+  virtual channel identifier.
+  The 'reg' property inside this 'endpoint' represents the CSI2 virtual channel
+  identifier.
+  This 'endpoint' can then be used as a source pad for another controller
+  (next in pipeline).
+  Please refer to the bindings defined in
+  Documentation/devicetree/bindings/media/video-interfaces.txt.
+
+  CSI2DC must have two clocks to function correctly. One clock is the
+  peripheral clock for the inside functionality of the hardware block.
+  This is named 'pclk'. The second clock must be the cross domain clock,
+  in which CSI2DC will perform clock crossing. This clock must be fed
+  by the next controller in pipeline, which usually is a sensor controller.
+  Normally this clock should be given by this sensor controller who
+  is also a clock source. This clock is named 'scck', sensor controller clock.
+
+  CSI2DC also supports direct access to the data through AHB, via DMA channel,
+  called data pipe.
+  Because of this, the sink 'port' child node (second) is not mandatory.
+  If the sink 'port' child node is missing, only data pipe is available.
+
+properties:
+  compatible:
+    const: microchip,sama7g5-csi2dc
+
+  reg:
+    description:
+      Physical base address and length of the registers set for the device.
+    maxItems: 1
+
+  clocks:
+    maxItems: 2
+
+  clock-names:
+    items:
+      - const: pclk
+      - const: scck
+
+  microchip,clk-gated:
+    type: boolean
+    description:
+      If present, indicates that the clock is gated.
+      Otherwise, the clock is free-running.
+
+  microchip,inter-line-delay:
+    allOf:
+    - $ref: /schemas/types.yaml#/definitions/uint32
+    - minimum: 1
+    - maximum: 16
+    default: 16
+    description:
+      Indicates how many clock cycles should be introduced between each line.
+
+  port@0:
+    type: object
+    description:
+      Input port node, single endpoint describing the input pad.
+
+    properties:
+      reg:
+        const: 0
+
+      endpoint:
+        type: object
+
+        properties:
+          remote-endpoint: true
+
+        required:
+          - remote-endpoint
+
+        additionalProperties: false
+
+    additionalProperties: false
+
+  port@1:
+    type: object
+    description:
+      Output port node, single endpoint, describing the output pad.
+
+    properties:
+      '#address-cells':
+        const: 1
+
+      '#size-cells':
+        const: 0
+
+      reg:
+        const: 1
+
+    patternProperties:
+      "^endpoint@[0-9a-f]$":
+        type: object
+
+        properties:
+          reg:
+            enum: [0, 1, 2, 3]
+            description: virtual channel for the endpoint
+
+          remote-endpoint: true
+
+        required:
+          - remote-endpoint
+          - reg
+
+        additionalProperties: false
+
+    additionalProperties: false
+
+required:
+  - compatible
+  - reg
+  - clocks
+  - clock-names
+  - port@0
+
+examples:
+  - |
+    csi2dc@e1404000 {
+        compatible = "microchip,sama7g5-csi2dc";
+        #address-cells = <1>;
+        #size-cells = <0>;
+        reg = <0xe1404000 0x500>;
+        clocks = <&pclk>, <&scck>;
+        clock-names = "pclk", "scck";
+
+        port@0 {
+               reg = <0>; /* must be 0, first child port */
+               csi2dc_in: endpoint { /* input from IDI interface */
+                     remote-endpoint = <&csi2host_out>;
+               };
+        };
+
+        port@1 {
+                #address-cells = <1>;
+                #size-cells = <0>;
+                reg = <1>; /* must be 1, second child port */
+                csi2dc_out: endpoint@2 {
+                        reg = <2>;  /* virtual channel identifier */
+                        remote-endpoint = <&xisc_in>; /* output to sensor controller */
+                };
+        };
+    };
+
+...