Re: HVR-900H dvb-t regression(s)
On 11/28/2011 10:07 PM, Mauro Carvalho Chehab wrote: Btw, Stefan sent some fixes to the ML. I'll test if the patch solves the audio issue with HVR-900H on analog mode. I just finished testing those ones and they seem to fix my specific issue. There is still one thing that puzzles me, but maybe it´s just my misunderstanding on how dvb-t protocol works. root@cerberus:~# scan -a 0 /home/fabbione/dk scanning /home/fabbione/dk using '/dev/dvb/adapter0/frontend0' and '/dev/dvb/adapter0/demux0' initial transponder 58600 0 2 9 3 1 3 0 tune to: 58600:INVERSION_AUTO:BANDWIDTH_8_MHZ:FEC_2_3:FEC_AUTO:QAM_64:TRANSMISSION_MODE_8K:GUARD_INTERVAL_1_4:HIERARCHY_NONE 0x 0x0065: pmt_pid 0x0065 DR -- DR1 (running) 0x 0x00d9: pmt_pid 0x0835 TV 2 -- TV 2 (Lorry) (running) 0x 0x01a1: pmt_pid 0x0191 DIGI-TV -- Hovedstaden (running) 0x 0x0066: pmt_pid 0x00c9 DR -- DR2 (running) 0x 0x006f: pmt_pid 0x0068 DR -- DR Synstolkning (running) 0x 0x0051: pmt_pid 0x0051 DIGI-TV -- OAD MUX1 (running) Network Name 'Mux1 kbhv-glx' tune to: 73000:INVERSION_AUTO:BANDWIDTH_8_MHZ:FEC_2_3:FEC_2_3:QAM_64:TRANSMISSION_MODE_8K:GUARD_INTERVAL_1_4:HIERARCHY_NONE WARNING: filter timeout pid 0x0011 WARNING: filter timeout pid 0x WARNING: filter timeout pid 0x0010 dumping lists (6 services) OAD MUX1:58600:INVERSION_AUTO:BANDWIDTH_8_MHZ:FEC_2_3:FEC_AUTO:QAM_64:TRANSMISSION_MODE_8K:GUARD_INTERVAL_1_4:HIERARCHY_NONE:0:0:81 DR1:58600:INVERSION_AUTO:BANDWIDTH_8_MHZ:FEC_2_3:FEC_AUTO:QAM_64:TRANSMISSION_MODE_8K:GUARD_INTERVAL_1_4:HIERARCHY_NONE:111:121:101 DR2:58600:INVERSION_AUTO:BANDWIDTH_8_MHZ:FEC_2_3:FEC_AUTO:QAM_64:TRANSMISSION_MODE_8K:GUARD_INTERVAL_1_4:HIERARCHY_NONE:211:221:102 DR Synstolkning:58600:INVERSION_AUTO:BANDWIDTH_8_MHZ:FEC_2_3:FEC_AUTO:QAM_64:TRANSMISSION_MODE_8K:GUARD_INTERVAL_1_4:HIERARCHY_NONE:111:122:111 TV 2 (Lorry):58600:INVERSION_AUTO:BANDWIDTH_8_MHZ:FEC_2_3:FEC_AUTO:QAM_64:TRANSMISSION_MODE_8K:GUARD_INTERVAL_1_4:HIERARCHY_NONE:2111:2121:217 Hovedstaden:58600:INVERSION_AUTO:BANDWIDTH_8_MHZ:FEC_2_3:FEC_AUTO:QAM_64:TRANSMISSION_MODE_8K:GUARD_INTERVAL_1_4:HIERARCHY_NONE:411:421:417 Done. In my dk file I only specify: root@cerberus:~# cat /home/fabbione/dk # Denmark, whole country # Created from http://www.digi-tv.dk/Indhold_og_tilbud/frekvenser.asp # and http://www.digi-tv.dk/Sendenettets_opbygning/ # T freq bw fec_hi fec_lo mod transmission-mode guard-interval hierarchy T 58600 8MHz 2/3 NONE QAM64 8k 1/4 NONE because for simple testing I don´t need to scan the whole spectrum. Now, in some versions of the driver, it automatically picks up 730MHz (I know it´s a good frequency in the area as I get it at my home and shares the same channels as 586). What I noticed is that sometimes it tunes and time outs, sometime it tunes and scan correctly, but with the latest driver from HEAD, it failed completely to tune with the usual error. Not sure if this info might be relevant. As for analog I am not able to even get scantv to find the channel broadcasted from the VCR. I´ll need to investigate if it´s a problem with the VCR/tuner/driver etc. (there is no analog broadcast in dk). So far this is what I get: scantv -n PAL-DK -f europe-west -c /dev/video0 -C /dev/null [global] freqtab = europe-west [defaults] input = Television norm = PAL-DK ioctl: VIDIOC_S_CTRL(id=9963778;value=0): Inappropriate ioctl for device ioctl: VIDIOC_S_CTRL(id=9963776;value=0): Inappropriate ioctl for device ioctl: VIDIOC_S_CTRL(id=9963779;value=0): Inappropriate ioctl for device ioctl: VIDIOC_S_CTRL(id=9963777;value=130): Inappropriate ioctl for device scanning channel list europe-west... E2 ( 48.25 MHz): ioctl: VIDIOC_S_CTRL(id=9963785;value=1): Inappropriate ioctl for device ioctl: VIDIOC_S_CTRL(id=9963785;value=0): Inappropriate ioctl for device no station (repeat the above for every single channel and no channels found) The result is pretty much the same with or without tm6000-dvb loaded. Fabio -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: HVR-900H dvb-t regression(s)
On 11/29/2011 12:35 PM, Mauro Carvalho Chehab wrote: On 29-11-2011 02:53, Fabio M. Di Nitto wrote: [ 7867.776612] tm6000: Found Generic tm6010 board [ 7867.841177] tm6000 #1: i2c eeprom 00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [SNIP] [ 7869.707769] Device has eeprom but is currently unknown and the device will be miss-detected. I don't think this was ever the case, but I can easily check the dmesg output that I collected. This may affect your bisect tests. The eeprom was never 00 all the way. You can fix it by forcing the driver to use card=9 via modprobe option. Btw, Stefan sent some fixes to the ML. I'll test if the patch solves the audio issue with HVR-900H on analog mode. Ok, I'll try to grab them. It appears that mail relay from linux-media to my inbox is not reliable. I've applied them yesterday. tested them already, I sent the results in another email. As for the analog, I should be able to test it today. On the tests I've made yesterday after applying Stefan and my patches, analog is working fine. Audio got corrected by the patches for MSC (the audio standard used on NTSC and PAL-M). I tested here with both NTSC and PAL-M standards, and it worked as expected. There are some fixes applied yesterday that are related to DTV. One of them fixes the alloc function call used for the DVB streaming buffer inside the USB stack: - ret = usb_submit_urb(dvb-bulk_urb, GFP_KERNEL); + ret = usb_submit_urb(dvb-bulk_urb, GFP_ATOMIC); The usage of GFP_KERNEL there may fail, causing failures at the DVB stream. I'm now seeing if I can make the IR work on HVR-900H. No luck with analog here, but I need to do more investigation as the source might be broken all together. Fabio -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
HVR-900H dvb-t regression(s)
Hi all, short summary is that dvb-t on $subject doesn´t work with head of the tree (for_3.3 branch) and scan or mplayer stop working. Here is the breakdown of what I found with all logs. Please let me know if you need any extra info. Can easily test patches and gather more logs if necessary. Also please note that I am no media guru of any kind. I had to work on some assumptions from time to time. Based on git bisect: The last known good commit is e872bb9a7ddfc025ed727cc922b0aa32a7582004 The first known bad commit is f010dca2e52d8dcc0445d695192df19241afacdb commit f010dca2e52d8dcc0445d695192df19241afacdb Author: Stefan Ringel stefan.rin...@arcor.de Date: Mon May 9 16:53:58 2011 -0300 [media] tm6000: move from tm6000_set_reg to tm6000_set_reg_mask move from tm6000_set_reg to tm6000_set_reg_mask Signed-off-by: Stefan Ringel stefan.rin...@arcor.de Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com While this commit appears rather innocent, it changes the way some registries are set. the original code did: read_reg... change value write_reg.. (unconditionally) the new code path: read_reg... calculate new value check if it is same if not, write_reg... So I did the simplest test as possible by removing the conditional in tm6000_set_reg_mask and dvb-t started working again. something along those lines: diff --git a/drivers/media/video/tm6000/tm6000-core.c b/drivers/media/video/tm6000/tm6000-core.c index 9783616..818f542 100644 --- a/drivers/media/video/tm6000/tm6000-core.c +++ b/drivers/media/video/tm6000/tm6000-core.c @@ -132,8 +132,8 @@ int tm6000_set_reg_mask(struct tm6000_core *dev, u8 req, u16 value, new_index = (buf[0] ~mask) | (index mask); - if (new_index == index) - return 0; +// if (new_index == index) +// return 0; return tm6000_read_write_usb(dev, USB_DIR_OUT | USB_TYPE_VENDOR, req, value, new_index, NULL, 0); but moving this change to the HEAD of for_v3.3 doesn´t solve the problem, possibly hinting to multiple regressions in the driver but at this point I am slightly lost because i can´t figure out what else is wrong. Some semi-random git bisect didn´t bring me anywhere useful at this point. In an poor attempt to be a good boy, I collected all the data here: http://fabbione.fedorapeople.org/dvblogs.tar.xz (NOTE: 76MB file, 101MB unpacked) The file contains 5 dirs: last-known-good-e872bb9a7ddfc025ed727cc922b0aa32a7582004 first-known-bad-f010dca2e52d8dcc0445d695192df19241afacdb test1-change-set-reg-mask-f010dca2e52d8dcc0445d695192df19241afacdb+ head-known-bad-7e5219d18e93dd23e834a53b1ea73ead19cfeeb1 test2-change-set-reg-mask-7e5219d18e93dd23e834a53b1ea73ead19cfeeb1+ and each directory has: dmesg scan_results tcpdump (tcpdump -i usbmod1 -w tcpdump) usbmon0u (cat /sys usbmod0u) captures are started before modprobe tm6000-dvb and stop after a scan -a 0 dk The testX are marked + as they contain the workaround mentioned above (test1 also adds a build workaround fixed a few commits later in the tree to unexport a symbol). Thanks Fabio -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: HVR-900H dvb-t regression(s)
On 11/28/2011 10:07 PM, Mauro Carvalho Chehab wrote: On 28-11-2011 12:41, Fabio M. Di Nitto wrote: Hi all, short summary is that dvb-t on $subject doesn´t work with head of the tree (for_3.3 branch) and scan or mplayer stop working. Here is the breakdown of what I found with all logs. Please let me know if you need any extra info. Can easily test patches and gather more logs if necessary. Also please note that I am no media guru of any kind. I had to work on some assumptions from time to time. Based on git bisect: The last known good commit is e872bb9a7ddfc025ed727cc922b0aa32a7582004 The first known bad commit is f010dca2e52d8dcc0445d695192df19241afacdb commit f010dca2e52d8dcc0445d695192df19241afacdb Author: Stefan Ringelstefan.rin...@arcor.de Date: Mon May 9 16:53:58 2011 -0300 [media] tm6000: move from tm6000_set_reg to tm6000_set_reg_mask move from tm6000_set_reg to tm6000_set_reg_mask Signed-off-by: Stefan Ringelstefan.rin...@arcor.de Signed-off-by: Mauro Carvalho Chehabmche...@redhat.com While this commit appears rather innocent, it changes the way some registries are set. the original code did: read_reg... change value write_reg.. (unconditionally) the new code path: read_reg... calculate new value check if it is same if not, write_reg... So I did the simplest test as possible by removing the conditional in tm6000_set_reg_mask and dvb-t started working again. something along those lines: diff --git a/drivers/media/video/tm6000/tm6000-core.c b/drivers/media/video/tm6000/tm6000-core.c index 9783616..818f542 100644 --- a/drivers/media/video/tm6000/tm6000-core.c +++ b/drivers/media/video/tm6000/tm6000-core.c @@ -132,8 +132,8 @@ int tm6000_set_reg_mask(struct tm6000_core *dev, u8 req, u16 value, new_index = (buf[0] ~mask) | (index mask); - if (new_index == index) - return 0; +// if (new_index == index) +// return 0; return tm6000_read_write_usb(dev, USB_DIR_OUT | USB_TYPE_VENDOR, req, value, new_index, NULL, 0); but moving this change to the HEAD of for_v3.3 doesn´t solve the problem, possibly hinting to multiple regressions in the driver but at this point I am slightly lost because i can´t figure out what else is wrong. Some semi-random git bisect didn´t bring me anywhere useful at this point. Hmm... It occurred to me that HVR-900H has a bug at device initialization. Sometimes, after a device connect it can't read anything from eeprom. As result, it will print: [ 7867.776612] tm6000: Found Generic tm6010 board [ 7867.841177] tm6000 #1: i2c eeprom 00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [SNIP] [ 7869.707769] Device has eeprom but is currently unknown and the device will be miss-detected. I don't think this was ever the case, but I can easily check the dmesg output that I collected. You can fix it by forcing the driver to use card=9 via modprobe option. Btw, Stefan sent some fixes to the ML. I'll test if the patch solves the audio issue with HVR-900H on analog mode. Ok, I'll try to grab them. It appears that mail relay from linux-media to my inbox is not reliable. As for the analog, I should be able to test it today. Fabio -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
