[TDA4AL] TIDSS SYNC LOST

Hi,

Are you enabling DSS on A72 or on R5F? Because once you install vision apps dtb files, DSS would not be available on A72. So can you please check ?

Regards,

Brijesh

After I enable DSS on A72 for using Qt GUI application, I newly built k3-j721s2-vision-apps.dtbo.

Below is k3-j721s2-vision_apps.dts fixed.

Thanks for sharing this fix, we will fix this in the upcoming SDK release.

Brijesh Jadav Hi Brijesh, I am working with Unkyoung. It seems there was a misunderstanding in communication between you and Unkyoung.

Unkyoung told "Below is k3-j721s2-vision_apps.dts fixed.", but it was NOT FIXED(he said wrong). We just changed k3-j721s2-vision_apps.dts to enable DSS on A72 because we should use qt display with vision_apps. So this issue is not resolved yet. Please keep checking this issue.

Hi Hoewon Kim,

ok, can you please try running qt application, without using vision apps dtb file? Also please remove mcu2_0 firmware from /lib/firmware when checking this out. 

If this works, can you also please try removing DSS from R5F firmware by commenting out ENABLE_DSS_SINGLE/ENABLE_DSS_DUAL in ti-processor-sdk-rtos-j721e-evm-08_04_00_02\vision_apps\platform\j721e\rtos\common\app_cfg_mcu2_0.h file?

Regards,

Brijesh

Brijesh Jadav We have already commented  ENABLE_DSS_SINGLE/ENABLE_DSS_DUAL in vision_apps/platform/j721s2/rtos/common/app_cfg_mcu2_0.h. So qt display is working properly with 30-fps camera input. But the sync lost issue occurs while our algorithm is running. You can find that frame image is often broken with the linked video which Unkyoung shared in first.

Hi Hoewon Kim,

ok, i understood the issue now. What i am suspecting is, QOS parameters are not setup for DSS correctly. In the file board-support/u-boot-2021.01+gitAUTOINC+a169f42610-ga169f42610/arch/arm/mach-k3/j721s2_init.c, i dont see QoS setup for DSS. This could be reason for DSS Sync lost. 

Can you just copy setup_dss_qos from j721e_init.c file in the j721s2_init.c file and see if it helps? 

Regards,

Brijesh

I checked ti-processor-sdk-linux-j721s2-evm-08_04_00_13/board-support/u-boot-2021.01+gitAUTOINC+a169f42610-ga169f42610/arch/arm/mach-k3/j721e_init.c file.

But I can't find code about setup_dss_qos. The same goes for the j721s2_init.c.

If you need to see this file that I have, I will additionally attach file here reply.

I would appreciate it if you could let me know what more I can do.

Also, I checked one more thing.

I compared The PSDK Linux 8.4.0.11 for J721E and 8.4.0.13 J721S2's j721e_init.c.

The difference is define CONFIG_TI_SECURE_DEVICE.

The 8.4.0.11 (j721e) includes code about define CONFIG_TI_SECURE_DEVICE, but 8.4.0.13 (j721s2) doesn't.

This code (define CONFIG_TI_SECURE_DEVICE) includes setup_dss_qos.

Could I need to try to add code about define CONFIG_TI_SECURE_DEVICE into 8.4.0.13 (j721s2)'s j721s2_init.c ?

Hi Lee,

Please copy this part of the code from J721E release into j721s2_init.c file and call this API just before spl_early_init API call. 

Regards,

Brijesh

I got a build errof because of no define of board-support/u-boot-2021.01+gitAUTOINC+a169f42610-ga169f42610/arch/arm/mach-k3/include/mach/j721e_qos_params.h.

Could you send me the built u-boot including setup_dss_qos?

Or not, hard coding, is it okay?

I mean that just I define things to happen error copying from j721e_qos_params.h.

Code changes

* ti-processor-sdk/ti-processor-sdk-linux-j721s2-evm-08_04_00_13/board-support/u-boot-2021.01+gitAUTOINC+a169f42610-ga169f42610/arch/arm/mach-k3/j721s2_init.c

Outputs

• ti-processor-sdk-linux-j721s2-evm-08_04_00_13/board-support/
  •  u-boot_build/
    • a72/
      • tispl.bin
      • u-boot.img
    • r5/
      • u-boot.img
      • ti-boot3.bin
  • k3-image-gen-2022.01/
    • ti-boot3.bin

Fisrt, I tested a72's tispl.bin, u-boot.img, & k3-image...'s ti-boot3.bin.

But still I have TIDSS SYNC LOST.

What combination should I use for test?

Hi Lee,

SYNC LOST error typically comes when DSS is not able to read the image fast enough from the DDR and one of the reason could be incorrect these parameters.. I am not sure why they are not enabled yet, i am checking it internally with the team.

Meanwhile, can you please help me understand what the algorithm is doing? Does this algorithm use high DDR BW? or can we measure the DDR BW ?

Regards,

