We are using a 4460 with an OV5640 sensor attached to CSIA and are not seeing the expected frame rate. Even when I increase the speed of the MIPI clock I do not see a change in the frame rate. First, I would like to verify that we are programming the PLLs in the sensor correctly to achieve the expected frame rate but I'm not sure how to make that calculations.
I am capturing YUV 422(2 bytes per pixels), VGA data using 2 MIPI data lanes. If I want to capture 30fps, what is the clock speed should I see if I measure it on the MIPI clock lane?
Second, can somebody tell me what the DDRCLK is when reference in the TRM in regards to how to program the ths_term and ths_settle fields in the CSI2 Phy REGISTER0 register. The TRM makes these references
ths_term = ceil(12.5 / DDR clock period) –1 ths_settle = ceil(90 ns / DDR clock period) + 3
Can you please tell me which kernel release you are using ? Is it V4L2 based capture ?
What is the frequency from OV5640 sensor, which you see when you probe the clock lane ?
What value do you see in ov5640_s_fmt() function for ov5640->pixel_rate->cur.val64 variable ?
If you are using V4L2 based kernel, can you tell me what is the value of DDR clock frequency ?
Please refer to omap4iss_csiphy_config function of "drivers/media/video/omap4iss/iss_csiphy.c" for the calculation.
Yes, doing v4l with a 2.6.30 kernel. The mipi_pclk is 112000000(this is the value returned by get_pclk) so what I see on the bus is 56000000. The cur.val64 is 7000000 and the ddr_clk is 28000. This is for 16bit per pixel VGA using 2 data lanes.
which sensor are you using and have you verified that the sensor is outputting at 30fps?
Please click the Verify Answer button on this post if it answers your question. ------------------------------------------------------------------------------------------------------------------
OV5640. We can't access the h/v sync pins on the sensor so cannot verify it on the sensor. That's why I'm trying to determine if the mipi clock is running fast enough to achieve the data rate I want. If yes, then I can look at other possibilities.
A rough calculation says you need at least 73MHz MIPI clock for VGA 30, 16bpp. This is assuming no H and V blanking, The clock you have set is too low.
I got some feedback from the sensor vendor and have modified the registers settings such that the clock rate is 114MHz. However, on the OMAP's side it seems to think it is running at 15fps. We are not dropping any incoming frames in the driver. When I get back in the office I will connect a scope to a gpio that is being toggled in the CSI's ISR to actually measure what the chip is seeing. Is there anything that I should be looking at to determine why I am not getting the expected frame rate?
Please validate frame rate using the scope. From SW standpoint here is something you can try:
1. Run camera_test from /system/bin. Usage is camera_test f
2. Press 'E' to print capabilities. Make sure that 30fps is supported.
3. If supported, adjust camera fps range to [30, 30] and start preview using camera_test menu options.
4. Measure the frame rate
Just to clarify. Is camera_test an android/openMAX application? Is the source for this somewhere in android tree?
It is a native (C++) app which uses Android CameraService APIs just like an android app will do. It is a little easier to debug and modify than Java code.
You can find the source in the folder hardware/ti/omap4xxx/test/CameraHal/
I am unable to run the camera test:
/system/bin/camera_test -f openCamera(camera_index=0)Unable to connect to CameraServiceRetrying... Giving up!! Camera initialization failedApplication closed after: 1014502 ms
I'm guessing this is because of these android logs:
logcat -d |busybox grep -i cameraI/CameraService( 108): CameraService started (pid=108)E/CameraHal( 108): (40079630) hardware/ti/omap4xxx/camera/OMXCameraAdapter/OMXDCC.cpp:99 initDCC - No DCC files found, switching back to default DCCE/CameraHal( 108): (40079630) hardware/ti/omap4xxx/camera/OMXCameraAdapter/OMXDCC.cpp:44 loadDCC - Error in DCC InitE/CameraHal( 108): (40079630) hardware/ti/omap4xxx/camera/BaseCameraAdapter.cpp:2682 CameraAdapter_Capabilities - supportedCameras= 0E/CameraHal( 108): (40079630) hardware/ti/omap4xxx/camera/CameraProperties.cpp:108 loadProperties - camera busy. properties not loaded. num_cameras = 0E/CameraHal( 108): (40079630) hardware/ti/omap4xxx/camera/CameraHal_Module.cpp:750 camera_get_number_of_cameras - Unable to create or initialize CameraPropertiesW/PackageManager( 280): Package com.ti.omap4.android.camera desires unavailable shared library com.google.android.media.effects; ignoring!E/CameraService( 108): CameraService::connect X (pid 805) rejected (invalid cameraId 0).E/CameraService( 108): CameraService::connect X (pid 805) rejected (invalid cameraId 0).E/CameraService( 108): CameraService::connect X (pid 818) rejected (invalid cameraId 0).
And the ducati logs indicate that it is looking for a OV5650:
[ 0.884] [ERR=22] src/sensor_detect_MSP.c::0>>:OV5650 Socket:0
and since we are using a 5640 there is no sensor detected. There is a OV5640 driver in the ducati source so I don't understand why it does not see it. We are using the pre-built ducati firmware that comes with the 4AJ.2.1 release:
[ 0.000] ***DUCATI VERSION INFO*** [ 0.000] Compile DATE Sep 27 2012 TIME 16:29:43 [ 0.000] GIT ducati_mmlegacy [ 0.000] BRANCH:(no branch) TAG:TI-MM-DUCATI_RLS_2.x.15.2 [ 0.000] COMMIT-ID:36d0068
Have you been using a non Ducati driver so far? camera_test works only with OMX Camera Adapter.
That is correct, we are using a V4L driver. When I disable the v4l driver and try to use the ducati firmware, it does not recognized the 5640 sensor. However, the ducati source code does have a driver for the 5640. Do I need to compile my own ducati firmware to recognize the OV5640 sensor?
Also, during the course of debugging, I plugged in a HDMI monitor and the camera will run at the expected frame rate. In fact, I can unplug/plug the HDMI cable and the camera frame rate will change between 15/30). Is the image subsystem connected to the display subsystem in some manner? Again, this is just with linux running, android has not been started yet.
Investigating the changes in behavior with a HDMI monitor connected let to the discover that the HDMI driver is changing the priority of the dma latency via pm_qos_add_request and PM_QOS_CPU_DMA_LATENCY. Adding calls to this function in the v4l driver at start stream resolved the issue
Congratulations. Please mark this post as closed.
All content and materials on this site are provided "as is". TI and its respective suppliers and providers of content make no representations about the suitability of these materials for any purpose and disclaim all warranties and conditions with regard to these materials, including but not limited to all implied warranties and conditions of merchantability, fitness for a particular purpose, title and non-infringement of any third party intellectual property right. TI and its respective suppliers and providers of content make no representations about the suitability of these materials for any purpose and disclaim all warranties and conditions with respect to these materials. No license, either express or implied, by estoppel or otherwise, is granted by TI. Use of the information on this site may require a license from a third party, or a license from TI.
TI is a global semiconductor design and manufacturing company. Innovate with 100,000+ analog ICs andembedded processors, along with software, tools and the industry’s largest sales/support staff.