Skip to contentSkip to conversation

dt-bindings: media: video-interfaces: How to describe physical lanes for CSI-2 C-PHY

RFC Niklas Söderlund 2 participants 3 messages May 25, 2024 – May 27, 2024 Media (V4L/DVB)

lore
Share & tools
lore
#0 lore raw

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.

Signature · 2 lines
Kind Regards,
Niklas Söderlund
#1 lore raw

Hejssan Niklas,

Quoted 11 lines · Niklas Söderlund

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.

Could you add a property for this called "line-orders" with matching data line order in MIPI DisCo for Imaging specification <URL:https://www.mipi.org/specifications/mipi-disco-imaging>?

The polarity isn't a right term here as it's not a differential pair as on D-PHY.

Signature · 3 lines
Hälsningar,

Sakari Ailus
#2 lore raw

Hej Sakari,

Quoted 12 lines · Sakari Ailus

Hejssan Niklas,

Quoted 9 lines · Niklas Söderlund

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}?

Quoted 6 lines
Quoted 2 lines

This feels wrong as we already have 'lane-polarities' and it is used for CSI-2 D-PHY configurations already.

Could you add a property for this called "line-orders" with matching data line order in MIPI DisCo for Imaging specification <URL:https://www.mipi.org/specifications/mipi-disco-imaging>?

Thanks for this document! I looked for the C-PHY specification when trying to figure this out. But as that is not public I gave up on trying to use MIPI as a resource to work on MIPI stuff ;-)

Your suggestion for a line-orders property with the values described in the port properties section of is a good way forward, thanks!

Quoted 8 lines

The polarity isn't a right term here as it's not a differential pair as on D-PHY.

Signature · 3 lines
Hälsningar,

Sakari Ailus
Signature · 2 lines
Kind Regards,
Niklas Söderlund