On Sun, 2008-06-08 at 10:24 -0700, Michael wrote: > > On Fri, 2008-06-06 at 10:22 -0700, Michael wrote: > > > > Hmm. I really though the problem could have been that. Here's my > > > > rationale: > > > > > > > > 1. From my dmesg output, the cx18 driver talks to the i2c devices in > > > > the following order at initialization: > > > > > > > > EEPROM chip > > > > Analog tuner chips > > > > CS5345 audio digitizer/multiplexer chip > > > > MXL5005S chip > > > > S5H1490 chip > > > > > > > > 2. From your dmesg output, normally the CS5345 is the first device to > > > > actually respond properly. That would suggest accessing the CS5345 or > > > > the analog tuner somehow clears up the I2C bus problem. > > > > > > > > 3. A similar sequence of mdelay()'s is used in cx23885/cx23885-cards.c > > > > for the HVR-1200, HVR-1400, HVR-1500, HVR-1700, and HVR-1800 to reset > > > > the analog tuner. > > > > > > > > 4. You have a different analog tuner (Philips FM1236 MK5 idx 116, type > > > > 43) than I (TCL M2523_5N_E idx 112, type 50), so perhaps it needs a > > > > longer delay to be ready after reset. Or since yours seems to have FM > > > > radio, and mine doesn't, we might be missing a reset line for a tuner > > > > chip. > > > > > > > > > > > > > > > > > > > > > > > > Since we've got that one good EEPROM read from May 10th, you can use > > > > some command line options to try and get your card working: > > > > > > > > # modprobe -r cx18 > > > > # modprobe tveeprom debug=1 > > > > # modprobe cx18 cardtype=1 tuner=43 radio=1 ntsc=M > > > > > > > > Things look positive, but let's talk about exactly what you applied to > > the code first... > > > > > I tried this with the latest patch you sent me, and only that patch. > > > After > > running dmesg, eeprom error still occurs. I know there is extra > > information in > > the middle (extra as in not relating to the TV Tuner), but I'm not going to > > remove it, as I'm afraid I may accidentally remove something important. > > > > So you didn't increase the mdelay()'s in the bottom of cx18-i2c.c, > > right? > > > No, I didn't change the values. > > > > If you didn't, given that the analog tuner didn't get recognized in any > > of your output, you may want to put some larger values in them. You can > > try 100 in each of them. If that works to get the analog tuner > > initialized, we can work our way down to shorter values. > > > Do you want me to try changing both to 100, or leave the first one at 10, as > we did last time?
Try changing both. What we are trying to do is reset the analog tuner. These is no harm in holding reset lines asserted for longer than the minimum interval or waiting too long for the tuner to recover and become ready. If the delays are too short, then the reset of the device might not happen properly. > > > > You may also want to increase the "msecs_asserted" and "msecs_recovery" > > values in cx18-cards.c. Try 100 in all of them. If that works to get > > the eeprom read properly on the first try, we can work our way down to > > shorter values. > > > > > Try this with the reset3 patch you sent, correct? Yes. Again there's no harm in having reset of device take longer than it needs too and waiting around. If the delays aren't long enough, a device might not actually get reset. > > > > > http://h1.ripway.com/hendrick/TV.txt > > > > Things look better! > > > > So for the first 2 modprobes of cx18, the card's EEPROM doesn't get > > recognized properly :( but the remaining 3 (or 4?) times it did get > > recognized! :) > > > > What I didn't see was messages about the NTSC tuner getting initialized > > properly. So whatever the patch and your action did, at least the first > > I2C bus got unstuck. Since the analog tuner doesn't look like it's > > responding on the second I2C bus, analog RF capture may not work. > > > > What should work for you is: > > > > 1. analog capture from line in (S-Video or Composite) > > 2. digital video scan and captures (ATSC QAM or 8VSB). > > > > So give it a try! :) > > > > > > In a previous email, you said to try this for a digital scan: > scandvb -A 1 -v -a 0 > /usr/share/dvb-apps/atsc/us-ATSC-center-frequencies-8VSB > However, I never was able to have that command work. scandvb is a Fedora/RedHat rename of a DVB utility command. I'm not an expert in the DVB utilities, so feel free to google around and figure out what you need to do to perform scans. My command above was specifically to look for over the air 8VSB terrestrial ATSC broadcasts in the US. Cable uses QAM. If you're not in the US, OTA 8VSB isn't likely to be in your area. > I then tried using kdetv to scan, however, it wasn't able to pick up any > digital channels. (I know using WinTV in XP, I pick up a few QAM.) So you have cable if you get QAM. Brandon Jenkins reported on the linux-dvb list that something had changed recently with the new mxl5005s driver that the dvb portion cx18 relies on. With the old mxl500x module, on a scan he found many more QAM channels than he did with the mxl5005s driver module. I can't test/debug QAM at the moment, as I don't have cable TV nor do I have a datasheet for the MXL5005. If you already know the QAM channel frequencies and services you receive in Windows, with some work, you could create a channels.conf file and tune to the channels anyway. Again, I'm not the expert here. > Also according to kdetv, VBI decoder isn't running. I'm not sure if thats > important or not, but it effects a few settings that I can edit in the > program. VBI is in work. The cx23418 chip's encoding engine seems to stall transfers when we ask it for VBI, so we need to get that resolved first. > I tried this: > v4l2-ctl -d /dev/video0 -i1 > However, I haven't found a view it yet. "-i1" is the first SVideo input. So you get nothing when you have and SVideo source hooked up to the card and use $ mplayer -cache 8192 /dev/video0 ? > Thanks again for the help! You're welcome. I'm trying to buy a version of the HVR-1600 that you have (74551) off of ebay, to see if I can reproduce the problem first hand. (Plus I'll have two digital tuners then!) I lost the first auction, and was just outbid on the second. :( Regards, Andy _______________________________________________ ivtv-users mailing list [email protected] http://ivtvdriver.org/mailman/listinfo/ivtv-users