Brijesh

1. Any more don't I need to do test the setup_dss_qos that you let me know?
   
   
2. What the algorithm is doing are same as below.
   • Camera gives images.
   • MSC1 scales images.
   • C7x2 preprocesses images for TIDL input.
   • C7x1 (with MMA) runs TIDL.
   • A72 postprocesses TIDL output.
   • A72 displays Qt application.
   • C7x2 & A72 additionally process some others algorithms too.
     
     
3. Below is DDR BW information.

   • Summary of CPU load,
     ====================
     
     CPU: mpu1_0: TOTAL LOAD =  82.91 % ( HWI =   2.45 %, SWI =   0.91 % )
     CPU: mcu2_0: TOTAL LOAD =  16. 0 % ( HWI =   0. 0 %, SWI =   0. 0 % )
     CPU: mcu2_1: TOTAL LOAD =  15. 0 % ( HWI =   0. 0 %, SWI =   0. 0 % )
     CPU:  c7x_1: TOTAL LOAD =  49. 0 % ( HWI =   0. 0 %, SWI =   0. 0 % )
     CPU:  c7x_2: TOTAL LOAD =  43. 0 % ( HWI =   0. 0 %, SWI =   0. 0 % )
     
     
     HWA performance statistics,
     ===========================
     
     HWA:   LDC : LOAD =   3.21 % ( 20 MP/s )
     HWA:   MSC0: LOAD =   4.78 % ( 31 MP/s )
     
     
     DDR performance statistics,
     ===========================
     
     DDR: READ  BW: AVG =   2991 MB/s, PEAK =  18920 MB/s
     DDR: WRITE BW: AVG =   1968 MB/s, PEAK =  13377 MB/s
     DDR: TOTAL BW: AVG =   4959 MB/s, PEAK =  32297 MB/s
     
     
     Detailed CPU performance/memory statistics,
     ===========================================
     
     DDR_SHARED_MEM: Alloc's: 392 alloc's of 191319740 bytes
     DDR_SHARED_MEM: Free's : 0 free's  of 0 bytes
     DDR_SHARED_MEM: Open's : 392 allocs  of 191319740 bytes
     DDR_SHARED_MEM: Total size: 536870912 bytes
     
     CPU: mcu2_0: TASK:           IPC_RX:   0. 3 %
     CPU: mcu2_0: TASK:       REMOTE_SRV:   0. 2 %
     CPU: mcu2_0: TASK:        LOAD_TEST:   0. 0 %
     CPU: mcu2_0: TASK:       TIVX_CPU_0:   0. 0 %
     CPU: mcu2_0: TASK:      TIVX_VPAC_N:   0. 0 %
     CPU: mcu2_0: TASK:      TIVX_VPAC_L:   0.32 %
     CPU: mcu2_0: TASK:      TIVX_VPAC_M:   0.43 %
     CPU: mcu2_0: TASK:      TIVX_VPAC_M:   0. 0 %
     CPU: mcu2_0: TASK:      TIVX_VPAC_V:   0. 0 %
     CPU: mcu2_0: TASK:       TIVX_CAPT1:   0.24 %
     CPU: mcu2_0: TASK:       TIVX_CAPT2:   0. 0 %
     CPU: mcu2_0: TASK:       TIVX_DISP1:   0. 0 %
     CPU: mcu2_0: TASK:       TIVX_DISP2:   0. 0 %
     CPU: mcu2_0: TASK:       TIVX_CSITX:   0. 0 %
     CPU: mcu2_0: TASK:       TIVX_CAPT3:   0. 0 %
     CPU: mcu2_0: TASK:       TIVX_CAPT4:   0. 0 %
     CPU: mcu2_0: TASK:       TIVX_CAPT5:   0. 0 %
     CPU: mcu2_0: TASK:       TIVX_CAPT6:   0. 0 %
     CPU: mcu2_0: TASK:       TIVX_CAPT7:   0. 0 %
     CPU: mcu2_0: TASK:       TIVX_CAPT8:   0. 0 %
     CPU: mcu2_0: TASK:      TIVX_DISP_M:   0. 0 %
     CPU: mcu2_0: TASK:      TIVX_DISP_M:   0. 0 %
     CPU: mcu2_0: TASK:      TIVX_DISP_M:   0. 0 %
     CPU: mcu2_0: TASK:      TIVX_DISP_M:   0. 0 %
     
     CPU: mcu2_0: HEAP:    DDR_LOCAL_MEM: size =   16777216 B, free =   16714496 B ( 99 % unused)
     
     CPU: mcu2_1: TASK:           IPC_RX:   0. 0 %
     CPU: mcu2_1: TASK:       REMOTE_SRV:   0. 0 %
     CPU: mcu2_1: TASK:        LOAD_TEST:   0. 0 %
     CPU: mcu2_1: TASK:         TIVX_SDE:   0. 0 %
     CPU: mcu2_1: TASK:         TIVX_DOF:   0. 0 %
     CPU: mcu2_1: TASK:       TIVX_CPU_1:   0. 0 %
     CPU: mcu2_1: TASK:      IPC_TEST_RX:   0. 0 %
     CPU: mcu2_1: TASK:      IPC_TEST_TX:   0. 0 %
     CPU: mcu2_1: TASK:      IPC_TEST_TX:   0. 0 %
     CPU: mcu2_1: TASK:      IPC_TEST_TX:   0. 0 %
     CPU: mcu2_1: TASK:      IPC_TEST_TX:   0. 0 %
     
     CPU: mcu2_1: HEAP:    DDR_LOCAL_MEM: size =   16777216 B, free =   16773120 B ( 99 % unused)
     
     CPU:  c7x_1: TASK:           IPC_RX:   0. 4 %
     CPU:  c7x_1: TASK:       REMOTE_SRV:   0. 0 %
     CPU:  c7x_1: TASK:        LOAD_TEST:   0. 0 %
     CPU:  c7x_1: TASK:      TIVX_C7_1_P:  35.12 %
     CPU:  c7x_1: TASK:      TIVX_C7_1_P:   0. 0 %
     CPU:  c7x_1: TASK:      TIVX_C7_1_P:   0. 0 %
     CPU:  c7x_1: TASK:      TIVX_C7_1_P:   0. 0 %
     CPU:  c7x_1: TASK:      TIVX_C7_1_P:   0. 0 %
     CPU:  c7x_1: TASK:      TIVX_C7_1_P:   0. 0 %
     CPU:  c7x_1: TASK:      TIVX_C7_1_P:   0. 0 %
     CPU:  c7x_1: TASK:      TIVX_C7_1_P:   0. 0 %
     CPU:  c7x_1: TASK:      IPC_TEST_RX:   0. 0 %
     CPU:  c7x_1: TASK:      IPC_TEST_TX:   0. 0 %
     CPU:  c7x_1: TASK:      IPC_TEST_TX:   0. 0 %
     CPU:  c7x_1: TASK:      IPC_TEST_TX:   0. 0 %
     CPU:  c7x_1: TASK:      IPC_TEST_TX:   0. 0 %
     
     CPU:  c7x_1: HEAP:    DDR_LOCAL_MEM: size =  268435456 B, free =  230155776 B ( 85 % unused)
     CPU:  c7x_1: HEAP:           L3_MEM: size =    3964928 B, free =     819200 B ( 20 % unused)
     CPU:  c7x_1: HEAP:           L2_MEM: size =     458752 B, free =     458752 B (100 % unused)
     CPU:  c7x_1: HEAP:           L1_MEM: size =      16384 B, free =          0 B (  0 % unused)
     CPU:  c7x_1: HEAP:  DDR_SCRATCH_MEM: size =  419430400 B, free =  392325888 B ( 93 % unused)
     
     CPU:  c7x_2: TASK:           IPC_RX:   0.10 %
     CPU:  c7x_2: TASK:       REMOTE_SRV:   0. 0 %
     CPU:  c7x_2: TASK:        LOAD_TEST:   0. 0 %
     CPU:  c7x_2: TASK:         TIVX_CPU:  29.34 %
     CPU:  c7x_2: TASK:      IPC_TEST_RX:   0. 0 %
     CPU:  c7x_2: TASK:      IPC_TEST_TX:   0. 0 %
     CPU:  c7x_2: TASK:      IPC_TEST_TX:   0. 0 %
     CPU:  c7x_2: TASK:      IPC_TEST_TX:   0. 0 %
     CPU:  c7x_2: TASK:      IPC_TEST_TX:   0. 0 %
     
     CPU:  c7x_2: HEAP:    DDR_LOCAL_MEM: size =   16777216 B, free =   14806784 B ( 88 % unused)
     CPU:  c7x_2: HEAP:           L2_MEM: size =     458752 B, free =     425984 B ( 92 % unused)
     CPU:  c7x_2: HEAP:           L1_MEM: size =      16384 B, free =      16384 B (100 % unused)
     CPU:  c7x_2: HEAP:  DDR_SCRATCH_MEM: size =   67108864 B, free =    2628608 B (  3 % unused)

