* 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