- 20 May, 2011 40 commits
-
-
Dan Carpenter authored
This function returns NULL on failure so lets do that if kzalloc() fails. There is a separate problem that the caller for this function doesn't check for errors... Signed-off-by:
Dan Carpenter <error27@gmail.com> Acked-By:
Mike Isely <isely@pobox.com> Signed-off-by:
Mauro Carvalho Chehab <mchehab@redhat.com>
-
Timothy Lee authored
This card has a TD18271 silicon tuner, and uses TDA8290 and LGS8G75 to demodulate analog and digital broadcast respectively. GPIO configurations were derived using DScaler regspy. Signed-off-by: -
Jean Delvare authored
The ability to force the encoder or decoder chip was broken by commit 0ab6e1c3 in February 2009. As nobody complained for over 2 years, I take it that these parameters were no longer used so we can simply drop them. Signed-off-by:
Jean Delvare <khali@linux-fr.org> Cc: Hans Verkuil <hverkuil@xs4all.nl> Signed-off-by:
-
Florian Mickler authored
usb_control_msg initiates (and waits for completion of) a dma transfer using the supplied buffer. That buffer thus has to be seperately allocated on the heap. In lib/dma_debug.c the function check_for_stack even warns about it: WARNING: at lib/dma-debug.c:866 check_for_stack Tested-by:
Malcolm Priestley <tvboxspy@gmail.com> Signed-off-by:
Florian Mickler <florian@mickler.org> Signed-off-by:
-
Florian Mickler authored
usb_control_msg initiates (and waits for completion of) a dma transfer using the supplied buffer. That buffer thus has to be seperately allocated on the heap. In lib/dma_debug.c the function check_for_stack even warns about it: WARNING: at lib/dma-debug.c:866 check_for_stack Signed-off-by:
Antti Palosaari <crope@iki.fi> Reviewed-by:
-
Florian Mickler authored
usb_control_msg initiates (and waits for completion of) a dma transfer using the supplied buffer. That buffer thus has to be seperately allocated on the heap. In lib/dma_debug.c the function check_for_stack even warns about it: WARNING: at lib/dma-debug.c:866 check_for_stack Signed-off-by:
-
Florian Mickler authored
usb_control_msg initiates (and waits for completion of) a dma transfer using the supplied buffer. That buffer thus has to be seperately allocated on the heap. In lib/dma_debug.c the function check_for_stack even warns about it: WARNING: at lib/dma-debug.c:866 check_for_stack Signed-off-by:
-
Florian Mickler authored
Note: This change is tested to compile only as I don't have the hardware. Signed-off-by:
-
Florian Mickler authored
If we need a bigger buffer, we reallocte a new buffer and free the old one. Note: This change is tested to compile only as I don't have the hardware. Signed-off-by:
-
Florian Mickler authored
Note: This change is tested to compile only as I don't have the hardware. Signed-off-by:
-
Florian Mickler authored
Otherwise it is not obvious that vp702x_usb_in_op or vp702x_usb_out_op will not interfere with any vp702x_usb_inout_op. Note: This change is tested to compile only, as I don't have the hardware. Signed-off-by:
-
Florian Mickler authored
usb_control_msg initiates (and waits for completion of) a dma transfer using the supplied buffer. That buffer thus has to be seperately allocated on the heap. In lib/dma_debug.c the function check_for_stack even warns about it: WARNING: at lib/dma-debug.c:866 check_for_stack Note: This change is tested to compile only, as I don't have the hardware. Signed-off-by:
-
Florian Mickler authored
struct vp702x_device_state.power_state is nowhere referenced. Signed-off-by:
-
Florian Mickler authored
This sets up a buffer and a mutex protecting that buffer in the struct vp702x_device_state. The definition of struct vp702x_device_state is moved into the header in order to use the buffer also in the frontend. Signed-off-by:
-
Florian Mickler authored
We need a state struct for the dvb_usb_device. In order to reduce confusion we rename the vp702x_state struct. Signed-off-by:
-
Florian Mickler authored
Some whitespace, one linebreak and one unneded variable initialization... Signed-off-by:
-
Florian Mickler authored
usb_control_msg initiates (and waits for completion of) a dma transfer using the supplied buffer. That buffer thus has to be seperately allocated on the heap. In lib/dma_debug.c the function check_for_stack even warns about it: WARNING: at lib/dma-debug.c:866 check_for_stack Note: This change is tested to compile only, as I don't have the hardware. Signed-off-by:
-
Florian Mickler authored
usb_control_msg initiates (and waits for completion of) a dma transfer using the supplied buffer. That buffer thus has to be seperately allocated on the heap. In lib/dma_debug.c the function check_for_stack even warns about it: WARNING: at lib/dma-debug.c:866 check_for_stack Note: This change is tested to compile only, as I don't have the hardware. Signed-off-by:
-
Florian Mickler authored
usb_control_msg initiates (and waits for completion of) a dma transfer using the supplied buffer. That buffer thus has to be seperately allocated on the heap. In lib/dma_debug.c the function check_for_stack even warns about it: WARNING: at lib/dma-debug.c:866 check_for_stack Note: This change is tested to compile only, as I don't have the hardware. Signed-off-by:
-
Florian Mickler authored
usb_control_msg initiates (and waits for completion of) a dma transfer using the supplied buffer. That buffer thus has to be seperately allocated on the heap. In lib/dma_debug.c the function check_for_stack even warns about it: WARNING: at lib/dma-debug.c:866 check_for_stack Note: This change is tested to compile only, as I don't have the hardware. Signed-off-by:
-
Florian Mickler authored
Signed-off-by: -
Florian Mickler authored
usb_control_msg initiates (and waits for completion of) a dma transfer using the supplied buffer. That buffer thus has to be seperately allocated on the heap. In lib/dma_debug.c the function check_for_stack even warns about it: WARNING: at lib/dma-debug.c:866 check_for_stack Note: This change is tested to compile only, as I don't have the hardware. Signed-off-by:
-
Florian Mickler authored
This variable is never used. Signed-off-by:
-
Olivier Grenie authored
This patch removes the on-stack buffers for USB DMA transfers. This is an alternative version of the patch discussed by Florian here: http://thread.gmane.org/gmane.linux.kernel/1115695/Signed-off-by:
Olivier Grenie <olivier.grenie@dibcom.fr> Signed-off-by:
Patrick Boettcher <patrick.boettcher@dibcom.fr> Signed-off-by:
-
Florian Mickler authored
This should not change anything except whitespace. Signed-off-by:
-
Michael Jones authored
It only contains generated files Signed-off-by:
Michael Jones <michael.jones@matrix-vision.de> Acked-by:
Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by:
-
Joonyoung Shim authored
Signed-off-by:
Joonyoung Shim <jy0922.shim@samsung.com> Signed-off-by:
-
Joonyoung Shim authored
Signed-off-by:
-
Joonyoung Shim authored
Currently we use busy waiting to seek and tune, it can replace to interrupt way. SI470X I2C driver supports interrupt way to week and tune via this patch. Signed-off-by:
-
Jarod Wilson authored
In commit 8aff8ba9, most of the manipulations to vbuf inside copy_streams were gated on if !dev->radio, but one place that touches vbuf lays outside those gates -- a memcpy of vbuf isn't NULL. If we initialize vbuf to NULL, that memcpy will never happen in the case where we do have dev->radio, and otherwise, in the !dev->radio case, the code behaves exactly like it did prior to 8aff8ba9. While we're at it, also fix an incorrectly indented closing brace for one of the sections touching vbuf that is conditional on !dev->radio. Signed-off-by:
Jarod Wilson <jarod@redhat.com> Signed-off-by:
-
Jarod Wilson authored
Signed-off-by:
-
Jarod Wilson authored
Remove DEBUG define, key debug spew off of the module's debug param that already exists. Signed-off-by:
-
Jarod Wilson authored
Per hardware provided to me, the Formosa Industrial Computing eHome Infrared Receiver, 0x147a:0xe017, has no tx capability, it is rx only. Thanks go to Paul Rae for the hardware. Signed-off-by:
-
Jarod Wilson authored
Thanks to some excellent investigative work by Douglas Clowes, it was uncovered that the older w83667hg Nuvoton chip functions with this driver after actually enabling the CIR function via its multi-function chip config register. The CIR and CIR wide-band sensor enable bits are just in a different place on this hardware, so we only poke register 0x27 on 677 hardware now, and we poke register 0x2c on the 667 now. Reported-by:
Douglas Clowes <dclowes1@optusnet.com.au> Signed-off-by:
-
Jarod Wilson authored
There are additional chip IDs that report a PNP ID of NTN0530, which we were refusing to load on. Instead, lets just warn if we encounter an unknown chip, as there's a chance it will work just fine. Also, expand the list of known hardware to include both an earlier and a later generation chip that this driver should function with. Douglas has an older w83667hg variant, that with a touch more work, will be supported by this driver, and Lutz has a newer w83677hg variant that works without any further modifications to the driver. Reported-by:
Lutz Sammer <johns98@gmx.net> Signed-off-by:
-
Jarod Wilson authored
Use the newly introduced KEY_IMAGES where appropriate, and standardize on KEY_MEDIA for media center/application launcher button (such as the Windows logo key on the Windows Media Center Ed. remotes). Signed-off-by:
-
Jarod Wilson authored
Signed-off-by:
-
Jarod Wilson authored
Signed-off-by:
-
Antonio Ospite authored
The Kinect sensor is a device used by Microsoft for its Kinect project, which is a system for controller-less Human-Computer interaction targeted for Xbox 360. In the Kinect device, RGBD data is captured from two distinct sensors: a regular RGB sensor and a monochrome sensor which, with the aid of a IR structured light, captures what is finally exposed as a depth map; so what we have is basically a Structured-light 3D scanner. The Kinect gspca subdriver just supports the video stream for now, exposing the output from the RGB sensor or the unprocessed output from the monochrome sensor; it does not deal with the processed depth stream yet, but it allows using the sensor as a Webcam or as an IR camera (an external source of IR light might be needed for this use). The low level implementation is based on code from the OpenKinect project (http://openkinect.org). Signed-off-by:
Antonio Ospite <ospite@studenti.unina.it> Signed-off-by:
Jean-François Moine <moinejf@free.fr> Signed-off-by:
-
Antonio Ospite authored
Add a 10 bits per pixel greyscale format in a bit-packed array representation, naming it Y10B. Such pixel format is supplied for instance by the Kinect sensor device. Signed-off-by:
-
