DM3730 resizer is slow

This seems very high, there could be various parameters which may contributing to this, like

 - ISP module Clock configuration?

 - Pixel clock?

 - How are you serializing whole use-case? Bottleneck could be due to wrong serialization?

 - Have you profiled Resizer interrupt? How did you come to this ~47ms value?

 - Not sure about your use-case here, but the whole objective here is to display the image, you can also make use of Display Resizer available @ Video1 and Video2 planes.

 -May also need to check from system performance perspective?

Also, since you are already using Previewer module in on-the-fly mode, why can't you try Resizer module also in the same mode.

CCDC=>Previewer=>Resizer=>Memory

Another point I would like to share here, till PSP03.00.01.06 release, we were supporting Resizer driver and were providing performance data as well. Just for reference you can refer to the below wiki page, will give you some idea about Resizer performance.

http://processors.wiki.ti.com/index.php/AM35x-OMAP35x-PSP_03.00.01.06_Feature_Performance_Guide#Performance_and_Benchmarks_5

Thanks,

Vaibhav

Viabhav,

Thanks for your response - here's the answer to your questions, along with a few more of my own:

Vaibhav Hiremath said:

This seems very high, there could be various parameters which may contributing to this, like

 - ISP module Clock configuration?

I think the ISP module is clocked by the L3_ICLK, right?  I believe my L3_ICLK is running at 216 MHz.  I have not done anything different with the clocking scheme as it was on the DM3730 EVM.  Is it possible to clock the ISP faster?  If so, how would I go about doing that?

 - Pixel clock?

My pixel clock is 78.75 MHz, but I'd like to go faster (~92 MHz).

 - How are you serializing whole use-case? Bottleneck could be due to wrong serialization?

I'm not sure what you mean by this, please clarify.

 - Have you profiled Resizer interrupt? How did you come to this ~47ms value?

I'm using the timer functions provided by the DMAI interface.  47 ms is the time it takes for the RSZ_RESIZE ioctl to return.

 - Not sure about your use-case here, but the whole objective here is to display the image, you can also make use of Display Resizer available @ Video1 and Video2 planes.

I need to also encode the resized video to an H.264 file, so I'm afraid this won't be any help

 -May also need to check from system performance perspective?

The system is very basic right now.  All it should be doing is taking in frames, running them through the previewer, then resizer, then display.

Also, since you are already using Previewer module in on-the-fly mode, why can't you try Resizer module also in the same mode.

CCDC=>Previewer=>Resizer=>Memory

I need to be able to finely control the resizer parameters (for digital zoom).  I also may have the need to multi-pass the resizer.  My understanding is that on-the-fly mode doesn't actually work.  It looks like there are memcpy's in the ISP driver to get around this issue.  I'd be interested in the on-the-fly mode if this reduced my memory bandwidth needs.

Another point I would like to share here, till PSP03.00.01.06 release, we were supporting Resizer driver and were providing performance data as well. Just for reference you can refer to the below wiki page, will give you some idea about Resizer performance.

http://processors.wiki.ti.com/index.php/AM35x-OMAP35x-PSP_03.00.01.06_Feature_Performance_Guide#Performance_and_Benchmarks_5

Thanks,

Vaibhav

I tried reducing the size of my input image - I'm taking in 1104x612 and resizing that up to 1280x720.  I thought that by taking in less data (and asking the resizer to deal with less data) that it would help the issue.  The resizer is indeed running faster (I haven't timed it, but I know its fast enough to keep up with my 30 fps input), but I'm back to getting SBL overflows whenever I try to use my digital zoom functionality.  For example, if I put in a 352x198 image into the resizer and try to upscale it to 1280x720, I get this message REPEATEDLY:

omap3isp omap3isp: omap34xx_isp_isr: sbl overflow, sbl_pcr = 00400000

I've tried playing with the SBL_SDR_REQ_EXP register to try and prevent these overflows but I can't seem to get them to stop.

I've been working with this part for 4 months now and I can't understand why it won't do a simple preview and resize application with a CMOS sensor... what am I missing here???

Thanks,

Jason

I did see that a new DVSDK for this part was just recently released.  I'd really appreciate an answer to these questions regarding the new DVSDK:

1.)    I’m currently using version 2.6.32 kernel with DVSDK 4.02.00.06.  Is there a significant advantage for me to move to the 2.6.37 kernel in the newly release DVSDK 4.03.00.06?  There is the new Media Controller Framework in this new kernel, which looks like a much cleaner and efficient way of capturing data from a CMOS sensor. 

2.)    Could this new kernel alleviate the “SBL overflow” issues that I’m constantly having?

3.)    Does this new kernel allow me to access previewer and resizer in user space?  If the answer is no, can I configure the previewer and resizer params from user space so that I can change them on the fly?

Thanks,

Jason

Vaibhav,

I'm trying to go back and use your suggestion of on-the-fly mode for the resizer.  By default in the 2.6.32 kernel distributed with PSP 3.00.01.06, the pipeline is set up as CCDC->PREV->MEM->RSZ->MEM.  I made the changes to set it up for CCDC->PREV->RSZ->MEM.  However, when doing this I get an incorrect image as shown in the attachment to this post. 

There are several comments in isp.c regarding a workaround stemming from the OMAP3430 errata.  The exact comment is:

ISP MMU mapped temporary buffer address used for 34xx Workaround
 *           for CCDC->PRV->RSZ datapath errata.

I do not see any related issue in the DM3730 errata.  My question is does the DM3730 have this same problem that requires the workaround?  Or is the driver just not set up correctly for on-the-fly resizer?  I think on-the-fly mode would really help meet my frame rate requirement.

Thank you,

Jason

Jason,

Did you ever get an answer to this question? I'm running into similar issues...

Thanks,

Rick