litmus-rt.git - The LITMUS^RT kernel.

	Commit message (Collapse)	Author	Age
*	V4L/DVB (13453): gspca - all subdrivers: Remove the unused frame ptr from ↵	Jean-Francois Moine	2009-12-05
\| \| \| \| \| \| \|	pkt_scan(). Signed-off-by: Jean-Francois Moine <moinejf@free.fr> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
*	V4L/DVB (13140): gspca_jeilinj: once one frame is discarded it keeps ↵	Hans de Goede	2009-12-05
\| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \|	discarding all frames While checking all gspca sub drivers pkt_scan functions for a bug I found in 1 of them (and after checking also in another), I noticed a bug in the gspca_jeilinj work queue function, once it has decided to start discard a frame because the application is not reading fast enough (and thus returning buffers to fill fast enough), it never stops discarding. This patch fixes this by simply completely removing the "discarding" variable, if we need to discard the current frame because there is no buffer to store it, the "frame" pointer will be NULL, so that is all we need to check. I've also moved the gspca_get_i_frame() call and the writing of the jpg header to the buffer to after the first usb_bulk_msg() call, as we don't need it before that, and that will give the app slightly more time to queue a buffer for us to fill. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
*	V4L/DVB (13017): gspca: kmalloc failure ignored in sd_start()	Roel Kluin	2009-09-18
\| \| \| \| \| \| \| \| \|	Prevent NULL dereference if kmalloc() fails. Cc: Jean-Francois Moine <moinejf@free.fr> Signed-off-by: Roel Kluin <roel.kluin@gmail.com> Signed-off-by: Douglas Schilling Landgraf <dougsland@redhat.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
*	V4L/DVB (12459): gspca - jeilinj: New subdriver for Jeilin chip.	Theodore Kilgore	2009-09-12
	Signed-off-by: Theodore Kilgore <kilgota@auburn.edu> Signed-off-by: Jean-Francois Moine <moinejf@free.fr> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>