Andrew de Quincey wrote:
sorry, but I can't get your point. I don't see any duplication, and I don't see any point in using a standard that is just not providing the functionality we need. Did you read and undersood my proposals before, can you please explain a little more in detail where exactly you see duplicated code?Yeah, that sounds good. So effectively the frontend drivers will cease to be kernel i2c devices. However, we'll still use the kernel i2c for the adapter's i2c buses if need be, so no one can complain we're duplicating stuff again. That makes sense - theres no point really in making the frontends generic devices usable by non-DVB code. How will we prevent things like that tda9887 tuner from taking over our addresses on the bus accidentally if our bus is marked as ANALOGUE and DIGITAL? We should probably claim addresses on the bus that we use - but it all depends on what order things are loaded in.I would not claim any addresses, why should we? Even registration to the kernel i2c API is optional (and only introduces delays and the risk of accidentally attached devices from other subsystems).
I would prefer to use the kernel i2c API because it is there, is standard, and otherwise means duplication of code and lots of locking.
The generic i2c_read/write() implementations in the card drivers should allow writes to all addresses. If not we should fix them, we're maintaining them anyway. We also need to ensure they are correctly locking on the low level because we don't rely on the i2c layer locking mechanism anymore (but last time I checked most drivers implemented correct semaphores, so this should not really be a problem). If properly done both systems can existence peacefully in coexistence and concurrent accesses are allowed (like it was the case for the dvb_i2c_bus code).
The whole reason for starting this discussion was because an analog TV tuner was incorrectly thinking the cx22702 demodulator was actually an instance of itself because there isn't a way to reliably autodetect the tda9887 (I've checked the docs).
the same problem we have since years for many i2c chips.
Having two separate buses will not solve this problem - if a card is both DIGITAL and ANALOGUE, then the situation above could still occur. Only then, we'll have two drivers trying to talk to the same i2c device at possibly the same time, only one of which will be the correct driver.Please read my proposal, we don't have any bus anymore, we don't need any detection.