Trent Piepho wrote: > On Wed, 23 May 2007, Manu Abraham wrote: >> Johannes Stezenbach wrote: >>> On Sun, May 20, 2007, e9hack wrote: >>>> With the attached patch, it works for the stv0297 functions. It >>>> doesn't solve the problem, why I've wrote the initial patch. I need a >>>> dump from the registers of the stv0297. I've attach a second patch. >>>> stv0297_attach() inserts a wrapper between i2ctransfer() and the >>>> transfer function of the saa7146. The add/del functions for the >>>> wrapper are a little bit >>>> dirty. I didn't find a clean way for the add/del function. >>> Hm, I was trying to tell you that the problem is in i2cdump, >>> not in saa7146 or stv0297. >>> >>> i2cdump is simply limited to simple SMBUS-like transfers, >>> but I think it wouldn't be difficult to extend it or >>> write a new utility which uses the I2C_RDWR ioctl to >>> perform the transfer as required by stv0297. >> I have been looking at the STV0297D/E datasheets specifically to check >> this issue (and i don't see any differences than how it is "potentially' >> differently from other devices): >> >> HTH >> >> >> The STV0297D/E datasheet defines the transaction thus .. >> >> I2C Read: >> >> START >> SLAVE ADDRESS >> R/W >> ACK (STV0297) >> BASE ADDRESS >> ACK (STV0297) >> STOP <------ this is different >> START >> SLAVE ADDRESS >> R/W >> ACK (STV0297) >> DATA BYTE 1 >> ACK (Host) >> DATA BYTE n >> ACK (Host) >> STOP > > The emulated smbus commands that i2cdump uses don't have a stop between > writing the base address and reading the data bytes. Check > Documentation/i2c/smbus-protocol: > SMBus Read Byte Data > S Addr Wr [A] Comm [A] S Addr Rd [A] [Data] NA P > > What the stv0297 wants is: > S Addr Wr [A] Comm [A] P S Addr Rd [A] [Data] NA P > The STV0297 is just a normal demod like the others, nothing special about it (according to ST). Well of course i2cdump can be wrong. _______________________________________________ linux-dvb mailing list linux-dvb@xxxxxxxxxxx http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
