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 _______________________________________________ linux-dvb mailing list linux-dvb@xxxxxxxxxxx http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
