On 2016-04-05 16:50, Antti Palosaari wrote: > On 03/23/2016 06:58 PM, Peter Rosin wrote: >> On 2016-01-06 06:42, Antti Palosaari wrote: >>> Recent i2c mux locking update offers support for i2c controlled i2c >>> muxes. Use it and get the rid of homemade hackish i2c adapter >>> locking code. >> >> [actual patch elided] >> >> I had a 2nd look and it seems that the saa7164 driver has support for >> a HVR2055 card with dual si2168 chips. These two chips appear to sit >> on the same i2c-bus with different i2c-addresses (0x64 and 0x66) and >> with gates (implemented as muxes) to two identical tuners with the >> same i2c-address (0x60). Do I read it right? > > saa7164 has 3 different I2C adapters. > > saa7164 I2C bus #0: > * eeprom > * Si2157 #1 > > saa7164 I2C bus #1: > * Si2157 #2 > > saa7164 I2C bus #2: > * Si2168 #1 > * Si2168 #2 > > So both of the Si2157 tuners could have same addresses. > > (It is Hauppauge WinTV-HVR2205, not HVR-2055). Ok, so I did read it right. >> With the current i2c-mux-locking (parent-locked muxes), this works >> fine as an access to one of the tuners locks the root i2c adapter >> and thus the other tuner is also locked out. But with the upcoming >> i2c-mux-locking for i2c-controlled muxes (self-locked muxes), the >> root i2c adapter would no longer be locked for the full transaction >> when one of the tuners is accessed. This means that accesses to the >> two tuners may interleave and cause all kinds of trouble, should >> both gates be open at the same time. So, is it really correct and >> safe to change the si2168 driver to use a self-locked mux? >> >> Unless there is some other mechanism that prevents the two tuners >> from being accessed in parallel, I think not. But maybe there is such >> a mechanism? > > Good point. Actually there is pretty often this kind of configuration used for those dual tuner devices and it will cause problems... Currently all of those implements hackish i2c_gate_ctrl() callback to switch mux. > > ____________ ____________ ____________ > |I2C-adapter | | I2C-mux | | I2C-client | > |------------| |------------| |------------| > | | | addr 0x1c | | addr 0x60 | > | | | | | | > | |-+-I2C---|-----/ -----|---I2C---| | > |____________| | |____________| |____________| > | ____________ ____________ > | | I2C-mux | | I2C-client | > | |------------| |------------| > | | addr 0x1d | | addr 0x60 | > | | | | | > +-I2C---|-----/ -----|---I2C---| | > |____________| |____________| Right, so self-locked muxes (as in v5 [1]) can't do the job, but mux-locked muxes (as in v6 [2]) should be fine. The v6 mux- locked muxes grab a new mux_lock in the parent adapter where the v5 self-locked muxes grabbed a lock in the mux itself. Which means that sibling muxes will lock each other out with v6 when they go for the same lock, which is what we want. Cheers, Peter (v5 and v6 refer to the mux locking update patch series) [1] http://marc.info/?l=linux-i2c&m=145805103325611&w=2 [2] http://marc.info/?l=linux-i2c&m=145967417924732&w=2 -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
