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.

DM8148 Port A overflow

Expert 2220 points
Other Parts Discussed in Thread: TVP7002

Hello,

I am using EZSDK 5.04.00.11 with the dm8148.

I am trying to get saLoopback to capture YUV 1080p 30 fps using discrete syncs. I am capturing directly from an imager. I had everything working on DM8168 and successfully created a V4L2 subdevice and am able to capture with it using the DM8168. I am now trying to do the same for dm8148. 

After I Dequeue the first image I get a "Port A overflowed", the capture driver tries to restart and then immediately hangs and times out. Is there a known cause for why this would happen? Is this too "heavy" of a use?

Thanks,

Ben

  • Hi,

    We are looking into this issue at our end.

    Regards,

    Hardik Shah

  • Hi Hardik,

    Do you know exactly what the issue is, I am going to try to debug the problem myself (I have the source). I am trying to narrow down the parameters that reproduce the problem. I am assuming it is the discrete syncing setup that causes the problem since it seems to work fine when I am connected to the TVP7002 and that uses embedded syncs. Any pointers as to what you think may be going on would be greatly appreciated. 

    Thanks,

    Ben

  • Hi,

    VIP Port overflow in case input to it is not proper. This normally happens because of signal integrity or decoder is not programmed properly. Only way out is to reset and restart the VIP port in case of overflow. Which PSP release version are you  using?

    Regards,

    Hardik Shah

  • Hi Hardik,

    I am using TI81XXPSP 04.04.00.01.patch2 checked out from the arago repo. After the overflow even the reset and restart of the video port is failing. When I try to restart I get a "VPSS_FVID2: contrl event 0x6 timeout " printout. I am capturing from an imager. The imager is getting initialized and v4l2 is getting set up exactly the same as my 8168 setup which works fine. Since 8168 and 8148 share the same kernel source, I build the kernel with 8168 parameters and it works, I build with the 8148 parameters and it doesn't. Any idea where I might have gone wrong? Could this possibly be a pinmux issue?

    Also, I am trying to understand my situation a little better so if you could just answer these quick questions:

    1. Is this a known issue with EZSDK 5.04.00.11 and/or PSP 4.04.00.01 patch2?

    2. Is there a known working EZSDK or psp combination that will support discrete sync capture of a 1080p30 image with 8148?

    3. If this is a known issues, do we know if it is a problem in the M3 source, VPDMA, or kernel?

    Your time is much appreciated,

    Ben