v4l2_queryctrl sets the step value based on the control type. That would
be fine if it used the control type stored in the V4L2 kernel control
object, not the one stored in the userspace ioctl structure that has
just been memset to 0. Fix this.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Acked-by: Hans Verkuil <hverkuil@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
When queryctrl is called with a V4L2_CID_PRIVATE_BASE control ID, then
currently it is replaced by the real internal ID. This is not according to
the spec so keep the V4L2_CID_PRIVATE_BASE ID in this case.
Signed-off-by: Hans Verkuil <hverkuil@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
VIDIOC_S_CTRL did not check against read-only controls. Even worse, for
controls of type CTRL_CLASS it would cause a kernel oops since those controls
do not have a s_ctrl op.
Signed-off-by: Hans Verkuil <hverkuil@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
When registering an IR Rx device with the I2C subsystem, provide more detailed
information about the IR device and default remote configuration for the IR
driver modules.
Also explicitly register any IR Tx device with the I2C subsystem.
Signed-off-by: Andy Walls <awalls@md.metrocast.net>
Acked-by: Mike Isely <isely@pobox.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
This reverts a portion of commit
44243fc2ef
A commit for which I errantly recommended that defaults for I2C address
0x71 not be set by ir-kbd-i2c.c
The pvrusb2 and bttv drivers currently rely on ir-kbd-i2c setting
defaults for that address. Until I can get those bridge drivers fixed
to properly send IR_i2c_init_data for boards with Zilog Z8 chips,
just add back the default settings for I2C address 0x71.
Signed-off-by: Andy Walls <awalls@md.metrocast.net>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
The ir_command() function is a do-nothing stub; remove it.
Signed-off-by: Andy Walls <awalls@md.metrocast.net>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
The driver is now structured so that it must handle an IR Tx unit
for a Z8 IR chip, or it refuses to handle that Z8 IR chip. This
allows us to assume that ir->tx != NULL in a few places in the driver,
and also allows us to always report Tx is available to userspace.
Get rid of unneeded tests for ir->tx == NULL and always report that
Tx is available.
Signed-off-by: Andy Walls <awalls@md.metrocast.net>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
The IR Rx polling thread was originally a kernel_thread long ago,
and had only been minimally converted to a kthread. This patch
finishes that conversion by
- cleaning up all the unneeded completions
- destroying the kthread properly by calling kthread_stop()
- changing lirc_thread() to test kthread_should_stop() just before
every point where it may sleep
- reorganizing the lirc_thread() function so it uses fewer lines
- modifying the name of the kthread from "lirc_zilog" to
"zilog-rx-i2c-N", so ps will show which kthread polls
which Zilog Z8 IR unit.
Also some minor tweaks were made to logging emitted by the
ir_probe() function.
Signed-off-by: Andy Walls <awalls@md.metrocast.net>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
This patch is an extensive rework of the ir_probe() and ir_remove() functions.
It removes all the double binding and allocation problems on module load.
It removes almost all the memory leaks on module exit and on device
instantiation failure. Proper destruction of the Rx polling kthread still
needs investigation and more work, but it is no worse than it already was.
This rework also had side effects that include:
- encapsulation of the ir_devices[] array
- serialization of access to the ir_devices[] array
- semantic change of the module parameter "disable_rx" to "tx_only"
If tx_only is true, the module does not claim the i2c_client for the IR Rx
function, and only claims and handles the i2c_client for the IR Tx function.
This is a first step in providing the option of letting ir-kbd-i2c.c handle
IR Rx function, while lirc_zilog handles the IR Tx function.
Signed-off-by: Andy Walls <awalls@md.metrocast.net>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Don't make private copies of the i2c clients provided by the I2C
subsystem, don't change the client address field, and don't probe
the client addresses - the bridge driver already did that. This
moves us to the proper I2C and binding model.
Signed-off-by: Andy Walls <awalls@md.metrocast.net>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
This change is a mostly mechanical break of the main struct IR
data structure into common, Rx, and Tx structures. There were some
small logical changes required as well, such as eliminating "is_hdpvr",
to accomplish this.
This change is an intiial step in reworking lirc_zilog to decouple the
Rx and Tx handling as much as possible to fit with the new I2C
binding model. This change actually makes lirc_zilog a little more
broken than it already was - memory deallocation in particular got worse.
However, this change makes the remaining problems easier to see and address.
Signed-off-by: Andy Walls <awalls@md.metrocast.net>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
The only reason to use the lirc_zilog module is for IR Tx, so remove
the possibility of disabling IR Tx. If the user needs only IR Rx,
then the ir-kbd-i2c module works just fine, and doesn't require a
"firmware" image.
Signed-off-by: Andy Walls <awalls@md.metrocast.net>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Jean Delvare <khali@linux-fr.org> suggested this better
format for debug output in ir_probe().
Signed-off-by: Andy Walls <awalls@md.metrocast.net>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
After a recent update of xf86-input-evdev and xorg-server, I noticed
that X11 applications did not receive keypresses from the FireDTV
infrared remote control anymore. Instead, the Xorg log featured lots of
"FireDTV remote control: dropping event due to full queue!"
exclamations. The Linux console did not have an issue with the
FireDTV's RC though.
The fix is to insert EV_SYN events after the key-down/-up events.
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Rework device init part. Move common code part to a function.
Usefull for register multiple devices like video, radio, vbi etc.
Signed-off-by: Beholder Intl. Ltd. Dmitry Belimov <d.belimov@gmail.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Commit e3c9221519 ("[media] radio-aimslab.c: Fix
gcc 4.5+ bug") removed the include, but introduced new callers of msleep():
| drivers/media/radio/radio-aimslab.c: In function ‘rt_decvol’:
| drivers/media/radio/radio-aimslab.c:76: error: implicit declaration of function ‘msleep’
Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Fix sparse warning for non-ANSI function declaration:
drivers/media/rc/ir-raw.c:247:30: warning: non-ANSI function declaration of function 'ir_raw_get_allowed_protocols'
Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com>
Cc: Mauro Carvalho Chehab <mchehab@infradead.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
This patch adds s_power support to adv7175 driver. Power-down is done
by power-down all four DACs.
Signed-off-by: Christian Gmeiner <christian.gmeiner@gmail.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
info->num comes from the user. It's type int. If the user passes
in a negative value that would cause memory corruption.
Signed-off-by: Dan Carpenter <error27@gmail.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
My initial thinking was that we should default to mouse mode, so people
could use the mouse function to click on something on a login screen,
but a lot of systems where a remote is useful automatically log in a
user and launch a media center application, some of which hide the
mouse, which can be confusing to users if they punch buttons on the
remote and don't see any feedback. Plus, first and foremost, its a
remote, so lets default to being a remote, and only toggle into mouse
mode when the user explicitly asks for it. As a nice side-effect, this
actually simplifies some of the code a fair bit...
Signed-off-by: Jarod Wilson <jarod@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
The ene_ir driver was using a private define of MS_TO_NS, which is meant
to be microseconds to nanoseconds. The mceusb driver copied it,
intending to use is a milliseconds to microseconds. Lets move the
defines to a common location, expand and standardize them a touch, so
that we now have:
MS_TO_NS - milliseconds to nanoseconds
MS_TO_US - milliseconds to microseconds
US_TO_NS - microseconds to nanoseconds
Reported-by: David Härdeman <david@hardeman.nu>
CC: Maxim Levitsky <maximlevitsky@gmail.com>
Signed-off-by: Jarod Wilson <jarod@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Otherwise, we have a null receive buffer, and the logic all falls down,
goes boom, all ffdc devs wind up as imon IR w/VFD. Oops.
Signed-off-by: Jarod Wilson <jarod@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
dev->rdev is accessed in ene_setup_hw_settings, so it needs to be wired
up before then.
[Jarod Wilson]: Also fix a possible improper resource freeing bug while
we're looking at possible probe issues here.
Signed-off-by: Kyle McMartin <kmcmartin@redhat.com>
CC: Maxim Levitsky <maximlevitsky@gmail.com>
Signed-off-by: Jarod Wilson <jarod@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
There's a nasty bug that slipped in when the rc device interface was
altered, only affecting the older 0xffdc imon devices. We were trying
to access ictx->rdev->allowed_protos before ictx->rdev had been set.
There's also an issue with call ordering that meant the correct
keymap wasn't getting loaded for MCE IR type 0xffdc devices.
Signed-off-by: Jarod Wilson <jarod@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Use unlocked_ioctl in v4l2_file_operations. The locking is
already in place.
Signed-off-by: Matti J. Aaltonen <matti.j.aaltonen@nokia.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
With cmwq, there's no reason to use separate out_work_queue. Drop it
and use system_wq instead. The in_work_queue needs to be ordered so
can't use one of the system wqs; however, as it isn't used to reclaim
memory, allocate the workqueue with alloc_ordered_workqueue() without
WQ_MEM_RECLAIM.
Signed-off-by: Tejun Heo <tj@kernel.org>
Reviewed-by: Andy Walls <awalls@md.metrocast.net>
Acked-by: Andy Walls <awalls@md.metrocast.net>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Hi,
While reading
drivers/media/video/tlg2300/pd-video.c::alloc_bulk_urbs_generic() I
noticed that
- We don't free the memory allocated to 'urb' if the call to
usb_alloc_coherent() fails.
- If the 'num' argument to the function is ever <= 0 we'll return an
uninitialized variable 'i' to the caller.
The following patch addresses both of the above by a) calling
usb_free_urb() when usb_alloc_coherent() fails and by explicitly
initializing 'i' to zero.
I also moved the variables 'mem' and 'urb' inside the for loop. This does
not actually make any difference, it just seemed more correct to me to let
variables exist only in the innermost scope they are used.
Signed-off-by: Jesper Juhl <jj@chaosbits.net>
Acked-by: Huang Shijie <shijie8@gmail.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
We may leak the storage allocated to 'state' in
drivers/media/dvb/frontends/ix2505v.c::ix2505v_attach() on error, as
it is too early to be able to call ix2505v_release().
This patch makes sure we free the allocated memory in the failure case.
Signed-off-by: Jesper Juhl <jj@chaosbits.net>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
The infrared was set by sensor write instead of bridge GPIO.
It is now settable by the standard control ILLUMINATOR_1.
A module parameter permits to set the right GPIO bit according
to the StarCam model.
Signed-off-by: Jean-François Moine <moinejf@free.fr>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
__devinit* must not be used in USB drivers.
Signed-off-by: Jean-François Moine <moinejf@free.fr>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Renamed has_new to is_new.
Drivers can use the is_new field to determine if a new value was specified
for a control. The v4l2_ctrl_handler_setup() must always set this to 1 since
the setup has to force a full update of all controls.
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>
Some subdevs need to call into the board code after they are registered
and have a valid struct v4l2_device pointer. The s_config op was abused
for this, but now that it is removed we need a cleaner way of solving this.
So this patch adds a struct with internal ops that the v4l2 core can call.
Currently only two ops exist: register and unregister. Subdevs can implement
these to call the board code and pass it the v4l2_device pointer, which the
board code can then use to get access to the struct that embeds the
v4l2_device.
It is expected that in the future open and close ops will also be added.
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>
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>
There are some weird bugs at tda8290/tda18271 initialization, as it
insits do do analog initialization during DVB frontend attach:
DVB: registering new adapter (saa7133[0])
DVB: registering adapter 0 frontend 0 (Fujitsu mb86A20s)...
mb86a20s: mb86a20s_initfe
tda18271_write_regs: [2-0060|M] ERROR: idx = 0x5, len = 1, i2c_transfer returned: -5
tda18271_init: [2-0060|M] error -5 on line 830
tda18271_tune: [2-0060|M] error -5 on line 908
tda18271_write_regs
tda18271_write_regs: [2-0060|M] ERROR: idx = 0x5, len = 1, i2c_transfer returned: -5
tda18271c2_rf_tracking_filters_correction: [2-0060|M] error -5 on line 265
tda18271_write_regs
tda18271_write_regs: [2-0060|M] ERROR: idx = 0x25, len = 1, i2c_transfer returned: -5
tda18271_channel_configuration: [2-0060|M] error -5 on line 119
tda18271_set_analog_params: [2-0060|M] error -5 on line 1045
tda18271_set_analog_params: [2-0060|M] error -5 on line 1045
tda829x 2-004b: tda8295 not locked, no signal?
tda829x 2-004b: tda8295_i2c_bridge: disable i2c gate
tda829x 2-004b: tda8295 not locked, no signal?
tda829x 2-004b: tda8295_i2c_bridge: disable i2c gate
mb86a20s_i2c_writereg: writereg error (rc == -5, reg == 0x29, data == 0x33)
mb86a20s: Init failed. Will try again later
The problem is that mb86a20s is only visible if the analog part is disabled.
However, due to a trick at mb86a20s, it will later initialize properly:
mb86a20s: mb86a20s_initfe: Initialization succeded.
This is hacky and ugly. However, I coldn't find any easy way to fix it.
A proper fix would be to have a resource locking schema, used by both
V4L and DVB parts that would block access to analog registers while
digital registers are in use, but this will probably put tda829x into
a dead lock.
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
There were some issues at tda8290 that were preventing this device
to work. Now that those fixes were fixed, we can enable analog
mode.
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Due to a hard to track bug between tda829x/tda18271/saa7134, tda829x
wants to go to analog mode during DVB initialization, causing some
I2C errors.
The analog failure doesn't cause any harm, as the device were already
properly initialized in analog mode. However, the failure at the digital
mode causes the frontend mb86a20s to not initialize. Fortunately, at
least on my tests, it was possible to detect that the device is a
mb86a20s before the failure.
What happens is that tda8290 is a very bad boy: during DVB setup, it
keeps insisting to call tda18271 analog_set_params, that calls
tune_agc code. The tune_agc code calls saa7134 driver, changing the
value of GPIO 27, switching from digital to analog mode and disabling
the access to mb86a20s, as, on Kworld SBTVD, the same GPIO used
to switch the hardware AGC mode seems to be used to enable the I2C
switch that allows access to the frontend (mb86a20s).
So, a call to analog_set_params ultimately disables the access to
the frontend, and causes a failure at the init frontend logic.
This patch is a workaround for this issue: it simply checks if the
frontend init had any failure. If so, it will init the frontend when
some DTV application will try to set DVB mode.
Even being a hack for Kworld SBTVD to work, and assumning that we could
teach tda8290 to be a good boy, this is actually an improvement at the
frontend driver, as it will be more reliable to initialization failures.
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
A script replaced err var to rc. Howerver, this script gambled
"error" string, changing it to "rcor". Revert that bad change.
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
On Kworld SBTVD, tda8295-c1 starts in power off mode. It needs
to be powered, otherwise, the I2C gate control command won't work.
Cc: Michael Krufky <mkrufky@kernellabs.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Read operations should be preceeded by a write operation. However,
nothing prevents that an I2C operation could happen between the two
transactions.
To avoid that problem, use an unique I2C transfer for both parts of
the I2C transaction.
Cc: Michael Krufky <mkrufky@kernellabs.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>
Fixes Fedora 14 bug: https://bugzilla.redhat.com/show_bug.cgi?id=667157
There are a few bugs at the code that generates the scancode at dib0700:
- RC keycode is wrong (it outputs a 24 bits keycode);
- NEC extended outputs a keycode that have endiannes issues;
- keycode tables for NEC extended remotes need to be updated.
The last issue need to be done as we get reports, as we don't have
the complete NEC-extended keycodes at the dibcom table.
This patch fixes the first two issues.
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
The si470x i2c and usb driver support the RDS, so this ifdef statement
doesn't need more.
[mchehab@redhat.com: Fix a conflict on it]
Signed-off-by: Joonyoung Shim <jy0922.shim@samsung.com>
Acked-by: Tobias Lorenz <tobias.lorenz@gmx.net>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
The ioctls VIDIOC_DBG_S_REGISTER and VIDIOC_DBG_G_REGISTER should return -EINVAL
if the driver didn't implement them. Currently they return -EPERM if called as
non-root user. However, this check should only be done if the driver actually
implemented these ioctls. Otherwise, just return -EINVAL as we do with all
unimplemented ioctls.
This bug make the v4l2-compliance test suite fail.
Signed-off-by: Hans Verkuil <hverkuil@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
While going through windows inf file I found more usb-id, add a comment
with this id for future reference.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Acked-by: Jean-Francois Moine <moinejf@free.fr>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Looking at the windows inf file, for usb ids with a sensor type where probing
is needed to determine the type (for example ov7630 or soi768), this is
needed for all bridge variants with a usb id indicating this sensor type.
So do the probing to determine the actual sensor type for types where the
usb-id info is not 100% deterministic, independent of the bridge type.
If you look through the list of currently active usb ids in sonixj, this
effectively only changes the code path for 0c45:60fe (sn9c105 + ov7630) and
0c45:612e (sn9c110 + ov7630), which according to the inf file can have a
soi768 instead of a ov7630 just like the sn9c120 + ov7630 models where we
already probe for a soi7630.
The main reason for this code change is to keep the code paths as bridge
variant independent as possible, so that we don't need a lot of special
per bridge cases, as we enable more usb-ids in the future.
This change makes the 0c45:60fe code path identical to the successfully
tested 0c45:613e, so also make sonixj the default driver for 0c45:60fe.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Acked-by: Jean-Francois Moine <moinejf@free.fr>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Both we and the windows driver make no sensor specific differences
(with some exceptions) for different sonixj bridge types. Thus if a
sn9c105 bridge has been successfully tested with a sensor, the same
sensor can be successfully used with a sn9c120 bridge too.
Using this knowledge we can move over most usb-ids too the sonixj
driver when both are compiled.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Acked-by: Jean-Francois Moine <moinejf@free.fr>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Now that our bridge code is unified for sn9c101/102 and sn9c103 models,
the sn9c103 models should simply work, given that the only difference
in the sn9c103 is audio support and a gamma correction table.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Acked-by: Jean-Francois Moine <moinejf@free.fr>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Also fix the issue of the image being mirrored.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Acked-by: Jean-Francois Moine <moinejf@free.fr>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Refactor the code to unify how the sn9c101/102 and the sn9c103 bridge
are handled. Also move code which is the same for all sensors from
the per sensor init register settings to a central place.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Acked-by: Jean-Francois Moine <moinejf@free.fr>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
The sn9c102 driver claims a number of usb-ids which are for cameras
with sensor types which it does not support. Also it claims a number
of usb-ids which do not exist at all (not present in the windows
drivers .inf files, not known by google).
This patch also fixes the conflict with the gspca_sonixj driver for the
0c45:60c0 and 0c45:60fb usb ids.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Acked-by: Jean-Francois Moine <moinejf@free.fr>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
The et61x251 driver claims a whole list of usb id's, but it only has
one sensor "module" which does sensor detection based on usb id and that
only supports devices with the 102c:6251 usb id. Remove the usb-ids for
other devices as for those the driver will fail with an unable to determine
sensor type message anyways.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
We check for not streaming as a condition to abort waiting in dqbuf, so
when another thread does a streamoff we should wake the wq.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Acked-by: Jean-Francois Moine <moinejf@free.fr>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Some applications (xawtv, qv4l2) mix read and mmap calls. Allow switching
from read mode back to mmap mode (by doing a reqbufs).
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Acked-by: Jean-Francois Moine <moinejf@free.fr>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
gspca_dev->memory == GSPCA_MEMORY_NO implies gspca_dev->nframes == 0,
so there is no need to check for both in dev_poll. The check in
dev_read also is more complex then needed, as dqbuf which dev_read
calls already does all necessary checks. Moreover dqbuf is holding
the proper locks while checking where as dev_read itself is not.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Acked-by: Jean-Francois Moine <moinejf@free.fr>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Before this patch we were not setting the memory type to GSPCA_MEMORY_NO
when the buffers were released by the app doing a reqbufs 0. Nor would
the memory type be set to GSPCA_MEMORY_NO on device close, as capture_file
already is NULL on device close because of the reqbufs 0. This caused the
following problem:
-app1 does reqbufs USERPTR for 4 buffers
-app1 does reqbufs USERPTR for 0 buffers
-app2 tries to do reqbufs MMAP for 4 buffers
fails because gspca_dev->memory still is USERPTR
Fixing this also allows an app to switch memory type's by unrequesting
the buffers and re-requesting them of a different type.
This patch also moves the setting of gspca_dev->frsz and gscpa_dev->memory
to after alloc_frame succeeding, so that they are not changed when allocating
fails.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Acked-by: Jean-Francois Moine <moinejf@free.fr>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Remove the no longer used / useful users variable, and with that gone
there also is no longer a need to take queue_lock in dev_open.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Acked-by: Jean-Francois Moine <moinejf@free.fr>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Before this patch dqbuf errors out on a failing user_copy (with user pointers)
before updating the buffer flags, causing a successsfully dequeued buffer
to still have the DONE flag, which means that it could no longer be
re-queueud (assuming the app somehow survives the segfault).
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Acked-by: Jean-Francois Moine <moinejf@free.fr>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Before this patch vidioc_dqbuf is using its own read_lock, where as
other queue related functions use queue_lock. This means that dqbuf is
accessing several variables in a racy manor. The most important one
being fr_o, which may be changed from underneath dqbuf by vidioc_reqbufs
or vidioc_streamoff. Other variables which it accesses unprotected
are gspca_dev->memory, gspca_dev->streaming and gspca_dev->capt_file.
This patch fixes this by changing vidioc_dqbuf to also use the queue_lock.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Acked-by: Jean-Francois Moine <moinejf@free.fr>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
The gspca_dev->streaming boolean is protected against multiple access
through gspca_dev->queue_lock everywhere except for 2 places. This patch
fixes this by bringing it under the lock in vidioc_streamoff. And by
removing the check for gspca_dev->streaming in gspca_disconnect,
the destroy_urbs call may be called multiple times (and is protected
by the usb_lock) and calling wake_up_interruptible can also always be done
safely.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Acked-by: Jean-Francois Moine <moinejf@free.fr>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
IF freq for DVB-T 7 MHz and 8 MHz was set slightly wrong. Due to that it
didn't worked at all (?) for 7 MHz channels and most likely performance
was dropped for 8 MHz channels.
That bug was pointed by few people during last two months. Thank you.
Trivial fix. Compile tested only due to lack of proper HW and signal.
Signed-off-by: Antti Palosaari <crope@iki.fi>
Cc: Romolo Manfredini <romoloman@hotmail.com>
Cc: Alireza Moini <alireza.moini@silverbrookresearch.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
The radio-gemtek-pci driver is for the same hardware as the radio-maxiradio
driver which uses the same GemTek PR103 and tea5757 combination and the two
drivers are identical. I chose the maxiradio over the gemtek-pci driver since
the maxiradio has support for mono/stereo detection.
Tested with my gemtek-pci card.
Signed-off-by: Hans Verkuil <hverkuil@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Use the standard USA/Europe frequency range of 87-108 MHz instead of the
arbitrary 50-150 MHz.
Copied from the radio-gemtek-pci driver which supports the same hardware.
Signed-off-by: Hans Verkuil <hverkuil@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Added functions to set and get custom DV timings.
Signed-off-by: Mats Randgaard <mats.randgaard@cisco.com>
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Acked-by: Vaibhav Hiremath <hvaibhav@ti.com>
Acked-by: Manjunath Hadli <manjunath.hadli@ti.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
- Added functions to set/get/query/enum DV presets for vpif_caputre and
vpif_display.
- The format specification table is extended with all the DV formats
supported by TVP7002.
Signed-off-by: Mats Randgaard <mats.randgaard@cisco.com>
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Acked-by: Manjunath Hadli <manjunath.hadli@ti.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
- The ch_params tables in vpif_capture.c and vpif_display.c are moved to a common
table in vpif.c. Then it is easier to maintain the table.
- The field "fps" is removed from the struct vpif_channel_config_params because it
is not used.
Signed-off-by: Mats Randgaard <mats.randgaard@cisco.com>
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Acked-by : Murali Karicheri <mkaricheri@gmail.com>
Acked-by: Manjunath Hadli <manjunath.hadli@ti.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Convert saa7146 to use core-assisted locking.
Signed-off-by: Hans Verkuil <hverkuil@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Since tda9875 is part of tvaudio this field no longer makes sense. Remove it.
Signed-off-by: Hans Verkuil <hverkuil@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
In commit 411674fd18 the tda9875 support was
added to tvaudio. This means that tda9875 is no longer used since mid-2009.
If there are out-of-tree users of this driver, then they can switch to tvaudio
instead.
The original commit message read as follows:
This change allows bttv to use tvaudio for this device. Since this device
has the same i2c address as the tda9874 we need to support both in the same
tvaudio driver. This makes it possible for tvaudio to detect which chip is
used. Originally the tda9875 was only available in the dedicated tda9875
driver, but that makes life very hard for bttv since loading tvaudio might
misdetect a tda9875 as a tda9874.
So there were good reasons for moving the tda9875 code into tvaudio.
Signed-off-by: Hans Verkuil <hverkuil@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
History: This support changes a method to "serialized" on the fly if the
method generates an AE_ALREADY_EXISTS error, indicating the possibility
that it cannot handle reentrancy.
This fix repairs a couple of issues seen in the field, especially on
machines with many cores.
1) Delete method children only upon the exit of the last thread, so
as to not delete objects out from under running threads.
2) Set the "serialized" bit for the method only upon the exit of the
last thread, so as to not cause deadlock when running threads attempt
to exit.
3) Cleanup the use of the AML "MethodFlags" and internal method flags
so that there is no longer any confustion between the two.
Reported-by: Dana Myers <dana.myers@oracle.com>
Signed-off-by: Lin Ming <ming.m.lin@intel.com>
Signed-off-by: Bob Moore <robert.moore@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
Prevents issues if the namespace is changing underneath the
debugger. Especially temporary nodes, since the debugger displays
these also.
Signed-off-by: Bob Moore <robert.moore@intel.com>
Signed-off-by: Lin Ming <ming.m.lin@intel.com>
Reviewed-by: Rafael Wysocki <rjw@sisk.pl>
Signed-off-by: Len Brown <len.brown@intel.com>
Fixes a race condition between method execution and namespace
walks that can possibly fault. Problem was apparently introduced
in version 20100528 as a result of a performance optimization
that reduces the number of namespace walks upon method exit
by using the delete_namespace_subtree function instead of the
delete_namespace_by_owner function used previously. Bug is in
the delete_namespace_subtree function.
Signed-off-by: Dana Myers <dana.myers@oracle.com>
Signed-off-by: Bob Moore <robert.moore@intel.com>
Signed-off-by: Lin Ming <ming.m.lin@intel.com>
Reviewed-by: Rafael Wysocki <rjw@sisk.pl>
Signed-off-by: Len Brown <len.brown@intel.com>
We will leak the memory allocated to 'local_gpe_event_info' if
'acpi_ut_acquire_mutex()' fails or if 'acpi_ev_valid_gpe_event()' fails in
drivers/acpi/acpica/evgpe.c::acpi_ev_asynch_execute_gpe_method().
Signed-off-by: Jesper Juhl <jj@chaosbits.net>
Reviewed-by: Rafael Wysocki <rjw@sisk.pl>
Signed-off-by: Len Brown <len.brown@intel.com>
Just stumbled upon the issue while looking for another bug.
The code looks correct, the indentation is not.
Signed-off-by: Anton Vorontsov <cbouatmailru@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
sh_irda can not use RX/TX in same time,
but this driver didn't return to RX mode when TX error occurred.
This patch care xmit error case to solve this issue.
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
- tx_fixup() can be called from either timer callback or from xmit()
in usbnet, so spinlock is added to avoid concurrency-related problem.
- minor correction due to checkpatch warning for some line over 80
chars after previous patch was applied.
Signed-off-by: Alexey Orishko <alexey.orishko@stericsson.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
In drivers/net/ns83820.c::ns83820_init_one() we dynamically allocate
memory via alloc_etherdev(). We then call PRIV() on the returned storage
which is 'return netdev_priv()'. netdev_priv() takes the pointer it is
passed and adds 'ALIGN(sizeof(struct net_device), NETDEV_ALIGN)' to it and
returns it. Then we test the resulting pointer for NULL, which it is
unlikely to be at this point, and later dereference it. This will go bad
if alloc_etherdev() actually returned NULL.
This patch reworks the code slightly so that we test for a NULL pointer
(and return -ENOMEM) directly after calling alloc_etherdev().
Signed-off-by: Jesper Juhl <jj@chaosbits.net>
Signed-off-by: Benjamin LaHaise <bcrl@kvack.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
Update bnx2x version to 1.62.00-4
Signed-off-by: Yaniv Rosner <yanivr@broadcom.com>
Signed-off-by: Eilon Greenstein <eilong@broadcom.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
