Re: bttv, tvaudio and ir-kbd-i2c probing conflict

[Jean Delvare <khali@linux-fr.org>]

Hi Trent,

On Sun, 15 Mar 2009 16:46:36 -0700 (PDT), Trent Piepho wrote:
> On Sun, 15 Mar 2009, Andy Walls wrote:
> > But the specific problem that Hans' brings up is precisely a Linux
> > kernel I2C subsystem *software* prohibition on two i2c_clients binding
> > to the same address on the same adapter.
> 
> For a lot of i2c devices, it would be difficult for two drivers to access
> the device at the same time without some kind of locking.
> 
> If you take the reads and writes of one driver and then intersperse the
> reads and writes of another driver, the resulting sequence from the i2c
> device's point of view is completely broken.

Correct.

> But, I suppose there are some devices where if the drivers all use
> i2c_smbus_read/write_byte/word_data or equivalent atomic transactions
> with i2c_transfer(), then you could get away with two drivers talking to
> the same chip.

Yes, this may be possible for some devices, but it can't be
generalized. Non-atomic transactions are one problem but there are
others, for example some I2C devices do not have a flat address space
(the same I2C transaction can access different registers depending on
the value of another register commonly known as bank selector.) Another
problem is read-modify-write cycles, which in my experience are often
needed for I2C devices, and which are racy if several drivers attempt
to handle the same device and want to touch the same register.

So, all in all, great care should always be taken when more than one
driver accesses the same I2C device. And even if only one driver
accesses the I2C device, all accesses that can happen in parallel (for
example triggered by sysfs attribute reads or writes) may have to be
serialized by the driver.

-- 
Jean Delvare