The PMT table for AC3 audio is different.
Thanks to Dmitry Belimov for providing the table data.
Signed-off-by: Hans Verkuil <hverkuil@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
v4l2_ctrl_query_menu_valid_items() makes it easy to handle control menus
that have a lot of invalid 'holes'. For example, many MPEG encoders only
support a limited subset of audio bitrates. In that case a driver can
specify an array listing the set of valid bitrates and pass that to
this function.
Signed-off-by: Hans Verkuil <hverkuil@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Add function that returns the control name. Allows this to be used in
places where the normal v4l2_ctrl_query_fill() function cannot be
used (e.g. uvc).
Signed-off-by: Hans Verkuil <hverkuil@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Some models of the saa6752hs support AC-3. Extend the API with the
necessary controls for AC-3.
Signed-off-by: Hans Verkuil <hverkuil@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Adds Advanced Audio Coding (AAC) and MPEG-4 Advanced Video Coding
(AVC/H.264) as audio/video codecs to the extended controls API.
Updates cx2341x driver to the new values.
Signed-off-by: Janne Grunau <j@jannau.net>
Signed-off-by: Hans Verkuil <hverkuil@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Thanks to Sistema Fenix (http://www.sistemafenix.com.br/) and CDI Brasil
(www.cdibrasil.com.br/) for sponsoring this development.
Signed-off-by: Gilberto <gilberto@sistemafenix.com.br>
Signed-off-by: Mauro Carvalho Chehab <mchehab@infradead.org>
Thanks to Sistema Fenix (http://www.sistemafenix.com.br/) and CDI Brasil
(www.cdibrasil.com.br/) for sponsoring this development.
Signed-off-by: Gilberto <gilberto@sistemafenix.com.br>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
This patch adds the capability of decoding NEC protocol, received via GPIO18 line.
This GPIO port can trigger saa7134 IRQ.
A future improvement would be to make it a little more generic to work also
with GPIO16 line.
A pure IRQ code didn't work, since some delays were introduced on the tests we
did.
A possible approach would be to use polling at a rate of 2.5 ms or less. If a
new code were taken, a code similar to nec_task() could be used. However, this
would add an extra overhead to kernel, and will consume more power.
Due to that, we took an hybrid approach: an IRQ upper half to trigger when a
new key is received and a bottom half to convert pulse-distance into a keycode.
The bottom half is polling based, to improve performance. During the bottom
half proccess, GPIO18 IRQ line is disabled, preventing IRQ reentrancy and
improving performance a little bit.
Thanks to Sistema Fenix (http://www.sistemafenix.com.br/) for sponsoring this
development.
Signed-off-by: Gilberto <gilberto@sistemafenix.com.br>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
The BKL is now moved from the video_open function in v4l2-dev.c to the
various drivers. It seems about a third of the drivers already has a
lock of some sort protecting the open(), another third uses
video_exclusive_open (yuck!) and the last third required adding the
BKL in their open function.
Signed-off-by: Hans Verkuil <hverkuil@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
ivtv_claim_stream() can now become static.
Signed-off-by: Adrian Bunk <bunk@kernel.org>
Signed-off-by: Hans Verkuil <hverkuil@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Use "[%04x:%04x]" for PCI vendor/device IDs to follow the format
used by lspci(8).
Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
It seems cosmetically better to let USB drivers be the last one.
Also, two SOC drivers were using select, instead of depends on SOC_CAMERA.
Since select has some drawbacks when checking for dependencies, convert those
two into depends on.
Cc: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
* 'for-linus' of master.kernel.org:/home/rmk/linux-2.6-arm: (236 commits)
[ARM] 5300/1: fixup spitz reset during boot
[ARM] 5295/1: make ZONE_DMA optional
[ARM] 5239/1: Palm Zire 72 power management support
[ARM] 5298/1: Drop desc_handle_irq()
[ARM] 5297/1: [KS8695] Fix two compile-time warnings
[ARM] 5296/1: [KS8695] Replace macro's with trailing underscores.
[ARM] pxa: allow multi-machine PCMCIA builds
[ARM] pxa: add preliminary CPUFREQ support for PXA3xx
[ARM] pxa: add missing ACCR bit definitions to pxa3xx-regs.h
[ARM] pxa: rename cpu-pxa.c to cpufreq-pxa2xx.c
[ARM] pxa/zylonite: add support for USB OHCI
[ARM] ohci-pxa27x: use ioremap() and offset for register access
[ARM] ohci-pxa27x: introduce pxa27x_clear_otgph()
[ARM] ohci-pxa27x: use platform_get_{irq,resource} for the resource
[ARM] ohci-pxa27x: move OHCI controller specific registers into the driver
[ARM] ohci-pxa27x: introduce flags to avoid direct access to OHCI registers
[ARM] pxa: move I2S register and bit definitions into pxa2xx-i2s.c
[ARM] pxa: simplify DMA register definitions
[ARM] pxa: make additional DCSR bits valid for PXA3xx
[ARM] pxa: move i2c register and bit definitions into i2c-pxa.c
...
Fixed up conflicts in
arch/arm/mach-versatile/core.c
sound/soc/pxa/pxa2xx-ac97.c
sound/soc/pxa/pxa2xx-i2s.c
manually.
NULL function pointers are very bad security wise. This one got caught by
kerneloops.org quite a few times, so it's happening in the field....
Fix is simple, check the function pointer for NULL, like 6 other places
in the same function are already doing.
Signed-off-by: Arjan van de Ven <arjan@linux.intel.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
1. DRCMRxx is no longer recommended, use DRCMR(xx) instead, and
pass DRCMR index by "struct resource" if possible
2. DCSRxx, DDADRxx, DSADRxx, DTADRxx, DCMDxx is never used, use
DCSR(), DDADR(), DSADR(), DTADR(), DCMD() instead
Signed-off-by: Eric Miao <eric.miao@marvell.com>
Acked-by: Nicolas Pitre <nico@cam.org>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
commit 0d3244d643 ("V4L/DVB (8342):
sh_mobile_ceu_camera: Add SuperH Mobile CEU driver V3") introduced
VIDEO_SH_MOBILE_CEU, which selects VIDEOBUF_DMA_CONTIG. This circumvents the
dependency on HAS_DMA of VIDEOBUF_DMA_CONTIG.
Add a dependency on HAS_DMA to VIDEO_SH_MOBILE_CEU to fix this.
Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
Acked-by: Paul Mundt <lethal@linux-sh.org>
Acked-by: Magnus Damm <damm@igel.co.jp>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
While doing some testing using Luca Risolia's sonix driver I noticed that
the video device did not get ACL's set to allow access by locally logged in
users, nor does it show up as a video device in lshal, causing cheese to not
see it.
This turns out to be caused by all of Luca Risolia's drivers not setting
the parent member of the video_device struct. This patch fixes this.
Cc: Luca Risolia <luca.risolia@studio.unibo.it>
Signed-off-by: Hans de Goede <j.w.r.degoede@hhs.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
b2c2-flexcop, dvb/bt8xx and video/bt8xx fails to build on ARM with:
__bad_udelay is specifically designed on ARM to fail when udelay is
called in a bad way. arch/arm/include/asm/delay.h has this to say
about __bad_udelay:
/*
* This function intentionally does not exist; if you see references to
* it, it means that you're calling udelay() with an out of range value.
*
* With currently imposed limits, this means that we support a max delay
* of 2000us. Further limits: HZ<=1000 and bogomips<=3355
*/
extern void __bad_udelay(void);
Solution is to replace udelay by a mdelay and udelay with value less than 2000
Signed-off-by: Thierry MERLE <thierry.merle@free.fr>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
budget.ko fails to build on ARM with:
ERROR: "__bad_udelay" [drivers/media/dvb/ttpci/budget.ko] undefined!
make[1]: *** [__modpost] Error 1
__bad_udelay is specifically designed on ARM to fail when udelay is
called in a bad way. arch/arm/include/asm/delay.h has this to say
about __bad_udelay:
/*
* This function intentionally does not exist; if you see references to
* it, it means that you're calling udelay() with an out of range value.
*
* With currently imposed limits, this means that we support a max delay
* of 2000us. Further limits: HZ<=1000 and bogomips<=3355
*/
extern void __bad_udelay(void);
Solution is to replace udelay by a mdelay and udelay with value less than 2000
Acked-by: Oliver Endriss <o.endriss@gmx.de>
Signed-off-by: Thierry MERLE <thierry.merle@free.fr>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
- Adjust hstart in ov7630 on sn9c103 initdata to shift bayer pattern, this is
the same change as done for the other initdata tables in a previous patch.
- Assign usb-id's for the ov7630 + sn9c103 to gspca if gspca and sn9c102
drivers are both enabled.
Signed-off-by: Hans de Goede <j.w.r.degoede@hhs.nl>
Signed-off-by: Jean-Francois Moine <moinejf@free.fr>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
-Make raw bayer header size change from 20 to 16 affect rev072a only, my 2
rev012a cams both have a header size of 20
-While testing this I also tested the new exposure setting (good work on
finding the register JF), and after quite a bit of testing have found out the
exact meaning of the register, this patch modifies setexposure to control
the exposure over a much wider range.
Signed-off-by: Hans de Goede <j.w.r.degoede@hhs.nl>
Signed-off-by: Jean-Francois Moine <moinejf@free.fr>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
When using the sonixb driver in a dark room and given that the autoexposure
algorithm starts with a setting most suitable for daylight, the picture
produced by the cam may actually be 100% black leading to a avg_lum value of 0,
so an avg_lum value of 0 does not always signal an exposure settings change
(which it normally does). This patch adds a check for the really black image
case and stops dropping all frames as invalid in this case.
Signed-off-by: Hans de Goede <j.w.r.degoede@hhs.nl>
Signed-off-by: Jean-Francois Moine <moinejf@free.fr>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
This patch makes gspca claim the USB-ID for sn9c101/2 cams with a TAS5110C1B
sensor even if both gspca and sn9c102 are enabled, as these cams are much
better supported under gspca (and extensively tested with gspca).
It also removes an usb-id from sn9c102 for one more unsupported bridge
sensor combo.
Signed-off-by: Hans de Goede <j.w.r.degoede@hhs.nl>
Signed-off-by: Jean-Francois Moine <moinejf@free.fr>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
- Add documentation for some known registers
- Add support for vga modes (320x240, 160x120) for sif sensors
- Remove F_RAW sensor flag raw mode should work on any sensor as its a bridge
only thing and keeping the flag was becoming awkward.
- Fixup ov6650 and pas106 auto exposure window settings
Signed-off-by: Hans de Goede <j.w.r.degoede@hhs.nl>
Signed-off-by: Jean-Francois Moine <moinejf@free.fr>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
This patch fixes a memory leak in an error path.
Reported-by: Adrian Bunk <bunk@kernel.org>
Signed-off-by: Adrian Bunk <bunk@kernel.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
video_device_release() does kfree(), which made the following printk()
doing a use-after-free.
printk() first and release then.
Reported-by: Adrian Bunk <bunk@kernel.org>
Signed-off-by: Adrian Bunk <bunk@kernel.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
This adds basic support for the Hauppauge Nova-TD-500 84xxx series.
A future patch will allow for one aerial input to supply both tuners.
With the current code, an aerial must be plugged into each antannae input
in order for both tuners to function.
Signed-off-by: Michael Krufky <mkrufky@linuxtv.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
This comment helps to make the code more readable.
Signed-off-by: Michael Krufky <mkrufky@linuxtv.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Some DVB drivers are incorrectly assuming that the size of
i2c_adapter.name is I2C_NAME_SIZE. Here's a fix.
Also change strncpy to strlcpy, as the former is error-prone (and was
indeed incorrectly used.)
Signed-off-by: Jean Delvare <khali@linux-fr.org>
Acked-by: Uwe Bugla <uwe.bugla@gmx.de>
Reviewed-by: Michael Krufky <mkrufky@linuxtv.org>
Signed-off-by: Steven Toth <stoth@hauppauge.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
1) Lower the hstart setting for all sensor by 1 so that we generate
(compressed) BGGR data just like sn9c102 does (instead of GBRG data)
2) Add support for raw bayer output in the lowest resolutions (not enough
bandwidth for higher resolutions), this should work with all sensors but
to be sure only enable it for sensors where it has been tested.
Signed-off-by: Hans de Goede <j.w.r.degoede@hhs.nl>
Signed-off-by: Jean-Francois Moine <moinejf@free.fr>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Under certain conditions sonixb compressed frame size can get bigger then
the uncompressed size (seen with 0c45:6028), so make the buffers slightly
bigger.
Signed-off-by: Hans de Goede <j.w.r.degoede@hhs.nl>
Signed-off-by: Jean-Francois Moine <moinejf@free.fr>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
-the usb-id table caried several flags which were not usb-id specific but
sensor specific, add a sensor_data array and move these flag there
-fr_h_sz was being abused to store and check which bridge was being used
instead add a bridge member to the sd struct
-now that we have a sensor_data table use that to store pointers to
init_sequences instead of using switch cases on sd->sensor
Signed-off-by: Hans de Goede <j.w.r.degoede@hhs.nl>
Signed-off-by: Jean-Francois Moine <moinejf@free.fr>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
-remove USB-id's from zc0301 for cams for which zc0301.c does not support
the sensor
-remove USB-id's from sn9c102 for cams where sn9c102 does not support the
bridge sensor combination
-no longer make inclusion of usb id's removed from zc0301 and sn9c102
conditional in gspca
-fix conditional inclusion of USB-id's in gspca to also work when the
conflicting drivers are build as a module
-add a number of USB-id's to gspca from various windows .inf files:
0c45:608f from generic sonix sn9c103 inf file (+ ov7630 which we support)
041e:4022 from creative webcam nx pro, same as already supported 041e:401e
0ac8:0301 from generic zc0301 driver which supports many sensors
10fd:804d from typhoon webshot driver (also FlyCAM-USB 300 plus)
Signed-off-by: Hans de Goede <j.w.r.degoede@hhs.nl>
Signed-off-by: Jean-Francois Moine <moinejf@free.fr>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
The USB buffer may be used for DMA and there may be a caching problem
if the buffer is part of the device structure.
Thanks to Alan Stern.
Signed-off-by: Jean-Francois Moine <moinejf@free.fr>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
-Add usb id for 093a:2624 (pac7302)
-Report some controls to userspace with 7302 only, as they are 7302 only
-Add gain and exposure controls
-Add autogain
-Fix 7302 imaged being mirrored by default
Signed-off-by: Hans de Goede <j.w.r.degoede@hhs.nl>
Signed-off-by: Jean-Francois Moine <moinejf@free.fr>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
