• State Resolved
  • Locked Locked
  • Replies 5 replies
  • Subscribers 99 subscribers
  • Views 712 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.

Calculating LCD controllers DMA bandwidth

John Conover
Genius 4350 points

Hi,

     We are currently using the AM335x SDK under StarterWare running the grlib example which uses a 24BPP frame buffer and runs LCD controller in Raster mode. We are trying to calculate the bus bandwidth that the LCD DMAs are consuming. The Technical reference manual in section 13.4.3.1 mentions in raster mode at the end of the frame (of frame buffer 0) the DMA does not stop but either goes over to frame buffer1 or begins again at frame buffer 0. This seems to suggest that there is always a frame buffer DMA happening regardless of whether there have been changes to the buffer or not. This concerns us as we have sensor data coming in on EDMA3 Channel Controllers that need to be a higher priority. So could someone from TI(or well versed in the DMA workings of the 3359) tell us:

- Are the LCD DMAs going all the time in raster mode? If so can they be changed to only occur on frame buffer modifications?

- Is there a way to give the EDMA controller priority over the LCD DMA?

Thanks,

     John C.

  • 0
    Guru 31670 points

    John,

    AM335x LCD controller has two modes of operation as you might already be aware. One is raster and another LIDD or RFBI interface. If its raster, there will be a DMA operation always on going except for the sync pulse intervals. Also this doesn't mean that bus is always occupied by the LCD controller. The DMA operation is performed in small bursts of 32bytes(not sure about the exact number in AM335x). So the bus will still be available for others. 

    If you use LIDD mode then you can reduce the bandwidth consumed by doing a write to the remote frame buffer only when the current framebuffer becomes dirty. I think you've to add support for this in your code. 

  • 0 in reply to Renjith Thomas
    Genius 4350 points

    Renjith,

         Thanks for the information. The technical document suggested this was the case but was not clear. Is there another section or document that describes how much data is configured during the DMA transfer? Section 13.3.7 say "The DMA parses the frame buffer according to the frame buffer type and supplies the raster processing chain with Palette information and pixel data as needed". There is section 13.4.4 on Palette Lookup which breaks down bpp vs. Palette and DMA but never makes clear what the DMA sizes would be for 24bpp. A simple table of:

    1 bpp DMA data size

    2 bpp DMA data size

    ...

    24 bpp DMA data size

         Is there any place I could find this info.

    Thanks again,

         John C.

  • 0 in reply to John Conover
    Guru 31670 points

    John,

    Have you checked the LCDDMA_CTRL register in LCD controller chapter?

  • 0 in reply to Renjith Thomas
    Genius 4350 points

    Renjith,

         Thanks for the info. It looks like almost all the StarterWare examples use a burst size of 16. I'm assuming that because the register note says "(all DMA transfers are 32 bits
    wide)" a burst size of 16 means 16*4bytes = 64 byte burst.

    John C.

  • 0 in reply to John Conover
    Guru 31670 points

    John,

    Your assumption is correct.