[RFC] drivers: mipi_dbi: add support for mipi_dbi_configure_te

[danieldegrasse]

Many MIPI DBI displays support a "tearing effect" signal, which can be
configured to signal each v-sync or h-sync interval. This signal can be
used by the MIPI DBI controller to synchronize writes with the
controller, and avoid tearing effects on the screen (which occur when
the write pointer from the MCU overlaps with the panel's read pointer in
the display controller's graphics RAM).

Add the mipi_dbi_configure_te API, which allows display controllers to
configure MIPI DBI controller to wait for a TE edge before streaming
display data. Allow the tearing enable parameters to be configured via
devicetree settings, since these will vary based on the MIPI DBI
controller and display controller in use.

For an example of how this signal can be used, see the write diagrams within the ST7796S datasheet (section 10.8.3):

Depends on #81245 for some fixes to the LCDIC driver

Todo:

• Validate changes on frdm_mcxn947 with lcd_par_s035_8080 shield
• Validate changes on rd_rw612_bga with adafruit_2_8_tft_touch_v2 shield

[erwango]

Some controllers also support TE source (DSI link or External pin). How would you propose to configure this ?

[danieldegrasse]

Do you have an example I could look at? Not sure I follow here. Do you mean that the MIPI controller supports selecting the TE source between an on chip DSI peripheral and external pin?

[erwango]

Yes, supported in https://www.st.com/resource/en/reference_manual/rm0399-stm32h745755-and-stm32h747757-advanced-armbased-32bit-mcus-stmicroelectronics.pdf.
See 34.16.1

[danieldegrasse]

Thanks for pointing this out- one thing to note, this is a DSI controller, not a DBI controller- so it wouldn't fit within the MIPI DBI API itself.

Looking at this more, I do think we'd need something like this within the MIPI DSI API though- it looks like DSI controllers can either signal TE via a dedicated GPIO pin, or via a D-PHY trigger event on the DSI bus itself.

[danieldegrasse]

@Finomnis or @faxe1008, would either of you be willing to provide feedback on this PR?

[Finomnis]

Sure, but probably not within the next couple of days, due to short deadlines. Remind me again in a couple of days if I forget.

[Finomnis]

I'm a little confused here; the way this if statement is written, if every single frame is frame_incomplete = false, then the te_sync will only be active every other write call. Is that intended?

I feel like the else should be removed, and the if (!desc->frame_incomplete) should be an independent separate block that gets always executed regardless of the previous if block.

Feel free to correct my thoughts if I'm mistaken.

[danieldegrasse]

No, I think you are right here. We always want the next call after one with frame_incomplete = false to trigger a TE wait. I'll update this.

[danieldegrasse]

Updated

[Finomnis]

Looks good to me so far, although I didn't put the time into checking all the registers. But the general code doesn't seem wrong to me.

[danieldegrasse]

Can't approve my own PR, reassigning to @dleach02 as this touches NXP drivers

[Finomnis]

@danieldegrasse did you confirm with an osci that this is working properly?

[danieldegrasse]

@danieldegrasse did you confirm with an osci that this is working properly?

I have not with latest push (as I no longer have access to the hardware), but yes I have verified the TE signal delays as expected with a signal analyzer using the LVGL sample. That didn't expose the bug you caught because LVGL will only set frame_incomplete to false once every 10 frames in the default configuration (where the framebuffer is 10% of the screen size)