The display settings (nvidia,dsi-init-cmd) did not reach the display properly. Certain settings were modified by the hardware.
What we did see:
A display that was not properly configured.
To check where the problem lay, we checked the init sequence that was transferred over the MIPI DSI to the LCD. When we compared this to the data that should have been sent, we noticed some differences with the data in the packet sequence.
Our packet sequence consisted of:
...
<TEGRA_DSI_PACKET_CMD DSI_DCS_WRITE_1_PARAM 0x3C 0x72 0x00>,
<TEGRA_DSI_PACKET_CMD DSI_DCS_WRITE_1_PARAM 0x3D 0xFF 0x00>,
<TEGRA_DSI_PACKET_CMD DSI_DCS_WRITE_1_PARAM 0x3E 0xFF 0x00>
...
<TEGRA_DSI_PACKET_CMD DSI_DCS_WRITE_1_PARAM 0x2C 0x09 0x00>,
<TEGRA_DSI_PACKET_CMD DSI_DCS_WRITE_1_PARAM 0x2D 0x1A 0x00>,
<TEGRA_DSI_PACKET_CMD DSI_DCS_WRITE_1_PARAM 0x2E 0x0B 0x00>,
...
For sequence commands that contain address 0x2D, 0x2E, 0x3D and 0x3E, the address and the value were replaced by 0x00. Resulting in that on address 0x00 value 0x00 was written in the LCD controller.
We traced this all the way to the tegra_dsi_controller_writel(…) function. In that function, when writel() is called, the value that is written to DSI_WR_DATA register is still valid. When we measure/trace in on the DSI line, the data is changed to 0x00.
We were able to work around this issue by changing the parts in the sequence where these addresses are written to long writes by making use of the auto increment in the LCD controller:
...
<TEGRA_DSI_PACKET_CMD DSI_DCS_LONG_WRITE 0x4 0x0 0x0 0x3C 0x38 0x1D 0x1F 0x0 0x0>,
...
<TEGRA_DSI_PACKET_CMD DSI_DCS_LONG_WRITE 0x4 0x0 0x0 0x2C 0x09 0x1A 0x0B 0x0 0x0>
...
We have it working now, but we still have some open questions:
- Is this a known bug in the silicon?
- Are only the 0x2D, 0x2E, 0x3D and 0x3E addresses affected by this bug?
