* HVR-1600 - unable to find tuner @ 2008-09-20 10:52 Dale Pontius 2008-09-21 1:43 ` Andy Walls 0 siblings, 1 reply; 6+ messages in thread From: Dale Pontius @ 2008-09-20 10:52 UTC (permalink / raw) To: video4linux-list I've been having mail problems recently, both at my ISP and my server, so if this is a dupe, I apologize. A week back I posted a "newby question," and eventually it became apparent that I can't find my tuner. Though I have a supposedly good (PCI-2.3) motherboard, I loaded the module with: "modprobe cx18 mmio_ndelay=61" The results of dmesg: cx18: Start initialization, version 1.0.0 cx18-0: Initializing card #0 cx18-0: Autodetected Hauppauge card ACPI: PCI Interrupt 0000:05:08.0[A] -> Link [APC3] -> GSI 18 (level, low) -> IRQ 18 cx18-0: Unreasonably low latency timer, setting to 64 (was 32) cx18-0: cx23418 revision 01010000 (B) tveeprom 6-0050: Hauppauge model 74041, rev C6B2, serial# 3334244 tveeprom 6-0050: MAC address is 00-0D-FE-32-E0-64 tveeprom 6-0050: tuner model is TCL M2523_5N_E (idx 112, type 50) tveeprom 6-0050: TV standards NTSC(M) (eeprom 0x08) tveeprom 6-0050: audio processor is CX23418 (idx 38) tveeprom 6-0050: decoder processor is CX23418 (idx 31) tveeprom 6-0050: has no radio, has IR receiver, has IR transmitter cx18-0: Autodetected Hauppauge HVR-1600 cx18-0: VBI is not yet supported cs5345 6-004c: chip found @ 0x98 (cx18 i2c driver #0-0) cx18-0: Disabled encoder IDX device cx18-0: Registered device video1 for encoder MPEG (2 MB) DVB: registering new adapter (cx18) MXL5005S: Attached at address 0x63 DVB: registering frontend 0 (Samsung S5H1409 QAM/8VSB Frontend)... cx18-0: DVB Frontend registered cx18-0: Registered device video32 for encoder YUV (2 MB) cx18-0: Registered device video24 for encoder PCM audio (1 MB) cx18-0: Initialized card #0: Hauppauge HVR-1600 cx18: End initialization Then thinking about the i2c problems, and not easily finding any sort of "i2c-explorer" or "lsi2c" I went probing around in "/sys/class/i2c-adapter". The card shows up as i2c-6 and i2c-7: (cat i2c-*/name) SMBus nForce2 adapter at 4c00 SMBus nForce2 adapter at 4c40 bt878 #0 [sw] NVIDIA i2c adapter NVIDIA i2c adapter NVIDIA i2c adapter cx18 i2c driver #0-0 cx18 i2c driver #0-1 (Even though it says "SMBus nForce2" it's really nForce4.) The i2c-6 bus is the cs5345: i2c-6: total 0 drwxr-xr-x 3 root root 0 Sep 19 19:33 6-004c lrwxrwxrwx 1 root root 0 Sep 19 19:33 device -> ../../../devices/pci0000:00/0000:00:09.0/0000:05:08.0 -r--r--r-- 1 root root 4096 Sep 19 19:33 name (cx18 i2c driver #0-0) drwxr-xr-x 2 root root 0 Sep 19 19:33 power lrwxrwxrwx 1 root root 0 Sep 19 19:33 subsystem -> ../../i2c-adapter -rw-r--r-- 1 root root 4096 Sep 19 19:33 uevent i2c-6/6-004c: total 0 lrwxrwxrwx 1 root root 0 Sep 19 19:33 bus -> ../../../../bus/i2c lrwxrwxrwx 1 root root 0 Sep 19 19:33 driver -> ../../../../bus/i2c/drivers/cs5345 -r--r--r-- 1 root root 4096 Sep 19 19:33 modalias (cs5345) -r--r--r-- 1 root root 4096 Sep 19 19:33 name ( ) drwxr-xr-x 2 root root 0 Sep 19 19:33 power lrwxrwxrwx 1 root root 0 Sep 19 19:33 subsystem -> ../../../../bus/i2c -rw-r--r-- 1 root root 4096 Sep 19 19:33 uevent i2c-6/6-004c/power: total 0 -rw-r--r-- 1 root root 4096 Sep 19 19:33 wakeup i2c-6/power: total 0 -rw-r--r-- 1 root root 4096 Sep 19 19:33 wakeup The i2c-7 bus is the cx18: i2c-7: total 0 lrwxrwxrwx 1 root root 0 Sep 19 19:34 device -> ../../../devices/pci0000:00/0000:00:09.0/0000:05:08.0 -r--r--r-- 1 root root 4096 Sep 19 19:33 name drwxr-xr-x 2 root root 0 Sep 19 19:34 power lrwxrwxrwx 1 root root 0 Sep 19 19:34 subsystem -> ../../i2c-adapter -rw-r--r-- 1 root root 4096 Sep 19 19:34 uevent i2c-7/power: total 0 -rw-r--r-- 1 root root 4096 Sep 19 19:34 wakeup And there's a bit more information under i2c-7/device/: .: total 0 -rw-r--r-- 1 root root 4096 Sep 19 19:38 broken_parity_status lrwxrwxrwx 1 root root 0 Sep 19 06:22 bus -> ../../../../bus/pci -r--r--r-- 1 root root 4096 Sep 19 19:38 class -rw-r--r-- 1 root root 256 Sep 19 19:38 config -r--r--r-- 1 root root 4096 Sep 19 19:38 device lrwxrwxrwx 1 root root 0 Sep 19 19:38 driver -> ../../../../bus/pci/drivers/cx18 lrwxrwxrwx 1 root root 0 Sep 19 19:38 dvb:dvb0.demux0 -> ../../../../class/dvb/dvb0.demux0 lrwxrwxrwx 1 root root 0 Sep 19 19:38 dvb:dvb0.dvr0 -> ../../../../class/dvb/dvb0.dvr0 lrwxrwxrwx 1 root root 0 Sep 19 19:38 dvb:dvb0.frontend0 -> ../../../../class/dvb/dvb0.frontend0 lrwxrwxrwx 1 root root 0 Sep 19 19:38 dvb:dvb0.net0 -> ../../../../class/dvb/dvb0.net0 -rw------- 1 root root 4096 Sep 19 19:38 enable lrwxrwxrwx 1 root root 0 Sep 19 19:38 i2c-adapter:i2c-6 -> ../../../../class/i2c-adapter/i2c-6 lrwxrwxrwx 1 root root 0 Sep 19 19:38 i2c-adapter:i2c-7 -> ../../../../class/i2c-adapter/i2c-7 -r--r--r-- 1 root root 4096 Sep 19 19:38 irq -r--r--r-- 1 root root 4096 Sep 19 19:38 local_cpus -r--r--r-- 1 root root 4096 Sep 19 19:38 modalias -rw-r--r-- 1 root root 4096 Sep 19 19:38 msi_bus drwxr-xr-x 2 root root 0 Sep 19 06:30 power -r--r--r-- 1 root root 4096 Sep 19 06:22 resource -rw------- 1 root root 67108864 Sep 19 19:38 resource0 lrwxrwxrwx 1 root root 0 Sep 19 19:38 subsystem -> ../../../../bus/pci -r--r--r-- 1 root root 4096 Sep 19 19:38 subsystem_device -r--r--r-- 1 root root 4096 Sep 19 19:38 subsystem_vendor -rw-r--r-- 1 root root 4096 Sep 19 06:22 uevent -r--r--r-- 1 root root 4096 Sep 19 19:38 vendor lrwxrwxrwx 1 root root 0 Sep 19 19:38 video4linux:video1 -> ../../../../class/video4linux/video1 lrwxrwxrwx 1 root root 0 Sep 19 19:38 video4linux:video24 -> ../../../../class/video4linux/video24 lrwxrwxrwx 1 root root 0 Sep 19 19:38 video4linux:video32 -> ../../../../class/video4linux/video32 ./power: total 0 -rw-r--r-- 1 root root 4096 Sep 19 06:30 wakeup I understand that both tuners are supposed to be attached to the i2c bus of the cx18, and it's pretty clear that the ATSC/QAM tuner is there. But other than the "video4linux:video1" I don't see anything that smacks of the NTSC tuner. Can someone tell me what this is supposed to look like, or suggest a next step in finding my tuner? Thanks, Dale Pontius -- video4linux-list mailing list Unsubscribe mailto:video4linux-list-request@redhat.com?subject=unsubscribe https://www.redhat.com/mailman/listinfo/video4linux-list ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: HVR-1600 - unable to find tuner 2008-09-20 10:52 HVR-1600 - unable to find tuner Dale Pontius @ 2008-09-21 1:43 ` Andy Walls 2008-09-22 1:53 ` Dale Pontius 0 siblings, 1 reply; 6+ messages in thread From: Andy Walls @ 2008-09-21 1:43 UTC (permalink / raw) To: Dale Pontius; +Cc: video4linux-list On Sat, 2008-09-20 at 06:52 -0400, Dale Pontius wrote: > A week back I posted a "newby question," and eventually it became > apparent that I can't find my tuner. > I loaded the module with: > "modprobe cx18 mmio_ndelay=61" You can always try higher numbers to see if things get better at some higher value. Use multiples of 30.3. > The results of dmesg: > cx18: Start initialization, version 1.0.0 > cx18-0: Initializing card #0 > cx18-0: Autodetected Hauppauge card > ACPI: PCI Interrupt 0000:05:08.0[A] -> Link [APC3] -> GSI 18 (level, low) -> IRQ 18 > cx18-0: Unreasonably low latency timer, setting to 64 (was 32) > cx18-0: cx23418 revision 01010000 (B) > tveeprom 6-0050: Hauppauge model 74041, rev C6B2, serial# 3334244 > tveeprom 6-0050: MAC address is 00-0D-FE-32-E0-64 > tveeprom 6-0050: tuner model is TCL M2523_5N_E (idx 112, type 50) > tveeprom 6-0050: TV standards NTSC(M) (eeprom 0x08) > tveeprom 6-0050: audio processor is CX23418 (idx 38) > tveeprom 6-0050: decoder processor is CX23418 (idx 31) > tveeprom 6-0050: has no radio, has IR receiver, has IR transmitter > cx18-0: Autodetected Hauppauge HVR-1600 > cx18-0: VBI is not yet supported > cs5345 6-004c: chip found @ 0x98 (cx18 i2c driver #0-0) > cx18-0: Disabled encoder IDX device > cx18-0: Registered device video1 for encoder MPEG (2 MB) > DVB: registering new adapter (cx18) > MXL5005S: Attached at address 0x63 > DVB: registering frontend 0 (Samsung S5H1409 QAM/8VSB Frontend)... > cx18-0: DVB Frontend registered > cx18-0: Registered device video32 for encoder YUV (2 MB) > cx18-0: Registered device video24 for encoder PCM audio (1 MB) > cx18-0: Initialized card #0: Hauppauge HVR-1600 > cx18: End initialization Just FYI, the CX23418 has 2 I2C masters built into it, so it contributes two new, separate i2c buses to your system. In this case i2c-6 and i2c-7 are the two buses on your system. The two I2C devices that correspond to the analog NTSC tuner (a mixer/osc chip and an IF demodulator chip) should be on the second i2c bus (i2c-7 or cx18 i2c driver #0-1). All the other devices are on the first i2c bus. > Then thinking about the i2c problems, and not easily finding any sort > of "i2c-explorer" or "lsi2c" For a handy i2c explorer tool you can use i2cdetect from the lm_sensors or i2c-tools package. You must also have the i2c-dev module built. Modprobe the i2c-dev module, have i2cdetect list the buses, then run i2cdetect to probe all the addresses on the i2c buses of the cx18 based card. Analog tuner mixer/osc chips will show up in the low 0x60's (0x60, 0x61 IIRC). > I understand that both tuners are supposed to be attached to the i2c > bus of the cx18, and it's pretty clear that the ATSC/QAM tuner is > there. But other than the "video4linux:video1" I don't see > anything that smacks of the NTSC tuner. > > Can someone tell me what this is supposed to look like, The init messages in dmesg for my HVR-1600 MCE shows the mixer/osc is at 0x61 (0xc2) and the IF demodulator is at 0x43 (0x86) and that they are both on the second i2c bus: cx18 #0-1: tuner 1-0043: chip found @ 0x86 (cx18 i2c driver #0-1) tda9887 1-0043: creating new instance tda9887 1-0043: tda988[5/6/7] found tuner 1-0061: chip found @ 0xc2 (cx18 i2c driver #0-1) tuner-simple 1-0061: creating new instance tuner-simple 1-0061: type set to 43 (Philips NTSC MK3 (FM1236MK3 or FM1236/F)) The MCE version has a tda9887 IF demodulator which supports FM radio. Your non-MCE card, without FM radio, may have something a little different for an IF demodulator chip. > or suggest a next step in finding my tuner? 1. Make sure you have tuner modules installed somewhere under /lib/modules (i.e. tuner.ko, tuner-simple.ko, etc.) 2. Turn on some debugging in /etc/modprobe.conf: options tuner debug=1 show_i2c=1 options tuner-simple debug=1 options cx18 debug=67 and see, if on module load, something obviously looks wrong. 3. You can increase the msecs_asserted and msecs_recovery in linux/drivers/media/video/cx18/cx18-cards.c and the mdelays() in linux/drivers/media/video/cx18/cx18-i2c.c to some ridiculously high numbers (e.g. 100 msec) to make sure everything connected to the I2C buses gets reset. (Obviously rebuild and reinstall the cx18.ko module.) 4. As I mentioned before, you may just need to set the mmio_ndelay number higher. From my observations, the CX23418 appears to have a problem when accessing one set of its registers and then jumping to access registers in a different part of its register address space with no "dead time" in between. The control registers for the first and second I2C bus masters are about 64k apart, and, of course, accessed almost back to back during module initialization. The mmio_ndelay parameter adds in the "dead time" the CX23418 occasionally seems to need. Good luck. Andy > Thanks, > Dale Pontius -- video4linux-list mailing list Unsubscribe mailto:video4linux-list-request@redhat.com?subject=unsubscribe https://www.redhat.com/mailman/listinfo/video4linux-list ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: HVR-1600 - unable to find tuner 2008-09-21 1:43 ` Andy Walls @ 2008-09-22 1:53 ` Dale Pontius 2008-09-24 0:57 ` Andy Walls 0 siblings, 1 reply; 6+ messages in thread From: Dale Pontius @ 2008-09-22 1:53 UTC (permalink / raw) To: Andy Walls; +Cc: video4linux-list Andy Walls wrote: > On Sat, 2008-09-20 at 06:52 -0400, Dale Pontius wrote: > >> A week back I posted a "newby question," and eventually it became >> apparent that I can't find my tuner. > >> I loaded the module with: >> "modprobe cx18 mmio_ndelay=61" > > You can always try higher numbers to see if things get better at some > higher value. Use multiples of 30.3. > Things look a litte different with "modprobe cx18 mmio_ndelay=182 debug=67", and I've also added the other debug parameters you suggest later. With that, here's my dmesg: --------------------------------------------------------------------------- cx18-0: Autodetected Hauppauge HVR-1600 cx18-0 info: NTSC tuner detected cx18-0: VBI is not yet supported cx18-0 info: Loaded module tuner cx18-0 info: Loaded module cs5345 cx18-0 i2c: i2c client register cx18-0 i2c: i2c client register cs5345 6-004c: chip found @ 0x98 (cx18 i2c driver #0-0) cx18-0 info: Allocate encoder MPEG stream: 63 x 32768 buffers (2016kB total) cx18-0 info: Allocate TS stream: 32 x 32768 buffers (1024kB total) cx18-0 info: Allocate encoder YUV stream: 16 x 131072 buffers (2048kB total) cx18-0 info: Allocate encoder PCM audio stream: 63 x 16384 buffers (1008kB total) cx18-0: Disabled encoder IDX device cx18-0: Registered device video1 for encoder MPEG (2 MB) DVB: registering new adapter (cx18) MXL5005S: Attached at address 0x63 DVB: registering frontend 0 (Samsung S5H1409 QAM/8VSB Frontend)... cx18-0: DVB Frontend registered cx18-0: Registered device video32 for encoder YUV (2 MB) cx18-0: Registered device video24 for encoder PCM audio (1 MB) cx18-0: Initialized card #0: Hauppauge HVR-1600 cx18: End initialization tuner' 2-0061: tv freq set to 463.25 tuner-simple 2-0061: using tuner params #0 (ntsc) tuner-simple 2-0061: freq = 463.25 (7412), range = 2, config = 0x8e, cb = 0x08 tuner-simple 2-0061: Freq= 463.25 MHz, V_IF=45.75 MHz, Offset=0.00 MHz, div=8144 tuner-simple 2-0061: tv 0x1f 0xd0 0x8e 0x08 tuner' 2-0061: tv freq set to 463.25 tuner-simple 2-0061: using tuner params #0 (ntsc) tuner-simple 2-0061: freq = 463.25 (7412), range = 2, config = 0x8e, cb = 0x08 tuner-simple 2-0061: Freq= 463.25 MHz, V_IF=45.75 MHz, Offset=0.00 MHz, div=8144 tuner-simple 2-0061: tv 0x1f 0xd0 0x8e 0x08 tuner' 2-0061: tv freq set to 463.25 tuner-simple 2-0061: using tuner params #0 (ntsc) tuner-simple 2-0061: freq = 463.25 (7412), range = 2, config = 0x8e, cb = 0x08 tuner-simple 2-0061: Freq= 463.25 MHz, V_IF=45.75 MHz, Offset=0.00 MHz, div=8144 tuner-simple 2-0061: tv 0x1f 0xd0 0x8e 0x08 tuner' 2-0061: tv freq set to 463.25 tuner-simple 2-0061: using tuner params #0 (ntsc) tuner-simple 2-0061: freq = 463.25 (7412), range = 2, config = 0x8e, cb = 0x08 tuner-simple 2-0061: Freq= 463.25 MHz, V_IF=45.75 MHz, Offset=0.00 MHz, div=8144 tuner-simple 2-0061: tv 0x1f 0xd0 0x8e 0x08 tuner' 2-0061: tv freq set to 463.25 tuner-simple 2-0061: using tuner params #0 (ntsc) tuner-simple 2-0061: freq = 463.25 (7412), range = 2, config = 0x8e, cb = 0x08 tuner-simple 2-0061: Freq= 463.25 MHz, V_IF=45.75 MHz, Offset=0.00 MHz, div=8144 tuner-simple 2-0061: tv 0x1f 0xd0 0x8e 0x08 tuner' 2-0061: tv freq set to 463.25 tuner-simple 2-0061: using tuner params #0 (ntsc) tuner-simple 2-0061: freq = 463.25 (7412), range = 2, config = 0x8e, cb = 0x08 tuner-simple 2-0061: Freq= 463.25 MHz, V_IF=45.75 MHz, Offset=0.00 MHz, div=8144 tuner-simple 2-0061: tv 0x1f 0xd0 0x8e 0x08 tuner' 2-0061: tv freq set to 463.25 tuner-simple 2-0061: using tuner params #0 (ntsc) tuner-simple 2-0061: freq = 463.25 (7412), range = 2, config = 0x8e, cb = 0x08 tuner-simple 2-0061: Freq= 463.25 MHz, V_IF=45.75 MHz, Offset=0.00 MHz, div=8144 tuner-simple 2-0061: tv 0x1f 0xd0 0x8e 0x08 cx18-0 info: load segment a00000-a07fff cx18-0 info: load segment ae0000-ae00ff cx18-0 info: load segment b00000-b1a65f cx18-0: loaded v4l-cx23418-apu.fw firmware V00120000 (141200 bytes) cx18-0: loaded v4l-cx23418-cpu.fw firmware (158332 bytes) cx18-0 info: 1 MiniMe Encoder Firmware 0.0.74.0 (Release 2007/03/12) cx18-0: FW version: 0.0.74.0 (Release 2007/03/12) cx18-0 info: load segment a00000-a07fff cx18-0 info: load segment ae0000-ae00ff cx18-0 info: load segment b00000-b1a65f cx18-0 info: 1 MiniMe Encoder Firmware 0.0.74.0 (Release 2007/03/12) cx18-0 info: Changing input from 1 to 0 cx18-0 info: Mute cx18-0 info: cmd 4008646f triggered fw load cx18-0: loaded v4l-cx23418-dig.fw firmware (16382 bytes) cx18-0 info: decoder set video input 7, audio input 8 cx18-0 i2c: call_i2c_client addr=4c cx18-0 info: decoder set video input 7, audio input 8 cx18-0 info: Unmute cx18-0 info: Switching standard to 1000. cx18-0 info: changing video std to fmt 1 cx18-0 info: PLL regs = int: 15, frac: 2876158, post: 4 cx18-0 info: PLL = 0.000011 MHz cx18-0 info: PLL/8 = 0.000001 MHz cx18-0 info: ADC Sampling freq = 0.000001 MHz cx18-0 info: Chroma sub-carrier freq = 0.000000 MHz cx18-0 info: hblank 122, hactive 720, vblank 26 , vactive 487, vblank656 26, src_dec 543,burst 0x5b, luma_lpf 1, uv_lpf 1, comb 0x66, sc 0x087c1f cx18-0 info: Mute cx18-0 info: v4l2 ioctl: set frequency 1076 cx18-0 info: Unmute --------------------------------------------------------------------------- I'm getting some noise about a tuner, but apparently not enough. My bttv card attaches its tuner before (I've got the cx18 blacklisted, so it won't autoload.) this, and it gives more informative messages about the tuner, more similar to what you show. There appears to be info here about what the tuner is doing, but nothing about the tuner, itself. As for your later suggestions, I've set msecs_asserted=100, msecs_recovery=200, and mdelay(100), and the dmesg shows no significant difference. All subsequent stuff is with the tweaked driver. Incidentally, "v4l2-ctl -d /dev/video1 --log-status" gives: --------------------------------------------------------------------------- Status Log: cx18-0: ================= START STATUS CARD #0 ================= tveeprom 6-0050: Hauppauge model 74041, rev C6B2, serial# 3334244 tveeprom 6-0050: MAC address is 00-0D-FE-32-E0-64 tveeprom 6-0050: tuner model is TCL M2523_5N_E (idx 112, type 50) tveeprom 6-0050: TV standards NTSC(M) (eeprom 0x08) tveeprom 6-0050: audio processor is CX23418 (idx 38) tveeprom 6-0050: decoder processor is CX23418 (idx 31) tveeprom 6-0050: has no radio, has IR receiver, has IR transmitter cx18-0: Video signal: not present cx18-0: Detected format: NTSC-M cx18-0: Specified standard: NTSC-M cx18-0: Specified video input: Composite 7 cx18-0: Specified audioclock freq: 32000 Hz cx18-0: Detected audio mode: mono cx18-0: Detected audio standard: no detected audio standard cx18-0: Audio muted: yes cx18-0: Audio microcontroller: running cx18-0: Configured audio standard: automatic detection cx18-0: Configured audio system: BTSC cx18-0: Specified audio input: Tuner (In8) cx18-0: Preferred audio mode: stereo cs5345 6-004c: Input: 1 cs5345 6-004c: Volume: 0 dB cx18-0: Video Input: Tuner 1 cx18-0: Audio Input: Tuner 1 cx18-0: GPIO: direction 0x00003001, value 0x00003001 cx18-0: Tuner: TV cx18-0: Stream: MPEG-2 Program Stream cx18-0: VBI Format: No VBI cx18-0: Video: 480x480, 30 fps cx18-0: Video: MPEG-2, 4x3, Variable Bitrate, 4500000, Peak 6000000 cx18-0: Video: GOP Size 15, 2 B-Frames, GOP Closure cx18-0: Audio: 32 kHz, MPEG-1/2 Layer II, 384 kbps, Stereo, No Emphasis, No CRC cx18-0: Spatial Filter: Manual, Luma 1D Horizontal, Chroma 1D Horizontal, 0 cx18-0: Temporal Filter: Manual, 0 cx18-0: Median Filter: Off, Luma [0, 255], Chroma [0, 255] cx18-0: Status flags: 0x00200001 cx18-0: Stream encoder MPEG: status 0x0000, 0% of 2016 KiB (63 buffers) in use cx18-0: Stream encoder YUV: status 0x0000, 0% of 2048 KiB (16 buffers) in use cx18-0: Stream encoder PCM audio: status 0x0000, 0% of 1008 KiB (63 buffers) in use cx18-0: Read MPEG/VBI: 23478272/0 bytes cx18-0: ================== END STATUS CARD #0 ================== --------------------------------------------------------------------------- Still "Video signal: not present". The resolution is odd, but that's because MythTV has touched it. I notice that the format is "NTSC-M" instead of "NTSC", but am not sure if that's significant. Lastly, I'm not sure how much sense this makes, "i2cdetect -y 7" : --------------------------------------------------------------------------- 0 1 2 3 4 5 6 7 8 9 a b c d e f 00: -- -- -- -- -- -- -- -- -- -- -- -- -- 10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 70: -- -- -- -- -- -- -- -- --------------------------------------------------------------------------- Rather indicates that nothing is there, but I suspect I did something wrong. It did seem to detect a tuner, and besides the tuner the other messages appeared to be OK. Incidentally, this was done with the tweaked values in the source code. I'm wondering if either my bttv card is interfering somehow, or if this card needs to be RMA'ed. I have another identical card in an unopened box, if it's time to try that. I'll have to check the doc to see if Win98SE is supported, but I don't have a handy WinXP machine to try this in. My cunning plan was to move to the dual Hauppauge cards because I figured I couldn't do software encoding with 2 simple cards in one box. The HVR-1600 left me ready for the cutover, and MythTV with a "strategy" for sticking with my old TVs. Thanks, Dale Pontius >> or suggest a next step in finding my tuner? > > 1. Make sure you have tuner modules installed somewhere > under /lib/modules (i.e. tuner.ko, tuner-simple.ko, etc.) > > 2. Turn on some debugging in /etc/modprobe.conf: > > options tuner debug=1 show_i2c=1 > options tuner-simple debug=1 > options cx18 debug=67 > > and see, if on module load, something obviously looks wrong. > > 3. You can increase the msecs_asserted and msecs_recovery in > linux/drivers/media/video/cx18/cx18-cards.c and the mdelays() in > linux/drivers/media/video/cx18/cx18-i2c.c to some ridiculously high > numbers (e.g. 100 msec) to make sure everything connected to the I2C > buses gets reset. (Obviously rebuild and reinstall the cx18.ko module.) > > 4. As I mentioned before, you may just need to set the mmio_ndelay > number higher. From my observations, the CX23418 appears to have a > problem when accessing one set of its registers and then jumping to > access registers in a different part of its register address space with > no "dead time" in between. The control registers for the first and > second I2C bus masters are about 64k apart, and, of course, accessed > almost back to back during module initialization. The mmio_ndelay > parameter adds in the "dead time" the CX23418 occasionally seems to > need. > > > Good luck. > > Andy > >> Thanks, >> Dale Pontius > -- video4linux-list mailing list Unsubscribe mailto:video4linux-list-request@redhat.com?subject=unsubscribe https://www.redhat.com/mailman/listinfo/video4linux-list ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: HVR-1600 - unable to find tuner 2008-09-22 1:53 ` Dale Pontius @ 2008-09-24 0:57 ` Andy Walls 2008-09-24 1:48 ` Dale Pontius 0 siblings, 1 reply; 6+ messages in thread From: Andy Walls @ 2008-09-24 0:57 UTC (permalink / raw) To: Dale Pontius; +Cc: video4linux-list On Sun, 2008-09-21 at 21:53 -0400, Dale Pontius wrote: > Andy Walls wrote: > > On Sat, 2008-09-20 at 06:52 -0400, Dale Pontius wrote: > > > >> A week back I posted a "newby question," and eventually it became > >> apparent that I can't find my tuner. > > > >> I loaded the module with: > >> "modprobe cx18 mmio_ndelay=61" > > > > You can always try higher numbers to see if things get better at some > > higher value. Use multiples of 30.3. > > > > Things look a litte different with "modprobe cx18 mmio_ndelay=182 debug=67", > and I've also added the other debug parameters you suggest later. With that, > here's my dmesg: > --------------------------------------------------------------------------- > cx18-0: Autodetected Hauppauge HVR-1600 > cx18-0 info: NTSC tuner detected This message means the driver has likely parsed the EEPROM properly and thinks you have an NTSC tuner (which you should). > cx18-0: VBI is not yet supported > cx18-0 info: Loaded module tuner > cx18-0 info: Loaded module cs5345 > cx18-0 i2c: i2c client register That was the analog tuner I2C device registration message. You should have seen: "tuner n-0061: chip found @ 0xc2 (cx18 i2c driver #0-1)" if the tuner driver had found an analog tuner (mixer/oscillator chip) responding on the proper I2C bus on this card. This likely means the very last call to i2c_new_probed_device() at the bottom of cx18-i2c.c:cx18_i2c_register() is failing to return a successful probe of the tuner device. > cx18-0 i2c: i2c client register > cs5345 6-004c: chip found @ 0x98 (cx18 i2c driver #0-0) > cx18-0 info: Allocate encoder MPEG stream: 63 x 32768 buffers (2016kB > total) [snip] > tuner' 2-0061: tv freq set to 463.25 > tuner-simple 2-0061: using tuner params #0 (ntsc) > tuner-simple 2-0061: freq = 463.25 (7412), range = 2, config = 0x8e, cb = 0x08 > tuner-simple 2-0061: Freq= 463.25 MHz, V_IF=45.75 MHz, Offset=0.00 MHz, div=8144 > tuner-simple 2-0061: tv 0x1f 0xd0 0x8e 0x08 [snip] I'm not sure what to make of these repeated tunes to US cable channel 64. I wouldn't expect it to happen on cx18 driver initialization. [snip] > cx18-0 info: Switching standard to 1000. > cx18-0 info: changing video std to fmt 1 > cx18-0 info: PLL regs = int: 15, frac: 2876158, post: 4 > cx18-0 info: PLL = 0.000011 MHz > cx18-0 info: PLL/8 = 0.000001 MHz > cx18-0 info: ADC Sampling freq = 0.000001 MHz > cx18-0 info: Chroma sub-carrier freq = 0.000000 MHz > cx18-0 info: hblank 122, hactive 720, vblank 26 , vactive 487, vblank656 26, src_dec 543,burst 0x5b, luma_lpf 1, uv_lpf 1, comb 0x66, sc 0x087c1f > cx18-0 info: Mute > cx18-0 info: v4l2 ioctl: set frequency 1076 This is an attempt to tune to US broadcast and cable channel 4. The driver tries to do this at the end of initialization. If the command actually went to a tuner driver, and the tuner and tuner-simple modules had debugging set, you should have seen more messages like the previous tunes but to 67.25 MHz. For reference, here is the full log from my non-MCE HVR-1600 being initialized with the following set in /etc/modprobe.conf: options tuner show_i2c=1 debug=1 options tuner-simple debug=1 and doing # modprobe cx18 debug=67 (with some minor changes in my stuff to do with video buffers) cx18: Start initialization, version 1.0.0 cx18-0: Initializing card #0 cx18-0: Autodetected Hauppauge card cx18-0 info: base addr: 0xf8000000 cx18-0 info: Enabling pci device ACPI: PCI Interrupt 0000:03:03.0[A] -> GSI 21 (level, low) -> IRQ 21 cx18-0 info: cx23418 (rev 0) at 03:03.0, irq: 21, latency: 64, memory: 0xf8000000 cx18-0 info: attempting ioremap at 0xf8000000 len 0x04000000 cx18-0: cx23418 revision 01010000 (B) cx18-0 info: GPIO initial dir: 0000cffe/0000ffff out: 00003001/00000000 cx18-0 info: activating i2c... cx18-0 i2c: i2c init cx18-0 info: Active card count: 1. tveeprom 0-0050: Hauppauge model 74041, rev C5B2, serial# 891351 tveeprom 0-0050: MAC address is 00-0D-FE-0D-99-D7 tveeprom 0-0050: tuner model is TCL M2523_5N_E (idx 112, type 50) tveeprom 0-0050: TV standards NTSC(M) (eeprom 0x08) tveeprom 0-0050: audio processor is CX23418 (idx 38) tveeprom 0-0050: decoder processor is CX23418 (idx 31) tveeprom 0-0050: has no radio, has IR receiver, has IR transmitter cx18-0: Autodetected Hauppauge HVR-1600 cx18-0 info: NTSC tuner detected cx18-0: VBI is not yet supported cx18-0 info: Loaded module tuner cx18-0 info: Loaded module cs5345 cx18-0 i2c: i2c client register tuner 2-0061: I2C RECV = 79 79 79 79 79 79 79 79 79 79 79 79 79 79 79 79 tuner 2-0061: Setting mode_mask to 0x0e tuner 2-0061: chip found @ 0xc2 (cx18 i2c driver #0-1) tuner 2-0061: tuner 0x61: Tuner type absent cx18-0 i2c: i2c client register cs5345 0-004c: chip found @ 0x98 (cx18 i2c driver #0-0) tuner 2-0061: Calling set_type_addr for type=50, addr=0xff, mode=0x04, config=0x32 tuner-simple 2-0061: creating new instance tuner-simple 2-0061: type set to 50 (TCL 2002N) tuner-simple 2-0061: tuner 0 atv rf input will be autoselected tuner-simple 2-0061: tuner 0 dtv rf input will be autoselected tuner 2-0061: type set to TCL 2002N tuner 2-0061: tv freq set to 400.00 tuner-simple 2-0061: desired params (pal) undefined for tuner 50 tuner-simple 2-0061: using tuner params #0 (ntsc) tuner-simple 2-0061: freq = 400.00 (6400), range = 1, config = 0x8e, cb = 0x02 tuner-simple 2-0061: Freq= 400.00 MHz, V_IF=38.93 MHz, Offset=0.00 MHz, div=7023 tuner-simple 2-0061: tv 0x1b 0x6f 0x8e 0x02 tuner 2-0061: cx18 i2c driver #0-1 tuner I2C addr 0xc2 with type 50 used for 0x0e cx18-0 info: Allocate encoder MPEG stream: 63 x 8192 buffers (504kB total) cx18-0 info: Allocate TS stream: 63 x 8192 buffers (504kB total) cx18-0 info: Allocate encoder YUV stream: 8 x 131072 buffers (1024kB total) cx18-0 info: Allocate encoder PCM audio stream: 63 x 6144 buffers (378kB total) cx18-0: Disabled encoder IDX device cx18-0: Registered device video0 for encoder MPEG (63 x 8 kiB) DVB: registering new adapter (cx18) cx18-0 info: load segment a00000-a07fff cx18-0 info: load segment ae0000-ae00ff cx18-0 info: load segment b00000-b1a65f cx18-0: loaded v4l-cx23418-apu.fw firmware V00120000 (141200 bytes) MXL5005S: Attached at address 0x63 DVB: registering frontend 0 (Samsung S5H1409 QAM/8VSB Frontend)... cx18-0: Registered DVB adapter0 for TS (63 x 8 kiB) cx18-0: Registered device video32 for encoder YUV (8 x 128 kiB) cx18-0: Registered device video24 for encoder PCM audio (63 x 6 kiB) cx18-0: Initialized card #0: Hauppauge HVR-1600 cx18: End initialization cx18-0: loaded v4l-cx23418-cpu.fw firmware (158332 bytes) cx18-0 info: 1 MiniMe Encoder Firmware 0.0.74.0 (Release 2007/03/12) cx18-0: FW version: 0.0.74.0 (Release 2007/03/12) cx18-0 info: load segment a00000-a07fff cx18-0 info: load segment ae0000-ae00ff cx18-0 info: load segment b00000-b1a65f cx18-0 info: 1 MiniMe Encoder Firmware 0.0.74.0 (Release 2007/03/12) cx18-0 info: Changing input from 1 to 0 cx18-0 info: Mute cx18-0 info: cmd 4008646f triggered fw load cx18-0: loaded v4l-cx23418-dig.fw firmware (16382 bytes) cx18-0 info: decoder set video input 7, audio input 8 cx18-0 i2c: call_i2c_client addr=4c cx18-0 info: decoder set video input 7, audio input 8 cx18-0 info: Unmute cx18-0 info: Switching standard to 1000. cx18-0 info: changing video std to fmt 1 cx18-0 info: PLL regs = int: 15, frac: 2876158, post: 4 cx18-0 info: PLL = 0.000011 MHz cx18-0 info: PLL/8 = 0.000001 MHz cx18-0 info: ADC Sampling freq = 0.000001 MHz cx18-0 info: Chroma sub-carrier freq = 0.000000 MHz cx18-0 info: hblank 122, hactive 720, vblank 26 , vactive 487, vblank656 26, src_dec 543,burst 0x5b, luma_lpf 1, uv_lpf 1, comb 0x66, sc 0x087c1f tuner 2-0061: switching to v4l2 tuner 2-0061: tv freq set to 400.00 tuner-simple 2-0061: using tuner params #0 (ntsc) tuner-simple 2-0061: freq = 400.00 (6400), range = 1, config = 0x8e, cb = 0x02 tuner-simple 2-0061: Freq= 400.00 MHz, V_IF=45.75 MHz, Offset=0.00 MHz, div=7132 tuner-simple 2-0061: tv 0x1b 0xdc 0x8e 0x02 cx18-0 info: Mute cx18-0 info: v4l2 ioctl: set frequency 1076 tuner 2-0061: tv freq set to 67.25 tuner-simple 2-0061: using tuner params #0 (ntsc) tuner-simple 2-0061: freq = 67.25 (1076), range = 0, config = 0x8e, cb = 0x01 tuner-simple 2-0061: Freq= 67.25 MHz, V_IF=45.75 MHz, Offset=0.00 MHz, div=1808 tuner-simple 2-0061: tv 0x8e 0x01 0x07 0x10 cx18-0 info: Unmute > I'm getting some noise about a tuner, but apparently not enough. My bttv > card attaches its tuner before (I've got the cx18 blacklisted, so it won't > autoload.) this, and it gives more informative messages about the tuner, more > similar to what you show. There appears to be info here about what the tuner > is doing, but nothing about the tuner, itself. For testing, I'd try blacklisting the bttv driver too. That way you can try to modprobe the cx18 driver before any other driver has tried to load the tuner modules. I'm kind of in the dark about why > As for your later suggestions, I've set msecs_asserted=100, msecs_recovery=200, > and mdelay(100), and the dmesg shows no significant difference. All subsequent > stuff is with the tweaked driver. OK. That should have really ensured hardware on the I2C buses was reset. > Incidentally, "v4l2-ctl -d /dev/video1 --log-status" gives: > --------------------------------------------------------------------------- > Status Log: > [snip] Your log info showed no tuner status lines. This is a further indication that the driver doesn't have a tuner device of it's own registered properly. > I notice that the format is "NTSC-M" instead of "NTSC", > but am not sure if that's significant. That just means the driver read that you have an NTSC-M system tuner via the EEPROM chip. The standard M system is appropriate for almost all NTSC broadcasts except in Japan and South Korea (IIRC). > Lastly, I'm not sure how much sense this makes, "i2cdetect -y 7" : > --------------------------------------------------------------------------- > 0 1 2 3 4 5 6 7 8 9 a b c d e f > 00: -- -- -- -- -- -- -- -- -- -- -- -- -- > 10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- > 20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- > 30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- > 40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- > 50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- > 60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- > 70: -- -- -- -- -- -- -- -- > --------------------------------------------------------------------------- > Rather indicates that nothing is there, but I suspect I did something wrong. > It did seem to detect a tuner, and besides the tuner the other messages > appeared to be OK. Incidentally, this was done with the tweaked values in > the source code. Well there should be only one tuner (mixer/oscillator) chip on that 2nd i2c bus on the HVR-1600 bus. The output of i2cdetect, assuming you queried the correct bus, says that no chip is responding anywhere on that bus, nor has any address on that bus been claimed by a driver. This could be because the tuner's actually bad, or simply not responding for some reason (i.e. the reset sequence with mdelay()'s at the end of cx18-i2c.c didn't work), or the CX23418 chip is not responding properly on the PCI bus when querying it's I2C control registers for the second I2C bus (weird since everything else looks to be working). For reference, here's output from my working HVR-1600 # modprobe i2c-dev # i2cdetect -l i2c-1 smbus SMBus PIIX4 adapter at 0b00 SMBus adapter i2c-0 i2c cx18 i2c driver #0-0 I2C adapter i2c-2 i2c cx18 i2c driver #0-1 I2C adapter # i2cdetect -y 0 0 1 2 3 4 5 6 7 8 9 a b c d e f 00: -- -- -- -- -- -- -- -- -- -- -- -- -- 10: -- -- -- -- -- -- -- -- -- 19 -- -- -- -- -- -- 20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 40: -- -- -- -- -- -- -- -- -- -- -- -- UU -- -- -- 50: 50 -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 60: -- -- -- 63 -- -- -- -- -- -- -- -- -- -- -- -- 70: 70 71 72 73 -- -- -- -- (IIRC 19 = cx25447 4c = cs5345 UU = device has been claimed by a driver 50 = ATMEL eeprom 63 = mxl5005s 70-73 = Z8F0811 IR microcontroller) # i2cdetect -y 2 0 1 2 3 4 5 6 7 8 9 a b c d e f 00: -- -- -- -- -- -- -- -- -- -- -- -- -- 10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 60: -- UU -- -- -- -- -- -- -- -- -- -- -- -- -- -- 70: -- -- -- -- -- -- -- -- 61 = simple tuner mixer/oscillator chip UU = device has been claimed by a driver > I'm wondering if either my bttv card is interfering somehow, If you got all '--' on the i2cdetect of the correct i2c bus on the HVR-1600, then it really can't be the bttv driver, AFAICT. For testing, I'm going to try to implement another, agressive PCI bus access algorithm for accessing the CX23418 instead of using simple delays with mmio_ndelay. I don't have a definite schedule on this yet. I'm not hopeful that it will help though, seeing as your CX23418 seems to behaving well otherwise (no -121 errors, can always read the eeprom, always loads the firmware, always can init the ATSC side of the card, etc.). > or if this card > needs to be RMA'ed. Try it in a Windows installation first. > I have another identical card in an unopened box, if it's > time to try that. I suspect it may behave differently (manufacturing variations). If your second card works, it doesn't mean your first card is broken though. It may mean the cx18 driver needs to do something differently. Make sure the first card doesn't work in Windows as well before returning (if possible). > Thanks, > Dale Pontius Regards, Andy -- video4linux-list mailing list Unsubscribe mailto:video4linux-list-request@redhat.com?subject=unsubscribe https://www.redhat.com/mailman/listinfo/video4linux-list ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: HVR-1600 - unable to find tuner 2008-09-24 0:57 ` Andy Walls @ 2008-09-24 1:48 ` Dale Pontius 2008-09-24 2:31 ` Andy Walls 0 siblings, 1 reply; 6+ messages in thread From: Dale Pontius @ 2008-09-24 1:48 UTC (permalink / raw) To: Andy Walls; +Cc: video4linux-list Andy Walls wrote: > On Sun, 2008-09-21 at 21:53 -0400, Dale Pontius wrote: >> Andy Walls wrote: >>> On Sat, 2008-09-20 at 06:52 -0400, Dale Pontius wrote: >>> >>>> A week back I posted a "newby question," and eventually it became >>>> apparent that I can't find my tuner. >>>> I loaded the module with: >>>> "modprobe cx18 mmio_ndelay=61" >>> You can always try higher numbers to see if things get better at some >>> higher value. Use multiples of 30.3. >>> >> Things look a litte different with "modprobe cx18 mmio_ndelay=182 debug=67", >> and I've also added the other debug parameters you suggest later. With that, >> here's my dmesg: >> --------------------------------------------------------------------------- >> cx18-0: Autodetected Hauppauge HVR-1600 >> cx18-0 info: NTSC tuner detected > > This message means the driver has likely parsed the EEPROM properly and > thinks you have an NTSC tuner (which you should). snip > > Well there should be only one tuner (mixer/oscillator) chip on that 2nd > i2c bus on the HVR-1600 bus. The output of i2cdetect, assuming you > queried the correct bus, says that no chip is responding anywhere on > that bus, nor has any address on that bus been claimed by a driver. > > This could be because the tuner's actually bad, or simply not responding > for some reason (i.e. the reset sequence with mdelay()'s at the end of > cx18-i2c.c didn't work), or the CX23418 chip is not responding properly > on the PCI bus when querying it's I2C control registers for the second > I2C bus (weird since everything else looks to be working). > > > For reference, here's output from my working HVR-1600 > > # modprobe i2c-dev > # i2cdetect -l > i2c-1 smbus SMBus PIIX4 adapter at 0b00 SMBus adapter > i2c-0 i2c cx18 i2c driver #0-0 I2C adapter > i2c-2 i2c cx18 i2c driver #0-1 I2C adapter > > # i2cdetect -y 0 > 0 1 2 3 4 5 6 7 8 9 a b c d e f > 00: -- -- -- -- -- -- -- -- -- -- -- -- -- > 10: -- -- -- -- -- -- -- -- -- 19 -- -- -- -- -- -- > 20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- > 30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- > 40: -- -- -- -- -- -- -- -- -- -- -- -- UU -- -- -- > 50: 50 -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- > 60: -- -- -- 63 -- -- -- -- -- -- -- -- -- -- -- -- > 70: 70 71 72 73 -- -- -- -- > > (IIRC > 19 = cx25447 > 4c = cs5345 > UU = device has been claimed by a driver > 50 = ATMEL eeprom > 63 = mxl5005s > 70-73 = Z8F0811 IR microcontroller) > Now comes something I think might be truly interesting. Tonight when I tried modprobing my card, I put in an even longer delay, but there was no significant difference. However in every case, even with the default delay, it takes at least 30 seconds, possibly as long as a minute before modprobe returns. I think I need to repeat this with "tail -f messages" and see if there is any particular breakpoint. The reason I bring this up is that I just tried running i2cdetect against i2c-6, and it was done in less than a second. Running i2cdetect against i2c-7 takes minutes. I guess I figured those "--"s were all timeouts, but that didn't stop the first bus from running fast. This is the first time I've probed the first bus, and saw the difference in time. Incidentally, my results on the first bus match yours. Just started a timed run on modprobe. I get to "cx18-0 i2c: i2c client register" within 5 seconds, and then get to "cx18: End initialization" after 50-55 seconds. It's chewing its fat on the i2c bus for 45-50 seconds, which is consistent with my very long "i2cdetect -y 7" times. Is this significant? Thanks, Dale one more note... I'll have to see what I can do about a Windows system. I have one system that dual-boots Win98SE, so I'll have to read the manual and see if it's supported. I also have a friend who might have an XP system we can check it out in, so I'll check that. > # i2cdetect -y 2 > 0 1 2 3 4 5 6 7 8 9 a b c d e f > 00: -- -- -- -- -- -- -- -- -- -- -- -- -- > 10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- > 20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- > 30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- > 40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- > 50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- > 60: -- UU -- -- -- -- -- -- -- -- -- -- -- -- -- -- > 70: -- -- -- -- -- -- -- -- > > 61 = simple tuner mixer/oscillator chip > UU = device has been claimed by a driver > > >> I'm wondering if either my bttv card is interfering somehow, > > If you got all '--' on the i2cdetect of the correct i2c bus on the > HVR-1600, then it really can't be the bttv driver, AFAICT. > > For testing, I'm going to try to implement another, agressive PCI bus > access algorithm for accessing the CX23418 instead of using simple > delays with mmio_ndelay. I don't have a definite schedule on this yet. > I'm not hopeful that it will help though, seeing as your CX23418 seems > to behaving well otherwise (no -121 errors, can always read the eeprom, > always loads the firmware, always can init the ATSC side of the card, > etc.). > > >> or if this card >> needs to be RMA'ed. > > Try it in a Windows installation first. > > >> I have another identical card in an unopened box, if it's >> time to try that. > > I suspect it may behave differently (manufacturing variations). If your > second card works, it doesn't mean your first card is broken though. It > may mean the cx18 driver needs to do something differently. Make sure > the first card doesn't work in Windows as well before returning (if > possible). > > >> Thanks, >> Dale Pontius > > Regards, > Andy > > -- video4linux-list mailing list Unsubscribe mailto:video4linux-list-request@redhat.com?subject=unsubscribe https://www.redhat.com/mailman/listinfo/video4linux-list ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: HVR-1600 - unable to find tuner 2008-09-24 1:48 ` Dale Pontius @ 2008-09-24 2:31 ` Andy Walls 0 siblings, 0 replies; 6+ messages in thread From: Andy Walls @ 2008-09-24 2:31 UTC (permalink / raw) To: Dale Pontius; +Cc: video4linux-list On Tue, 2008-09-23 at 21:48 -0400, Dale Pontius wrote: > Andy Walls wrote: > > On Sun, 2008-09-21 at 21:53 -0400, Dale Pontius wrote: > >> Andy Walls wrote: > >>> On Sat, 2008-09-20 at 06:52 -0400, Dale Pontius wrote: > >>> > >>>> A week back I posted a "newby question," and eventually it became > >>>> apparent that I can't find my tuner. > >>>> I loaded the module with: > >>>> "modprobe cx18 mmio_ndelay=61" > >>> You can always try higher numbers to see if things get better at some > >>> higher value. Use multiples of 30.3. > >>> > >> Things look a litte different with "modprobe cx18 mmio_ndelay=182 debug=67", > >> and I've also added the other debug parameters you suggest later. With that, > >> here's my dmesg: > >> --------------------------------------------------------------------------- > >> cx18-0: Autodetected Hauppauge HVR-1600 > >> cx18-0 info: NTSC tuner detected > > > > This message means the driver has likely parsed the EEPROM properly and > > thinks you have an NTSC tuner (which you should). > snip > > > > Well there should be only one tuner (mixer/oscillator) chip on that 2nd > > i2c bus on the HVR-1600 bus. The output of i2cdetect, assuming you > > queried the correct bus, says that no chip is responding anywhere on > > that bus, nor has any address on that bus been claimed by a driver. > > > > This could be because the tuner's actually bad, or simply not responding > > for some reason (i.e. the reset sequence with mdelay()'s at the end of > > cx18-i2c.c didn't work), or the CX23418 chip is not responding properly > > on the PCI bus when querying it's I2C control registers for the second > > I2C bus (weird since everything else looks to be working). > > > > > > For reference, here's output from my working HVR-1600 > > > > # modprobe i2c-dev > > # i2cdetect -l > > i2c-1 smbus SMBus PIIX4 adapter at 0b00 SMBus adapter > > i2c-0 i2c cx18 i2c driver #0-0 I2C adapter > > i2c-2 i2c cx18 i2c driver #0-1 I2C adapter > > > > # i2cdetect -y 0 > > 0 1 2 3 4 5 6 7 8 9 a b c d e f > > 00: -- -- -- -- -- -- -- -- -- -- -- -- -- > > 10: -- -- -- -- -- -- -- -- -- 19 -- -- -- -- -- -- > > 20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- > > 30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- > > 40: -- -- -- -- -- -- -- -- -- -- -- -- UU -- -- -- > > 50: 50 -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- > > 60: -- -- -- 63 -- -- -- -- -- -- -- -- -- -- -- -- > > 70: 70 71 72 73 -- -- -- -- > > > > (IIRC > > 19 = cx25447 > > 4c = cs5345 > > UU = device has been claimed by a driver > > 50 = ATMEL eeprom > > 63 = mxl5005s > > 70-73 = Z8F0811 IR microcontroller) > > > > Now comes something I think might be truly interesting. Tonight when I tried > modprobing my card, I put in an even longer delay, but there was no significant > difference. > > However in every case, even with the default delay, it takes at least 30 seconds, > possibly as long as a minute before modprobe returns. That's not right. The i2c-algo-bit module implements a driver specific timeout whenever it is waiting for the I2C bus clock line (SCL) to go high (slaves on the bus are allowed to stretch the clock). For the cx18 driver that time is specified in cx18-i2c.c as #define CX18_ALGO_BIT_TIMEOUT (2) /* seconds */ This long delay you are experiencing is a very good indicator that the SCL line on the second I2C bus on the card is stuck low. AFAIK, there are only two devices on that bus and the tuner chip and the CX23418 itself (and probably a pullup resistor). > I think I need to repeat > this with "tail -f messages" and see if there is any particular breakpoint. > > The reason I bring this up is that I just tried running i2cdetect against i2c-6, > and it was done in less than a second. Running i2cdetect against i2c-7 takes > minutes. I guess I figured those "--"s were all timeouts, but that didn't stop > the first bus from running fast. This is the first time I've probed the first > bus, and saw the difference in time. Incidentally, my results on the first bus > match yours. Good. > Just started a timed run on modprobe. I get to "cx18-0 i2c: i2c client register" > within 5 seconds, and then get to "cx18: End initialization" after 50-55 seconds. That's too long. > It's chewing its fat on the i2c bus for 45-50 seconds, which is consistent with > my very long "i2cdetect -y 7" times. Yup. > Is this significant? Yes in that it indicates the SCL line appears to be stuck low on that bus, indicating bad hardware, hardware that isn't getting reset, or bad CPU host to CX23418 communications (but only for resetting devices or the 2nd I2C bus and nothing else, which doesn't seem plausible). The i2c modules do having debugging switches, but they aren't compiled in by default. The i2c-algo-bit module does have one compiled-in default module parameter called 'bit_test', when set to 1 causes the module to check for stuck I2C bus lines. Add that option to your /etc/modprobe.conf, reboot, and the watch the i2c-algo-bit module gripe when you modprobe cx18. > Thanks, > Dale > one more note... I'll have to see what I can do about a Windows system. I have > one system that dual-boots Win98SE, so I'll have to read the manual and see if > it's supported. I suspect the Windows driver doesn't support Win98SE. Steve Toth (stoth) hangs out on the linux-dvb list and on the IRC channels (not sure if he's on this list too). You can ask him; he'd know. Regards, Andy -- video4linux-list mailing list Unsubscribe mailto:video4linux-list-request@redhat.com?subject=unsubscribe https://www.redhat.com/mailman/listinfo/video4linux-list ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2008-09-24 2:32 UTC | newest] Thread overview: 6+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2008-09-20 10:52 HVR-1600 - unable to find tuner Dale Pontius 2008-09-21 1:43 ` Andy Walls 2008-09-22 1:53 ` Dale Pontius 2008-09-24 0:57 ` Andy Walls 2008-09-24 1:48 ` Dale Pontius 2008-09-24 2:31 ` Andy Walls
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox