• State
  • Locked Locked
  • Replies 2 replies
  • Subscribers 98 subscribers
  • Views 468 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Display DMA synchronisation

Jeromert
Prodigy 40 points

Hello,

I'm having some problems when I start DMA transfers that write data into the display frame buffer. Sometimes short flicker can be seen, other times my DMA function returns a time-out after 1 second ( the DMA CSR register bit 5 is not set ). I'm sure that this is a problem related to DMA, because when I write pixel by pixel into the frame buffer, everything works fine.

In http://focus.ti.com/lit/ug/spruf98d/spruf98d.pdf, chapter 15.3.2.1.1
I have read, that there is a DMA synchronization line (DSS_LINE_TRIGGER) used to signalize when memory can be updated:

"One DMA synchronization line (DSS_LINE_TRIGGER) is connected to the sDMA by the sDMA controller
(S_DMA_5) input line. This DMA request is not a classical one but a synchronization signal from the
display subsystem to the sDMA informing the sDMA that a programmable number of lines are output to
the LCD, and that the system memory can be updated. This request is related to an interrupt event
described in Section 15.3.2.2, Interrupt Requests. This allows the sDMA channel to be synchronized with
the Display subsystem internal DMA controller. In other words, it allows to synchronize a memory to
memory frame buffer update based on the scan line of the frame buffer in system memory (SDRAM or
SRAM) by the display controller. The DSS_LINE_TRIGGER DMA request is generated at a programmable
line number defined in DSS.DISPC_LINE_NUMBER[10:0] LINENUMBER field."

I could not understand HOW to use this DMA line for synchronisation. Can you give me a hint ?
I have to write directly to the registers, because my application is not running on Windows or Linux.

Thanks in advance

Jerome

  • 0
    TI__Mastermind 43875 points

    Jerome,

    All this interrupt really does is trigger an interrupts at a desired line in the output video frame.  This is useful if you are using a single frame buffer (rather than double or triple buffering), and allows you to synchronize your own access to the frame buffer such that any changes you make do not cause tearing or (hopefully)flicker.

    Think of the following scenario...

    There is a chunk of memory that the display subsystem keeps reading over and over, sending the memory to your monitor. Let's say you want to render a mouse cursor into this memory, so you start changing the memory. If the DSS is initially reading from memory above your cursor, and when it reaches a location corresponding to half way through where you would like to display your cursor you start rendering the cursor. Now, the DSS will have already sent the frame buffer memory up to the mid point of where you would like your cursor to be displayed, but you have not started rendering it, so no cursor data will be displayed.

    Next, you start rendering your cursor into the frame buffer, which you can do very fast you will fill the frame buffer with your cursor, and will 'overtake' the memory address from which the DSS is reading. This means that the DSS will then continue reading the frame buffer, but by the time it gets  to the memory where you rendered your cursor it actually contains your cursor data, so it will send this information to your monitor.

    The result is that you will only see the bottom part of your mouse cursor even though you rendered the complete image to memory.

    If nothing new happens now, then the NEXT frame displayed by the DSS will show a complete cursor since it will already be there in memory, but if you move your mouse, hence need to erase the old image and render a new one, the same issue will occur.

    So, using the line interrupts allows you to pick a time relative to the DSS output memory scanning at which to start rendering your mouse such that your cursor memory writes never "overtake" the DSS memory reads, hence never cause the 'tearing' of the mouse image.

    The exact position of this interrupt really depends on lots of things, such as how long it takes you to render your image (if you are rendering a large video overlay it could take a long time for example), where on the screen you are rendering to, what the output video size and pixel rate are (this really just defines the relationship of what "a long time" really means) etc...

    Now, regarding the DMA... Have you tried simply initiating DMA transfers which are not synchronized, or using other DMA mechanisms, just to see if you can see a pattern?

    I do not know too much about the sDMA but will try to find out more information for you.

    BR,

    Steve

  • 0 in reply to Steve Clynes
    Prodigy 40 points

    Hello Steve,

    thank you for your information. Bad programming was the cause for the DMA errors ( multiple Task accessed one DMA channel without any protection ). There is also no more flicker visible.

    I would like to ask you some other questions:

    assuming the display controller reads data from all 3 channels (gfx, vid1, vid2) at full size (on my system 1024x768 pixel, ARGB color format); then 9,4 MB are read from memory each frame.

    Will this affect other applications that also transfer big amounts of data from/to memory?
    Will the transfer take more time?
    And, when is the maximum data transfer rate reached?

    Best regards

    Jerome