Re: [linux-dvb] Hotbird-13.0H patch
On Wednesday 04 April 2007, Salvatore De Paolis wrote: Here's a patch adding new transponders. Now i am able to scan 1773 services which is nice. applied. thanks marcel ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
[linux-dvb] New card, Compro VideoMate T750
Hello, I have been given a Compro VideoMate T750 to try. I would like to add support if I can get some basic directions on how to do this. The Compro web site page for the card is: http://www.comprousa.com/New/en/product/t750/t750-hardware.html The card has a Philips SAA7135 and Zarlink ZL10353 (or is it an Intel CE 6353) and both seem to be supported but I cannot see an example of them both together. I do not know what the tuner is. There is also a Compro custom. Regards Chris ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
[linux-dvb] Compro VideoMate T750
I have recently been given a Compro VideoMate T750 to get working with Linux. Unfortunately it is not yet supported by the v4l-dvb drivers. This is an Australian card has the following features: - Analog TV Tuner (PAL-BG?) - Analog TV Capture (SVideo Composite) - FM Radio - IR - DVB-T * 2 I have tested a few similar cards using the Mercurial drivers and the analog capture works. I have not been able to get the DVB working (which is what I want the most). I am prepared to do whatever testing is required to get this working but I was hoping there was a saa7134 expert who could suggest the best way to go about it. The card is currently installed in my linux dev box but I can pull it and/or stick it in a windows box if necessary. I have used btspy under windows in the past to figure out bt878 based cards. Is there a similar saaspy? T750 Card details: 02:02.0 Class 0480: 1131:7133 (rev d1) Subsystem: 185b:c900 Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium TAbort- TAbort- MAbort- SERR- PERR- Latency: 32 (21000ns min, 8000ns max) Interrupt: pin A routed to IRQ 217 Region 0: Memory at f6004000 (32-bit, non-prefetchable) [size=2K] Capabilities: [40] Power Management version 2 Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-) Status: D0 PME-Enable- DSel=0 DScale=1 PME- saa7133[0]: i2c eeprom 00: 5b 18 00 c9 54 20 1c 00 43 43 a9 1c 55 d2 b2 92 saa7133[0]: i2c eeprom 10: 00 ff 86 0f ff 20 ff ff ff ff ff ff ff ff ff ff saa7133[0]: i2c eeprom 20: 01 40 01 03 03 01 03 01 08 ff 00 89 ff ff ff ff saa7133[0]: i2c eeprom 30: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff saa7133[0]: i2c eeprom 40: ff d7 00 c4 86 1e 05 ff 02 c2 ff 01 ff ff ff ff saa7133[0]: i2c eeprom 50: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff cb saa7133[0]: i2c eeprom 60: 30 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff saa7133[0]: i2c eeprom 70: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff Loading the wrong card type (70) results in: saa7133[0]: board init: gpio is 84bf00 input: saa7134 IR (Compro Videomate DV as /class/input/input8 tuner 1-0062: chip found @ 0xc4 (saa7133[0]) tuner 1-0063: chip found @ 0xc6 (saa7133[0]) tuner 1-0068: chip found @ 0xd0 (saa7133[0]) see also http://lists-archives.org/video4linux/16606-driver-for-compro-videomate-t750-saa7135-card.html Any help would be much appreciated. John. ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] Compro VideoMate T750
I pulled the card and found the following chips: SAA7135HL/203 (CG2548 13 TSG06302) COMPRO PRO1A 0643D WJCE6353 (W620AA17) (Codfam decoder?) ATMEL642 (EEPROM?) Plus 2 ICs which have been defaced. One is a SO-14 package and looks like it might have a Philips logo on it It might be a 74HC74N. The 74 can be read. The letters are a bit harder to make out. I don't know why they would need to deface that. One is a SO-8 package and although you can see writing, it can't be read. There are also 2 metal enclosures. Much smaller than any I have seen before. They are both 36mm x 26mm x 5mm. I have not tried opening them. I forgot that the card also has a wake up clock. You can connect it to the atx power switch and it can wake up the machine at a specified time. (Might also support PCI wake up). Other interesting things (all might be crystals): 4.0F6L 32.1F6L S6X3 NSK 6JLA Z 20.4800 John. John Newbigin wrote: I have recently been given a Compro VideoMate T750 to get working with Linux. Unfortunately it is not yet supported by the v4l-dvb drivers. This is an Australian card has the following features: - Analog TV Tuner (PAL-BG?) - Analog TV Capture (SVideo Composite) - FM Radio - IR - DVB-T * 2 I have tested a few similar cards using the Mercurial drivers and the analog capture works. I have not been able to get the DVB working (which is what I want the most). I am prepared to do whatever testing is required to get this working but I was hoping there was a saa7134 expert who could suggest the best way to go about it. The card is currently installed in my linux dev box but I can pull it and/or stick it in a windows box if necessary. I have used btspy under windows in the past to figure out bt878 based cards. Is there a similar saaspy? T750 Card details: 02:02.0 Class 0480: 1131:7133 (rev d1) Subsystem: 185b:c900 Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium TAbort- TAbort- MAbort- SERR- PERR- Latency: 32 (21000ns min, 8000ns max) Interrupt: pin A routed to IRQ 217 Region 0: Memory at f6004000 (32-bit, non-prefetchable) [size=2K] Capabilities: [40] Power Management version 2 Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-) Status: D0 PME-Enable- DSel=0 DScale=1 PME- saa7133[0]: i2c eeprom 00: 5b 18 00 c9 54 20 1c 00 43 43 a9 1c 55 d2 b2 92 saa7133[0]: i2c eeprom 10: 00 ff 86 0f ff 20 ff ff ff ff ff ff ff ff ff ff saa7133[0]: i2c eeprom 20: 01 40 01 03 03 01 03 01 08 ff 00 89 ff ff ff ff saa7133[0]: i2c eeprom 30: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff saa7133[0]: i2c eeprom 40: ff d7 00 c4 86 1e 05 ff 02 c2 ff 01 ff ff ff ff saa7133[0]: i2c eeprom 50: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff cb saa7133[0]: i2c eeprom 60: 30 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff saa7133[0]: i2c eeprom 70: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff Loading the wrong card type (70) results in: saa7133[0]: board init: gpio is 84bf00 input: saa7134 IR (Compro Videomate DV as /class/input/input8 tuner 1-0062: chip found @ 0xc4 (saa7133[0]) tuner 1-0063: chip found @ 0xc6 (saa7133[0]) tuner 1-0068: chip found @ 0xd0 (saa7133[0]) see also http://lists-archives.org/video4linux/16606-driver-for-compro-videomate-t750-saa7135-card.html Any help would be much appreciated. John. ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] [BUG] flexcop lockdep
Am Mittwoch, den 04.04.2007, 23:29 +0300 schrieb Antti Seppälä: Borgi2008 wrote: Hello, i've created a bugfixes. Hope it could helps you. Hendrik Borghorst Actually, looking at the code I cannot figure out why there has to be a spinlock in the first place. The lock is only taken in the interrupt handler which already runs in atomic context so there is no use in making the handler protected by a spinlock. Am I missing something here? I think the spinlock is unnecessary and should be removed entirely. -- Antti Seppälä Hello, it could be that the spinlock can be completely removed. I only saw that the spinlock is called before initialization. :-) So I fixed because this crashed my system. I would like to see that the bug is fixed official so i have not to patch my kernels anymore. Best greets Hendrik Borghorst ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] [BUG] flexcop lockdep
On Thu, 5 Apr 2007, Borgi2008 wrote: Am Mittwoch, den 04.04.2007, 23:29 +0300 schrieb Antti Seppälä: Borgi2008 wrote: Hello, i've created a bugfixes. Hope it could helps you. Hendrik Borghorst Actually, looking at the code I cannot figure out why there has to be a spinlock in the first place. The lock is only taken in the interrupt handler which already runs in atomic context so there is no use in making the handler protected by a spinlock. Am I missing something here? I think the spinlock is unnecessary and should be removed entirely. Even on SMP systems? ISRs are only atomic on one CPU. Patrick.___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
[linux-dvb] Cinergy DT USB XS Diversity TerraTec
Hello , this ist my first email here in the list. So i have the following problem. The USB CVB-T Stick has these Chips DiBCom 700 and 7700 mt2060 I`ve searches for the Driver and i found out that they are supported anyway it was said. the modules for it are dib0700 which should include the 7700 chip and the mt2060 module. But i had a problem when i tryed out my stick: dmesg [ 5050.256000] usb 5-3: new high speed USB device using ehci_hcd and address 7 [ 5050.388000] usb 5-3: configuration #1 chosen from 1 choice [ 5050.388000] em28xx new video device (0ccd:005a): interface 0, class 255 [ 5050.388000] em28xx probing error: endpoint is non-ISO endpoint! and usbview said that it talks only `bulk`. Maybe some of you can help me, because i know that a few users thinking about it to buy these stick although they have linux. My motherlangugage is german so if something is not understandable you can ask me in german. bidoma smime.p7s Description: S/MIME cryptographic signature ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] Cinergy DT USB XS Diversity TerraTec
On 4/5/07, Birgit Scholueke [EMAIL PROTECTED] wrote: Hello , this ist my first email here in the list. So i have the following problem. The USB CVB-T Stick has these Chips DiBCom 700 and 7700 mt2060 I`ve searches for the Driver and i found out that they are supported anyway it was said. the modules for it are dib0700 which should include the 7700 chip and the mt2060 module. But i had a problem when i tryed out my stick: dmesg [ 5050.256000] usb 5-3: new high speed USB device using ehci_hcd and address 7 [ 5050.388000] usb 5-3: configuration #1 chosen from 1 choice [ 5050.388000] em28xx new video device (0ccd:005a): interface 0, class 255 [ 5050.388000] em28xx probing error: endpoint is non-ISO endpoint! regarding this one, there are em28xx devices out there which use the same USB product ID. There's a small check in the usb probe function which at least checks for isochronous endpoints, if it fails it will not attach because it would be the wrong driver for it. and usbview said that it talks only `bulk`. Maybe some of you can help me, because i know that a few users thinking about it to buy these stick although they have linux. My motherlangugage is german so if something is not understandable you can ask me in german. cheers, Markus ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] [BUG] flexcop lockdep
Patrick Boettcher wrote: On Thu, 5 Apr 2007, Borgi2008 wrote: Am Mittwoch, den 04.04.2007, 23:29 +0300 schrieb Antti Seppälä: Borgi2008 wrote: Hello, i've created a bugfixes. Hope it could helps you. Hendrik Borghorst Actually, looking at the code I cannot figure out why there has to be a spinlock in the first place. The lock is only taken in the interrupt handler which already runs in atomic context so there is no use in making the handler protected by a spinlock. Am I missing something here? I think the spinlock is unnecessary and should be removed entirely. Even on SMP systems? ISRs are only atomic on one CPU. Redhat has a bugzilla ticket open about this issue. Patrick, please take a look at the patch in bugzilla: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=234900 Regards, Michael Krufky ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] [BUG] flexcop lockdep
Michael Krufky wrote: Patrick Boettcher wrote: On Thu, 5 Apr 2007, Borgi2008 wrote: Am Mittwoch, den 04.04.2007, 23:29 +0300 schrieb Antti Seppälä: Borgi2008 wrote: Hello, i've created a bugfixes. Hope it could helps you. Hendrik Borghorst Actually, looking at the code I cannot figure out why there has to be a spinlock in the first place. The lock is only taken in the interrupt handler which already runs in atomic context so there is no use in making the handler protected by a spinlock. Am I missing something here? I think the spinlock is unnecessary and should be removed entirely. Even on SMP systems? ISRs are only atomic on one CPU. Redhat has a bugzilla ticket open about this issue. Patrick, please take a look at the patch in bugzilla: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=234900 Actually, the bugzilla patch is also from Hendrik Borghorst ... Sorry about that... Nothing in the bugzilla report that hasnt already been said in this thread. -- Michael Krufky ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] [BUG] flexcop lockdep
Em Qua, 2007-04-04 às 15:28 +0200, P. van Gaans escreveu: I've got a Technisat Airstar USB that doesn't lock, so I'd like to try the patch whatever it's for. How do I apply it? I've just commited Hendrik's patch at v4l-dvb tree. So, you can just do: hg clone http://linuxtv.org/hg/v4l-dvb or cd v4l-dvb;hg pull (if you have already a copy of the tree) Borgi2008 wrote: Hello, i've created a bugfixes. Hope it could helps you. Hendrik Borghorst Hendrik, You've forgot to sign your patch. This is not really required for such very simple fixes, but it would be nice if you can provide your SOB for me to add on it, before I submit it to mainstream. Cheers, Mauro ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
[linux-dvb] Re: [RFC] multi std silicon tuners and analog tuners
Hi Manu, Em Qui, 2007-04-05 às 00:16 +0400, Manu Abraham escreveu: so when subsystem A acquires control, a lock is acquired by the bridge (the bridge can be imagined as a fulcrum for switching between systems) This locking would be a FSM for handling different switches. now the bridge can acquire/release locks, needs some code additions to the bridge to have this, for old devices it doesn't matter at all. now when subsystem B request control, it makes a request to the control manager on the bridge, the control is passed all the way down from the frontend(DVB)/ tuner(V4L) so it still remains quite independent the tuner/frontend part from the bridge with regards to TUNER (V4L) the same can be achieved using set standard or similar. Will have additionally one more callback (a new one) Currently, there two different tuner approaches for dealing with hybrid tuners. One as part of DVB frontend and another on V4L tuner implementation. This is bad, since it results on duplicating some code. For example, if you look on non-silicon tuners, the core of dvb-pll do the same programming as tuner-simple. Also, for silicon tuners, we have a recent case, where tda897x deals with dvb, while tda8290 deals also with tda897x, but for v4l. The right direction for this is to have the same tuner code used by both V4L and DVB. DVB callback approach for dvb_frontends seems to be an interesting approach. It doesn't cover, however, all needs for V4L. For example, some devices have also FM radio support, where stereo carrier detect and analog signal strengh are important measures. So, it is needed to add newer callbacks and maybe some extra data field for this struct to be used also by v4l. One interesting target is to have a common tuner/frontend code that can be used by radio, analog and digital tuners, in a way that it can be attached to dvb_frontend and/or to tuner_core. If just one module is handling both analog and digital tuning, it would be easier to have locks protecting the concurrence troubles you've pointed above. -- Cheers, Mauro ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
[linux-dvb] parser.pl patch for BULK handling
Should parse the logs properly now, and non digit bulk packet indexes.
Dont know much perl or if theres a better
regexp solution. But seems to be fairly solid with what comes out of
usbsnoop.log
Jules
--- parser.pl.orig 2007-04-06 04:46:51.0 +1000
+++ parser.pl 2007-04-06 04:47:37.0 +1000
@@ -62,7 +62,7 @@
}
if($enabled==1){
if($setuppacket==1){
-if(/\d{4}: (.*)/){
+if(/\s{4}\w{8}: ([\w{2} ]+)/){
foreach $idb (keys %{$urbhash{$urbrequest}}){
if($idb eq out){
printlog();
@@ -73,7 +73,7 @@
}
$urbhash{$urbrequest}{'timing'}=$timing;
} else {
-if(/\d{4}: (.*)/){
+if(/\s{4}\w{8}: ([\w{2} ]+)/){
if($urbhash{$urbrequest}{'type'} eq bulk and $direction == $dir_out) {
push(@{$urbhash{$urbrequest}{'out'}},$1);
} elsif ($urbhash{$urbrequest}{'type'} eq bulk and $direction == $dir_in) {
___
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] parser.pl patch for BULK handling
On 4/5/07, Julian [EMAIL PROTECTED] wrote: Should parse the logs properly now, and non digit bulk packet indexes. Dont know much perl or if theres a better regexp solution. But seems to be fairly solid with what comes out of usbsnoop.log Jules great thanks alot! :-) Markus ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
[linux-dvb] Re: [RFC] multi std silicon tuners and analog tuners
Mauro Carvalho Chehab wrote: Hi Manu, Em Qui, 2007-04-05 às 00:16 +0400, Manu Abraham escreveu: so when subsystem A acquires control, a lock is acquired by the bridge (the bridge can be imagined as a fulcrum for switching between systems) This locking would be a FSM for handling different switches. now the bridge can acquire/release locks, needs some code additions to the bridge to have this, for old devices it doesn't matter at all. now when subsystem B request control, it makes a request to the control manager on the bridge, the control is passed all the way down from the frontend(DVB)/ tuner(V4L) so it still remains quite independent the tuner/frontend part from the bridge with regards to TUNER (V4L) the same can be achieved using set standard or similar. Will have additionally one more callback (a new one) Currently, there two different tuner approaches for dealing with hybrid tuners. One as part of DVB frontend and another on V4L tuner implementation. This is bad, since it results on duplicating some code. ACK, not only is that duplication bad, but when there will be large changes with one system, that approach will be a failure. Too much work will be involved when an internal API changes, not to mention when the external API change occurs. For example, if you look on non-silicon tuners, the core of dvb-pll do the same programming as tuner-simple. Also, for silicon tuners, we have a recent case, where tda897x deals with dvb, while tda8290 deals also with tda897x, but for v4l. The right direction for this is to have the same tuner code used by both V4L and DVB. DVB callback approach for dvb_frontends seems to be an interesting approach. It doesn't cover, however, all needs for V4L. For example, some devices have also FM radio support, where stereo carrier detect and analog signal strengh are important measures. So, it is needed to add newer callbacks and maybe some extra data field for this struct to be used also by v4l. With what i thought, with some slight changes at both ends (very minimal) it should be able to work. One interesting target is to have a common tuner/frontend code that can be used by radio, analog and digital tuners, in a way that it can be attached to dvb_frontend and/or to tuner_core. Even without a common tuner, things can be achieved quite well, which require lesser maintenance. With the case of DVB, things are moving, ie not stagnant due to the arrival/addition of new stuff, so that is also an important aspect in deciding how to go about. A high maintenance path is not a viable option. Having a common tuner is not a nice aspect. Subsystems should be separated out, while still being interoperable. If just one module is handling both analog and digital tuning, it would be easier to have locks protecting the concurrence troubles you've pointed above. Already have a driver now. It requires some trimming of the V4L parts (someone probably might need to retouch/complete the V4L area), will post after a few reviews. ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] [BUG] flexcop lockdep
Patrick Boettcher wrote: On Thu, 5 Apr 2007, Borgi2008 wrote: Am Mittwoch, den 04.04.2007, 23:29 +0300 schrieb Antti Seppälä: Borgi2008 wrote: Hello, i've created a bugfixes. Hope it could helps you. Hendrik Borghorst Actually, looking at the code I cannot figure out why there has to be a spinlock in the first place. The lock is only taken in the interrupt handler which already runs in atomic context so there is no use in making the handler protected by a spinlock. Am I missing something here? I think the spinlock is unnecessary and should be removed entirely. Even on SMP systems? ISRs are only atomic on one CPU. Patrick. Apparently I've used to thinking too much in the UP world. It seems that flexcop interrupts are not acked with a special register write so an interrupt can then occur even while it is being processed on another CPU.(?) In that case the patch from Hendrik is correct. -- Antti Seppälä ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
[linux-dvb] Re: [RFC] multi std silicon tuners and analog tuners
Em Qui, 2007-04-05 às 23:41 +0400, Manu Abraham escreveu: DVB callback approach for dvb_frontends seems to be an interesting approach. It doesn't cover, however, all needs for V4L. For example, some devices have also FM radio support, where stereo carrier detect and analog signal strengh are important measures. So, it is needed to add newer callbacks and maybe some extra data field for this struct to be used also by v4l. With what i thought, with some slight changes at both ends (very minimal) it should be able to work. Yes. It doesn't seem to be hard to do a few changes on both sides in a way that the same tuner driver can be used by both subsystem cores. One interesting target is to have a common tuner/frontend code that can be used by radio, analog and digital tuners, in a way that it can be attached to dvb_frontend and/or to tuner_core. Even without a common tuner, things can be achieved quite well, which require lesser maintenance. With the case of DVB, things are moving, ie not stagnant due to the arrival/addition of new stuff, so that is also an important aspect in deciding how to go about. A high maintenance path is not a viable option. Having a common tuner is not a nice aspect. Subsystems should be separated out, while still being interoperable. I'm thinking on having a common tuner/frontend struct that can be attached on both subsystem cores. For now, I agree that it is better to have the cores separate, since there are some internal interfaces that would be difficult to merge. Basically, on DVB, i2c support is used at the lowest possible API, while, on V4L, we use the higher level I2C support. I2C guys are working on providing some newer ways to attach devices at the high level API. After those changes, maybe it would valuable to have dvb and v4l using the same i2c api. Then, we may have one common tuner core. If just one module is handling both analog and digital tuning, it would be easier to have locks protecting the concurrence troubles you've pointed above. Already have a driver now. It requires some trimming of the V4L parts (someone probably might need to retouch/complete the V4L area), will post after a few reviews. Ok. Markus also did another approach on his RFC. We really should address this issue as soon as possible, to allow better support for hybrid devices. -- Cheers, Mauro ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] Re: [RFC] multi std silicon tuners and analog tuners
Mauro Carvalho Chehab wrote: Also, for silicon tuners, we have a recent case, where tda897x deals with dvb, while tda8290 deals also with tda897x, but for v4l. Please leave tda8290 / tda8275(a) alone for now. Hartmut and I have some big changes coming, and external changes made to those files will screw us up. FYI, tda8290 is predominantly a driver for the analog IF demod. The tuning code itself can easily be factored into a unified tuning sub-module, useable by both subsystems. I have plans to do this now, without any need for API changes. Once we reach agreement on how we handle hybrid silicon, I will handle the conversion for the tda827x tuners. Regards, Michael Krufky ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] Re: [RFC] multi std silicon tuners and analog tuners
Michael, Em Qui, 2007-04-05 às 16:31 -0400, Michael Krufky escreveu: Mauro Carvalho Chehab wrote: Also, for silicon tuners, we have a recent case, where tda897x deals with dvb, while tda8290 deals also with tda897x, but for v4l. Please leave tda8290 / tda8275(a) alone for now. Hartmut and I have some big changes coming, and external changes made to those files will screw us up. FYI, tda8290 is predominantly a driver for the analog IF demod. The tuning code itself can easily be factored into a unified tuning sub-module, useable by both subsystems. I have plans to do this now, without any need for API changes. Once we reach agreement on how we handle hybrid silicon, I will handle the conversion for the tda827x tuners. This doesn't make my argument invalid. The fact is that the support for hybrid tuners is hard due the lack of a proper way to connect the same driver to both cores. This lead each developer to find his own way for handling tuners, resulting on duplicated stuff and two different drivers for the same device. Not having a standard way for this is not good. We need to have one way, used by all developers that works with hybrid devices. It should also have a locking schema avoiding the usage of both tuner modes at the same time. What happens if you call both a dvb and an analog app at the same time with the current code? The tuning code itself can easily be factored into a unified tuning sub-module, useable by both subsystems. I have plans to do this now, without any need for API changes. How would you do this without API changes? V4L tuners currently can't currently be a separate module, but should be part of tuner-core. So, to allow a tuner to register on tuner-core, some API changes are required. Otherwise, you cannot load a sub-module at tuner-core. Also, tuner struct is different from dvb_frontends struct, although both have several stuff that can be common. If you pass a dvb_frontends struct to tuner-core, or otherwise, pass a struct tuner to dvb, there will be some missing parameters. Once we reach agreement on how we handle hybrid silicon, I will handle the conversion for the tda827x tuners. This seems to be the proper way. Let's first close the API changes, then convert the drivers. I intend to convert all tuner drivers to the newer API, to allow to modularize the tuners, including tuner-simple. -- Cheers, Mauro ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] Re: [RFC] multi std silicon tuners and analog tuners
Mauro, Mauro Carvalho Chehab wrote: Michael, Em Qui, 2007-04-05 às 16:31 -0400, Michael Krufky escreveu: Mauro Carvalho Chehab wrote: Also, for silicon tuners, we have a recent case, where tda897x deals with dvb, while tda8290 deals also with tda897x, but for v4l. Please leave tda8290 / tda8275(a) alone for now. Hartmut and I have some big changes coming, and external changes made to those files will screw us up. FYI, tda8290 is predominantly a driver for the analog IF demod. The tuning code itself can easily be factored into a unified tuning sub-module, useable by both subsystems. I have plans to do this now, without any need for API changes. Once we reach agreement on how we handle hybrid silicon, I will handle the conversion for the tda827x tuners. This doesn't make my argument invalid. It appears that I may have been misunderstood. Your argument is completely valid, I only ask that nobody touch tda8290.c or tda827x.c until Hartmut and I are done with our upcoming changes. The fact is that the support for hybrid tuners is hard due the lack of a proper way to connect the same driver to both cores. This lead each developer to find his own way for handling tuners, resulting on duplicated stuff and two different drivers for the same device. Agreed. Not having a standard way for this is not good. We need to have one way, used by all developers that works with hybrid devices. Agreed. It should also have a locking schema avoiding the usage of both tuner modes at the same time. What happens if you call both a dvb and an analog app at the same time with the current code? Agreed. The tuning code itself can easily be factored into a unified tuning sub-module, useable by both subsystems. I have plans to do this now, without any need for API changes. How would you do this without API changes? V4L tuners currently can't currently be a separate module, but should be part of tuner-core. So, to allow a tuner to register on tuner-core, some API changes are required. Otherwise, you cannot load a sub-module at tuner-core. Again, I am being misunderstood The API changes are indeed needed. I am just working on reusing the code without duplication. In order for us to Do The Right Thing (tm) , we *do* need some api changes. I'd rather not go into detail about my uncommitted changes. Maybe it would be best if you pretend I never said I have plans to do this now, without any need for API changes. I was only talking about code unification. We still need the API changes to provide a single tuner interface, and locking abilities. I repeat - the discussion that you and Manu are having is a very good discussion, and I fully support the direction that this is taking. Also, tuner struct is different from dvb_frontends struct, although both have several stuff that can be common. If you pass a dvb_frontends struct to tuner-core, or otherwise, pass a struct tuner to dvb, there will be some missing parameters. Once we reach agreement on how we handle hybrid silicon, I will handle the conversion for the tda827x tuners. This seems to be the proper way. Let's first close the API changes, then convert the drivers. Yes. For now, I am developing my tuner driver with the current methods. It will be very easy to convert to the new methods once we reach agreement. I intend to convert all tuner drivers to the newer API, to allow to modularize the tuners, including tuner-simple. Good. Hopefully I will be able to get my change into tda8290.c before we're ready for the conversion. I should be able to push in some patches in a week or so... -- Michael Krufky ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] Re: [RFC] multi std silicon tuners and analog tuners
Em Qui, 2007-04-05 às 17:10 -0400, Michael Krufky escreveu: It appears that I may have been misunderstood. Your argument is completely valid, I only ask that nobody touch tda8290.c or tda827x.c until Hartmut and I are done with our upcoming changes. Yes. It doesn't make sense touching the code right now, before we've agreed on the changes. There's just a point that worries me: Markus, Manu and you are coding different solutions for the API. We should focus our discussion at the API changes *then* coding the drivers. Otherwise, the discussion will just generate warm, since each one will defend his approach, according with his own foot and it would be really hard to have a common approach. My suggestion is to start the discussion from Markus RFC, since it is the first one who proposed an RFC on this subject, (his second approach is dated from Feb, 27). He sent the 3rd approach today. As it is an RFC, and provided that *all* keep the discussions at the highest possible technical level, not starting or answering to personal flames, I can see everyone collaborating on this and converging to a common sense. This is a good time to remind about good values. Happy Easter for all! -- Cheers, Mauro ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] Re: [RFC] multi std silicon tuners and analog tuners
Mauro Carvalho Chehab wrote: Em Qui, 2007-04-05 às 17:10 -0400, Michael Krufky escreveu: It appears that I may have been misunderstood. Your argument is completely valid, I only ask that nobody touch tda8290.c or tda827x.c until Hartmut and I are done with our upcoming changes. Yes. It doesn't make sense touching the code right now, before we've agreed on the changes. There's just a point that worries me: Markus, Manu and you are coding different solutions for the API. We should focus our discussion at the API changes *then* coding the drivers. Otherwise, the discussion will just generate warm, since each one will defend his approach, according with his own foot and it would be really hard to have a common approach. I am not touching the API. I am working on adding support for the tda8295+8275a and tda8295+18271 to tda8290.c and tda827x.c . For now, I have the analog parts working and ready, will push in a patch after Hartmut's review. Manu's proposal runs deeper than Markus, and address the issue in a much more thorough manner. I like the direction that the discussion between you and Manu are going. We must all keep an open mind, and make the BEST decision. This is not a race, and it doesnt matter who came first. I have no proposal on the table. I just want to see the best solution made. My suggestion is to start the discussion from Markus RFC, since it is the first one who proposed an RFC on this subject, (his second approach is dated from Feb, 27). He sent the 3rd approach today. Manu's rfc has been outstanding for over a year now. Multiproto is required for dvb-s2 support, and Markus' proposal does not take multiproto into account. I am sure Manu will be able to get into better detail, here. As it is an RFC, and provided that *all* keep the discussions at the highest possible technical level, not starting or answering to personal flames, I can see everyone collaborating on this and converging to a common sense. Yes. This is a good time to remind about good values. Happy Easter for all! same to you. Regards, Michael Krufky ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] Re: [RFC] multi std silicon tuners and analog tuners
Mauro Carvalho Chehab wrote: Em Qui, 2007-04-05 às 17:10 -0400, Michael Krufky escreveu: It appears that I may have been misunderstood. Your argument is completely valid, I only ask that nobody touch tda8290.c or tda827x.c until Hartmut and I are done with our upcoming changes. Yes. It doesn't make sense touching the code right now, before we've agreed on the changes. There's just a point that worries me: Markus, Manu and you are coding different solutions for the API. We should focus our discussion at the API changes *then* coding the drivers. Otherwise, the discussion will just generate warm, since each one will defend his approach, according with his own foot and it would be really hard to have a common approach. My suggestion is to start the discussion from Markus RFC, since it is the first one who proposed an RFC on this subject, (his second approach is dated from Feb, 27). He sent the 3rd approach today. As it is an RFC, and provided that *all* keep the discussions at the highest possible technical level, not starting or answering to personal flames, I can see everyone collaborating on this and converging to a common sense. As i said .. With the case of DVB, things are moving, ie not stagnant due to the arrival/addition of new stuff, so that is also an important aspect in deciding how to go about. A high maintenance path is not a viable option. The reason being DVB is a fast moving commercial target. Linux/OSS just barely tries to catch up. I don't care what option is chosen (for the same reason had been silent), but the above is extremely important. There are more things important to DVB than just Hybrid/Analog device support alone. This is a good time to remind about good values. Happy Easter for all! Wishing you all the same Regards, Manu ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
[linux-dvb] Compro Videomate U300
Hi, has anyone used this? It seems to be basically identical to the Compro Videomate U5000 which is supported by pb's dib7000 driver. I can get these for a very good price, so if they're good hardware and well supported I might buy a couple and build multituner capability that way instead of investing in a dualtuner card. Anyone have any experiences with this or other dib7000 sticks? /fnord ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
[linux-dvb] DVB devices fails after kernel.i686 2.6.20-1.2925.fc6
I have two DVB devices but one of these fails to initialise after I update my FC6 kernel, I'm pretty sure its the Air2PC/AirStar 2 DVB-T PCI card. I have regressed back to kernel.i686 2.6.19-1.2911.6.5.fc6 which brings my devices back online. I have pasted the /var/log/dmesg output for both working and broken kernel below The most interesting message is : **WARNING** I2C adapter driver [B2C2 FlexCop device] forgot to specify physical device; fix it! Any hints on what this means and if this can be fixed? or do I need to make some changes in my modules.conf?? Thanks FC6 Kernel 2911 (working) b2c2-flexcop: B2C2 FlexcopII/II(b)/III digital TV receiver chip loaded successfully flexcop-pci: will use the HW PID filter. flexcop-pci: card revision 2 ACPI: PCI Interrupt :01:06.0[A] - Link [APC3] - GSI 18 (level, low) - IRQ 20 DVB: registering new adapter (FlexCop Digital TV device). b2c2-flexcop: MAC address = 00:d0:d7:0a:33:62 ieee1394: Initialized config rom entry `ip1394' b2c2-flexcop: i2c master_xfer failed cx2388x v4l2 driver version 0.0.6 loaded b2c2-flexcop: i2c master_xfer failed b2c2-flexcop: found the mt352 at i2c address: 0x0f DVB: registering frontend 0 (Zarlink MT352 DVB-T)... b2c2-flexcop: initialization of 'Air2PC/AirStar 2 DVB-T' at the 'PCI' bus controlled by a 'FlexCopIIb' complete FC6 Kernel 2933: (not working) b2c2-flexcop: B2C2 FlexcopII/II(b)/III digital TV receiver chip loaded successfully Linux video capture interface: v2.00 cx2388x cx88-mpeg Driver Manager version 0.0.6 loaded /8] CORE cx88[0]: subsystem: 1822:0025, board: digitalnow DNTV Live! DVB-T Pro [card=42,insmod option] TV tuner 63 at 0x1fe, Radio tuner -1 at 0x1fe cx2388x v4l2 driver version 0.0.6 loaded input: cx88 IR (digitalnow DNTV Live! as /class/input/input4 cx88[0]/2: cx2388x 8802 Driver Manager cx88[0]/2: found at :01:08.2, rev: 5, irq: 21, latency: 32, mmio: 0xf600 flexcop-pci: will use the HW PID filter. flexcop-pci: card revision 2 DVB: registering new adapter (FlexCop Digital TV device). b2c2-flexcop: MAC address = 00:d0:d7:0a:33:62 **WARNING** I2C adapter driver [B2C2 FlexCop device] forgot to specify physical device; fix it! b2c2-flexcop: i2c master_xfer failed b2c2-flexcop: i2c master_xfer failed b2c2-flexcop: found the mt352 at i2c address: 0x0f DVB: registering frontend 0 (Zarlink MT352 DVB-T)... b2c2-flexcop: initialization of 'Air2PC/AirStar 2 DVB-T' at the 'PCI' bus controlled by a 'FlexCopIIb' complete ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] [BUG] flexcop lockdep
On Thu, 5 Apr 2007, Patrick Boettcher wrote: On Thu, 5 Apr 2007, Borgi2008 wrote: Am Mittwoch, den 04.04.2007, 23:29 +0300 schrieb Antti Sepp?l?: Actually, looking at the code I cannot figure out why there has to be a spinlock in the first place. The lock is only taken in the interrupt handler which already runs in atomic context so there is no use in making the handler protected by a spinlock. Am I missing something here? I think the spinlock is unnecessary and should be removed entirely. Even on SMP systems? ISRs are only atomic on one CPU. I thought ISRs were normally atomic even on SMP systems. When an interrupt occurs, that interrupt is disabled until the ISR returns. Except in fast handlers (which flexcop is not) all interrupts aren't disabled, and so an ISR can be interrupted by a _different_ ISR, and a different ISR could be running at the same time on another CPU. But an ISR doesn't have to worry about two copies of itself running at the same time. At least, that's how I think it works. I don't see how a spin lock that is only used from the ISR could be useful, assuming the ISR is only called via an interrupt. There is no reason you couldn't call the isr function from some system call handler, but that would be an unusual thing to do. Normally an ISR does need a spinlock, to access data shared by the non-interrupt part of the driver. I wonder if there is a bug in flexcop in that nothing else uses irq_lock? ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
RE: [linux-dvb] Re: STB0899 and TT 3200-S2
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Manu Abraham Sent: Saturday, 24 February 2007 8:56 p.m. To: Mike Kazmier Cc: linux-dvb@linuxtv.org Subject: Re: [linux-dvb] Re: STB0899 and TT 3200-S2 On 2/23/07, Mike Kazmier [EMAIL PROTECTED] wrote: I do have an update: I was able to patch the v4l-dvb mercurial tip with patches from http://kromtek.com/dvb/patches/ and build the stb0899 modules. I was able to load the stb0899 kernel module successfully along with the budget kernel module but I can't see and /dev/dvb devices. I saw the post from manu about the new szap, but I can't even get the card up. Manu - have you ever used the TT3200-S2 successfully? Has anyone? Yep, will update the tree soon. manu ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb Hi, I'm new at all this though I've been readying the posts for some months. Can anyone tell me where to find the tree Manu was to update? Then maybe I to can get my TT S2-3200 working. Thanks Peter Cockle ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] DVB (AirStar/B2C2 FlexCop ) fails after kernel.i686 2.6.20-1.2925.fc6
changing title to hopefully trigger some help, as I noticed other threads which perhaps are related? ie keywords of AirStar FlexCop which is possibly the card / driver I use. Paul On 6/04/2007 10:14 AM, Paul Wilson wrote: I have two DVB devices but one of these fails to initialise after I update my FC6 kernel, I'm pretty sure its the Air2PC/AirStar 2 DVB-T PCI card. I have regressed back to kernel.i686 2.6.19-1.2911.6.5.fc6 which brings my devices back online. I have pasted the /var/log/dmesg output for both working and broken kernel below The most interesting message is : **WARNING** I2C adapter driver [B2C2 FlexCop device] forgot to specify physical device; fix it! Any hints on what this means and if this can be fixed? or do I need to make some changes in my modules.conf?? Thanks FC6 Kernel 2911 (working) b2c2-flexcop: B2C2 FlexcopII/II(b)/III digital TV receiver chip loaded successfully flexcop-pci: will use the HW PID filter. flexcop-pci: card revision 2 ACPI: PCI Interrupt :01:06.0[A] - Link [APC3] - GSI 18 (level, low) - IRQ 20 DVB: registering new adapter (FlexCop Digital TV device). b2c2-flexcop: MAC address = 00:d0:d7:0a:33:62 ieee1394: Initialized config rom entry `ip1394' b2c2-flexcop: i2c master_xfer failed cx2388x v4l2 driver version 0.0.6 loaded b2c2-flexcop: i2c master_xfer failed b2c2-flexcop: found the mt352 at i2c address: 0x0f DVB: registering frontend 0 (Zarlink MT352 DVB-T)... b2c2-flexcop: initialization of 'Air2PC/AirStar 2 DVB-T' at the 'PCI' bus controlled by a 'FlexCopIIb' complete FC6 Kernel 2933: (not working) b2c2-flexcop: B2C2 FlexcopII/II(b)/III digital TV receiver chip loaded successfully Linux video capture interface: v2.00 cx2388x cx88-mpeg Driver Manager version 0.0.6 loaded /8] CORE cx88[0]: subsystem: 1822:0025, board: digitalnow DNTV Live! DVB-T Pro [card=42,insmod option] TV tuner 63 at 0x1fe, Radio tuner -1 at 0x1fe cx2388x v4l2 driver version 0.0.6 loaded input: cx88 IR (digitalnow DNTV Live! as /class/input/input4 cx88[0]/2: cx2388x 8802 Driver Manager cx88[0]/2: found at :01:08.2, rev: 5, irq: 21, latency: 32, mmio: 0xf600 flexcop-pci: will use the HW PID filter. flexcop-pci: card revision 2 DVB: registering new adapter (FlexCop Digital TV device). b2c2-flexcop: MAC address = 00:d0:d7:0a:33:62 **WARNING** I2C adapter driver [B2C2 FlexCop device] forgot to specify physical device; fix it! b2c2-flexcop: i2c master_xfer failed b2c2-flexcop: i2c master_xfer failed b2c2-flexcop: found the mt352 at i2c address: 0x0f DVB: registering frontend 0 (Zarlink MT352 DVB-T)... b2c2-flexcop: initialization of 'Air2PC/AirStar 2 DVB-T' at the 'PCI' bus controlled by a 'FlexCopIIb' complete ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
