I am working on a system based on the 3.1 DVSDK and a DM365/DM368 processor that includes a new sensor driver for a Micron/Aptina MT9J003 10-megapixel imager. The board being used is a Leopard EUSDK with the sensor changed out (and with the software updated to the 3.1 DVSDK linux). So far, I've got the sensor driver written and installed and I'm attempting to use the capture_prev_rsz_onthe_fly_bayer example code as a test application. I've found that there is one assumption in the VPFE area that doesn't work well for my setup so I've attempted to 'relax' it without breaking any surrounding code. I don't think I've broken anything by doing this but unfortunately I don't have a working system either .... sigh.
The problematic assumption is in the vpfe_s_crop routine (this lives in the vpfe_capture.c file). There is a block comment early on in the routine that explains this assumption. In a nutshell it says that when the image source is a camera any cropping is limited by the frame size of the sensor as set at device open or upon a S_FMT call. Just below this block comment is an "if" statement that supposedly implements this assumption. I have found it necessary to reverse the sense of the "if" since my camera has a frame of 3664x2752 and after device open those values are present in the active_pixels and active_lines fields of the vpfe_dev->std_info struct, These are what I'd like to have the system use as a limit but the way things are coded, it uses the frame size from the prevailing video std instead! By complementing the predicate of the "if" statement I get the behavior I need. So far, so good.
Unfortunately there is more to the story (or so I believe). There is also the assumption that cropping/scaling/binning is to be done in the sensor. Together with the image pipeline's resizer this can result in zooming and/or translation of the camera image. In order to get the best possible image quality and also the most capability in the overall system, I want to use a fairly simple-minded setup of the sensor (essentially using only 1x1 or 2x2 with binning and avoiding the use of the sensor's scaling capability completely). This means that I need to partition any cropping activity so that the translational part of it (which is true cropping within the sensor's available area) can be done in the sensor with the remaining resizing done in the IMP pipeline. Accordingly, I've inserted a call to the v4l2 sensor device's s_crop routine from within the vpfe_s_crop routine. Seems like it should have been called from there anyway, but wasn't. Once I do this I get the cropping I want happening at the sensor with something convenient like 720 pixel width and 480 pixel height coming back from the sensor to the resizer. I inserted this s_crop subdevice call just before the ccdc_dev->hw_ops.set_image_win() call in the middle of the vpfe_s_crop routine. Just after returning from the subdevice s_crop, I set the crop.left and crop.top to 0,0 (since that part of the cropping has already been handled in the sensor and we don't want the resizer to do any cropping with respect to what it is getting). What I hope will happen next is that the rest of the IMP pipeline code will get setup correctly.
What I'm seeing is that the sensor is setup correcly and it is delivering 30 fps with the correct cropping happening and with 720x480 (Bayer) pixels coming out. I can see this on a logic analyzer and together with I2C register dumps I can verify that the sensor is doing what I want. I can see the frame interrupts happening in the vpfe_isr for VINT0. What I'm *not* seeing, however, is the finishing of the capture. According to some kernel log printouts, there is no interrupt activity in the ISR vpfe_imp_dma_isr(). I have checked a lot of other related data items and the associated logic and, so far, I'm unable to see anything wrong .... yet the system just sits there waiting for the resizer to signal that it has finished its work. Meanwhile the sensor has gone on to the next frame and the next ... and the next.
Any suggestions or help on getting this to work would be greatly appreciated. I'd like to know, specifically how to check progress (perhaps by reading some hardware registers or looking at some other kernel data structures). Another question .... why is there no detection of a stall like I am getting? It seems like it would be preferable to have some sort of timer running. If the timer ran out well after the longest possible time for the expected interrupt then it could log an error and reset the hardware or something. Just leaving things stuck and hung is not a good thing and it makes it very tough to figure out what we are waiting on.
Any clarification as to what (exactly) I might be waiting on in this scenario? Any known bugs or fixes in this area? Any suggestions for reading some registers to determine the progress made before the hang? Anything along these lines would be very helpful.
Thanks in advance
Steve B