Re: [ivtv-devel] tveeprom cannot autodetect tuner! (FQ1216LME MK5)

2009-05-27 Thread Hans Verkuil
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)

2009-05-27 Thread Hans Verkuil
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.

2009-05-27 Thread Paul Mundt
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.

2009-05-27 Thread Jean Delvare
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

2009-05-27 Thread Antti Palosaari

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

2009-05-27 Thread Eduardo Valentin
# 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

2009-05-27 Thread Eduardo Valentin
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

2009-05-27 Thread Eduardo Valentin
# 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

2009-05-27 Thread Eduardo Valentin
# 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

2009-05-27 Thread Eduardo Valentin
# 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

2009-05-27 Thread Eduardo Valentin
# 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

2009-05-27 Thread Eduardo Valentin
# 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

2009-05-27 Thread Eduardo Valentin
# 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

2009-05-27 Thread Guennadi Liakhovetski
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?)

2009-05-27 Thread Jonathan Cameron
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

2009-05-27 Thread David Wong
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.

2009-05-27 Thread Mark Brown
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/

2009-05-27 Thread Mauro Carvalho Chehab
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

2009-05-27 Thread Mauro Carvalho Chehab
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

2009-05-27 Thread Mauro Carvalho Chehab
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

2009-05-27 Thread Devin Heitmueller
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

2009-05-27 Thread Devin Heitmueller
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

2009-05-27 Thread Steven Toth

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

2009-05-27 Thread Laurent Pinchart
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

2009-05-27 Thread Hans Verkuil

 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

2009-05-27 Thread Alexey Klimov
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

2009-05-27 Thread Hans Verkuil
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

2009-05-27 Thread Mauro Carvalho Chehab
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

2009-05-27 Thread Mauro Carvalho Chehab
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

2009-05-27 Thread Mauro Carvalho Chehab
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

2009-05-27 Thread David
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)

2009-05-27 Thread Randy Dunlap
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

2009-05-27 Thread Mauro Carvalho Chehab
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)

2009-05-27 Thread Theodore Kilgore


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

2009-05-27 Thread David
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

2009-05-27 Thread FUJITA Tomonori
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


Re: PULL request - http://linuxtv.org/hg/~pb/v4l-dvb/

2009-05-27 Thread Trent Piepho
On Tue, 26 May 2009, Patrick Boettcher wrote:
  MHz to 161 Mhz as welll as 439-447 MHz.  Probably wrong.  My guess is the
  data sheet says, low band 48 to 154 MHz, mid band 161 MHz to 439 MHz,
  etc., where 154 is the frequency of the last channel in the low band and
  161 is the first channel in the mid band.  Then someone translated this to
  code without really understanding what's going on.  It should probably be:
 
  if  (params-frequency  44300) bs = 0x08;
  else if (params-frequency  15750) bs = 0x0a;
  elsebs = 0x09;
 
  The tuner's limits should already be enforced elsewhere.  Or just convert
  this to use dvb_pll.

 Thanks for pointing this out, can you please provide a patch for that?
 Preferably for the dvb_pll-solution?

I've done this, but found some more mistakes in the flexcop code wrt
frontend attachment.

In patch 7469 you changed a failure path dvb_frontend_detach(fc-fe) into
a fc-fe-ops-release(fc-fe), which isn't correct.  There is more stuff
dvb_frontend_detach() does besides call the main release method.

The various attach functions in flexcop-fe-tuner don't return success/fail,
which is a problem when frontend attachment partially fails.  For instance
if mt352 attachment works but dvb-pll attachment then fails the driver
will think everything is ok because fc-fe is non-NULL, but the tuner will
not work.  It makes more sense to consider this an error and clean up.

There are a couple other places where frontend attachment can partially
fail where I wasn't entirely sure what's right.  In
skystar2_rev27_attach(), after the s5h1420 demod is attached, attachment of
a ISL6421 LNB and ITD1000 tuner is attempted.  If these fail an error
message is printed but the rest of the code will consider the frontend to
be successfully attached.  Can the frontend work if the ISL6421 or ITD1000
didn't attach (which can happen if the driver isn't present even if the
hardware is fine)?  I'm guessing not and called these cases an error.  If
it's not an error, then the err() printout should probably be warning or
info level.

Does this patch to fix these problems look ok?

Maybe change if (!i2c_tuner) return 0; into BUG_ON(!i2c_tuner);?

In the case of a partial frontend attachment failure, should we keep
trying the rest of the frontends in the list or fail out early?  This patch
does the former, but the latter could easily be done by adding a break to
the end of the Clean up partially attached frontend code block.


# HG changeset patch
# User Trent Piepho xy...@speakeasy.org
# Date 1243476805 25200
# Node ID 27aa25fe54ae2fd9a166bfdb3cec4c4ecadc9cba
# Parent  480905f8768ce2e5b01da1c6d723cf95cf134d0b
b2c2: Fix problems with frontend attachment

From: Trent Piepho xy...@speakeasy.org

The frontend attachment code didn't handle cases where the frontend
partially failed to attach.  For instance, when the demod was attached
successfully but the tuner driver wasn't compiled or fails to init for some
reason.  In these cases we try to clean up the partial attachment and fail
instead of proceeding with a broken frontend.

If frontend registration fails, clean up with dvb_frontend_detach() rather
than just calling the frontend's main release method.  The former does some
additional stuff, like release an attached tuner and take care of putting
symbols when dynamic binding is used.

In skystar2_rev23_attach() it's not necessary to set fc-dev_type, that
gets set before skystar2_rev23_attach() is called.

Priority: normal

Signed-off-by: Trent Piepho xy...@speakeasy.org

diff -r 480905f8768c -r 27aa25fe54ae 
linux/drivers/media/dvb/b2c2/flexcop-fe-tuner.c
--- a/linux/drivers/media/dvb/b2c2/flexcop-fe-tuner.c   Wed May 27 17:35:06 
2009 -0700
+++ b/linux/drivers/media/dvb/b2c2/flexcop-fe-tuner.c   Wed May 27 19:13:25 
2009 -0700
@@ -175,23 +175,23 @@ static int skystar23_samsung_tbdu18132_t
return 0;
 }

-static void skystar2_rev23_attach(struct flexcop_device *fc,
-   struct i2c_adapter *i2c)
-{
-   fc-fe = dvb_attach(mt312_attach,
-   skystar23_samsung_tbdu18132_config, i2c);
+static int skystar2_rev23_attach(struct flexcop_device *fc,
+   struct i2c_adapter *i2c)
+{
+   fc-fe = dvb_attach(mt312_attach, skystar23_samsung_tbdu18132_config, 
i2c);
if (fc-fe != NULL) {
struct dvb_frontend_ops *ops = fc-fe-ops;
-   ops-tuner_ops.set_params \
-   = skystar23_samsung_tbdu18132_tuner_set_params;
+   ops-tuner_ops.set_params   =
+   skystar23_samsung_tbdu18132_tuner_set_params;
ops-diseqc_send_master_cmd = flexcop_diseqc_send_master_cmd;
ops-diseqc_send_burst  = flexcop_diseqc_send_burst;
ops-set_tone   = flexcop_set_tone;
ops-set_voltage= flexcop_set_voltage;
fc-fe_sleep= ops-sleep;
ops-sleep

[PULL] http://kernellabs.com/hg/~dheitmueller/misc-fixes-2

2009-05-27 Thread Devin Heitmueller
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

2009-05-27 Thread David Ward
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

2009-05-27 Thread Dmitri Belimov
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);
-