Re: [ivtv-devel] tveeprom cannot autodetect tuner! (FQ1216LME MK5)
On Tuesday 26 May 2009 22:21:31 Martin Dauskardt wrote: I should add that the picture quality is with all tested tuner types worse than with my PVR250/350. I don't know if a PVR150 is in generally worse than a PVR250. I can't call it really noisy, but in german I would say the picture is a little bit grobkörnig. It really needs a temporal filter setting of value 8 or more, while my other PVR cards have a nice quality even with value 0. It's always been my impression that the saa7115/msp3400 combo is superior to the cx2584x. I can't prove it, but the PVR150 picture quality is never as sharp as what I get with my PVR350. Regards, Hans I will test whatever you guys want me to test :-) But I am not a programmer, so I need detailled instructions what to patch. My next step will be testing an older v4l2 with an 2.6.27 kernel to see if the audio problem still exists. -- Hans Verkuil - video4linux developer - sponsored by TANDBERG Telecom -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [ivtv-devel] tveeprom cannot autodetect tuner! (FQ1216LME MK5)
On Wednesday 27 May 2009 05:28:19 Ant wrote: Andy Walls wrote: Hermann, There is an FQ1216LME MK3 data sheet here: http://dl.ivtvdriver.org/datasheets/tuners/FQ1216LME%20Mk3.pdf Is it safe to assume that the MK5 is not very different from the MK3? I am no expert on the subject, but I found this reference to the MK3 vs MK5: http://www.nxp.com/acrobat_download/other/products/rf/fq_mk5.pdf Where it says The FQ1200 MK5 family is identical in footprint to the FQ1200 MK3 series, ensuring a quick drop-in replacement. If the MK5 family is designed as a drop in replacement for the MK3 family, I would think there is a good chance it functions exactly the same. Anthony And in addition I have the datasheets for the FM1216ME_MK3, FM1216ME_MK5 and FQ1236MK5. All combined should give enough information to deduce what if any the changes are between the FQ1216LME MK3 and MK5. Please mail me who wants these datasheets and I'll send them to you. Regards, Hans -- Hans Verkuil - video4linux developer - sponsored by TANDBERG Telecom -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] i2c: Simplified CONFIG_I2C=n interface.
Another day, another module-related failure due to the i2c interface
being used in code that optionally uses it:
ERROR: i2c_new_device [drivers/media/video/soc_camera.ko] undefined!
ERROR: i2c_get_adapter [drivers/media/video/soc_camera.ko] undefined!
ERROR: i2c_put_adapter [drivers/media/video/soc_camera.ko] undefined!
ERROR: i2c_unregister_device [drivers/media/video/soc_camera.ko] undefined!
make[2]: *** [__modpost] Error 1
make[1]: *** [modules] Error 2
make: *** [sub-make] Error 2
In the interest of not continually inserting i2c ifdefs in to every
driver that supports an optional i2c interface, this provides a stubbed
set of interfaces for the CONFIG_I2C=n case.
I've covered the obvious ones that cause the majority of the build
failures, anything more involved really ought to have its dependencies
fixed instead.
Signed-off-by: Paul Mundt let...@linux-sh.org
---
include/linux/i2c.h | 109
1 file changed, 109 insertions(+)
diff --git a/include/linux/i2c.h b/include/linux/i2c.h
index ad25805..ba73cd0 100644
--- a/include/linux/i2c.h
+++ b/include/linux/i2c.h
@@ -277,6 +277,8 @@ struct i2c_board_info {
.type = dev_type, .addr = (dev_addr)
+#ifdef CONFIG_I2C
+
/* Add-on boards should register/unregister their devices; e.g. a board
* with integrated I2C, a config eeprom, sensors, and a codec that's
* used in conjunction with the primary hardware.
@@ -301,6 +303,33 @@ i2c_new_dummy(struct i2c_adapter *adap, u16 address);
extern void i2c_unregister_device(struct i2c_client *);
+#else
+
+static inline struct i2c_client *
+i2c_new_device(struct i2c_adapter *adap, struct i2c_board_info const *info)
+{
+ return NULL;
+}
+
+static inline struct i2c_client *
+i2c_new_probed_device(struct i2c_adapter *adap,
+ struct i2c_board_info *info,
+ unsigned short const *addr_list)
+{
+ return NULL;
+}
+
+static inline struct i2c_client *
+i2c_new_dummy(struct i2c_adapter *adap, u16 address)
+{
+ return NULL;
+}
+
+static inline void i2c_unregister_device(struct i2c_client *client)
+{
+}
+#endif /* CONFIG_I2C */
+
/* Mainboard arch_initcall() code should register all its I2C devices.
* This is done at arch_initcall time, before declaring any i2c adapters.
* Modules for add-on boards must use other calls.
@@ -415,6 +444,7 @@ struct i2c_client_address_data {
/* - functions exported by i2c.o */
+#ifdef CONFIG_I2C
/* administration...
*/
extern int i2c_add_adapter(struct i2c_adapter *);
@@ -460,6 +490,85 @@ static inline u32 i2c_get_functionality(struct i2c_adapter
*adap)
return adap-algo-functionality(adap);
}
+#else
+
+static inline int i2c_add_adapter(struct i2c_adapter *adap)
+{
+ return -ENODEV;
+}
+
+static inline int i2c_del_adapter(struct i2c_adapter *adap)
+{
+ return -ENODEV;
+}
+
+static inline int i2c_add_numbered_adapter(struct i2c_adapter *adap)
+{
+ return -ENODEV;
+}
+
+static inline int i2c_register_driver(struct module *module,
+ struct i2c_driver *driver)
+{
+ return -ENODEV;
+}
+
+static inline void i2c_del_driver(struct i2c_driver *driver)
+{
+}
+
+static inline int i2c_add_driver(struct i2c_driver *driver)
+{
+ return -ENODEV;
+}
+
+static inline int __deprecated i2c_attach_client(struct i2c_client *client)
+{
+ return -EINVAL;
+}
+
+static inline int __deprecated i2c_detach_client(struct i2c_client *client)
+{
+ return -EINVAL;
+}
+
+static inline struct i2c_client *i2c_use_client(struct i2c_client *client)
+{
+ return NULL;
+}
+
+static inline void i2c_release_client(struct i2c_client *client)
+{
+}
+
+static inline void i2c_clients_command(struct i2c_adapter *adap,
+ unsigned int cmd, void *arg)
+{
+}
+
+static inline int i2c_probe(struct i2c_adapter *adapter,
+ const struct i2c_client_address_data *address_data,
+ int (*found_proc) (struct i2c_adapter *, int, int))
+{
+ return -ENODEV;
+}
+
+static inline struct i2c_adapter *i2c_get_adapter(int id)
+{
+ return NULL;
+}
+
+static inline void i2c_put_adapter(struct i2c_adapter *adap)
+{
+}
+
+/* Return the functionality mask */
+static inline u32 i2c_get_functionality(struct i2c_adapter *adap)
+{
+ return 0;
+}
+#endif /* CONFIG_I2C */
+
/* Return 1 if adapter supports everything we need, 0 if not. */
static inline int i2c_check_functionality(struct i2c_adapter *adap, u32 func)
{
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] i2c: Simplified CONFIG_I2C=n interface.
On Wed, 27 May 2009 16:08:50 +0900, Paul Mundt wrote: Another day, another module-related failure due to the i2c interface being used in code that optionally uses it: ERROR: i2c_new_device [drivers/media/video/soc_camera.ko] undefined! ERROR: i2c_get_adapter [drivers/media/video/soc_camera.ko] undefined! ERROR: i2c_put_adapter [drivers/media/video/soc_camera.ko] undefined! ERROR: i2c_unregister_device [drivers/media/video/soc_camera.ko] undefined! make[2]: *** [__modpost] Error 1 make[1]: *** [modules] Error 2 make: *** [sub-make] Error 2 In the interest of not continually inserting i2c ifdefs in to every driver that supports an optional i2c interface, this provides a stubbed set of interfaces for the CONFIG_I2C=n case. I've covered the obvious ones that cause the majority of the build failures, anything more involved really ought to have its dependencies fixed instead. Violent nack. Drivers which optionally use I2C are a minority. Designing them in such a way that a single #ifdef CONFIG_I2C will make them work can't be that hard, really. Not to mention that having a dozen stubs in i2c.h in the CONFIG_I2C=n case won't save you much work at the driver level anyway, because you certainly need to run different code paths depending on how the device is connected, and you also have to differentiate between the I2C support is missing case and the I2C device registration failed case, etc. -- Jean Delvare -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-dvb] how to get the SNR DB value for DVICO DVB-T Dual express card
On 05/26/2009 09:37 PM, Tu-Tu Yu wrote: Hello: this is the output of the status... I would like to know how to calculate the the SNR DB value. Thank you so much! The frontend they used for DVB-T DUAL express is Zarlink zl10353 DVB-T status 1e | signal b788 | snr 0f1f1 | ber | unc | FE_HAS_LOCK status 1e | signal b78c | snr 0f2f2 | ber | unc | FE_HAS_LOCK status 1e | signal b77c | snr 0f2f2 | ber | unc | FE_HAS_LOCK status 1e | signal b780 | snr 0f1f1 | ber | unc | FE_HAS_LOCK status 1e | signal b774 | snr 0f1f1 | ber | unc | FE_HAS_LOCK status 1e | signal b77c | snr 0f1f1 | ber | unc | FE_HAS_LOCK 0xf1/8 = 30.125dB regards Antti -- http://palosaari.fi/ -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv4 8 of 8] FMTx: si4713: Add document file
# HG changeset patch # User Eduardo Valentin eduardo.valen...@nokia.com # Date 1243414607 -10800 # Branch export # Node ID fadf1cddf504609cdb4889f4aa3305ca8d15323a # Parent b1d98e675a3c4e9e6d247701c9ac18239e3dcc1c Signed-off-by: Eduardo Valentin eduardo.valen...@nokia.com --- Documentation/video4linux/si4713.txt | 133 ++ 1 files changed, 133 insertions(+), 0 deletions(-) create mode 100644 Documentation/video4linux/si4713.txt diff -r b1d98e675a3c -r fadf1cddf504 linux/Documentation/video4linux/si4713.txt --- /dev/null Thu Jan 01 00:00:00 1970 + +++ b/linux/Documentation/video4linux/si4713.txtWed May 27 11:56:47 2009 +0300 @@ -0,0 +1,133 @@ +Driver for I2C radios for the Silicon Labs Si4713 FM Radio Transmitters + +Copyright (c) 2009 Nokia Corporation +Contact: Eduardo Valentin eduardo.valen...@nokia.com + + +Information about the Device + +This chip is a Silicon Labs product. It is a I2C device, currently on 0Ã63 address. +Basically, it has transmission and signal noise level measurement features. + +The Si4713 integrates transmit functions for FM broadcast stereo transmission. +The chip also allows integrated receive power scanning to identify low signal +power FM channels. + +The chip is programmed using commands and responses. There are also several +properties which can change the behavior of this chip. + +Users must comply with local regulations on radio frequency (RF) transmission. + +Device driver description += +There are two modules to handle this device. One is a I2C device driver +and the other is a platform driver. + +The I2C device driver exports a v4l2-subdev interface to the kernel. Also +it exports several device properties through sysfs interface to the user land. +All properties can also be accessed by v4l2 extended controls interface, by +using the v4l2-subdev calls (g_ext_ctrls, s_ext_ctrls). + +The platform device driver exports a v4l2 radio device interface to user land. +So, it uses the I2C device driver as a sub device in order to send the user +commands to the actual device. Basically it is a wrapper to the I2C device driver. + +So, in summary, the device driver has two interfaces to the user space. + +Applications can use v4l2 radio API to specify frequency of operation, mute state, +etc. But mostly of its properties will be present in the extended controls. +However, the device properties can also be accessed through its sysfs directory. + +When the v4l2 mute property is set to 1 (true), the driver will turn the chip off. + +Properties description +== + +The properties can be accessed in sysfs device directory. Using v4l2 extended +controls as well. + +# ls +acomp_attack_timemodalias rds_radio_text +acomp_enabledname region +acomp_gain pilot_deviation region_bottom_frequency +acomp_release_time pilot_enabledregion_channel_spacing +acomp_threshold pilot_frequency region_preemphasis +antenna_capacitorpowerregion_top_frequency +bus power_level stereo_enabled +driver rds_enabled subsystem +limiter_deviationrds_pi tune_measure +limiter_enabled rds_ps_name uevent +limiter_release_time rds_pty + +Here is a summary of them: + +* Pilot is an audible tone sent by the device. + +pilot_frequency - Configures the frequency of the stereo pilot tone. +pilot_deviation - Configures pilot tone frequency deviation level. +pilot_enabled - Enables or disables the pilot tone feature. + +* The si4713 device is capable of applying audio compression to the transmitted signal. + +acomp_enabled - Enables or disables the audio dynamic range control feature. +acomp_gain - Sets the gain for audio dynamic range control. +acomp_threshold - Sets the threshold level for audio dynamic range control. +acomp_attack_time - Sets the attack time for audio dynamic range control. +acomp_release_time - Sets the release time for audio dynamic range control. + +* Limiter setups audio deviation limiter feature. Once a over deviation occurs, +it is possible to adjust the front-end gain of the audio input and always +prevent over deviation. + +limiter_enabled - Enables or disables the limiter feature. +limiter_deviation - Configures audio frequency deviation level. +limiter_release_time - Sets the limiter release time. + +* Tuning power + +power_level - Sets the output power level for signal transmission. +antenna_capacitor - This selects the value of antenna tuning capacitor manually +or automatically if set to zero. +tune_measure - With this you can get the value of signal length of a specific frequency. + +* RDS related + +rds_enabled - Enables or disables the RDS feature. +rds_ps_name - Sets the RDS ps name field for transmission.
[PATCHv4 0 of 8] FM Transmitter (si4713) and another changes
Hello all, I'm resending the FM transmitter driver and the proposed changes in v4l2 api files in order to cover the fmtx extended controls class. It is basically the same series of version #3. However I rewrote it to add the following comments: * Check kernel version for i2c helper function. Now the board data is passed not using i2c_board_info. This way all supported kernel versions can use the api. Besides that, the .s_config callback was added in core ops. * All patches are against v4l-dvb hg repository. Again, comments are welcome. BR, --- Eduardo Valentin -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv4 1 of 8] v4l2_subdev i2c: Add v4l2_i2c_new_subdev_board i2c helper function
# HG changeset patch
# User Eduardo Valentin eduardo.valen...@nokia.com
# Date 1243414605 -10800
# Branch export
# Node ID 4fb354645426f8b187c2c90cd8528b2518461005
# Parent 142fd6020df3b4d543068155e49a2618140efa49
Device drivers of v4l2_subdev devices may want to have
board specific data. This patch adds an helper function
to allow bridge drivers to pass board specific data to
v4l2_subdev drivers.
For those drivers which need to support kernel versions
bellow 2.6.26, a .s_config callback was added. The
idea of this callback is to pass board configuration
as well. In that case, subdev driver should set .s_config
properly, because v4l2_i2c_new_subdev_board will call
the .s_config directly. Of course, if we are = 2.6.26,
the same data will be passed through i2c board info as well.
Signed-off-by: Eduardo Valentin eduardo.valen...@nokia.com
---
drivers/media/linux/video/v4l2-common.c | 37
+++--
include/media/linux/v4l2-common.h |8
include/media/linux/v4l2-subdev.h |1 +
3 files changed, 44 insertions(+), 2 deletions(-)
diff -r 142fd6020df3 -r 4fb354645426 linux/drivers/media/video/v4l2-common.c
--- a/linux/drivers/media/video/v4l2-common.c Mon May 18 02:31:55 2009 +
+++ b/linux/drivers/media/video/v4l2-common.c Wed May 27 11:56:45 2009 +0300
@@ -819,9 +819,10 @@
/* Load an i2c sub-device. */
-struct v4l2_subdev *v4l2_i2c_new_subdev(struct v4l2_device *v4l2_dev,
+static struct v4l2_subdev *__v4l2_i2c_new_subdev(struct v4l2_device *v4l2_dev,
struct i2c_adapter *adapter,
- const char *module_name, const char *client_type, u8 addr)
+ const char *module_name, const char *client_type, u8 addr,
+ int irq, void *platform_data)
{
struct v4l2_subdev *sd = NULL;
struct i2c_client *client;
@@ -840,6 +841,8 @@
memset(info, 0, sizeof(info));
strlcpy(info.type, client_type, sizeof(info.type));
info.addr = addr;
+ info.irq = irq;
+ info.platform_data = platform_data;
/* Create the i2c client */
client = i2c_new_device(adapter, info);
@@ -877,8 +880,38 @@
#endif
return sd;
}
+
+struct v4l2_subdev *v4l2_i2c_new_subdev(struct v4l2_device *v4l2_dev,
+ struct i2c_adapter *adapter,
+ const char *module_name, const char *client_type, u8 addr)
+{
+ return __v4l2_i2c_new_subdev(v4l2_dev, adapter, module_name,
+ client_type, addr, 0, NULL);
+}
EXPORT_SYMBOL_GPL(v4l2_i2c_new_subdev);
+struct v4l2_subdev *v4l2_i2c_new_subdev_board(struct v4l2_device *v4l2_dev,
+ struct i2c_adapter *adapter,
+ const char *module_name, const char *client_type, u8 addr,
+ int irq, void *platform_data)
+{
+ struct v4l2_subdev *sd;
+ int err = 0;
+
+ sd = __v4l2_i2c_new_subdev(v4l2_dev, adapter, module_name, client_type,
+ addr, irq, platform_data);
+
+ /*
+* We return errors from v4l2_subdev_call only if we have the callback
+* as the .s_config is not mandatory
+*/
+ if (sd sd-ops sd-ops-core sd-ops-core-s_config)
+ err = sd-ops-core-s_config(sd, irq, platform_data);
+
+ return err 0 ? NULL : sd;
+}
+EXPORT_SYMBOL_GPL(v4l2_i2c_new_subdev_board);
+
/* Probe and load an i2c sub-device. */
struct v4l2_subdev *v4l2_i2c_new_probed_subdev(struct v4l2_device *v4l2_dev,
struct i2c_adapter *adapter,
diff -r 142fd6020df3 -r 4fb354645426 linux/include/media/v4l2-common.h
--- a/linux/include/media/v4l2-common.h Mon May 18 02:31:55 2009 +
+++ b/linux/include/media/v4l2-common.h Wed May 27 11:56:45 2009 +0300
@@ -147,6 +147,14 @@
struct v4l2_subdev *v4l2_i2c_new_subdev(struct v4l2_device *v4l2_dev,
struct i2c_adapter *adapter,
const char *module_name, const char *client_type, u8 addr);
+/*
+ * Same as v4l2_i2c_new_subdev, but with the opportunity to configure
+ * subdevice with board specific data (irq and platform_data).
+ */
+struct v4l2_subdev *v4l2_i2c_new_subdev_board(struct v4l2_device *v4l2_dev,
+ struct i2c_adapter *adapter,
+ const char *module_name, const char *client_type, u8 addr,
+ int irq, void *platform_data);
/* Probe and load an i2c module and return an initialized v4l2_subdev struct.
Only call request_module if module_name != NULL.
The client_type argument is the name of the chip that's on the adapter. */
diff -r 142fd6020df3 -r 4fb354645426 linux/include/media/v4l2-subdev.h
--- a/linux/include/media/v4l2-subdev.h Mon May 18 02:31:55 2009 +
+++ b/linux/include/media/v4l2-subdev.h Wed May 27 11:56:45 2009 +0300
@@ -96,6 +96,7 @@
struct v4l2_subdev_core_ops {
int (*g_chip_ident)(struct v4l2_subdev *sd, struct v4l2_dbg_chip_ident
*chip);
int (*log_status)(struct v4l2_subdev *sd);
+ int (*s_config)(struct
[PATCHv4 7 of 8] FMTx: si4713: Add Kconfig and Makefile entries
# HG changeset patch # User Eduardo Valentin eduardo.valen...@nokia.com # Date 1243414607 -10800 # Branch export # Node ID b1d98e675a3c4e9e6d247701c9ac18239e3dcc1c # Parent 1abb96fdce05e1449faac2223e93056bacf389bd Signed-off-by: Eduardo Valentin eduardo.valen...@nokia.com --- drivers/media/linux/radio/Kconfig | 22 ++ drivers/media/linux/radio/Makefile |3 +++ 2 files changed, 25 insertions(+), 0 deletions(-) diff -r 1abb96fdce05 -r b1d98e675a3c linux/drivers/media/radio/Kconfig --- a/linux/drivers/media/radio/Kconfig Wed May 27 11:56:46 2009 +0300 +++ b/linux/drivers/media/radio/Kconfig Wed May 27 11:56:47 2009 +0300 @@ -339,6 +339,28 @@ help Enter the I/O port of your Zoltrix radio card. +config I2C_SI4713 + tristate I2C driver for Silicon Labs Si4713 device + depends on I2C VIDEO_V4L2 + ---help--- + Say Y here if you want support to Si4713 I2C device. + This device driver supports only i2c bus. + + To compile this driver as a module, choose M here: the + module will be called si4713. + +config RADIO_SI4713 + tristate Silicon Labs Si4713 FM Radio Transmitter support + depends on I2C VIDEO_V4L2 + ---help--- + Say Y here if you want support to Si4713 FM Radio Transmitter. + This device can transmit audio through FM. It can transmit + EDS and EBDS signals as well. This module is the v4l2 radio + interface for the i2c driver of this device. + + To compile this driver as a module, choose M here: the + module will be called radio-si4713. + config USB_DSBR tristate D-Link/GemTek USB FM radio support depends on USB VIDEO_V4L2 diff -r 1abb96fdce05 -r b1d98e675a3c linux/drivers/media/radio/Makefile --- a/linux/drivers/media/radio/MakefileWed May 27 11:56:46 2009 +0300 +++ b/linux/drivers/media/radio/MakefileWed May 27 11:56:47 2009 +0300 @@ -15,6 +15,9 @@ obj-$(CONFIG_RADIO_GEMTEK) += radio-gemtek.o obj-$(CONFIG_RADIO_GEMTEK_PCI) += radio-gemtek-pci.o obj-$(CONFIG_RADIO_TRUST) += radio-trust.o +obj-$(CONFIG_I2C_SI4713) += si4713-i2c.o +si4713-i2c-objs := si4713.o si4713-subdev.o +obj-$(CONFIG_RADIO_SI4713) += radio-si4713.o obj-$(CONFIG_RADIO_MAESTRO) += radio-maestro.o obj-$(CONFIG_USB_DSBR) += dsbr100.o obj-$(CONFIG_USB_SI470X) += radio-si470x.o -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv4 2 of 8] v4l2: video device: Add V4L2_CTRL_CLASS_FMTX controls
# HG changeset patch
# User Eduardo Valentin eduardo.valen...@nokia.com
# Date 1243414606 -10800
# Branch export
# Node ID ebb409d7a258df2bc7a6dcd72113584b4c0e7ce2
# Parent 4fb354645426f8b187c2c90cd8528b2518461005
This patch adds a new class of extended controls. This class
is intended to support Radio Modulators properties such as:
rds, audio limiters, audio compression, pilot tone generation,
tuning power levels and region related properties.
Signed-off-by: Eduardo Valentin eduardo.valen...@nokia.com
---
include/linux/videodev2.h | 34 ++
1 files changed, 34 insertions(+), 0 deletions(-)
diff -r 4fb354645426 -r ebb409d7a258 linux/include/linux/videodev2.h
--- a/linux/include/linux/videodev2.h Wed May 27 11:56:45 2009 +0300
+++ b/linux/include/linux/videodev2.h Wed May 27 11:56:46 2009 +0300
@@ -803,6 +803,7 @@
#define V4L2_CTRL_CLASS_USER 0x0098/* Old-style 'user' controls */
#define V4L2_CTRL_CLASS_MPEG 0x0099/* MPEG-compression controls */
#define V4L2_CTRL_CLASS_CAMERA 0x009a /* Camera class controls */
+#define V4L2_CTRL_CLASS_FMTX 0x009b/* FM Radio Modulator class
controls */
#define V4L2_CTRL_ID_MASK(0x0fff)
#define V4L2_CTRL_ID2CLASS(id)((id) 0x0fffUL)
@@ -1141,6 +1142,39 @@
#define V4L2_CID_PRIVACY (V4L2_CID_CAMERA_CLASS_BASE+16)
+/* FM Radio Modulator class control IDs */
+#define V4L2_CID_FMTX_CLASS_BASE (V4L2_CTRL_CLASS_FMTX | 0x900)
+#define V4L2_CID_FMTX_CLASS(V4L2_CTRL_CLASS_FMTX | 1)
+
+#define V4L2_CID_RDS_ENABLED (V4L2_CID_FMTX_CLASS_BASE + 1)
+#define V4L2_CID_RDS_PI
(V4L2_CID_FMTX_CLASS_BASE + 2)
+#define V4L2_CID_RDS_PTY (V4L2_CID_FMTX_CLASS_BASE + 3)
+#define V4L2_CID_RDS_PS_NAME (V4L2_CID_FMTX_CLASS_BASE + 4)
+#define V4L2_CID_RDS_RADIO_TEXT
(V4L2_CID_FMTX_CLASS_BASE + 5)
+
+#define V4L2_CID_AUDIO_LIMITER_ENABLED (V4L2_CID_FMTX_CLASS_BASE + 6)
+#define V4L2_CID_AUDIO_LIMITER_RELEASE_TIME(V4L2_CID_FMTX_CLASS_BASE + 7)
+#define V4L2_CID_AUDIO_LIMITER_DEVIATION (V4L2_CID_FMTX_CLASS_BASE + 8)
+
+#define V4L2_CID_AUDIO_COMPRESSION_ENABLED (V4L2_CID_FMTX_CLASS_BASE + 9)
+#define V4L2_CID_AUDIO_COMPRESSION_GAIN
(V4L2_CID_FMTX_CLASS_BASE + 10)
+#define V4L2_CID_AUDIO_COMPRESSION_THRESHOLD (V4L2_CID_FMTX_CLASS_BASE + 11)
+#define V4L2_CID_AUDIO_COMPRESSION_ATTACK_TIME (V4L2_CID_FMTX_CLASS_BASE + 12)
+#define V4L2_CID_AUDIO_COMPRESSION_RELEASE_TIME
(V4L2_CID_FMTX_CLASS_BASE + 13)
+
+#define V4L2_CID_PILOT_TONE_ENABLED(V4L2_CID_FMTX_CLASS_BASE + 14)
+#define V4L2_CID_PILOT_TONE_DEVIATION (V4L2_CID_FMTX_CLASS_BASE + 15)
+#define V4L2_CID_PILOT_TONE_FREQUENCY (V4L2_CID_FMTX_CLASS_BASE + 16)
+
+#define V4L2_CID_PREEMPHASIS (V4L2_CID_FMTX_CLASS_BASE + 17)
+enum v4l2_fmtx_preemphasis {
+ V4L2_FMTX_PREEMPHASIS_DISABLED = 0,
+ V4L2_FMTX_PREEMPHASIS_50_uS = 1,
+ V4L2_FMTX_PREEMPHASIS_75_uS = 2,
+};
+#define V4L2_CID_TUNE_POWER_LEVEL (V4L2_CID_FMTX_CLASS_BASE + 18)
+#define V4L2_CID_TUNE_ANTENNA_CAPACITOR
(V4L2_CID_FMTX_CLASS_BASE + 19)
+
/*
* T U N I N G
*/
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv4 4 of 8] Add documentation description for FM Transmitter Extended Control Class
# HG changeset patch # User Eduardo Valentin eduardo.valen...@nokia.com # Date 1242209424 -10800 # Branch export # Node ID 2dd45d3736ae1952dfa98e65b072eb08157fb19d # Parent fadf1cddf504609cdb4889f4aa3305ca8d15323a From: Eduardo Valentin eduardo.valen...@nokia.com This single patch adds documentation description for FM Transmitter (FMTX) Extended Control Class and its Control IDs. The text was added under Extended Controls section. Priority: normal Signed-off-by: Eduardo Valentin eduardo.valen...@nokia.com diff -r fadf1cddf504 -r 2dd45d3736ae v4l2-spec/controls.sgml --- a/v4l2-spec/controls.sgml Wed May 27 11:56:47 2009 +0300 +++ b/v4l2-spec/controls.sgml Wed May 13 13:10:24 2009 +0300 @@ -458,6 +458,12 @@ paraUnfortunately, the original control API lacked some features needed for these new uses and so it was extended into the (not terribly originally named) extended control API./para + + paraEven though the MPEG encoding API was the first effort +to use the Extended Control API, nowadays there are also other classes +of Extended Controls, such as Camera Controls and FM Transmitter Controls. +The Extended Controls API as well as all Extended Controls classes are +described in the following text./para /section section @@ -1816,6 +1822,200 @@ /tgroup /table /section + +section id=fmtx-controls + titleFM Transmitter Control Reference/title + + paraThe FM Transmitter (FMTX) class includes controls for common features of +FM transmissions capable devices. Currently this class include parameters for audio +compression, pilot tone generation, audio deviation limiter, RDS transmission and +tuning power features./para + + table pgwide=1 frame=none id=fmtx-control-id + titleFMTX Control IDs/title + + tgroup cols=4 + colspec colname=c1 colwidth=1* + colspec colname=c2 colwidth=6* + colspec colname=c3 colwidth=2* + colspec colname=c4 colwidth=6* + spanspec namest=c1 nameend=c2 spanname=id + spanspec namest=c2 nameend=c4 spanname=descr + thead + row + entry spanname=id align=leftID/entry + entry align=leftType/entry + /rowrow rowsep=1entry spanname=descr align=leftDescription/entry + /row + /thead + tbody valign=top + rowentry/entry/row + row + entry spanname=idconstantV4L2_CID_FMTX_CLASS/constantnbsp;/entry + entryclass/entry + /rowrowentry spanname=descrThe FMTX class +descriptor. Calling VIDIOC-QUERYCTRL; for this control will return a +description of this control class./entry + /row + row + entry spanname=idconstantV4L2_CID_RDS_ENABLED/constantnbsp;/entry + entryboolean/entry + /row + rowentry spanname=descrEnables or disables the RDS transmission feature./entry + /row + row + entry spanname=idconstantV4L2_CID_RDS_PI/constantnbsp;/entry + entryinteger/entry + /row + rowentry spanname=descrSets the RDS Programme Identification field +for transmission./entry + /row + row + entry spanname=idconstantV4L2_CID_RDS_PTY/constantnbsp;/entry + entryinteger/entry + /row + rowentry spanname=descriSets the RDS Programme Type field for transmission. +This coding of up to 31 pre-defined programme types./entry + /row +!-- + row + entry spanname=idconstantV4L2_CID_RDS_PS_NAME/constantnbsp;/entry + entryinteger/entry + /row + rowentry spanname=descr./entry + /row + row + entry spanname=idconstantV4L2_CID_RDS_RADIO_TEXT/constantnbsp;/entry + entryinteger/entry + /row + rowentry spanname=descr./entry + /row +-- + row + entry spanname=idconstantV4L2_CID_AUDIO_LIMITER_ENABLED/constantnbsp;/entry + entryboolean/entry + /row + rowentry spanname=descrEnables or disables the audio deviation limiter feature. +The limiter is useful when trying to maximize the audio volume, minimize receiver-generated +distortion and prevent overmodulation. +/entry + /row + row + entry spanname=idconstantV4L2_CID_AUDIO_LIMITER_RELEASE_TIME/constantnbsp;/entry + entryinteger/entry + /row + rowentry spanname=descrSets the audio deviation limiter feature release time. +The unit, step and range are driver-specific./entry + /row + row + entry spanname=idconstantV4L2_CID_AUDIO_LIMITER_DEVIATION/constantnbsp;/entry + entryinteger/entry + /row + rowentry spanname=descrConfigures audio frequency deviation level in Hz. +The range and step are driver-specific./entry + /row + row + entry spanname=idconstantV4L2_CID_AUDIO_COMPRESSION_ENABLED/constantnbsp;/entry + entryboolean/entry +
[PATCHv4 3 of 8] v4l2: video device: Add FMTX controls default configurations
# HG changeset patch
# User Eduardo Valentin eduardo.valen...@nokia.com
# Date 1243414606 -10800
# Branch export
# Node ID 85b64a6cc67c0c0d6a795388f8ca02dad2ff9da7
# Parent ebb409d7a258df2bc7a6dcd72113584b4c0e7ce2
Signed-off-by: Eduardo Valentin eduardo.valen...@nokia.com
---
drivers/media/linux/video/v4l2-common.c | 46
+
1 files changed, 46 insertions(+), 0 deletions(-)
diff -r ebb409d7a258 -r 85b64a6cc67c linux/drivers/media/video/v4l2-common.c
--- a/linux/drivers/media/video/v4l2-common.c Wed May 27 11:56:46 2009 +0300
+++ b/linux/drivers/media/video/v4l2-common.c Wed May 27 11:56:46 2009 +0300
@@ -341,6 +341,12 @@
Sepia,
NULL
};
+ static const char *fmtx_preemphasis[] = {
+ No preemphasis,
+ 50 useconds,
+ 75 useconds,
+ NULL,
+ };
switch (id) {
case V4L2_CID_MPEG_AUDIO_SAMPLING_FREQ:
@@ -379,6 +385,8 @@
return camera_exposure_auto;
case V4L2_CID_COLORFX:
return colorfx;
+ case V4L2_CID_PREEMPHASIS:
+ return fmtx_preemphasis;
default:
return NULL;
}
@@ -477,6 +485,28 @@
case V4L2_CID_ZOOM_CONTINUOUS: return Zoom, Continuous;
case V4L2_CID_PRIVACY: return Privacy;
+ /* FM Radio Modulator control */
+ case V4L2_CID_FMTX_CLASS: return FM Radio Modulator
Controls;
+ case V4L2_CID_RDS_ENABLED: return RDS Feature Enabled;
+ case V4L2_CID_RDS_PI: return RDS Program ID;
+ case V4L2_CID_RDS_PTY: return RDS Program Type;
+ case V4L2_CID_RDS_PS_NAME: return RDS PS Name;
+ case V4L2_CID_RDS_RADIO_TEXT: return RDS Radio Text;
+ case V4L2_CID_AUDIO_LIMITER_ENABLED:return Audio Limiter Feature
Enabled;
+ case V4L2_CID_AUDIO_LIMITER_RELEASE_TIME: return Audio Limiter Release
Time;
+ case V4L2_CID_AUDIO_LIMITER_DEVIATION: return Audio Limiter
Deviation;
+ case V4L2_CID_AUDIO_COMPRESSION_ENABLED: return Audio Compression
Feature Enabled;
+ case V4L2_CID_AUDIO_COMPRESSION_GAIN: return Audio Compression Gain;
+ case V4L2_CID_AUDIO_COMPRESSION_THRESHOLD: return Audio Compression
Threshold;
+ case V4L2_CID_AUDIO_COMPRESSION_ATTACK_TIME: return Audio Compression
Attack Time;
+ case V4L2_CID_AUDIO_COMPRESSION_RELEASE_TIME: return Audio Compression
Release Time;
+ case V4L2_CID_PILOT_TONE_ENABLED: return Pilot Tone Feature
Enabled;
+ case V4L2_CID_PILOT_TONE_DEVIATION: return Pilot Tone Deviation;
+ case V4L2_CID_PILOT_TONE_FREQUENCY: return Pilot Tone Frequency;
+ case V4L2_CID_PREEMPHASIS: return Pre-emphasis settings;
+ case V4L2_CID_TUNE_POWER_LEVEL: return Tune Power Level;
+ case V4L2_CID_TUNE_ANTENNA_CAPACITOR: return Tune Antenna Capacitor;
+
default:
return NULL;
}
@@ -509,6 +539,10 @@
case V4L2_CID_EXPOSURE_AUTO_PRIORITY:
case V4L2_CID_FOCUS_AUTO:
case V4L2_CID_PRIVACY:
+ case V4L2_CID_RDS_ENABLED:
+ case V4L2_CID_AUDIO_LIMITER_ENABLED:
+ case V4L2_CID_AUDIO_COMPRESSION_ENABLED:
+ case V4L2_CID_PILOT_TONE_ENABLED:
qctrl-type = V4L2_CTRL_TYPE_BOOLEAN;
min = 0;
max = step = 1;
@@ -537,12 +571,14 @@
case V4L2_CID_MPEG_STREAM_VBI_FMT:
case V4L2_CID_EXPOSURE_AUTO:
case V4L2_CID_COLORFX:
+ case V4L2_CID_PREEMPHASIS:
qctrl-type = V4L2_CTRL_TYPE_MENU;
step = 1;
break;
case V4L2_CID_USER_CLASS:
case V4L2_CID_CAMERA_CLASS:
case V4L2_CID_MPEG_CLASS:
+ case V4L2_CID_FMTX_CLASS:
qctrl-type = V4L2_CTRL_TYPE_CTRL_CLASS;
qctrl-flags |= V4L2_CTRL_FLAG_READ_ONLY;
min = max = step = def = 0;
@@ -571,6 +607,16 @@
case V4L2_CID_BLUE_BALANCE:
case V4L2_CID_GAMMA:
case V4L2_CID_SHARPNESS:
+ case V4L2_CID_AUDIO_LIMITER_RELEASE_TIME:
+ case V4L2_CID_AUDIO_LIMITER_DEVIATION:
+ case V4L2_CID_AUDIO_COMPRESSION_GAIN:
+ case V4L2_CID_AUDIO_COMPRESSION_THRESHOLD:
+ case V4L2_CID_AUDIO_COMPRESSION_ATTACK_TIME:
+ case V4L2_CID_AUDIO_COMPRESSION_RELEASE_TIME:
+ case V4L2_CID_PILOT_TONE_DEVIATION:
+ case V4L2_CID_PILOT_TONE_FREQUENCY:
+ case V4L2_CID_TUNE_POWER_LEVEL:
+ case V4L2_CID_TUNE_ANTENNA_CAPACITOR:
qctrl-flags |= V4L2_CTRL_FLAG_SLIDER;
break;
case V4L2_CID_PAN_RELATIVE:
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at
[PATCHv4 6 of 8] FMTx: si4713: Add files to add radio interface for si4713
# HG changeset patch
# User Eduardo Valentin eduardo.valen...@nokia.com
# Date 1243414606 -10800
# Branch export
# Node ID 1abb96fdce05e1449faac2223e93056bacf389bd
# Parent 94b5043b692a6218a667326536d3d76a0c591307
This patch adds files which creates the radio interface
for si4713 FM transmitter devices.
Signed-off-by: Eduardo Valentin eduardo.valen...@nokia.com
---
drivers/media/linux/radio/radio-si4713.c | 333
drivers/media/linux/radio/radio-si4713.h | 49 ++
2 files changed, 382 insertions(+), 0 deletions(-)
create mode 100644 drivers/media/linux/radio/radio-si4713.c
create mode 100644 drivers/media/linux/radio/radio-si4713.h
diff -r 94b5043b692a -r 1abb96fdce05
linux/drivers/media/linux/radio/radio-si4713.c
--- /dev/null Thu Jan 01 00:00:00 1970 +
+++ b/linux/drivers/media/linux/radio/radio-si4713.cWed May 27 11:56:46
2009 +0300
@@ -0,0 +1,333 @@
+/*
+ * drivers/media/linux/radio/radio-si4713.c
+ *
+ * Platform Driver for Silicon Labs Si4713 FM Radio Transmitter:
+ *
+ * Copyright (c) 2008 Instituto Nokia de Tecnologia - INdT
+ * Contact: Eduardo Valentin eduardo.valen...@nokia.com
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+ */
+
+#include linux/kernel.h
+#include linux/module.h
+#include linux/init.h
+#include linux/version.h
+#include linux/platform_device.h
+#include linux/i2c.h
+#include linux/videodev2.h
+#include media/linux/v4l2-device.h
+#include media/linux/v4l2-common.h
+#include media/linux/v4l2-ioctl.h
+
+#include radio-si4713.h
+#include si4713.h
+
+/* module parameters */
+static int radio_nr = -1; /* radio device minor (-1 == auto assign) */
+
+/* radio_si4713_fops - file operations interface */
+static const struct v4l2_file_operations radio_si4713_fops = {
+ .owner = THIS_MODULE,
+ .ioctl = video_ioctl2,
+};
+
+/* Video4Linux Interface */
+static int radio_si4713_vidioc_g_audio(struct file *file, void *priv,
+ struct v4l2_audio *audio)
+{
+ if (audio-index 1)
+ return -EINVAL;
+
+ strncpy(audio-name, Radio, 32);
+ audio-capability = V4L2_AUDCAP_STEREO;
+
+ return 0;
+}
+
+static int radio_si4713_vidioc_s_audio(struct file *file, void *priv,
+ struct v4l2_audio *audio)
+{
+ if (audio-index != 0)
+ return -EINVAL;
+
+ return 0;
+}
+
+static int radio_si4713_vidioc_g_input(struct file *file, void *priv,
+ unsigned int *i)
+{
+ *i = 0;
+
+ return 0;
+}
+
+static int radio_si4713_vidioc_s_input(struct file *file, void *priv,
+ unsigned int i)
+{
+ if (i != 0)
+ return -EINVAL;
+
+ return 0;
+}
+
+/* radio_si4713_vidioc_querycap - query device capabilities */
+static int radio_si4713_vidioc_querycap(struct file *file, void *priv,
+ struct v4l2_capability *capability)
+{
+ struct radio_si4713_device *rsdev;
+
+ rsdev = video_get_drvdata(video_devdata(file));
+
+ strlcpy(capability-driver, radio-si4713, sizeof(capability-driver));
+ strlcpy(capability-card, Silicon Labs Si4713 FM Radio Transmitter,
+ sizeof(capability-card));
+ capability-capabilities = V4L2_CAP_TUNER;
+
+ return 0;
+}
+
+/* radio_si4713_vidioc_queryctrl - enumerate control items */
+static int radio_si4713_vidioc_queryctrl(struct file *file, void *priv,
+ struct v4l2_queryctrl *qc)
+{
+
+ /* Must be sorted from low to high control ID! */
+ static const u32 user_ctrls[] = {
+ V4L2_CID_USER_CLASS,
+ V4L2_CID_AUDIO_VOLUME,
+ V4L2_CID_AUDIO_BALANCE,
+ V4L2_CID_AUDIO_BASS,
+ V4L2_CID_AUDIO_TREBLE,
+ V4L2_CID_AUDIO_LOUDNESS,
+ V4L2_CID_AUDIO_MUTE,
+ 0
+ };
+
+ /* Must be sorted from low to high control ID! */
+ static const u32 fmtx_ctrls[] = {
+ V4L2_CID_FMTX_CLASS,
+ V4L2_CID_RDS_ENABLED,
+ V4L2_CID_RDS_PI,
+ V4L2_CID_RDS_PTY,
+ V4L2_CID_RDS_PS_NAME,
+
Re: Image filter controls
On Wed, 27 May 2009, Dongsoo, Nathaniel Kim wrote: Hi Guennadi, In my opinion (in totally user aspect) those CIDs you mentioned do not fit in the purpose. Only low-pass filtering control could be considered as a colorfx, even though low-pass filtering is not a color effect it could be possible to sense the meaning of effect on it. How about making a new CID for band-stop filtering control and V4L2_COLORFX_BORDER_DENOISING for low-pass filter? Maybe, let's see what others say. Although, the low-pass filter doesn't seem to be directly related to colour-transformation to me. BTW, would you give more information about fluorescent light band-stop filter in detail? Because if you mean flicker control caused by power line frequency, 50Hz...60Hz thing, I think we already have one for that. As far as I know, V4L2_CID_POWER_LINE_FREQUENCY is for that flickering control. No, here's an excerpt from a datasheet (not for the camera I'm implementing this, but it's the same parameter, I think): COMJ[2] - Band filter enable. After adjust frame rate to match indoor light frequency, this bit enable a different exposure algorithm to cut light band induced by fluorescent light. Not sure though how they reduce the fluorescent light by adjusting the exposure algorithm. Thanks Guennadi --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/ -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
OV7670 Soc-camera driver (anyone else want to merge versions?)
Hi All, The email is mainly in the interests of avoiding wasting time. I'm currently updating the driver I posted alongside Guennadi's soc-camera changes with the intention to also merge features from the 3 drivers that are out there. Unsurprisingly they all have different feature sets at the moment and ideally we want to support everything the individual drivers do. Is anyone else doing or aiming to do the same? Thanks, --- Jonathan Cameron -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
i2c-compat.h and old kernel support
I found that i2c-compat.h is not referred by any linux/media code and it seems code for Linux 2.4/2.5 support. What is the minimum supporting kernel of the current development tree? It looks like i2c-compat.h could be dropped. David -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] i2c: Simplified CONFIG_I2C=n interface.
On Wed, May 27, 2009 at 09:18:31AM +0200, Jean Delvare wrote: Violent nack. Drivers which optionally use I2C are a minority. It's extremely common for devices like the CODECs and PMICs used in embedded systems to have both I2C and SPI interfaces, selectable via a pin strap at power on. It's less common to have the SPI option for things like hardware monitoring chips found in PCs but for anything that might be I/O bound the high speed interface is a very common option. Designing them in such a way that a single #ifdef CONFIG_I2C will make them work can't be that hard, really. Not to mention that having a dozen stubs in i2c.h in the CONFIG_I2C=n case won't save you much work at the driver level anyway, because you certainly need to run different code paths depending on how the device is connected, and you also have to differentiate between the I2C support is missing case and the I2C device registration failed case, etc. For the devices I've dealt with there's very little work at the driver level - the various interfaces that can be used each probe using the normal device model, set some register read/write operations and possibly some other things and then call into the bulk of the driver which has all the I/O abstracted away from it. The error handling is already an issue with the current situation since people are just silently building out the I2C support when I2C is not enabled. At the minute the main problem is with people not remembering to do the #ifdef (a lot of platforms really need I2C enabled to be useful so people never think to do the build without). -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PULL] http://kernellabs.com/hg/~stoth/tda10048-merge/
Em Thu, 21 May 2009 22:26:29 -0500 (CDT) Mike Isely is...@isely.net escreveu: I see no issues here with the pvrusb2 part of it... Acked-by: Mike Isely is...@pobox.com Due to the way -hg works, I can't add your ack at -hg (otherwise, I would break Steven and mkrufky's trees). So, I'll add it at -git only Cheers, Mauro -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PULL] http://kernellabs.com/hg/~dheitmueller/misc-fixes
Em Sat, 23 May 2009 03:48:21 +0200 (CEST) BOUWSMA Barry freebeer.bouw...@gmail.com escreveu: On Thu, 21 May 2009, Devin Heitmueller wrote: em28xx: Don't let device work unless connected to a high speed USB port (grrr, dyndns addresses that are actually dynamically changing) |The em28xx basically just doesn't work at 12 Mbps. The isoc pipe needs |nearly 200 Mbps for analog support, so users would see garbage video, |and on |the DVB/ATSC side scanning is likely to work but if the user tried to |tune it |would certainly appear to have failed. |It's better to fail explicity up front and tell the user to plug into a |USB 2.0 Hi Devin, I've spent the last night trying to wrap my brane around the DVB code and how it reflects on the ability of hardware to perform PID filtering or not, thereby the expected load due to interrupts and filtering in the CPU. If my current machine is being fed a single stream from a lower-bandwidth source (not sure where the filtering to a crummy audio stream is being performed, but even the full bandwidth available from a 1,5MHz-wide chunk of spectrum is well within USB1.1), load is negligible. Multicasting the filtered data back out over a USB1.1 net adapter bumps up the interrupt load somewhat, but `top' idle time remains high. There are some cases where USB 1.1 is fine, being the most trivial example the FM radio reception. The trouble with em28xx and 1.5 Mbps or 12 Mbps is that, currently, em28xx doesn't limit its usage to fit into lower bus bandwidth. So, it would accept users call to provide non-compressed analog TV, at maximum resolution and at 30 fps even without having enough bandwidth at USB. It won't even generate a warning at dmesg. The problem will be noticed only due to the video garbage. So, the right solution to support 12 Mbps (or even 1.5 Mbps) would be to have some routines there to estimate the maximum bus bandwidth and to deny requests that would exceed it. Another alternative would be to have a whitelist for those devices that works fine with usb 1.1 (for example ISDB-T 1 seg and DVB-H devices without analog). I don't think it would be a worthy trial to do such patch (since USB 3.0 is arriving the market and USB 1.1 is an old standard), but if someone write such patch, we may later revert this one. While we don't have this, it is better to just deny rates lower than 480 Mbps. That's said, the reasons given at the patch for nacking USB low speed (on both the driver and the patch descriptions) are not ok, since the problem is not that em28xx only works with usb 2.0 or that all DVB streams will fail. Instead of: + /* Make sure they are connected to a USB 2.0 port. If the device is + connected to a USB 1.1 port at 12 Mbps, things like dvb scanning + will work but tuning will fail, and attempts to watch analog will + show garbage video. Better to just fail explicitly... */ So, it should be saying, instead: /* * Make sure we have 480 Mbps of bandwidth, otherwise things like * video stream wouldn't likely work, since 12 Mbps is generally * not enough even for most Digital TV streams. */ Devin, Could you please change the comment and the patch description and resubmit the pull request? Cheers, Mauro -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PULL] http://kernellabs.com/hg/~dheitmueller/misc-fixes
Em Thu, 21 May 2009 22:26:35 -0400 Devin Heitmueller dheitmuel...@kernellabs.com escreveu: Hello Mauro, Please pull from http://kernellabs.com/hg/~dheitmueller/misc-fixes for the following: em28xx: don't create the audio device if no onboard audio processor I don't think that this patch is right. There are some devices that are equipped with non ac97 audio processors, for example the ones with msp34xx. Those devices have digital audio. I'm not sure if they work with em28xx-audio or with snd-usb-audio. So, the safest way is not to deny the load of em28xx-audio. Cheers, Mauro -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PULL] http://kernellabs.com/hg/~dheitmueller/misc-fixes
On Wed, May 27, 2009 at 9:00 AM, Mauro Carvalho Chehab mche...@infradead.org wrote: Em Thu, 21 May 2009 22:26:35 -0400 Devin Heitmueller dheitmuel...@kernellabs.com escreveu: Hello Mauro, Please pull from http://kernellabs.com/hg/~dheitmueller/misc-fixes for the following: em28xx: don't create the audio device if no onboard audio processor I don't think that this patch is right. There are some devices that are equipped with non ac97 audio processors, for example the ones with msp34xx. Those devices have digital audio. I'm not sure if they work with em28xx-audio or with snd-usb-audio. So, the safest way is not to deny the load of em28xx-audio. Mauro, The code does take into account devices that provide I2S audio. However, I think you may be correct that if I2S audio is configured, the driver will not load. I think I'm going to need to rework the patch a bit. The correct behavior should be that the em28xx-audio driver should only be loaded if vendor audio is required (either AC97 or I2S), and it appears that my logic didn't accomplish that [I confused an if() for an else if()]. Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-dvb] fe status values
On Wed, May 27, 2009 at 6:59 AM, Markus Oliver Hahn markus.o.h...@gmx.de wrote: Hi there, I was just going throug the dvbapi 5.0 but I couldn`t find ow to interpret the values which I get by int ioctl( int fd, int request = FE_READ_SIGNAL_STRENGTH, int16_t *strength); and int ioctl(int fd, int request = FE_READ_SNR, int16_t *snr) strengt should be (signed) dBm and 0.snr dB is this right ? regards markus -- Neu: GMX FreeDSL Komplettanschluss mit DSL 6.000 Flatrate + Telefonanschluss für nur 17,95 Euro/mtl.!* http://portal.gmx.net/de/go/dsl02 ___ linux-dvb users mailing list For V4L/DVB development, please use instead linux-media@vger.kernel.org linux-...@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb Hello Markus, Unfortunately, there is currently no standard way in which the return values can be interpreted. The content varies by demodulator. This has been discussed at length on the linux-media ML if you want to read the back history. Regards, Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-dvb] EPG (Electronic Program Guide) Tools
Where does the EPG come from? Is it incorporated into the output stream through PID's some how or is it read from one of the other devices under adapter0? Are there simple command line tools to read it or do you have to write a custom program to interpret it somehow? Could someone please point me in the right direction to get started? If no tools exist, perhaps links to either api or lib docs/samples? Much appreciated. Chris. Hello Chris, The ATSC EPG is sent via the ATSC PSIP protocol. I do not know of any tools currently available to extract the information. MeTV has a working implementation (with some bugs I have seen), and I was looking at getting it to work in Kaffeine at some point. The spec is freely available here: http://www.atsc.org/standards/a_65cr1_with_amend_1.pdf Chris, You'd expect to be able to get 3-4 days of advanced data to populate a guide with, in reality you can often get as little a six hours and that's it. The mandatory side of the spec is weak in this area. six hours is fine for Now / Next but of little use for anything else. Depending on your needs, your mileage may vary. Regards, - Steve -- Steven Toth - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC,PATCH] VIDIOC_G_EXT_CTRLS does not handle NULL pointer correctly
On Monday 25 May 2009 21:22:06 Trent Piepho wrote:
On Mon, 25 May 2009, Laurent Pinchart wrote:
diff -r e0d881b21bc9 linux/drivers/media/video/v4l2-ioctl.c
--- a/linux/drivers/media/video/v4l2-ioctl.cTue May 19 15:12:17 2009
+0200 +++ b/linux/drivers/media/video/v4l2-ioctl.c Sun May 24 18:26:29
2009 +0200 @@ -402,6 +402,10 @@
a specific control that caused it. */
p-error_idx = p-count;
user_ptr = (void __user *)p-controls;
+ if (p-count KMALLOC_MAX_SIZE / sizeof(p-controls[0])) {
+ err = -ENOMEM;
+ goto out_ext_ctrl;
+ }
if (p-count) {
ctrls_size = sizeof(struct v4l2_ext_control) * p-count;
/* Note: v4l2_ext_controls fits in sbuf[] so mbuf is
still NULL. */
@@ -1859,6 +1863,10 @@
a specific control that caused it. */
p-error_idx = p-count;
user_ptr = (void __user *)p-controls;
+ if (p-count KMALLOC_MAX_SIZE / sizeof(p-controls[0])) {
+ err = -ENOMEM;
+ goto out_ext_ctrl;
+ }
if (p-count) {
ctrls_size = sizeof(struct v4l2_ext_control) * p-count;
/* Note: v4l2_ext_controls fits in sbuf[] so mbuf is
still NULL. */
Restricting v4l2_ext_controls::count to values smaller than
KMALLOC_MAX_SIZE / sizeof(struct v4l2_ext_control) should be enough, but
we might want to restrict the value even further. I'd like opinions on
this.
One thing that could be done is to call access_ok() on the range before
kmalloc'ing a buffer. If p-count is too high, then it's possible that the
copy_from_user will fail because the process does not have the address
space to copy.
arch/x86/include/asm/uaccess.h, about access_ok():
* Note that, depending on architecture, this function probably just
* checks that the pointer is in the user space range - after calling
* this function, memory access functions may still return -EFAULT.
I don't think it's worth it. Let's just kmalloc (or kzalloc) and
copy_from_user. If one of them fails we'll return an error.
Could a very large number of control requests be used as a DoS attack vector ?
A userspace application could kmalloc large amounts of memory without any
restriction. Memory would be reclaimed eventually, but after performing a
large number of USB requests, which could take quite a long time.
Best regards,
Laurent Pinchart
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC, PATCH] VIDIOC_G_EXT_CTRLS does not handle NULL pointer correctly
On Monday 25 May 2009 21:22:06 Trent Piepho wrote:
On Mon, 25 May 2009, Laurent Pinchart wrote:
diff -r e0d881b21bc9 linux/drivers/media/video/v4l2-ioctl.c
--- a/linux/drivers/media/video/v4l2-ioctl.c Tue May 19 15:12:17 2009
+0200 +++ b/linux/drivers/media/video/v4l2-ioctl.c Sun May 24 18:26:29
2009 +0200 @@ -402,6 +402,10 @@
a specific control that caused it. */
p-error_idx = p-count;
user_ptr = (void __user *)p-controls;
+ if (p-count KMALLOC_MAX_SIZE / sizeof(p-controls[0])) {
+ err = -ENOMEM;
+ goto out_ext_ctrl;
+ }
if (p-count) {
ctrls_size = sizeof(struct v4l2_ext_control) * p-count;
/* Note: v4l2_ext_controls fits in sbuf[] so mbuf is
still NULL.
*/
@@ -1859,6 +1863,10 @@
a specific control that caused it. */
p-error_idx = p-count;
user_ptr = (void __user *)p-controls;
+ if (p-count KMALLOC_MAX_SIZE / sizeof(p-controls[0])) {
+ err = -ENOMEM;
+ goto out_ext_ctrl;
+ }
if (p-count) {
ctrls_size = sizeof(struct v4l2_ext_control) * p-count;
/* Note: v4l2_ext_controls fits in sbuf[] so mbuf is
still NULL.
*/
Restricting v4l2_ext_controls::count to values smaller than
KMALLOC_MAX_SIZE / sizeof(struct v4l2_ext_control) should be enough,
but
we might want to restrict the value even further. I'd like opinions on
this.
One thing that could be done is to call access_ok() on the range before
kmalloc'ing a buffer. If p-count is too high, then it's possible that
the
copy_from_user will fail because the process does not have the address
space to copy.
arch/x86/include/asm/uaccess.h, about access_ok():
* Note that, depending on architecture, this function probably just
* checks that the pointer is in the user space range - after calling
* this function, memory access functions may still return -EFAULT.
I don't think it's worth it. Let's just kmalloc (or kzalloc) and
copy_from_user. If one of them fails we'll return an error.
Could a very large number of control requests be used as a DoS attack
vector ?
A userspace application could kmalloc large amounts of memory without any
restriction. Memory would be reclaimed eventually, but after performing a
large number of USB requests, which could take quite a long time.
Perhaps we should limit the number of controls to a maximum of 1024. That
should really be enough :-)
I'm OK with such a limitation.
Regards,
Hans
--
Hans Verkuil - video4linux developer - sponsored by TANDBERG
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Probably strange bug with usb radio-mr800
Hello,
Doing some improvements in media/radio/radio-mr800.c i see very
strange situation.
I made simple patch that removed usb_amradio_open function. There is
no need in this function (no need to start/set frequency radio in open
procedure, and also removed lock/unlock_kernel() calls).
Here is this patch:
diff -r a344b328a34b linux/drivers/media/radio/radio-mr800.c
--- a/linux/drivers/media/radio/radio-mr800.c Wed May 27 21:21:36 2009 +0400
+++ b/linux/drivers/media/radio/radio-mr800.c Wed May 27 21:25:41 2009 +0400
@@ -119,7 +119,6 @@
static int usb_amradio_probe(struct usb_interface *intf,
const struct usb_device_id *id);
static void usb_amradio_disconnect(struct usb_interface *intf);
-static int usb_amradio_open(struct file *file);
static int usb_amradio_close(struct file *file);
static int usb_amradio_suspend(struct usb_interface *intf,
pm_message_t message);
@@ -533,40 +532,6 @@
return 0;
}
-/* open device - amradio_start() and amradio_setfreq() */
-static int usb_amradio_open(struct file *file)
-{
- struct amradio_device *radio = video_get_drvdata(video_devdata(file));
- int retval;
-
- lock_kernel();
-
- radio-users = 1;
- radio-muted = 1;
-
- retval = amradio_set_mute(radio, AMRADIO_START);
- if (retval 0) {
- amradio_dev_warn(radio-videodev-dev,
- radio did not start up properly\n);
- radio-users = 0;
- unlock_kernel();
- return -EIO;
- }
-
- retval = amradio_set_stereo(radio, WANT_STEREO);
- if (retval 0)
- amradio_dev_warn(radio-videodev-dev,
- set stereo failed\n);
-
- retval = amradio_setfreq(radio, radio-curfreq);
- if (retval 0)
- amradio_dev_warn(radio-videodev-dev,
- set frequency failed\n);
-
- unlock_kernel();
- return 0;
-}
-
/*close device */
static int usb_amradio_close(struct file *file)
{
@@ -623,7 +588,6 @@
/* File system interface */
static const struct v4l2_file_operations usb_amradio_fops = {
.owner = THIS_MODULE,
- .open = usb_amradio_open,
.release= usb_amradio_close,
.ioctl = video_ioctl2,
};
Then i test it. I have two machines: pentium-m and athlon 64 X2 dual
core. Kernel is 2.6.30-rc7 on both machines.
After patch such tools like fmtools, gnomeradio, kradio works fine
with radio. But mplayer didn't.
On 64bit machine mplayer didn't start radio. I ask usbmon to help me
and here is messages from usbmon:
cat /sys/kernel/debug/usbmon/2u
880022e380c0 1662784522 S Io:2:003:2 -115:64 8 = 0055aa00 ab01
(this message stops radio)
880022e380c0 1662799160 C Io:2:003:2 0:64 8
880022e380c0 1662799273 S Io:2:003:2 -115:64 8 = 0055aa00 ae00
(this ask radio to have stereo signal)
880022e380c0 1662831161 C Io:2:003:2 0:64 8
880022e380c0 1662831439 S Io:2:003:2 -115:64 8 = 0055aa03 a408
(this and next message set frequency)
880022e380c0 1662863161 C Io:2:003:2 0:64 8
880022e380c0 1662863233 S Io:2:003:2 -115:64 8 = 1dd00100
880022e380c0 1662895155 C Io:2:003:2 0:64 8
880022e380c0 1662895190 S Io:2:003:2 -115:64 8 = 0055aa00 ab00
(this message starts radio)
880022e380c0 1662927156 C Io:2:003:2 0:64 8
Well, there is no sound from usb device after that.
On 32bit machine mplayer starts radio fine and works ok. Usbmon shows
me the same messages:
tux ~ # cat /sys/kernel/debug/usbmon/0u
f6530900 2647820070 S Io:2:002:2 -115:64 8 = 0055aa00 ab01
f6530900 2647859740 C Io:2:002:2 0:64 8
f6530900 2647859825 S Io:2:002:2 -115:64 8 = 0055aa00 ae00
f6530900 2647923747 C Io:2:002:2 0:64 8
f6530900 2647923942 S Io:2:002:2 -115:64 8 = 0055aa03 a408
f6530900 2647987749 C Io:2:002:2 0:64 8
f6530900 2647987766 S Io:2:002:2 -115:64 8 = 1dcf0100
f6530900 2648051747 C Io:2:002:2 0:64 8
f6530900 2648051775 S Io:2:002:2 -115:64 8 = 0055aa00 ab00
f6530900 2648115753 C Io:2:002:2 0:64 8
So, the same messages to device works fine with radio on 32bit machine
and nothing on 64bit machine.
Good thing is if i add one more start message radio works on 64bit machine also.
Is this usb subsystem bug?
Should i make some workaround to deal with this and add comments about mplayer?
--
Best regards, Klimov Alexey
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[cron job] v4l-dvb daily build 2.6.22 and up: ERRORS, 2.6.16-2.6.21: ERRORS
This message is generated daily by a cron job that builds v4l-dvb for the kernels and architectures in the list below. Results of the daily build of v4l-dvb: date:Wed May 27 19:00:06 CEST 2009 path:http://www.linuxtv.org/hg/v4l-dvb changeset: 11873:22fcdb8c1c36 gcc version: gcc (GCC) 4.3.1 hardware:x86_64 host os: 2.6.26 linux-2.6.22.19-armv5: OK linux-2.6.23.12-armv5: OK linux-2.6.24.7-armv5: OK linux-2.6.25.11-armv5: OK linux-2.6.26-armv5: OK linux-2.6.27-armv5: OK linux-2.6.28-armv5: OK linux-2.6.29.1-armv5: OK linux-2.6.30-rc7-armv5: OK linux-2.6.27-armv5-ixp: WARNINGS linux-2.6.28-armv5-ixp: WARNINGS linux-2.6.29.1-armv5-ixp: WARNINGS linux-2.6.30-rc7-armv5-ixp: WARNINGS linux-2.6.28-armv5-omap2: WARNINGS linux-2.6.29.1-armv5-omap2: WARNINGS linux-2.6.30-rc7-armv5-omap2: WARNINGS linux-2.6.22.19-i686: ERRORS linux-2.6.23.12-i686: ERRORS linux-2.6.24.7-i686: ERRORS linux-2.6.25.11-i686: ERRORS linux-2.6.26-i686: WARNINGS linux-2.6.27-i686: WARNINGS linux-2.6.28-i686: WARNINGS linux-2.6.29.1-i686: WARNINGS linux-2.6.30-rc7-i686: WARNINGS linux-2.6.23.12-m32r: OK linux-2.6.24.7-m32r: OK linux-2.6.25.11-m32r: OK linux-2.6.26-m32r: OK linux-2.6.27-m32r: OK linux-2.6.28-m32r: OK linux-2.6.29.1-m32r: OK linux-2.6.30-rc7-m32r: OK linux-2.6.22.19-mips: ERRORS linux-2.6.26-mips: ERRORS linux-2.6.27-mips: ERRORS linux-2.6.28-mips: ERRORS linux-2.6.29.1-mips: ERRORS linux-2.6.30-rc7-mips: ERRORS linux-2.6.27-powerpc64: WARNINGS linux-2.6.28-powerpc64: WARNINGS linux-2.6.29.1-powerpc64: WARNINGS linux-2.6.30-rc7-powerpc64: WARNINGS linux-2.6.22.19-x86_64: ERRORS linux-2.6.23.12-x86_64: ERRORS linux-2.6.24.7-x86_64: ERRORS linux-2.6.25.11-x86_64: ERRORS linux-2.6.26-x86_64: WARNINGS linux-2.6.27-x86_64: WARNINGS linux-2.6.28-x86_64: WARNINGS linux-2.6.29.1-x86_64: WARNINGS linux-2.6.30-rc7-x86_64: WARNINGS sparse (linux-2.6.29.1): OK sparse (linux-2.6.30-rc7): OK linux-2.6.16.61-i686: ERRORS linux-2.6.17.14-i686: ERRORS linux-2.6.18.8-i686: ERRORS linux-2.6.19.5-i686: ERRORS linux-2.6.20.21-i686: ERRORS linux-2.6.21.7-i686: ERRORS linux-2.6.16.61-x86_64: ERRORS linux-2.6.17.14-x86_64: ERRORS linux-2.6.18.8-x86_64: ERRORS linux-2.6.19.5-x86_64: ERRORS linux-2.6.20.21-x86_64: ERRORS linux-2.6.21.7-x86_64: ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Wednesday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Wednesday.tar.bz2 The V4L2 specification from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/v4l2.html The DVB API specification from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/dvbapi.pdf -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: v4l-dvb and old kernels
Em Tue, 26 May 2009 15:03:56 +0200 Antonio Beamud Montero antonio.bea...@gmail.com escreveu: It would compile today's snapshot of v4l-dvb with an old kernel version (for example 2.6.16)? (or is better to upgrade the kernel?) Trying to compile today's mercurial snapshot in a SuSE 10.1 (2.6.16-21), give the next errors: /root/v4l-dvb/v4l/bttv-i2c.c: In function 'init_bttv_i2c': /root/v4l-dvb/v4l/bttv-i2c.c:411: error: storage size of 'info' isn't known /root/v4l-dvb/v4l/bttv-i2c.c:425: error: invalid application of 'sizeof' to incomplete type 'struct i2c_board_info' /root/v4l-dvb/v4l/bttv-i2c.c:425: error: invalid application of 'sizeof' to incomplete type 'struct i2c_board_info' /root/v4l-dvb/v4l/bttv-i2c.c:425: error: invalid application of 'sizeof' to incomplete type 'struct i2c_board_info' /root/v4l-dvb/v4l/bttv-i2c.c:425: error: invalid application of 'sizeof' to incomplete type 'struct i2c_board_info' /root/v4l-dvb/v4l/bttv-i2c.c:425: error: invalid application of 'sizeof' to incomplete type 'struct i2c_board_info' /root/v4l-dvb/v4l/bttv-i2c.c:425: error: invalid application of 'sizeof' to incomplete type 'struct i2c_board_info' /root/v4l-dvb/v4l/bttv-i2c.c:427: error: implicit declaration of function 'i2c_new_probed_device' /root/v4l-dvb/v4l/bttv-i2c.c:411: warning: unused variable 'info' make[5]: *** [/root/v4l-dvb/v4l/bttv-i2c.o] Error 1 The issue should be fixed with the current tip. I just added a backport patch that will restore backward compilation starting from 2.6.16 Cheers, Mauro -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: v4l: Compile ADV7343 and THS7303 drivers for kernels = 2.6.26
Em Wed, 27 May 2009 01:42:44 -0400 Chaithrika U S chaithr...@ti.com escreveu: Signed-off-by: Chaithrika U S chaithr...@ti.com --- v4l/versions.txt |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/v4l/versions.txt b/v4l/versions.txt index eb206b5..3c57c14 100644 --- a/v4l/versions.txt +++ b/v4l/versions.txt @@ -13,6 +13,8 @@ USB_STV06XX VIDEO_TVP514X # requires id_table and new i2c stuff RADIO_TEA5764 +VIDEO_THS7303 +VIDEO_ADV7343 [2.6.25] # Requires gpiolib Thanks for the patch, but I just added a patch fixing compilation with older kernels. There were more things broken due to the ir-kbd-i2c patches. Cheers, Mauro -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Fwd: [Linux-uvc-devel] Compilation error
Em Wed, 27 May 2009 01:57:55 +0200 Laurent Pinchart laurent.pinch...@skynet.be escreveu: Hi everybody, -- Forwarded Message -- Subject: [Linux-uvc-devel] Compilation error Date: Tuesday 26 May 2009 From: Phil Lemelin To: linux-uvc-de...@lists.berlios.de Hi uvc-devel list, I'm trying to get my usb camera to work ( 174f:8a34 Syntek ) on a older system ( 2.6.18-6, debian etch ) and I am not able to compile the source code found on the HG repository. The error I get is the following : *snip* CC [M] /home/phil/uvcvideo-b7cdedd8e305/v4l/av7110_hw.o /home/phil/uvcvideo-b7cdedd8e305/v4l/av7110_hw.c:294: error: expected declaration specifiers or '...' before string constant /home/phil/uvcvideo-b7cdedd8e305/v4l/av7110_hw.c:294: warning: data definition has no type or storage class /home/phil/uvcvideo-b7cdedd8e305/v4l/av7110_hw.c:294: warning: type defaults to 'int' in declaration of 'MODULE_FIRMWARE' /home/phil/uvcvideo-b7cdedd8e305/v4l/av7110_hw.c:294: warning: function declaration isn't a prototype make[3]: *** [/home/phil/uvcvideo-b7cdedd8e305/v4l/av7110_hw.o] Error 1 make[2]: *** [_module_/home/phil/uvcvideo-b7cdedd8e305/v4l] Error 2 make[2]: Leaving directory `/usr/src/linux-headers-2.6.18-6-686' make[1]: *** [default] Error 2 make[1]: Leaving directory `/home/phil/uvcvideo-b7cdedd8e305/v4l' make: *** [all] Error 2 --- Is an update to v4l/versions.txt needed ? I just applied a patch at tip that restores compilation with legacy kernels, tested here with a RHEL5 kernel (a patched version of 2.6.16) Cheers, Mauro -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: USB/DVB - Old Technotrend TT-connect S-2400 regression tracked down
Alan Stern wrote: On Mon, 25 May 2009, David wrote: I think the idea of the patch was good, but the endpoint direction information got lost (because the information was taken from the dummy qTD which is always marked as OUT -- I don't see how this could ever have worked properly). So let's redo it, using the new and proper interface for resetting endpoints. To tell the truth, I'm not entirely certain this will work either. The hardware may cache the endpoint state, so it may be necessary to unlink the endpoint completely. Still, try this version and see what happens. Alan Stern Sorry for the delay, your patch reached me just after I turned in last night. It looks good to me. dmesg is how I'd expect, and I've attached the usb trace which looks pretty similar to when the original patch was reverted. I'll test some more with some other peripherals check that they work ok. Thanks a lot! David patch2.log.bz2 Description: application/bzip
[PATCH v2] Re: videodev: Unknown symbol i2c_unregister_device (in kernels older than 2.6.26)
Mauro Carvalho Chehab wrote:
Em Mon, 25 May 2009 09:10:17 +1000
Matt Doran matt.do...@papercut.com escreveu:
Hi there,
I tried using the latest v4l code on an Mythtv box running 2.6.20, but
the v4l videodev module fails to load with the following warnings:
videodev: Unknown symbol i2c_unregister_device
v4l2_common: Unknown symbol v4l2_device_register_subdev
It seems the i2c_unregister_device function was added in 2.6.26.
References to this function in v4l2-common.c are enclosed in an ifdef like:
#if LINUX_VERSION_CODE = KERNEL_VERSION(2, 6, 26)
However in v4l2_device_unregister() in v4l2-device.c, there is a
reference to i2c_unregister_device without any ifdefs. I am running
a pretty old kernel, but I'd guess anyone running 2.6.25 or earlier will
have this problem. It seems this code was added by Mauro 3 weeks ago
in this rev:
http://linuxtv.org/hg/v4l-dvb/rev/87afa7a4ccdf
I've just applied a patch at the tree that should fix this issue. It adds
several tests and the code, but, hopefully, it should be possible even to use
the IR's with kernels starting from 2.6.16.
Hi Mauro,
If you are referring to my recent patch, it needs a modification to be like
other places in drivers/media/video. Patch below applies on top of the
previous one.
---
From: Randy Dunlap randy.dun...@oracle.com
Fix v4l2-device usage of i2c_unregister_device() and handle the case of
CONFIG_I2C=m CONFIG_MEDIA_VIDEO=y.
Signed-off-by: Randy Dunlap randy.dun...@oracle.com
---
drivers/media/video/v4l2-device.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- linux-next-20090527.orig/drivers/media/video/v4l2-device.c
+++ linux-next-20090527/drivers/media/video/v4l2-device.c
@@ -85,7 +85,7 @@ void v4l2_device_unregister(struct v4l2_
/* Unregister subdevs */
list_for_each_entry_safe(sd, next, v4l2_dev-subdevs, list) {
v4l2_device_unregister_subdev(sd);
-#if defined(CONFIG_I2C) || defined(CONFIG_I2C_MODULE)
+#if defined(CONFIG_I2C) || (defined(CONFIG_I2C_MODULE) defined(MODULE))
if (sd-flags V4L2_SUBDEV_FL_IS_I2C) {
struct i2c_client *client = v4l2_get_subdevdata(sd);
--
~Randy
LPC 2009, Sept. 23-25, Portland, Oregon
http://linuxplumbersconf.org/2009/
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH][RESEND] Use correct sampling rate for TV/FM radio
Em Sat, 23 May 2009 19:09:12 +0200 Oldrich Jedlicka oldium@seznam.cz escreveu: On Tuesday 19 of May 2009 at 19:54:18, Oldrich Jedlicka wrote: On Tuesday 14 of April 2009 at 20:48:14, Oldrich Jedlicka wrote: Here is the fix for using the 32kHz sampling rate for TV and FM radio (ALSA). The TV uses 32kHz anyway (mode 0; 32kHz demdec on), radio works only with 32kHz (mode 1; 32kHz baseband). The ALSA wrongly reported 32kHz and 48kHz for everything (TV, radio, LINE1/2). Now it should be possible to just use the card without the need to change the capture rate from 48kHz to 32kHz. Enjoy :-) Hi Mauro, I put you on CC in my previous mail, but maybe it would be better to send it directly. So do you have any opinions about the approach described above/below? I did a look at saa713x datasheet. In thesis, it could be possible to program the audio sampling rate divider for several rates including 32 kHz, 44.1 kHz and 48 kHz. However, I suspect that only MONO is supported with rates different than 32 kHz, since it is said there that AM/FM requires a nominal audio sample of 32 kHz, and that NICAM nominal audio sample rate is 32 kHz. So, IMO, the right patch is just to allow samplings at 32 kHz Cheers, Mauro -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Licensing question regarding SN9C2028 decompression (fwd)
Hans, Here is the answer which I got about the question of GPL-LGPL licensing in regard to the sn9c2028 decompression code. Theodore Kilgore -- Forwarded message -- Date: Wed, 27 May 2009 13:19:46 -0400 From: Harald h...@users.sourceforge.net To: Theodore Kilgore kilg...@banach.math.auburn.edu Subject: Re: Licensing question regarding SN9C2028 decompression Hi Theodore, I give you permission to use the SN9C2028 code with a LGPL license. I am the current maintainer of the macam project. Most of the code that has been added in the last few years is mine. However, I did not originate the SN9C2028 code. I have messed with it a lot, it may not bear much resemblance to the original code. I am sure that whatever code you based your version on has been modified as well. I doubt that you use Objective-C for example... It is likely that technically all of macam should be under LGPL anyway, as it works as a plug-in component to QuickTime. So from an intent perspective, that is how the macam code is used anyway. You should be able to use it the same way. I have never been able to contact the originator (mattik) of the project! I became admin through an intermediate admin (dirkx). We're all three admins, but neither of the others have contributed anything in the last 5 years. I hope this helps, Harald On May 24, 2009, at 13:40, Theodore Kilgore wrote: Harald, Right now I am working on putting streaming support for the SN9C2028 cameras (supported by libgphoto2/camlibs/sonix as still cameras) into the Linux kernel, as part of linux/drivers/media/video/gspca. In doing so, there is a licensing conflict, as follows: The Linux kernel is of course GPL licensed, as we are aware. However, the philosophy of what the kernel is supposed to do with things like video devices is, it takes care of creating a device dev/video and it takes care of basic infrastructural things such as how to talk to the camera, to initialize it, to turn it off, to tell it to stream, and to detect and save packets and to construct frames. The code for things like decompression has been deliberately moved away from the kernel code, and the idea is to put all that stuff into a library called libv4l, which then provides a unified interface for userspace streaming apps. The problem is, the decompression code would need to go into part of libv4l, namely libv4lconvert. And the license for libv4l and everything in it is LGPL, not GPL. As the originator of the decompression function for the Sonix cameras, are you willing to give permission for taking my version of the code from GPL to LGPL? Or can you suggest some other appropriate course of action? Theodore Kilgore -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: USB/DVB - Old Technotrend TT-connect S-2400 regression tracked down
Alan Stern wrote: On Wed, 27 May 2009, David wrote: Sorry for the delay, your patch reached me just after I turned in last night. It looks good to me. dmesg is how I'd expect, and I've attached the usb trace which looks pretty similar to when the original patch was reverted. I'll test some more with some other peripherals check that they work ok. Thanks a lot! I'm not done yet. That patch seemed a bit unsafe, so I revised it. This version is a lot more careful about modifying data structures while they are still in use by the hardware. If it works okay for you, I'll submit it. Still looks good to me. Cheers David patch3.log.bz2 Description: application/bzip
[PATCH] vino: replace dma_sync_single with dma_sync_single_for_cpu
This replaces dma_sync_single() with dma_sync_single_for_cpu() because dma_sync_single() is an obsolete API; include/linux/dma-mapping.h says: /* Backwards compat, remove in 2.7.x */ #define dma_sync_single dma_sync_single_for_cpu #define dma_sync_sg dma_sync_sg_for_cpu Signed-off-by: FUJITA Tomonori fujita.tomon...@lab.ntt.co.jp --- drivers/media/video/vino.c |6 +++--- 1 files changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/media/video/vino.c b/drivers/media/video/vino.c index 43e0998..97b082f 100644 --- a/drivers/media/video/vino.c +++ b/drivers/media/video/vino.c @@ -868,9 +868,9 @@ static void vino_sync_buffer(struct vino_framebuffer *fb) dprintk(vino_sync_buffer():\n); for (i = 0; i fb-desc_table.page_count; i++) - dma_sync_single(NULL, - fb-desc_table.dma_cpu[VINO_PAGE_RATIO * i], - PAGE_SIZE, DMA_FROM_DEVICE); + dma_sync_single_for_cpu(NULL, + fb-desc_table.dma_cpu[VINO_PAGE_RATIO * i], + PAGE_SIZE, DMA_FROM_DEVICE); } /* Framebuffer fifo functions (need to be locked externally) */ -- 1.6.0.6 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PULL] http://kernellabs.com/hg/~dheitmueller/misc-fixes-2
Hello Mauro, Please pull from http://kernellabs.com/hg/~dheitmueller/misc-fixes-2 for the following: em28xx: Don't let device work unless connected to a high speed USB port au0828: Don't let device work unless connected to a high speed USB port em28xx: Add support for the K-World 2800d tuner-core: fix warning introduced when cleaning up xc5000 init routine em28xx: provide module option to disable USB speed check au0828: provide module option to disable USB speed check The series changes the comment as you requested, adds a routine to allow advanced users to override the bus speed check (at their own risk), and removes the patch related to the loading of the em28xx-audio if no audio present. I will need to revisit that code and come up with the correct patch that works even with i2s audio. Thanks, Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Unknown symbol __udivdi3 with rev = 11873
Revision 11873 (committed earlier today) has broken the cx18 driver for me, with the line cx18: Unknown symbol __udivdi3 appearing in dmesg when the module tries to load. I'm using Ubuntu 8.04.2 which uses kernel 2.6.24 and gcc 4.2.4. I also wanted to express my appreciation to Mauro for fixing the build for older kernels today, as it is very desirable for me to use a distribution/kernel which has long-term support and updates, but I simply need to add a DVB driver that wasn't part of the older kernel. Thanks so much. David Ward -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[RESEND PATCH 3/3 v2] big rework of TS for saa7134
Hi all.
1. Add start/stop TS function.
2. Move setup DMA of TS to DMA function.
3. Write support cupture via MMAP
4. Rework startup and finish process, remove simple FSM.
diff -r 8d37e8505664 linux/drivers/media/video/saa7134/saa7134-cards.c
--- a/linux/drivers/media/video/saa7134/saa7134-cards.c Mon May 11 09:37:41
2009 -0700
+++ b/linux/drivers/media/video/saa7134/saa7134-cards.c Tue May 12 21:48:12
2009 +0200
@@ -4495,6 +4495,7 @@
/* Igor Kuznetsov i...@igk.ru */
/* Andrey Melnikoff temn...@kmv.ru */
/* Beholder Intl. Ltd. Dmitry Belimov d.beli...@gmail.com */
+ /* Alexey Osipov lion-si...@pridelands.ru */
.name = Beholder BeholdTV M6,
.audio_clock= 0x00187de7,
.tuner_type = TUNER_PHILIPS_FM1216ME_MK3,
@@ -4569,6 +4570,7 @@
/* Igor Kuznetsov i...@igk.ru */
/* Andrey Melnikoff temn...@kmv.ru */
/* Beholder Intl. Ltd. Dmitry Belimov d.beli...@gmail.com */
+ /* Alexey Osipov lion-si...@pridelands.ru */
.name = Beholder BeholdTV M6 Extra,
.audio_clock= 0x00187de7,
.tuner_type = TUNER_PHILIPS_FM1216ME_MK3, /* FIXME to MK5 */
diff -r 8d37e8505664 linux/drivers/media/video/saa7134/saa7134-core.c
--- a/linux/drivers/media/video/saa7134/saa7134-core.c Mon May 11 09:37:41
2009 -0700
+++ b/linux/drivers/media/video/saa7134/saa7134-core.c Tue May 12 21:48:12
2009 +0200
@@ -380,6 +380,10 @@
dprintk(buffer_next %p\n,NULL);
saa7134_set_dmabits(dev);
del_timer(q-timeout);
+
+ if (card_has_mpeg(dev))
+ if (dev-ts_started)
+ saa7134_ts_stop(dev);
}
}
@@ -465,6 +469,19 @@
ctrl |= SAA7134_MAIN_CTRL_TE5;
irq |= SAA7134_IRQ1_INTE_RA2_1 |
SAA7134_IRQ1_INTE_RA2_0;
+
+ /* dma: setup channel 5 (= TS) */
+
+ saa_writeb(SAA7134_TS_DMA0, (dev-ts.nr_packets - 1) 0xff);
+ saa_writeb(SAA7134_TS_DMA1,
+ ((dev-ts.nr_packets - 1) 8) 0xff);
+ /* TSNOPIT=0, TSCOLAP=0 */
+ saa_writeb(SAA7134_TS_DMA2,
+ (((dev-ts.nr_packets - 1) 16) 0x3f) | 0x00);
+ saa_writel(SAA7134_RS_PITCH(5), TS_PACKET_SIZE);
+ saa_writel(SAA7134_RS_CONTROL(5), SAA7134_RS_CONTROL_BURST_16 |
+ SAA7134_RS_CONTROL_ME |
+ (dev-ts.pt_ts.dma 12));
}
/* set task conditions + field handling */
diff -r 8d37e8505664 linux/drivers/media/video/saa7134/saa7134-empress.c
--- a/linux/drivers/media/video/saa7134/saa7134-empress.c Mon May 11
09:37:41 2009 -0700
+++ b/linux/drivers/media/video/saa7134/saa7134-empress.c Tue May 12
21:48:12 2009 +0200
@@ -255,6 +255,16 @@
return 0;
}
+static int empress_try_fmt_vid_cap(struct file *file, void *priv,
+ struct v4l2_format *f)
+{
+ struct saa7134_dev *dev = file-private_data;
+
+ f-fmt.pix.pixelformat = V4L2_PIX_FMT_MPEG;
+ f-fmt.pix.sizeimage= TS_PACKET_SIZE * dev-ts.nr_packets;
+
+ return 0;
+}
static int empress_reqbufs(struct file *file, void *priv,
struct v4l2_requestbuffers *p)
@@ -450,6 +460,7 @@
static const struct v4l2_ioctl_ops ts_ioctl_ops = {
.vidioc_querycap= empress_querycap,
.vidioc_enum_fmt_vid_cap= empress_enum_fmt_vid_cap,
+ .vidioc_try_fmt_vid_cap = empress_try_fmt_vid_cap,
.vidioc_s_fmt_vid_cap = empress_s_fmt_vid_cap,
.vidioc_g_fmt_vid_cap = empress_g_fmt_vid_cap,
.vidioc_reqbufs = empress_reqbufs,
diff -r 8d37e8505664 linux/drivers/media/video/saa7134/saa7134-ts.c
--- a/linux/drivers/media/video/saa7134/saa7134-ts.cMon May 11 09:37:41
2009 -0700
+++ b/linux/drivers/media/video/saa7134/saa7134-ts.cTue May 12 21:48:12
2009 +0200
@@ -67,33 +67,8 @@
mod_timer(dev-ts_q.timeout, jiffies+TS_BUFFER_TIMEOUT);
- if (dev-ts_state == SAA7134_TS_BUFF_DONE) {
- /* Clear TS cache */
- dev-buff_cnt = 0;
- saa_writeb(SAA7134_TS_SERIAL1, 0x00);
- saa_writeb(SAA7134_TS_SERIAL1, 0x03);
- saa_writeb(SAA7134_TS_SERIAL1, 0x00);
- saa_writeb(SAA7134_TS_SERIAL1, 0x01);
-
- /* TS clock non-inverted */
- saa_writeb(SAA7134_TS_SERIAL1, 0x00);
-
- /* Start TS stream */
- switch (saa7134_boards[dev-board].ts_type) {
- case SAA7134_MPEG_TS_PARALLEL:
- saa_writeb(SAA7134_TS_SERIAL0, 0x40);
-
