Re: Questions to ngene/dvb_frontend driver [Original email was "Problems with ngene based DVB cards (Digital Devices Cine S2 Dual DVB-S2 , Mystique SaTiX S2 Dual)"]
Hi list, in addition to my previous tests, I found that the problems with long tuning delays only occurs when switching to an SD channel. If I switch to an HD channel, e.g., using adapter 0, I always get fast tuning times (see my tests below). Since the large delays only occur when switching to an SD channel, I have the following questions. 1) Is there different code for tuning to an HD channel or tuning to an SD-channel? 2) If yes, which which methods in which modules are repsonsible for tuning to an SD/HD channel? 3) Are there any methods wihtin the dvb_frontend oder ngene Modul (or anywhere in the DVB driver) that have to differ between SD- and HD channels? It would be realy great, if somone can answer these questions or give me some hints to find the problem. Best regards Michael Tests (channels_DVB-S2_transponder_switch_HD.conf and channels_DVB-S2_transponder_switch.conf are attached to this email): 1) Tune to a TV channel and forward data to dvr device ./szap-s2 -S 1 -H -c channels_DVB-S2_transponder_switch.conf -a 1 -n 1 -r 2) In paralle to1) use adapter 0 to tune to an HD-Kanal ./szap-s2 -H -c channels_DVB-S2_transponder_switch_HD.conf -a 0 -n 2 -x -S 1 | grep Delay Delay : 0.569672 3) In paralle to1) use adapter 0 to tune to an HD-Kanal ./szap-s2 -H -c channels_DVB-S2_transponder_switch_HD.conf -a 0 -n 1 -x -S 1 | grep Delay Delay : 0.581712 4) In paralle to1) use adapter 0 to tune to an SD-Kanal ./szap-s2 -H -c channels_DVB-S2_transponder_switch.conf -a 0 -n 1 -x | grep Delay Delay : 1.760880 Michael Repplinger wrote: > Hi, > I read the problems described in email thread "Problems with ngene based > DVB cards (Digital Devices Cine S2 Dual DVB-S2 , Mystique SaTiX S2 > Dual)". Unfortunately, I just subscribed to this list so I cannot > respond to the original mail directly but it can be found at the end of > this mail. > > For tracking down the described problems with high delays, I tried to > understand the dvb_frontend and ngene driver and added some output > messages. The added output messages are attached as a ptach to this > email. Since this was the first time I read the source code of the > module I was not able to find a real problem or bug. > > However, I found 3 issues that I would like to report. Especially issue > 1) could be a problem. Here the irq handler of ngene module is still > triggered for 60secs if the last application using the DVB devices > terminates. > In Issue 2) I describe the methods that need more time when the > described problem occur. Unfortunately, I could only determine that > these methods need more time but was not able to find a reason. > Issue 3) could be related to issue 1). Here I saw that the ngene module > is not informed if the DVB frontend device is closed. > > Again, since I read the source code of a driver for the first time I > don't know if the described issues are OK or not. It would be great if > some of you could check the described issues. Maybe this information > helps to find/solve the problem. > > Thanks in advance > Michael Repplinger > > Testsystem: > -Kernel: 2.6.25.20-0.5-pae (Suse 11.0 distribution) > -Driver: following endriss/ngene DVB driver + attached patch > *Repository URL : http://linuxtv.org/hg/~endriss/ngene > *Revision : 14413:510e37da759e > > *Issue 1) IRQ handler is triggered for 60 seconds after last > application stops using the dvb device:* > > Reproduce Test: > a) load dvb modules as follows: > rmmod ngene > rmmod dvb_core > > modprobe dvb_core dvbdev_debug=1 frontend_debug=1 debug=1 cam_debug=1 > dvb_demux_tscheck=1 dvb_net_debug=1 > modprobe ngene debug=1 one_adapter=0 > > b) tail -f /var/log/messages > c) In parallel to b) start >./szap-s2 -H -c channels_DVB-S2_transponder_switch.conf -a 0 -n 1 -x > > *Observation 1: * > In b) one can see the following output messages: > Mar 20 14:18:01 dvb_host kernel: ngene>: irq_handler IRQ 16 > Mar 20 14:18:01 dvb_host kernel: ngene< : irq_handler return IRQ_HANDLED > Mar 20 14:18:01 dvb_host kernel: ngene: demux_tasklet > Mar 20 14:18:01 dvb_host kernel: ngene: tsin_exchange > > => The following mehtods of ngene-core.c are called > - static irqreturn_t irq_handler(int irq, void *dev_id) ( produces the > first two lines of the above output messages) > - static void demux_tasklet(unsigned long data) ( produces the third > lines of the above output messages) > - static void *tsin_exchange(void *priv, void *buf, u32 len, u32 clock, > u32 flags) (procudes the last output message) > > => IRQ handler of ngene-core module is periodically triggered as soon as the > first application using DVB device has been used > > *Observation 2: * > Exactly 60 seconds after executing c), the IRQ handler is no longer > triggered > and no more output messages appear in b). > Here the last output messages are: > > Mar 20 14:19:01 dvb_host kernel: ngene< : irq_handler return IRQ_HANDLED > Mar 20 14:19:01 dvb_host kernel: ngene: demux_tasklet > Mar 20 14:19:01 dvb_ho
Questions to ngene/dvb_frontend driver [Original email was "Problems with ngene based DVB cards (Digital Devices Cine S2 Dual DVB-S2 , Mystique SaTiX S2 Dual)"]
Hi, I read the problems described in email thread "Problems with ngene based DVB cards (Digital Devices Cine S2 Dual DVB-S2 , Mystique SaTiX S2 Dual)". Unfortunately, I just subscribed to this list so I cannot respond to the original mail directly but it can be found at the end of this mail. For tracking down the described problems with high delays, I tried to understand the dvb_frontend and ngene driver and added some output messages. The added output messages are attached as a ptach to this email. Since this was the first time I read the source code of the module I was not able to find a real problem or bug. However, I found 3 issues that I would like to report. Especially issue 1) could be a problem. Here the irq handler of ngene module is still triggered for 60secs if the last application using the DVB devices terminates. In Issue 2) I describe the methods that need more time when the described problem occur. Unfortunately, I could only determine that these methods need more time but was not able to find a reason. Issue 3) could be related to issue 1). Here I saw that the ngene module is not informed if the DVB frontend device is closed. Again, since I read the source code of a driver for the first time I don't know if the described issues are OK or not. It would be great if some of you could check the described issues. Maybe this information helps to find/solve the problem. Thanks in advance Michael Repplinger Testsystem: -Kernel: 2.6.25.20-0.5-pae (Suse 11.0 distribution) -Driver: following endriss/ngene DVB driver + attached patch *Repository URL : http://linuxtv.org/hg/~endriss/ngene *Revision : 14413:510e37da759e *Issue 1) IRQ handler is triggered for 60 seconds after last application stops using the dvb device:* Reproduce Test: a) load dvb modules as follows: rmmod ngene rmmod dvb_core modprobe dvb_core dvbdev_debug=1 frontend_debug=1 debug=1 cam_debug=1 dvb_demux_tscheck=1 dvb_net_debug=1 modprobe ngene debug=1 one_adapter=0 b) tail -f /var/log/messages c) In parallel to b) start ./szap-s2 -H -c channels_DVB-S2_transponder_switch.conf -a 0 -n 1 -x *Observation 1: * In b) one can see the following output messages: Mar 20 14:18:01 dvb_host kernel: ngene>: irq_handler IRQ 16 Mar 20 14:18:01 dvb_host kernel: ngene< : irq_handler return IRQ_HANDLED Mar 20 14:18:01 dvb_host kernel: ngene: demux_tasklet Mar 20 14:18:01 dvb_host kernel: ngene: tsin_exchange => The following mehtods of ngene-core.c are called - static irqreturn_t irq_handler(int irq, void *dev_id) ( produces the first two lines of the above output messages) - static void demux_tasklet(unsigned long data) ( produces the third lines of the above output messages) - static void *tsin_exchange(void *priv, void *buf, u32 len, u32 clock, u32 flags) (procudes the last output message) => IRQ handler of ngene-core module is periodically triggered as soon as the first application using DVB device has been used *Observation 2: * Exactly 60 seconds after executing c), the IRQ handler is no longer triggered and no more output messages appear in b). Here the last output messages are: Mar 20 14:19:01 dvb_host kernel: ngene< : irq_handler return IRQ_HANDLED Mar 20 14:19:01 dvb_host kernel: ngene: demux_tasklet Mar 20 14:19:01 dvb_host kernel: ngene: tsin_exchange Mar 20 14:19:01 dvb_host kernel: ngene: ngene_i2c_master_xfer Mar 20 14:19:01 dvb_host kernel: ngene: > ngene_i2x_set_bus Mar 20 14:19:01 dvb_host kernel: ngene: ngene_i2c_set_bus Mar 20 14:19:01 dvb_host kernel: ngene: < ngene_i2x_set_bus Mar 20 14:19:01 dvb_host kernel: ngene: num = 1 ngene_command_i2c_write Mar 20 14:19:01 dvb_host kernel: ngene: ngene_command_i2c_write Mar 20 14:19:01 dvb_host kernel: ngene: ngene_command Mar 20 14:19:01 dvb_host kernel: ngene: ngene_command_mutex Mar 20 14:19:01 dvb_host kernel: ngene>: irq_handler IRQ 16 Mar 20 14:19:01 dvb_host kernel: ngene< : irq_handler return IRQ_HANDLED Mar 20 14:19:01 dvb_host kernel: ngene>: irq_handler IRQ 16 Mar 20 14:19:01 dvb_host kernel: ngene< : irq_handler return IRQ_HANDLED Mar 20 14:19:01 dvb_host kernel: ngene: ngene_i2c_master_xfer succeeded => In this case, the mehtod ngene_i2c_master_xfer is invoked and successfully processed (additional invoked methods can also be seen from the output). *Conclusion: * Since I dont understand whats going on here, I don't know if this is correct or could cause problems. However, I would expect that the IRQ handler is not triggered, if no application accesses the DVB device. Moreover, after 60 seconds the IRQ trigger is no longer triggered. This looks like the kernel (or any other module) stops the ngene-module. *Issue 2) High delay ~(1.7-18 seconds) when switching the channel * By enabling and adding additional output messages in used dvb modules, I was able to find the mehtod that causes a higher delay. Reproduce Test: a) load dvb modules as follows: rmmod ngene rmmod dvb_core modprobe dvb_core dvbdev_debug=1 frontend_debug=1 debug=
