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.

OMAP3530 ISP - CCDC memory to Preview(without VP port)

Other Parts Discussed in Thread: OMAP3530

Hi All,

I am using OMAP3530 with ISP for video capture using the kernel 2.6.22 kernel.

I have used the 2.6.22 ISP driver in the following pipeline method:

Camera Sensor -> ISPCCDC->VP port MEMORY->Preview->Resizer.

The above pipeline stage is working fine. 

But our requirement is use the ISP without VP port and using the following pipeline stage

Camera Sensor -> ISPCCDC->Others MEMORY->Preview->Resizer. ( Video Port is not used).

This method is not working. I am not able to get preview done and resize interrupts from ISP port.  Is there any restiction that the above pipeline will not work?. OR any other suggestions are welcome.

Thanks in advance

Senthil

 

 

 

 

  • senthilnathan KS said:
    I am using OMAP3530 with ISP for video capture using the kernel 2.6.22 kernel.

    This is a bit of an old kernel, so you may find support is limited, the PSP kernel released back then does not appear to have had official previewer/resizer support.

    senthilnathan KS said:

    I have used the 2.6.22 ISP driver in the following pipeline method:

    Camera Sensor -> ISPCCDC->VP port MEMORY->Preview->Resizer.

    The above pipeline stage is working fine. 

    But our requirement is use the ISP without VP port and using the following pipeline stage

    Camera Sensor -> ISPCCDC->Others MEMORY->Preview->Resizer. ( Video Port is not used).

    To better understand the situation, it sounds like you are trying to output the image into memory before performing the preview and resize operations? I am curious why you need it to operate in this fashion, perhaps some software processing on the raw image?

    senthilnathan KS said:
    This method is not working. I am not able to get preview done and resize interrupts from ISP port.  Is there any restiction that the above pipeline will not work?. OR any other suggestions are welcome.

    You should be able to invoke the previewer and resizer on their own from a hardware standpoint, the current PSP based on kernel 2.6.26 has a resizer driver that can operate independently on images in memory. Unfortunately I do not know of any software for leveraging the previewer on data in memory, the only previewer code I am aware of is in the camera driver itself and only works on the fly.

  • Hi Thompson,

    We are using the custom OMAP3530 camera board with camera sensor connected using serial cable(LVDS mode) to OMAP3530.

    The actual issue we are facing with ISP 2.6.22 kernel is whenever there is a EMI disturbance near the Camera cable(LVDS cable), the video image running at 30 fps, got split and color of the image skewed. The video continuous with split and color skew. It is not recovering from this corrupted scenario.

    Please find the attached video snapshot after the issue occurred. We are trying to find and isolate which part of ISP hardware generates the image split and color skew. We have tried the following steps to find the issue.

    1. Disabled the preview and resizer stages. Still video image splits.

    i.e, Camera Sensor->CCDC(through VP port)->memory->to display device ==> image split.

    2. Then bypassed the VP, Resize and Preview and used only CCDC to memory. This time we are not seeing any image split at all. We have induces heavy EMI over the sensor LVDS cable, there is no image split at all.

    i.e, Camera Sensor->CCDC(bypass VP port)->memory        ==> works fine.(no image split)

    Thus we feel that the issue due to Video port configuration.  We then tried to enable/disable the video port bit in the ISP CCDC registers, whenever there is an EMI disturbance, but image still split. It looks we have to totally avoid the Video Port and we need the ISP pipeline stage as shown below

    i.e, Camera Sensor->CCDC(bypass VP port)->memory ->Preview->memory->Resize->memory

    Without VP port configuration, the above pipeline implementation is not working and it is not generating the preview and re-size interrupts.

    If we get any suggestions to use the ISP pipeline stages without VP port, it may help to solve the issue.

    Thanks

    Senthil

  • Hi Thompson,

    We are using the custom OMAP3530 camera board with camera sensor connected using serial cable(LVDS mode) to OMAP3530.

    The actual issue we are facing with ISP 2.6.22 kernel is whenever there is a EMI disturbance near the Camera cable(LVDS cable), the video image running at 30 fps, got split and color of the image skewed. The video continuous with split and color skew. It is not recovering from this corrupted scenario.

    Please find the attached video snapshot after the issue occurred. We are trying to find and isolate which part of ISP hardware generates the image split and color skew. We have tried the following steps to find the issue.

    1. Disabled the preview and resizer stages. Still video image splits.

    i.e, Camera Sensor->CCDC(through VP port)->memory->to display device ==> image split.

    2. Then bypassed the VP, Resize and Preview and used only CCDC to memory. This time we are not seeing any image split at all. We have induces heavy EMI over the sensor LVDS cable, there is no image split at all.

    i.e, Camera Sensor->CCDC(bypass VP port)->memory        ==> works fine.(no image split)

    Thus we feel that the issue due to Video port configuration.  We then tried to enable/disable the video port bit in the ISP CCDC registers, whenever there is an EMI disturbance, but image still split. It looks we have to totally avoid the Video Port and we need the ISP pipeline stage as shown below

    i.e, Camera Sensor->CCDC(bypass VP port)->memory ->Preview->memory->Resize->memory

    Without VP port configuration, the above pipeline implementation is not working and it is not generating the preview and re-size interrupts.

    If we get any suggestions to use the ISP pipeline stages without VP port, it may help to solve the issue.

    Thanks

    Senthil

     

     

     

  • senthilnathan KS said:
    We are using the custom OMAP3530 camera board with camera sensor connected using serial cable(LVDS mode) to OMAP3530.

    There are no serial camera inputs on the OMAP35xx series (though there are on the similar OMAP34xx series) so I imagine you have some deserializer outside of the OMAP to interface with the parallel camera input? If this is the case than that part may also be suspect.

    senthilnathan KS said:

    2. Then bypassed the VP, Resize and Preview and used only CCDC to memory. This time we are not seeing any image split at all. We have induces heavy EMI over the sensor LVDS cable, there is no image split at all.

    i.e, Camera Sensor->CCDC(bypass VP port)->memory        ==> works fine.(no image split)

    Thus we feel that the issue due to Video port configuration.  We then tried to enable/disable the video port bit in the ISP CCDC registers, whenever there is an EMI disturbance, but image still split. It looks we have to totally avoid the Video Port and we need the ISP pipeline stage as shown below

    Your testing sounds ok, but I do not see how bypassing the VP, previewer and resizer would prevent this sort of issue since a split like this indicates an offset vertical sync in some form, the internal VP formatter should be forced in sync with the rest of the capture hardware. I imagine you have run the test with the VP formatter bypassed several times to ensure that it is really fixing the problem?

    I am curious if the split is always in the same vertical position or if it is randomly placed on the display?

    senthilnathan KS said:
    Without VP port configuration, the above pipeline implementation is not working and it is not generating the preview and re-size interrupts.

    If you are working from memory than the previewer/resizer need to be initialized and synchronized by software, are you saying that you are not getting completion interrupts? I imagine you have modified the ISP_IRQxENABLE register of your choice to allow the previewer and resizer interrupts to fire?

  • Ans:-

    We used deserializer in between camera sensor and ISP port.The image is always splits in vertical position as in the attached picture.

    ==================

    After doing several testing, We and the TI team came to a conclusion that the VP ( video port which is part of CCDC module) is not properly synchronizing and resulting image split.

    Thus we decided to disable/bypass the video port by using the following pipeline stage

    sensor->ISP port->CCDC(bypass Video Port)->memory->preview->memory->resizer->memory.  

    The kernels 2.6.22 and 2.6.29 ISP drivers are not implementing the above ISP pipeline stage. We have tried to bypass the video port in the 2.6.22 ISP driver. But we are not getting the preview and resize completion interrupts and we have enabled all the interrupts in the ISP_IRQxENABLE register.

    Any suggestion to solve this issue OR solution for the above pipeline stage OR any latest kernel which supporting this feature will help us to fix the issue ASAP. 

     

    Thanks in advance

    Senthil

     

     

  • senthilnathan KS said:
    After doing several testing, We and the TI team came to a conclusion that the VP ( video port which is part of CCDC module) is not properly synchronizing and resulting image split.

    This is an interesting prospect, I was under the impression that the synchronization between the video port formatter and the capture interface itself would be fixed in hardware, so if this is the case it sounds like a silicon errata for the capture port. I imagine the TI team you are working with is taking care of verifying this and feeding it back internally.

    As to actually making the interrupts work I am not sure what to say, the only ISP specific portion is the ISP_IRQxENABLE register which should allow you to enable the interrupts for the completion events, everything beyond that would be at the higher level interrupt context, i.e. making sure interrupts are actually enabled and you have an ISR to handle when the event happens. I suspect this would require digging further into how the capture driver handles interrupt events, it may be getting the event for the completions and ignoring it.