Part Number: AM625
Hi,
After the 653460b9520 ("drm/tidss: Fix sampling edge configuration") commit in the TI v6.18 kernel, we noticed a regression with one of our panels.
On our board, a Toshiba TC358768 DPI-to-DSI bridge is connected to the parallel RGB output. The bridge requires data to be driven on the negative edge, and this is also reflected by the ipc variable in dispc_vp_enable(), which is set to 1.
With this patch applied, however, data is driven on the positive edge instead.
According to SPRUIV7C, both MAIN_CTRL_MMR_CFG0_DPI0_CLK_CTRL[8] and DSS_VP1_POL_FREQ[14] IPC should be programmed consistently. However, if we follow the actual bit descriptions, and ignore the sentence saying that the two programmed values should be the same, the data is driven on the requested edge.
As stated in the reference manual:
```
MAIN_CTRL_MMR_CFG0_DPI0_CLK_CTRL[8] (DPI0_CLK_CTRL_DATA_CLK_INVDIS):
Clock edge select for DPI0 data outputs
Note that this value should be the same as the programmed value of
DSS_POL_FREQ[14] IPC.
Reset Source: mod_por_rst_n
0 DATA and DE are driven on the falling edge of clk
1 DATA and DE are driven on the rising edge of clk
DSS_VP1_POL_FREQ[14] (IPC):
Invert pixel clock
To set data to pixel clock relationship, CTRL_MMR_DPI0_CLK_CTRL[8]
DPI0_CLK_CTRL_DATA_CLK_INVDIS setting should be the same as the [14]
IPC setting.
0 Data is driven on the LCD data lines on the rising-edge of the pixel clock
1 Data is driven on the LCD data lines on the falling-edge of the pixel clock
```
The following change to the patch fixes the issue:
- regmap_update_bits(dispc->clk_ctrl, 0, 0x100, ipc ? 0x100 : 0x000);
+ regmap_update_bits(dispc->clk_ctrl, 0, 0x100, ipc ? 0x000 : 0x100);Reverting the patch also makes our Toshiba bridge work correctly again. However, we can confirm that the patch is needed, otherwise only the positive-edge case (our case) works correctly.
In other words, the two registers need to match semantically, not numerically.
Additionally, I also raised this same concern in the patch sent to mainline: lore.kernel.org/.../
Best regards,
Leonardo
