Double buffering for a display driver on imx8m

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

Double buffering for a display driver on imx8m

118 Views
TomHarvey
Contributor I

Hi All,

Apologies if this is the wrong place to post this, please direct me elsewhere if that is the case.

Throughout this question i shall reference the following specification "i.MX 8M Dual/8M QuadLite/8M Quad Applications Processors Reference Manual"


I'm currently developing a display driver for the imx8m. To display moving images I have implemented double buffering using the context loader (15.4 Context Load (CTX_LD)).

The idea is that whilst the current frame is being displayed, the next frame buffer is being written to. I have set up the context loader to switch the address of the frame buffer each time the context loader is run. The memory register I have set up to use in the context loader is DPR_1_FRAME_1P_BASE_ADDR_CTRL0 (15.7.3.1.38)

The issue I'm facing is that each time it switches frames i can see a visible redraw of the screen. As far as I am aware, this issue isn't anything to do with tearing as I have pre written each buffer and as a proof of concept I am just switching between displaying the two with no writing in between. The visible redraw can't easily be seen with the naked eye, but it results in a slight "jitteryness" when switching frames.

I currently use double buffering to achieve this, which states in the documentation (15.4.2 Functional Description) that double buffered registers "require their next state to be loaded into shadow registers during the active display time". I have attempted to use single buffering which seems more suitable by the definition "require the next state to be loaded during the vertical blanking time". But i get the same affect as with double buffered registers with the screen intermittently flickering to black.

Just to confirm - I am successfully displaying two different screen states one after another with the context loader, but the issue is that when switching to the next display state it will visibly redraw the screen from the top, resulting in a subtle visual glitch. The position of the draw is consistent with each context switch.

It seems to be that my display timing settings must not be set up correctly, but I am having trouble figuring out exactly what is missing from my setup. My understanding of the context loader is that it automates the process of changing the display from one state to another, leveraging the timing signals from the Display Timing Generator (15.3 Display Timing Generator).

For the Display Timing generator (DTG) I have set up the following memory registers as per the example (15.3.2.4 DTG Programming Example

  • 15.3.3.1.3 DTG lower right corner locations (TC_DTG_REG1)
  • 15.3.3.1.4 Display Register: TOP Window Coordinates for Active display area (TC_DISPLAY_REG2)
  • 15.3.3.1.5 Display Register: BOTTOM Window Coordinates for Activedisplay area (TC_DISPLAY_REG3)
  • 15.3.3.1.6 Channel 1 window Register: TOP Window Coordinates forchannel1 (TC_CH1_REG4)
  • 15.3.3.1.7 Channel_1 window Register: BOTTOM Window Coordinates forchannel_1 window (TC_CH1_REG5)

 

When following the example it does not work as expected, so I have looked at the linux and uboot implementations of this driver and have taken inspiration from the values they use to set these memory registers which are different to what is written in the spec. When using these settings it works in displaying my image correctly formatted on the screen.

I have also played around with values in the following memory register, which is clearly important for this to work:

  • 15.3.3.1.12 Context Loader Register: Coordinates in the raster table wherethe context loader is started. (TC_CTX_LD_REG10)


I have done the same for the subsampler following the example, which works as expected without any deviation from the spec:

  • 15.11.3.1.10 (SS_HSYNC)
  • 15.11.3.1.14 (SS_VSYNC)
  • 15.11.3.1.18 (SS_DE_ULC)
  • 15.11.3.1.22 (SS_DE_LRC)

I understand that there are many other parts of the setup that I have not included here that could affect things. But I'm reaching out on this forum just to get some clarification or potential guidance on the following points:

  • Can the context loader be used for double buffering so that whilst one frame is being written to the other is being displayed. If this is the case, am i changing the correct register()? Should this use single or double buffered registers?
  • I have a feeling that the context loader is working as expected, but it isn't changing in the vertical blanking region. If this is the case, will i need to configure the DTG differently?
  • I am currently not using interrupts for this and I am relying on polling the context loader as described in (15.4.2.2 Display State Loading Sequence). Is it necessary to set up any interrupts from the DTG, or should this all be possible polling the context loader?

 

If anyone has any advice on this, it would be greatly appreicated. Thanks,

Tom

 

0 Kudos
2 Replies

90 Views
Bio_TICFSL
NXP TechSupport
NXP TechSupport

Hello,

What are you using? Linux? Android? this could be a bug in our current bsp.

regards

0 Kudos

66 Views
TomHarvey
Contributor I

Hello, Thanks for the quick response.

I'm trying to write my own bare metal driver so im not using any bsp.

Kind regards, 

Tom

0 Kudos