Feedback-ID: i80c9496c:Fastmail
Date: Sun, 26 May 2024 00:07:47 +0200
From: Niklas =?utf-8?Q?S=C3=B6derlund?= <niklas.soderlund@ragnatech.se>
To: Sakari Ailus <sakari.ailus@linux.intel.com>,
	Laurent Pinchart <laurent.pinchart@ideasonboard.com>,
	Mauro Carvalho Chehab <mchehab@kernel.org>,
	Rob Herring <robh@kernel.org>,
	Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>,
	Conor Dooley <conor+dt@kernel.org>, linux-media@vger.kernel.org,
	devicetree@vger.kernel.org
Cc: linux-renesas-soc@vger.kernel.org
Subject: [RFC] dt-bindings: media: video-interfaces: How to describe physical
 lanes for CSI-2 C-PHY
Message-ID: <20240525220747.GD1900917@ragnatech.se>
Precedence: bulk
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit

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