On Sun, 04 Oct 2009 17:36:55 +0200 Hans de Goede <hdegoede@xxxxxxxxxx> wrote: > As Jean-Francois very correctly pointed out, but no worries. The > handling of isoc irq's is serialised elsewhere in the kernel, the > issue of what James is seeing is much simpler. > > When we call gspca_frame_add, it returns a pointer to the frame > passed in, unless we call it with LAST_PACKET, when it will return a > pointer to a new frame in to whoch store the frame data for the next > frame. So whenever calling: > gspca_frame_add(gspca_dev, LAST_PACKET, frame, data, len); > we should do this as: > frame = gspca_frame_add(gspca_dev, LAST_PACKET, frame, data, len); > > So that any further data got from of the pkt we are handling in > pkt_scan, goes to the next frame. > > We are not doing this in stv06xx.c pkt_scan method, which the cause > of what James is seeing. So I started checking all drivers, and we > are not doing this either in ov519.c when handling an ov518 bridge. > So now the framerate of my 3 ov518 test cams has just doubled. Thanks > James! > > I'll send a patch with the fix in a separate mail. Hello Hans, Thank you for the patch. Yes, it was simple and I should have seen it before! I think this problem could be avoided if the frame pointer is not given to the pkt_scan function (if the subdriver needs it, it is returned by gspca_get_i_frame). Best regards. -- Ken ar c'hentañ | ** Breizh ha Linux atav! ** Jef | http://moinejf.free.fr/ -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