Hi Lee,

Unkyoung Lee said:

Any more don't I need to do test the setup_dss_qos that you let me know?

I also have the same question. Ideally we should be setting qos here as well. but let me confirm with the team.. 

Looking at the performance states, i am bit worried about the peak BW, reaching almost upto the limit, even though average BW is smaller.. I think the only way to control and limit them is by using QoS parameters. So let me check and confirm the same with the team. I will get back as soon as possible. 

Regards,

Brijesh

What files should I use after building?
As I said last time, when you build, several files are created.
But I'm not sure which file to use.

Output file list

• ti-processor-sdk-linux-j721s2-evm-08_04_00_13/board-support/
  •  u-boot_build/
    • a72/
      • tispl.bin
      • u-boot.img
    • r5/
      • u-boot.img
      • ti-boot3.bin
  • k3-image-gen-2022.01/
    • ti-boot3.bin

I accidentally clicked the resolved button because the web page was displayed too late, but I can't cancel it.

Anyway, I applied the patch you told me to apply, but I can't boot.

1. 'git am patch_file_name' is not working.
   

   $ cd board-support/u-boot-2021.01+gitAUTOINC+a169f42610-ga169f42610
   $ git am 0001-Added-QoS-parameters-settings.patch

   
   
2. I just applied manually patch code.
   
   • patched_files.tar
