Em Mon, 04 Mar 2013 22:24:43 +0100 Frank Schäfer <fschaefer.oss@xxxxxxxxxxxxxx> escreveu: > Am 04.03.2013 20:14, schrieb Mauro Carvalho Chehab: > > 3) It doesn't properly address the real issue: a separate I2C > > register is needed for bus B. > > Definitely. :( > We talked about that at the beginning. > > I have spent several ours working on this, but finally gave it up (for > now), because > a) it is a very huge change. I started changing/fixing one thing, then I > noticed that this requires fixing 2 other issues first, which again made > it necessary to change others and so on... > The main problem isn't the i2c adapter/bus changes, it's the subdevice > handling/tracking... > b) the resulting code has a big overhead and I'm not sure if it is > justified as long as there is no device yet using both busses in parallel. > > Sure, we all like clean code and sooner or later we will likely be > forced to do it properly. > Maybe I will come back to it when the webcam stuff is finished. > But for now (with regards to the eeprom reading), reordering the bus > setup/configuration calls seems to be the easiest and appropriate > solution to me. Hmm... I found it easy to do it ;) The fact that, currently, on all devices, The first bus has the eeprom[1] and that all other devices are on the secondary bus makes easy to properly implementing it with just a few changes. Ok, if/when we start to see devices mixed, we'll need to add a more complex logic, but for now, it can be simply done, and em28xx i2c scan can check both buses, with may help future development. I'll post some patches tomorrow after testing. [1] That could be a hardware requirement, as it makes easier for the device to seek for eeprom data. Regards, Mauro -- 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
