cafe_ccic slowness in VIDIOC_S_FMT

Dan Williams dcbw at redhat.com
Sat Jul 7 20:30:53 EDT 2007


Hi,

The gstreamer is taking a long time to start the pipeline, so I put some
debugging info into the v4l2 source.  Here's what I got:

0:00:02.403650000 v4l2src v4l2src_calls.c:874:gst_v4l2src_set_capture:<v4l2src0> V4L2SRC: Setting capture format to 640x480, format YUYV
0:00:02.403785000 v4l2src v4l2src_calls.c:887:gst_v4l2src_set_capture:<v4l2src0> *** VIDIOC_G_FMT: 22 microseconds
0:00:06.059932000 v4l2src v4l2src_calls.c:901:gst_v4l2src_set_capture:<v4l2src0> *** VIDIOC_S_FMT: 3655992 microseconds
0:00:06.061419000 v4l2src v4l2src_calls.c:916:gst_v4l2src_set_capture:<v4l2src0> *** VIDIOC_G_PARM: 1313 microseconds
0:00:06.082901000 v4l2src v4l2src_calls.c:927:gst_v4l2src_set_capture:<v4l2src0> *** VIDIOC_S_PARM: 21368 microseconds
0:00:06.083023000 v4l2src v4l2src_calls.c:1014:gst_v4l2src_capture_init:<v4l2src0> initializing the capture system
0:00:06.083127000 v4l2src v4l2src_calls.c:1023:gst_v4l2src_capture_init:<v4l2src0> *** calling REQBUFS, requested 2 buffers
0:00:06.088328000 v4l2src v4l2src_calls.c:1028:gst_v4l2src_capture_init:<v4l2src0> *** called REQBUFS, got 6 buffers

So here you see that calling VIDIOC_S_FMT takes 3655992 microseconds,
which is a _really_ long time.  Turns out that cafe_cam_configure() from
s_fmt_cap() takes 378 jiffies.  Breaking this down, the pieces of
cafe_cam_configure() and the jiffies they take are:

INT_INIT:  301352 -> 301682  (330)
S_FMT:     301682 -> 301725  ( 43)
set_flip:  301725 -> 301729  (  4)

All INT_INIT does is write the default registers to the chip, which is a
lot of calls to (eventually) i2c_smbus_xfer() in drivers/i2c/i2c-core.c.
I'm not sure where it goes after that.  I assume that each call probably
does an mdelay or something.  Is there anything that can be done to
batch these register writes together, or cut down the time that calling
cafe_cam_configure() will take?  It takes a _really_ long time to set up
for streaming capture as seen from userspace...

Thanks,
Dan





More information about the Devel mailing list