3. And then the new binaries was copied to BOOT filesystem.
   • patched_binaries.zip
   • board-support/u-boot_build/a72/tispl.bin
   • board-support/u-boot_build/a72/u-boot.img

   • board-support/k3-image-gen-2022.01/ti-boot3.bin

But I got a error boot message.

• error message
  

  U-Boot SPL 2021.01 (Dec 12 2022 - 23:14:10 +0900)
  SYSFW ABI: 3.1 (firmware rev 0x0008 '8.4.1--v08.04.01 (Jolly Jellyfi')
  SPL initial stack usage: 13472 bytes
  Trying to boot from MMC2
  Starting ATF on ARM64 core...
  
  NOTICE:  BL31: v2.6(release):v2.7-rc0-dirty
  NOTICE:  BL31: Built : 11:58:46, Aug 30 2022
  I/TC:
  I/TC: OP-TEE version: 3.17.0-125-g15a746d28 (gcc version 9.2.1 20191025 (GNU Toolchain for the A-profile Architecture 9.2-2019.12 (arm-9.10))) #1 Tue Aug 30 11:59:08 UTC 2022 aarch64
  I/TC: WARNING: This OP-TEE configuration might be insecure!
  I/TC: WARNING: Please check https://optee.readthedocs.io/en/latest/architecture/porting_guidelines.html
  I/TC: Primary CPU initializing
  I/TC: SYSFW ABI: 3.1 (firmware rev 0x0008 '8.4.1--v08.04.01 (Jolly Jellyfi')
  I/TC: HUK Initialized
  I/TC: Primary CPU switching to normal world boot

Is there something I did wrong in applying the patch?

Thanks Lee, yes, navss and c66x QoS shouldn't be added. 

Looking at the performance stats again, the reason why DSS is loosing sync is because of the high peak BW. It almost reaches to 32GB/s, which is too high.. 

On C7x, how are you accessing the buffers? Are you using DRU or UDMA channels to access them? or is it CPU access?

Because in the above code, we haven't set the priority for the C7x, so wondering if it is affecting the DSS. 

Regards,

Brijesh

Yes, some algorithms access the buffers by using DMAUtils for DMA Copy.

But same S/W accesses the buffers by using DMAUtils on J721E too.

On J721E, the BW peak is 8GB/s.

The difference is what hardware the algorithms run on.

Alg1 was moved c66 to c7x2 on J721S2.(not using DMA Copy)

Alg2 was moved c7x1 to c7x2 on J721S2. (not using DMA Copy)

Other algorithms run on same H/W in J721E & J721S2. (including algorithm using DMA Copy)

• Alg3 (TIDL) runs on c7x1 using DMA Copy with MMA.
• Alg4, Alg5 runs on a72 for post process, display.
• ...

---------------------------------------------------------------------------------------------------------------------------------

Anyway I want to know one thing.

Is there way to check that the dss qos patch is well applied?

For example, the register dump...

Thanks for your support.

Hi, Brijesh:

Below is additional internal another simple test app (without our algorithm process)'s result.

Test app is working as below.

• Input - Full HD NV12 images
• Process - scaling by MSC
• Output - Display using Qt

Result table

The difference in AVG BW seems to be due to the frame rate.

But this test app's PEAK seems to be very high in TDA4AL like the other app's result.

Could you please confirm why this could be the result?

Best regards,

UK

Anyway I want to know one thing.

Is there way to check that the dss qos patch is well applied?

For example, the register dump...

Thanks for your support.

Any updates on the above?

Hi Lee,

Can you please readback the DSS QOS registers from the Linux command prompt and confirm that they are setup correctly? You could find the register details in j721s2_qos_params.h header file, essentially below macros.

+#define QOS_DSS0_DMA 0x45dc2000
+#define QOS_DSS0_DMA_NUM_J_CH 2
+#define QOS_DSS0_DMA_NUM_I_CH 10
+#define QOS_DSS0_DMA_CBASS_GRP_MAP1(j) (QOS_DSS0_DMA + 0x0 + (j) * 8)
+#define QOS_DSS0_DMA_CBASS_GRP_MAP2(j) (QOS_DSS0_DMA + 0x4 + (j) * 8)
+#define QOS_DSS0_DMA_CBASS_MAP(i) (QOS_DSS0_DMA + 0x100 + (i) * 4)

Apart from this, can you also please read below register values and share them?

