Re: [linux-dvb] en50221_tl_poll: CAWrite failed
> > [EMAIL PROTECTED] gnutv]# ./gnutv -cammenu > > en50221_tl_poll: CAWrite failed > > en50221_stdcam_llci_poll: Error reported by stack:-2 > > Can anyone suggest anything? Does this look like faulty hardware??? It > > does it in 2 different machines. > > It is indeed not flaky hardware as i wrote earlier. -2 is timeout. It is > due to a bug in debiread/write > Have been looking at that bug. The bug is that the driver times out. The > bug was discovered by julian (adding his CC) > > > > > What is going on here? Can anyone help? > > The bug is that the debi bus looks unlocked and that debiread/write > doesn't look serialized, using uselocks creates it's own set of problems. > <> Thanks Manu - sorry, I had my SPAM filters set wrong and your message was mis-filed. Any suggestions on this? ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] en50221_tl_poll: CAWrite failed
Am Dienstag 01 Mai 2007 21:38 schrieb Manu Abraham: > Simon Baxter wrote: > > Thought I'd try a new thread with this problem as I'm getting no where - > > and not sure what else to try. > > > > I've just added a Irdeto CAM to my TT-1500 Budget DVB-C card and I'm > > getting write errors with VDR and with gnutv: > > > > [EMAIL PROTECTED] gnutv]# dmesg | grep DVB > > DVB: registering new adapter (TT-Budget-C-CI PCI). > > DVB: registering frontend 0 (ST STV0297 DVB-C)... > > dvb_ca adapter 0: DVB CAM detected and initialised successfully > > dvb_ca adapter 0: DVB CAM detected and initialised successfully > > > > [EMAIL PROTECTED] gnutv]# ./gnutv -cammenu > > en50221_tl_poll: CAWrite failed > > en50221_stdcam_llci_poll: Error reported by stack:-2 > > > > and > > > > In /var/log/messages: > > Apr 30 19:31:26 media1 vdr: [2774] CAM 1: module present > > Apr 30 19:31:28 media1 kernel: dvb_ca adapter 0: DVB CAM detected and > > initialised successfully > > Apr 30 19:31:28 media1 vdr: [2774] CAM 1: module ready > > Apr 30 19:31:29 media1 vdr: [2774] ERROR: can't write to CI adapter on > > device 0: Input/output error > > > > In dmesg: > > dvb_ca adapter 0: DVB CAM detected and initialised successfully > > dvb_ca adapter 0: DVB CAM detected and initialised successfully > > dvb_ca adapter 0: DVB CAM detected and initialised successfully > > > > I'm running the latest hg v4l-dvb. > > > > Can anyone suggest anything? Does this look like faulty hardware??? It > > does it in 2 different machines. > > It is indeed not flaky hardware as i wrote earlier. -2 is timeout. It is > due to a bug in debiread/write -2 is not timeout but read/write error. What CAM are you using? - And is this running on a SMP (Core Duo, etc) system? With some CAMs I ran into trouble with read/write errors, but that was on initialising. It helped to simply outcomment the checks for STATUSREG_RE in dvb_ca_en50221.c. You might try that, though it will also break correct error-detection. -Julian ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] en50221_tl_poll: CAWrite failed
> > > [EMAIL PROTECTED] gnutv]# ./gnutv -cammenu > > > en50221_tl_poll: CAWrite failed > > > en50221_stdcam_llci_poll: Error reported by stack:-2 > > It is indeed not flaky hardware as i wrote earlier. -2 is timeout. It is > > due to a bug in debiread/write > > -2 is not timeout but read/write error. What CAM are you using? - And is this > running on a SMP (Core Duo, etc) system? > With some CAMs I ran into trouble with read/write errors, but that was on > initialising. It helped to simply outcomment the checks for STATUSREG_RE in > dvb_ca_en50221.c. You might try that, though it will also break correct > error-detection. > > -Julian I'm using an Irdeto 2 CAM. Have installed the same v4l-dvb drivers on 2 different machines with the same results. One is an Intel P2 350, the other a P4 Dell GX260. Which lines should I comment in dvb_ca_en50221.c ??? [EMAIL PROTECTED] v4l-dvb]# find . | grep dvb_ca_en50221.c ./linux/drivers/media/dvb/dvb-core/dvb_ca_en50221.c ./v4l/dvb_ca_en50221.c ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] en50221_tl_poll: CAWrite failed
Am Mittwoch 02 Mai 2007 12:01 schrieb Simon Baxter:
> > > > [EMAIL PROTECTED] gnutv]# ./gnutv -cammenu
> > > > en50221_tl_poll: CAWrite failed
> > > > en50221_stdcam_llci_poll: Error reported by stack:-2
> > >
> > > It is indeed not flaky hardware as i wrote earlier. -2 is timeout. It
> > > is due to a bug in debiread/write
> >
> > -2 is not timeout but read/write error. What CAM are you using? - And is
>
> this
>
> > running on a SMP (Core Duo, etc) system?
> > With some CAMs I ran into trouble with read/write errors, but that was on
> > initialising. It helped to simply outcomment the checks for STATUSREG_RE
>
> in
>
> > dvb_ca_en50221.c. You might try that, though it will also break correct
> > error-detection.
> >
> > -Julian
>
> I'm using an Irdeto 2 CAM. Have installed the same v4l-dvb drivers on 2
> different machines with the same results.
> One is an Intel P2 350, the other a P4 Dell GX260.
>
> Which lines should I comment in dvb_ca_en50221.c ???
>
> [EMAIL PROTECTED] v4l-dvb]# find . | grep dvb_ca_en50221.c
> ./linux/drivers/media/dvb/dvb-core/dvb_ca_en50221.c
> ./v4l/dvb_ca_en50221.c
In dvb_ca_en50221_read_data outcomment this block:
if (status & STATUSREG_RE) {
ca->slot_info[slot].slot_state = DVB_CA_SLOTSTATE_LINKINIT;
status = -EIO;
goto exit;
}
and this one in dvb_ca_en50221_write_data:
if (status & (STATUSREG_DA | STATUSREG_RE)) {
status = -EAGAIN;
goto exitnowrite;
}
you might also try to outcomment this, also in dvb_ca_en50221_write_data:
if (status & STATUSREG_WE) {
ca->slot_info[slot].slot_state = DVB_CA_SLOTSTATE_LINKINIT;
status = -EIO;
goto exit;
}
Pleas keep in mind that this just disables some error checks. Actually for me
it solved some troubles.
Regards,
Julian
___
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] Re: DST/BT878 module customization (.. was: Critical points about ...)
On Tue, 1 May 2007, Mauro Carvalho Chehab wrote: > Em Ter, 2007-05-01 ??s 16:16 -0700, Trent Piepho escreveu: > > On Tue, 1 May 2007, Mauro Carvalho Chehab wrote: > > > With this configuration, dvb-bt8xx hangs during initialization, > > > generating an OOPS, if you have a board with DST (modprobe dvb-bt8xx > > > never returns). > > > > Stupid typo in the first patch, a != should have been ==. > > > > Fixed: > > http://linuxtv.org/hg/~tap/dst-new > > With the changes, the dst unselection worked. > > Those are the logs with dst unselected: > > DVB: registering new adapter (bttv0). > DVB: Unable to find symbol dst_attach() > frontend_init: Could not find a Twinhan DST. > dvb-bt8xx: A frontend driver was not found for device 109e/0878 subsystem > fbfb/f800 This is the dvb_attach() "not found" message. You should see this same message if you leave dst selected and then just delete the dst modules before loading dvb-bt8xx. If you turn dvb_attach off, you should see a different "dst support was disabled" message (and no crash!). > However, when dst is selected, I got those errors: When I made this patch I was basing it off a patch I made around 9 months ago. I thought since that one was ok, this would be ok too, and in my hurry to get it done I've clearly put too little effort into checking it, and I'm sorry to have wasted your time. I promise, this time it's right! http://linuxtv.org/hg/~tap/dst-new ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] Re: DST/BT878 module customization (.. was: Critical points about ...)
Original-Nachricht Datum: Wed, 2 May 2007 04:10:03 -0700 (PDT) Von: Trent Piepho <[EMAIL PROTECTED]> An: Mauro Carvalho Chehab <[EMAIL PROTECTED]> CC: linux-dvb@linuxtv.org, [EMAIL PROTECTED], Manu Abraham <[EMAIL PROTECTED]> Betreff: Re: [linux-dvb] Re: DST/BT878 module customization (.. was: Criticalpoints about ...) > On Tue, 1 May 2007, Mauro Carvalho Chehab wrote: > > Em Ter, 2007-05-01 Ã s 16:16 -0700, Trent Piepho escreveu: > > > On Tue, 1 May 2007, Mauro Carvalho Chehab wrote: > > > > With this configuration, dvb-bt8xx hangs during initialization, > > > > generating an OOPS, if you have a board with DST (modprobe dvb-bt8xx > > > > never returns). > > > > > > Stupid typo in the first patch, a != should have been ==. > > > > > > Fixed: > > > http://linuxtv.org/hg/~tap/dst-new > > > > With the changes, the dst unselection worked. > > > > Those are the logs with dst unselected: > > > > DVB: registering new adapter (bttv0). > > DVB: Unable to find symbol dst_attach() > > frontend_init: Could not find a Twinhan DST. > > dvb-bt8xx: A frontend driver was not found for device 109e/0878 > subsystem fbfb/f800 > > This is the dvb_attach() "not found" message. You should see this same > message if you leave dst selected and then just delete the dst modules > before > loading dvb-bt8xx. > > If you turn dvb_attach off, you should see a different "dst support was > disabled" message (and no crash!). > > > However, when dst is selected, I got those errors: > > When I made this patch I was basing it off a patch I made around 9 months > ago. I thought since that one was ok, this would be ok too, and in my > hurry to get it done I've clearly put too little effort into checking it, > and I'm sorry to have wasted your time. > > I promise, this time it's right! > http://linuxtv.org/hg/~tap/dst-new The DST card with CA slot and the DST card without CA slot are two different cases. Like the Pinnacle PCTV SAT with CI extension and the Pinnacle PCTV SAT without CI extension. In so far my questions are: Shouldn't there be two cases for deselecting DST modules? At least my basic approach tried to distinct those two cases. In how far is it enough or technically sufficient to treat those two cases as one? And, as already mentioned: At least in all of those 4 cases no dvb-pll module isn't needed at all - someone simply forgot to add some lines for the exception handling in dvb-bt8xx to get rid of dvb-pll.c if there is no lgdt330x frontend needed (read: if there is no Fusion HDTV Lite card in the machine at all). If this small case is being fixed you simply can expand the deselection of dvb-pll.c on all cards treated in backend module dvb-bt8xx.c. Uwe > > ___ > linux-dvb mailing list > linux-dvb@linuxtv.org > http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb -- "Feel free" - 10 GB Mailbox, 100 FreeSMS/Monat ... Jetzt GMX TopMail testen: http://www.gmx.net/de/go/topmail ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] DST/BT878 module customization (.. was: Critical points about ...)
Trent Piepho wrote: > On Tue, 1 May 2007, Simon Arlott wrote: >> On 30/04/07 22:17, Markus Rechberger wrote: >>> From my side I do not see any problem with that patch, if someone else >>> has a problem with it please state out the reason. >> I have no problem with the patch since it has nothing to do with my DVB >> card but you're only encouraging Uwe to be abusive since it seems to >> help get him what he wants: > > I've been aware of the problem with dst not fully using the dvb customization > systems(*) for a long time. It came up when dvb_attach() et al were first > being integrated, well before any rejected patches or strongly worded emails > or whatever from certain people that I'm aware of. > Well, your understanding of the device is quite limited and hence your comments and patches. The DST as it refers to is an embedded system a x86 Compatible RISC core [1] running at 20Mhz with 4MB Flash and 1MB RAM. The device has it's own IO and 2 DMA channels. What we have is a PQFP device This is the case in most cases. On some cheaper cards the embedded system is replaced by an 8 bit host microcontroller, to cut down costs where all the features are not required for a specific model Additionally this embedded system has a fast shovelling engine for the MPEG2 TS routing in between the This embedded system is connected to an actual (1) DVB frontend [2] (2) DVB CA interface [3] (3) Analog tuner (4) Audio interfaces These features are not the characteristics of a DVB Frontend. Here there is a DVB frontend like the normal ones which is hidden behind another pseudo bridge (So you don't have *any* access to the frontend at large) It is not necessary that *all* the dst cards (there are around ~15 different variants of the same) do have the very same feature set. It does support DVB-S/DSS/DVB-C/DVB-T/ATSC depending on the cards. In fact it is a combo driver supporting the entire devices using a common command set In such a case it has more characteristics of the PCI bridge and in fact heavily tied to it and has it's own advantages. > I saw some discussion about dst by Markus, Mauro, and Andrew Morton, and since > I already know about the issues here, I felt I should post a patch for them > any other reasonable developers who might spend time on this. > I would think that it would be *extremely* rude for a person to send in patches for a device that which you don't understand at all, when it is for limiting the capability of the said device > If there is an abusive person, I'm not going to let it affect my behavior. > You lose if you let them influence your decisions one way, or influence them > another way. > > > (*) There are two customization/dependency control systems in DVB. One is > dvb_attach(), the other is DVB_FE_CUSTOMISE. They are not two entirely > separate systems, but overlap in their design a great deal. > Here we have the attach method attaching different objects, but basically it can be handled for the frontend devices only (and that too that share a very common trait, in this case, frontends are coupled using the i2c bus) and not for other devices. Situation changes when you use another interface such as SPI, where the interface is not well defined. In the DVB OO concept we have, where the objects are at different levels, the basic concept is that an object is indeed a smaller subset, depending on the level that which it pertains to. In such a case the frontend is limited to do just frontend related operations. There could be other ways that things can be done maybe the DVB API can be redone to have all DVB operations through the frontend alone. But that is not at all decent way of doing it. > The significant part, common to both, is the overall design of the driver > framework. DVB uses what I would describe as an object oriented system. A > driver for a certain type of hardware exports a single attach function, which > returns an object for one instance of that hardware. All control of that > hardware is done via methods defined in this object. There is typical > hierarchy, where an 'adapter' object will contain a 'frontend' object which > will contain a 'tuner' object. Of course hardware designers are not > constrained by the software frameworks we create, so sometimes it's more > complex (e.g., dst). It is a bit more complex than you think. You can imagine the entire DVB-CORE along with proprietory vendor specific tuning algorithms (on all devices, specific to the hardware onbaord. Algorithms do change from slight change of hardware such as demodulators and or CA interface stacks) on CA devices it has an onboard EN50221 CA stack from SCM [4] called the Sunplus CI stack. On Hybrid DST devices they do feature in analog core support in there as well as Audio too on some cards. It is not a constraint as what you might think, as the DST is complete hardware solution of the interfaces that you are talking about. (There are 2 approaches, (1) do everything in hardware (2)
[linux-dvb] Problem with TT C1500
Hello, I have a rather strange ( I think) problem with a TT C1500 card I just bought. When watching tv directly with 1 MythTV -> Watch TV 2 xine dvb:// 3 dvbstream -ps | mplayer - , all these methods of watching DVB directly gives a LOT of artifacts in picture and sound. (blocking mostly.) _But_ if i do dvbstream -ps > file.mpeg , and then mplayer or xine to play the file there is _no_ artifacts. This goes for both encrypted and non-encrypted channels . (CommonInterface and Conax CAM is intialized and seems to be working with my program card. . ) I even tried both knoppmyth and Mythdora (newest versions as of april 2007), end both have the same problem. Does anyone have a clue what could cause such behavior ? I have tried to increase the cache of mplayer to several megabytes, but with no difference. How should I proceed to find more relevant information , and / or identify if there is a problem / bug with the dvb drivers/libraries, or other things. Best regards Jarle Bjørgeengen ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] DST/BT878 module customization (.. was: Critical points about ...)
Uwe Bugla wrote: > Original-Nachricht > Datum: Wed, 02 May 2007 17:30:32 +0400 > Von: Manu Abraham <[EMAIL PROTECTED]> > An: Trent Piepho <[EMAIL PROTECTED]> > CC: Simon Arlott <[EMAIL PROTECTED]>, Linux Kernel Mailing list <[EMAIL > PROTECTED]>, [EMAIL PROTECTED], Jan Engelhardt <[EMAIL PROTECTED]>, [EMAIL > PROTECTED], [EMAIL PROTECTED], Linux DVB > Betreff: Re: [linux-dvb] DST/BT878 module customization (.. was: Critical > points about ...) > >> Trent Piepho wrote: >>> On Tue, 1 May 2007, Simon Arlott wrote: On 30/04/07 22:17, Markus Rechberger wrote: > From my side I do not see any problem with that patch, if someone else > has a problem with it please state out the reason. I have no problem with the patch since it has nothing to do with my DVB card but you're only encouraging Uwe to be abusive since it seems to help get him what he wants: >>> I've been aware of the problem with dst not fully using the dvb >> customization >>> systems(*) for a long time. It came up when dvb_attach() et al were >> first >>> being integrated, well before any rejected patches or strongly worded >> emails >>> or whatever from certain people that I'm aware of. >>> >> Well, your understanding of the device is quite limited and hence your >> comments and patches. >> >> The DST as it refers to is an embedded system a x86 Compatible RISC core >> [1] running at 20Mhz with 4MB Flash and 1MB RAM. The device has it's own >> IO and 2 DMA channels. What we have is a PQFP device >> >> This is the case in most cases. On some cheaper cards the embedded >> system is replaced by an 8 bit host microcontroller, to cut down costs >> where all the features are not required for a specific model >> >> Additionally this embedded system has a fast shovelling engine for the >> MPEG2 TS routing in between the >> This embedded system is connected to an actual >> (1) DVB frontend [2] >> (2) DVB CA interface [3] >> (3) Analog tuner >> (4) Audio interfaces >> >> These features are not the characteristics of a DVB Frontend. Here there >> is a DVB frontend like the normal ones which is hidden behind another >> pseudo bridge (So you don't have *any* access to the frontend at large) >> >> It is not necessary that *all* the dst cards (there are around ~15 >> different variants of the same) do have the very same feature set. >> >> It does support DVB-S/DSS/DVB-C/DVB-T/ATSC depending on the cards. In >> fact it is a combo driver supporting the entire devices using a common >> command set >> >> In such a case it has more characteristics of the PCI bridge and in fact >> heavily tied to it and has it's own advantages. >> >>> I saw some discussion about dst by Markus, Mauro, and Andrew Morton, and >> since >>> I already know about the issues here, I felt I should post a patch for >> them >>> any other reasonable developers who might spend time on this. >>> >> I would think that it would be *extremely* rude for a person to send in >> patches for a device that which you don't understand at all, when it is >> for limiting the capability of the said device > > Hi Manu, > now if this is your evalution about it all, then let me tell you that I feel > deeply sorry about it. > > Fact is: > Noone ever intended to send in patches limiting the capability of the said > device (DST): I never did, Trent never did, Markus, Mauro, Andrew and others > never did... > > Instead of this we all have very different knowledge and understanding > levels, with you obviously being the one with the most elaborate and > sophisticated level. > > So please why, instead of marking other people as "rude" whose solutions you > do not appreciate at all, don't you just pick up the pratical proposals of > other persons, even if you do not like them for some reasons, and at least > try to raise them up to a far more better level? > Thus you definitely could avoid a lots of flaming, misunderstanding, and > other counterproductive things to happen... > And this would conform to practising the synergetic principle, wouldn't it? > > Just one hint to help you: I remember a mail from Johannes in which he told > me that you started up this whole development thing from a zero level some > two or three years ago. And Johannes not forgot to state that in the > beginning you were nothing but nerving... (now add a smiley behind this, > please, I'd deeply appreciate you to do). > > Above that: > 1. Taking part in testing the mm-tree and eliminating horrible bugs in it I > never experienced but positive and warm compromise solutions in the end. > Experiencing this is highly enlarging one's own personality. > 2. If you start up at zero (like you did once too - see above and ask > Johannes if you do not remember at all) it is no good start at all if your > humble effort is being thrown off after the first or second reject. That's > highly discouraging, and if it happens very often the bad experience remains > in one's own subjective
Re: [linux-dvb] Problem with TT C1500
Jarle Bjørgeengen wrote: Hello, I have a rather strange ( I think) problem with a TT C1500 card I just bought. When watching tv directly with 1 MythTV -> Watch TV 2 xine dvb:// 3 dvbstream -ps | mplayer - , all these methods of watching DVB directly gives a LOT of artifacts in picture and sound. (blocking mostly.) _But_ if i do dvbstream -ps > file.mpeg , and then mplayer or xine to play the file there is _no_ artifacts. This goes for both encrypted and non-encrypted channels . (CommonInterface and Conax CAM is intialized and seems to be working with my program card. . ) I even tried both knoppmyth and Mythdora (newest versions as of april 2007), end both have the same problem. Does anyone have a clue what could cause such behavior ? Do you by any change have an NVIDIA graphics card? I had a similar problem a while ago with my HVR3000 DVB-S card. Recording to disk worked fine. But try to record and watch at the same time caused artifacts. I managed to track this down to two things. Firstly if I used the NVIDIA binary drivers, I had this problem, but if I used the "nv" driver I didn't. For me using the nv driver wasn't really an option (MythTV menus were horribly slow) Eventually I re-aligned my sat dish to get better reception and the problem went away even with the NVIDIA drivers. So it seems that somehow the NVIDIA graphics drivers were causing interferrence with the DVB-S capture card. A few things you can try to see if the problem is the same : 1) Start a recording to disk, wait for 10 seconds, then start playing back that file. See if the first 10 seconds of the recording are artifact free, and then artifacts start after 10 seconds have passed (when you started using the graphics) 2) Switch to the nv driver (if you using nvidia) and see if the problem goes away. 3) Start a recording to disk, and play back an entirely different recording - see if you get artifacts. 4) Check the quality output of szap (or whatever) and see if there is an increased BER, or drop off in signal quality while playing back video. Basically though, I never solved the problem of intereferrence, but since I improved my signal the effects don't have a detrimental effect on the recording. I think it's still the case that if the video card is busy then I get a slightly worse signal quality, but it's still "good enough" to not matter. Robert. ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] DST/BT878 module customization (.. was: Critical points about ...)
On 5/2/07, Manu Abraham <[EMAIL PROTECTED]> wrote: Uwe Bugla wrote: > Original-Nachricht > Datum: Wed, 02 May 2007 17:30:32 +0400 > Von: Manu Abraham <[EMAIL PROTECTED]> > An: Trent Piepho <[EMAIL PROTECTED]> > CC: Simon Arlott <[EMAIL PROTECTED]>, Linux Kernel Mailing list <[EMAIL PROTECTED]>, [EMAIL PROTECTED], Jan Engelhardt <[EMAIL PROTECTED]>, [EMAIL PROTECTED], [EMAIL PROTECTED], Linux DVB > Betreff: Re: [linux-dvb] DST/BT878 module customization (.. was: Criticalpoints about ...) > >> Trent Piepho wrote: >>> On Tue, 1 May 2007, Simon Arlott wrote: On 30/04/07 22:17, Markus Rechberger wrote: > From my side I do not see any problem with that patch, if someone else > has a problem with it please state out the reason. I have no problem with the patch since it has nothing to do with my DVB card but you're only encouraging Uwe to be abusive since it seems to help get him what he wants: >>> I've been aware of the problem with dst not fully using the dvb >> customization >>> systems(*) for a long time. It came up when dvb_attach() et al were >> first >>> being integrated, well before any rejected patches or strongly worded >> emails >>> or whatever from certain people that I'm aware of. >>> >> Well, your understanding of the device is quite limited and hence your >> comments and patches. >> >> The DST as it refers to is an embedded system a x86 Compatible RISC core >> [1] running at 20Mhz with 4MB Flash and 1MB RAM. The device has it's own >> IO and 2 DMA channels. What we have is a PQFP device >> >> This is the case in most cases. On some cheaper cards the embedded >> system is replaced by an 8 bit host microcontroller, to cut down costs >> where all the features are not required for a specific model >> >> Additionally this embedded system has a fast shovelling engine for the >> MPEG2 TS routing in between the >> This embedded system is connected to an actual >> (1) DVB frontend [2] >> (2) DVB CA interface [3] >> (3) Analog tuner >> (4) Audio interfaces >> >> These features are not the characteristics of a DVB Frontend. Here there >> is a DVB frontend like the normal ones which is hidden behind another >> pseudo bridge (So you don't have *any* access to the frontend at large) >> >> It is not necessary that *all* the dst cards (there are around ~15 >> different variants of the same) do have the very same feature set. >> >> It does support DVB-S/DSS/DVB-C/DVB-T/ATSC depending on the cards. In >> fact it is a combo driver supporting the entire devices using a common >> command set >> >> In such a case it has more characteristics of the PCI bridge and in fact >> heavily tied to it and has it's own advantages. >> >>> I saw some discussion about dst by Markus, Mauro, and Andrew Morton, and >> since >>> I already know about the issues here, I felt I should post a patch for >> them >>> any other reasonable developers who might spend time on this. >>> >> I would think that it would be *extremely* rude for a person to send in >> patches for a device that which you don't understand at all, when it is >> for limiting the capability of the said device > > Hi Manu, > now if this is your evalution about it all, then let me tell you that I feel deeply sorry about it. > > Fact is: > Noone ever intended to send in patches limiting the capability of the said device (DST): I never did, Trent never did, Markus, Mauro, Andrew and others never did... > > Instead of this we all have very different knowledge and understanding levels, with you obviously being the one with the most elaborate and sophisticated level. > > So please why, instead of marking other people as "rude" whose solutions you do not appreciate at all, don't you just pick up the pratical proposals of other persons, even if you do not like them for some reasons, and at least try to raise them up to a far more better level? > Thus you definitely could avoid a lots of flaming, misunderstanding, and other counterproductive things to happen... > And this would conform to practising the synergetic principle, wouldn't it? > > Just one hint to help you: I remember a mail from Johannes in which he told me that you started up this whole development thing from a zero level some two or three years ago. And Johannes not forgot to state that in the beginning you were nothing but nerving... (now add a smiley behind this, please, I'd deeply appreciate you to do). > > Above that: > 1. Taking part in testing the mm-tree and eliminating horrible bugs in it I never experienced but positive and warm compromise solutions in the end. Experiencing this is highly enlarging one's own personality. > 2. If you start up at zero (like you did once too - see above and ask Johannes if you do not remember at all) it is no good start at all if your humble effort is being thrown off after the first or second reject. That's highly discouraging, and if it happens very often the bad experience remains in one's own subjective perception filter
Re: [linux-dvb] en50221_tl_poll: CAWrite failed
> Am Mittwoch 02 Mai 2007 12:01 schrieb Simon Baxter:
> > > > > [EMAIL PROTECTED] gnutv]# ./gnutv -cammenu
> > > > > en50221_tl_poll: CAWrite failed
> > > > > en50221_stdcam_llci_poll: Error reported by stack:-2
> > > >
> > > > It is indeed not flaky hardware as i wrote earlier. -2 is timeout.
It
> > > > is due to a bug in debiread/write
> > >
> > Which lines should I comment in dvb_ca_en50221.c ???
> >
> > [EMAIL PROTECTED] v4l-dvb]# find . | grep dvb_ca_en50221.c
> > ./linux/drivers/media/dvb/dvb-core/dvb_ca_en50221.c
> > ./v4l/dvb_ca_en50221.c
>
> In dvb_ca_en50221_read_data outcomment this block:
>
> if (status & STATUSREG_RE) {
> ca->slot_info[slot].slot_state =
DVB_CA_SLOTSTATE_LINKINIT;
> status = -EIO;
> goto exit;
> }
>
> and this one in dvb_ca_en50221_write_data:
>
> if (status & (STATUSREG_DA | STATUSREG_RE)) {
> status = -EAGAIN;
> goto exitnowrite;
> }
>
> you might also try to outcomment this, also in dvb_ca_en50221_write_data:
>
> if (status & STATUSREG_WE) {
> ca->slot_info[slot].slot_state =
DVB_CA_SLOTSTATE_LINKINIT;
> status = -EIO;
> goto exit;
> }
>
> Pleas keep in mind that this just disables some error checks. Actually for
me
> it solved some troubles.
>
> Regards,
> Julian
I made the above changes, but still get the error??
[EMAIL PROTECTED] v4l-dvb]# gnutv -cammenu
en50221_tl_poll: CAWrite failed
en50221_stdcam_llci_poll: Error reported by stack:-2
STATUSREG_RE.patch
Description: Binary data
___
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
[linux-dvb] Where is i2c stuff from usbsnoop for Acorp DS120 DVB-S USB
I am curious, where is i2c stuff in this usbsnoop log file. I am grateful for any advice. Card is Acorp DS120 DVB-S USB2.0. (USB ID 04B4:2102) It contains: * Cypress CY7C68013 USB chip * Sharp BS2F7VZ0194A tuner with integrated STV0299B I'm afraid, without i2c, it will be allmost impossible to wright dvb-usb framework compliant driver for now. infokparsed.txt.tar.gz Description: application/tgz ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
[linux-dvb] HVR4000-"howto" ;)
Hi! I have a HVR4000 in yhe same computer as my other DVB-cards (that I'm using together with Myth) - I compiled stoth's HVR4000-tree but I couldn't of course insmod any modules because of a bunch unresolved symbols (I'm running 2.6.20-rc5). If I still want to use my other DVB-cards with Myth and I would like to do some testing with the HVR - how should I do? Can I use the HVR4000-tree for all cards and together with Myth? Thanks for any help. /Lars .___.____ .__ __| _/|__| ___/ |_|__|__ __ / __ | | |/ ___\_/ __ \ / ___/\ __\ \ \/ // __ \ / /_/ | | / /_/ > ___/ \___ \ | | | |\ /\ ___/ \ | |__\___ / \___ > > |__| |__| \_/ \___ > \/ /_/ \/ \/ \/ http://www.fredriksson.net/ :: http://digestive.mine.nu/ ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] inconsistent use of saa7146_pgtable_free?
On Wed, 2007-05-02 at 02:32 +0200, Oliver Endriss wrote:
> Jon Burgess wrote:
> > Sorry for the delay. I wanted to track down the DMA sync bug before I
> > came back to look at this again.
> >
> > I have added saa7146_vmalloc_destroy_pgtable() which frees the resources
>
> Shouldn't it better be called saa7146_vfree_destroy_pgtable()?
> ^
Sounds good. Implemented in the attached patch.
> > allocated by saa7146_vmalloc_build_pgtable() and updated the callers in
> > budget-core.c and av711o.c. I have also been through the updated
> > functions and updated the error paths to ensure they free all allocated
> > resources on error.
> >
> > Also included in this patch are the previous fixes for pci_unmap_sg()
> > and syncing the PCI streamed data to work with a SWIOTLB and match the
> > requirements documented in DMA-API.txt.
>
> Thanks, looks perfect.
>
> @all:
> Any comments?
>
> Btw, why did DMA work without pci_dma_sync_sg_for_cpu()
> on most machines?
It is probably the CPU cache snooping which happens on x86 to ensure
cache coherency. Most non-x86 architectures require manual cache
writeback and invalidation. Having cache coherency costs transistors,
power, design complexity etc. so RISC architectures avoid it at the
expense of a slightly more complex driver.
The 2003 OLS presentation "Integrating DMA Into the Generic Device
Model" has some more details and background.
http://licensing.steeleye.com/support/papers/ols_2003_dma.pdf
Jon
Signed-off-by: Jon Burgess <[EMAIL PROTECTED]>
diff -r e3779e21a314 linux/drivers/media/common/saa7146_core.c
--- a/linux/drivers/media/common/saa7146_core.c Tue May 01 10:48:09 2007 -0300
+++ b/linux/drivers/media/common/saa7146_core.c Tue May 01 21:54:19 2007 +0100
@@ -136,28 +136,45 @@ char *saa7146_vmalloc_build_pgtable(stru
char *mem = vmalloc_32(length);
int slen = 0;
- if (NULL == mem) {
- return NULL;
- }
-
- if (!(pt->slist = vmalloc_to_sg(mem, pages))) {
- vfree(mem);
- return NULL;
- }
-
- if (saa7146_pgtable_alloc(pci, pt)) {
- kfree(pt->slist);
- pt->slist = NULL;
- vfree(mem);
- return NULL;
- }
-
- slen = pci_map_sg(pci,pt->slist,pages,PCI_DMA_FROMDEVICE);
- if (0 != saa7146_pgtable_build_single(pci, pt, pt->slist, slen)) {
- return NULL;
- }
+ if (NULL == mem)
+ goto err_null;
+
+ if (!(pt->slist = vmalloc_to_sg(mem, pages)))
+ goto err_free_mem;
+
+ if (saa7146_pgtable_alloc(pci, pt))
+ goto err_free_slist;
+
+ pt->nents = pages;
+ slen = pci_map_sg(pci,pt->slist,pt->nents,PCI_DMA_FROMDEVICE);
+ if (0 == slen)
+ goto err_free_pgtable;
+
+ if (0 != saa7146_pgtable_build_single(pci, pt, pt->slist, slen))
+ goto err_unmap_sg;
return mem;
+
+err_unmap_sg:
+ pci_unmap_sg(pci, pt->slist, pt->nents, PCI_DMA_FROMDEVICE);
+err_free_pgtable:
+ saa7146_pgtable_free(pci, pt);
+err_free_slist:
+ kfree(pt->slist);
+ pt->slist = NULL;
+err_free_mem:
+ vfree(mem);
+err_null:
+ return NULL;
+}
+
+void saa7146_vfree_destroy_pgtable(struct pci_dev *pci, char *mem, struct saa7146_pgtable *pt)
+{
+ pci_unmap_sg(pci, pt->slist, pt->nents, PCI_DMA_FROMDEVICE);
+ saa7146_pgtable_free(pci, pt);
+ kfree(pt->slist);
+ pt->slist = NULL;
+ vfree(mem);
}
void saa7146_pgtable_free(struct pci_dev *pci, struct saa7146_pgtable *pt)
@@ -166,8 +183,6 @@ void saa7146_pgtable_free(struct pci_dev
return;
pci_free_consistent(pci, pt->size, pt->cpu, pt->dma);
pt->cpu = NULL;
- kfree(pt->slist);
- pt->slist = NULL;
}
int saa7146_pgtable_alloc(struct pci_dev *pci, struct saa7146_pgtable *pt)
@@ -532,6 +547,7 @@ EXPORT_SYMBOL_GPL(saa7146_pgtable_free);
EXPORT_SYMBOL_GPL(saa7146_pgtable_free);
EXPORT_SYMBOL_GPL(saa7146_pgtable_build_single);
EXPORT_SYMBOL_GPL(saa7146_vmalloc_build_pgtable);
+EXPORT_SYMBOL_GPL(saa7146_vfree_destroy_pgtable);
EXPORT_SYMBOL_GPL(saa7146_wait_for_debi_done);
EXPORT_SYMBOL_GPL(saa7146_setgpio);
diff -r e3779e21a314 linux/drivers/media/dvb/ttpci/av7110.c
--- a/linux/drivers/media/dvb/ttpci/av7110.c Tue May 01 10:48:09 2007 -0300
+++ b/linux/drivers/media/dvb/ttpci/av7110.c Tue May 01 22:29:11 2007 +0100
@@ -1245,6 +1245,9 @@ static void vpeirq(unsigned long data)
if (!budget->feeding1 || (newdma == olddma))
return;
+
+ /* Ensure streamed PCI data is synced to CPU */
+ pci_dma_sync_sg_for_cpu(budget->dev->pci, budget->pt.slist, budget->pt.nents, PCI_DMA_FROMDEVICE);
#if 0 /* keep */
/* track rps1 activity */
@@ -2679,8 +2682,8 @@ err_pci_free_5:
err_pci_free_5:
pci_free_consistent(pdev, 8192, av7110->debi_virt, av7110->debi_bus);
err_saa71466_vfree_4:
- if (!av7110->grabbing)
- saa7146_pgtable_free(pdev, &av7110->pt);
+ if (av7110->grabbing)
+ saa7146_vfree_destroy_pgtable(pdev, av7110->grabbing, &av7110->pt);
err_i2c_del_3:
i2c_del_adapter(&av7110->i2c_adap);
err_dvb_unregister_adapter_2:
@@ -2710,7 +2713,7 @@ static int __devexit av7110_detach(struc
SAA7146_ISR_CLEAR(saa, MASK_10);
msleep(50);
tasklet_kill(&av7110->vpe_tasklet);
- saa7146
Re: [linux-dvb] Indoor aerial for DVB-T
I think it is an interesting mail, so I copy it back in the mailing list. On 5/2/07, Tobias Stoeber <[EMAIL PROTECTED]> wrote: Regarding the "One For All" Aerial it seems, that it can be positioned either vertically or horizontally. So you should first try to (if you didn't already) to get to know, which polarisation the signal from your dvb-t station has. Make sure it's placed right, e.g. if its horizontally polarised it should be like in the small picture, if its vertically polarized it should be like in the large picture. I live in London, and I get signal from Crystal Palace, and I had better results with the horizontal position. Next I would try different location within the flat. Your aerial has a 20 dB amplifier. Unfortunately, if the original signal is bad / has much noise, a more powerful amplifier will not be of much help (you will just amplify the noise/interference as much a the signal itself). I think it is the case. Someone in the building mentioned that there is an iron structure that kills all signals. People at the lower floors have problems to tune a radio. Thanks for the info about the aerial. I'll try to understand better your message. It looks to me that there are different shapes, the one in your picture looks VERY different than the One For All, and the ones your linked from Amazon. Do you recommend a compact one (maybe more elegant) or a trditional shape? Or it does not matter? For some testing I would buy (or try to borrow) an large outdoor aerial and search for positions, where I would get I good signal. Then I would try to use an indoor or small outdoor aerial. I mysqlf use both an self-built log.-periodic dipole antenna/aerial (LPDA) and a small indoor aerial. A picture of the LPDA you'll find here (if my home server is online/working ;) - usually during working hours) http://www.extern.softclick-it.de/~tobi/public/tmp/dvbt/dvb-t-lpda-1-det.jpg http://www.extern.softclick-it.de/~tobi/public/tmp/dvbt/dvb-t-lpda-1.jpg The indoor antenna I bought was about 10 Euro (~7 £) and is a THOMSON ANT D220. I can really recommend it (but my LPDA is still a little bit better, but also larger [length 96 cm, height 32 cm]). In a test report (here in Germany from "Stiftung Warentest") your aerial scored 12th place out of 20 aerials, with resonable but not good reception (antenna gain). The Thomson got 3rd place (lost some points because it has some problems when mounted somewhere without screws due to it's thick cable - I just replaced it). Placed on 1st place was "Hirschmann Zifa D-16", 2nd "Philips SBC TT350". Thanks for the info. I've found a cheap 2nd hand of the Philips. I will try it. Maybe you can also have a look at the follwing models (sorry for the link from amazon.de in German): AXING 1603 with 25-27 dB amplifier http://www.amazon.de/Axing-Flachantenne-Zimmerantenne-geeignet-Verst%C3%A4rker/dp/B000KU1FJ0/ref=sr_1_23/302-4850549-8840012?ie=UTF8&s=ce-de&qid=1178060712&sr=8-23 Kathrein BZD 40 http://www.amazon.de/Kathrein-BZD-DVB-T-Outdoor-Antenne/dp/B000KPPXIO/ref=sr_1_43/302-4850549-8840012?ie=UTF8&s=ce-de&qid=1178060729&sr=8-43 Well, good luck! ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
[linux-dvb] Mantis driver with ivtv
Hello, I downloaded the mantis file from http://jusst.de/manu/mantis-v4l-dvb.tar.bz2. and used Marko's patch. I can watch FTA channels. The next step is to get my hauppauge 350 working again. It worked fine with ivtv 10.1 but since I installed v4l-dvb it doesn't work anymore. I also downloaded the latest v4l-dvb from cvs. It appears that ivtv is merged into v4l-dvb. When I install that one ivtv is also working. However there's no mantis driver in that one. So now I have 2 versions of v4l-dvb. One with support for the 1034 and the other one with support for the hauppauge 350. Can someone please tell me how I can use both cards at the same time? b.t.w. Great you are all still working on the mantis driver. Can't wait to try the CI when it's ready :) Thanx, Joep ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] HVR4000-"howto" ;)
On Wed, 2007-05-02 at 21:10 +0200, Lars Fredriksson wrote: > Hi! > > I have a HVR4000 in yhe same computer as my other DVB-cards (that I'm using > together with Myth) - I compiled stoth's HVR4000-tree but I couldn't of > course insmod any modules because of a bunch unresolved symbols (I'm running > 2.6.20-rc5). > > If I still want to use my other DVB-cards with Myth and I would like to do > some testing with the HVR - how should I do? Can I use the HVR4000-tree for > all cards and together with Myth? > > Thanks for any help. > > /Lars I'm not developer, and haven't work with the HVR4000-tree, so this can be wrong or stupid. You can try 'make unload', that should remove all modules bulit within the tree (even if loaded from kernel). "make load" will load all modules. Roland ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
[linux-dvb] (no subject)
Hi, Using Linux DVB api version 3, how do we access the hardware video decoder memory having decoded frames. Is it possible to access that memory and can we use the decoded frames ? -SS ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
[linux-dvb] how do we access the hardware video decoder memory
Hi, Using Linux DVB api version 3, how do we access the hardware video decoder memory having decoded frames. Is it possible to access that memory and can we use the decoded frames ? -SS ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] Problem with TT C1500
On Wed, 2 May 2007, Robert wrote: > I managed to track this down to two things. > > Firstly if I used the NVIDIA binary drivers, I had this problem, but if > I used the "nv" driver I didn't. For me using the nv driver wasn't > really an option (MythTV menus were horribly slow) I had this same problem (and so did others) with a pcHDTV HD-3000 ATSC card receiving QAM-256. With the nvidia binary driver, graphics activity would kill reception, while the nv driver didn't have this problem. 8-VSB reception, which doesn't need as high a SNR, is ok with the nvidia driver. I could run azap and watch the lock and SNR readings. If nothing was happening, they would be ok. But as soon as I moved a window around or started mplayer or scrolled an xterm, the SNR would drop and lock would be lost. I've seen reports that changing to a different power supply would fix the issue. Something about the nvidia graphics chip creating noise in the power supply rails, and a better power supply having better filtering. ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] want to work on the Pinnacle PCTV 200e
since I haven't received any answer yet, was the information I sent to you useful, otherwise I'll keep that device on my todolist for the next few weeks it doesn't seem to be undoable for a beginner at least.. Markus On 4/30/07, Jakob Steidl <[EMAIL PROTECTED]> wrote: Okay, the card has it's own page in the Wiki. Its already loaded with some information I could gather.. http://www.linuxtv.org/wiki/index.php/Pinnacle_PCTV_200e Markus Rechberger wrote: > Hi, > > can you put all your current information together onto a wikisite? > It shouldn't be hard to get that device work I have the same one but I > haven't had time to get my fingers on it yet... > I can give you some hints what to look at in the logfiles if you put > everything together somewhere. > > Markus > > On 4/28/07, Jakob Steidl <[EMAIL PROTECTED]> wrote: >> Hello, >> >> just like some other people, I want to use my above mentioned DVB-T >> adapter under Linux. As it seems one else is interested in writing a >> driver and since I've read this should be pretty easy, I think it's time >> to do it myself. -- Markus Rechberger ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] Problem with TT C1500
On Wed, 2007-05-02 at 17:48 +0100, Robert wrote: > Do you by any change have an NVIDIA graphics card? > I do indeed. Asus Pundit P1 with integrated Nvidia graphics. > So it seems that somehow the NVIDIA graphics drivers were causing > interferrence with the DVB-S capture card. > > A few things you can try to see if the problem is the same : > > 1) Start a recording to disk, wait for 10 seconds, then start playing > back that file. See if the first 10 seconds of the recording are > artifact free, and then artifacts start after 10 seconds have passed > (when you started using the graphics) > > 2) Switch to the nv driver (if you using nvidia) and see if the problem > goes away. > > 3) Start a recording to disk, and play back an entirely different > recording - see if you get artifacts. > > 4) Check the quality output of szap (or whatever) and see if there is an > increased BER, or drop off in signal quality while playing back video. > > Thanks for the tips. I'll try this. You wouldn't by any chance know of any good devices to amplify / clean DVB signal befor it's fed into the DVB-card ? I tried with an ordinary antenna amplifier , but that even made my settopbox , which normally works fine, go bananas too . - Jarle ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
[linux-dvb] Galaxis terminal : IDE connection
Hello, I'm using a DVB-C LinuxTv terminal called Galaxis. I bought it on Ebay and apparently it is made for the Austrian market. Everything works great on the French Cable! >From what I understood this terminal has a IDE connection for a hard drive. I opened the terminal and indeed I found the IDE plug. Though I didn't find the electrical plug for the hard drive. Does anybody own this terminal and tried to connect a hard drive? What would be the next step? Hard drive recognition by the BIOS? Software to install to be able to record TV shows? Thank you in advance. Patrick ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] Mantis driver with ivtv
joep admiraal schreef: Hello, I downloaded the mantis file from http://jusst.de/manu/mantis-v4l-dvb.tar.bz2. and used Marko's patch. I can watch FTA channels. The next step is to get my hauppauge 350 working again. It worked fine with ivtv 10.1 but since I installed v4l-dvb it doesn't work anymore. I also downloaded the latest v4l-dvb from cvs. It appears that ivtv is merged into v4l-dvb. When I install that one ivtv is also working. However there's no mantis driver in that one. So now I have 2 versions of v4l-dvb. One with support for the 1034 and the other one with support for the hauppauge 350. Can someone please tell me how I can use both cards at the same time? b.t.w. Great you are all still working on the mantis driver. Can't wait to try the CI when it's ready :) Thanx, Joep ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb Joep, Have a look at my mini howto http://www.verbraak.org/wiki/index.php/Linux_Mantis_driver In this I explain how I did it. Regards, Michel. ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
