Em Mon, 02 Feb 2015 21:33:24 +0100 Wolfram Sang <w...@the-dreams.de> escreveu:
> > > >Ok, this may eventually work ok for now, but a further change at the I2C > > >core could easily break it. So, we need to double check about such > > >patch with the I2C maintainer. > > > > > >Jean, > > > > > >Are you ok with such patch? If so, please ack. > > Jean handed over I2C to me in late 2012 :) Sorry for the mess... I mis-read MAINTAINERS. > > Basic problem here is that I2C-mux itself is controlled by same I2C device > > which implements I2C adapter for tuner. > > > > Here is what connections looks like: > > ___________ ____________ ____________ > > | USB IF | | demod | | tuner | > > |-----------| |------------| |------------| > > | |--I2C--|-----/ -----|--I2C--| | > > |I2C master | | I2C mux | | I2C slave | > > |___________| |____________| |____________| > > > > > > So when tuner is called via I2C, it needs recursively call same I2C adapter > > which is already locked. More elegant solution would be indeed nice. > > So, AFAIU this is the same problem that I2C based mux devices have (like > drivers/i2c/muxes/i2c-mux-pca954x.c)? They also use the unlocked > transfers... If I understood your comment correct, you're ok with this approach, right? I'll then merge the remaining of this 66-patch series. If latter a better way to lock the I2C mux appears, we can reverse this change. Regards, Mauro >
pgpcIQSSqAgoP.pgp
Description: Assinatura digital OpenPGP