-  DSS0_COMMON_DISPC_GLOBAL_MFLAG_ATTRIBUTE (0x04A00098)

-  DSS0_COMMON_DISPC_GLOBAL_BUFFER (0x04A000A0)

-  DSS0_COMMON_DSS_CBA_CFG (0x04A000A4)

-  DSS0_VID_BUF_THRESHOLD (For the video pipeline connected to the display, 0x04A2003C, 0x04A3003C, 0x04A5003C, 0x04A6003C)

-  DSS0_VID_MFLAG_THRESHOLD (For the video pipeline connected to the display, 0x04A20208, 0x04A30208, 0x04A50208, 0x04A60208)

Regards,

Brijesh

Brijesh Jadav

Hi, we tried to readback registers QOS_DSS0_DMA_CBASS_GRP_MAP1 & 2 by calling readl() in setup_dss_qos().

So we could get the bellows:

QOS_DSS0_DMA_CBASS_GRP_MAP1(0) : [0x45dc2000]=0x76543210
QOS_DSS0_DMA_CBASS_GRP_MAP2(0) : [0x45dc2004]=0xfedcba98
QOS_DSS0_DMA_CBASS_GRP_MAP1(1) : [0x45dc2008]=0x0
QOS_DSS0_DMA_CBASS_GRP_MAP2(1) : [0x45dc200c]=0x0

QOS_DSS0_DMA_CBASS_MAP(0) : [0x45dc2100]=0x90
QOS_DSS0_DMA_CBASS_MAP(1) : [0x45dc2104]=0x90
QOS_DSS0_DMA_CBASS_MAP(2) : [0x45dc2108]=0x90
QOS_DSS0_DMA_CBASS_MAP(3) : [0x45dc210c]=0x90
QOS_DSS0_DMA_CBASS_MAP(4) : [0x45dc2110]=0x90
QOS_DSS0_DMA_CBASS_MAP(5) : [0x45dc2114]=0x90
QOS_DSS0_DMA_CBASS_MAP(6) : [0x45dc2118]=0x90
QOS_DSS0_DMA_CBASS_MAP(7) : [0x45dc211c]=0x90
QOS_DSS0_DMA_CBASS_MAP(8) : [0x45dc2120]=0x90
QOS_DSS0_DMA_CBASS_MAP(9) : [0x45dc2124]=0x90

QOS_DSS0_FBDC_CBASS_GRP_MAP1(0) : [0x45dc2400]=0x76543210
QOS_DSS0_FBDC_CBASS_GRP_MAP2(0) : [0x45dc2404]=0xfedcba98
QOS_DSS0_FBDC_CBASS_GRP_MAP1(1) : [0x45dc2408]=0x0
QOS_DSS0_FBDC_CBASS_GRP_MAP2(1) : [0x45dc240c]=0x0

QOS_DSS0_FBDC_CBASS_MAP(0) : [0x45dc2500]=0x90
QOS_DSS0_FBDC_CBASS_MAP(1) : [0x45dc2504]=0x90
QOS_DSS0_FBDC_CBASS_MAP(2) : [0x45dc2508]=0x90
QOS_DSS0_FBDC_CBASS_MAP(3) : [0x45dc250c]=0x90
QOS_DSS0_FBDC_CBASS_MAP(4) : [0x45dc2510]=0x90
QOS_DSS0_FBDC_CBASS_MAP(5) : [0x45dc2514]=0x90
QOS_DSS0_FBDC_CBASS_MAP(6) : [0x45dc2518]=0x90
QOS_DSS0_FBDC_CBASS_MAP(7) : [0x45dc251c]=0x90
QOS_DSS0_FBDC_CBASS_MAP(8) : [0x45dc2520]=0x90
QOS_DSS0_FBDC_CBASS_MAP(9) : [0x45dc2524]=0x90

And then, we tried to readback others by using Linux command as the bellows:

[DSS0_COMMON_DISPC_GLOBAL_MFLAG_ATTRIBUTE (0x04A00098)]

root@j721s2-evm:~# devmem2 0x04A00098 l
/dev/mem opened.
Memory mapped at address 0xffffbae78000.
Read at address  0x04A00098 (0xffffbae78098): 0x0000000000000002


[DSS0_COMMON_DISPC_GLOBAL_BUFFER (0x04A000A0)]

root@j721s2-evm:~# devmem2 0x04A000A0 l
/dev/mem opened.
Memory mapped at address 0xffff9c9d7000.
Read at address  0x04A000A0 (0xffff9c9d70a0): 0x0000000100004688


[DSS0_COMMON_DSS_CBA_CFG (0x04A000A4)]

root@j721s2-evm:~# devmem2 0x04A000A4 l
/dev/mem opened.
Memory mapped at address 0xffffb4bbe000.
Read at address  0x04A000A4 (0xffffb4bbe0a0): 0x0000000100004688



