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.

Omap 35xx DSS lockup

Hello,

we use Omap 3515 which outputs GUI graphics over 30fps video on 1024x768 LCD display.

The GUI is 32bpp and may use POWERVR SGX for some operations:

Sometime we get the following messages from the 2.6.29 kernel:

 

isp_buf_process: Ouch - CCDC or resizer was busy.
ccdc 1 won't become idle!
ccdc 1 won't become idle!
isp_buf_process: Ouch - CCDC or resizer was busy.
ccdc 1 won't become idle!
isp_buf_process: Ouch - CCDC or resizer was busy.
isp_buf_process: Ouch - CCDC or resizer was busy.
ccdc 1 won't become idle!
ccdc 1 won't become idle!
isp_buf_process: Ouch - CCDC or resizer was busy.
ccdc 1 won't become idle!
ccdc 1 won't become idle!
isp_buf_process: Ouch - CCDC or resizer was busy.
ccdc 1 won't become idle!
isp_buf_process: Ouch - CCDC or resizer was busy.
ccdc 1 won't become idle!
isp_buf_process: Ouch - CCDC or resizer was busy.
isp_buf_process: Ouch - CCDC or resizer was busy.
isp_buf_process: Ouch - CCDC or resizer was busy.
ccdc 1 won't become idle!
isp_buf_process: Ouch - CCDC or resizer was busy.
isp_buf_process: Ouch - CCDC or resizer was busy.
ccdc 1 won't become idle!
isp_buf_process: Ouch - CCDC or resizer was busy.
isp_buf_process: Ouch - CCDC or resizer was busy.
omap-dss DISPC error: dispc irq error status 0460

After the last message, the kernel freezes and screen turns green. The 

status 0640 is from register DISPC_IRQSTATUS and two of the

bits set are VID1FIFOUNDERFLOW and GFXFIFOUNDERFLOW.

Is there any fix for this?

Martin

 

  • Hi Martin,

    You must be using camera interface, right? Or this could be due to Mem-to-Mem reiszer driver? Certainly it looks like you are hitting memory bandwidth related issue. Can you please provide further details in order to understand the use-case -

     - Are you using rotation on GFX OR Video or both?

    - On V4L2 side, how many buffers are you requesting?

    - Are you leveraging USRPTR mode of operation wherever possible and applicable?

    - How resizer driver is being used?

     

    Thanks,

    Vaibhav

  • Hi Vaibhav,

    yes, we use camera interface to capture 30 (or 25) frames per second. Frame sizes vary from 720x480 to 1024x720 depending on TV source.

    We are not using any rotation anywhere.

    There is one V4L2 app that captures the frames from camera interface and outputs them to DSS (display subsystem).  Initially (year ago) this app had few buffers for capture, few buffers for output, and used memcpy (copy by CPU) or resizer device (copy by DMA) to copy the frames from capture buffers to output buffers. Either way the initial app was wastefully copying all luma/chroma data.

    The current app uses 6 buffers that are created as memory-mapped buffers on output side and then also used as userptr buffers on capture side. The app starts by queueing all 6 buffers for capture, and starts capture streaming. Captured buffers are queued for  for DSS output. Once 3 buffers are queued for output we start output streaming.  Now the 6 buffers move around and there is no copying of luma/chroma data. I made a small fix to the omap kernel to make this work.

    The resizer may be used on the DSS side. For example. we want the 720x480 SDTV frames to fill the 1024x768 LCD screen,  so output V4L2 is setup to do the upscaling. The larger 1024x720 frame are not resized.

     

    I did not say in the initial post that the problem is rare. We may run continuously for days before it happens.  So when the kernel prints out

    omap-dss DISPC error: dispc irq error status 0460

    message, I would like reset/repair the whole DSS (LCD may freeze or flicker for a second, that's ok), and keep going. Right now, after the message, the kernel locks up and we need to reboot.

    Thanks, Martin