Hello, I'm trying to figure out how to best describe the ordering of the three physical copper (?) lanes that make up a logical lane in MIPI CSI-2 C-PHY. As far as I can tell there is no generic binding for this yet. Background: A logical lane in the MIPI CSI-2 C-PHY specification is created from three physical lanes on the SoC. The three physical lanes are commonly referred to as lane A, B and C. One or more logical lanes can be used to create a CSI-2 C-PHY bus. These logical lanes are commonly referred to in numerical incremental order. I don't have access to the MIPI CSI-2 C-PHY specification as that is available to MIPI members only. But I found these slides which I think can help illustrate the setup. https://2384176.fs1.hubspotusercontent-na1.net/hubfs/2384176/MIPI-C-PHY-Introduction-From-Basic-to-Implementation.pdf Problem: There is generic DT properties in video-interfaces.yaml to describe the logical lanes, 'data-lanes'. This property is used to describe how many logical lanes exists, and the order which they are connected. The order is important as logical lanes might be swapped between sender and receiver, and the sender and/or receiver can correct for this using software configuration. There are however no generic DT property in video-interfaces.yaml to describe the order of the A, B and C physical lanes that make up a logical lane. But just as the logical lanes these can be swapped between sender and receiver, and the device on either end of the link needs to correct for this with software configuration. For MIPI CSI-2 D-PHY lanes the same problem exists but is made simpler as each logical lane in D-PHY mode is made up of a differential pair of only two physical lanes. And the generic property 'lane-polarities' is used to describe if the P and N physical lanes have been swapped. lane-polarities: $ref: /schemas/types.yaml#/definitions/uint32-array minItems: 1 maxItems: 9 items: enum: [ 0, 1 ] description: An array of polarities of the lanes starting from the clock lane and followed by the data lanes in the same order as in data-lanes. Valid values are 0 (normal) and 1 (inverted). The length of the array should be the combined length of data-lanes and clock-lanes properties. If the lane-polarities property is omitted, the value must be interpreted as 0 (normal). This property is valid for serial busses only. How to best do something similar for the three physical lanes used for C-PHY which can be configured as either ABC, CBA, ACB, CAB, BAC or BCA? Any solutions I can think of feels wrong, but for different reasons. 1. We could add a new generic property to fulfill the 'lane-polarities' function for C-PHY, 'lane-polarities-mipi-cphy'. That would only be valid for C-PHY buses. The structure would be the same as for lane-polarities but the items enum would allow a value from 0-5 for each entry in the array. And we could define mappings in dt-bindings/media/video-interfaces.h to allow names in DTS, MEDIA_BUS_CSI2_CPHY_{ABC,CBA,ACB,CAB,BAC,BCA}? This feels wrong as we already have 'lane-polarities' and it is used for CSI-2 D-PHY configurations already. 2. We could extend the 'lane-polarities' property to accept values 0-5 and in video-interfaces.yaml describe that values other than 0 and 1 are only valid for CSI-2 C-PHY buses. We could still define the descriptive names in video-interfaces.h. This feels wrong as we would lose the ability to validate DTS files for D-PHY configurations only contain values 0 or 1. 3. We could use vendor specific properties to deal with C-PHY lane polarities. This just feels wrong as this is not a vendor specific issue. Maybe I'm overlooking a better solution? Any feedback on this problem would be appreciated. My current feeling for the least bad option is number 2 as it aligns how CSI-2 C-PHY and D-PHY are described. Unless a better idea comes along, or I'm educated on why this is a bad idea I will create a patch for this and see how it works out. -- Kind Regards, Niklas Söderlund
