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>
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: Mauro Carvalho Chehab <mchehab@redhat.com>
The ability to force the encoder or decoder chip was broken by commit
0ab6e1c38d 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: Mauro Carvalho Chehab <mchehab@redhat.com>
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: Mauro Carvalho Chehab <mchehab@redhat.com>
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 <florian@mickler.org>
Acked-by: Antti Palosaari <crope@iki.fi>
Reviewed-by: Antti Palosaari <crope@iki.fi>
Tested-by: Antti Palosaari <crope@iki.fi>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
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 <florian@mickler.org>
Acked-by: Antti Palosaari <crope@iki.fi>
Reviewed-by: Antti Palosaari <crope@iki.fi>
Tested-by: Antti Palosaari <crope@iki.fi>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
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 <florian@mickler.org>
Acked-by: Antti Palosaari <crope@iki.fi>
Reviewed-by: Antti Palosaari <crope@iki.fi>
Tested-by: Antti Palosaari <crope@iki.fi>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Note: This change is tested to compile only as I don't have the
hardware.
Signed-off-by: Florian Mickler <florian@mickler.org>
Cc: Patrick Boettcher <pb@linuxtv.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
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 <florian@mickler.org>
Cc: Patrick Boettcher <pb@linuxtv.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Note: This change is tested to compile only as I don't have the
hardware.
Signed-off-by: Florian Mickler <florian@mickler.org>
Cc: Patrick Boettcher <pb@linuxtv.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
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 <florian@mickler.org>
Cc: Patrick Boettcher <pb@linuxtv.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
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 <florian@mickler.org>
Cc: Patrick Boettcher <pb@linuxtv.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
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 <florian@mickler.org>
Cc: Patrick Boettcher <pb@linuxtv.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
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 <florian@mickler.org>
Cc: Patrick Boettcher <pb@linuxtv.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Some whitespace, one linebreak and one unneded variable
initialization...
Signed-off-by: Florian Mickler <florian@mickler.org>
Cc: Patrick Boettcher <pb@linuxtv.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
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 <florian@mickler.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
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 <florian@mickler.org>
Cc: Michael Krufky <mkrufky@linuxtv.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
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 <florian@mickler.org>
Cc: Igor M. Liplianin <liplianin@tut.by>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
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 <florian@mickler.org>
Cc: Akihiro Tsukada <tskd2@yahoo.co.jp>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
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 <florian@mickler.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
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: Mauro Carvalho Chehab <mchehab@redhat.com>
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: Joonyoung Shim <jy0922.shim@samsung.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Remove DEBUG define, key debug spew off of the module's debug param that
already exists.
Signed-off-by: Jarod Wilson <jarod@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
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 <jarod@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
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 <jarod@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
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: Douglas Clowes <dclowes1@optusnet.com.au>
Reported-by: Lutz Sammer <johns98@gmx.net>
Signed-off-by: Jarod Wilson <jarod@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
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 <jarod@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
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: Mauro Carvalho Chehab <mchehab@redhat.com>
Add some comments about known GPIO settings of supported board
versions.
Signed-off-by: Antti Palosaari <crope@iki.fi>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
After that Anysee I2C adapter is capable of one and two byte long
I2C addresses in case of read from I2C bus.
Signed-off-by: Antti Palosaari <crope@iki.fi>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Looks like it is IF route switch on IOE[0]. Set it correctly
to route signal from tuner to demod. Now it works for DVB-C too.
Signed-off-by: Antti Palosaari <crope@iki.fi>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
It is ZL10353, TDA10023 and TDA18212.
Tuner is inside of Samsung DNOD44CDH086A tuner module.
Signed-off-by: Antti Palosaari <crope@iki.fi>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
