[PATCH v2 02/25] dt-bindings: media: atmel: csi2dc: add bindings for microchip csi2dc

Eugen.Hristev at microchip.com Eugen.Hristev at microchip.com
Mon Dec 6 00:57:11 PST 2021


On 11/29/21 11:37 PM, Sakari Ailus wrote:
> Hi Rob, Eugen,
> 
> On Mon, Nov 29, 2021 at 03:10:26PM -0600, Rob Herring wrote:
>>> +        properties:
>>> +          endpoint:
>>> +            $ref: video-interfaces.yaml#
>>
>> But what properties from this do you use? It doesn't look like you need
>> this?
> 
> I'd expect to see data-lanes at least --- unless the number of lanes is
> really fixed.

Hello Sakari, Rob,

Actually the input port can be either the Synopsys IDI interface, or 
parallel.
Since there is no such bus type 'synopsys IDI' this input port 
connection cannot have number of lanes, etc. (it is a 32 bit proprietary 
synopsys interface which is a mux/repackage of the CSI2 bus)

Also, this input port could be connected to a parallel sensor. In this 
case the csi2dc acts as a bypass between the input port and the output 
port. However, the csi2dc still needs to be probed and still needs to be 
configured, thus, it cannot be removed from the pipeline (otherwise the 
hardware pipeline won't work)

So my current implementation is like this : if the input port is 
parallel, use parallel mode, but if the bus type is set to CSI2-DPHY ( 
actually this is the bus interface used by the sensor ), use the csi2dc 
demux video pipeline to demux from IDI to parallel interface.

maybe this schematic is more clear than my words above:


 

                        +-----------------+ +-------------+ 

                        |port 0           | |  port 1     | 

                        |                 | |             | 

                        |                 | |             | 

                        |                 | |             | 

                        |                 | |             | 

                        |                 | |             | 

   +----------+         |        +--------|-|-------+     | 

   |          |         |        |+------------+    |     | 

   |  parallel|---------|--------|| bypass| |  |    ------|---- 

   |  sensor  | parallel|        ||       | |  |    |     | 

   |          | intf    |        ||       | |  |    | parallel 

   +----------+         |        |+------------+    | output 

                        |        |        | |       | intf| 

                        |        | csi2dc | |       |     | 

                        |        |        | |       |     | 

   +---------------+    |        |        | |       |     | 

   |               |synopsys     |        | |       |     | 

   |  synopsys host|IDI |        |        | |       |     | 

   |  controller   --------------|        | |       |     | 

   |               |    |        |        | |       |     | 

   |               |    |        +--------|-|-------+     | 

   +---------------+    |                 | |             | 

           ^            |                 | |             | 

  csi2 bus |            |                 | |             | 

    +------------+      |                 | |             | 

    |            |      |                 | |             | 

    | csi2 sensor|      +-----------------+ +-------------+ 

    |            | 

    |            | 

    +------------+ 

 



In this case, what would you advise to use for the bindings of the csi2dc ?

One option is to add the Synopsys IDI interface and document this as a 
possible bus type. I would rather not do this, since it's Synopsys 
proprietary and it would be difficult for me to document it at this 
moment (rather someone from Synopsys who is more familiar with this )

So, I should still refer video interfaces in the node, and then specify 
that this bus can be either parallel or csi2 dphy, but without number of 
lanes since it does not make sense (this would be between csi2 sensor 
and synopsys host controller), and specify only parallel properties like 
bus width , etc ?

Which would be a better way to go ?

Thanks,
Eugen
 




> 
> --
> Sakari Ailus
> 



More information about the linux-arm-kernel mailing list