[DSS0_VID_BUF_THRESHOLD (For the video pipeline connected to the display, 0x04A2003C, 0x04A3003C, 0x04A5003C, 0x04A6003C)]

root@j721s2-evm:~# devmem2 0x04A2003C l
/dev/mem opened.
Memory mapped at address 0xffff9b70e000.
Read at address  0x04A2003C (0xffff9b70e038): 0x0FFF080000001000
root@j721s2-evm:~# devmem2 0x04A3003C l
/dev/mem opened.
Memory mapped at address 0xffff99a51000.
Read at address  0x04A3003C (0xffff99a51038): 0x0FFF080000001000
root@j721s2-evm:~# devmem2 0x04A5003C l
/dev/mem opened.
Memory mapped at address 0xffff89125000.
Read at address  0x04A5003C (0xffff89125038): 0x0FFF080000001000
root@j721s2-evm:~# devmem2 0x04A6003C l
/dev/mem opened.
Memory mapped at address 0xffff872e7000.
Read at address  0x04A6003C (0xffff872e7038): 0x0FFF080000001000


[DSS0_VID_MFLAG_THRESHOLD (For the video pipeline connected to the display, 0x04A20208, 0x04A30208, 0x04A50208, 0x04A60208)]

root@j721s2-evm:~# devmem2 0x04A20208 l
/dev/mem opened.
Memory mapped at address 0xffffb5ee5000.
Read at address  0x04A20208 (0xffffb5ee5208): 0x0437077F0AAA0555
root@j721s2-evm:~# devmem2 0x04A30208 l
/dev/mem opened.
Memory mapped at address 0xffffba2e6000.
Read at address  0x04A30208 (0xffffba2e6208): 0x0437077F0AAA0555
root@j721s2-evm:~# devmem2 0x04A50208 l
/dev/mem opened.
Memory mapped at address 0xffffaeb7e000.
Read at address  0x04A50208 (0xffffaeb7e208): 0x000000000AAA0555
root@j721s2-evm:~# devmem2 0x04A60208 l
/dev/mem opened.
Memory mapped at address 0xffffa2fcb000.
Read at address  0x04A60208 (0xffffa2fcb208): 0x000000000AAA0555

Best Regards,

Hoewon Kim

Hello Kim,

Can you please try with the two changes? 

- Can you please try setting value at the offset 0x04A00098 register to 0x1?

- Also please set the value at the offset 0x04A000A4 register to 0x0, ie 0x0000000000004688. 

Can you please try your usecase with above two changes and see if it improves? 

Regards,

Brijesh

Hi, Brijesh:

Setting

root@j721s2-evm:~# devmem2 0x04A00098 l
/dev/mem opened.
Memory mapped at address 0xffff803da000.
Read at address  0x04A00098 (0xffff803da098): 0x0000000000000001
root@j721s2-evm:~# devmem2 0x04A000A0 l
/dev/mem opened.
Memory mapped at address 0xffffabb26000.
Read at address  0x04A000A0 (0xffffabb260a0): 0x0000000000004688
root@j721s2-evm:~#

Mem BW

DDR: READ  BW: AVG =   2822 MB/s, PEAK =  15596 MB/s
DDR: WRITE BW: AVG =   1979 MB/s, PEAK =  11683 MB/s
DDR: TOTAL BW: AVG =   4801 MB/s, PEAK =  27279 MB/s

Sync lost error

[  338.511085] tidss_crtc_error_irq: 51994 callbacks suppressed
[  338.511098] tidss 4a00000.dss: CRTC0 SYNC LOST: (irq 80)
[  346.470673] tidss 4a00000.dss: CRTC0 SYNC LOST: (irq 80)
[  349.515486] tidss 4a00000.dss: CRTC0 SYNC LOST: (irq 80)
[  370.736015] tidss 4a00000.dss: CRTC0 SYNC LOST: (irq 80)
[  518.808913] tidss 4a00000.dss: CRTC0 SYNC LOST: (irq 80)

Unfortunately, the SYNC LOST still occurs.

Regards, UK

Hi Lee,

As far as i understand, this should have helped, but let me check with team and see if there is anything else required to give DSS highest priority.. 

Btw, is there a way to recreate this issue on EVM? 

Regards,

Brijesh

Does the EVM that you said mean TDA4VM, not AL?

As I shared with you last time, when I ran a simple test app and another app on TDA4VM, unlike Al, the memory bw peak was very stable with a similar value to avg bw.

I will talk to the team to see if there is a way to reproduce it in TDA4VM.

Yes, TDA4VL EVM. If possible, can you please try to recreate it on EVM to help debug it further? 

Regards,

Brijesh

Brijesh Jadav

Hi, we tried to change QOS_DSS0_DMA_ORDER_ID & QOS_DSS0_FBDC_ORDER_ID in arch/arm/mach-k3/include/mach/j721s2_qos_params.h as you suggested. So we could confirmed that the registers were changed as the bellow:

