This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

SK-AM62A-LP: CSI-2 D-PHY Clock and Data lane polarity inversion/swap

Part Number: SK-AM62A-LP

Greetings,

I am working with SDK 8.6 using a new image sensor and trying to display a test pattern at 1920x1080 resolution, 8bpp. I know that the Clock and Data Lanes 0-1 need to be inverted to the Raspberry Pi connector (i.e. P is going to N, N is going to P). We were hoping to do this with the image sensor but this is proving more difficult than anticipated so we would like to invert them at the DPHY input pins instead.  I see in the TRM RevB Section  "12.7.1.1 DPHY_RX Feature" states the DPHY_RX module supports "Swapping of DP/DN signals within each clock/data pair (Facilitated by CSI_RX_IF controller)"

According to Section "14.9.6.2.9.1 MMR_K3_DPHY_WRAP_LANE Register" at Physical Address 0x30111000, it looks like bits 0-4 all potentially deal with polarity for the clock and lanes being used. It isn't clear to me from the field descriptions (which are all identical) what bits 4 and 2 do and if they are required to be changed for this.

It seems to me that this currently requires an adjustment to the driver file in the Linux Kernel "drivers/phy/cdns-dphy.c". I adjusted this file as follows:

diff --git a/Desktop/kernel_configs/Cadence/cdns-dphy.c b/drivers/phy/cadence/cdns-dphy.c
index 68b871111e..272e8b909c 100644
--- a/Desktop/kernel_configs/Cadence/cdns-dphy.c
+++ b/drivers/phy/cadence/cdns-dphy.c
@@ -70,6 +70,11 @@
 
 #define DPHY_LANE                      DPHY_WRAP(0x0)
 #define DPHY_LANE_RESET_CMN_EN         BIT(23)
+#define DPHY_LANE_DATA1CLK_SWAPDPDN    BIT(4)
+#define DPHY_LANE_DATA0CLK_SWAPDPDN    BIT(3)
+#define DPHY_LANE_DATA1_SWAPDPDN       BIT(2)
+#define DPHY_LANE_DATA0_SWAPDPDN       BIT(1)
+#define DPHY_LANE_CLK_SWAPDPDN         BIT(0)
 
 #define DPHY_ISO_CL_CTRL_L             DPHY_ISO(0x10)
 #define DPHY_ISO_DL_CTRL_L0            DPHY_ISO(0x14)
