[linux-dvb] [PATCH] make the registers of the stv0297 visible for other applications (e.g. i2cdump)

Johannes Stezenbach js at linuxtv.org
Wed Jun 6 13:22:43 CEST 2007


On Tue, Jun 05, 2007 at 09:16:26PM -0700, Trent Piepho wrote:
> On Sat, 2 Jun 2007, Johannes Stezenbach wrote:
> >
> > 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.
> http://lists.lm-sensors.org/pipermail/i2c/2007-May/001362.html
> 
> 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.

What Jean writes only applies if you have a struct i2c_client
and i2c_driver to work with. the you can do lokcing in the
i2c_driver.

But we don't, IIRC because of problems with bus probing
done yb the i2c-core.
Not having an i2c_client is also the reason why we can't
use the i2c_smbus_* functions.

Well, maybe we could fix this and then use i2c_client
and i2c_driver everywhere, but it still wouldn't solve
the i2c-dev problem, which I2C_M_STOP would in a very
simple and elegant way. I2C_M_STOP might also be useful
to talk to devices behind a repeater/gate or hub.

> 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?

You can't know before you tried it.

I think Philips doesn't offer an "i2c bus spec conformance"
test (there is something for SMBus, though), so I'm quite sure
there are a lot of devices with subtly broken i2c bus implementations.


Johannes



More information about the linux-dvb mailing list