QOS_DSS0_DMA_CBASS_GRP_MAP1(0) : [0x45dc2000]=0x76543210
QOS_DSS0_DMA_CBASS_GRP_MAP2(0) : [0x45dc2004]=0xfedcba98
QOS_DSS0_DMA_CBASS_GRP_MAP1(1) : [0x45dc2008]=0x0
QOS_DSS0_DMA_CBASS_GRP_MAP2(1) : [0x45dc200c]=0x0

QOS_DSS0_DMA_CBASS_MAP(0) : [0x45dc2100]=0xa0
QOS_DSS0_DMA_CBASS_MAP(1) : [0x45dc2104]=0xa0
QOS_DSS0_DMA_CBASS_MAP(2) : [0x45dc2108]=0xa0
QOS_DSS0_DMA_CBASS_MAP(3) : [0x45dc210c]=0xa0
QOS_DSS0_DMA_CBASS_MAP(4) : [0x45dc2110]=0xa0
QOS_DSS0_DMA_CBASS_MAP(5) : [0x45dc2114]=0xa0
QOS_DSS0_DMA_CBASS_MAP(6) : [0x45dc2118]=0xa0
QOS_DSS0_DMA_CBASS_MAP(7) : [0x45dc211c]=0xa0
QOS_DSS0_DMA_CBASS_MAP(8) : [0x45dc2120]=0xa0
QOS_DSS0_DMA_CBASS_MAP(9) : [0x45dc2124]=0xa0

QOS_DSS0_FBDC_CBASS_GRP_MAP1(0) : [0x45dc2400]=0x76543210
QOS_DSS0_FBDC_CBASS_GRP_MAP2(0) : [0x45dc2404]=0xfedcba98
QOS_DSS0_FBDC_CBASS_GRP_MAP1(1) : [0x45dc2408]=0x0
QOS_DSS0_FBDC_CBASS_GRP_MAP2(1) : [0x45dc240c]=0x0

QOS_DSS0_FBDC_CBASS_MAP(0) : [0x45dc2500]=0xa0
QOS_DSS0_FBDC_CBASS_MAP(1) : [0x45dc2504]=0xa0
QOS_DSS0_FBDC_CBASS_MAP(2) : [0x45dc2508]=0xa0
QOS_DSS0_FBDC_CBASS_MAP(3) : [0x45dc250c]=0xa0
QOS_DSS0_FBDC_CBASS_MAP(4) : [0x45dc2510]=0xa0
QOS_DSS0_FBDC_CBASS_MAP(5) : [0x45dc2514]=0xa0
QOS_DSS0_FBDC_CBASS_MAP(6) : [0x45dc2518]=0xa0
QOS_DSS0_FBDC_CBASS_MAP(7) : [0x45dc251c]=0xa0
QOS_DSS0_FBDC_CBASS_MAP(8) : [0x45dc2520]=0xa0
QOS_DSS0_FBDC_CBASS_MAP(9) : [0x45dc2524]=0xa0

And then we also tried to set value at the offset 0x04A00098 register to 0x1 and the offset 0x04A000A4 register to 0x0, ie 0x0000000000004688 again as the bellow:

root@j721s2-evm:~# devmem2 0x04A00098 l 0x1
/dev/mem opened.
Memory mapped at address 0xffff90a6d000.
Read at address  0x04A00098 (0xffff90a6d098): 0x0000000000000002
Write at address 0x04A00098 (0xffff90a6d098): 0x0000000000000001, readback 0x0000000000000001
root@j721s2-evm:~# devmem2 0x04A000A0 l 0x4688
/dev/mem opened.
Memory mapped at address 0xffff84114000.
Read at address  0x04A000A0 (0xffff841140a0): 0x0000000100004688
Write at address 0x04A000A0 (0xffff841140a0): 0x0000000000004688, readback 0x0000000000004688
root@j721s2-evm:~#
root@j721s2-evm:~# devmem2 0x04A00098 l
/dev/mem opened.
Memory mapped at address 0xffffa01ca000.
Read at address  0x04A00098 (0xffffa01ca098): 0x0000000000000001
root@j721s2-evm:~# devmem2 0x04A000A0 l
/dev/mem opened.
Memory mapped at address 0xffffb81f1000.
Read at address  0x04A000A0 (0xffffb81f10a0): 0x0000000000004688

But we still faced the same issue as the bellow:

[  206.103217] tidss 4a00000.dss: CRTC0 SYNC LOST: (irq 80)
[  228.560330] tidss 4a00000.dss: CRTC0 SYNC LOST: (irq 80)
[  251.498385] tidss 4a00000.dss: CRTC0 SYNC LOST: (irq 80)
[  259.346126] tidss 4a00000.dss: CRTC0 SYNC LOST: (irq 80)
[  268.364002] tidss 4a00000.dss: CRTC0 SYNC LOST: (irq 80)

Hi Hoewon Kim,

Can you please try changing value from 0xA to 0xF? 

Regards,

Brijesh

