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>
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>
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>
