Simplifies the locking by moving the em28xx_init_extension() call until
em28xx_usb_probe() has finished with the dev->lock mutex. It therefore
makes the second and subsequent "plugging" events logically identical to
the first "plugging" event when the em28xx-dvb and em28xx-alsa modules
must be loaded (i.e. registered).
Basically, em28xx_usb_probe() requests that em28xx-dvb be loaded and
also triggers udev to initialise the V4L2 devices. These two events are
serialised by the dev->lock mutex but the order that they happen in is
undefined. But this has always been the case anyway.
Signed-off-by: Chris Rankin <rankincj@yahoo.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
This fixes the deadlock that occurs with either multiple PCTV 290e adapters or when a single PCTV 290e adapter is replugged.
For DVB devices, the device lock must now *not* be held when adding/removing either a device or an extension to the respective lists. (Because em28xx_init_dvb() will want to take the lock instead).
Conversely, for Audio-Only devices, the device lock *must* be held when adding/removing either a device or an extension to the respective lists.
Signed-off-by: Chris Rankin <rankincj@yahoo.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
This patch closes the race on the device and extension lists at USB disconnect
time. Previously, the device was removed from the device list during
em28xx_release_resources(), and then passed to the em28xx_close_extension()
function so that all extensions could run their fini() operations. However, this
left a (brief, theoretical, highly unlikely ;-)) window between these two calls
during which a new module could call em28xx_register_extension(). The result
would have been that the em28xx_usb_disconnect() function would also have passed
the device to the new extension's fini() function, despite never having called
the extension's init() function.
This patch also restores em28xx_close_extension()'s symmetry with
em28xx_init_extension(), and establishes the property that every device in the
device list must have been initialised for every extension in the extension list.
Signed-off-by: Chris Rankin <rankincj@yahoo.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
On 04/09/11 00:49, Mauro Carvalho Chehab wrote:
> This is an automatic generated email to let you know that the following patch were queued at the
> http://git.linuxtv.org/media_tree.git tree:
>
> Subject: [media] em28xx: use atomic bit operations for devices-in-use mask
> Author: Chris Rankin<rankincj@yahoo.com>
> Date: Sat Aug 20 08:21:03 2011 -0300
>
> Use atomic bit operations for the em28xx_devused mask, to prevent an
> unlikely race condition should two adapters be plugged in
> simultaneously. The operations also clearer than explicit bit
> manipulation anyway.
>
> Signed-off-by: Chris Rankin<rankincj@yahoo.com>
> Signed-off-by: Mauro Carvalho Chehab<mchehab@redhat.com>
>
> drivers/media/video/em28xx/em28xx-cards.c | 33 ++++++++++++++---------------
I think you missed this line in the merge.
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Release the dev->alt_max_pkt_size buffer in all cases.
Signed-off-by: Chris Rankin <rankincj@yahoo.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
This patch ensures that the em28xx_init_dev() function cleans up after itself,
in the event that it fails. This isimportant because the struct em28xx will be
deallocated if em28xx_init_dev() returns an error.
[mchehab@redhat.com: Fix merge conflicts and simplify the goto labels]
Signed-off-by: Chris Rankin <rankincj@yahoo.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Use atomic bit operations for the em28xx_devused mask, to prevent an
unlikely race condition should two adapters be plugged in
simultaneously. The operations also clearer than explicit bit
manipulation anyway.
Signed-off-by: Chris Rankin <rankincj@yahoo.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
snprintf()'s size parameter includes space for the terminating '\0' character.
Signed-off-by: Chris Rankin <rankincj@yahoo.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
This board were used for testing the em28xx-alsa using a separate interface.
So, it is obviously validated ;)
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Fixes most cases of initializing a var but not using it.
There are still 3 cases at em28xx-alsa, were those vars should
probably be used.
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
All boards use EM28xxx_BOARD, to identify that the macro
refers to a card entry. So:
EM2874_LEADERSHIP_ISDBT -> EM2874_BOARD_LEADERSHIP_ISDBT
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
EM28174 is very similar as already supported EM2874.
I am not sure what are differences, but it could be analog support.
Signed-off-by: Antti Palosaari <crope@iki.fi>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Add support for the PCTV 330e remote control
Signed-off-by: Devin Heitmueller <dheitmueller@kernellabs.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Remove the flag indicating the 330e board is not validated, based on the half
dozen users who have reported today that everything is working.
Signed-off-by: Devin Heitmueller <dheitmueller@kernellabs.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Add the calls necessary to use the new drx-d driver for the PCTV 330e
Signed-off-by: Devin Heitmueller <dheitmueller@kernellabs.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Given how PCTV has multiple products with the same model name, include the
model number in the description and #define to make it a little more clear.
Signed-off-by: Devin Heitmueller <dheitmueller@kernellabs.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
The em28xx bridge strobes the reset pin on the drx-d on every ts_ctrl call.
This results in the state of the chip getting out of the sync with the
state of the driver (and hence all tuning requests after the first one fail).
Make sure the drx-d is not being held in reset, but don't actually perform a
hardware reset on the chip.
The GPIO block has been split out from the other HVR-9x0 variants to reduce
the risk of regression, although in theory they would not have any issues
since none of those cases have the frontend driver managing any internal
state.
Signed-off-by: Devin Heitmueller <dheitmueller@kernellabs.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
The rc-hauppauge-new map is a messy thing, as it bundles 3
different remote controllers as if they were just one,
discarding the address byte. Also, some key maps are wrong.
With the conversion to the new rc-core, it is likely that
most of the devices won't be working properly, as the i2c
driver and the raw decoders are now providing 16 bits for
the remote, instead of just 8.
delete mode 100644 drivers/media/rc/keymaps/rc-hauppauge-new.c
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Signed-off-by: Jarod Wilson <jarod@redhat.com>
There are two "hauppauge-new" keymaps, one with protocol
unknown, and the other with the protocol marked accordingly.
However, both tables are miss-named.
Also, the old rc-hauppauge-new is broken, as it mixes
three different controllers as if they were just one.
This patch solves half of the problem by renaming the
correct keycode table as just rc-hauppauge. This table
contains the codes for the four different types of
remote controllers found on Hauppauge cards, properly
mapped with their different addresses.
create mode 100644 drivers/media/rc/keymaps/rc-hauppauge.c
delete mode 100644 drivers/media/rc/keymaps/rc-rc5-hauppauge-new.c
[Jarod: fix up RC_MAP_HAUPPAUGE defines]
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Signed-off-by: Jarod Wilson <jarod@redhat.com>
The core.s_config op was meant for legacy drivers that needed to work with old
pre-2.6.26 kernels. This is no longer relevant. Unfortunately, this op was
incorrectly called from several drivers.
Replace those occurences with proper i2c_board_info structs and call
v4l2_i2c_new_subdev_board.
After these changes v4l2_i2c_new_subdev_cfg() was no longer used, so remove
that function as well.
Signed-off-by: Hans Verkuil <hverkuil@xs4all.nl>
Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Due to a lack of a break inside the switch, it were getting the
wrong keytable and get_key function.
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
* 'for-2.6.38' of git://git.kernel.org/pub/scm/linux/kernel/git/tj/wq: (33 commits)
usb: don't use flush_scheduled_work()
speedtch: don't abuse struct delayed_work
media/video: don't use flush_scheduled_work()
media/video: explicitly flush request_module work
ioc4: use static work_struct for ioc4_load_modules()
init: don't call flush_scheduled_work() from do_initcalls()
s390: don't use flush_scheduled_work()
rtc: don't use flush_scheduled_work()
mmc: update workqueue usages
mfd: update workqueue usages
dvb: don't use flush_scheduled_work()
leds-wm8350: don't use flush_scheduled_work()
mISDN: don't use flush_scheduled_work()
macintosh/ams: don't use flush_scheduled_work()
vmwgfx: don't use flush_scheduled_work()
tpm: don't use flush_scheduled_work()
sonypi: don't use flush_scheduled_work()
hvsi: don't use flush_scheduled_work()
xen: don't use flush_scheduled_work()
gdrom: don't use flush_scheduled_work()
...
Fixed up trivial conflict in drivers/media/video/bt8xx/bttv-input.c
as per Tejun.
I found that the problems people have reported with the USB-TV-stick
"Terratec Cinergy Hybrid T USB XS" (USB-ID: 0ccd:0042)
are coming from a wrong header file in the v4l-sources.
Attached is a diff, which fixes the problem (tested successfully here).
Obviously the USB-ID has been associated with a wrong chip: EM2880
instead of EM2882, which would be correct.
Reported-by: Philippe Bourdin <richel@AngieBecker.ch>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
This device uses an em2874B + Sharp 921 One Seg frontend.
Signed-off-by: Douglas Schilling Landgraf <dougsland@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Video drivers request submodules using a work during probe and calls
flush_scheduled_work() on exit to make sure the work is complete
before being unloaded. This patch makes these drivers flush the work
directly instead of using flush_scheduled_work().
While at it, relocate request_submodules() call in saa7134_initdev()
right right before successful return as in other drivers to avoid
failing after the work is scheduled and returning failure without the
work still active.
This is in preparation for the deprecation of flush_scheduled_work().
Signed-off-by: Tejun Heo <tj@kernel.org>
Cc: Mauro Carvalho Chehab <mchehab@infradead.org>
The argument isn't used anymore by the functions, remove it.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
With the v4l2_i2c_new_subdev* functions now supporting loading modules
based on modaliases, replace the hardcoded module name passed to those
functions by NULL.
All corresponding I2C modules have been checked, and all of them include
a module aliases table with names corresponding to what the drivers
modified here use.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
This patch allows this device successfully to show video, at least from
its composite input.
I have no information about the true hardware contents of this device and so
this patch is based solely on fiddling with things until it worked. The
chip appears to be em2860, and the closest device with equivalent inputs
is the Typhoon DVD Maker. Copying the settings for that device appears
to do the trick. That's what this patch does.
[mchehab@redhat.com: update CARDLIST.em28xx accordingly, via script]
Signed-off-by: Adrian Taylor <adrian.taylor@realvnc.com>
Reviewed-by: Jarod Wilson <jarod@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
The probe method used by i2c_new_probed_device() may not be suitable
for all cases. Let the caller provide its own, optional probe
function.
Signed-off-by: Jean Delvare <khali@linux-fr.org>
Acked-by: Mauro Carvalho Chehab <mchehab@redhat.com>
This adds support for the KWorld PlusTV 340U and KWorld UB345-Q ATSC
sticks, which are really the same device. The sticks have an eMPIA
em2870 usb bridge chipset, an LG Electronics LGDT3304 ATSC/QAM
demodulator and an NXP TDA18271HD tuner -- early versions of the 340U
have a a TDA18271HD/C1, later models and the UB435-Q have a C2.
The stick has been tested succesfully with both VSB_8 and QAM_256 signals.
Its using lgdt3304 support added to the lgdt3305 driver by a prior patch,
rather than the current lgdt3304 driver, as its severely lacking in
functionality by comparison (see said patch for details).
Signed-off-by: Jarod Wilson <jarod@redhat.com>
Signed-off-by: Michael Krufky <mkrufky@kernellabs.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Instead of using the ugly keymap sequences, use the new rc-*.ko keymap
files. For now, it is still needed to have one keymap loaded, for the
RC code to work. Later patches will remove this depenency.
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Replaces most of the occurences of IR keytables on V4L drivers by a macro
that evaluates to provide the name of the exported symbol.
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Add support for design which has an em2863/tvp5150 and uses the standard
empia USB ID. In Sander's case, it was branded as an "Eminent model EM3705"
Thanks to Sander Van Ginkel for testing and help debugging the support.
[mchehab@redhat.com: move it to a vague card number slot (card=29)]
Signed-off-by: Devin Heitmueller <dheitmueller@kernellabs.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
This patch adapts the changes submitted by Dainius Ridzevicius to the
linux-media mailing list on 8/14/09, to the current sources in order
to make the Kworld VS-DVB-T 323UR usb device work.
I also removed the "not validated" flag since I own the device and validated
that it works fine after the patch is applied.
Thanks to Devin Heitmueller for his guidance with the code.
Signed-off-by: Antonio Larrosa <larrosa@kde.org>
Acked-by: Devin Heitmueller <dheitmueller@kernellabs.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
percpu.h is included by sched.h and module.h and thus ends up being
included when building most .c files. percpu.h includes slab.h which
in turn includes gfp.h making everything defined by the two files
universally available and complicating inclusion dependencies.
percpu.h -> slab.h dependency is about to be removed. Prepare for
this change by updating users of gfp and slab facilities include those
headers directly instead of assuming availability. As this conversion
needs to touch large number of source files, the following script is
used as the basis of conversion.
http://userweb.kernel.org/~tj/misc/slabh-sweep.py
The script does the followings.
* Scan files for gfp and slab usages and update includes such that
only the necessary includes are there. ie. if only gfp is used,
gfp.h, if slab is used, slab.h.
* When the script inserts a new include, it looks at the include
blocks and try to put the new include such that its order conforms
to its surrounding. It's put in the include block which contains
core kernel includes, in the same order that the rest are ordered -
alphabetical, Christmas tree, rev-Xmas-tree or at the end if there
doesn't seem to be any matching order.
* If the script can't find a place to put a new include (mostly
because the file doesn't have fitting include block), it prints out
an error message indicating which .h file needs to be added to the
file.
The conversion was done in the following steps.
1. The initial automatic conversion of all .c files updated slightly
over 4000 files, deleting around 700 includes and adding ~480 gfp.h
and ~3000 slab.h inclusions. The script emitted errors for ~400
files.
2. Each error was manually checked. Some didn't need the inclusion,
some needed manual addition while adding it to implementation .h or
embedding .c file was more appropriate for others. This step added
inclusions to around 150 files.
3. The script was run again and the output was compared to the edits
from #2 to make sure no file was left behind.
4. Several build tests were done and a couple of problems were fixed.
e.g. lib/decompress_*.c used malloc/free() wrappers around slab
APIs requiring slab.h to be added manually.
5. The script was run on all .h files but without automatically
editing them as sprinkling gfp.h and slab.h inclusions around .h
files could easily lead to inclusion dependency hell. Most gfp.h
inclusion directives were ignored as stuff from gfp.h was usually
wildly available and often used in preprocessor macros. Each
slab.h inclusion directive was examined and added manually as
necessary.
6. percpu.h was updated not to include slab.h.
7. Build test were done on the following configurations and failures
were fixed. CONFIG_GCOV_KERNEL was turned off for all tests (as my
distributed build env didn't work with gcov compiles) and a few
more options had to be turned off depending on archs to make things
build (like ipr on powerpc/64 which failed due to missing writeq).
* x86 and x86_64 UP and SMP allmodconfig and a custom test config.
* powerpc and powerpc64 SMP allmodconfig
* sparc and sparc64 SMP allmodconfig
* ia64 SMP allmodconfig
* s390 SMP allmodconfig
* alpha SMP allmodconfig
* um on x86_64 SMP allmodconfig
8. percpu.h modifications were reverted so that it could be applied as
a separate patch and serve as bisection point.
Given the fact that I had only a couple of failures from tests on step
6, I'm fairly confident about the coverage of this conversion patch.
If there is a breakage, it's likely to be something in one of the arch
headers which should be easily discoverable easily on most builds of
the specific arch.
Signed-off-by: Tejun Heo <tj@kernel.org>
Guess-its-ok-by: Christoph Lameter <cl@linux-foundation.org>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Lee Schermerhorn <Lee.Schermerhorn@hp.com>
Adds digital and analogue tv support for Dikom DK300 hybrid usb card.
Not working: remote controller
To be done: it seems that with the proposed patch the digital demodulator
remains activated if the tuner is switched from digital to analogue mode.
Workaround is to unplug and replug the device when switching from digital to
analogue. If someone can explain how to verify the gpio settings using the
usbsnoop, the above issue perhaps can be resolved.
Signed-off-by: Andrea Amorosi <Andrea.Amorosi76@gmail.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