Sorry one more change. I see in your register dump that below two registers are not setup correctly. 

QOS_DSS0_DMA_CBASS_GRP_MAP1(1) : [0x45dc2008]=0x0
QOS_DSS0_DMA_CBASS_GRP_MAP2(1) : [0x45dc200c]=0x0

They should be set to same as below values.

QOS_DSS0_DMA_CBASS_GRP_MAP1(0) : [0x45dc2000]=0x76543210
QOS_DSS0_DMA_CBASS_GRP_MAP2(0) : [0x45dc2004]=0xfedcba98

Can you please hard code these values in the setup_dss_qos API, as shown below?

writel(0x76543210, 0x45dc2008);

writel(0xfedcba98,  0x45dc200C);

Regards,

Brijesh

Hi, Brijech:

After I applied code that you said (wirtel...), I built u-boot again.

But the register setting wasn't chagned.

So, I tried to set register using by devmem2.

However, the setting is reset automally as below.

root@j721s2-evm:~# devmem2 0x45dc2008 l 0x76543210
/dev/mem opened.
Memory mapped at address 0xffffb5018000.
Read at address  0x45DC2008 (0xffffb5018008): 0x0000000000000000
Write at address 0x45DC2008 (0xffffb5018008): 0x0000000076543210, readback 0x0000000076543210
root@j721s2-evm:~# devmem2 0x45dc2008 l
/dev/mem opened.
Memory mapped at address 0xffffa77af000.
Read at address  0x45DC2008 (0xffffa77af008): 0x0000000000000000
root@j721s2-evm:~#

Best regards,

UK Lee

Hi Lee,

Could you please provide some information about the display? What is the resolution of the display? fps? output format etc?

Regards,

Brijesh

Hi, Brijesh:

Monitor Spec

• Display model name - GeChic ON-LAB 1306H
• Resolution - 1920 x 1080
• Max refresh rate - 60Hz

We use Qt app on wayland.

So, there is no specific setting for display on our application.

Regards,

UK

Thanks Brijesh.

So, is it right that j721s2 supports QOS ?

My team member found content in document same as below.

Hi, Brijesh:

After applying two things that you said, I got result more good.

But still I have SYNC LOST sometimes.

Although the frequency has decreased considerably, it has not completely disappeared.

Best Regards,

UK Lee

Hi Lee,

Which setting is helping? can you please provide more details? Is it value 4 or value 2 in NAVSS0_NBSS_NB1_CFG_NB_THREADMAP register?

Regards,

Brijesh

It is value 4.

The setting value 4 is helping !

With value 2, if trying boot, it is stuck.

Hi Lee,

ok, can we now just the priority for DSS and navss modules? Essentially, please comment out call to all API except navss and dss, as shown below, in j721s2_init.c file. Lets see if this helps to give higher priority to DSS, compared to other traffic. 

{
setup_navss_nb();
//setup_c66_qos();
//setup_main_r5f_qos();
//setup_vpac_qos();
//setup_dmpac_qos();
setup_dss_qos();
//setup_gpu_qos();
//setup_encoder_qos();
}

Regards,

Brijesh

I didn't get any special change when setting only navss and dss.
Same as just before, sync lost does not completely disappear, only the frequency is significantly reduced.

ok, one more question, how many pipelines are you using and what is the input format for these pipelines?

Regards,

Brijesh

Hi Lee,

Apart from this, can we please try increasing lower threshold to see if it helps? Please set below registers

0x04A2003C = 0x0FFF0E00

0x04A3003C = 0x0FFF0E00

0x04A5003C = 0x0FFF0E00

0x04A6003C = 0x0FFF0E00

Regards,

Brijesh

Hi, Brijesh:

About pipelines

• pipeline depth is 4.
• input format - NV12 FHD images, tensors, TIDL's outputs.

Trying to increase lower threshold

• Last time, in setup_dss_qos(), if setting a register value by writel, it was not boot.
  So, I setup the register by devmem2.
  But if the register 0x043003C is set to 0x0FFF0E00, it is happened as below
  1. After writing, if reading the register, the value is not changed.
  2. But after setting, if time is gone, SYNC LOST is occured although any app wasn't run.
     
     

     [  138.754848] tidss_crtc_error_irq: 694421 callbacks suppressed
     [  138.754856] tidss 4a00000.dss: CRTC0 SYNC LOST: (irq 80)
     [  138.765911] tidss 4a00000.dss: CRTC0 SYNC LOST: (irq a0)
     [  138.771222] tidss 4a00000.dss: CRTC0 SYNC LOST: (irq 80)
     [  138.776527] tidss 4a00000.dss: CRTC0 SYNC LOST: (irq 80)

Changing macros

• #define QOS_DSS0_DMA_ATYPE (3U)
• #define QOS_DSS0_DMA_ORDER_ID (15U)
• To date, not a single SYNC LOST has occurred. I'm going to do some more aging tests. Thank you!

Best Regards,

UK Lee