AM3352: OCP_COFING register setting

Zou Qi

Prodigy 30 points

Part Number: AM3352
Other Parts Discussed in Thread: SN65LVDS93A

Currently, we are using AM3352 with a 15inch LCD, the LCD type is NL13676ac25-05d from TianMa.

the interface of LCD is LVDS, so I use SN65LVDS93A to convert RGB to LVDS.

On the customer side, the LCD will filker and screen shift after power on several hours or days.

Now we locate the issue on register "OCP_Config":

during development, we got FAE support from TI to modify the value to 0x141414.

and, in the forum, there is a similar case:

https://e2e.ti.com/support/processors-group/processors/f/processors-forum/300197/am3359-timing/1052263?cm_session=157e70fa-f21a-4ccc-ac88-5528eed98576&cm_type=link&cm_link=4bc7785a-a0fb-444a-90c4-6d3ad7cbf59a&utm_campaign=157e70fa-f21a-4ccc-ac88-5528eed98576&utm_medium=email&utm_source=contactmonkey&utm_content=sales%201%3a1&utm_term=RE%3a+Help+on+LCD+display+shift#1052263

but in this case, they use 0x38 to fix the issue.

Currently, we already using 14, but still have a problem on display (flicker, shift, very hard to reproduce, but it must be reproducible)

if we continue to reduce the value, how can we know the effect on system performance?

Are there any documents that can be referenced to guide on balance solving LCD display issue and system performance?

Thanks

over 4 years ago

0 Thomas Yang55737 over 4 years ago

TI__Expert 6296 points

Hi Expert

Any update on this? The 0x141414 register value is follow up below ticket suggestion, but need explain to why it should be set this value, this info will be helpful to debug a field issue as 0x141414 can not work in the new case, we need to know the exact setting logistics of this register to solve the issue.

Linux/AM3354: Display shift and freeze - Processors forum - Processors - TI E2E support forums

[U-Boot] [PATCH v3] arm: am33xx: Initialize EMIF REG_PR_OLD_COUNT for BBB and am335x-evm (denx.de)

+/**
+ * AM335X (EMIF_4D) EMIF REG_COS_COUNT_1, REG_COS_COUNT_2, and
+ * REG_PR_OLD_COUNT values to avoid LCDC DMA FIFO underflows and Frame
+ * Synchronization Lost errors. The values are the biggest that work
+ * reliably with offered video modes and the memory subsystem on the
+ * boards. These register have are briefly documented in "7.3.3.5.2
+ * Command Starvation" section of AM335x TRM. The REG_COS_COUNT_1 and
+ * REG_COS_COUNT_2 do not have any effect on current versions of
+ * AM335x.
+ */
+#define EMIF_OCP_CONFIG_BEAGLEBONE_BLACK       0x00141414
+#define EMIF_OCP_CONFIG_AM335X_EVM             0x003d3d3d

0 JJD over 4 years ago in reply to Thomas Yang55737

TI__Guru* 95721 points

The values in these bit fields are very application dependent. As the bit field description suggests, the user can set the threshold of command starvation so that lower priority commands eventually get serviced by the EMIF. Your customer will need to adjust the values in these bit fields depending on their application. These registers work in cooperation with the CONNID_COS_x_MAP registers to specify two different class of service (COS) for the masters in the system. This helps give priority control for different use cases. Please see section 7.3.3.5.4 of the TRM for more information.

In your case, since a value of 0x38 fixes this issue, this is allowing more bandwidth to the higher priority traffic, and the EMIF is not servicing the low priority traffic as often. You would have to evaluate whether or not the lower priority traffic can be pre-empted for a longer period of time in your use case.

Regards,

James