[RESEND PATCH v2 5/5] drm/tidss: Fix sampling edge configuration

[Swamil Jain]

Hi Leonardo,

On 7/2/26 18:29, Leonardo Costa wrote:
> Hello,
> 
> We tested this patch and it introduces a regression on our panel.
> 
> 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.
> 
>>From SPRUIV7C (https://www.ti.com/lit/ug/spruiv7b/spruiv7c.pdf):
> 
> 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
> 
> So, the proposed fix to this patch is:
> 
> ```diff
> - regmap_update_bits(dispc->clk_ctrl, 0, 0x100, ipc ? 0x100 : 0x000);
> + regmap_update_bits(dispc->clk_ctrl, 0, 0x100, ipc ? 0x000 : 0x100);
> ```
> 

Thanks for the suggestion, Tomi is trying to fix this issue, please have
a look: 
https://lore.kernel.org/all/20260529-beagley-ai-display-v3-9-7fefdc5d1adf@ideasonboard.com/

Regards,
Swamil.

> Reverting the patch also makes the 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.
> 
> Please ignore the previous email I sent:
> https://lore.kernel.org/all/20260702104817.1219078-1-leoreis.costa@gmail.com/
> I hadn't seen this more recent thread at the time.
>