Re: You are now subscribed to linuxtv-dvb-apps
On Friday 26 February 2010 18:02:53 Raphael Hertzog wrote: I was expecting somehow that either the Debian maintainer or the upstream maintainer of linuxtv-dvb-apps thought that it was a good idea to receive Debian BTS mails on his mailing list. Debian Maintainer (me), thinking it is good for upstream to receive user updates of frequencies of their local TV stations which we are receiving in the BTS. Mark signature.asc Description: This is a digitally signed message part.
Re: You are now subscribed to linuxtv-dvb-apps
On Fri, 26 Feb 2010 08:02:53 BST, Raphael Hertzog wrote: [snip] You reply to subscription confirmation mails that you have not asked for? Seriously... Only once. I was expecting somehow that either the Debian maintainer or the upstream maintainer of linuxtv-dvb-apps thought that it was a good idea to receive Debian BTS mails on his mailing list. If that's not the case, someone should unsubscribe again (or I can do it for you). Ccing the debian maintainers to verify. Please do it for me. Hope I haven't made much work for anyone, Brian Keck -- 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
OnAir USB HDTV Creator
I am trying to use an 'OnAir USB HDTV Creator' (from autumnwave.com). According to http://www.linuxtv.org/wiki/index.php/OnAir_USB_HDTV_Creator This device is supported, however it's not working for me. Following the instructions at above link, I tried this: modprobe pvrusb2 initusbreset=0 The result: FATAL: Error inserting pvrusb2 (/lib/modules/2.6.31.12-desktop586-1mnb/kernel/drivers/media/video/pvrusb2/pvrusb2.ko.gz): Unknown symbol in module, or unknown parameter (see dmesg) When connecting the unit, dmesg shows only these six lines. usb 1-3: new high speed USB device using ehci_hcd and address 10 usb 1-3: New USB device found, idVendor=11ba, idProduct=1101 usb 1-3: New USB device strings: Mfr=1, Product=2, SerialNumber=0 usb 1-3: Product: USB HDTV-GT(1.1) usb 1-3: Manufacturer: OnAirSolution usb 1-3: configuration #1 chosen from 1 choice Anyone know what to do? -- 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: More videobuf and streaming I/O questions
Pawel Osciak wrote: On Tuesday 23 February 2010 08:41:49 Pawel Osciak wrote: On Mon, 22 Feb 2010 00:12:18 +0100 Laurent Pinchart laurent.pinch...@ideasonboard.com wrote: As for the REQBUF, I've always thought it'd be nice to be able to ask the driver for the recommended number of buffers that should be used by issuing a REQBUF with count=0... How would the driver come up with the number of recommended buffers ? From the top of my head: when encoding a video stream, a codec driver could decide on the minimum number of input frames required (including reference frames, etc.). Or maybe I am missing something, what is your opinion on that? There are some cases where this feature could be useful. For example, there are some devices used for surveillance that have one decoder connected to several inputs. For example, several bttv boards have one bt848 chip for each 8 inputs. Each input is connected to one camera. The minimum recommended number of buffers is 16 (2 per each input). This is poorly documented, on some wikis for some of the boards with such usage. That's said, there's currently a few missing features for surveillance: the user software need to manually switch from one input to another, and the video buffer metadata doesn't indicate the input. The better would be to provide a way to let the driver to switch to the next camera just after the reception of a new buffer (generally at the IRQ time), instead of letting the userspace software to do it at the DQBUF. -- 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: You are now subscribed to linuxtv-dvb-apps
Mark Purcell wrote: On Friday 26 February 2010 18:02:53 Raphael Hertzog wrote: I was expecting somehow that either the Debian maintainer or the upstream maintainer of linuxtv-dvb-apps thought that it was a good idea to receive Debian BTS mails on his mailing list. Debian Maintainer (me), thinking it is good for upstream to receive user updates of frequencies of their local TV stations which we are receiving in the BTS. Mark, While receiving dvb-apps updates on upstream is a good idea, I don't think that subscribing one list to the other is the proper way for it. If we use that logic, we would need to subscribe all kernel ML's (LMML, acpi, alsa, ...) at LKML. This would just add more traffic, mixing different subjects. As you'll be receiving those requests and patches, the better is for you to forward us the patches you receive and send us upstream patches based on the reports you're receive, keeping your package in sync with upstream, while saving us for any internal discussions that it may be pertinent only to the Debian ML. -- 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: More videobuf and streaming I/O questions
On Fri, Feb 26, 2010 at 7:04 AM, Mauro Carvalho Chehab mche...@infradead.org wrote: Pawel Osciak wrote: On Tuesday 23 February 2010 08:41:49 Pawel Osciak wrote: On Mon, 22 Feb 2010 00:12:18 +0100 Laurent Pinchart laurent.pinch...@ideasonboard.com wrote: As for the REQBUF, I've always thought it'd be nice to be able to ask the driver for the recommended number of buffers that should be used by issuing a REQBUF with count=0... How would the driver come up with the number of recommended buffers ? From the top of my head: when encoding a video stream, a codec driver could decide on the minimum number of input frames required (including reference frames, etc.). Or maybe I am missing something, what is your opinion on that? There are some cases where this feature could be useful. For example, there are some devices used for surveillance that have one decoder connected to several inputs. For example, several bttv boards have one bt848 chip for each 8 inputs. Each input is connected to one camera. The minimum recommended number of buffers is 16 (2 per each input). This is poorly documented, on some wikis for some of the boards with such usage. That's said, there's currently a few missing features for surveillance: the user software need to manually switch from one input to another, and the video buffer metadata doesn't indicate the input. The better would be to provide a way to let the driver to switch to the next camera just after the reception of a new buffer (generally at the IRQ time), instead of letting the userspace software to do it at the DQBUF. This is an interesting use case and I would like to know some details on this use case. When you say application manually switch the input, Is it implementing some kind of input multiplexing during the session (open, stream on - stream off, close) ? We have encountered a similar use case and I was wondering how this can be implemented in v4l2 driver. In my understanding, a v4l2 device is not allowed to switch input while streaming. Does it require 2 buffers per input because every frame period, you have multiple frames to queue from the different inputs? Usually a minimum of 3 buffers are typically required in a SoC case to do streaming. Could you share the details if possible? Murali -- 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 -- Murali Karicheri mkarich...@gmail.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
support for device node for sub devices
Hello Laurent, I see that you have added support for sub device device nodes in your media controller development tree. This is an important feature for SoC devices since this will allow application to configure the sub device nodes like that on VPFE/VPBE of a DMxxx device. Shouldn't we add this feature right away perhaps in 2.6.35 so that drivers can make use of it? -- Murali Karicheri -- 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: You are now subscribed to linuxtv-dvb-apps
On Friday 26 February 2010 23:46:30 Mauro Carvalho Chehab wrote: While receiving dvb-apps updates on upstream is a good idea, I don't think that subscribing one list to the other is the proper way for it. If we use that logic, we would need to subscribe all kernel ML's (LMML, acpi, alsa, ...) at LKML. This would just add more traffic, mixing different subjects. Well the Debian linuxtv-dvb-apps isn't really a mailing list, rather an alias where bug reports from users and other interesting stuff is forwarded about the dvb-apps application. As you'll be receiving those requests and patches, the better is for you to forward us the patches you receive and send us upstream patches based on the reports you're receive, keeping your package in sync with upstream, while saving us for any internal discussions that it may be pertinent only to the Debian ML. We aren't talking about a lot of traffic, there hasn't been any internal discussions and we have had 5 reports in the last 12 months.. http://bugs.debian.org/cgi-bin/pkgreport.cgi?pkg=dvb-apps;dist=unstable I'm happy to onforward, but there can be a lag of upto a couple of months. Mark signature.asc Description: This is a digitally signed message part.
Re: More videobuf and streaming I/O questions
Hi Pawel and Mauro, On Friday 26 February 2010 13:04:54 Mauro Carvalho Chehab wrote: Pawel Osciak wrote: On Tuesday 23 February 2010 08:41:49 Pawel Osciak wrote: On Mon, 22 Feb 2010 00:12:18 +0100 Laurent Pinchart laurent.pinch...@ideasonboard.com wrote: As for the REQBUF, I've always thought it'd be nice to be able to ask the driver for the recommended number of buffers that should be used by issuing a REQBUF with count=0... How would the driver come up with the number of recommended buffers ? From the top of my head: when encoding a video stream, a codec driver could decide on the minimum number of input frames required (including reference frames, etc.). Drivers can always raise or lower the number of buffers passed as the VIDIOC_REQBUFS argument, so we already have a way to handle hardware requirements there. If we really need a way to tell the driver please decide on the number of buffers for me, we could use a flag/magic value for the buffer count instead of using 0. The V4L2 specification clearly states that a count of 0 frees the buffers, and several applications rely on that feature. Or maybe I am missing something, what is your opinion on that? There are some cases where this feature could be useful. For example, there are some devices used for surveillance that have one decoder connected to several inputs. For example, several bttv boards have one bt848 chip for each 8 inputs. Each input is connected to one camera. The minimum recommended number of buffers is 16 (2 per each input). Why two per input ? There's a single video stream, buffers are not queued separately for each input. Beside, even if the number of recommended buffers was 2 per input, I would expect applications to know about that. If an application decides to open a single video node and call VIDIOC_S_INPUT during streaming (or configure the driver to do it automatically at IRQ time, which is conceptually similar), the application should be able to compute the required number of buffers. This is poorly documented, on some wikis for some of the boards with such usage. That's said, there's currently a few missing features for surveillance: the user software need to manually switch from one input to another, and the video buffer metadata doesn't indicate the input. There's actually an input field in v4l2_buffer. As far as I know it's only used by an out-of-tree, closed source driver that nobody is using anymore (I'm the one who requested a reserved field to be turned into the input field back then). Now that I'm a bit more knowledgeable about V4L2 and Linux in general, I don't think that's the best way to pass metadata around. The v4l2_buffer structure won't be able to hold all metadata we need in the future. The better would be to provide a way to let the driver to switch to the next camera just after the reception of a new buffer (generally at the IRQ time), instead of letting the userspace software to do it at the DQBUF. That would be an improvement, but even then it might be too late. The only way to handle analog input switching reliably is to synchronize the input switch to the analog signal, and that must be done by the hardware. That kind of feature is not commonly found in cheap bttv boards. -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: More videobuf and streaming I/O questions
Hi, On Friday 26 February 2010 14:05:30 Muralidharan Karicheri wrote: On Fri, Feb 26, 2010 at 7:04 AM, Mauro Carvalho Chehab wrote: Pawel Osciak wrote: On Tuesday 23 February 2010 08:41:49 Pawel Osciak wrote: On Mon, 22 Feb 2010 00:12:18 +0100 Laurent Pinchart laurent.pinch...@ideasonboard.com wrote: As for the REQBUF, I've always thought it'd be nice to be able to ask the driver for the recommended number of buffers that should be used by issuing a REQBUF with count=0... How would the driver come up with the number of recommended buffers ? From the top of my head: when encoding a video stream, a codec driver could decide on the minimum number of input frames required (including reference frames, etc.). Or maybe I am missing something, what is your opinion on that? There are some cases where this feature could be useful. For example, there are some devices used for surveillance that have one decoder connected to several inputs. For example, several bttv boards have one bt848 chip for each 8 inputs. Each input is connected to one camera. The minimum recommended number of buffers is 16 (2 per each input). This is poorly documented, on some wikis for some of the boards with such usage. That's said, there's currently a few missing features for surveillance: the user software need to manually switch from one input to another, and the video buffer metadata doesn't indicate the input. The better would be to provide a way to let the driver to switch to the next camera just after the reception of a new buffer (generally at the IRQ time), instead of letting the userspace software to do it at the DQBUF. This is an interesting use case and I would like to know some details on this use case. When you say application manually switch the input, Is it implementing some kind of input multiplexing during the session (open, stream on - stream off, close) ? No, applications just call VIDIOC_S_INPUT while the stream is active. We have encountered a similar use case and I was wondering how this can be implemented in v4l2 driver. In my understanding, a v4l2 device is not allowed to switch input while streaming. Switching input while streaming is allowed (if I'm not mistaken), as long as the format and size don't change (not sure about lowering the size, that needs to be double-checked). This being said, VIDIOC_S_INPUT was designed to switch analog sources. I'm not sure it would be the best would to multiplex streams from two digital sensors for instance. Even for analog signals, using the ioctl from userspace usually results in at least one corrupt frame if you don't synchronize the switching to the analog signals, which requires hardware support. Can you give us more details about the use case you're thinking about ? Does it require 2 buffers per input because every frame period, you have multiple frames to queue from the different inputs? In this case there's a single video stream, so I don't think it would require 2 buffers per input. Usually a minimum of 3 buffers are typically required in a SoC case to do streaming. Could you share the details if possible? -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[BUG] TDA10086 : Creatix CTX929_V.1 : TS continuity errors with good RF signal input
Hi, Issue is already confirmed here: http://www.vdr-portal.de/board/thread.php?threadid=93268 Linux 2.6.32.8, 80cm dish. Do we have any Tuner/Decoder optimization points in the FE code? This is not OK: lspci -s 00:08.0 -v 00:08.0 Multimedia controller: Philips Semiconductors SAA7134/SAA7135HL Video Broadcast Decoder (rev 01) Subsystem: Creatix Polymedia GmbH Device 0005 Flags: bus master, medium devsel, latency 32, IRQ 19 Memory at fbeff400 (32-bit, non-prefetchable) [size=1K] Capabilities: [40] Power Management version 1 Kernel driver in use: saa7134 grep cTS2PES /var/log/syslog Feb 26 13:46:59 tom1 vdr: [4082] cTS2PES got 7 TS errors, 113 TS continuity errors Feb 26 13:46:59 tom1 vdr: [4082] cTS2PES got 0 TS errors, 29 TS continuity errors Feb 26 13:47:52 tom1 vdr: [4082] cTS2PES got 17 TS errors, 5 TS continuity errors Feb 26 14:03:03 tom1 vdr: [4082] cTS2PES got 2 TS errors, 136 TS continuity errors Feb 26 14:03:03 tom1 vdr: [4082] cTS2PES got 0 TS errors, 32 TS continuity errors Feb 26 14:41:42 tom1 vdr: [4082] cTS2PES got 1 TS errors, 853 TS continuity errors Feb 26 14:41:42 tom1 vdr: [4082] cTS2PES got 0 TS errors, 194 TS continuity errors Feb 26 14:52:58 tom1 vdr: [4082] cTS2PES got 2 TS errors, 196 TS continuity errors Feb 26 14:52:58 tom1 vdr: [4082] cTS2PES got 0 TS errors, 52 TS continuity errors Feb 26 14:59:34 tom1 vdr: [4082] cTS2PES got 0 TS errors, 137 TS continuity errors Feb 26 14:59:34 tom1 vdr: [4082] cTS2PES got 0 TS errors, 43 TS continuity errors Feb 26 14:59:34 tom1 vdr: [4082] cTS2PES got 0 TS errors, 16 TS continuity errors Feb 26 14:59:34 tom1 vdr: [4082] cTS2PES got 0 TS errors, 57 TS continuity errors Feb 26 14:59:54 tom1 vdr: [4082] cTS2PES got 0 TS errors, 3 TS continuity errors Feb 26 14:59:54 tom1 vdr: [4082] cTS2PES got 0 TS errors, 2 TS continuity errors dvbsnoop -s feinfo -adapter 2 Current parameters: Frequency: 1236.253 MHz Inversion: OFF Symbol rate: 31.794142 MSym/s FEC: FEC 3/4 dvbsnoop -s signal -adapter 2 cycle: 1 d_time: 0.001 s Sig: 26471 SNR: 49858 BER: 0 UBLK: 0 Stat: 0x1f [SIG CARR VIT SYNC LOCK ] cycle: 2 d_time: 0.072 s Sig: 26471 SNR: 50115 BER: 0 UBLK: 0 Stat: 0x1f [SIG CARR VIT SYNC LOCK ] cycle: 3 d_time: 0.072 s Sig: 26728 SNR: 50115 BER: 0 UBLK: 0 Stat: 0x1f [SIG CARR VIT SYNC LOCK ] cycle: 4 d_time: 0.088 s Sig: 26728 SNR: 50115 BER: 0 UBLK: 0 Stat: 0x1f [SIG CARR VIT SYNC LOCK ] cycle: 5 d_time: 0.072 s Sig: 26471 SNR: 50115 BER: 0 UBLK: 0 Stat: 0x1f [SIG CARR VIT SYNC LOCK ] cycle: 6 d_time: 0.072 s Sig: 26471 SNR: 50115 BER: 0 UBLK: 0 Stat: 0x1f [SIG CARR VIT SYNC LOCK ] cycle: 7 d_time: 0.072 s Sig: 26471 SNR: 50115 BER: 0 UBLK: 0 Stat: 0x1f [SIG CARR VIT SYNC LOCK ] cycle: 8 d_time: 0.072 s Sig: 26471 SNR: 50115 BER: 0 UBLK: 0 Stat: 0x1f [SIG CARR VIT SYNC LOCK ] Low signal strength values are AGC-loop misinterpretation as usual? y tom -- 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: More videobuf and streaming I/O questions
This being said, VIDIOC_S_INPUT was designed to switch analog sources. I'm not sure it would be the best would to multiplex streams from two digital sensors for instance. Even for analog signals, using the ioctl from userspace usually results in at least one corrupt frame if you don't synchronize the switching to the analog signals, which requires hardware support. Can you give us more details about the use case you're thinking about ? This is for supporting interfacing of TVP5148 to DM365 that can mux from two sources. There is an implementation of this in our internal release. Just exploring how this can be ported to upstream. Not done any work yet on this from my side. Does it require 2 buffers per input because every frame period, you have multiple frames to queue from the different inputs? In this case there's a single video stream, so I don't think it would require 2 buffers per input. Usually a minimum of 3 buffers are typically required in a SoC case to do streaming. Could you share the details if possible? -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- 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: Requested feedback on V4L2 driver design
Laurent, Responses inline. Sincerely, Chase Maupin Software Applications Catalog DSP Products e-mail: chase.mau...@ti.com phone: (281) 274-3285 For support: Forums - http://community.ti.com/forums/ Wiki - http://wiki.davincidsp.com/ -Original Message- From: Laurent Pinchart [mailto:laurent.pinch...@ideasonboard.com] Sent: Thursday, February 25, 2010 6:35 PM To: Maupin, Chase Cc: Hans Verkuil; sakari.ai...@maxwell.research.nokia.com; mche...@infradead.org; vpss_driver_des...@list.ti.com - This list is to discuss the VPSS driver design (May contain non-TIers); linux- me...@vger.kernel.org Subject: Re: Requested feedback on V4L2 driver design Hi Chase, On Tuesday 16 February 2010 14:00:11 Maupin, Chase wrote: Laurent, To follow up with some of the comments I made before I got additional clarification about the commands supported by the proxy driver running on the VPSS MCU. The proxy will support all of the commands used by V4L2 as well as those proposed extensions to V4L2 that Hans has mentioned. Basically, the list of commands supported at initial release is not only those required today, but a full set for all the features of the VPSS. In this was as new APIs are added to V4L2 the support for those features will already be supported by the VPSS MCU proxy driver. Thank you for the clarification. A few things are still uncleared to me, as stated in my previous mail (from a few minutes ago). My main question is, if the VPSS API is full-featured and accessible from the master CPU, why do we need a proxy driver in the firmware at all ? The proxy driver is the piece of code in the firmware that is actually exposing the VPSS API to the master CPU. It is responsible for listening for requests from the master CPU and then executing those requests on the VPSS CPU. Without the proxy there is no way to tell the VPSS CPU which functions to execute. As for the license of the firmware this is still being worked. It is currently under TI proprietary license and will be distributed as binary under Technical Software Publicly Available (TSPA) which means it can be obtained by anyone. If you feel that source code is required for the firmware at launch to gain acceptance please let us know and we can start working that issue. I think it would definitely help keeping the Linux driver and the VPSS firmware in sync if the VPSS firmware source was available. The firmware source code could even be distributed along with the Linux driver. Thanks for the input. We'll keep this in mind and see what we can do. By the way, will the firmware be loaded at runtime by the driver, or will it be stored internally in the chip ? The firmware will not be stored internally on the chip and will have to be loaded at runtime. We have not settled on how the loading will be done. Currently we are thinking on loading it from u-boot similar to an FPGA firmware load but it could also be done from the kernel. -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: OnAir USB HDTV Creator
On Fri, 26 Feb 2010, Dean wrote: I am trying to use an 'OnAir USB HDTV Creator' (from autumnwave.com). According to http://www.linuxtv.org/wiki/index.php/OnAir_USB_HDTV_Creator This device is supported, however it's not working for me. Following the instructions at above link, I tried this: modprobe pvrusb2 initusbreset=0 The result: FATAL: Error inserting pvrusb2 (/lib/modules/2.6.31.12-desktop586-1mnb/kernel/drivers/media/video/pvrusb2/pvrusb2.ko.gz): Unknown symbol in module, or unknown parameter (see dmesg) Dean: The initusbreset module option no longer exists. That's why your modprobe command is failing. That feature was removed from the driver, due to a change in USB stack behavior that started with the 2.6.27 kernel. (The resolution hinted at in the wiki page was in fact just removal of the feature.) So you need to not use initusbreset=0. The advice in the wiki is over a year out of date. -Mike -- Mike Isely isely @ isely (dot) net PGP: 03 54 43 4D 75 E5 CC 92 71 16 01 E2 B5 F5 C1 E8 -- 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: Requested feedback on V4L2 driver design
Laurent, Responses inline Puru, There is a question for you below. Can you look at it and provide an answer? Sincerely, Chase Maupin Software Applications Catalog DSP Products e-mail: chase.mau...@ti.com phone: (281) 274-3285 For support: Forums - http://community.ti.com/forums/ Wiki - http://wiki.davincidsp.com/ -Original Message- From: Laurent Pinchart [mailto:laurent.pinch...@ideasonboard.com] Sent: Thursday, February 25, 2010 6:32 PM To: Maupin, Chase Cc: Hans Verkuil; sakari.ai...@maxwell.research.nokia.com; mche...@infradead.org; vpss_driver_des...@list.ti.com - This list is to discuss the VPSS driver design (May contain non-TIers); linux- me...@vger.kernel.org; Kamoolkar, Mugdha Subject: Re: Requested feedback on V4L2 driver design Hi Chase, On Friday 12 February 2010 17:46:55 Maupin, Chase wrote: Laurent, First let me thank you for taking time to review this. You're welcome. [snip] -Original Message- From: Laurent Pinchart [mailto:laurent.pinch...@ideasonboard.com] Sent: Thursday, February 11, 2010 7:23 PM On Monday 08 February 2010 16:08:37 Maupin, Chase wrote: [snip] If you have additional questions or need more information please feel free to contact us (we have setup a mailing list at vpss_driver_des...@list.ti.com) so we can answer them. I'll answer here as the instructions provided in the wiki to subscribe to the vpss_driver_design mailing list are incorrect (http://list.ti.com/ isn't accessible, the name has no A record associated to it). I've CC'ed the list in case subscription wouldn't be required to post. The page for subscribing to the list requires a my.TI login which you can setup at https://myportal.ti.com/portal/dt?provider=TIPassLoginSingleContainerlt=m ytij5=2j3=1goto=https%3A%2F%2Fmy.ti.com%3A443%2Fcgi- bin%2Fhome.pl%3FDCMP %3DTIHeaderTracking%26HQS%3DOther%2BOT%2Bhdr_my_ti. However, your reply to the list should be fine without subscribing. Thanks for the information, but http://list.ti.com/ still can't be accessed. The host list.ti.com has no A record, an HTTP connection can't thus be established. I'm not sure what is going on here. Let me file a ticket with our IT group and see if they can fix the problem. 1. Multi-core design OMAP3 was already a dual-core system, OMAP4 (I assume all this is about the OMAP4 processors family) seems to push the concept one step further. With its heterogeneous multi-core design (ARM master CPU and slave DSPs), the OMAP architecture delivers high performances at the cost of higher development time and effort as users need to write software for completely different cores, usually using different toolchains. This is in my opinion a good (or at least acceptable) trade-off between CPU power, development time and power consumption (DSPs being more efficient at signal processing at the cost of a higher development complexity). I'm a bit puzzled, however, by how the VPSS MCU will help improving the situation compared to the OMAP3 design. The VPSS MCU will provide an API that will expose a fixed subset of the hardware capabilities. This is only a guess, but I suppose the firmware will be fairly generic, and that TI will provide customized versions to big customers tailored for their needs and use cases. The official kernel drivers will then need to be changed, and those changes will have no chance to be accepted in the mainline kernel. This will lead to forks and fragmentation of the developers base among the big players in the embedded markets. What will be the compensation for that ? How will the VPSS MCU provide higher performances than the OMAP3 model ? The firmware on the VPSS MCU will be able to configure/control all of the functionality that the VPSS MCU has and will be the same for all customers. The only part that may change is the proxy driver of the firmware. The proxy driver is the piece that will be responsible for taking the commands from the driver and telling the firmware to execute the operation. As the proxy is the tip of the firmware iceberg, it will be all the Linux driver will care about. Whether the firmware backend is able to configure and control all of the functionality that the VPSS MCU offers is then irrelevant, as the Linux driver will have no way to access that backend directly. Is my understanding correct ? As you saw in my follow-up e-mail the proxy will support all the VPSS APIs so my statement was misleading. The initial version of the proxy will support all the standard V4L2 operations. As new operations (such as on the fly video scaling) are added to the V4L2 API the firmware may require an update to the proxy driver to handle these requests, but the underlying code will remain the same. Different proxy versions will need different version of the Linux
V4L2 file handle and event patches
Sakari Ailus wrote: Hi, Here's the tenth version of the V4L2 file handle and event interface patchset. The patchset has been tested with the OMAP 3 ISP driver. Patches for OMAP 3 ISP are not part of this patchset but are available in Gitorious (branch is called event): git://gitorious.org/omap3camera/mainline.git event The patchset I'm posting now is against the v4l-dvb tree instead of linux-omap. The omap3camera tree thus has a slightly different version of these patches (just Makefiles) due to different baselines. Hi Mauro, What is your opinion on the file handle and event patchset? Could we get them integrated for 2.6.34? Hans Verkuil as well as many others have no more comments on them. The patchset in question is v8. Sincerely, -- Sakari Ailus sakari.ai...@maxwell.research.nokia.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
cx18: where do the transport stream PIDs come from?
Hi, while working on a small test app which repacks the ivtv-PS into a TS, I received a sample from a cx18-based card. The TS contains the video PID 301, audio PID 300 and PCR pid 101. Where do these PIDs come from, are they set by the driver or are they firmware given? Is it possible to change them? Regards, Lars. -- 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: How to add DVB-S2 support to firedtv?
Hi there I own a FireDTV S2 and I'm willing to invest some time. I poked around in the driver code previously and I might do some coding given that I have access to the required technical information. As far as I know Digital Everywhere is out of business - does this mean that the NDAs are no longer in effect and that someone could give me the technical documentation required? Cheerio Beat On Thu, 2010-02-18 at 11:04 +0100, Henrik Kurelid wrote: Hi, Regarding the documentation and code: From a quick glance, the LNB/QPSK2 code follows the documentation fairly good. I guess it could do with a deeper check (I could see that at least the FEC switch case does seems to have some invalid values) but I would prefer that this is done by someone that actually has a DVB-S(2) card. Regards, Henrik Hi all, what steps need to be taken to get DVB-S2 support into the firedtv driver? (The status is, as far as I understood: FireDTV S2 and Floppy DTV S2 devices recognize HD channels during channel scan but cannot tune to them. FireDTV C/CI DVB-C boxes however tune and play back HD channels just fine.) I suppose the frontend needs to be extended for s2api. Was there a respective conversion in another DVB driver that can serve as a good coding example? Is documentation from Digital Everywhere required regarding the vendor-specific AV/C requests (LNB_CONTROL? TUNE_QPSK2?) or is the current driver code enough to connect the dots? Is the transport stream different from DVB-C HD streams so that changes to the isochronous I/O part would be required? -- Stefan Richter -=-==-=- --=- -===- http://arcgraph.de/sr/ -- 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
Announcing v4l-utils-0.7.90 (which includes libv4l-0.7.90)
Hi, I'm happy to announce the first (test / beta) release of v4l-utils, v4l-utils is the combination of various v4l and dvb utilities which used to be part of the v4l-dvb mercurial kernel tree and libv4l. I encourage people to give this version a spin. I esp. would like feedback on which v4l / dvb utilities should end up being installed by make install. For now I've stuck with what the Makefile in v4l2-apps did. See README for a list of all utilities and if they are currently installed or not. If you are doing distribution packaging of libv4l, note that the good old libv4l tarbal releases are going away, libv4l will now be released as part of v4l-utils, and you are encouraged to package that up completely including the included utilities. As I'm doing distro package maintenance myself I know this is a pain, but in the long run having a single source for v4l + dvb userspace tools and libraries is for the best. New this release: v4l-utils-0.7.90 * This is the first release of v4l-utils, v4l-utils is the combination of various v4l and dvb utilities which used to be part of v4l-dvb mercurial kernel tree and libv4l. * This first version is 0.7.90, as the version numbers continue were libv4l as a standalone source archive stops. * libv4l changes: * Add more laptop models to the upside down devices table * Fix Pixart JPEG ff ff ff xx markers removal, this fixes the occasional corrupt frame we used to get (thanks to Németh Márton) * Enable whitebalance by default on various sonixj based cams * Enable whitebalance + gamma correction by default on all sonixb cams * Enable gamma correction by default on pac7302 based cams Go get it here: http://people.fedoraproject.org/~jwrdegoede/v4l-utils-0.7.90.tar.bz2 You can always find the latest developments here: http://git.linuxtv.org/v4l-utils.git Note, it would be good to have some place at linuxtv.org to host the tarbals, if someone could help me set that up that would be great. Regards, Hans -- 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
[GIT PULL for 2.6.33-rc1] V4L/DVB updates
The following changes since commit 60b341b778cc2929df16c0a504c91621b3c6a4ad: Linus Torvalds (1): Linux 2.6.33 are available in the git repository at: ssh://master.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-2.6.git v4l_for_linus Abylay Ospan (3): V4L/DVB (13936): 22-kHz set_tone fix for NetUP Dual DVB-S2-CI card V4L/DVB: 22-kHz set_tone fix for NetUP Dual DVB-S2-CI card. 22kHz logic controlled by demod V4L/DVB: STV0900 Cut 3.0 AGC2 fix for NetUP Dual DVB-S2-CI card Adams Xu (1): V4L/DVB: AZ6027: Initial import of the driver Alexander Beregalov (1): V4L/DVB: ir: fix memory leak Alexander Strakh (1): V4L/DVB: cafe_ccic: Fix lock imbalances Alexey Dobriyan (1): V4L/DVB (13946): proc_fops: convert av7110 andrea.amoros...@gmail.com (1): V4L/DVB: em28xx: add Dikom DK300 hybrid USB tuner Andreas Regel (12): V4L/DVB (13974): [STV090x] Fix locking reliabilty issues in automatic mode. V4L/DVB (13975): [STV090x] Added internal structure with shared settings and data. V4L/DVB (13976): [STV090x] Added mutex protection around tuner I2C access. V4L/DVB (13977): [STV090x] Test for valid frequency before starting to tune V4L/DVB (13978): [STV090x] set FE_HAS_SIGNAL flag in stv090x_read_status when locked. V4L/DVB (13979): [STV090x] Added possibility to set a fixed TS output clock. V4L/DVB (13980): [STV6110x] Added function stv6110x_write_regs V4L/DVB (13981): [STV6110x] Add a local register map for each instance of the driver. V4L/DVB (13982): [STV090x] setup master clock in stv090x_init instead of stv090x_setup. V4L/DVB (13983): [STV6110x] add clk_div member to stv6110x_config structure V4L/DVB (13984): [BUDGET] Use a tuner clock output divider of 2 for TT S2-1600. V4L/DVB (13985): [STV090x] reset mclk and dev_ver of internal structure after allocating Andrew Morton (3): V4L/DVB: drivers/media/video/cx18/cx18-alsa-pcm.c: fix printk warning V4L/DVB: drivers/media/dvb/frontends/stv090x.c: fix use-uninitialised V4L/DVB: drivers/media/dvb/frontends/stv090x.c: fix use-uninitlalised Andy Walls (22): V4L/DVB (13902): cx18: Update MPEG Index stream buffers module option processing V4L/DVB (13903): cx18: Encapsulate check for a stream being enabled into an inline function V4L/DVB (13904): cx18: Fix TS and IDX stream buffer memory leak on module unload V4L/DVB (13905): cx18: Allow MPEG index streams to be started and stopped internally V4L/DVB (13906): cx18: Start IDX streams automatically as an internal associated stream V4L/DVB (13907): cx18: Perform automatic rotation of very old, unread IDX buffers V4L/DVB (13908): cx18: Add initial working VIDIOC_G_ENC_INDEX ioctl() support V4L/DVB (13909): cx18: Clean up dead code from ivtv once used for IDX processing V4L/DVB (13910): cx18: Fix set indextable command to properly select I/P/B index entries V4L/DVB (13913): saa7127: Add support for generating SECAM output for the SAA712[89] chips V4L/DVB: cx25840, v4l2-subdev, ivtv, pvrusb2: Fix ivtv/cx25840 tinny audio V4L/DVB: ivtv: Adjust msleep() delays used to prevent tinny audio and PCI bus hang V4L/DVB: cx18-alsa: Initial non-working cx18-alsa files V4L/DVB: cx18-alsa: Add non-working cx18-alsa-pcm.[ch] files to avoid data loss V4L/DVB: cx18: Rename snd_cx18_mixer_lock to snd_cx18_lock and increase visibility V4L/DVB: cx18: Add missing serialization locking to cx18-alsa V4L/DVB: cx18: Fix memory leak in cx18-alsa starting of PCM captures V4L/DVB: cx18: Increment driver version for the addition of cx18-alsa and fixes V4L/DVB: cx18: Add missing serialization locks to cx18-dvb V4L/DVB: ivtv: Fix ivtv_api_get_data() to avoid unneeded IO during IRQ handling V4L/DVB: tuner-types: Add Sony BTF-Pxn01Z tuner type used on GigaPocket cards V4L/DVB: ivtv: Tweak Sony GigaPocket Kikyou card entry based on experiments Antoine Jacquet (1): V4L/DVB (13885): zr364xx: fix support for Aiptek DV T300 Antonio Ospite (3): V4L/DVB: gspca - ov534: Allow enumerating supported framerates V4L/DVB: gspca - ov534: Fix end of frame handling pxa_camera: remove init() callback Antti Palosaari (5): V4L/DVB: af9015: support for DigitalNow TinyTwin v2 V4L/DVB: af9015: support for Leadtek WinFast DTV2000DS V4L/DVB: af9015: A-Link DTU(m) remote autodetection V4L/DVB: af9015: MYGICTV U718 remote autodetection V4L/DVB: af901x: inform NXP TDA18218 tuner as know but not supported Arnaud Patard (1): V4L/DVB: Fix VIDIOC_QBUF compat ioctl32 Arvo Järve (1): V4L/DVB (13989): [TDA8261] Fix TDA8261 I2C read bug Baruch Siach (1): V4L/DVB: v4l: soc_camera: fix bound checking of mbus_fmt[] index Ben Hutchings (1): V4L/DVB: dabusb: declare MODULE_FIRMWARE Catimimi (1):
[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:Fri Feb 26 19:00:20 CET 2010 path:http://www.linuxtv.org/hg/v4l-dvb changeset: 14319:37581bb7e6f1 gcc version: i686-linux-gcc (GCC) 4.4.3 host hardware:x86_64 host os: 2.6.32.5 linux-2.6.32.6-armv5: OK linux-2.6.33-armv5: OK linux-2.6.32.6-armv5-davinci: WARNINGS linux-2.6.33-armv5-davinci: WARNINGS linux-2.6.32.6-armv5-dm365: ERRORS linux-2.6.33-armv5-dm365: ERRORS linux-2.6.32.6-armv5-ixp: OK linux-2.6.33-armv5-ixp: OK linux-2.6.32.6-armv5-omap2: OK linux-2.6.33-armv5-omap2: OK linux-2.6.22.19-i686: OK linux-2.6.23.17-i686: OK linux-2.6.24.7-i686: OK linux-2.6.25.20-i686: OK linux-2.6.26.8-i686: OK linux-2.6.27.44-i686: OK linux-2.6.28.10-i686: OK linux-2.6.29.1-i686: WARNINGS linux-2.6.30.10-i686: WARNINGS linux-2.6.31.12-i686: OK linux-2.6.32.6-i686: OK linux-2.6.33-i686: OK linux-2.6.32.6-m32r: OK linux-2.6.33-m32r: OK linux-2.6.32.6-mips: OK linux-2.6.33-mips: OK linux-2.6.32.6-powerpc64: WARNINGS linux-2.6.33-powerpc64: WARNINGS linux-2.6.22.19-x86_64: OK linux-2.6.23.17-x86_64: OK linux-2.6.24.7-x86_64: OK linux-2.6.25.20-x86_64: OK linux-2.6.26.8-x86_64: OK linux-2.6.27.44-x86_64: OK linux-2.6.28.10-x86_64: OK linux-2.6.29.1-x86_64: WARNINGS linux-2.6.30.10-x86_64: WARNINGS linux-2.6.31.12-x86_64: OK linux-2.6.32.6-x86_64: OK linux-2.6.33-x86_64: OK spec: OK sparse (linux-2.6.33): ERRORS linux-2.6.16.62-i686: ERRORS linux-2.6.17.14-i686: ERRORS linux-2.6.18.8-i686: OK linux-2.6.19.7-i686: OK linux-2.6.20.21-i686: OK linux-2.6.21.7-i686: OK linux-2.6.16.62-x86_64: ERRORS linux-2.6.17.14-x86_64: ERRORS linux-2.6.18.8-x86_64: OK linux-2.6.19.7-x86_64: OK linux-2.6.20.21-x86_64: OK linux-2.6.21.7-x86_64: OK Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Friday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Friday.tar.bz2 The V4L-DVB specification from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/media.html -- 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
[bttv] Auto detection for Provideo PV- series capture cards
I'm writing concerning the Provideo PV-149, PV-155, PV-981-* and PV-183-*. These cards, for the most part, are drop in and 'just work' with the bttv driver. However the PV-149 / PV-981 / PV-155 is auto detected as the Provideo PV-150, which is not a valid Provideo part number. The PV-183-* is detected as 'Unknown / Generic' and requires setting card=98,98,98,98,98,98,98,98. I believe the text concerning 'detected: Provideo PV150A-1' should be changed to 'detected: Provideo PV149 / PV981 / PV155' I've attached outputs from the bttv kernel logs for the PV-149 / PV-981 / PV-183. If there's something I'm missing please let me know and I'll get it for you. Just for reference the PV-149 / PV-981 / PV-183 series cards are: PV-149 - 4 port, 4 BT878a chips - no forced card setting required PV-155 - 16 port, 4 BT878a chips - card=77,77,77,77 (Shares the same board and PCI ID / subsystem as the PV-149) PV-183-8: 8 port, 8 BT878a chips - card=98,98,98,98,98,98,98,98 PV-183-16: 16 port, 8 BT878a chips - card=98,98,98,98,98,98,98,98 (Shares the same board and PCI ID / subsystem as the PV-183-8) PV-981-4: 4 port, 4 BT878a chips - no modprobe setting required PV-981-8: 8 port, 4 BT878a chips - no modprobe setting required (Shares the same board as the PV-981-4) PV-981-16: 16 port, 4 BT878a chips - card=98,98,98,98,98,98,98,98 (Shares the same board and PCI ID / subsystem as the PV-981-4) Thanks! -- Curtis Hall (c...@bluecherry.net) Bluecherry - www.bluecherry.net (877) 418-3391 x 201 [ 10.287287] bttv: driver version 0.9.17 loaded [ 10.287289] bttv: using 8 buffers with 2080k (520 pages) each for capture [ 10.287336] bttv: Bt8xx card found (0). [ 10.287345] bttv :04:08.0: PCI INT A - GSI 22 (level, low) - IRQ 22 [ 10.287354] bttv0: Bt878 (rev 17) at :04:08.0, irq: 22, latency: 64, mmio: 0xfdfff000 [ 10.287367] bttv0: detected: Provideo PV150A-1 [card=98], PCI subsystem ID is aa00:1460 [ 10.287369] bttv0: using: ProVideo PV150 [card=98,autodetected] [ 10.287392] bttv0: gpio: en=, out= in=00ff [init] [ 10.287810] bttv0: tuner absent [ 10.287893] bttv0: registered device video0 [ 10.287925] bttv0: registered device vbi0 [ 10.287946] bttv0: PLL: 28636363 = 35468950 ..6hda_codec: Unknown model for ALC662, trying auto-probe from BIOS... [ 10.316095] ok [ 10.316109] bttv: Bt8xx card found (1). [ 10.316125] bttv :04:09.0: PCI INT A - GSI 23 (level, low) - IRQ 23 [ 10.316137] bttv1: Bt878 (rev 17) at :04:09.0, irq: 23, latency: 64, mmio: 0xfdffd000 [ 10.316190] bttv1: detected: Provideo PV150A-2 [card=98], PCI subsystem ID is aa01:1461 [ 10.316193] bttv1: using: ProVideo PV150 [card=98,autodetected] [ 10.316219] bttv1: gpio: en=, out= in=00ff [init] [ 10.316272] bttv1: tuner absent [ 10.316320] bttv1: registered device video1 [ 10.316354] bttv1: registered device vbi1 [ 10.316375] bttv1: PLL: 28636363 = 35468950 .. ok [ 10.348096] bttv: Bt8xx card found (2). [ 10.348112] bttv :04:0a.0: PCI INT A - GSI 20 (level, low) - IRQ 20 [ 10.348123] bttv2: Bt878 (rev 17) at :04:0a.0, irq: 20, latency: 64, mmio: 0xfdffb000 [ 10.348160] bttv2: detected: Provideo PV150A-3 [card=98], PCI subsystem ID is aa02:1462 [ 10.348163] bttv2: using: ProVideo PV150 [card=98,autodetected] [ 10.348197] bttv2: gpio: en=, out= in=00ff [init] [ 10.348258] bttv2: tuner absent [ 10.348302] bttv2: registered device video2 [ 10.348337] bttv2: registered device vbi2 [ 10.348360] bttv2: PLL: 28636363 = 35468950 .. ok [ 10.380043] bttv: Bt8xx card found (3). [ 10.380058] bttv :04:0b.0: PCI INT A - GSI 21 (level, low) - IRQ 21 [ 10.380069] bttv3: Bt878 (rev 17) at :04:0b.0, irq: 21, latency: 64, mmio: 0xfdff9000 [ 10.380128] bttv3: detected: Provideo PV150A-4 [card=98], PCI subsystem ID is aa03:1463 [ 10.380131] bttv3: using: ProVideo PV150 [card=98,autodetected] [ 10.380157] bttv3: gpio: en=, out= in=00ff [init] [ 10.380217] bttv3: tuner absent [ 10.380267] bttv3: registered device video3 [ 10.380299] bttv3: registered device vbi3 [ 10.380319] bttv3: PLL: 28636363 = 35468950 .. ok [ 13.438351] bttv :02:04.0: PCI INT A - Link[APC2] - GSI 17 (level, low) - IRQ 17 [ 13.438363] bttv0: Bt878 (rev 17) at :02:04.0, irq: 17, latency: 32, mmio: 0xd510 [ 13.438412] bttv0: subsystem: 1830:1540 (UNKNOWN) [ 13.438414] please mail id, board name and the correct card= insmod option to video4linux-l...@redhat.com [ 13.438416] bttv0: using: *** UNKNOWN/GENERIC *** [card=0,autodetected] [ 13.438453] bttv0: gpio: en=, out= in=00ff [init] [ 13.474501] bttv0: tuner type unset [ 13.474503] bttv0: i2c: checking for MSP34xx @ 0x80... not found [ 13.476477] bttv0: i2c: checking for TDA9875 @ 0xb0... not found [ 13.477175] bttv0: i2c: checking for TDA7432 @ 0x8a... not found [ 13.477963]
Re: [bttv] Auto detection for Provideo PV- series capture cards
On Fri, Feb 26, 2010 at 3:25 PM, Curtis Hall c...@bluecherry.net wrote: I'm writing concerning the Provideo PV-149, PV-155, PV-981-* and PV-183-*. These cards, for the most part, are drop in and 'just work' with the bttv driver. However the PV-149 / PV-981 / PV-155 is auto detected as the Provideo PV-150, which is not a valid Provideo part number. The PV-183-* is detected as 'Unknown / Generic' and requires setting card=98,98,98,98,98,98,98,98. Did you see the reply from Andy Walls over in video4linux? He provided a patch, and asked for a bunch of additional information he needs in order to get the boards working properly. 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: [bttv] Auto detection for Provideo PV- series capture cards
Devin, I saw his email and I've been in private communication between him and Provideo trying to get the information he needs. However his request was for the PV-947D against the IVTV driver. These cards are using the bttv driver. I was hoping a bttv maintainer could look at the information I posted first to make sure this information wasn't duplicated. Thanks! -- -- Curtis Hall (c...@bluecherry.net) Bluecherry - www.bluecherry.net (877) 418-3391 x 201 -- 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: [bttv] Auto detection for Provideo PV- series capture cards
On Fri, Feb 26, 2010 at 3:48 PM, Curtis Hall c...@bluecherry.net wrote: Devin, I saw his email and I've been in private communication between him and Provideo trying to get the information he needs. However his request was for the PV-947D against the IVTV driver. These cards are using the bttv driver. I was hoping a bttv maintainer could look at the information I posted first to make sure this information wasn't duplicated. Ah, my mistake. I didn't notice that Andy only replied regarding a board unrelated to your original post. Cheers, 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: [bttv] Auto detection for Provideo PV- series capture cards
Let's go by parts: Curtis Hall wrote: I'm writing concerning the Provideo PV-149, PV-155, PV-981-* and PV-183-*. These cards, for the most part, are drop in and 'just work' with the bttv driver. However the PV-149 / PV-981 / PV-155 is auto detected as the Provideo PV-150, which is not a valid Provideo part number. From your logs, both PV-149 and PV-981 shares the same PCI ID = aa00:1460, which is the same ID for PV-150. The entry for PV-150 were added at -hg tree by this changeset: changeset: 784:3c31d7e0b4bc user:Gerd Knorr date:Sun Feb 22 01:59:34 2004 + summary: Initial revision Probably, this is a discontinued model, but I don't know for sure. The PV-183-* is detected as 'Unknown / Generic' and requires setting card=98,98,98,98,98,98,98,98. This one is easy: [ 13.438412] bttv0: subsystem: 1830:1540 (UNKNOWN) As this PCI ID is not known, it is just a matter of associating the PV-183 ID's with card 98. I believe the text concerning 'detected: Provideo PV150A-1' should be changed to 'detected: Provideo PV149 / PV981 / PV155' Seems ok to me for PV-981. I've attached outputs from the bttv kernel logs for the PV-149 / PV-981 / PV-183. If there's something I'm missing please let me know and I'll get it for you. Just for reference the PV-149 / PV-981 / PV-183 series cards are: PV-149 - 4 port, 4 BT878a chips - no forced card setting required PV-155 - 16 port, 4 BT878a chips - card=77,77,77,77 (Shares the same board and PCI ID / subsystem as the PV-149) Hmm... PV-155 shares the same PCI ID as PV-149, but require a different entry, then we shouldn't add it to the PV-150 autodetection code. The better would be to check with the manufacturer if is there a way to detect between those two boards (maybe reading eeprom?). PV-183-8: 8 port, 8 BT878a chips - card=98,98,98,98,98,98,98,98 PV-183-16: 16 port, 8 BT878a chips - card=98,98,98,98,98,98,98,98 (Shares the same board and PCI ID / subsystem as the PV-183-8) PV-981-4: 4 port, 4 BT878a chips - no modprobe setting required PV-981-8: 8 port, 4 BT878a chips - no modprobe setting required (Shares the same board as the PV-981-4) PV-981-16: 16 port, 4 BT878a chips - card=98,98,98,98,98,98,98,98 (Shares the same board and PCI ID / subsystem as the PV-981-4) Why do you need the card= parameter, if it shares the same subsystem ID as the other PV-981 models? Thanks! -- Curtis Hall (c...@bluecherry.net) Bluecherry - www.bluecherry.net (877) 418-3391 x 201 -- 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: [bttv] Auto detection for Provideo PV- series capture cards
Mauro Carvalho Chehab wrote: Let's go by parts: The entry for PV-150 were added at -hg tree by this changeset: changeset: 784:3c31d7e0b4bc user:Gerd Knorr date:Sun Feb 22 01:59:34 2004 + summary: Initial revision Probably, this is a discontinued model, but I don't know for sure. We have been Provideo's US distributor since late 2004 and I've not heard of a PV-150 part number, and isn't not a current part number. This one is easy: [ 13.438412] bttv0: subsystem: 1830:1540 (UNKNOWN) As this PCI ID is not known, it is just a matter of associating the PV-183 ID's with card 98. I figured, thanks Just for reference the PV-149 / PV-981 / PV-183 series cards are: PV-149 - 4 port, 4 BT878a chips - no forced card setting required PV-155 - 16 port, 4 BT878a chips - card=77,77,77,77 (Shares the same board and PCI ID / subsystem as the PV-149) Hmm... PV-155 shares the same PCI ID as PV-149, but require a different entry, then we shouldn't add it to the PV-150 autodetection code. Okay. You can easily access four ports on the PV-155 / PV-981, but to access the sub (/dev/videoX,1-3) channels you need to add the modprobe line. The better would be to check with the manufacturer if is there a way to detect between those two boards (maybe reading eeprom?). I can find out, but getting technical data from Provideo can be more painful then pulling teeth. Why do you need the card= parameter, if it shares the same subsystem ID as the other PV-981 models? I think I explained that about with the sub channels, if I'm missing something let me know. Thanks! -- -- Curtis Hall (c...@bluecherry.net) Bluecherry - www.bluecherry.net (877) 418-3391 x 201 -- 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: af9015: tuner id:179 not supported, please report!
Using the previous patch, the compiler will complain about a missing
file (tda18218.h). Please use this updated version of the patch, also
made by Nikola.
Have fun with it, it's working fine here!
Regards, Bert
On Wed, Feb 24, 2010 at 22:42, Bert Massop bert.mas...@gmail.com wrote:
This is a forward of the original email from Nikola Pajkovsky. Just
for the records, so it is on the list.
This solves the problem of the tuner id:179 not supported error, when
loading the AF9015 driver.
Thank you, Nikola!
Regards,
Bert Massop
-- Forwarded message --
From: Nikola Pajkovsky npajk...@redhat.com
Date: Wed, Feb 24, 2010 at 11:54
Subject: Re: af901x: NXP TDA18218
To: Antti Palosaari cr...@iki.fi
Cc: jan.sund...@aland.net, bert.mas...@gmail.com,
mkru...@kernellabs.com, dheitmuel...@kernellabs.com
Hello,
here is my solution, I can watch Vancouver right now :). I don't
look at the patch if there is some mistake(no time watch Vancouver),
but I will when I will have some free time.
Attached patch apply against this souce (hg clone
http://linuxtv.org/hg/~anttip/af9015/).
Firmware:
wget http://jusst.de/manu/fw/AFA/dvb-usb-af9015.fw_a-link
sudo mv dvb-usb-af9015.fw_a-link /lib/firmware/dvb-usb-af9015.fw
Have a nice day ;)
On 23.2.2010 14:02, Antti Palosaari wrote:
Hello,
I just got info from one user about this driver, looks like Terratec have
driver.
http://forum.ubuntuusers.de/topic/probleme-beim-installieren-terratec-cinergy-t/3/?highlight=terratec+cinergy+t+stick
Antti
Nikola Pajkovsky wrote:
Hello,
is any chance that will be support for TDA182118?
Regards,
--
Nikola
diff -r 0f41fd7df85d linux/drivers/media/common/tuners/Kconfig
--- a/linux/drivers/media/common/tuners/Kconfig Thu Feb 11 02:33:12 2010 +0200
+++ b/linux/drivers/media/common/tuners/Kconfig Thu Feb 25 17:21:11 2010 +0100
@@ -179,4 +179,11 @@
help
A driver for the silicon tuner MAX2165 from Maxim.
+config MEDIA_TUNER_TDA18218
+ tristate NXP TDA18218 silicon tuner
+ depends on VIDEO_MEDIA I2C
+ default m if MEDIA_TUNER_CUSTOMISE
+ help
+ A driver for the silicon tuner TDA18218 from NXP.
+
endif # MEDIA_TUNER_CUSTOMISE
diff -r 0f41fd7df85d linux/drivers/media/common/tuners/Makefile
--- a/linux/drivers/media/common/tuners/Makefile Thu Feb 11 02:33:12 2010 +0200
+++ b/linux/drivers/media/common/tuners/Makefile Thu Feb 25 17:21:11 2010 +0100
@@ -24,6 +24,7 @@
obj-$(CONFIG_MEDIA_TUNER_MXL5007T) += mxl5007t.o
obj-$(CONFIG_MEDIA_TUNER_MC44S803) += mc44s803.o
obj-$(CONFIG_MEDIA_TUNER_MAX2165) += max2165.o
+obj-$(CONFIG_MEDIA_TUNER_TDA18218) += tda18218.o
EXTRA_CFLAGS += -Idrivers/media/dvb/dvb-core
EXTRA_CFLAGS += -Idrivers/media/dvb/frontends
diff -r 0f41fd7df85d linux/drivers/media/common/tuners/tda18218.c
--- /dev/null Thu Jan 01 00:00:00 1970 +
+++ b/linux/drivers/media/common/tuners/tda18218.c Thu Feb 25 17:21:11 2010 +0100
@@ -0,0 +1,471 @@
+/*
+ * Driver for NXP TDA18218 silicon tuner
+ *
+ * Copyright (C) 2010 Lauris Ding ld...@gmx.de
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
+ */
+#include tda18218.h
+#include compat.h
+#include tda18218_priv.h
+
+static int tda18218_write_reg(struct dvb_frontend *fe, u8 reg, u8 val)
+{
+ struct tda18218_priv *priv = fe-tuner_priv;
+ u8 buf[2] = { reg, val };
+ struct i2c_msg msg = { .addr = priv-cfg-i2c_address, .flags = 0,
+ .buf = buf, .len = 2 };
+ int ret;
+
+ if (fe-ops.i2c_gate_ctrl)
+ fe-ops.i2c_gate_ctrl(fe, 1);
+ /* write register */
+ ret = i2c_transfer(priv-i2c, msg, 1);
+ if (fe-ops.i2c_gate_ctrl)
+ fe-ops.i2c_gate_ctrl(fe, 0);
+
+ if (ret != 1)
+ printk(KERN_WARNING I2C write failed ret: %d reg: %02x\n, ret, reg);
+
+ return (ret == 1 ? 0 : ret);
+}
+
+static int tda18218_write_regs(struct dvb_frontend *fe, u8 reg,
+ u8 *val, u8 len)
+{
+ struct tda18218_priv *priv = fe-tuner_priv;
+ u8 buf[1+len];
+ struct i2c_msg msg = {
+ .addr = priv-cfg-i2c_address,
+ .flags = 0,
+ .len = sizeof(buf),
+ .buf = buf };
+
+ int ret;
+
+ buf[0] = reg;
+ memcpy(buf[1], val, len);
+
+ if (fe-ops.i2c_gate_ctrl)
+ fe-ops.i2c_gate_ctrl(fe, 1);
+ ret = i2c_transfer(priv-i2c, msg, 1);
+ if (fe-ops.i2c_gate_ctrl)
+ fe-ops.i2c_gate_ctrl(fe, 1);
+
+ if (ret != 1)
+ printk(KERN_WARNING I2C write failed ret: %d reg: %02x len:
Re: af901x: NXP TDA18218
Using the previous patch, the compiler will complain about a missing
file (tda18218.h). Please use this updated version of the patch, also
made by Nikola.
Have fun with it, it's working fine here!
Regards, Bert
On Wed, Feb 24, 2010 at 22:41, Bert Massop bert.mas...@gmail.com wrote:
This is a forward of the original email from Nikola Pajkovsky. Just
for the records, so it is on the list.
This solves the problem of the tuner id:179 not supported error, when
loading the AF9015 driver.
Thank you, Nikola!
Regards,
Bert Massop
-- Forwarded message --
From: Nikola Pajkovsky npajk...@redhat.com
Date: Wed, Feb 24, 2010 at 11:54
Subject: Re: af901x: NXP TDA18218
To: Antti Palosaari cr...@iki.fi
Cc: jan.sund...@aland.net, bert.mas...@gmail.com,
mkru...@kernellabs.com, dheitmuel...@kernellabs.com
Hello,
here is my solution, I can watch Vancouver right now :). I don't
look at the patch if there is some mistake(no time watch Vancouver),
but I will when I will have some free time.
Attached patch apply against this souce (hg clone
http://linuxtv.org/hg/~anttip/af9015/).
Firmware:
wget http://jusst.de/manu/fw/AFA/dvb-usb-af9015.fw_a-link
sudo mv dvb-usb-af9015.fw_a-link /lib/firmware/dvb-usb-af9015.fw
Have a nice day ;)
On 23.2.2010 14:02, Antti Palosaari wrote:
Hello,
I just got info from one user about this driver, looks like Terratec have
driver.
http://forum.ubuntuusers.de/topic/probleme-beim-installieren-terratec-cinergy-t/3/?highlight=terratec+cinergy+t+stick
Antti
Nikola Pajkovsky wrote:
Hello,
is any chance that will be support for TDA182118?
Regards,
--
Nikola
diff -r 0f41fd7df85d linux/drivers/media/common/tuners/Kconfig
--- a/linux/drivers/media/common/tuners/Kconfig Thu Feb 11 02:33:12 2010 +0200
+++ b/linux/drivers/media/common/tuners/Kconfig Thu Feb 25 17:21:11 2010 +0100
@@ -179,4 +179,11 @@
help
A driver for the silicon tuner MAX2165 from Maxim.
+config MEDIA_TUNER_TDA18218
+ tristate NXP TDA18218 silicon tuner
+ depends on VIDEO_MEDIA I2C
+ default m if MEDIA_TUNER_CUSTOMISE
+ help
+ A driver for the silicon tuner TDA18218 from NXP.
+
endif # MEDIA_TUNER_CUSTOMISE
diff -r 0f41fd7df85d linux/drivers/media/common/tuners/Makefile
--- a/linux/drivers/media/common/tuners/Makefile Thu Feb 11 02:33:12 2010 +0200
+++ b/linux/drivers/media/common/tuners/Makefile Thu Feb 25 17:21:11 2010 +0100
@@ -24,6 +24,7 @@
obj-$(CONFIG_MEDIA_TUNER_MXL5007T) += mxl5007t.o
obj-$(CONFIG_MEDIA_TUNER_MC44S803) += mc44s803.o
obj-$(CONFIG_MEDIA_TUNER_MAX2165) += max2165.o
+obj-$(CONFIG_MEDIA_TUNER_TDA18218) += tda18218.o
EXTRA_CFLAGS += -Idrivers/media/dvb/dvb-core
EXTRA_CFLAGS += -Idrivers/media/dvb/frontends
diff -r 0f41fd7df85d linux/drivers/media/common/tuners/tda18218.c
--- /dev/null Thu Jan 01 00:00:00 1970 +
+++ b/linux/drivers/media/common/tuners/tda18218.c Thu Feb 25 17:21:11 2010 +0100
@@ -0,0 +1,471 @@
+/*
+ * Driver for NXP TDA18218 silicon tuner
+ *
+ * Copyright (C) 2010 Lauris Ding ld...@gmx.de
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
+ */
+#include tda18218.h
+#include compat.h
+#include tda18218_priv.h
+
+static int tda18218_write_reg(struct dvb_frontend *fe, u8 reg, u8 val)
+{
+ struct tda18218_priv *priv = fe-tuner_priv;
+ u8 buf[2] = { reg, val };
+ struct i2c_msg msg = { .addr = priv-cfg-i2c_address, .flags = 0,
+ .buf = buf, .len = 2 };
+ int ret;
+
+ if (fe-ops.i2c_gate_ctrl)
+ fe-ops.i2c_gate_ctrl(fe, 1);
+ /* write register */
+ ret = i2c_transfer(priv-i2c, msg, 1);
+ if (fe-ops.i2c_gate_ctrl)
+ fe-ops.i2c_gate_ctrl(fe, 0);
+
+ if (ret != 1)
+ printk(KERN_WARNING I2C write failed ret: %d reg: %02x\n, ret, reg);
+
+ return (ret == 1 ? 0 : ret);
+}
+
+static int tda18218_write_regs(struct dvb_frontend *fe, u8 reg,
+ u8 *val, u8 len)
+{
+ struct tda18218_priv *priv = fe-tuner_priv;
+ u8 buf[1+len];
+ struct i2c_msg msg = {
+ .addr = priv-cfg-i2c_address,
+ .flags = 0,
+ .len = sizeof(buf),
+ .buf = buf };
+
+ int ret;
+
+ buf[0] = reg;
+ memcpy(buf[1], val, len);
+
+ if (fe-ops.i2c_gate_ctrl)
+ fe-ops.i2c_gate_ctrl(fe, 1);
+ ret = i2c_transfer(priv-i2c, msg, 1);
+ if (fe-ops.i2c_gate_ctrl)
+ fe-ops.i2c_gate_ctrl(fe, 1);
+
+ if (ret != 1)
+ printk(KERN_WARNING I2C write failed ret: %d reg: %02x len: %d\n, ret, reg,
Re: [BUG] TDA10086 : Creatix CTX929_V.1 : TS continuity errors with good RF signal input
Looks like fixed by linux 2.6.33 just in time, BIG Thank You guys ;-) Even at higher BER: Current parameters: Frequency: 1945.320 MHz Inversion: OFF Symbol rate: 22.000154 MSym/s FEC: FEC 5/6 cycle: 1 d_time: 0.001 s Sig: 18504 SNR: 39578 BER: 168 UBLK: 0 Stat: 0x1f [SIG CARR VIT SYNC LOCK ] cycle: 2 d_time: 0.073 s Sig: 18247 SNR: 39578 BER: 225 UBLK: 0 Stat: 0x1f [SIG CARR VIT SYNC LOCK ] cycle: 3 d_time: 0.079 s Sig: 18504 SNR: 37779 BER: 140 UBLK: 0 Stat: 0x1f [SIG CARR VIT SYNC LOCK ] cycle: 4 d_time: 0.072 s Sig: 18504 SNR: 39835 BER: 198 UBLK: 0 Stat: 0x1f [SIG CARR VIT SYNC LOCK ] cycle: 5 d_time: 0.071 s Sig: 18504 SNR: 39835 BER: 221 UBLK: 0 Stat: 0x1f [SIG CARR VIT SYNC LOCK ] cycle: 6 d_time: 0.072 s Sig: 18247 SNR: 39578 BER: 249 UBLK: 0 Stat: 0x1f [SIG CARR VIT SYNC LOCK ] cycle: 7 d_time: 0.072 s Sig: 18504 SNR: 39835 BER: 191 UBLK: 0 Stat: 0x1f [SIG CARR VIT SYNC LOCK ] cycle: 8 d_time: 0.072 s Sig: 18504 SNR: 39578 BER: 185 UBLK: 0 Stat: 0x1f [SIG CARR VIT SYNC LOCK ] cycle: 9 d_time: 0.072 s Sig: 18761 SNR: 39578 BER: 137 UBLK: 0 Stat: 0x1f [SIG CARR VIT SYNC LOCK ] I'll report if issue reoccurs and try to finetune crystal based tuner/demod parameters, then. y tom thomas schorpp wrote: Hi, Issue is already confirmed here: http://www.vdr-portal.de/board/thread.php?threadid=93268 Linux 2.6.32.8, 80cm dish. Do we have any Tuner/Decoder optimization points in the FE code? This is not OK: lspci -s 00:08.0 -v 00:08.0 Multimedia controller: Philips Semiconductors SAA7134/SAA7135HL Video Broadcast Decoder (rev 01) Subsystem: Creatix Polymedia GmbH Device 0005 Flags: bus master, medium devsel, latency 32, IRQ 19 Memory at fbeff400 (32-bit, non-prefetchable) [size=1K] Capabilities: [40] Power Management version 1 Kernel driver in use: saa7134 grep cTS2PES /var/log/syslog Feb 26 13:46:59 tom1 vdr: [4082] cTS2PES got 7 TS errors, 113 TS continuity errors Feb 26 13:46:59 tom1 vdr: [4082] cTS2PES got 0 TS errors, 29 TS continuity errors Feb 26 13:47:52 tom1 vdr: [4082] cTS2PES got 17 TS errors, 5 TS continuity errors Feb 26 14:03:03 tom1 vdr: [4082] cTS2PES got 2 TS errors, 136 TS continuity errors Feb 26 14:03:03 tom1 vdr: [4082] cTS2PES got 0 TS errors, 32 TS continuity errors Feb 26 14:41:42 tom1 vdr: [4082] cTS2PES got 1 TS errors, 853 TS continuity errors Feb 26 14:41:42 tom1 vdr: [4082] cTS2PES got 0 TS errors, 194 TS continuity errors Feb 26 14:52:58 tom1 vdr: [4082] cTS2PES got 2 TS errors, 196 TS continuity errors Feb 26 14:52:58 tom1 vdr: [4082] cTS2PES got 0 TS errors, 52 TS continuity errors Feb 26 14:59:34 tom1 vdr: [4082] cTS2PES got 0 TS errors, 137 TS continuity errors Feb 26 14:59:34 tom1 vdr: [4082] cTS2PES got 0 TS errors, 43 TS continuity errors Feb 26 14:59:34 tom1 vdr: [4082] cTS2PES got 0 TS errors, 16 TS continuity errors Feb 26 14:59:34 tom1 vdr: [4082] cTS2PES got 0 TS errors, 57 TS continuity errors Feb 26 14:59:54 tom1 vdr: [4082] cTS2PES got 0 TS errors, 3 TS continuity errors Feb 26 14:59:54 tom1 vdr: [4082] cTS2PES got 0 TS errors, 2 TS continuity errors dvbsnoop -s feinfo -adapter 2 Current parameters: Frequency: 1236.253 MHz Inversion: OFF Symbol rate: 31.794142 MSym/s FEC: FEC 3/4 dvbsnoop -s signal -adapter 2 cycle: 1 d_time: 0.001 s Sig: 26471 SNR: 49858 BER: 0 UBLK: 0 Stat: 0x1f [SIG CARR VIT SYNC LOCK ] cycle: 2 d_time: 0.072 s Sig: 26471 SNR: 50115 BER: 0 UBLK: 0 Stat: 0x1f [SIG CARR VIT SYNC LOCK ] cycle: 3 d_time: 0.072 s Sig: 26728 SNR: 50115 BER: 0 UBLK: 0 Stat: 0x1f [SIG CARR VIT SYNC LOCK ] cycle: 4 d_time: 0.088 s Sig: 26728 SNR: 50115 BER: 0 UBLK: 0 Stat: 0x1f [SIG CARR VIT SYNC LOCK ] cycle: 5 d_time: 0.072 s Sig: 26471 SNR: 50115 BER: 0 UBLK: 0 Stat: 0x1f [SIG CARR VIT SYNC LOCK ] cycle: 6 d_time: 0.072 s Sig: 26471 SNR: 50115 BER: 0 UBLK: 0 Stat: 0x1f [SIG CARR VIT SYNC LOCK ] cycle: 7 d_time: 0.072 s Sig: 26471 SNR: 50115 BER: 0 UBLK: 0 Stat: 0x1f [SIG CARR VIT SYNC LOCK ] cycle: 8 d_time: 0.072 s Sig: 26471 SNR: 50115 BER: 0 UBLK: 0 Stat: 0x1f [SIG CARR VIT SYNC LOCK ] Low signal strength values are AGC-loop misinterpretation as usual? y tom -- 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
smatch on V4L/DVB updates
On Fri, Feb 26, 2010 at 04:43:05PM -0300, Mauro Carvalho Chehab wrote: The following changes since commit 60b341b778cc2929df16c0a504c91621b3c6a4ad: Linus Torvalds (1): Linux 2.6.33 are available in the git repository at: ssh://master.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-2.6.git v4l_for_linus These changes introduce some smatch warnings. How I generated this list was I made a list of the C files that were changed: for i in $(cat files.retest) ; do kchecker $i ; done | tee retest.out /path/to/smatch_scripts/new_bugs.sh retest.out warns.txt | tee err-list (I had created warns.txt in a previous nightly compile) Then I went through the list and manually seperated out the actual bugs from the false positives using smatch_scripts/summarize_errs.sh. Mostly it's just doing DMA on the stack (see Documentation/DMA-mapping.txt). Eventually, the goal is to start testing linux-next using smatch but it could be a couple months yet because I'm going to be on the road for a while. regards, dan carpenter drivers/media/dvb/dvb-usb/az6027.c +1043 az6027_identify_state(6) error: doing dma on the stack (b) drivers/media/dvb/dvb-usb/dib0700_core.c +643 dib0700_rc_setup(12) error: doing dma on the stack (rc_setup) arch/mn10300/unit-asb2305/pci.c +294 pci_sanity_check(2) warn: 'bus' puts 612 bytes on stack arch/mn10300/unit-asb2305/pci.c +502 unit_pci_init(2) warn: 'bus' puts 612 bytes on stack drivers/media/dvb/dvb-usb/dib0700_devices.c +494 dib0700_rc_query(18) error: doing dma on the stack (key) drivers/media/dvb/frontends/stv090x.c +4553 stv090x_attach(37) error: potential null dereference 'state-internal'. (kmalloc returns null) drivers/media/video/davinci/dm355_ccdc.c +332 ccdc_set_params(2) warn: 'ccdc_raw_params' puts 584 bytes on stack drivers/media/video/davinci/vpfe_capture.c +1988 vpfe_probe(200) warn: 'mutex:ccdc_lock' is sometimes locked here and sometimes unlocked. drivers/media/video/em28xx/em28xx-video.c +287 em28xx_copy_vbi(10) warn: variable dereferenced before check 'dev' drivers/media/video/sh_mobile_ceu_camera.c +356 sh_mobile_ceu_videobuf_prepare(29) warn: variable dereferenced before check 'icd-current_fmt' drivers/media/video/sh_mobile_ceu_camera.c +1032 client_s_crop(9) warn: variable dereferenced before check 'sd' drivers/media/video/tlg2300/pd-main.c +83 send_set_req(18) error: doing dma on the stack (data) drivers/media/video/tlg2300/pd-main.c +123 send_get_req(18) error: doing dma on the stack (data) drivers/media/video/uvc/uvc_ctrl.c +1292 uvc_ctrl_add_ctrl(51) error: doing dma on the stack (inf) drivers/media/video/uvc/uvc_v4l2.c +688 uvc_v4l2_do_ioctl(207) error: doing dma on the stack (input) -- 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: [BUG] TDA10086 : Creatix CTX929_V.1 : TS continuity errors with good RF signal input
Hi Thomas, Am Samstag, den 27.02.2010, 00:34 +0100 schrieb thomas schorpp: Looks like fixed by linux 2.6.33 just in time, BIG Thank You guys ;-) Even at higher BER: Current parameters: Frequency: 1945.320 MHz Inversion: OFF Symbol rate: 22.000154 MSym/s FEC: FEC 5/6 cycle: 1 d_time: 0.001 s Sig: 18504 SNR: 39578 BER: 168 UBLK: 0 Stat: 0x1f [SIG CARR VIT SYNC LOCK ] cycle: 2 d_time: 0.073 s Sig: 18247 SNR: 39578 BER: 225 UBLK: 0 Stat: 0x1f [SIG CARR VIT SYNC LOCK ] cycle: 3 d_time: 0.079 s Sig: 18504 SNR: 37779 BER: 140 UBLK: 0 Stat: 0x1f [SIG CARR VIT SYNC LOCK ] cycle: 4 d_time: 0.072 s Sig: 18504 SNR: 39835 BER: 198 UBLK: 0 Stat: 0x1f [SIG CARR VIT SYNC LOCK ] cycle: 5 d_time: 0.071 s Sig: 18504 SNR: 39835 BER: 221 UBLK: 0 Stat: 0x1f [SIG CARR VIT SYNC LOCK ] cycle: 6 d_time: 0.072 s Sig: 18247 SNR: 39578 BER: 249 UBLK: 0 Stat: 0x1f [SIG CARR VIT SYNC LOCK ] cycle: 7 d_time: 0.072 s Sig: 18504 SNR: 39835 BER: 191 UBLK: 0 Stat: 0x1f [SIG CARR VIT SYNC LOCK ] cycle: 8 d_time: 0.072 s Sig: 18504 SNR: 39578 BER: 185 UBLK: 0 Stat: 0x1f [SIG CARR VIT SYNC LOCK ] cycle: 9 d_time: 0.072 s Sig: 18761 SNR: 39578 BER: 137 UBLK: 0 Stat: 0x1f [SIG CARR VIT SYNC LOCK ] I'll report if issue reoccurs and try to finetune crystal based tuner/demod parameters, then. y tom I just started to try to look it up, but don't have ground yet. I reported unexpected bad performance under GNU/Linux for that card previously. Can you point me to the fix? Cheers, Hermann thomas schorpp wrote: Hi, Issue is already confirmed here: http://www.vdr-portal.de/board/thread.php?threadid=93268 Linux 2.6.32.8, 80cm dish. Do we have any Tuner/Decoder optimization points in the FE code? This is not OK: lspci -s 00:08.0 -v 00:08.0 Multimedia controller: Philips Semiconductors SAA7134/SAA7135HL Video Broadcast Decoder (rev 01) Subsystem: Creatix Polymedia GmbH Device 0005 Flags: bus master, medium devsel, latency 32, IRQ 19 Memory at fbeff400 (32-bit, non-prefetchable) [size=1K] Capabilities: [40] Power Management version 1 Kernel driver in use: saa7134 grep cTS2PES /var/log/syslog Feb 26 13:46:59 tom1 vdr: [4082] cTS2PES got 7 TS errors, 113 TS continuity errors Feb 26 13:46:59 tom1 vdr: [4082] cTS2PES got 0 TS errors, 29 TS continuity errors Feb 26 13:47:52 tom1 vdr: [4082] cTS2PES got 17 TS errors, 5 TS continuity errors Feb 26 14:03:03 tom1 vdr: [4082] cTS2PES got 2 TS errors, 136 TS continuity errors Feb 26 14:03:03 tom1 vdr: [4082] cTS2PES got 0 TS errors, 32 TS continuity errors Feb 26 14:41:42 tom1 vdr: [4082] cTS2PES got 1 TS errors, 853 TS continuity errors Feb 26 14:41:42 tom1 vdr: [4082] cTS2PES got 0 TS errors, 194 TS continuity errors Feb 26 14:52:58 tom1 vdr: [4082] cTS2PES got 2 TS errors, 196 TS continuity errors Feb 26 14:52:58 tom1 vdr: [4082] cTS2PES got 0 TS errors, 52 TS continuity errors Feb 26 14:59:34 tom1 vdr: [4082] cTS2PES got 0 TS errors, 137 TS continuity errors Feb 26 14:59:34 tom1 vdr: [4082] cTS2PES got 0 TS errors, 43 TS continuity errors Feb 26 14:59:34 tom1 vdr: [4082] cTS2PES got 0 TS errors, 16 TS continuity errors Feb 26 14:59:34 tom1 vdr: [4082] cTS2PES got 0 TS errors, 57 TS continuity errors Feb 26 14:59:54 tom1 vdr: [4082] cTS2PES got 0 TS errors, 3 TS continuity errors Feb 26 14:59:54 tom1 vdr: [4082] cTS2PES got 0 TS errors, 2 TS continuity errors dvbsnoop -s feinfo -adapter 2 Current parameters: Frequency: 1236.253 MHz Inversion: OFF Symbol rate: 31.794142 MSym/s FEC: FEC 3/4 dvbsnoop -s signal -adapter 2 cycle: 1 d_time: 0.001 s Sig: 26471 SNR: 49858 BER: 0 UBLK: 0 Stat: 0x1f [SIG CARR VIT SYNC LOCK ] cycle: 2 d_time: 0.072 s Sig: 26471 SNR: 50115 BER: 0 UBLK: 0 Stat: 0x1f [SIG CARR VIT SYNC LOCK ] cycle: 3 d_time: 0.072 s Sig: 26728 SNR: 50115 BER: 0 UBLK: 0 Stat: 0x1f [SIG CARR VIT SYNC LOCK ] cycle: 4 d_time: 0.088 s Sig: 26728 SNR: 50115 BER: 0 UBLK: 0 Stat: 0x1f [SIG CARR VIT SYNC LOCK ] cycle: 5 d_time: 0.072 s Sig: 26471 SNR: 50115 BER: 0 UBLK: 0 Stat: 0x1f [SIG CARR VIT SYNC LOCK ] cycle: 6 d_time: 0.072 s Sig: 26471 SNR: 50115 BER: 0 UBLK: 0 Stat: 0x1f [SIG CARR VIT SYNC LOCK ] cycle: 7 d_time: 0.072 s Sig: 26471 SNR: 50115 BER: 0 UBLK: 0 Stat: 0x1f [SIG CARR VIT SYNC LOCK ] cycle: 8 d_time: 0.072 s Sig: 26471 SNR: 50115 BER: 0 UBLK: 0 Stat: 0x1f [SIG CARR VIT SYNC LOCK ] Low signal strength values are AGC-loop misinterpretation as usual? y tom -- 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 1/2] gspca pac7302: allow controlling LED separately
From: Márton Németh nm...@freemail.hu
On Labtec Webcam 2200 there is a feedback LED which can be controlled
independent from the streaming. The feedback LED can be used from
user space application to show for example detected motion or to
distinguish between the preview and on-air state of the video stream.
The default value of the LED trigger keeps the previous behaviour:
LED is off when the stream is off, LED is on if the stream is on.
The code is working in the following three cases:
(1) when the LED subsystem ins not configured at all;
(2) when the LED subsystem is available, but the LED triggers are not
available and
(3) when both the LED subsystem and LED triggers are configured.
Signed-off-by: Márton Németh nm...@freemail.hu
---
diff -r 4f102b2f7ac1 linux/drivers/media/video/gspca/pac7302.c
--- a/linux/drivers/media/video/gspca/pac7302.c Thu Jan 28 20:35:40 2010 +0100
+++ b/linux/drivers/media/video/gspca/pac7302.c Sat Feb 27 00:57:32 2010 +0100
@@ -6,6 +6,7 @@
*
* Separated from Pixart PAC7311 library by Márton Németh
* Camera button input handling by Márton Németh nm...@freemail.hu
+ * LED control by Márton Németh nm...@freemail.hu
* Copyright (C) 2009-2010 Márton Németh nm...@freemail.hu
*
* This program is free software; you can redistribute it and/or modify
@@ -62,6 +63,7 @@
0 | 0xc6 | setwhitebalance()
0 | 0xc7 | setbluebalance()
0 | 0xdc | setbrightcont(), setcolors()
+1 | 0x78 | set_streaming_led()
3 | 0x02 | setexposure()
3 | 0x10 | setgain()
3 | 0x11 | setcolors(), setgain(), setexposure(), sethvflip()
@@ -72,6 +74,8 @@
#include linux/input.h
#include media/v4l2-chip-ident.h
+#include linux/leds.h
+#include linux/workqueue.h
#include gspca.h
MODULE_AUTHOR(Thomas Kaiser tho...@kaiser-linux.li);
@@ -91,6 +95,7 @@
unsigned char gain;
unsigned char exposure;
unsigned char autogain;
+ unsigned char led;
__u8 hflip;
__u8 vflip;
u8 flags;
@@ -101,6 +106,16 @@
u8 autogain_ignore_frames;
atomic_t avg_lum;
+
+#ifdef CONFIG_LEDS_CLASS
+ struct led_classdev led_cdev;
+ struct work_struct led_work;
+ char name[32];
+#ifdef CONFIG_LEDS_TRIGGERS
+ struct led_trigger led_trigger;
+ char trigger_name[32];
+#endif
+#endif
};
/* V4L2 controls supported by the driver */
@@ -572,6 +587,7 @@
sd-gain = GAIN_DEF;
sd-exposure = EXPOSURE_DEF;
sd-autogain = AUTOGAIN_DEF;
+ sd-led = 0;
sd-hflip = HFLIP_DEF;
sd-vflip = VFLIP_DEF;
sd-flags = id-driver_info;
@@ -716,6 +732,58 @@
reg_w(gspca_dev, 0x11, 0x01);
}
+static void set_streaming_led(struct gspca_dev *gspca_dev, u8 streaming)
+{
+ struct sd *sd = (struct sd *) gspca_dev;
+ u8 data = 0;
+
+ if (sd-led) {
+ if (streaming)
+ data = 0x01;
+ else
+ data = 0x00;
+ } else {
+ if (streaming)
+ data = 0x41;
+ else
+ data = 0x40;
+ }
+
+ reg_w(gspca_dev, 0xff, 0x01);
+ reg_w(gspca_dev, 0x78, data);
+}
+
+#ifdef CONFIG_LEDS_CLASS
+/* Set the LED, may sleep */
+static void led_work(struct work_struct *work)
+{
+ struct sd *sd = container_of(work, struct sd, led_work);
+ struct gspca_dev *gspca_dev = sd-gspca_dev;
+
+ mutex_lock(gspca_dev-usb_lock);
+ set_streaming_led(gspca_dev, gspca_dev-streaming);
+ mutex_unlock(gspca_dev-usb_lock);
+}
+
+/* LED state set request, must not sleep */
+static void led_set(struct led_classdev *led_cdev,
+ enum led_brightness value)
+{
+ u8 new_value;
+ struct sd *sd = container_of(led_cdev, struct sd, led_cdev);
+
+ if (value == LED_OFF)
+ new_value = 0;
+ else
+ new_value = 1;
+
+ if (sd-led != new_value) {
+ sd-led = new_value;
+ schedule_work(sd-led_work);
+ }
+}
+#endif
+
/* this function is called at probe and resume time for pac7302 */
static int sd_init(struct gspca_dev *gspca_dev)
{
@@ -747,27 +815,60 @@
atomic_set(sd-avg_lum, -1);
/* start stream */
- reg_w(gspca_dev, 0xff, 0x01);
- reg_w(gspca_dev, 0x78, 0x01);
+
+#if defined(CONFIG_LEDS_CLASS) defined(CONFIG_LEDS_TRIGGERS)
+ led_trigger_event(sd-led_trigger, LED_FULL);
+#elif defined(CONFIG_LEDS_CLASS)
+ sd-led_cdev.brightness = sd-led_cdev.max_brightness;
+ if (!(sd-led_cdev.flags LED_SUSPENDED))
+ sd-led_cdev.brightness_set(sd-led_cdev,
+ sd-led_cdev.brightness);
+#else
+ sd-led = 1;
+#endif
+ set_streaming_led(gspca_dev, 1);
return gspca_dev-usb_err;
}
static void sd_stopN(struct gspca_dev *gspca_dev)
{
+ struct sd *sd = container_of(gspca_dev, struct sd,
[PATCH 2/2] gspca pac7302: remove LED blinking when switching stream on and off
From: Márton Németh nm...@freemail.hu
The init sequences for PAC7302 contained register settings affecting
the LED state which can result blinking of the LED when it is set to
always on or always off. The blinking happened when the stream was
switched on or off.
Remove the register changes from the init sequence and handle it with
the function set_streaming_led().
Signed-off-by: Márton Németh nm...@freemail.hu
---
--- a/linux/drivers/media/video/gspca/pac7302.c.orig2010-02-27
01:00:30.0 +0100
+++ b/linux/drivers/media/video/gspca/pac7302.c 2010-02-27 01:00:49.0
+0100
@@ -322,13 +322,6 @@
#define END_OF_SEQUENCE0
/* pac 7302 */
-static const __u8 init_7302[] = {
-/* index,value */
- 0xff, 0x01, /* page 1 */
- 0x78, 0x00, /* deactivate */
- 0xff, 0x01,
- 0x78, 0x40, /* led off */
-};
static const __u8 start_7302[] = {
/* index, len, [value]* */
0xff, 1,0x00, /* page 0 */
@@ -364,7 +357,8 @@
0xff, 1,0x01, /* page 1 */
0x12, 3,0x02, 0x00, 0x01,
0x3e, 2,0x00, 0x00,
- 0x76, 5,0x01, 0x20, 0x40, 0x00, 0xf2,
+ 0x76, 2,0x01, 0x20,
+ 0x79, 2,0x00, 0xf2,
0x7c, 1,0x00,
0x7f, 10, 0x4b, 0x0f, 0x01, 0x2c, 0x02, 0x58, 0x03, 0x20,
0x02, 0x00,
@@ -388,8 +382,6 @@
0x2a, 5,0xc8, 0x00, 0x18, 0x12, 0x22,
0x64, 8,0x00, 0x00, 0xf0, 0x01, 0x14, 0x44, 0x44, 0x44,
0x6e, 1,0x08,
- 0xff, 1,0x01, /* page 1 */
- 0x78, 1,0x00,
0, END_OF_SEQUENCE /* end of sequence */
};
@@ -487,15 +479,6 @@
}
}
-static void reg_w_seq(struct gspca_dev *gspca_dev,
- const __u8 *seq, int len)
-{
- while (--len = 0) {
- reg_w(gspca_dev, seq[0], seq[1]);
- seq += 2;
- }
-}
-
/* load the beginning of a page */
static void reg_w_page(struct gspca_dev *gspca_dev,
const __u8 *page, int len)
@@ -787,7 +770,7 @@
/* this function is called at probe and resume time for pac7302 */
static int sd_init(struct gspca_dev *gspca_dev)
{
- reg_w_seq(gspca_dev, init_7302, sizeof(init_7302)/2);
+ set_streaming_led(gspca_dev, 0);
return gspca_dev-usb_err;
}
--
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: [BUG] TDA10086 : Creatix CTX929_V.1 : TS continuity errors with good RF signal input
Hello, Hermann, hermann pitton wrote: Hi Thomas, Am Samstag, den 27.02.2010, 00:34 +0100 schrieb thomas schorpp: Looks like fixed by linux 2.6.33 just in time, BIG Thank You guys ;-) Even at higher BER: Current parameters: Frequency: 1945.320 MHz Inversion: OFF Symbol rate: 22.000154 MSym/s FEC: FEC 5/6 cycle: 1 d_time: 0.001 s Sig: 18504 SNR: 39578 BER: 168 UBLK: 0 Stat: 0x1f [SIG CARR VIT SYNC LOCK ] cycle: 2 d_time: 0.073 s Sig: 18247 SNR: 39578 BER: 225 UBLK: 0 Stat: 0x1f [SIG CARR VIT SYNC LOCK ] cycle: 3 d_time: 0.079 s Sig: 18504 SNR: 37779 BER: 140 UBLK: 0 Stat: 0x1f [SIG CARR VIT SYNC LOCK ] cycle: 4 d_time: 0.072 s Sig: 18504 SNR: 39835 BER: 198 UBLK: 0 Stat: 0x1f [SIG CARR VIT SYNC LOCK ] cycle: 5 d_time: 0.071 s Sig: 18504 SNR: 39835 BER: 221 UBLK: 0 Stat: 0x1f [SIG CARR VIT SYNC LOCK ] cycle: 6 d_time: 0.072 s Sig: 18247 SNR: 39578 BER: 249 UBLK: 0 Stat: 0x1f [SIG CARR VIT SYNC LOCK ] cycle: 7 d_time: 0.072 s Sig: 18504 SNR: 39835 BER: 191 UBLK: 0 Stat: 0x1f [SIG CARR VIT SYNC LOCK ] cycle: 8 d_time: 0.072 s Sig: 18504 SNR: 39578 BER: 185 UBLK: 0 Stat: 0x1f [SIG CARR VIT SYNC LOCK ] cycle: 9 d_time: 0.072 s Sig: 18761 SNR: 39578 BER: 137 UBLK: 0 Stat: 0x1f [SIG CARR VIT SYNC LOCK ] I'll report if issue reoccurs and try to finetune crystal based tuner/demod parameters, then. y tom I just started to try to look it up, but don't have ground yet. Look for tda10086 changesets in the stable branch git repository at kernel.org 2.6.32.7...33 and linux-media repository ? If there's no applicable change then I've misinterpreted the fix for the clear sky tonight :D but I'm pretty sure the issue occured at any weather with hours of clear sky periods last week, there's not been a minute without TS errors in VDR as long as the card has been in use. I reported unexpected bad performance under GNU/Linux for that card previously. On this list? Give weblink pls. Can you point me to the fix? Cheers, Hermann y tom thomas schorpp wrote: Hi, Issue is already confirmed here: http://www.vdr-portal.de/board/thread.php?threadid=93268 Linux 2.6.32.8, 80cm dish. Do we have any Tuner/Decoder optimization points in the FE code? This is not OK: lspci -s 00:08.0 -v 00:08.0 Multimedia controller: Philips Semiconductors SAA7134/SAA7135HL Video Broadcast Decoder (rev 01) Subsystem: Creatix Polymedia GmbH Device 0005 Flags: bus master, medium devsel, latency 32, IRQ 19 Memory at fbeff400 (32-bit, non-prefetchable) [size=1K] Capabilities: [40] Power Management version 1 Kernel driver in use: saa7134 grep cTS2PES /var/log/syslog Feb 26 13:46:59 tom1 vdr: [4082] cTS2PES got 7 TS errors, 113 TS continuity errors Feb 26 13:46:59 tom1 vdr: [4082] cTS2PES got 0 TS errors, 29 TS continuity errors Feb 26 13:47:52 tom1 vdr: [4082] cTS2PES got 17 TS errors, 5 TS continuity errors Feb 26 14:03:03 tom1 vdr: [4082] cTS2PES got 2 TS errors, 136 TS continuity errors Feb 26 14:03:03 tom1 vdr: [4082] cTS2PES got 0 TS errors, 32 TS continuity errors Feb 26 14:41:42 tom1 vdr: [4082] cTS2PES got 1 TS errors, 853 TS continuity errors Feb 26 14:41:42 tom1 vdr: [4082] cTS2PES got 0 TS errors, 194 TS continuity errors Feb 26 14:52:58 tom1 vdr: [4082] cTS2PES got 2 TS errors, 196 TS continuity errors Feb 26 14:52:58 tom1 vdr: [4082] cTS2PES got 0 TS errors, 52 TS continuity errors Feb 26 14:59:34 tom1 vdr: [4082] cTS2PES got 0 TS errors, 137 TS continuity errors Feb 26 14:59:34 tom1 vdr: [4082] cTS2PES got 0 TS errors, 43 TS continuity errors Feb 26 14:59:34 tom1 vdr: [4082] cTS2PES got 0 TS errors, 16 TS continuity errors Feb 26 14:59:34 tom1 vdr: [4082] cTS2PES got 0 TS errors, 57 TS continuity errors Feb 26 14:59:54 tom1 vdr: [4082] cTS2PES got 0 TS errors, 3 TS continuity errors Feb 26 14:59:54 tom1 vdr: [4082] cTS2PES got 0 TS errors, 2 TS continuity errors dvbsnoop -s feinfo -adapter 2 Current parameters: Frequency: 1236.253 MHz Inversion: OFF Symbol rate: 31.794142 MSym/s FEC: FEC 3/4 dvbsnoop -s signal -adapter 2 cycle: 1 d_time: 0.001 s Sig: 26471 SNR: 49858 BER: 0 UBLK: 0 Stat: 0x1f [SIG CARR VIT SYNC LOCK ] cycle: 2 d_time: 0.072 s Sig: 26471 SNR: 50115 BER: 0 UBLK: 0 Stat: 0x1f [SIG CARR VIT SYNC LOCK ] cycle: 3 d_time: 0.072 s Sig: 26728 SNR: 50115 BER: 0 UBLK: 0 Stat: 0x1f [SIG CARR VIT SYNC LOCK ] cycle: 4 d_time: 0.088 s Sig: 26728 SNR: 50115 BER: 0 UBLK: 0 Stat: 0x1f [SIG CARR VIT SYNC LOCK ] cycle: 5 d_time: 0.072 s Sig: 26471 SNR: 50115 BER: 0 UBLK: 0 Stat: 0x1f [SIG CARR VIT SYNC LOCK ] cycle: 6 d_time: 0.072 s Sig: 26471 SNR: 50115 BER: 0 UBLK: 0 Stat: 0x1f [SIG CARR VIT SYNC LOCK ] cycle: 7 d_time: 0.072 s Sig: 26471 SNR: 50115 BER: 0 UBLK: 0 Stat: 0x1f [SIG CARR VIT SYNC LOCK ] cycle: 8 d_time: 0.072 s Sig: 26471 SNR: 50115 BER: 0 UBLK: 0 Stat: 0x1f [SIG CARR VIT SYNC LOCK ] Low signal strength values are AGC-loop misinterpretation as usual? y tom -- To unsubscribe
Re: [bttv] Auto detection for Provideo PV- series capture cards
Curtis Hall wrote: Mauro Carvalho Chehab wrote: Let's go by parts: The entry for PV-150 were added at -hg tree by this changeset: changeset: 784:3c31d7e0b4bc user:Gerd Knorr date:Sun Feb 22 01:59:34 2004 + summary: Initial revision Probably, this is a discontinued model, but I don't know for sure. We have been Provideo's US distributor since late 2004 and I've not heard of a PV-150 part number, and isn't not a current part number. This is the original commit when the old maintainer created his tree. It has all drivers there. The kernel addition is for sure older than 2004. It is hard to dig into changes that happened before 2004/2005, since in the past, both V4L and Kernel used different ways to manage patches. Also, a quick research at the internet showed this site in Australia: http://www.allthings.com.au/Digital%20Video%20Recording%20Remote%20Viewing%20Web%20Cams/Video%20Capture%20Card%20SDK%208%20Ch%204%20IC.htm At BTTV gallery (http://www.bttv-gallery.de/), it describes PV150 as: # PV150 Pci card with 4 bt878's on board and a HINT PCI-PCI bridge for each bt878 there is a i2c eeprom (CSI 24WC02P) and a microprocessor (PIC ?) EM78P156ELP Maybe this model were for non-US market. This one is easy: [ 13.438412] bttv0: subsystem: 1830:1540 (UNKNOWN) As this PCI ID is not known, it is just a matter of associating the PV-183 ID's with card 98. I figured, thanks Could you please send a patch for me to apply upstream? Just for reference the PV-149 / PV-981 / PV-183 series cards are: PV-149 - 4 port, 4 BT878a chips - no forced card setting required PV-155 - 16 port, 4 BT878a chips - card=77,77,77,77 (Shares the same board and PCI ID / subsystem as the PV-149) Hmm... PV-155 shares the same PCI ID as PV-149, but require a different entry, then we shouldn't add it to the PV-150 autodetection code. Okay. You can easily access four ports on the PV-155 / PV-981, but to access the sub (/dev/videoX,1-3) channels you need to add the modprobe line. Then, maybe there are some missing subsystem ID's. In the case of PV-150 entry, it has 4 subsystem ID's. It PV-155/PV-981 are equivalent, then it will likely have different PCI ID's for each /dev/video[0-3]. Could you please check it with lspci? The better would be to check with the manufacturer if is there a way to detect between those two boards (maybe reading eeprom?). I can find out, but getting technical data from Provideo can be more painful then pulling teeth. I understand, but, without this data, we cannot add auto-detection. Why do you need the card= parameter, if it shares the same subsystem ID as the other PV-981 models? I think I explained that about with the sub channels, if I'm missing something let me know. Thanks! -- 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: [BUG] TDA10086 : Creatix CTX929_V.1 : TS continuity errors with good RF signal input
Hi Thomas, Am Samstag, den 27.02.2010, 01:31 +0100 schrieb thomas schorpp: Hello, Hermann, hermann pitton wrote: Hi Thomas, Am Samstag, den 27.02.2010, 00:34 +0100 schrieb thomas schorpp: Looks like fixed by linux 2.6.33 just in time, BIG Thank You guys ;-) Even at higher BER: Current parameters: Frequency: 1945.320 MHz Inversion: OFF Symbol rate: 22.000154 MSym/s FEC: FEC 5/6 cycle: 1 d_time: 0.001 s Sig: 18504 SNR: 39578 BER: 168 UBLK: 0 Stat: 0x1f [SIG CARR VIT SYNC LOCK ] cycle: 2 d_time: 0.073 s Sig: 18247 SNR: 39578 BER: 225 UBLK: 0 Stat: 0x1f [SIG CARR VIT SYNC LOCK ] cycle: 3 d_time: 0.079 s Sig: 18504 SNR: 37779 BER: 140 UBLK: 0 Stat: 0x1f [SIG CARR VIT SYNC LOCK ] cycle: 4 d_time: 0.072 s Sig: 18504 SNR: 39835 BER: 198 UBLK: 0 Stat: 0x1f [SIG CARR VIT SYNC LOCK ] cycle: 5 d_time: 0.071 s Sig: 18504 SNR: 39835 BER: 221 UBLK: 0 Stat: 0x1f [SIG CARR VIT SYNC LOCK ] cycle: 6 d_time: 0.072 s Sig: 18247 SNR: 39578 BER: 249 UBLK: 0 Stat: 0x1f [SIG CARR VIT SYNC LOCK ] cycle: 7 d_time: 0.072 s Sig: 18504 SNR: 39835 BER: 191 UBLK: 0 Stat: 0x1f [SIG CARR VIT SYNC LOCK ] cycle: 8 d_time: 0.072 s Sig: 18504 SNR: 39578 BER: 185 UBLK: 0 Stat: 0x1f [SIG CARR VIT SYNC LOCK ] cycle: 9 d_time: 0.072 s Sig: 18761 SNR: 39578 BER: 137 UBLK: 0 Stat: 0x1f [SIG CARR VIT SYNC LOCK ] I'll report if issue reoccurs and try to finetune crystal based tuner/demod parameters, then. y tom I just started to try to look it up, but don't have ground yet. Look for tda10086 changesets in the stable branch git repository at kernel.org 2.6.32.7...33 and linux-media repository ? If there's no applicable change then I've misinterpreted the fix for the clear sky tonight :D but I'm pretty sure the issue occured at any weather with hours of clear sky periods last week, there's not been a minute without TS errors in VDR as long as the card has been in use. I reported unexpected bad performance under GNU/Linux for that card previously. On this list? Give weblink pls. No, but here is http://www.mail-archive.com/linux-media@vger.kernel.org/msg15335.html I know for sure, that I was totally baffled, when Manu, Oliver and Hartmut did start talking about big head room for improvements on the tda826x, given the results I had on the tda8261 compared on m$ for both. The flaw on linux was on the tda8261. I'm sure I did not shut up, but don't have a link for now. Thanks to Julian in the first place I would expect. Cheers, Hermann We always will have bugs. Can you point me to the fix? Cheers, Hermann y tom thomas schorpp wrote: Hi, Issue is already confirmed here: http://www.vdr-portal.de/board/thread.php?threadid=93268 Linux 2.6.32.8, 80cm dish. Do we have any Tuner/Decoder optimization points in the FE code? This is not OK: lspci -s 00:08.0 -v 00:08.0 Multimedia controller: Philips Semiconductors SAA7134/SAA7135HL Video Broadcast Decoder (rev 01) Subsystem: Creatix Polymedia GmbH Device 0005 Flags: bus master, medium devsel, latency 32, IRQ 19 Memory at fbeff400 (32-bit, non-prefetchable) [size=1K] Capabilities: [40] Power Management version 1 Kernel driver in use: saa7134 grep cTS2PES /var/log/syslog Feb 26 13:46:59 tom1 vdr: [4082] cTS2PES got 7 TS errors, 113 TS continuity errors Feb 26 13:46:59 tom1 vdr: [4082] cTS2PES got 0 TS errors, 29 TS continuity errors Feb 26 13:47:52 tom1 vdr: [4082] cTS2PES got 17 TS errors, 5 TS continuity errors Feb 26 14:03:03 tom1 vdr: [4082] cTS2PES got 2 TS errors, 136 TS continuity errors Feb 26 14:03:03 tom1 vdr: [4082] cTS2PES got 0 TS errors, 32 TS continuity errors Feb 26 14:41:42 tom1 vdr: [4082] cTS2PES got 1 TS errors, 853 TS continuity errors Feb 26 14:41:42 tom1 vdr: [4082] cTS2PES got 0 TS errors, 194 TS continuity errors Feb 26 14:52:58 tom1 vdr: [4082] cTS2PES got 2 TS errors, 196 TS continuity errors Feb 26 14:52:58 tom1 vdr: [4082] cTS2PES got 0 TS errors, 52 TS continuity errors Feb 26 14:59:34 tom1 vdr: [4082] cTS2PES got 0 TS errors, 137 TS continuity errors Feb 26 14:59:34 tom1 vdr: [4082] cTS2PES got 0 TS errors, 43 TS continuity errors Feb 26 14:59:34 tom1 vdr: [4082] cTS2PES got 0 TS errors, 16 TS continuity errors Feb 26 14:59:34 tom1 vdr: [4082] cTS2PES got 0 TS errors, 57 TS continuity errors Feb 26 14:59:54 tom1 vdr: [4082] cTS2PES got 0 TS errors, 3 TS continuity errors Feb 26 14:59:54 tom1 vdr: [4082] cTS2PES got 0 TS errors, 2 TS continuity errors dvbsnoop -s feinfo -adapter 2 Current parameters: Frequency: 1236.253 MHz Inversion: OFF Symbol rate: 31.794142 MSym/s FEC: FEC 3/4 dvbsnoop -s signal -adapter 2 cycle: 1 d_time: 0.001 s Sig: 26471 SNR: 49858 BER: 0 UBLK: 0 Stat: 0x1f [SIG CARR VIT SYNC LOCK ] cycle: 2 d_time:
Re: [PATCH 1/2] gspca pac7302: allow controlling LED separately
Hi, On 02/27/2010 01:20 AM, Németh Márton wrote: From: Márton Némethnm...@freemail.hu On Labtec Webcam 2200 there is a feedback LED which can be controlled independent from the streaming. This is true for a lot of cameras, so if we are going to add a way to support control of the LED separate of the streaming state, we should do that at the gspca_main level, and let sub drivers which support this export a set_led callback function. I must say I personally don't see much of a use case for this feature, but I believe JF Moine does, so I'll leave further comments and review of this to JF. I do believe it is important that if we go this way we do so add the gspca_main level. Regards, Hans -- 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
