[linux-dvb] [PATCH] make the registers of the stv0297 visible for other applications (e.g. i2cdump)
xyzzy at speakeasy.org
Wed Jun 6 06:16:26 CEST 2007
On Sat, 2 Jun 2007, Johannes Stezenbach wrote:
> On Fri, Jun 01, 2007, Oliver Endriss wrote:
> > 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
> There's also some more explanation:
> 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.
> IMHO both possibilities are just as likely, however I trust
> adq has actually tested that repeat start doesn't work.
> Then I2C_M_STOP still makes sense, but the patch should document
> that it's used only a workaround for broken hardware.
Well, I tried but no one on the i2c list liked the I2C_M_STOP idea.
The answer seems to be that one should have your i2c driver use it's own
mutex to insure that an i2c transaction with a stop is atomic.
That won't work if you try to use both the stv0297 driver and i2cdump from
userspace at the same time, so the answer there is just to not do that.
If you want to dump the registers, you need to put a copy of i2cdump in the
kernel for each driver that you want a register dump from. Then the driver
can create a sysfs file with a register dump. That way the in-kernel
driver specific i2cdump can use driver's mutex to insure atomic bus access.
I'm still unclear on exactly what the stv0297 requires. The datasheet says
one can't use a repeated start, but must have a stop between a read and a
write. That's simple enough, but has anyone actually verified that the
datasheet is really correct? I know many datasheets provide some
_examples_ of i2c transactions, but it's by no means an exahstive list.
Just because something isn't listed doesn't mean it won't work too.
Does the stv0297 require that no other i2c traffic, to a different device,
appear between the write and the read? Something like:
S stv_addr_W A reg_addr A P
S tuner_addr_W A tuner_data1 A tuner_data2 A P
S stv_addr_R A reg_data NA P
Will the i2c message to the tuner between the two parts of the stv register
reading sequence be a problem?
More information about the linux-dvb