v4l-dvb status
good morning to all in the list. I have a few questions, back trying to install v4l-dvb kernel drivers after some time. 1. Is the project going to support kernel 2.6.31? 2. I used to use tvtime + sox for the usb audio, with big problems causing audio desynchronization with large delay with respect to the video: do the (new) drivers solve the issue? - I also remember that there was an integrated version of tvtime/usb audio in hg repositories, is it still maintained? is there a particular version to download to correctly build it? 3. It's two years since I first installed v4l-dvb drivers, and still I encounter problems to find all the channels with tvtime. Is there some module parameter to provide for the module em28xx for Pinnacle PCTV USB2, for the Italian standards? Thanks in advance for any hint and the great work done on v4l-dvb project Giacomo -- Giacomo S. http://www.giacomos.it - - - - - - - - - - - - - - - - - - - - - - * Aprile 2008: iqfire-wall, un progetto open source che implementa un filtro di pacchetti di rete per Linux, e` disponibile per il download qui: http://sourceforge.net/projects/ipfire-wall * Informazioni e pagina web ufficiale: http://www.giacomos.it/iqfire/index.html - - - - - - - - - - - - - - - - - - - - - - . '' `. : :': `. ` ' `- Debian GNU/Linux -- The power of freedom http://www.debian.org -- 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] Restructure video_device
Hi Hans, On Saturday 07 November 2009 13:36:33 Hans Verkuil wrote: On Friday 06 November 2009 11:23:59 Laurent Pinchart wrote: Hi Hans, On Thursday 05 November 2009 15:19:06 Hans Verkuil wrote: On Friday 23 October 2009 16:25:40 Laurent Pinchart wrote: Hi everybody, while working on device node support for subdevs I ran into an issue with the way v4l2 objects are structured. We currently have the following structure: - video_device represents a device that complies with the V4L1 or V4L2 API. Every video_device has a corresponding device node. - v4l2_device represents a high-level media device that handles sub-devices. With the new media controller infrastructure a v4l2_device will have a device node as well. - v4l2_subdev represents a sub-device. As for v4l2_device's, the new media controller infrastructure will give a device node for every sub-device. - v4l2_entity is the structure that both v4l2_subdev and video_device derive from. Most of the media controller code will deal with entities rather than sub-devices or video devices, as most operations (such as discovering the topology and create links) do not depend on the exact nature of the entity. New types of entities could be introduced later. Both the video_device and v4l2_subdev structure inherit from v4l2_entity, so both of them have a v4l2_entity field. With v4l2_device and v4l2_subdev now needing to devices to have device nodes created, the v4l2_device and v4l2_subdev structure both have a video_device field. This isn't clean for two reasons: - v4l2_device isn't a v4l2_entity, so it should inherit from a structure (video_device) that itself inherits from v4l2_entity. - v4l2_subdev shouldn't inherit twice from v4l2_entity, once directly and once through video_device. I agree. To fix this I would like to refactor the video_device structure and cut it in two pieces. One of them will deal with device node related tasks, being mostly V4L1/V4L2 agnostic, and the other will inherit from the first and add V4L1/V4L2 support (tvnorms/current_norm/ioctl_ops fields from the current video_device structure), as well as media controller support (inheriting from v4l2_entity). My plan was to create a video_devnode structure for the low-level device node Let's call it v4l2_devnode to be consistent with the current naming convention. Ok. related structure, and keeping the video_device name for the higher level structure. v4l2_device, v4l2_subdev and video_device would then all have a video_devnode field. While this isn't exactly difficult, it would require changing a lot of drivers, as some field will be moved from video_device to video_device::video_devnode. Some of those fields are internal, some of them are accessed by drivers while they shouldn't in most cases (the minor field for instance), and some are public (name, parent). I would like to have your opinion on whether you think this proposal is acceptable or whether you see a better and cleaner way to restructure the video device code structures. I have two issues with this: 1) Is it really necessary to do this now? We are still in the prototyping phase and I think it is probably more efficient right now to hack around this and postpone the real fix (as described above) until we are sure that the mc concept is working correctly. The media controller prototyping code is, as usual with prototyping codes, a bit messy. Splitting the device node management part from video_device into v4l2_devnode will make the media controller code easier to understand for outsiders (by outsider I mean every person who haven't been actively working on the code, so that includes pretty much everybody). I think it's worth it, especially given that I've already written the patches. They can live in the media controller tree of course, we don't have to apply them to mainline at the moment. Ah, it's only for the mc tree. I was getting the impression that you wanted to do this for the mainline tree as well. But if it is just for the mc tree, then go ahead. You can just do it in your own tree; as far as I am concerned your tree is leading for now. Ok. I just wanted to make sure there was no huge issue with the proposed change. I want to avoid writing code that I'll have to completely redesign later. 2) I'm not sure whether the final media controller will and should be part of the v4l framework at all. I think that this is something that can be used separately from the v4l subsystem. I think it should not be part of the v4l subsystem. ALSA will benefit from the media controller, and so might other subsystems such as GPU. A media_ prefix would be much nicer. I agree, but let's postpone such
Re: [PATCH 29/75] cx18: declare MODULE_FIRMWARE
On Sunday 08 November 2009 03:08:56 Andy Walls wrote: On Sun, 2009-11-08 at 01:53 +, Ben Hutchings wrote: On Sat, 2009-11-07 at 20:40 -0500, Andy Walls wrote: On Sat, 2009-11-07 at 21:51 +, Ben Hutchings wrote: +MODULE_FIRMWARE(dvb-cx18-mpc718-mt352.fw); + Ben, This particular firmware is only needed by one relatively rare TV card. Is there any way for MODULE_FIRMWARE advertisements to hint at mandatory vs. particular case(s)? No, but perhaps there ought to be. In this case the declaration could be left out for now. It is only critical to list all firmware in drivers that may be needed for booting. OK. I don't know that a TV card driver is every *needed* for booting. Maybe one day when I can net-boot with cable-modem like functionality... ;) I'm OK with the MODULE_FIRMWARE announcements in cx18 so long as automatic behaviors like 1. persistent, repeatitive, or truly alarming user warnings, or 2. refusing to load the module due to missing firmware files don't happen. I agree with Andy here. In the case of ivtv and cx18 (unless that changed since the last time I worked on it) the cx firmware is actually not loaded when the module is inited but on the first open() call. So it is not even that clear to me whether we want to have these fairly large fw files in an initramfs image at all. Regards, Hans Regards, Andy Ben. -- 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 -- 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: [PATCH] v4l2-dbg: report fail reason to the user
On Sunday 08 November 2009 13:32:50 Németh Márton wrote:
From: Márton Németh nm...@freemail.hu
Report the fail reason to the user when writing a register even if
the verbose mode is switched off.
Remove duplicated code ioctl() call which may cause different ioctl()
function call in case of verbose and non verbose if not handled carefully.
Signed-off-by: Márton Németh nm...@freemail.hu
---
diff -r 19c0469c02c3 v4l2-apps/util/v4l2-dbg.cpp
--- a/v4l2-apps/util/v4l2-dbg.cpp Sat Nov 07 15:51:01 2009 -0200
+++ b/v4l2-apps/util/v4l2-dbg.cpp Sun Nov 08 14:13:52 2009 +0100
@@ -354,13 +354,14 @@
{
int retVal;
- if (!options[OptVerbose]) return ioctl(fd, request, parm);
retVal = ioctl(fd, request, parm);
- printf(%s: , name);
- if (retVal 0)
- printf(failed: %s\n, strerror(errno));
- else
- printf(ok\n);
+ if (options[OptVerbose]) {
+ printf(%s: , name);
+ if (retVal 0)
+ printf(failed: %s\n, strerror(errno));
Strictly speaking if the printf two line back would produce an error, then
errno would now contain the errno from the printf and not from the ioctl.
So errno should be assigned to a local variable right after the ioctl.
Note that this was already a bug in the original code.
Note also that I fail to see any difference in the old vs the new code.
+ else
+ printf(ok\n);
+ }
return retVal;
}
@@ -586,8 +587,9 @@
printf( set to 0x%llx\n, set_reg.val);
} else {
- printf(Failed to set register 0x%08llx value
0x%llx\n,
- set_reg.reg, set_reg.val);
+ printf(Failed to set register 0x%08llx value
0x%llx:
+ %s\n,
Please keep this printf on one line. Yes, you get a checkpatch warning but
I'd rather have a slightly longer line than an ugly split line.
Regards,
Hans
+ set_reg.reg, set_reg.val,
strerror(errno));
}
set_reg.reg++;
}
--
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
--
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
[XC3028] Terretec Cinergy T XS wrong firmware xc3028-v27.fw
Hi all, I have a problem trying to user Terratec Cinergy T XS (usb dvb only adapter) with XC3028 tuner: v4l dvb driver installed in last kernel versions (actually I am using 2.6.31 from ubuntu 9.10) detects this device but then looks for the wrong firmware xc3028-v27.fw, and, moreover, seems to not contain correct device firmware at all. This makes the device to be detected but dvb device /dev/dvb is not created by the kernel. Is there a way to make this device to work with last kernel versions and last v4l-dvb driver versions? Thanks and regards in advance Valerio Bontempi -- 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] What is the status of the driver TT CT-3650
Hi, Anyone know how to get this working or this card is in a working state under linux. Because if it not working yet I will stop wasting my time Second that request. Is anybody working on a driver for this device? Is it worth waiting? Technotrend DVB products have been good for me in the past and this combination of DVB-C with CI is something well suited for my next vdr hardware setup. Thanks, Hanno -- 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 10/75] V4L/DVB: declare MODULE_FIRMWARE for modules using XC2028 and XC3028L tuners
Em Mon, 09 Nov 2009 03:02:49 +0100 hermann pitton hermann-pit...@arcor.de escreveu: Am Sonntag, den 08.11.2009, 22:43 -0200 schrieb Mauro Carvalho Chehab: Em Mon, 09 Nov 2009 00:32:29 +0100 hermann pitton hermann-pit...@arcor.de escreveu: I agree. An interesting case happens with devices that uses tda10046 DVB demods. They have the firmware stored internally on their eeprom. Those firmwares can be replaced by a different version loaded in ram, but, in general, they work properly with the eeprom one. So, even having the firmware load code there, the firmware at /lib/firmware is optional. Mauro, that could lead to some misunderstanding of the current use conditions, at least on saa7134. Minor annotations, the tda10046 does not store firmware internally, but there are cards which have an extra eeprom to store such firmware. If such a firmware eeprom is found and correctly configured, the driver in all cases will load the firmware from that eeprom and all other firmware in /lib/firmware is ignored. If not, the firmware will be loaded from /lib/firmware. For all what I know, firmware revisions 26 and 29 are both valid enough, correspondents to what we can load either from TechnoTrend or LifeView with the getfirmware script, and might be either stored in an extra eeprom or loaded from host/file. Prior revisions had issues with missing freqs, in what combination ever. We also can't totally exclude, given the whole mass of such, that in some cases firmware eeproms might exist on some boards, but are not correctly configured and load from host only because of that. The tendency seen overall is that competitors save the few cents for an extra firmware eeprom these days ... Yes, I know. I have myself a Cardbus device with such eeprom (I think it has revision 29 stored at the eeprom). The point is that it is not mandatory for such devices to have a firmware at the filesystem for the device to work. So, a static indication that devices with tda10046 need firmware is wrong, since some devices don't need it. There are of course lots of devices needing the firmware mandatory at the file system. I try to tell that it is not a mistake, in case the device has no firmware on an extra eeprom, to store latest revision in /lib/firmware. Or tell me better ... But also, OEMs a little bit more motivated on new hardware will not count the costs of an extra firmware eeprom, if being first in having substantial amounts of chips and get a good deal for such. But that was the past. Cheers, Mauro Else I do totally agree. I do just point to some ambiguous conditions we should stay aware of. It is very unlikely that we can talk them away. Do we have all firmware loaded from eeproms possibly existing on cards is only one minor question. Maybe we miss some. Should we not even better avoid such, since still no official update for firmware eeprom flashing? To restore the bridge eeprom we seem to be not such bad now, but also the reasons for a possible corruption are far from clearly identified in case we should be involved in it. Despite of legal issues, we should have the latest revision of the tda10046 firmware at the host. As said, those having it at an extra eeprom will load it anyway from there. Hermann, maybe you missed the point here: the driver will keep dynamically loading the modules at the right place, for the devices that really need firmwares to run. The issue I'm seeing is that the MODULE_FIRMWARE series of patches is adding an static meta-tag that indicates that the devices associated with a driver will need one or more firmwares, with the specified names at the tag. While it is not clear on Ben's proposal how those userspace tools will be, considering that he is concerning about initramfs and that there are devices (like for example rtl8192u) that needs several firmwares to run, in order to properly work for initramfs, the tools should assume that all firmwares using the tag will be needed for that device, to be sure that the machine won't hang during the boot. In the case of the v4l-dvb devices, the firmware needs are dynamic. For example, in the case of tuner-xc2028, you need _OR_ xc3028 _OR_ xc3028l firmwares (and, if considering tm6000 devices, you may need firmware version 1 for older devices). In the case of tda10046, some devices will need a firmware, while others won't need. So, you'll only know what firmware is really needed at runtime. An alternative for a static table would be to associate the firmware needs to the USB and PCI ID's, but even the USB/PCI ID tables will also have some troubles. For example, the flexcop driver supports 7 different versions of a device, all sharing the same PCI ID, but each version requires a different frontend. The driver only knows what frontend is needed at runtime, after
Re: [PATCH 29/75] cx18: declare MODULE_FIRMWARE
On Mon, 2009-11-09 at 11:06 +0100, Hans Verkuil wrote: On Sunday 08 November 2009 03:08:56 Andy Walls wrote: On Sun, 2009-11-08 at 01:53 +, Ben Hutchings wrote: On Sat, 2009-11-07 at 20:40 -0500, Andy Walls wrote: On Sat, 2009-11-07 at 21:51 +, Ben Hutchings wrote: +MODULE_FIRMWARE(dvb-cx18-mpc718-mt352.fw); + Ben, This particular firmware is only needed by one relatively rare TV card. Is there any way for MODULE_FIRMWARE advertisements to hint at mandatory vs. particular case(s)? No, but perhaps there ought to be. In this case the declaration could be left out for now. It is only critical to list all firmware in drivers that may be needed for booting. OK. I don't know that a TV card driver is every *needed* for booting. Maybe one day when I can net-boot with cable-modem like functionality... ;) I'm OK with the MODULE_FIRMWARE announcements in cx18 so long as automatic behaviors like 1. persistent, repeatitive, or truly alarming user warnings, or 2. refusing to load the module due to missing firmware files don't happen. I agree with Andy here. In the case of ivtv and cx18 (unless that changed since the last time I worked on it) the cx firmware is actually not loaded when the module is inited but on the first open() call. So it is not even that clear to me whether we want to have these fairly large fw files in an initramfs image at all. I've been thinking about this all a bit more since I read Mauro's comment. MODULE_FIRMWARE() is essentially turning kernel driver modules into an interactive, read-only, database for (a particular set of ?) end users. The process of keeping MODULE_FIRMWARE declarations up to date will run into all the incentive, governance, and maintenance problems that any database has. Due to lack incentive structure, one will end up with missing data at any point in time, as the current patch series points out. It may be better to keep tabs on module firmware image names with a database outside of the kernel *.[ch] files. It could be a simple as a text file somewhere. I suspect it would have just as likely a chance or better of being up to date at any point in time. That would also be a bit more flexible. One could add additional fields to the records for amplifying information (e.g required, optional, card xyz) without perturbing a slew of kernel *.[ch] files. My $0.02. Regards, Andy -- 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] What is the status of the driver TT CT-3650
Hanno,
I've been working on having the CT-3650 supported however I didn't go
very farther than having the dvb-c frontend to work. Nothing else
works : no CI, no DVB-T, no IR.
I've attached a patch which is working for me. Again, only the dvb-c
interface works. Also this patch should definitely not go upstream.
The cold firmware should not be used but it's there because I erased
the eeprom of my card by mistake.
I'm still planning to have a better support for this card but I
unfortunately have other things to work on before.
HTH,
Guy
On Mon, 09 Nov 2009 11:55:23 +0100
Hanno Zulla a...@hanno.de wrote:
Hi,
Anyone know how to get this working or this card is in a working
state under linux. Because if it not working yet I will stop
wasting my time
Second that request. Is anybody working on a driver for this device?
Is it worth waiting?
Technotrend DVB products have been good for me in the past and this
combination of DVB-C with CI is something well suited for my next vdr
hardware setup.
Thanks,
Hanno
diff -r 6f58a5d8c7c6 linux/drivers/media/dvb/dvb-usb/dvb-usb-ids.h
--- a/linux/drivers/media/dvb/dvb-usb/dvb-usb-ids.h Sat Aug 29 09:01:54 2009 -0300
+++ b/linux/drivers/media/dvb/dvb-usb/dvb-usb-ids.h Sat Nov 07 12:27:27 2009 +0100
@@ -61,7 +61,7 @@
#define USB_VID_HUMAX_COEX 0x10b9
/* Product IDs */
-#define USB_PID_ADSTECH_USB2_COLD 0xa333
+//#define USB_PID_ADSTECH_USB2_COLD 0xa333
#define USB_PID_ADSTECH_USB2_WARM 0xa334
#define USB_PID_AFATECH_AF90050x9020
#define USB_PID_AFATECH_AF9015_9015 0x9015
@@ -178,6 +178,7 @@
#define USB_PID_AVERMEDIA_A8500x850a
#define USB_PID_AVERMEDIA_A8050xa805
#define USB_PID_TECHNOTREND_CONNECT_S2400 0x3006
+#define USB_PID_TECHNOTREND_CONNECT_CT3650 0x300d
#define USB_PID_TERRATEC_CINERGY_DT_XS_DIVERSITY 0x005a
#define USB_PID_TERRATEC_CINERGY_DT_XS_DIVERSITY_2 0x0081
#define USB_PID_TERRATEC_CINERGY_HT_USB_XE 0x0058
diff -r 6f58a5d8c7c6 linux/drivers/media/dvb/dvb-usb/ttusb2.c
--- a/linux/drivers/media/dvb/dvb-usb/ttusb2.c Sat Aug 29 09:01:54 2009 -0300
+++ b/linux/drivers/media/dvb/dvb-usb/ttusb2.c Sat Nov 07 12:27:27 2009 +0100
@@ -29,6 +29,9 @@
#include tda826x.h
#include tda10086.h
+#include tda1002x.h
+#include tda827x.h
+#include tda10048.h
#include lnbp21.h
/* debug */
@@ -159,7 +162,34 @@
.xtal_freq = TDA10086_XTAL_16M,
};
-static int ttusb2_frontend_attach(struct dvb_usb_adapter *adap)
+static struct tda10023_config tda10023_config = {
+ .demod_address = 0x0c,
+ .invert = 0,
+ .xtal = 1600,
+ .pll_m = 11,
+ .pll_p = 3,
+ .pll_n = 1,
+ .deltaf = 0xa511,
+};
+
+static struct tda10048_config tda10048_config = {
+ .demod_address = 0x8,
+ .output_mode= TDA10048_SERIAL_OUTPUT,
+ .fwbulkwritelen = TDA10048_BULKWRITE_50,
+ .inversion = TDA10048_INVERSION_ON,
+ .dtv6_if_freq_khz = TDA10048_IF_3300,
+ .dtv7_if_freq_khz = TDA10048_IF_3800,
+ .dtv8_if_freq_khz = TDA10048_IF_4300,
+ .clk_freq_khz = TDA10048_CLK_16000,
+ .disable_gate_access = 1,
+};
+
+static struct tda827x_config tda827x_config = {
+ .config = 0,
+// .switch_addr = 0x4b,
+};
+
+static int ttusb2_frontend_tda10086_attach(struct dvb_usb_adapter *adap)
{
if (usb_set_interface(adap-dev-udev,0,3) 0)
err(set interface to alts=3 failed);
@@ -172,7 +202,40 @@
return 0;
}
-static int ttusb2_tuner_attach(struct dvb_usb_adapter *adap)
+static int ttusb2_frontend_tda10048_attach(struct dvb_usb_adapter *adap)
+{
+ if (usb_set_interface(adap-dev-udev,0,3) 0)
+ err(set interface to alts=3 failed);
+
+ if ((adap-fe = dvb_attach(tda10048_attach, tda10048_config, adap-dev-i2c_adap)) == NULL) {
+ deb_info(TDA10048 attach failed\n);
+ return -ENODEV;
+ }
+
+ return 0;
+}
+
+static int ttusb2_frontend_tda10023_attach(struct dvb_usb_adapter *adap)
+{
+ if (usb_set_interface(adap-dev-udev,0,3) 0)
+ err(set interface to alts=3 failed);
+ if ((adap-fe = dvb_attach(tda10023_attach, tda10023_config, adap-dev-i2c_adap, 0x48)) == NULL) {
+ deb_info(TDA10023 attach failed\n);
+ return -ENODEV;
+ }
+ return 0;
+}
+
+static int ttusb2_tuner_tda827x_attach(struct dvb_usb_adapter *adap) {
+
+ if (dvb_attach(tda827x_attach, adap-fe, 0x60, adap-dev-i2c_adap, tda827x_config) == NULL) {
+ printk(KERN_ERR %s: No tda827x found!\n, __func__);
+ return -ENODEV;
+ }
+ return 0;
+}
+
+static int ttusb2_tuner_tda826x_attach(struct dvb_usb_adapter *adap)
{
if (dvb_attach(tda826x_attach, adap-fe, 0x60, adap-dev-i2c_adap, 0) == NULL) {
deb_info(TDA8263 attach failed\n);
@@ -189,6 +252,7 @@
/* DVB USB Driver stuff */
static struct dvb_usb_device_properties ttusb2_properties;
static struct dvb_usb_device_properties ttusb2_properties_s2400;
+static struct dvb_usb_device_properties ttusb2_properties_ct3650;
static int ttusb2_probe(struct usb_interface *intf,
const struct usb_device_id *id)
@@ -196,6 +260,8 @@
if (0 == dvb_usb_device_init(intf, ttusb2_properties,
THIS_MODULE, NULL, adapter_nr) ||
Re: [PATCH 29/75] cx18: declare MODULE_FIRMWARE
Em Mon, 09 Nov 2009 07:03:02 -0500 Andy Walls awa...@radix.net escreveu: On Mon, 2009-11-09 at 11:06 +0100, Hans Verkuil wrote: On Sunday 08 November 2009 03:08:56 Andy Walls wrote: On Sun, 2009-11-08 at 01:53 +, Ben Hutchings wrote: On Sat, 2009-11-07 at 20:40 -0500, Andy Walls wrote: On Sat, 2009-11-07 at 21:51 +, Ben Hutchings wrote: +MODULE_FIRMWARE(dvb-cx18-mpc718-mt352.fw); + Ben, This particular firmware is only needed by one relatively rare TV card. Is there any way for MODULE_FIRMWARE advertisements to hint at mandatory vs. particular case(s)? No, but perhaps there ought to be. In this case the declaration could be left out for now. It is only critical to list all firmware in drivers that may be needed for booting. OK. I don't know that a TV card driver is every *needed* for booting. Maybe one day when I can net-boot with cable-modem like functionality... ;) I'm OK with the MODULE_FIRMWARE announcements in cx18 so long as automatic behaviors like 1. persistent, repeatitive, or truly alarming user warnings, or 2. refusing to load the module due to missing firmware files don't happen. I agree with Andy here. In the case of ivtv and cx18 (unless that changed since the last time I worked on it) the cx firmware is actually not loaded when the module is inited but on the first open() call. So it is not even that clear to me whether we want to have these fairly large fw files in an initramfs image at all. I've been thinking about this all a bit more since I read Mauro's comment. MODULE_FIRMWARE() is essentially turning kernel driver modules into an interactive, read-only, database for (a particular set of ?) end users. The process of keeping MODULE_FIRMWARE declarations up to date will run into all the incentive, governance, and maintenance problems that any database has. Due to lack incentive structure, one will end up with missing data at any point in time, as the current patch series points out. It may be better to keep tabs on module firmware image names with a database outside of the kernel *.[ch] files. It could be a simple as a text file somewhere. I suspect it would have just as likely a chance or better of being up to date at any point in time. That would also be a bit more flexible. One could add additional fields to the records for amplifying information (e.g required, optional, card xyz) without perturbing a slew of kernel *.[ch] files. Yes, this will work better, IMHO, but won't cover the few cases where you only know the frontend/tuner at the runtime, after probing the device or reading the device eeprom. If the need is to detect the firmware needs during installation, upgrades or hardware changes, the simplest way is to use an userspace tool for the request_firmware hotplug interface that catches the firmware requests after loading and opening a V4L/DVB device. This will catch all cases and will be a way easier than maintaining a database. 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: [PATCH 6/6] TVP514x:Switch to automode for s_input/querystd
Hi Vaibhav, See the review comments below. On Tuesday 13 October 2009 17:12:59 hvaib...@ti.com wrote: From: Vaibhav Hiremath hvaib...@ti.com Driver should switch to AutoSwitch mode on S_INPUT and QUERYSTD ioctls. It has been observed that, if user configure the standard explicitely then driver preserves the old settings. Reviewed by: Vaibhav Hiremath hvaib...@ti.com Signed-off-by: Brijesh Jadav brijes...@ti.com --- drivers/media/video/tvp514x.c | 17 + 1 files changed, 17 insertions(+), 0 deletions(-) diff --git a/drivers/media/video/tvp514x.c b/drivers/media/video/tvp514x.c index 2443726..0b0412d 100644 --- a/drivers/media/video/tvp514x.c +++ b/drivers/media/video/tvp514x.c @@ -523,10 +523,18 @@ static int tvp514x_querystd(struct v4l2_subdev *sd, v4l2_std_id *std_id) enum tvp514x_std current_std; enum tvp514x_input input_sel; u8 sync_lock_status, lock_mask; + int err; if (std_id == NULL) return -EINVAL; + err = tvp514x_write_reg(sd, REG_VIDEO_STD, + VIDEO_STD_AUTO_SWITCH_BIT); + if (err 0) + return err; + + msleep(LOCK_RETRY_DELAY); + We have a problem here with the V4L2 spec. The spec says that the standard should not change unless set explicitly by the user. So switching to auto mode in querystd is not correct. Is it possible to detect the standard without switching to automode? If it is, then that's the preferred solution. If it cannot be done, then we need to extend the API and add support for a proper way of enabling automode. This is actually a long standing issue that used to be pretty low prio since it is very rare to see 'spontaneous' switches from e.g. PAL to NTSC. But with the upcoming timings API for HDTV this will become much more common. (e.g. switching from 1080p to 720p). We need to define this quite carefully. In particular what will happen if the standard switches while streaming. How does that relate to a scaler setup with S_FMT? Do we know when this happens so that we can notify the application? Can we lock the standard when starting capturing? My gut feeling is that AUTO detect should only be allowed if the application can be notified when the standard changes, or if the standard can be locked when streaming starts. The second part that is needed is some way to set the receiver into auto switching mode. For SDTV that probably means adding a new AUTO standard bit. Although to be honest I'm not keen on having to add something to v4l2_std_id. For the HDTV timings API we probably need to add an AUTO preset. Murali, can you think about this a bit and see how that will work out? /* get the current standard */ current_std = tvp514x_get_current_std(sd); if (current_std == STD_INVALID) @@ -643,6 +651,15 @@ static int tvp514x_s_routing(struct v4l2_subdev *sd, /* Index out of bound */ return -EINVAL; + /* Since this api is goint to detect the input, it is required +to set the standard in the auto switch mode */ + err = tvp514x_write_reg(sd, REG_VIDEO_STD, + VIDEO_STD_AUTO_SWITCH_BIT); Huh? I don't see what s_routing has to do with auto switch mode. + if (err 0) + return err; + + msleep(LOCK_RETRY_DELAY); + input_sel = input; output_sel = output; -- 1.6.2.4 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
Re: v4l-dvb status
Hi Giacomo,
Em Mon, 9 Nov 2009 09:19:05 +0100
Giacomo dellece...@gmail.com escreveu:
good morning to all in the list.
I have a few questions, back trying to install v4l-dvb kernel drivers
after some time.
1. Is the project going to support kernel 2.6.31?
Huh? This project is for upstream kernel drivers. All drivers produced go to
kernel.
2. I used to use tvtime + sox for the usb audio, with big problems
causing audio
desynchronization with large delay with respect to the video: do
the (new) drivers
solve the issue?
- I also remember that there was an integrated version of
tvtime/usb audio in hg repositories,
is it still maintained? is there a particular version to download
to correctly build it?
tvtime stopped being maintained on 2005. You may find a few patches for it on
some places, but there are some issues on those patches.
Currently, you'll find a good support for V4L2 with mplayer. It generally
synchronizes audio and video well.
3. It's two years since I first installed v4l-dvb drivers, and still I
encounter problems to find all
the channels with tvtime.
Is there some module parameter to provide for the module em28xx for
Pinnacle PCTV USB2,
for the Italian standards?
You should be sure to select the proper video standard used in Italy. Maybe your
device tuner is different than the one configured at the driver. Different
tuners
generally have different cut-off frequencies between the 3 bands (low VHF, high
VHF,
UHF). If you are using a different tuner, you may not be able to see the
channels that
are close to the cut-off frequencies.
Currently, there are two variants of PCTV:
[EM2820_BOARD_PINNACLE_USB_2] = {
.name = Pinnacle PCTV USB 2,
.tuner_type = TUNER_LG_PAL_NEW_TAPC,
[EM2820_BOARD_PINNACLE_USB_2_FM1216ME] = {
.name = Pinnacle PCTV USB 2 (Philips FM1216ME),
.tuner_type = TUNER_PHILIPS_FM1216ME_MK3,
Each with a different tuner. The better way is to open your device and see
what's labeled at the metal can inside it, to be sure what variant are you
using.
You may also play with the tuner by passing a parameter to the kernel driver
specifying your
tuner model, based on the numbers at:
linux/Documentation/video4linux/CARDLIST.tuner
Thanks in advance for any hint and the great work done on v4l-dvb project
Giacomo
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
Terratec Cinergy Hybrid T USB XS FM and 2.6.31 : no more support ?
Hi,
Terratec Cinergy Hybrid T USB XS FM is fully supported by em28xx-new
project, but em28xx-new project is no more supported and not compatible with
kernel 2.6.31.
Is this hardware still supported ?
ID is 0ccd:0072 and hardware was mapped in em28xx-new like this :
[EM2883_BOARD_TERRATEC_HYBRID_
XS_FM] = {
.name = Terratec Hybrid XS FM (em2883),
.em_type = EM2883,
.vchannels = 3,
.norm = V4L2_STD_PAL_BG,
.has_radio = 1,
.has_inttuner = 1,
#if 0
.powersaving = 1,
#endif
.tuner_type = TUNER_XCEIVE_XC5000,
.decoder = EM28XX_CX25843,
.ir_keytab = ir_codes_em_terratec2,
.ir_getkey = em2880_get_key_terratec,
.dev_modes = EM28XX_VIDEO | EM28XX_VBI | EM28XX_DVBT |
EM28XX_AUDIO | EM28XX_RADIO,
.input = {{
.type = EM28XX_VMUX_TELEVISION,
.vmux = CX25843_TELEVISION,
.amux = 0,
}, {
.type = EM28XX_VMUX_COMPOSITE1,
.vmux = CX25843_COMPOSITE1,
.amux = 4,
}, {
.type = EM28XX_VMUX_SVIDEO,
.vmux = CX25843_SVIDEO,
.amux = 5,
} },
.tvnorms = EETI_XC5000_DEFAULT_ANALOG,
.dvbnorms = EETI_XC5000_DEFAULT_DVBT,
.fmnorms = EETI_XC5000_DEFAULT_FM,
},
--
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
saa7416 woes
Since the day my local transmitter 'upgraded' my budget DVB-T will no longer tune any station (tested with various apps, on various recent kernels), gut feeling is this may be a kernel driver issue. I know the transmission mode for all channels included changes from 2K, QAM16 to 8K, QAM64, and suspect this may be the reason (or one hell of a coincidence), can anyone offer any advice as what to do to obtain meaningful information to include in a bug report posting. PS. I tested the DVB-T card under WindowsXP and it (the hardware with the Windows software) works OK. I live in one of the first areas of the UK to 'upgrade'. lspci -v 02:09.0 Multimedia controller: Philips Semiconductors SAA7146 (rev 01) Subsystem: Technotrend Systemtechnik GmbH Technotrend-Budget/Hauppauge WinTV-NOVA-T DVB card Flags: bus master, medium devsel, latency 32, IRQ 17 Memory at e3001000 (32-bit, non-prefetchable) [size=512] Kernel driver in use: budget dvb Kernel modules: budget -- 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: Terratec Cinergy Hybrid T USB XS FM and 2.6.31 : no more support ?
On Mon, Nov 9, 2009 at 2:13 PM, Florent nouvellon flonouvel...@gmail.com wrote: Hi, Terratec Cinergy Hybrid T USB XS FM is fully supported by em28xx-new project, but em28xx-new project is no more supported and not compatible with kernel 2.6.31. Is this hardware still supported ? This device has never been supported in the mainline kernel. I don't foresee it getting implemented anytime soon since I don't have a board to debug/test with (and since this is the first instance where we would be doing xc5000 on em28xx, I wanted to have a unit I could debug personally). 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
[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:Mon Nov 9 19:00:03 CET 2009 path:http://www.linuxtv.org/hg/v4l-dvb changeset: 13327:19c0469c02c3 gcc version: gcc (GCC) 4.3.1 hardware:x86_64 host os: 2.6.26 linux-2.6.22.19-armv5: WARNINGS linux-2.6.23.12-armv5: WARNINGS linux-2.6.24.7-armv5: WARNINGS linux-2.6.25.11-armv5: WARNINGS linux-2.6.26-armv5: WARNINGS linux-2.6.27-armv5: WARNINGS linux-2.6.28-armv5: WARNINGS linux-2.6.29.1-armv5: WARNINGS linux-2.6.30-armv5: WARNINGS linux-2.6.31-armv5: WARNINGS linux-2.6.32-rc3-armv5: ERRORS linux-2.6.32-rc3-armv5-davinci: ERRORS 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-armv5-ixp: WARNINGS linux-2.6.31-armv5-ixp: WARNINGS linux-2.6.32-rc3-armv5-ixp: ERRORS linux-2.6.28-armv5-omap2: WARNINGS linux-2.6.29.1-armv5-omap2: WARNINGS linux-2.6.30-armv5-omap2: WARNINGS linux-2.6.31-armv5-omap2: ERRORS linux-2.6.32-rc3-armv5-omap2: OK linux-2.6.22.19-i686: WARNINGS linux-2.6.23.12-i686: WARNINGS linux-2.6.24.7-i686: WARNINGS linux-2.6.25.11-i686: WARNINGS 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-i686: WARNINGS linux-2.6.31-i686: WARNINGS linux-2.6.32-rc3-i686: WARNINGS linux-2.6.23.12-m32r: WARNINGS linux-2.6.24.7-m32r: WARNINGS linux-2.6.25.11-m32r: WARNINGS linux-2.6.26-m32r: WARNINGS linux-2.6.27-m32r: WARNINGS linux-2.6.28-m32r: WARNINGS linux-2.6.29.1-m32r: WARNINGS linux-2.6.30-m32r: WARNINGS linux-2.6.31-m32r: WARNINGS linux-2.6.32-rc3-m32r: OK linux-2.6.30-mips: WARNINGS linux-2.6.31-mips: WARNINGS linux-2.6.32-rc3-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-powerpc64: WARNINGS linux-2.6.31-powerpc64: WARNINGS linux-2.6.32-rc3-powerpc64: WARNINGS linux-2.6.22.19-x86_64: WARNINGS linux-2.6.23.12-x86_64: WARNINGS linux-2.6.24.7-x86_64: WARNINGS linux-2.6.25.11-x86_64: WARNINGS 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-x86_64: WARNINGS linux-2.6.31-x86_64: WARNINGS linux-2.6.32-rc3-x86_64: ERRORS sparse (linux-2.6.31): OK sparse (linux-2.6.32-rc3): OK linux-2.6.16.61-i686: ERRORS linux-2.6.17.14-i686: ERRORS linux-2.6.18.8-i686: WARNINGS linux-2.6.19.5-i686: WARNINGS linux-2.6.20.21-i686: WARNINGS linux-2.6.21.7-i686: WARNINGS linux-2.6.16.61-x86_64: ERRORS linux-2.6.17.14-x86_64: ERRORS linux-2.6.18.8-x86_64: WARNINGS linux-2.6.19.5-x86_64: WARNINGS linux-2.6.20.21-x86_64: WARNINGS linux-2.6.21.7-x86_64: WARNINGS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Monday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Monday.tar.bz2 The V4L2 specification failed to build, but the last compiled spec is here: http://www.xs4all.nl/~hverkuil/spec/v4l2.html The DVB API specification failed to build, but the last compiled spec 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: S_FMT @ sensor driver bridge driver
On Mon, 9 Nov 2009, Karicheri, Muralidharan wrote: -Original Message- From: Hans Verkuil [mailto:hverk...@xs4all.nl] Sent: Monday, November 09, 2009 10:16 AM To: Karicheri, Muralidharan Cc: linux-media@vger.kernel.org Subject: Re: S_FMT @ sensor driver bridge driver On Monday 09 November 2009 15:48:35 Karicheri, Muralidharan wrote: Hello, Currently the S_FMT IOCTL is used to configure the image resolution and (there by scaler settings) at the sensor (example MT9T031). Platforms like TI's DMxxx VPFE has Resizer in the pipeline that can be used as well by application to either zoom in a specific region of the capture image from the sensor or scale it up for some other reason. To do this we need to issue two S_FMT commands, 1st to set the capture frame resolution at the sensor and second to configure resize ration at the SOC Resizer. With the current API, I don't see a way this can be done. I wish we had some extra bytes in the S_FMT structure to add a flag that can indicate if S_FMT applies to the sensor or at the SOC (bridge). One way to implement this is to add a control to tell the bridge driver to send a specific IOCTL command to the sensor. Another use of such a command will be for control. For example if a specific control such as White balance is available at the SOC pipeline as well as at the sensor, then application can use the above control to direct that IOCTL command to the specific device. You might argue that Media controller will allow you to direct such commands directly to the target device. This is true for control example I have mentioned above. But when applying S_FMT at the sensor, we might want to passing it through the bridge driver (as is the case with VPFE) so that it can request extra lines to be captured as overhead to allow processing the frame at the SOC pipeline in real time. So I do see this control command staying even after we have media controller. Let me know if you disagree with this proposal or have alternative to implement the same. If I don't hear anything against this approach, I would like to send patch to implement this control for vpfe capture driver. I don't think this is a good idea. This is something that is highly hw dependent and as such should be done as part of the hw-specific subdev API that we will get in the future. The S_FMT ioctl is really a best-effort when it comes to SoCs. I.e. the S_FMT driver implementation should just try to do the best setup it can do (within reason). I wonder if we shouldn't start implementing the code needed to get subdev device nodes: if we have those, then it becomes much easier to start implementing hw-specific features. We don't need the media controller for that initially. It is hardware dependent. I strongly feel we need to have device node for sub device so that we can make changes to existing drivers like to ccdc to remove the experimental ioctl and add the same to the sub device driver. Assuming we have a device node, do you think we could add the extra line requirement that I had mentioned to the platform data of the sub device? So application does the following to start streaming in the sensor 1) Issue S_FMT to the sensor (mt9t031 for example) (set resolution to 1280x720), sub device driver adds extra lines if needed for a specific platform) 2) Issue a S_FMT to the video node. At this point, bridge driver issue g_fmt() to the sensor sub device to get current image size, frame format, pixel format etc. Set the resizer resize ration based on the sensor input image size and required final image size at the video node. You might want to have a look at http://www.spinics.net/lists/linux-media/msg11926.html and at the inplementation in drivers/media/video/sh_mobile_ceu_camera.c. In short - without configuring the client and the host separately we try to configure the client as good as possible to optimise for bus-usage, and then adjust for user-request on the host. BTW, it might be a good idea to implement this algorithm generically for all host drivers. If this is fine, then what it takes to add device node to a sub device? I know that Laurent is already working on the Media controller and adding video node to sub device is one of the development items. Probably a patch to add video node to sub device can then be pushed first so that drivers can leverage on this framework to implement hardware dependent features. Otherwise, we need something on the interim to implement the above feature in vpfe capture. 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
[patch] radio-mr800 - autosuspend for radio-mr800 driver
From: Oliver Neukum oli...@neukum.org
Patch adds autosuspend support for mr800 radio driver.
Priority: normal
Signed-off-by: Oliver Neukum oli...@neukum.org
Acked-by: Alexey Klimov klimov.li...@gmail.com
--
diff -r 19c0469c02c3 linux/drivers/media/radio/radio-mr800.c
--- a/linux/drivers/media/radio/radio-mr800.c Sat Nov 07 15:51:01 2009 -0200
+++ b/linux/drivers/media/radio/radio-mr800.c Tue Nov 10 00:38:19 2009 +0300
@@ -133,6 +133,7 @@
struct amradio_device {
/* reference to USB and video device */
struct usb_device *usbdev;
+ struct usb_interface *intf;
struct video_device videodev;
struct v4l2_device v4l2_dev;
@@ -166,7 +167,7 @@
.reset_resume = usb_amradio_resume,
#endif
.id_table = usb_amradio_device_table,
- .supports_autosuspend = 0,
+ .supports_autosuspend = 1,
};
/* switch on/off the radio. Send 8 bytes to device */
@@ -509,9 +510,15 @@
}
file-private_data = radio;
+ retval = usb_autopm_get_interface(radio-intf);
+ if (retval)
+ goto unlock;
- if (unlikely(!radio-initialized))
+ if (unlikely(!radio-initialized)) {
retval = usb_amradio_init(radio);
+ if (retval)
+ usb_autopm_put_interface(radio-intf);
+ }
unlock:
mutex_unlock(radio-lock);
@@ -528,6 +535,8 @@
if (!radio-usbdev)
retval = -EIO;
+ else
+ usb_autopm_put_interface(radio-intf);
mutex_unlock(radio-lock);
return retval;
@@ -669,6 +678,7 @@
radio-videodev.release = usb_amradio_video_device_release;
radio-usbdev = interface_to_usbdev(intf);
+ radio-intf = intf;
radio-curfreq = 95.16 * FREQ_MUL;
mutex_init(radio-lock);
--
Alexey Klimov
--
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
Problems with Terratec Hybrid USB XS
Hello, i get this message while connecting my terratec Hybrid USB XS to Ubuntu 9.10 [7.561527] usb 1-8: new high speed USB device using ehci_hcd and address 5 [7.712973] usb 1-8: configuration #1 chosen from 1 choice [7.906708] em28xx: New device TerraTec Electronic GmbH Cinergy Hybrid T USB XS (2882) @ 480 Mbps (0ccd:005e, interface 0, class 0) [7.906904] em28xx #0: chip ID is em2882/em2883 [7.968084] usb 2-1: new low speed USB device using uhci_hcd and address 2 [8.158102] usb 2-1: configuration #1 chosen from 1 choice [8.278805] em28xx #0: i2c eeprom 00: 1a eb 67 95 cd 0c 5e 00 d0 12 5c 03 9e 40 de 1c [8.278841] em28xx #0: i2c eeprom 10: 6a 34 27 57 46 07 01 00 00 00 00 00 00 00 00 00 [8.278875] em28xx #0: i2c eeprom 20: 46 00 01 00 f0 10 31 00 b8 00 14 00 5b 1e 00 00 [8.278906] em28xx #0: i2c eeprom 30: 00 00 20 40 20 6e 02 20 10 01 00 00 00 00 00 00 [8.278941] em28xx #0: i2c eeprom 40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [8.278973] em28xx #0: i2c eeprom 50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [8.279003] em28xx #0: i2c eeprom 60: 00 00 00 00 00 00 00 00 00 00 34 03 54 00 65 00 [8.279036] em28xx #0: i2c eeprom 70: 72 00 72 00 61 00 54 00 65 00 63 00 20 00 45 00 [8.279070] em28xx #0: i2c eeprom 80: 6c 00 65 00 63 00 74 00 72 00 6f 00 6e 00 69 00 [8.279103] em28xx #0: i2c eeprom 90: 63 00 20 00 47 00 6d 00 62 00 48 00 00 00 40 03 [8.279135] em28xx #0: i2c eeprom a0: 43 00 69 00 6e 00 65 00 72 00 67 00 79 00 20 00 [8.279164] em28xx #0: i2c eeprom b0: 48 00 79 00 62 00 72 00 69 00 64 00 20 00 54 00 [8.279193] em28xx #0: i2c eeprom c0: 20 00 55 00 53 00 42 00 20 00 58 00 53 00 20 00 [8.279224] em28xx #0: i2c eeprom d0: 28 00 32 00 38 00 38 00 32 00 29 00 00 00 1c 03 [8.279256] em28xx #0: i2c eeprom e0: 30 00 36 00 31 00 32 00 30 00 32 00 30 00 30 00 [8.279288] em28xx #0: i2c eeprom f0: 34 00 38 00 32 00 34 00 00 00 00 00 00 00 00 00 [8.279324] em28xx #0: EEPROM ID= 0x9567eb1a, EEPROM hash = 0x6513b2be [8.279331] em28xx #0: EEPROM info: [8.279337] em28xx #0: AC97 audio (5 sample rates) [8.279343] em28xx #0: 500mA max power [8.279351] em28xx #0: Table at 0x27, strings=0x409e, 0x1cde, 0x346a [8.293136] em28xx #0: Identified as Terratec Hybrid XS (em2882) (card=55) [8.293147] em28xx #0: [8.293150] [8.293158] em28xx #0: The support for this board weren't valid yet. [8.293166] em28xx #0: Please send a report of having this working [8.293174] em28xx #0: not to V4L mailing list (and/or to other addresses) [8.293178] [8.367181] tvp5150 2-005c: chip found @ 0xb8 (em28xx #0) [8.409317] tuner 2-0061: chip found @ 0xc2 (em28xx #0) [8.548712] xc2028 2-0061: creating new instance [8.548721] xc2028 2-0061: type set to XCeive xc2028/xc3028 tuner [8.548739] usb 1-8: firmware: requesting xc3028-v27.fw [8.593615] usbcore: registered new interface driver hiddev [8.606545] input: USB Optical Mouse as /devices/pci:00/:00:1d.0/usb2/2-1/2-1:1.0/input/input9 [8.606842] generic-usb 0003:0461:4D17.0001: input,hidraw0: USB HID v1.11 Mouse [USB Optical Mouse] on usb-:00:1d.0-1/input0 [8.606899] usbcore: registered new interface driver usbhid [8.606911] usbhid: v2.6:USB HID core driver [8.613601] xc2028 2-0061: Loading 80 firmware images from xc3028-v27.fw, type: xc2028 firmware, ver 2.7 [8.665571] xc2028 2-0061: Loading firmware for type=BASE (1), id . [ 10.631931] xc2028 2-0061: Loading firmware for type=(0), id b700. [ 10.648764] SCODE (2000), id b700: [ 10.648787] xc2028 2-0061: Loading SCODE for type=MONO SCODE HAS_IF_4320 (60008000), id 8000. [ 10.833110] em28xx #0: Config register raw data: 0xd0 [ 10.833848] em28xx #0: AC97 vendor ID = 0x [ 10.834801] em28xx #0: AC97 features = 0x6a90 [ 10.834810] em28xx #0: Empia 202 AC97 audio processor detected [ 10.972632] tvp5150 2-005c: tvp5150am1 detected. [ 11.095362] em28xx #0: v4l2 driver version 0.1.2 [ 11.227453] em28xx #0: V4L2 device registered as /dev/video1 and /dev/vbi0 [ 11.246162] usbcore: registered new interface driver em28xx [ 11.246175] em28xx driver loaded [ 11.268371] em28xx-audio.c: probing for em28x1 non standard usbaudio [ 11.268383] em28xx-audio.c: Copyright (C) 2006 Markus Rechberger [ 11.271206] Em28xx: Initialized (Em28xx Audio Extension) extension [ 11.482349] tvp5150 2-005c: tvp5150am1 detected. [ 12.173607] tvp5150 2-005c: tvp5150am1 detected. can you please help me to get this stick running? -- 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
ov538-ov7690
Hi all I'm working on the ov538 bridge with the ov7690 camera connected. Somentimes I receive [ 1268.146705] gspca: ISOC data error: [110] len=1020, status=-71 [ 1270.946739] gspca: ISOC data error: [114] len=1020, status=-71 [ 1271.426689] gspca: ISOC data error: [82] len=1020, status=-71 [ 1273.314640] gspca: ISOC data error: [1] len=1020, status=-71 [ 1274.114661] gspca: ISOC data error: [17] len=1020, status=-71 [ 1274.658718] gspca: ISOC data error: [125] len=1020, status=-71 [ 1274.834666] gspca: ISOC data error: [21] len=1020, status=-71 [ 1275.84] gspca: ISOC data error: [94] len=1020, status=-71 [ 1275.826645] gspca: ISOC data error: [40] len=1020, status=-71 [ 1276.226721] gspca: ISOC data error: [100] len=1020, status=-71 This error from the usb, how are they related to the camera? Michael -- 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] Dual tuner DVB-T card on Linux
any card would do it. I'm using a program called getstream. It demultiplexes a stream so you can record it with a program like mencoder. regards --- On Fri, 11/6/09, shacky shack...@gmail.com wrote: From: shacky shack...@gmail.com Subject: [linux-dvb] Dual tuner DVB-T card on Linux To: linux-...@linuxtv.org Date: Friday, November 6, 2009, 4:52 PM Hi. Could you help me to find any DVB-T dual input/tuner card that work with Linux without problems? I need to record two programs in the same time with MythTV.. Thank you very much! Bye. ___ 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 -- 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: [XC3028] Terretec Cinergy T XS wrong firmware xc3028-v27.fw
Em Mon, 9 Nov 2009 12:13:22 +0100 Valerio Bontempi valerio.bonte...@gmail.com escreveu: Hi all, I have a problem trying to user Terratec Cinergy T XS (usb dvb only adapter) with XC3028 tuner: v4l dvb driver installed in last kernel versions (actually I am using 2.6.31 from ubuntu 9.10) detects this device but then looks for the wrong firmware xc3028-v27.fw, and, moreover, seems to not contain correct device firmware at all. This makes the device to be detected but dvb device /dev/dvb is not created by the kernel. Is there a way to make this device to work with last kernel versions and last v4l-dvb driver versions? Earlier versions of Ubuntu used to contain an out-of-tree driver for xc3028, that used a different firmware format. Due to license issues, distros can't package the firmware files (since the vendor didn't give any redistribution rights for the firmwares up to now). So, you'll need to download a driver with the firmware inside and run a script to create the firmware. For more info and instructions on how to get the firmware, please see: http://www.linuxtv.org/wiki/index.php/Xceive_XC3028/XC2028#How_to_Obtain_the_Firmware Cheers, Mauro Mauro, Although the xc3028-v27.fw generated from HVR-12x0-14x0-17x0_1_25_25271_WHQL.zip using the above process works fine for me, the firmware is a couple of years old now and I can't help wondering if there might be a newer version in the latest Windows drivers out there containing performance or stability fixes it in. Do you think it would be worthwhile extracting a newer version of firmware? -Rob -- 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 10/75] V4L/DVB: declare MODULE_FIRMWARE for modules using XC2028 and XC3028L tuners
Hi, Am Montag, den 09.11.2009, 09:37 -0200 schrieb Mauro Carvalho Chehab: Em Mon, 09 Nov 2009 03:02:49 +0100 hermann pitton hermann-pit...@arcor.de escreveu: Am Sonntag, den 08.11.2009, 22:43 -0200 schrieb Mauro Carvalho Chehab: Em Mon, 09 Nov 2009 00:32:29 +0100 hermann pitton hermann-pit...@arcor.de escreveu: I agree. An interesting case happens with devices that uses tda10046 DVB demods. They have the firmware stored internally on their eeprom. Those firmwares can be replaced by a different version loaded in ram, but, in general, they work properly with the eeprom one. So, even having the firmware load code there, the firmware at /lib/firmware is optional. Mauro, that could lead to some misunderstanding of the current use conditions, at least on saa7134. Minor annotations, the tda10046 does not store firmware internally, but there are cards which have an extra eeprom to store such firmware. If such a firmware eeprom is found and correctly configured, the driver in all cases will load the firmware from that eeprom and all other firmware in /lib/firmware is ignored. If not, the firmware will be loaded from /lib/firmware. For all what I know, firmware revisions 26 and 29 are both valid enough, correspondents to what we can load either from TechnoTrend or LifeView with the getfirmware script, and might be either stored in an extra eeprom or loaded from host/file. Prior revisions had issues with missing freqs, in what combination ever. We also can't totally exclude, given the whole mass of such, that in some cases firmware eeproms might exist on some boards, but are not correctly configured and load from host only because of that. The tendency seen overall is that competitors save the few cents for an extra firmware eeprom these days ... Yes, I know. I have myself a Cardbus device with such eeprom (I think it has revision 29 stored at the eeprom). The point is that it is not mandatory for such devices to have a firmware at the filesystem for the device to work. So, a static indication that devices with tda10046 need firmware is wrong, since some devices don't need it. There are of course lots of devices needing the firmware mandatory at the file system. I try to tell that it is not a mistake, in case the device has no firmware on an extra eeprom, to store latest revision in /lib/firmware. Or tell me better ... But also, OEMs a little bit more motivated on new hardware will not count the costs of an extra firmware eeprom, if being first in having substantial amounts of chips and get a good deal for such. But that was the past. Cheers, Mauro Else I do totally agree. I do just point to some ambiguous conditions we should stay aware of. It is very unlikely that we can talk them away. Do we have all firmware loaded from eeproms possibly existing on cards is only one minor question. Maybe we miss some. Should we not even better avoid such, since still no official update for firmware eeprom flashing? To restore the bridge eeprom we seem to be not such bad now, but also the reasons for a possible corruption are far from clearly identified in case we should be involved in it. Despite of legal issues, we should have the latest revision of the tda10046 firmware at the host. As said, those having it at an extra eeprom will load it anyway from there. Hermann, maybe you missed the point here: the driver will keep dynamically loading the modules at the right place, for the devices that really need firmwares to run. The issue I'm seeing is that the MODULE_FIRMWARE series of patches is adding an static meta-tag that indicates that the devices associated with a driver will need one or more firmwares, with the specified names at the tag. While it is not clear on Ben's proposal how those userspace tools will be, considering that he is concerning about initramfs and that there are devices (like for example rtl8192u) that needs several firmwares to run, in order to properly work for initramfs, the tools should assume that all firmwares using the tag will be needed for that device, to be sure that the machine won't hang during the boot. In the case of the v4l-dvb devices, the firmware needs are dynamic. For example, in the case of tuner-xc2028, you need _OR_ xc3028 _OR_ xc3028l firmwares (and, if considering tm6000 devices, you may need firmware version 1 for older devices). In the case of tda10046, some devices will need a firmware, while others won't need. So, you'll only know what firmware is really needed at runtime. An alternative for a static table would be to associate the firmware needs to the USB and PCI ID's, but even the USB/PCI ID tables will also have some troubles. For example, the
Re: [XC3028] Terretec Cinergy T XS wrong firmware xc3028-v27.fw
On Mon, Nov 9, 2009 at 6:41 PM, Robert Lowery rglow...@exemail.com.au wrote: Although the xc3028-v27.fw generated from HVR-12x0-14x0-17x0_1_25_25271_WHQL.zip using the above process works fine for me, the firmware is a couple of years old now and I can't help wondering if there might be a newer version in the latest Windows drivers out there containing performance or stability fixes it in. Do you think it would be worthwhile extracting a newer version of firmware? That is the latest version of the firmware for that chip. Xceive has not updated it since then, given that they are focusing on newer products like the xc5000 and xc3028L. Your problem has nothing to do with the firmware. The issue is the driver support for your particular device was only added recently (after Ubuntu did their kernel freeze for Karmic). The work associated with adding support for devices is nontrivial, and I typically only do it when people report that their device needs support. 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: [XC3028] Terretec Cinergy T XS wrong firmware xc3028-v27.fw
On Mon, Nov 9, 2009 at 6:41 PM, Robert Lowery rglow...@exemail.com.au wrote: Although the xc3028-v27.fw generated from HVR-12x0-14x0-17x0_1_25_25271_WHQL.zip using the above process works fine for me, the firmware is a couple of years old now and I can't help wondering if there might be a newer version in the latest Windows drivers out there containing performance or stability fixes it in. Do you think it would be worthwhile extracting a newer version of firmware? That is the latest version of the firmware for that chip. Xceive has not updated it since then, given that they are focusing on newer products like the xc5000 and xc3028L. Your problem has nothing to do with the firmware. The issue is the driver support for your particular device was only added recently (after Ubuntu did their kernel freeze for Karmic). The work associated with adding support for devices is nontrivial, and I typically only do it when people report that their device needs support. Devin Sorry Devin, I shoudn't have hijacked this thread. My question was general in nature and not related to the issues being discussed in this thread. If v2.7 is the latest firmware released by Xceive for the xc3028 then that answers my question Thanks -Rob -- 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 10/75] V4L/DVB: declare MODULE_FIRMWARE for modules using XC2028 and XC3028L tuners
[snip] If there are no known issues with latest, we should ask Philips/NXP if we are allowed to distribute it with the kernel. To make it more clear. OEMs did modify the eeprom content of their devices not following the Philips rules anymore and causing troubles. I would like to know, if this can happen for firmware too. I really hope it never came to this point. Cheers, Hermann -- 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/RFC] tmio_mmc: keep card-detect interrupts enabled
Well if they are only masked they shouldnt stop being asserted. But we should unmask them again. Im not really sure we should mask them anyway, with the card possibly being gone... Will need to look into it further. 2009/11/9 Guennadi Liakhovetski g.liakhovet...@gmx.de: (re-adding accidentally dropped ML) On Mon, 9 Nov 2009, Ian Molton wrote: Well, I presume we want to know when the card gets removed :) Sure, that's why we shouldn't mask those interrupts:-) If they do get masked and missed, I do not know, if the interrupt remains pending in this case, because they never get detected then:) 2009/11/9 Guennadi Liakhovetski g.liakhovet...@gmx.de: Hi Ian Why did you drop all CCs? On Mon, 9 Nov 2009, Ian Molton wrote: I havent looked at the consequences for the driver if a insert IRQ occurs during IO, however it seems logical that we should not permanently mask the IRQ. I presume that the IRQ remains pending? Don't know, never checked. Is this important to know? Thanks Guennadi 2009/11/6 Guennadi Liakhovetski g.liakhovet...@gmx.de: On SuperH platforms the SDHI controller does not produce any command IRQs after a completed IO. This leads to card-detect interrupts staying disabled. Do not disable card-detect interrupts on DATA IRQs. Signed-off-by: Guennadi Liakhovetski g.liakhovet...@gmx.de --- Marked as RFC because I'm not really sure this is a correct approach to fix this problem, and whether this will have negative effect on other tmio_mmc MFD users. diff --git a/drivers/mmc/host/tmio_mmc.h b/drivers/mmc/host/tmio_mmc.h index c676767..0b31d44 100644 --- a/drivers/mmc/host/tmio_mmc.h +++ b/drivers/mmc/host/tmio_mmc.h @@ -55,10 +55,8 @@ /* Define some IRQ masks */ /* This is the mask used at reset by the chip */ #define TMIO_MASK_ALL 0x837f031d -#define TMIO_MASK_READOP (TMIO_STAT_RXRDY | TMIO_STAT_DATAEND | \ - TMIO_STAT_CARD_REMOVE | TMIO_STAT_CARD_INSERT) -#define TMIO_MASK_WRITEOP (TMIO_STAT_TXRQ | TMIO_STAT_DATAEND | \ - TMIO_STAT_CARD_REMOVE | TMIO_STAT_CARD_INSERT) +#define TMIO_MASK_READOP (TMIO_STAT_RXRDY | TMIO_STAT_DATAEND) +#define TMIO_MASK_WRITEOP (TMIO_STAT_TXRQ | TMIO_STAT_DATAEND) #define TMIO_MASK_CMD (TMIO_STAT_CMDRESPEND | TMIO_STAT_CMDTIMEOUT | \ TMIO_STAT_CARD_REMOVE | TMIO_STAT_CARD_INSERT) #define TMIO_MASK_IRQ (TMIO_MASK_READOP | TMIO_MASK_WRITEOP | TMIO_MASK_CMD) Thanks Guennadi --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/ -- Ian Molton Linux, Automotive, and other hacking: http://www.mnementh.co.uk/ -- 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] v4l2-dbg: report fail reason to the user
Hans Verkuil wrote:
On Sunday 08 November 2009 13:32:50 Németh Márton wrote:
From: Márton Németh nm...@freemail.hu
Report the fail reason to the user when writing a register even if
the verbose mode is switched off.
Remove duplicated code ioctl() call which may cause different ioctl()
function call in case of verbose and non verbose if not handled carefully.
Signed-off-by: Márton Németh nm...@freemail.hu
---
diff -r 19c0469c02c3 v4l2-apps/util/v4l2-dbg.cpp
--- a/v4l2-apps/util/v4l2-dbg.cppSat Nov 07 15:51:01 2009 -0200
+++ b/v4l2-apps/util/v4l2-dbg.cppSun Nov 08 14:13:52 2009 +0100
@@ -354,13 +354,14 @@
{
int retVal;
-if (!options[OptVerbose]) return ioctl(fd, request, parm);
retVal = ioctl(fd, request, parm);
-printf(%s: , name);
-if (retVal 0)
-printf(failed: %s\n, strerror(errno));
-else
-printf(ok\n);
+if (options[OptVerbose]) {
+printf(%s: , name);
+if (retVal 0)
+printf(failed: %s\n, strerror(errno));
Strictly speaking if the printf two line back would produce an error, then
errno would now contain the errno from the printf and not from the ioctl.
So errno should be assigned to a local variable right after the ioctl.
Note that this was already a bug in the original code.
You are right, this problem was not solved by the new code.
Note also that I fail to see any difference in the old vs the new code.
In this function I only tried to modify the programming style: only one call to
ioctl(). In the original code the ioctl() call was duplicated which which
results a not-so-well maintainable code: if ever is needed to modify the
parameters
of the ioctl() then in the original code two lines would be needed to modify.
The
lines are to be modified exactly the same way in that case which may result
different
behaviour in case of verbose switched on or off.
+else
+printf(ok\n);
+}
return retVal;
}
@@ -586,8 +587,9 @@
printf( set to 0x%llx\n, set_reg.val);
} else {
-printf(Failed to set register 0x%08llx value
0x%llx\n,
-set_reg.reg, set_reg.val);
+printf(Failed to set register 0x%08llx value
0x%llx:
+%s\n,
Please keep this printf on one line. Yes, you get a checkpatch warning but
I'd rather have a slightly longer line than an ugly split line.
Regards,
Hans
+set_reg.reg, set_reg.val,
strerror(errno));
}
set_reg.reg++;
}
--
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] Add new TV cards of Beholder
Hi All
Add new TV cards of Beholder for autodetect.
diff -r 3919b17dc88e linux/drivers/staging/tm6000/tm6000-cards.c
--- a/linux/drivers/staging/tm6000/tm6000-cards.c Wed Oct 14 12:52:55
2009 -0300
+++ b/linux/drivers/staging/tm6000/tm6000-cards.c Tue Nov 10 08:05:15
2009 +0900
@@ -33,6 +33,7 @@
#include tm6000.h
#include tm6000-regs.h
#include tuner-xc2028.h
+#include tuner-xc5000.h
#define TM6000_BOARD_UNKNOWN 0
#define TM5600_BOARD_GENERIC 1
@@ -193,6 +194,36 @@
},
.gpio_addr_tun_reset = TM6000_GPIO_2,
},
+ [TM6010_BOARD_BEHOLD_WANDER] = {
+ .name = Beholder Wander DVB-T/TV/FM USB2.0,
+ .tuner_type = TUNER_XC5000,
+ .tuner_addr = 0xc2 1,
+ .demod_addr = 0x1e 1,
+ .type = TM6010,
+ .caps = {
+ .has_tuner= 1,
+ .has_dvb = 1,
+ .has_zl10353 = 1,
+ .has_eeprom = 1,
+ .has_remote = 1,
+ },
+ .gpio_addr_tun_reset = TM6000_GPIO_2,
+ },
+ [TM6010_BOARD_BEHOLD_VOYAGER] = {
+ .name = Beholder Voyager TV/FM USB2.0,
+ .tuner_type = TUNER_XC5000,
+ .tuner_addr = 0xc2 1,
+ .type = TM6010,
+ .caps = {
+ .has_tuner= 1,
+ .has_dvb = 0,
+ .has_zl10353 = 0,
+ .has_eeprom = 1,
+ .has_remote = 1,
+ },
+ .gpio_addr_tun_reset = TM6000_GPIO_2,
+ },
+
};
/* table of devices that work with this driver */
@@ -203,6 +234,8 @@
{ USB_DEVICE(0x14aa, 0x0620), .driver_info =
TM6000_BOARD_FREECOM_AND_SIMILAR },
{ USB_DEVICE(0x06e1, 0xb339), .driver_info =
TM6000_BOARD_ADSTECH_MINI_DUAL_TV },
{ USB_DEVICE(0x2040, 0x6600), .driver_info =
TM6010_BOARD_HAUPPAUGE_900H },
+ { USB_DEVICE(0x6000, 0xdec0), .driver_info = TM6010_BOARD_BEHOLD_WANDER
},
+ { USB_DEVICE(0x6000, 0xdec1), .driver_info =
TM6010_BOARD_BEHOLD_VOYAGER },
{ },
};
Signed-off-by: Beholder Intl. Ltd. Dmitry Belimov d.beli...@gmail.com
With my best regards, Dmitry.
diff -r 3919b17dc88e linux/drivers/staging/tm6000/tm6000-cards.c
--- a/linux/drivers/staging/tm6000/tm6000-cards.c Wed Oct 14 12:52:55 2009 -0300
+++ b/linux/drivers/staging/tm6000/tm6000-cards.c Tue Nov 10 08:05:15 2009 +0900
@@ -33,6 +33,7 @@
#include tm6000.h
#include tm6000-regs.h
#include tuner-xc2028.h
+#include tuner-xc5000.h
#define TM6000_BOARD_UNKNOWN 0
#define TM5600_BOARD_GENERIC 1
@@ -193,6 +194,36 @@
},
.gpio_addr_tun_reset = TM6000_GPIO_2,
},
+ [TM6010_BOARD_BEHOLD_WANDER] = {
+ .name = Beholder Wander DVB-T/TV/FM USB2.0,
+ .tuner_type = TUNER_XC5000,
+ .tuner_addr = 0xc2 1,
+ .demod_addr = 0x1e 1,
+ .type = TM6010,
+ .caps = {
+ .has_tuner= 1,
+ .has_dvb = 1,
+ .has_zl10353 = 1,
+ .has_eeprom = 1,
+ .has_remote = 1,
+ },
+ .gpio_addr_tun_reset = TM6000_GPIO_2,
+ },
+ [TM6010_BOARD_BEHOLD_VOYAGER] = {
+ .name = Beholder Voyager TV/FM USB2.0,
+ .tuner_type = TUNER_XC5000,
+ .tuner_addr = 0xc2 1,
+ .type = TM6010,
+ .caps = {
+ .has_tuner= 1,
+ .has_dvb = 0,
+ .has_zl10353 = 0,
+ .has_eeprom = 1,
+ .has_remote = 1,
+ },
+ .gpio_addr_tun_reset = TM6000_GPIO_2,
+ },
+
};
/* table of devices that work with this driver */
@@ -203,6 +234,8 @@
{ USB_DEVICE(0x14aa, 0x0620), .driver_info = TM6000_BOARD_FREECOM_AND_SIMILAR },
{ USB_DEVICE(0x06e1, 0xb339), .driver_info = TM6000_BOARD_ADSTECH_MINI_DUAL_TV },
{ USB_DEVICE(0x2040, 0x6600), .driver_info = TM6010_BOARD_HAUPPAUGE_900H },
+ { USB_DEVICE(0x6000, 0xdec0), .driver_info = TM6010_BOARD_BEHOLD_WANDER },
+ { USB_DEVICE(0x6000, 0xdec1), .driver_info = TM6010_BOARD_BEHOLD_VOYAGER },
{ },
};
Signed-off-by: Beholder Intl. Ltd. Dmitry Belimov d.beli...@gmail.com
RE: [PATCH 6/6] TVP514x:Switch to automode for s_input/querystd
-Original Message- From: Hans Verkuil [mailto:hverk...@xs4all.nl] Sent: Monday, November 09, 2009 6:10 PM To: Hiremath, Vaibhav Cc: linux-media@vger.kernel.org; Jadav, Brijesh R; Karicheri, Muralidharan Subject: Re: [PATCH 6/6] TVP514x:Switch to automode for s_input/querystd Hi Vaibhav, See the review comments below. On Tuesday 13 October 2009 17:12:59 hvaib...@ti.com wrote: From: Vaibhav Hiremath hvaib...@ti.com Driver should switch to AutoSwitch mode on S_INPUT and QUERYSTD ioctls. It has been observed that, if user configure the standard explicitely then driver preserves the old settings. Reviewed by: Vaibhav Hiremath hvaib...@ti.com Signed-off-by: Brijesh Jadav brijes...@ti.com --- drivers/media/video/tvp514x.c | 17 + 1 files changed, 17 insertions(+), 0 deletions(-) diff --git a/drivers/media/video/tvp514x.c b/drivers/media/video/tvp514x.c index 2443726..0b0412d 100644 --- a/drivers/media/video/tvp514x.c +++ b/drivers/media/video/tvp514x.c @@ -523,10 +523,18 @@ static int tvp514x_querystd(struct v4l2_subdev *sd, v4l2_std_id *std_id) enum tvp514x_std current_std; enum tvp514x_input input_sel; u8 sync_lock_status, lock_mask; + int err; if (std_id == NULL) return -EINVAL; + err = tvp514x_write_reg(sd, REG_VIDEO_STD, + VIDEO_STD_AUTO_SWITCH_BIT); + if (err 0) + return err; + + msleep(LOCK_RETRY_DELAY); + We have a problem here with the V4L2 spec. The spec says that the standard should not change unless set explicitly by the user. So switching to auto mode in querystd is not correct. [Hiremath, Vaibhav] Hans, I have added this considering that; querystd means auto-detection of standard. V4L2 spec says that, Sense the video standard received by the current input. When user explicitly calls querystd, don't you think user should be aware of the fact that, driver is going to detect the standard automatically under this call. Is it possible to detect the standard without switching to automode? If it is, then that's the preferred solution. [Hiremath, Vaibhav] We can detect based on the TVP_VIDEO_STD_STATUS register, but will not be auto-detection. We will be reading the standard set by previous ioctls. If it cannot be done, then we need to extend the API and add support for a proper way of enabling automode. This is actually a long standing issue that used to be pretty low prio since it is very rare to see 'spontaneous' switches from e.g. PAL to NTSC. But with the upcoming timings API for HDTV this will become much more common. (e.g. switching from 1080p to 720p). We need to define this quite carefully. In particular what will happen if the standard switches while streaming. How does that relate to a scaler setup with S_FMT? Do we know when this happens so that we can notify the application? [Hiremath, Vaibhav] At-least in TVP5146 we have interrupt which we can enable on standard change from user on current input, but we are not using it. This could be another interesting point, how to add such support. Can we lock the standard when starting capturing? [Hiremath, Vaibhav] I think this makes sense to me, we should not allow changing the standard once streaming is going on. I think event manager may play a major role here, on standard change we should be able to send event back to application. Now the question is how application is going to handle this, since currently there is not way application can specify AUTOMODE, he has to query the standard and set it again. Thanks, Vaibhav My gut feeling is that AUTO detect should only be allowed if the application can be notified when the standard changes, or if the standard can be locked when streaming starts. The second part that is needed is some way to set the receiver into auto switching mode. For SDTV that probably means adding a new AUTO standard bit. Although to be honest I'm not keen on having to add something to v4l2_std_id. For the HDTV timings API we probably need to add an AUTO preset. Murali, can you think about this a bit and see how that will work out? /* get the current standard */ current_std = tvp514x_get_current_std(sd); if (current_std == STD_INVALID) @@ -643,6 +651,15 @@ static int tvp514x_s_routing(struct v4l2_subdev *sd, /* Index out of bound */ return -EINVAL; + /* Since this api is goint to detect the input, it is required + to set the standard in the auto switch mode */ + err = tvp514x_write_reg(sd, REG_VIDEO_STD, + VIDEO_STD_AUTO_SWITCH_BIT); Huh? I don't see what s_routing has to do with auto switch mode. + if (err 0) + return err; + + msleep(LOCK_RETRY_DELAY); + input_sel = input; output_sel = output; -- 1.6.2.4 Regards, Hans -- Hans
RE: Finished my email backlog, let me know if I missed anything
-Original Message- From: Hans Verkuil [mailto:hverk...@xs4all.nl] Sent: Monday, November 09, 2009 6:42 PM To: Hiremath, Vaibhav Cc: linux-media@vger.kernel.org Subject: Re: Finished my email backlog, let me know if I missed anything Hi Vaibhav, I've reviewed these patches, see comments below. [Hiremath, Vaibhav] Thanks a lot Hans, response in-lined below - On Friday 06 November 2009 07:49:47 Hiremath, Vaibhav wrote: -Original Message- From: linux-media-ow...@vger.kernel.org [mailto:linux-media- ow...@vger.kernel.org] On Behalf Of Hans Verkuil Sent: Thursday, November 05, 2009 10:01 PM To: linux-media@vger.kernel.org Subject: Finished my email backlog, let me know if I missed anything Hi all, As I've been away/busy for a few weeks I had a large pile of pending emails. I went through it all today, but if I missed anything then please remind me. [Hiremath, Vaibhav] Hans, there are some patches which I posted which need to be merged. Can you have look at it? VPFE - 6 patches I discovered that vpif_display.c does not compile at all due to a duplicate config pointer. This is both in our tree and in 2.6.32-rc6. I've made a patch for that. If you're OK with it then I pass it on to Mauro. [Hiremath, Vaibhav] Looks ok to me. I also noticed that vpif_capture.c/h were missing in v4l-dvb, so I copied them from 2.6.32-rc6. [Hiremath, Vaibhav] I just cross-checked in the L-o 2.6.32-rc6, and the file is present there. I think some commit removed these files from linuxtv/v4l-dvb repository, since this is only location where I don't see them. - Davinci VPFE Capture: Specify device pointer in videobuf_queue_dma_contig_init OK. - Davinci VPFE Capture:Replaced IRQ_VDINT1 with vpfe_dev- ccdc_irq1 OK. - Davinci VPFE Capture: Add support for Control ioctls[note: posting again] Waiting for your new post. [Hiremath, Vaibhav] Will be sending today. - TVP514x:Switch to automode for s_input/querystd Reviewed. See comments in the review of this particular patch. [Hiremath, Vaibhav] Thanks, will take it separately after closing on this. - Davinci VPFE Capture: Take i2c adapter id through platform data OK, but I split up the original patch into two: first adding the new field, then the arch patch can be applied, and then the final vpfe_capture.c change can be done. This ensures that a bisect will hopefully still work. [Hiremath, Vaibhav] I believe you have done the splitting here, right? Please let me know if you want me to do something here. OMAP - 2 patches - V4L2: Added CID's V4L2_CID_ROTATE/BG_COLOR OK. - v4l2 doc: Added S/G_ROTATE, S/G_BG_COLOR information OK. - V4L2: Add Capability and Flag field for Croma Key Missing documentation! BTW: the correct place to find the doc sources is in linux/Documentation/DocBook/v4l/ in the master v4l-dvb mercurial repository. [Hiremath, Vaibhav] Will send today. Thanks, Vaibhav - OMAP2/3 V4L2:Add support for OMAP2/3 V4L2 driver ontop of DSS2[Note: need to repost again] I wait for the repost and review it then. My tree with all the pending patches is available here: http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-vaibhav 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
Re: Finished my email backlog, let me know if I missed anything
On Tuesday 10 November 2009 07:36:22 Hiremath, Vaibhav wrote: -Original Message- From: Hans Verkuil [mailto:hverk...@xs4all.nl] Sent: Monday, November 09, 2009 6:42 PM To: Hiremath, Vaibhav Cc: linux-media@vger.kernel.org Subject: Re: Finished my email backlog, let me know if I missed anything Hi Vaibhav, I've reviewed these patches, see comments below. [Hiremath, Vaibhav] Thanks a lot Hans, response in-lined below - On Friday 06 November 2009 07:49:47 Hiremath, Vaibhav wrote: -Original Message- From: linux-media-ow...@vger.kernel.org [mailto:linux-media- ow...@vger.kernel.org] On Behalf Of Hans Verkuil Sent: Thursday, November 05, 2009 10:01 PM To: linux-media@vger.kernel.org Subject: Finished my email backlog, let me know if I missed anything Hi all, As I've been away/busy for a few weeks I had a large pile of pending emails. I went through it all today, but if I missed anything then please remind me. [Hiremath, Vaibhav] Hans, there are some patches which I posted which need to be merged. Can you have look at it? VPFE - 6 patches I discovered that vpif_display.c does not compile at all due to a duplicate config pointer. This is both in our tree and in 2.6.32-rc6. I've made a patch for that. If you're OK with it then I pass it on to Mauro. [Hiremath, Vaibhav] Looks ok to me. I also noticed that vpif_capture.c/h were missing in v4l-dvb, so I copied them from 2.6.32-rc6. [Hiremath, Vaibhav] I just cross-checked in the L-o 2.6.32-rc6, and the file is present there. I think some commit removed these files from linuxtv/v4l-dvb repository, since this is only location where I don't see them. - Davinci VPFE Capture: Specify device pointer in videobuf_queue_dma_contig_init OK. - Davinci VPFE Capture:Replaced IRQ_VDINT1 with vpfe_dev- ccdc_irq1 OK. - Davinci VPFE Capture: Add support for Control ioctls[note: posting again] Waiting for your new post. [Hiremath, Vaibhav] Will be sending today. Great! - TVP514x:Switch to automode for s_input/querystd Reviewed. See comments in the review of this particular patch. [Hiremath, Vaibhav] Thanks, will take it separately after closing on this. - Davinci VPFE Capture: Take i2c adapter id through platform data OK, but I split up the original patch into two: first adding the new field, then the arch patch can be applied, and then the final vpfe_capture.c change can be done. This ensures that a bisect will hopefully still work. [Hiremath, Vaibhav] I believe you have done the splitting here, right? Please let me know if you want me to do something here. That's correct, I split it up. So no need to do anything. OMAP - 2 patches - V4L2: Added CID's V4L2_CID_ROTATE/BG_COLOR OK. - v4l2 doc: Added S/G_ROTATE, S/G_BG_COLOR information OK. - V4L2: Add Capability and Flag field for Croma Key Missing documentation! BTW: the correct place to find the doc sources is in linux/Documentation/DocBook/v4l/ in the master v4l-dvb mercurial repository. [Hiremath, Vaibhav] Will send today. Good. Once I receive this one and the control patch today and assuming there are no issues with them, then I'll add them to my repo and make a pull request for the whole lot. 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
Re: v4l-dvb compile broken with stock Ubuntu Karmic build (firedtv-ieee1394.c errors)
Hello, I came across this thread from June 2009 in the news archives about Ubuntu Karmic and v4l-dvb compile broken with stock Ubuntu Karmic build: http://article.gmane.org/gmane.linux.drivers.video-input-infrastructure/7161 I've just come across this issue myself after an upgrade of a server to the Ubuntu Karmic release. Is there any plans to attempt to mitigate this so that other users would not be impacted? Regards, Thomas -- 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 6/6] TVP514x:Switch to automode for s_input/querystd
On Tuesday 10 November 2009 06:49:55 Hiremath, Vaibhav wrote: -Original Message- From: Hans Verkuil [mailto:hverk...@xs4all.nl] Sent: Monday, November 09, 2009 6:10 PM To: Hiremath, Vaibhav Cc: linux-media@vger.kernel.org; Jadav, Brijesh R; Karicheri, Muralidharan Subject: Re: [PATCH 6/6] TVP514x:Switch to automode for s_input/querystd Hi Vaibhav, See the review comments below. On Tuesday 13 October 2009 17:12:59 hvaib...@ti.com wrote: From: Vaibhav Hiremath hvaib...@ti.com Driver should switch to AutoSwitch mode on S_INPUT and QUERYSTD ioctls. It has been observed that, if user configure the standard explicitely then driver preserves the old settings. Reviewed by: Vaibhav Hiremath hvaib...@ti.com Signed-off-by: Brijesh Jadav brijes...@ti.com --- drivers/media/video/tvp514x.c | 17 + 1 files changed, 17 insertions(+), 0 deletions(-) diff --git a/drivers/media/video/tvp514x.c b/drivers/media/video/tvp514x.c index 2443726..0b0412d 100644 --- a/drivers/media/video/tvp514x.c +++ b/drivers/media/video/tvp514x.c @@ -523,10 +523,18 @@ static int tvp514x_querystd(struct v4l2_subdev *sd, v4l2_std_id *std_id) enum tvp514x_std current_std; enum tvp514x_input input_sel; u8 sync_lock_status, lock_mask; + int err; if (std_id == NULL) return -EINVAL; + err = tvp514x_write_reg(sd, REG_VIDEO_STD, + VIDEO_STD_AUTO_SWITCH_BIT); + if (err 0) + return err; + + msleep(LOCK_RETRY_DELAY); + We have a problem here with the V4L2 spec. The spec says that the standard should not change unless set explicitly by the user. So switching to auto mode in querystd is not correct. [Hiremath, Vaibhav] Hans, I have added this considering that; querystd means auto-detection of standard. V4L2 spec says that, Sense the video standard received by the current input. When user explicitly calls querystd, don't you think user should be aware of the fact that, driver is going to detect the standard automatically under this call. The spec is very silent about that :-) Perhaps we should modify the documentation and add one additional clause: QUERYSTD might return -EBUSY when capture is in progress depending on the driver. With this in place we can put the tvp514x in autodetect mode as long as there is no streaming going on. When streaming is started the tvp514x is set to the last selected S_STD standard and kept there until streaming stops, at which time it goes back to autodetect. Calling QUERYSTD while streaming will return -EBUSY. This makes sense to me. Is it possible to detect the standard without switching to automode? If it is, then that's the preferred solution. [Hiremath, Vaibhav] We can detect based on the TVP_VIDEO_STD_STATUS register, but will not be auto-detection. We will be reading the standard set by previous ioctls. If it cannot be done, then we need to extend the API and add support for a proper way of enabling automode. This is actually a long standing issue that used to be pretty low prio since it is very rare to see 'spontaneous' switches from e.g. PAL to NTSC. But with the upcoming timings API for HDTV this will become much more common. (e.g. switching from 1080p to 720p). We need to define this quite carefully. In particular what will happen if the standard switches while streaming. How does that relate to a scaler setup with S_FMT? Do we know when this happens so that we can notify the application? [Hiremath, Vaibhav] At-least in TVP5146 we have interrupt which we can enable on standard change from user on current input, but we are not using it. This could be another interesting point, how to add such support. Can we lock the standard when starting capturing? [Hiremath, Vaibhav] I think this makes sense to me, we should not allow changing the standard once streaming is going on. I think event manager may play a major role here, on standard change we should be able to send event back to application. Now the question is how application is going to handle this, since currently there is not way application can specify AUTOMODE, he has to query the standard and set it again. I don't think this is an issue for this device. And for HDTV devices we have to wait and see how that will work out. Regards, Hans Thanks, Vaibhav My gut feeling is that AUTO detect should only be allowed if the application can be notified when the standard changes, or if the standard can be locked when streaming starts. The second part that is needed is some way to set the receiver into auto switching mode. For SDTV that probably means adding a new AUTO standard bit. Although to be honest I'm not keen on having to add something to v4l2_std_id. For the HDTV timings API we probably need to add an
Re: v4l-dvb status
Thanks!
2009/11/9 Mauro Carvalho Chehab mche...@infradead.org:
Hi Giacomo,
Em Mon, 9 Nov 2009 09:19:05 +0100
Giacomo dellece...@gmail.com escreveu:
good morning to all in the list.
I have a few questions, back trying to install v4l-dvb kernel drivers
after some time.
1. Is the project going to support kernel 2.6.31?
Huh? This project is for upstream kernel drivers. All drivers produced go to
kernel.
Yes, I imagined.. but since still it does not compile on 2.6.31... I
just wanted to know..
anyway I managed compiling the drivers commenting inside a Makefile
the driver that
refused to..
2. I used to use tvtime + sox for the usb audio, with big problems
causing audio
desynchronization with large delay with respect to the video: do
the (new) drivers
solve the issue?
- I also remember that there was an integrated version of
tvtime/usb audio in hg repositories,
is it still maintained? is there a particular version to download
to correctly build it?
tvtime stopped being maintained on 2005. You may find a few patches for it on
some places, but there are some issues on those patches.
Currently, you'll find a good support for V4L2 with mplayer. It generally
synchronizes audio and video well.
I'll try it! Anyway, just yesterday playing with sox I found out a
satisfying configuration
for audio and video synchronization... the fact is that in most of
forums the posted information
is often wrong, and there is a lack of good `official' documentation,
leaving these kind of things
only for out-and-out specialists!
Thanks for your attention!
ciao Giacomo
3. It's two years since I first installed v4l-dvb drivers, and still I
encounter problems to find all
the channels with tvtime.
Is there some module parameter to provide for the module em28xx for
Pinnacle PCTV USB2,
for the Italian standards?
You should be sure to select the proper video standard used in Italy. Maybe
your
device tuner is different than the one configured at the driver. Different
tuners
generally have different cut-off frequencies between the 3 bands (low VHF,
high VHF,
UHF). If you are using a different tuner, you may not be able to see the
channels that
are close to the cut-off frequencies.
Currently, there are two variants of PCTV:
[EM2820_BOARD_PINNACLE_USB_2] = {
.name = Pinnacle PCTV USB 2,
.tuner_type = TUNER_LG_PAL_NEW_TAPC,
[EM2820_BOARD_PINNACLE_USB_2_FM1216ME] = {
.name = Pinnacle PCTV USB 2 (Philips FM1216ME),
.tuner_type = TUNER_PHILIPS_FM1216ME_MK3,
Each with a different tuner. The better way is to open your device and see
what's labeled at the metal can inside it, to be sure what variant are you
using.
You may also play with the tuner by passing a parameter to the kernel driver
specifying your
tuner model, based on the numbers at:
linux/Documentation/video4linux/CARDLIST.tuner
Thanks in advance for any hint and the great work done on v4l-dvb project
Giacomo
Cheers,
Mauro
--
Giacomo S.
http://www.giacomos.it
- - - - - - - - - - - - - - - - - - - - - -
* Aprile 2008: iqfire-wall, un progetto
open source che implementa un
filtro di pacchetti di rete per Linux,
e` disponibile per il download qui:
http://sourceforge.net/projects/ipfire-wall
* Informazioni e pagina web ufficiale:
http://www.giacomos.it/iqfire/index.html
- - - - - - - - - - - - - - - - - - - - - -
. '' `.
: :':
`. ` '
`- Debian GNU/Linux -- The power of freedom
http://www.debian.org
--
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
