Manu Abraham wrote: > On 6/2/07, Johannes Stezenbach <js@xxxxxxxxxxx> wrote: > > On Fri, Jun 01, 2007, Oliver Endriss wrote: > > > e9hack wrote: > > > > Manu Abraham wrote: > > > > > e9hack wrote: > > > > >> Manu Abraham wrote: > > > > >>> Trent Piepho wrote: > > > > >>>> 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. > > > > >> The stv0297 cannot handle a repeated start condition and it needs > > > > >> a little delay between the stop and the next start condition. A > > > > >> stop and a start condition cannot be on the same upload command > > > > >> of a saa7146 (on a TT 2300C). > > > > > > > > > > Any idea what the SAA7146 - STV0297 windows driver does ? > > > > > > > > > > > > > Good point. I can monitor any access to the saa7146 registers of the > > > > TT 2300C on Windows. I will check this issue. In the past, I was > > > > more interested in the high level part of the i2c-communication. > > > > > > Any news about this? > > > > > > Imho Trent's patch to add I2C_M_STOP makes sense. > > > > > > According to the stv0299 datasheet, the stv0299 requires this STOP > > > condition, too. This chip seems to be more tolerant though. > > > The current driver does not send STOP before READ, and it works. > > > > I re-read the i2c spec (conveniently available from > > http://i2c-bus.org/ ), and although it doesn't use very > > clear words I think it says that any device _must_ support > > repeated start conditions (e.g. section 9 FORMATS WITH 7-BIT > > ADDRESSES). > > I just miss a few points in there.. from the URL that you pasted in. > > "The I2C protocol defines a so-called repeated start condition. After > having sent the address byte (address and read/write bit) the master > may send any number of bytes followed by a stop condition." AFAICS repeated start conditions must be supported by all I2C devices. Furthermore, section 9 note 4 specifies that a device has to accept a start condition anytime, but that's more related to error recovery IMHO. > The STV0297 requires a STOP bit in between as stated. That's what the datasheet says. Same for stv0299. > > There's also some more explanation: > > http://i2c-bus.org/RepeatedStartCondition/ > > > > Now, it could well be that the stv0297 i2c interface > > is broken (broken because it cannot safely be used on a bus > > with multiple masters), but it may also be quite possible > > that the stv0297 datasheet is just inaccurate. > > Will any comments from STM would help ? If so, will request STM to > answer some questions that we have, if any explicit ones you have, i > can add them alongwith. Just that i got a bit confused now. If you have a contact at STM, that would be great. According to the datasheet, a read operation must look like this: (a) S waddr A reg A P S raddr A data A P According to the I2C standard, a device must support this, too: (b) S waddr A reg A Sr raddr A data A P S = start, P = stop, Sr = repeated start, A = acknowledge, waddr = address[write], raddr = address[read] I hope that the stv0297/stv0299 datasheets are incorrect/incomplete, and a type (b) transaction is supported, too. If not, the device cannot be used in a multi-master environment. (Note that a repeated start condition is used to 'lock' the I2C bus for the master which is currently accessing the device.) In this case we have have to add something like the M_STOP workaround to I2C core. Otherwise accessing the stv0297 would not be thread-safe... > > IMHO both possibilities are just as likely, however I trust > > adq has actually tested that repeat start doesn't work. > > http://linuxtv.org/hg/v4l-dvb/rev/c204a1d063aa > > > > Then I2C_M_STOP still makes sense, but the patch should document > > that it's used only a workaround for broken hardware. CU Oliver -- ---------------------------------------------------------------- VDR Remote Plugin 0.3.9: http://www.escape-edv.de/endriss/vdr/ ---------------------------------------------------------------- _______________________________________________ linux-dvb mailing list linux-dvb@xxxxxxxxxxx http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