@@ -561,7 +566,9 @@ static int cdns_dphy_rx_configure(struct cdns_dphy *dphy,
        if (soc && soc->data)
                soc_data = soc->data;
        if (!soc || (soc_data && !soc_data->has_hw_cmn_rstb)) {
-               reg = DPHY_LANE_RESET_CMN_EN;
+               // reg = DPHY_LANE_RESET_CMN_EN; // Orignial code
+               // reg = DPHY_LANE_RESET_CMN_EN | DPHY_LANE_DATA1CLK_SWAPDPDN | DPHY_LANE_DATA0CLK_SWAPDPDN | DPHY_LANE_DATA1_SWAPDPDN | DPHY_LANE_DATA0_SWAPDPDN | DPHY_LANE_CLK_SWAPDPDN;
+               reg = DPHY_LANE_RESET_CMN_EN | DPHY_LANE_DATA1_SWAPDPDN | DPHY_LANE_DATA0_SWAPDPDN | DPHY_LANE_CLK_SWAPDPDN;
                writel(reg, dphy->regs + DPHY_LANE);
        }
 

I believe I inverted the clock and data lanes doing this. I can use devmem2 tool to read the register:

root@am62axx-evm:/# devmem2 0x30111000 w
/dev/mem opened.
Read at address  0x30111000 (0xffffb79cd000): 0xC0800007

Unfortunately, there are more things in question with this image sensor so I can't say that this was a proper adjustment or not because I'm not able to receive the test pattern yet. Does this appear to be the correct solution or could more information be provided for the register fields and DPHY?

This seems like something ideal for a device-tree parameter perhaps for the j721e-csi2rx device section but I didn't find anything like "lane_polarity" in the device tree documentation for it or for the cdns,csi2rx device and related phy documents.

Thank you for your support,

Steve True

  • Hello Steve,

    Let me to check with the dev team regarding this. Please expect some delay in response.

    Regards,

    Jianzhong

  • Hello Jianzhong,

    Thank you for looking into this. Would you be able to provide an update on the current status?

    Best Regards,

    Steve

  • Hello Steve,

    Your SW changes look good. Our HW team are checking on this and will respond.

    Regards,

    Jianzhong

  • Hi Steve,

    Can you clarify a few things:

    1.) Did you try running line 23 already? 

    2.) Are you only enabling data lanes 0 and 1? 

    3.) As a debug step you can try adding in the data lane clock for data lanes 2 and 3 as well and see if this resolves anything. 

    For reference the data lane clocks (bit 3 and 4) are needed because the clk swap (bit 0) does not affect analog clock paths to the data lane. So both are needed when trying to swap the clock polarity. 

    Best regards,

    Sarah

  • Hello Sarah,

    1.) Did you try running line 23 already?

    Yes, I did try using line 23 ("reg = DPHY_LANE_RESET_CMN_EN | DPHY_LANE_DATA1CLK_SWAPDPDN | DPHY_LANE_DATA0CLK_SWAPDPDN | DPHY_LANE_DATA1_SWAPDPDN | DPHY_LANE_DATA0_SWAPDPDN | DPHY_LANE_CLK_SWAPDPDN;") before issuing this post actually.

    2.) Are you only enabling data lanes 0 and 1?

    Correct, I am only using data lanes 0 and 1. Good question though. I should have stated that in the original post.

    3.) As a debug step you can try adding in the data lane clock for data lanes 2 and 3 as well and see if this resolves anything

    I've just retried this since a couple things were adjusted in the setup during troubleshooting but I'm still unable to get any kind of output (i.e. a test pattern) yet from yavta, gstreamer, etc.

    So it seems that I should continue to use line 23 for my setup/config, correct?

    Thank you,

    Steve

  • Hi Steve,

    At the moment that is my understanding. I am looking into this to verify if there are other important bits that need to be set or proper sequencing. 

    I will update you shortly. 

    Thank you,

    Sarah

  • Hi Steve,

    To follow up here, I verified that I can swap the clk, data lane 0, and data lane 1 polarity using the same bits shown in line 23 and this works just fine. 

    What you have implemented should resolve the issue on the DUT side.

    Best regards,

    Sarah

  • Hi All, 

    Here are additional inputs  from the expert:

    I was able to successfully emulate frame transmission with the customer’s lane remapping configuration:

    DUT Designated Lane CLK-     Remapped Function CLK-

    DUT Designated Lane CLK+     Remapped Function CLK+

    DUT Designated Lane D0-      Remapped Function D3+

    DUT Designated Lane D0+      Remapped Function D3-

    DUT Designated Lane D1-      Remapped Function D1-

    DUT Designated Lane D1+      Remapped Function D1+

    DUT Designated Lane D2-      Remapped Function D0+

    DUT Designated Lane D2+      Remapped Function D0-

    DUT Designated Lane D3-      Remapped Function D2-

    DUT Designated Lane D3+      Remapped Function D2+

    The customer should not encounter any HW problems doing this.

     

    Regards,

    Sreenivasa

  • Hi All, 

    These would be accurate register modifications for the updated lane mapping:

    • 0x30101008 - CSIRX_STATIC_CFG
      • [30:28] - dl3_map = 0x3
      • [26:24] - dl2_map = 0x1
      • [22:20] - dl1_map = 0x2 (default)
      • [18:16] - dl0_map = 0x4
    • 0x30111000 - DPHYRX_WRAP_LANE
      • [8] - CLK_SWAPDPDN_DL_L_3 = 0x0 (default)
      • [7] - CLK_SWAPDPDN_DL_L_2 = 0x0 (default)
      • [6] - DATA_SWAPDPDN_DL_L_3 = 0x0 (default)
      • [5] - DATA_SWAPDPDN_DL_L_2 = 0x1
      • [4] - CLK_SWAPDPDN_DL_L_1 = 0x0 (default)
      • [3] - CLK_SWAPDPDN_DL_L_0 = 0x0 (default)
      • [2] - DATA_SWAPDPDN_DL_L_1 = 0x0 (default)
      • [1] - DATA_SWAPDPDN_DL_L_0 = 0x1
      • [0] - CLK_SWAPDPDN_DL_L_3 = 0x0 (default)

    Regards,

    Sreenivasa