Ryan Watts wrote: > Andy, > > Thanks for all your work on these patches. I have been trying to get around > to > work on this, but I have been way too busy lately. You may remember my > previous post: > http://ivtvdriver.org/pipermail/ivtv-devel/2008-February/005310.html
Yes. That was a day or two before I received my HVR-1600 in the mail. :) > Anyhow, I applied the 4 patches in order and still no luck. Bummer. You're the third to report no luck. Zero users have reported improvement. The patches still fixed some things that were wrong (but maybe not noticeable), but there is something else going on, masking any effects that those errors would have had. > I have attached > the > debug output from dmesg since it is too lengthy to put in an e-mail. I am > using > a 2.6.22.9 kernel with i2c debug. The output is after using "modprobe > i2c_algo_bit > i2c_debug=3" and "modprobe cx18 debug=511". > > I have also attached the output from "lspci -tv", "lspci -vvvnnxxx", and > "lsmod". > > If you need anything else, let me know. I have a logic analyzer that I can > hook up. On my card, the two test points at the top right corner of the card, TP10 and TP11, are SDA and SCL respectively for the I2C bus that the EEPROM is on. All the pins on one side of the ATMEL 24C02 EEPROM chip, at the very top corner of the board, are wired to ground, if you need a known ground reference > I haven't tested it on the patches, but when I hooked it up using the driver > a few > months ago, the SCL and SDA lines were stuck high. Well, with an open collector or open drain bus like I2C, things can't be "stuck" high, as that is the free state of the bus. Things can be stuck low. See section 3.1 of: http://www.nxp.com/acrobat/usermanuals/UM10204_3.pdf So what you observed was the cx23418 failing to drive the bus. That in itself is valuable to know. It would also be nice to know if this is still the case with the patches in place or with the latest driver. > I was going to try and > make > a PCI breakout card (i thought the problem might be with the PCI bus) but I > don't > have enough time and my logic analyzer only has 12 channels. That's probably overkill for right now. There are software indications of PCI bus errors that supposedly the kernel can notify the driver about. I'm going to write a callback routine to try and catch any of these. > I will see if I can stay on top of things, but it may be this weekend before > I can get > back to you. OK. If you do some testing on your own, don't be afraid to hit me with the details. I've got an EE background. If you see funny rise times, odd clock or data stretches, spurious transitions, etc. let me know. > Hopefully I can study your patches a little more thoroughly > and see > if I can understand them and maybe provide some help. 1/4: Added better driver book-keeping on which of the 2 I2C busses should be manipulated and eliminated duplicate functions. This should have no effect on operation. 2/4: Force PCI memory mapped IO writes to complete by performing a readback, before returning control to i2c-algo-bit. This is so i2c-algo-bit won't start it's timing loop before the cx23418 has actually gotten the command to toggle the line. 3/4: Bang on the slaves when we initialize each I2C bus, in the hopes of making sure no slave is hanging I2C (keeping it stuck low) and that they'll all be ready to listen. 4/4: Fix the SCL clock period timing for i2c-algo-bit, to actually use the maximum 100 kHz clock rate for Normal/Standard Mode I2C. Make the stuck SCL timeout 2 seconds, no matter what rate the kernel runs the PIT at. Versions of patch 1, 2, and 4 are already in the latest cx18 driver. > Thanks, > Ryan I'll look over you log outputs, then send a lists of tests you can try, along with what I'm trying to eliminate/discover with each. Regards, Andy _______________________________________________ ivtv-devel mailing list [email protected] http://ivtvdriver.org/mailman/listinfo/ivtv-devel
