Re: [PATCH] make the registers of the stv0297 visible for other applications (e.g. i2cdump)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

[Index of Archives]     [Linux Media]     [Video 4 Linux]     [Asterisk]     [Samba]     [Xorg]     [Xfree86]     [Linux USB]

  Powered by Linux