There is an integer overflow here because 0x03000000 * 1000 is too large
for 31 bits.
rawir.duration should be in terms of nsecs.
IR_MAX_DURATION and 0x03000000 are already in terms of nsecs.
STREAMZAP_TIMEOUT and STREAMZAP_RESOLUTION are 255 and 256 respectively
and are in terms of usecs.
The original code had a deadline of 1.005 seconds and the new code has a
deadline of .065 seconds.
Signed-off-by: Dan Carpenter <error27@gmail.com>
Signed-off-by: Jarod Wilson <jarod@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
As pointed out (and tested) by Joris van Rantwijk, we do actually need
to wire up .compat_ioctl for 32-bit lirc userspace to work with 64-bit
lirc kernelspace. Do it. And add a check to make sure we get a valid
irctl in the ioctl handler.
Signed-off-by: Jarod Wilson <jarod@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
>From Joris van Rantwijk <jorispubl@xs4all.nl>:
I tested lirc_serial and found that it works fine.
Except the LIRC ioctls do not work in my 64-bit-kernel/32-bit-user
setup. I added compat_ioctl entries in the drivers to fix this.
While doing so, I noticed inconsistencies in the argument type of
the LIRC ioctls. All ioctls are declared in lirc.h as having argument
type __u32, however there are a few places where the driver calls
get_user/put_user with an unsigned long argument.
The patch below changes lirc_dev and lirc_serial to use __u32 for all
ioctl arguments, and adds compat_ioctl entries.
It should probably also be done in the other low-level drivers,
but I don't have hardware to test those.
I've dropped the .compat_ioctl addition from Joris' original patch,
as I swear the non-compat definition should now work for both 32-bit
and 64-bit userspace. Technically, I think we still need/want a
in getting a reply to you).
Reported-by: Joris van Rantwijk <jorispubl@xs4all.nl>
Signed-off-by: Jarod Wilson <jarod@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Per discussion with Andy Walls on irc, rx fifo overruns are not all that
uncommon on a busy system, and the initial posting of the nuvoton-cir
driver doesn't handle them well enough. With this addition, we'll drain
the hw fifo, attempt to process any ir pulse trains completed with that
flush, then we'll issue a hw rx fifo clear and reset the raw ir sample
kfifo and start over collecting raw ir data.
Also slightly refactors the cir interrupt enabling so that we always get
consistent flags set and only have to modify them in one place, should
they need to be altered.
Signed-off-by: Jarod Wilson <jarod@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
This is a new ir-core pnp driver for the Nuvoton w836x7hg integrated CIR
function. The chip is found on at least the ASRock ION 330HT boxes and
apparently, on a number of Intel DP55-series motherboards:
http://www.asrock.com/nettop/overview.asp?Model=ION%20330HThttp://downloadcenter.intel.com/Detail_Desc.aspx?agr=Y&DwnldID=17685&lang=eng
This driver was made possible by a hardware donation from Nuvoton, along
with sample code (in the form of an lirc driver) and datasheet, so huge
thanks to them for supporting this effort. Note that this driver
constitutes a massive rewrite, porting from the lirc interfaces to the
ir-core interfaces, and restructuring the driver to look more like Maxim
Levitsky's ene_ir driver (as well as generally making it look more like
kernel code).
There's some work left to be done on this driver, to fully support the
range of functionality possible, but receive and IR power-on/wake are
both functional (may require setting wake key under another OS atm). The
hardware I've got (one of the ASRock boxes) only supports RX, so TX is
completely untested as of yet. Certain RX parameters, like sample
resolution and RX IRQ sample length trigger level could possibly stand
to be made tweakable via modparams or sysfs nodes, but the current
values work well enough for me w/an MCE RC6A remote.
The original lirc driver carried support for the Windows MCE IR
keyboard/mouse device, which I plan to add back generically, in a way
that should be usable by any raw IR receiver (or at least by this driver
and the mceusb driver).
Suspend and resume have also been tested, the power button on my remote
can be used to wake the machine, and CIR functionality resumes just
fine. Module unload/reload has also been tested, though not extensively
or repetitively. Also tested to work with the lirc bridge plugin for
userspace decoding.
Signed-off-by: Jarod Wilson <jarod@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
The new control mechanism uses dynamic control values in the subdriver
descriptor. It simplifies standard control handling.
Signed-off-by: Jean-François Moine <moinejf@free.fr>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Take the ctrl_mutex mutex before touching control information in those
functions.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
XU control information is supposed to be entirely discoverable using
standard UVC queries. As some devices report bogus information (such as
reporting a read-only control as being read-write), add a fixup table
for XU controls.
This table can also be used to selectively disable requests supposed to
be supported by all XU controls (GET_MIN, GET_MAX, GET_DEF, GET_RES) but
not correctly (or at all) supported by the device.
The table currently disables GET_CUR on the Logitech motor control XU
pan/tilt controls.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
XU controls initialization requires querying the device for control
information. As some buggy UVC devices will crash when queried
repeatedly in a tight loop, delay XU controls initialization until first
use.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Now that control information structures are not shared between control
instances, embed a uvc_control_info instance inside the uvc_control
structure instead of storing a pointer.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
This patch removes the sysadmin requirements for UVCIOC_CTRL_MAP (and the stub
implementation of UVCIOC_CTRL_ADD). This requirement no longer makes sense with
the new XU control access mechanisms since XU controls can be accessed without
adding control mappings first.
A maximum number (currently 1024) of control mappings per device is enforced to
avoid excess memory consumption caused by careless user space applications.
Signed-off-by: Martin Rubli <martin_rubli@logitech.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Devices advertise XU controls using a bitmask, in which each bit
corresponds to a control. The control selector, used to query the
control, isn't available in the USB descriptors.
All known UVC devices use control selectors equal to the control bit
index plus one. Hardcode that relationship in the driver, making the
UVCIOC_CTRL_ADD ioctl obsolete. All necessary information about XU
controls can be obtained by the driver at enumeration time.
The UVCIOC_CTRL_ADD ioctl is still supported for compatibility reasons,
but now always returns -EEXIST.
Finally, control mappings are now on a per-device basis and no longer
global.
As this changes the userspace interface, bump the driver version number
to 1.0.0 (it was about time).
Signed-off-by: Martin Rubli <martin_rubli@logitech.com>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Increase the sequence number of the v4l2_buffer structure regardless of
any buffer states, so that discontinuous sequence numbers allow
applications to detect lost video frames.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
The bandwidth estimate computed with the FIX_BANDIWDTH quirk is too low
for many cameras. Don't use maximum packet sizes lower than 1024 bytes
to try and work around the problem. According to measurements done on
two different camera models, the value is high enough to get most
resolutions working while not preventing two simultaneous VGA streams at
15 fps.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Instead of printing the query hex value in error messages, print its
name to make the messages more readable.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
They're not modified by the function, make them const.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
The Hercules Dualpix Exchange (06f8:3005) camera expose an absolute zoom
that is not implemented. Blacklist it.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Don't hold the lock before unregistering the device, since when the
device is unregistered the datastruct containing the lock may be freed
(if the refcount went to 0).
Also fixed the framework documentation that erroneously suggested the
wrong locking order as well.
Reported-by: David Ellingsworth <david@identd.dyndns.org>
Signed-off-by: Hans Verkuil <hverkuil@xs4all.nl>
Acked-by: David Ellingsworth <david@identd.dyndns.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Use new RC core instead of old legacy RC implementation.
Signed-off-by: Antti Palosaari <crope@iki.fi>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Imported from af9015.h. Initial keytable was from
Jose Alberto Reguero <jareguero@telefonica.net> and
Felipe Morales Moreno <felipe.morales.moreno@gmail.com>
Signed-off-by: Antti Palosaari <crope@iki.fi>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Digittrade DVB-T USB Stick remote controller.
Imported from af9015.h. Initial keytable was from Alain Kalker <miki@dds.nl>
Signed-off-by: Antti Palosaari <crope@iki.fi>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Imported from af9015.h.
Initial keytable was from Marc Schneider <macke@macke.org>
Signed-off-by: Antti Palosaari <crope@iki.fi>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
MSI DIGIVOX mini III remote controller. Uses NEC extended 0x61d6.
This remote seems to be same as rc-kworld-315u.c. Anyhow, add new remote
since rc-kworld-315u.c lacks NEC extended address byte.
Signed-off-by: Antti Palosaari <crope@iki.fi>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Variable is don't care in that case. No need to set value.
Signed-off-by: Antti Palosaari <crope@iki.fi>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
The AVerTV Red HD+ (A850T) is basically the same as the existing
AVerTV Volar Black HD (A850), but is specific to the french market.
The A850T identifies itself as a A850, but has its own PID. It even
suffers from the same EEPROM deficiencies.
This is based off a collection of information gathered from the
french support forums for Ubuntu, which I tried to properly format
into this patch:
http://forum.ubuntu-fr.org/viewtopic.php?pid=3322825
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
Signed-off-by: Antti Palosaari <crope@iki.fi>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Demod + tuner specific RF AGC and IF AGC limit values are read from demod
memory in every signal strength query. Cache those to reduce I2C traffic.
Signed-off-by: Antti Palosaari <crope@iki.fi>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Precalculate coefficients register values. This reduces text size around 300 bytes.
Signed-off-by: Antti Palosaari <crope@iki.fi>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
While here, documment that VBI may need changes, based on video STD, and
do some cleanup at device init, to be sure that VBI init will happen
all the times, and to remove a duplicated video standard call.
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Rework audio. Add SECAM-DK, move SECAM to SECAM-B | SECAM-G.
Add some new audio standards and tricks for future, see
tm6000_set_audio_std.
For SECAM-DK it works.
Signed-off-by: Beholder Intl. Ltd. Dmitry Belimov <d.belimov@gmail.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
The better is to remove the audio init from tm6000-core and add a
separate per-standard set of tables.
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Instead of doing its own lock, use core-assisted one. As a bonus, it
will do the proper unlock during queue wait events. This fixes a
long-standing bug where softwares like tvtime would hang if you try to
use cx231xx-alsa.
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
This file came originally from cx23885 driver. Some functions aren't
used. Now that they are declared as static, we have those errors:
drivers/media/video/cx231xx/cx231xx-417.c:615: warning: ‘mc417_gpio_set’ defined but not used
drivers/media/video/cx231xx/cx231xx-417.c:625: warning: ‘mc417_gpio_clear’ defined but not used
drivers/media/video/cx231xx/cx231xx-417.c:635: warning: ‘mc417_gpio_enable’ defined but not used
As they're not used, just remove them. If needed, they can be restored from
the git logs or from the cx23885 driver.
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
drivers/media/video/cx23885/built-in.o: In function `mc417_memory_write':
/home/v4l/v4l/patchwork/drivers/media/video/cx23885/cx23885-417.c:482: multiple definition of `mc417_memory_write'
drivers/media/video/cx231xx/built-in.o:/home/v4l/v4l/patchwork/drivers/media/video/cx231xx/cx231xx-417.c:477: first defined here
drivers/media/video/cx23885/built-in.o: In function `mc417_gpio_set':
/home/v4l/v4l/patchwork/drivers/media/video/cx23885/cx23885-417.c:636: multiple definition of `mc417_gpio_set'
drivers/media/video/cx231xx/built-in.o:/home/v4l/v4l/patchwork/drivers/media/video/cx231xx/cx231xx-417.c:615: first defined here
drivers/media/video/cx23885/built-in.o: In function `mc417_gpio_enable':
/home/v4l/v4l/patchwork/drivers/media/video/cx23885/cx23885-417.c:656: multiple definition of `mc417_gpio_enable'
drivers/media/video/cx231xx/built-in.o:/home/v4l/v4l/patchwork/drivers/media/video/cx231xx/cx231xx-417.c:635: first defined here
drivers/media/video/cx23885/built-in.o: In function `mc417_memory_read':
/home/v4l/v4l/patchwork/drivers/media/video/cx23885/cx23885-417.c:546: multiple definition of `mc417_memory_read'
drivers/media/video/cx231xx/built-in.o:/home/v4l/v4l/patchwork/drivers/media/video/cx231xx/cx231xx-417.c:541: first defined here
drivers/media/video/cx23885/built-in.o: In function `mc417_gpio_clear':
/home/v4l/v4l/patchwork/drivers/media/video/cx23885/cx23885-417.c:646: multiple definition of `mc417_gpio_clear'
drivers/media/video/cx231xx/built-in.o:/home/v4l/v4l/patchwork/drivers/media/video/cx231xx/cx231xx-417.c:625: first defined here
drivers/media/video/cx23885/built-in.o: In function `mc417_register_read':
/home/v4l/v4l/patchwork/drivers/media/video/cx23885/cx23885-417.c:388: multiple definition of `mc417_register_read'
drivers/media/video/cx231xx/built-in.o:/home/v4l/v4l/patchwork/drivers/media/video/cx231xx/cx231xx-417.c:401: first defined here
drivers/media/video/cx23885/built-in.o: In function `mc417_register_write':
/home/v4l/v4l/patchwork/drivers/media/video/cx23885/cx23885-417.c:324: multiple definition of `mc417_register_write'
drivers/media/video/cx231xx/built-in.o:/home/v4l/v4l/patchwork/drivers/media/video/cx231xx/cx231xx-417.c:343: first defined here
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
gcc didn't like to have i++ inside a complex operation:
drivers/media/video/cx231xx/cx231xx-417.c: In function ‘cx231xx_load_firmware’:
drivers/media/video/cx231xx/cx231xx-417.c:1059: warning: operation on ‘i’ may be undefined
drivers/media/video/cx231xx/cx231xx-417.c:1061: warning: operation on ‘i’ may be undefined
drivers/media/video/cx231xx/cx231xx-417.c:1063: warning: operation on ‘i’ may be undefined
Btw, I agree with gcc, as we're using i and i++ at the same operation and,
depending on how optimization may occur, it may produce a wrong code.
While here, fix CodingStyle issues on the changed code.
Acked-by: Sri Deevi <Srinivasa.Deevi@conexant.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
The patches received from the vendor contained a lot of CodingStyle
issues. Cleans the style issues reported by checkpatch.pl on
those drivers.
It is better to do such style fixes when merging a big set of
changes than latter. Of course, the better is to receive patches
already cleaned ;)
Acked-by: Sri Deevi <Srinivasa.Deevi@conexant.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
By default, tda18271 tries to optimize I2C bus by updating all registers
at the same time. Unfortunately, some devices doesn't support it.
The current logic has a problem when small_i2c is equal to 8, since there
are some transfers using 11 + 1 bytes.
Fix the problem by enforcing the max size at the right place, and allows
reducing it to max = 3 + 1.
Acked-by: Michael Krufky <mkrufky@kernellabs.com>
Acked-by: Sri Deevi <Srinivasa.Deevi@conexant.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Improves the logic, for it to be clearer and to avoid having
board-dependent config there.
Acked-by: Sri Deevi <Srinivasa.Deevi@conexant.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
The driver has a field to indicate what bus is used by tuner and
by demod. However, this field were never used. On Pixelview,
it uses I2C 2 for tuner, instead of I2C 1.
drivers/media/video/cx231xx/cx231xx-cards.c
Acked-by: Sri Deevi <Srinivasa.Deevi@conexant.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
drivers/media/video/cx231xx/cx231xx-avcore.c:1608: warning: format ‘%d’ expects type ‘int’, but argument 3 has type ‘long unsigned int’
drivers/media/video/cx231xx/cx231xx-417.c:1047: warning: format ‘%d’ expects type ‘int’, but argument 3 has type ‘size_t’
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Adjust the vblank and vactive counts so that they don't throw an error in
cx25840's set_std call (we did an equivalent change for NTSC when we got the
scaler working).
Signed-off-by: Devin Heitmueller <dheitmueller@hauppauge.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
The cx231xx_do_mode_ctrl_overrides() function was not touching the vactive line
count for PAL/SECAM modes, which in some use cases results in it being left in
the chip default state of 480 (NTSC).
Explicitly set the values, as is already done for NTSC.
Signed-off-by: Devin Heitmueller <dheitmueller@hauppauge.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Fix some indentation problems and remove an "if (1)" from the Colibri setup
function.
Signed-off-by: Devin Heitmueller <dheitmueller@hauppauge.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
The cx231xx_set_Colibri_For_LowIF() function is only ever called if the tuner
has a DIF (see vidioc_s_frequency() in cx231xx-video.c). Hence, we do not
need to do a board specific check in this function.
Signed-off-by: Devin Heitmueller <dheitmueller@hauppauge.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
The current code was deciding whether a DIF was present based on the board
profile. However, this is just another thing for someone to get wrong when
adding new boards. Make the decision based on the tuner instead, so that a
developer adding new boards only needs to specify which tuner the device has.
Of course, the first time somebody adds a board with a tuner other than xc5000
or tda18271, he/she will need to add another line for that tuner. But we
provide a friendly message in dmesg to let them know that.
Signed-off-by: Devin Heitmueller <dheitmueller@hauppauge.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Nobody is ever going to implement an i2c based IR controller on a bridge that
has an onboard universal IR receiver. This stuff was all copied from em28xx,
which has old enough versions of the chip that some didn't have onboard IR.
Remove the stubs related to i2c based IR (keeping the cx231xx-input code).
Signed-off-by: Devin Heitmueller <dheitmueller@hauppauge.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Move a printk() message which refers to enabling the cx23417 so that it only
shows up on a board that has the cx23417.
Signed-off-by: Devin Heitmueller <dheitmueller@hauppauge.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
The video grabber reference design (Veyron) does not have a tuner input, so
do not have it defined in the board profile.
Signed-off-by: Devin Heitmueller <dheitmueller@hauppauge.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Extend the board profile structure to allow configuration of the output mode.
Right now they are all doing VIP 1.1 format, but we have a board that needs
ITU656 format (which hasn't been checked in yet).
Signed-off-by: Devin Heitmueller <dheitmueller@hauppauge.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Add initial support for the Hauppauge USBLive 2 (2040:c200). Note that I
had to copy a bunch of the case statements used for the Conexant video grabber
reference design (which also doesn't have a tuner). This will likely need to
be refactored out into the board profile.
Signed-off-by: Devin Heitmueller <dheitmueller@hauppauge.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
The tuner is on i2c port 3 just like all the reference designs. Having it
improperly set to port #1 causes the tuner initialization to fail when enabling
the device.
Signed-off-by: Devin Heitmueller <dheitmueller@hauppauge.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
If switching to a tuner input, reset the standard and tune to the last known
frequency. We need to do this in particular for this bridge since the tuner
gets powered down when captuing on the composite or s-video inputs.
Signed-off-by: Devin Heitmueller <dheitmueller@hauppauge.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Remove a hack which was jammed into s_input to force the device into bulk mode
at runtime (an abuse of the API). If this sort of functionality is actually
needed (aside from the existing "transfer_mode" modprobe variable), a patch
can be submitted which makes use of a private control.
Signed-off-by: Devin Heitmueller <dheitmueller@hauppauge.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
The Exeter hardware design does not use GPIOs to manage whether its in
digital mode or analog mode, but we need to setup the power control properly.
For that board, setup power control and remove the mux select call. It is
highly likely that this change could be used by other boards as well, which
would make power management cleaner (fixing known issues transitioning between
analog and digital mode).
Signed-off-by: Devin Heitmueller <dheitmueller@hauppauge.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
You cannot call the video_mux routine from within the isoc setup, because that
code is shared with the digital isoc handler. This was causing the GPIOs and
power control to be put into the wrong state when starting up digital mode.
Signed-off-by: Devin Heitmueller <dheitmueller@hauppauge.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
We need to clear out the field before setting individual bits, or else we end
up with a union of whatever was there and what we are trying to set. For
example, switching to digital mode ends up being 0x30 instead of 0x10 if we
were previously in analog tv mode.
Signed-off-by: Devin Heitmueller <dheitmueller@hauppauge.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Move the responsibility for setting up the horizontal and vertical scalers
entirely to the cx25840 driver. The cx231xx-avcore was actually programming
garbage into the HSCALE_CTRL and VSCALE_CTRL registers (because of differences
in how the em28xx driver worked, which the cx231xx driver was derived from).
The net effect is that the scaler now works properly (tested with both PAL
and NTSC under mplayer and tvtime).
This patch also gets rid of cx25840 errors showing up in dmesg which say
"720x480 is not a valid size" (since we now properly setup the size of the
active video area).
Signed-off-by: Devin Heitmueller <dheitmueller@hauppauge.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Change the log level from info to debug for some log events that occur
frequently and should never need to be seen in normal operation.
Signed-off-by: Devin Heitmueller <dheitmueller@hauppauge.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
There is no need for a switch statement here. Use the contents of the board
profile to dictate the tuner driver and i2c address. Eventually if a board
ever comes around which has a different i2c bus than #1, well that should be a
field in the board profile as well.
Signed-off-by: Devin Heitmueller <dheitmueller@hauppauge.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
The current code was sending one videobuf per field (despite having specified
V4L2_FIELD_SEQ_TB during setup). As a result, application which used the
read() interface would work, except they would sometimes have the fields
reversed (depending on the luck of which field the device was on when the
application started VBI capture). The net effect was that CC decoding would
only work about 50% of the time.
Restructure the VBI code a bit so that works like all the other drivers, such
that both fields are delivered in a single videobuf buffer, which ensures that
they are always received in a predictable order.
Signed-off-by: Devin Heitmueller <dheitmueller@hauppauge.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
The VBI sampling rate and offset were incorrectly specified, which resulted in
CC data not being rendered under zvbi or tvtime.
Set the fields correctly.
Signed-off-by: Devin Heitmueller <dheitmueller@hauppauge.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Change a %x to a %p since the variable is a pointer
Signed-off-by: Devin Heitmueller <dheitmueller@hauppauge.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Run Lindent and fix a few spacing issues.
This patch makes no functional change to the driver.
Signed-off-by: Devin Heitmueller <dheitmueller@hauppauge.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Configure the tda18271 to use a smaller transaction size by default, which
works around some sort of i2c bug in the Polaris driver (which needs to be
debugged).
This should be safe for other boards (being in tuner-core means it will be
enabled by default), although testing needs to be done.
Signed-off-by: Devin Heitmueller <dheitmueller@hauppauge.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Fix case where analog calls come in while the DVB side of the board is still
initializing. This patch is actually just an exact port of the same patch
made by Mauro to em28xx in hg rev 14762.
Signed-off-by: Devin Heitmueller <dheitmueller@hauppauge.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Add support for various Hauppauge EXETER designs.
Note by DJH: fixed a few minor 'make checkpatch' warnings before commit.
Signed-off-by: Michael Krufky <mkrufky@kernellabs.com>
Signed-off-by: Devin Heitmueller <dheitmueller@hauppauge.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Introduce a new driver for the s5h1432
Signed-off-by: Palash Bandyopadhyay <palash.bandyopadhyay@conexant.com>
Signed-off-by: Devin Heitmueller <dheitmueller@hauppauge.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Errors found by the checkpatch.pl tool.
[mchehab@redhat.com: merged a series of CodingStyle cleanup patches for cx25851. They're all from the same author, and patches the same driver]
Signed-off-by: Ruslan Pisarev <ruslan@rpisarev.org.ua>
Cc: Palash Bandyopadhyay <Palash.Bandyopadhyay@conexant.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
fix "ERROR: space prohibited after that open parenthesis '('"
This is a patch to the cx25821-audio-upstream.h file that fixed up a
space errors found by the checkpatch.pl tools.
Signed-off-by: Ruslan Pisarev <ruslan@rpisarev.org.ua>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
This allows GStreamer to pick appropriate framerates and resolutions
based on desired capture parameters.
Signed-off-by: Daniel Drake <dsd@laptop.org>
Acked-by: Jonathan Corbet <corbet@lwn.net>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
This patch, which basically reverts 6d77444ac, fixes an occasional
on-boot or on-capture hang on the XO-1 laptop.
It seems like the cafe hardware is flakier than we thought and that in
some cases, the commands get executed but are never reported as completed
(even if we substantially increase the delays before reading registers).
Reintroduce the 1-second CAFE_SMBUS_TIMEOUT to catch and avoid this
strange hardware bug.
Signed-off-by: Daniel Drake <dsd@laptop.org>
Acked-by: Jonathan Corbet <corbet@lwn.net>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
