PROCESSOR-SDK-AM62X: DSS0 VP2_FREQ req RF setting ineffective

Hello!

Thank you for the suggestion. It seems we've encountered a similar issue before indeed (in relation to data line, not Vsynch though).

We will try the suggested patch on Monday and let you know if setting the shadow register was our fix.

/MK

Hello TI,

After changing the shadow register under 0x0010830 to 0x00000300" we see the following behaviour:

- the RF settings appear to be correct at the time from 0s to~2s after boot

between 2.0 and 3.0s (estimated) they are incorrect again (maybe reverted to default?) for a short while (~1s) and then they are correct again.

See below video.

This could be explained by the handover of the DSS ownership between M4 and the A53 cores (we have an early display during boot implemented on M4 then we hadover the DSS to A53).

Does this behaviour mean we have a short period of defautl settings during the handover? If so - how could this gap be closed?

There seems to be an additional side effect after this workaround - there is a considerable delay between LVDS and DPI sides.

What we checked so far:

- same shadow register settings on both sides

- the code delta looks clean - the delay is introduced after applying the new RF settings via the 0x0010830 shadow register.

The updated summary so far:

• the suggested patch seems to correct the RF behaviour but introduces at least two new issues:
  • delay between the LVDS and DPI on M4
  • no output at all on A53

 We narrowed down the SW delta to the shadow register change, there is no other SW difference between no issue and 2 new issues builds.

Additional point regarding the issue timing:


The RF flank settings coincide with the issue timing we observe.

The 2nd VP is not active until the RF setting transitions to the intermediate incorrect setting and both disappear as soon as the VSynch setting is back to normal. See the 1st reply. See also another video:

Hi Maciej,

Could you please check in pol_freq register, there is an align bit that is associated with this bit.

FPT was provided AM62P and AM62 Uboot to Linux transition for this implementation and had confirmed this to be fixed previously. Can you also answer the following issues:

1. Is this issue observed on small number of units or on all your samples.

2. What is the SDK baseline on which you are applying these patches.

3. Can you share the sequence in which this change is being applied.

Thanks and Regards,

Rahul Prabhu  

Hello Rahul,

The issue that we chased before was related to the data line driving. Unfortunately we never noticed that the VSynch setting was also incorrect, until due to HW tolerance variance a flicker has been reported.

The follow up problems with desynch and lack of linux output are reproducible on every ECU. The wrong driving edge configuration causes issues on ~1% of the devices.

We're still on the 08.06.00.42 SDK.

Questions regarding the register content and the sequence will have to wait until the development team is back online. 

Hello Rahul,

Below is the register setting for pol_freq and DPI0_CLK_CTRL in 2 cases

The value of these registers is read from Linux by devmem2 as below:

root@am62xx-zdml3:~# devmem2 0x3020A04C
/dev/mem opened.
Memory mapped at address 0xffff8dc6d000.
Read at address 0x3020A04C (0xffff8dc6d04c): 0x00070000
root@am62xx-zdml3:~# devmem2 0x3020B04C
/dev/mem opened.
Memory mapped at address 0xffff9c1c2000.
Read at address 0x3020B04C (0xffff9c1c204c): 0x00070000
root@am62xx-zdml3:~# devmem2 0x00108300
/dev/mem opened.
Memory mapped at address 0xffffac0fa000.
Read at address 0x00108300 (0xffffac0fa300): 0x00000300

3. Below is the sequense:

Progress update:

We removed an old workaround (hfp/hpb pixel shift) that was likely related to the wrong driving edge configuration:

and we currently have the following status:

• in M4 both VPs start simultaneously (no delay anymore)
• after the the transition to Linux 1 output disappears shortly
• the linux main light function is present on both sides after that.

The related video:

It looks like the current issue is limited to the VP init in A53 core(s).

After applying the shadow register changes only once in M4 we got rid of the handover problem, but have a new random issue that shows up only sometimes (~10-20% occurence).

The DPI side output can sometimes become tilted:

Syncing email conversation here, since the tilting issue has been resolved by readding the shadow register setting to 0x300 in the panel driver, I am closing this ticket for now.