There are a few errors at the PLL calculus, causing the device
to use wrong values.
While here, change the calculus to use 32 bits, as there's no
need for 64 bits there.
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com> Tested-by: Antti Palosaari <crope@iki.fi>
The rtl-sdr library disabled IMR callibration. While I'm not sure
yet why, it could be a good idea to add a modprobe parameter here,
to allow to also disable it. There are two rationale behind it:
- It helps to compare USB dumps between rtl-sdr and the Kernel module;
- If rtl-sdr disabled it, perhaps there's a good reason (e. g. it
might not be actually working, or it might be causing some trouble).
For both cases, it seems useful to add a modprobe parameter to allow
testing the device with both configurations.
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com> Tested-by: Antti Palosaari <crope@iki.fi>
Add the code to set the GPIO for this tuner. This code is
currently unused, so it is kept there only for completeness.
With this patch there are just two things that got left from
the original driver:
- At standby, there's another mode, not used by rtl2832u.
Not sure if it might be needed in the future, but I suspect
it is not used at all;
- There is a "fast tune" mode. As nor DVB or V4L API supports
it, it seems an overkill to implement it.
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com> Tested-by: Antti Palosaari <crope@iki.fi>
This code seems to calibrate I/Q phase and gain during the
device initialization.
This is done only once, and it doesn't seem to be needed to
happen after resuming.
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com> Tested-by: Antti Palosaari <crope@iki.fi>
The rtl-sdr library, from where this driver was initially
based, doesn't use half PLL clock, but this is used on
the Realtek Kernel driver. So, also do the same here.
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com> Tested-by: Antti Palosaari <crope@iki.fi>
This tuner works with 2 modes: automatic gain mode and manual
gain mode. Put it into automatic mode, as we currently don't
have any API for manual gain adjustment.
The logic to allow setting the manual mode is there, as it is
just a few extra code. This way, if/when we latter add support
for setting the gain mode, the code is already there.
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com> Tested-by: Antti Palosaari <crope@iki.fi>
[media] r820t: Add a tuner driver for Rafael Micro R820T silicon tuner
This driver was written from scratch, based on an existing driver
that it is part of rtl-sdr git tree, released under GPLv2:
https://groups.google.com/forum/#!topic/ultra-cheap-sdr/Y3rBEOFtHug
https://github.com/n1gp/gr-baz
http://cgit.osmocom.org/rtl-sdr/plain/src/tuner_r820t.c
(there are also other variants of it out there)
>From what I understood from the threads, the original driver was converted
to userspace from a Realtek tree. I couldn't find the original tree.
However, the original driver look awkward on my eyes. So, I decided to
write a new version from it from the scratch, while trying to reproduce
everything found there.
TODO:
- After locking, the original driver seems to have some routines to
improve reception. This was not implemented here yet.
- RF Gain set/get is not implemented.
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com> Tested-by: Antti Palosaari <crope@iki.fi>
[media] sta2x11_vip: Fix compilation if I2C is not set
From Fengguang Wu <fengguang.wu@intel.com>:
> drivers/media/pci/sta2x11/sta2x11_vip.c: In function 'sta2x11_vip_init_one':
> drivers/media/pci/sta2x11/sta2x11_vip.c:1314:2: error: implicit declaration of function 'i2c_get_adapter' [-Werror=implicit-function-declaration]
> drivers/media/pci/sta2x11/sta2x11_vip.c:1314:15: warning: assignment makes pointer from integer without a cast [enabled by default]
> drivers/media/pci/sta2x11/sta2x11_vip.c:1330:2: error: implicit declaration of function 'i2c_put_adapter' [-Werror=implicit-function-declaration]
And also:
> warning: (STA2X11_VIP) selects VIDEO_ADV7180 which has unmet direct dependencies (MEDIA_SUPPORT && VIDEO_V4L2 && I2C)
> drivers/media/i2c/adv7180.c: In function '__adv7180_status':
> drivers/media/i2c/adv7180.c:194:2: error: implicit declaration of function 'i2c_smbus_read_byte_data' [-Werror=implicit-function-declaration]
> drivers/media/i2c/adv7180.c: In function 'adv7180_s_routing':
> drivers/media/i2c/adv7180.c:251:2: error: implicit declaration of function 'i2c_smbus_write_byte_data' [-Werror=implicit-function-declaration]
> drivers/media/i2c/adv7180.c: In function 'adv7180_probe':
> drivers/media/i2c/adv7180.c:551:2: error: implicit declaration of function 'i2c_check_functionality' [-Werror=implicit-function-declaration]
> drivers/media/i2c/adv7180.c:554:2: error: implicit declaration of function 'i2c_adapter_id' [-Werror=implicit-function-declaration]
> drivers/media/i2c/adv7180.c: At top level:
> drivers/media/i2c/adv7180.c:663:1: warning: data definition has no type or storage class [enabled by default]
> drivers/media/i2c/adv7180.c:663:1: warning: type defaults to 'int' in declaration of 'module_i2c_driver' [-Wimplicit-int]
> drivers/media/i2c/adv7180.c:663:1: warning: parameter names (without types) in function declaration [enabled by default]
> drivers/media/i2c/adv7180.c:649:26: warning: 'adv7180_driver' defined but not used [-Wunused-variable]
[media] it913x: rename its tuner driver to tuner_it913x
There are three drivers with *it913x name on it, and they all
belong to the same device:
a tuner, at it913x.c;
a frontend: it913x-fe.c;
a bridge: it913x.c, renamed to dvb_usb_it913x by the
building system.
This is confusing. Even more confusing are the two .c files with
the same name under different directories, with different contents
and different functions. So, prepend the tuner one.
This also breaks the out-of-tree compilation system.
Reported-by: Frederic Fays <frederic.fays@gmail.com> Acked-by: Antti Palosaari <crope@iki.fi> Reviewed-by: Antti Palosaari <crope@iki.fi> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Fix mceusb_cmdsize() which returns incorrect datasize=0 for
sub-commands MCE_RSP_GETPORTSTATUS, MCE_RSP_GETWAKESOURCE,
MCE_RSP_EQDEVDETAILS, MCE_RSP_EQEMVER, and MCE_RSP_EQIRNUMPORTS.
While here, change mceusb_cmdsize() name to reflect that it returns
data size not cmd size.
Signed-off-by: William Steidtmann <billstei@hbci.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Randy Dunlap [Tue, 16 Apr 2013 14:33:22 +0000 (11:33 -0300)]
[media] staging/media: fix go7007 dependencies and build
VIDEO_GO7007 uses usb interfaces so it should depend on USB.
It also selects CYPRESS_FIRMWARE, which depends on USB.
Fixes build errors and a kconfig warning:
go7007-loader.c:(.text+0xcc7d0): undefined reference to `usb_get_dev'
go7007-loader.c:(.init.text+0x49f0): undefined reference to `usb_register_driver'
go7007-loader.c:(.exit.text+0x17ce): undefined reference to `usb_deregister'
warning: (DVB_USB_AZ6007 && VIDEO_GO7007) selects CYPRESS_FIRMWARE which has unmet direct dependencies (MEDIA_SUPPORT && USB)
Signed-off-by: Randy Dunlap <rdunlap@infradead.org> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Michal Marek [Tue, 16 Apr 2013 11:06:30 +0000 (08:06 -0300)]
[media] em28xx: Put remaining .vidioc_g_chip_info instance under ADV_DEBUG
Commit cd634f1 ("[media] v4l2: put VIDIOC_DBG_G_CHIP_NAME under
ADV_DEBUG") missed the initializer of radio_ioctl_ops:
drivers/media/usb/em28xx/em28xx-video.c:1830:2: error: unknown field 'vidioc_g_chip_info' specified in initializer
drivers/media/usb/em28xx/em28xx-video.c:1830:26: error: 'vidioc_g_chip_info' undeclared here (not in a function)
Signed-off-by: Michal Marek <mmarek@suse.cz> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
[media] cxd2820r_t2: Fix a warning: stream_id is unsigned
drivers/media/dvb-frontends/cxd2820r_t2.c: In function 'cxd2820r_set_frontend_t2':
drivers/media/dvb-frontends/cxd2820r_t2.c:128:2: warning: comparison of unsigned expression < 0 is always false [-Wtype-limits]
Antti Palosaari [Fri, 12 Apr 2013 16:59:02 +0000 (13:59 -0300)]
[media] rc: add rc-reddo
It is very similar than rc-msi-digivox-iii but new keytable is needed
as there is one existing scancode mapped to different button. Also that
one has less buttons.
NEC extended protocol with address 0x61d6.
Signed-off-by: Antti Palosaari <crope@iki.fi> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
[media] rc: ene_ir: fix potential double free in ene_probe()
Since rc_unregister_device() frees its argument, the subsequently
call to rc_free_device() on the same variable will cause a double
free bug. Fix by set argument to NULL, thus when fall through to
rc_free_device(), nothing will be done there.
[media] rc: nuvoton-cir: fix potential double free in nvt_probe()
Since rc_unregister_device() frees its argument, the subsequently
call to rc_free_device() on the same variable will cause a double
free bug. Fix by set argument to NULL, thus when fall through to
rc_free_device(), nothing will be done there.
[media] rc: ite-cir: fix potential double free in ite_probe()
Since rc_unregister_device() frees its argument, the subsequently
call to rc_free_device() on the same variable will cause a double
free bug. Fix by set argument to NULL, thus when fall through to
rc_free_device(), nothing will be done there.
[media] rc: winbond-cir: fix potential double free in wbcir_probe()
Since rc_unregister_device() frees its argument, the subsequently
call to rc_free_device() on the same variable will cause a double
free bug. Fix by set argument to NULL, thus when fall through to
rc_free_device(), nothing will be done there.
[media] soc-camera: fix typos in the default format-conversion table
The default format conversion table mbus_fmt[] in soc_mediabus.c lists
"natural" conversions between media-bus and fourcc pixel formats, that are
achieved by storing data from the bus in RAM exactly as it arrives, only
possibly padding missing high or low bits. Such data acquisition mode
cannot change data endianness, therefore two locations with opposite
endianness are erroneous. This change might affest the omap1-camera driver,
existing configurations should be verified.
Lad, Prabhakar [Fri, 22 Mar 2013 07:53:13 +0000 (04:53 -0300)]
[media] media: davinci: vpbe: venc: move the enabling of vpss clocks to driver
The vpss clocks were enabled by calling a exported function from a driver
in a machine code. calling driver code from platform code is incorrect way.
This patch fixes this issue and calls the function from driver code itself.
Lad, Prabhakar [Fri, 22 Mar 2013 07:53:12 +0000 (04:53 -0300)]
[media] media: davinci: vpss: enable vpss clocks
By default the VPSS clocks were enabled in capture driver
for davinci family which creates duplicates for dm355/dm365/dm644x.
This patch adds support to enable the VPSS clocks in VPSS driver,
which avoids duplication of code and also adding clock aliases.
This patch uses PM runtime API to enable/disable clock, instead
of DaVinci clock framework. con_ids for master and slave clocks of
vpss is added in pm_domain.
This patch cleanups the VPSS clock enabling in the capture driver,
and also removes the clock alias in machine file. Along side adds
a vpss slave clock for DM365 as mentioned by Sekhar
(https://patchwork.kernel.org/patch/1221261/).
The Suspend/Resume in dm644x_ccdc.c which enabled/disabled the VPSS clock
is now implemented as part of the VPSS driver.
Signed-off-by: Lad, Prabhakar <prabhakar.csengg@gmail.com> Acked-by: Sekhar Nori <nsekhar@ti.com> Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
drivers/media/platform/davinci/Kconfig uses selects where
it should be using 'depends on'. This results in warnings of
the following sort when doing randconfig builds.
warning: (VIDEO_DM6446_CCDC && VIDEO_DM355_CCDC && VIDEO_ISIF && VIDEO_DAVINCI_VPBE_DISPLAY) selects VIDEO_VPSS_SYSTEM which has unmet direct dependencies (MEDIA_SUPPORT && V4L_PLATFORM_DRIVERS && ARCH_DAVINCI)
The VPIF kconfigs had a strange 'select' and 'depends on' cross
linkage which have been fixed as well by removing unneeded
VIDEO_DAVINCI_VPIF config symbol.
Similarly, remove the unnecessary VIDEO_VPSS_SYSTEM and
VIDEO_VPFE_CAPTURE. They don't select any independent functionality
and were being used to manage code dependencies which can
be handled using makefile.
Selecting video modules is now dependent on all ARCH_DAVINCI
instead of specific EVMs and SoCs earlier. This should help build
coverage. Remove unnecessary 'default y' for some config symbols.
While at it, fix the Kconfig help text to make it more readable
and fix names of modules created during module build.
Rename VIDEO_ISIF to VIDEO_DM365_ISIF as per suggestion from
Prabhakar.
This patch has only been build tested; I have tried to not break
any existing assumptions. I do not have the setup to test video,
so any test reports welcome.
Reported-by: Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by: Sekhar Nori <nsekhar@ti.com>
[prabhakar.csengg@gmail.com: Fixed typo] Signed-off-by: Lad, Prabhakar <prabhakar.csengg@gmail.com> Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Frank Schaefer [Thu, 11 Apr 2013 18:56:47 +0000 (15:56 -0300)]
[media] em28xx: improve em2710/em2820 distinction
Chip id 18 is used by the em2710 and em2820.
The current code assumes that if the device is a camera, the chip is an em2710
and an em2820 otherwise.
But it turned out that the em2820 is also used in camera devices.
"Silvercrest 1.3 MPix" webcams for example are available with both chips.
Fortunately both variants are using different generic USD IDs which give us a
hint about the used chip.
Signed-off-by: Frank Schäfer <fschaefer.oss@googlemail.com> Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Frank Schaefer [Thu, 11 Apr 2013 18:56:01 +0000 (15:56 -0300)]
[media] em28xx: fix snapshot button support
The snapshot button support is currently broken, because module em28xx-rc is
loaded only if the device has remote control support.
Fix it by also loading this module if the device has a snapshot button.
Signed-off-by: Frank Schäfer <fschaefer.oss@googlemail.com> Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Hans Verkuil [Wed, 10 Apr 2013 17:26:52 +0000 (14:26 -0300)]
[media] hdpvr: allow g/s/enum/querystd when in legacy mode
Both MythTV and gstreamer expect that they can set/get/query/enumerate the
standards, even if the input is the component input for which standards
really do not apply.
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Hans Verkuil [Sat, 6 Apr 2013 09:00:17 +0000 (06:00 -0300)]
[media] hdpvr: remove hdpvr_fh and just use v4l2_fh
This prepares the driver for priority and control event handling.
This patch also checks for correct streaming ownership and it makes a
small improvement to the encoder_cmd ioctls: always zero 'flags' and
drop the memset of 'raw' as that is already done by the v4l2 core.
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Hans Verkuil [Wed, 20 Mar 2013 17:31:34 +0000 (14:31 -0300)]
[media] v4l2-dv-timings.h: add 480i59.94 and 576i50 CEA-861-E timings
These formats are supported by the HDPVR, but they were missing in the list.
Note that these formats are different from the common PAL/NTSC/SECAM formats
since all color channels are transmitted separately and so there is no PAL
or NTSC or SECAM color encoding involved.
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
This was set to 1 << 0 which is the same as V4L2_DV_FL_REDUCED_BLANKING.
It should be 1 << 3 instead. Luckily interlaced formats are rarely used,
which is why this bug wasn't seen until now.
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Hans Verkuil [Mon, 8 Apr 2013 09:31:30 +0000 (06:31 -0300)]
[media] radio-si4713: use V4L2 core lock
Simplify locking by using the V4L2 core lock mechanism. This allows us to
remove all locking from the i2c module. This will also simplify the upcoming
conversion to the control framework.
Hans Verkuil [Wed, 3 Apr 2013 07:08:19 +0000 (04:08 -0300)]
[media] v4l2: drop V4L2_CHIP_MATCH_SUBDEV_NAME
After using the new VIDIOC_DBG_G_CHIP_NAME ioctl I realized that the matching
by name possibility is useless. Just drop it and rename MATCH_SUBDEV_IDX to
just MATCH_SUBDEV.
The v4l2-dbg utility is much better placed to match by name by just enumerating
all bridge and subdev devices until chip_name.name matches.
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Hans Verkuil [Wed, 27 Mar 2013 11:04:23 +0000 (08:04 -0300)]
[media] v4l2: put VIDIOC_DBG_G_CHIP_NAME under ADV_DEBUG
Only enable this ioctl if the VIDEO_ADV_DEBUG config option is set. This
prevents abuse from both userspace and kernelspace (some bridge drivers
abuse DBG_G_CHIP_IDENT, lets prevent that from happening again with this
ioctl).
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Hans Verkuil [Sat, 6 Apr 2013 07:41:29 +0000 (04:41 -0300)]
[media] tuner-core/simple: get_rf_strength can be tuner mode specific
The get_rf_strength op in tuner-simple is valid only for the radio mode.
But due to the way get_signal in analog_demod_ops was designed it would
overwrite the signal value with a bogus value when in TV mode.
Pass a pointer to the signal value instead, and when not in radio mode
leave it alone in the tuner-simple.
This broke in commit 030755bde42bbed133182b0ece7c7a9c759478e8
(tuner-core: call has_signal for both TV and radio) in kernel 3.6. Before
that this was working correctly. That commit did the right thing, but what
wasn't realized at the time was that tuner-simple should have been updated
as well to restrict setting the signal strength to the radio mode only.
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Hans Verkuil [Sat, 6 Apr 2013 07:35:27 +0000 (04:35 -0300)]
[media] tuner-core/tda9887: get_afc can be tuner mode specific
The get_afc op in tda9887 is valid only for the radio mode.
But due to the way get_afc in analog_demod_ops was designed it would
overwrite the afc value with a bogus value when in TV mode.
Pass a pointer to the afc value instead, and when not in radio mode
leave it alone in the tda9887.
This broke a long time ago in 2.6.19 when the get_afc op was introduced.
Before that the afc was only set for radio mode in the tda9887.
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
projects / karo-tx-linux.git / log