| Age | Commit message (Collapse) | Author |
|---|
|
This patch merges the ir_input_dev and ir_dev_props structs into a single
struct called rc_dev. The drivers and various functions in rc-core used
by the drivers are also changed to use rc_dev as the primary interface
when dealing with rc-core.
This means that the input_dev is abstracted away from the drivers which
is necessary if we ever want to support multiple input devs per rc device.
The new API is similar to what the input subsystem uses, i.e:
rc_device_alloc()
rc_device_free()
rc_device_register()
rc_device_unregister()
[mchehab@redhat.com: Fix compilation on mceusb and cx231xx, due to merge conflicts]
Signed-off-by: David Härdeman <david@hardeman.nu>
Acked-by: Jarod Wilson <jarod@redhat.com>
Tested-by: Jarod Wilson <jarod@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
|
|
cx88 only depends on VIDEO_IR because it needs ir_extract_bits().
Move that function to ir-core.h and make it inline.
Lots of drivers had dependencies on VIDEO_IR when they really
wanted IR_CORE.
The only remaining drivers to depend on VIDEO_IR are bt8xx and
saa7134 (ir_rc5_timer_end is the only function exported by
ir-functions).
Rename VIDEO_IR -> IR_LEGACY to give a hint to anyone writing or
converting drivers to IR_CORE that they do not want a dependency
on IR_LEGACY.
Signed-off-by: David Härdeman <david@hardeman.nu>
Acked-by: Jarod Wilson <jarod@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
|
|
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
|
|
Although cx231xx has a very good IR support, already supported by
mceusb driver, some designs decided to add a separate I2C
microcontroller chip in order to handle IR.
Due to that, add a glue to ir-kbd-i2c is needed, in order to support
those devices.
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
|
|
By comparing the traffic between Pixelview (cx23102-based and Kworld
(saa7134-based), the only difference is at register 0xd5. After some
tests, It seems that it is used to change mode between serial and parallel.
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
|
|
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
|
|
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
|
|
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
|
|
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>
|
|
All of the hard problems for BKL removal appear to be solved in the
v4l-dvb/master tree. This removes the BKL from the various open
functions that do not need it, or only use it to protect an
open count.
The zoran driver is nontrivial in this regard, so I introduce
a new mutex that locks both the open/release and the ioctl
functions. Someone with access to the hardware can probably
improve that by using the existing lock in all cases.
Finally, all drivers that still use the locked version of the
ioctl function now get called under a new mutex instead of
the BKL.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
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 was supposed to be an unlock on the error path.
Signed-off-by: Dan Carpenter <error27@gmail.com>
Acked-by: Devin Heitmueller <dheitmueller@hauppauge.com>
Cc: Palash Bandyopadhyay < palash.bandyopadhyay@conexant.com>
Cc: Sri Deevi <Srinivasa.Deevi@conexant.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
|
|
In file included from drivers/media/video/cx231xx/cx231xx-audio.c:40:
drivers/media/video/cx231xx/cx231xx.h:559: error: field ‘frontends’ has incomplete type
make[4]: ** [drivers/media/video/cx231xx/cx231xx-audio.o] Erro 1
make[3]: ** [drivers/media/video/cx231xx] Erro 2
make[2]: ** [drivers/media/video] Erro 2
make[1]: ** [drivers/media] Erro 2
make: ** [drivers] Erro 2
Reported-by: Marcio Araujo Alves <froooozen@gmail.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
|
|
Polaris design uses MCE support. Instead of reinventing the wheel,
just let mceusb handle the remote controller.
Acked-by: Jarod Wilson <jarod@redhat.com>
Acked-by: Sri Devi <Srinivasa.Deevi@conexant.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
|
|
Interface 0 is used by IR. The current driver starts initializing
on it, finishing on interface 6. Change the logic to only handle
interface 1. This allows another driver (mceusb) to take care of
the IR interface.
Reviewed-by: Jarod Wilson <jarod@redhat.com>
Acked-by: Sri Devi <Srinivasa.Deevi@conexant.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
|
|
Fixes these build errors and warnings:
drivers/media/video/cx231xx/cx231xx-417.c: In function 'cx231xx_load_firmware':
drivers/media/video/cx231xx/cx231xx-417.c:943: error: implicit declaration of function 'vmalloc'
drivers/media/video/cx231xx/cx231xx-417.c:943: warning: cast to pointer from integer of different size
drivers/media/video/cx231xx/cx231xx-417.c:950: warning: cast to pointer from integer of different size
drivers/media/video/cx231xx/cx231xx-417.c:1039: error: implicit declaration of function 'vfree'
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
|
|
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>
|
|
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>
|
|
Acked-by: Sri Deevi <Srinivasa.Deevi@conexant.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.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>
|
|
This allows usage of a tool at v4l-utils tree to parse URB messages
and display them to userspace. The tool is available at:
http://git.linuxtv.org/v4l-utils.git?a=blob;f=contrib/cx231xx/parse_cx231xx.pl;hb=HEAD
Acked-by: Sri Deevi <Srinivasa.Deevi@conexant.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
|
|
ERROR: "cx2341x_mpeg_ctrls" [drivers/media/video/cx231xx/cx231xx.ko] undefined!
ERROR: "cx2341x_fill_defaults" [drivers/media/video/cx231xx/cx231xx.ko] undefined!
ERROR: "cx2341x_log_status" [drivers/media/video/cx231xx/cx231xx.ko] undefined!
ERROR: "cx2341x_ctrl_get_menu" [drivers/media/video/cx231xx/cx231xx.ko] undefined!
ERROR: "cx2341x_update" [drivers/media/video/cx231xx/cx231xx.ko] undefined!
ERROR: "cx2341x_ctrl_query" [drivers/media/video/cx231xx/cx231xx.ko] undefined!
ERROR: "cx2341x_ext_ctrls" [drivers/media/video/cx231xx/cx231xx.ko] undefined!
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>
|
