Messages in this thread | | | Date | Sat, 31 May 2008 20:39:25 +0200 | From | "Martin Samuelsson" <> | Subject | Multiple Zoran MJPEG cards and i2c misattachments |
| |
Hello,
I'm working on avs6eyes improvements in the current kernel. As I've equipped my machine with no less than three MJPEG-cards; Buz, 6 Eyes and DC10+, I happened to run into a bit of a snag:
saa7185, the video encoder of the Buz, and bt866, video encoder of the 6 Eyes, share the same i2c address, 0x88. This should not be a problem, because they are connected to different i2c buses, and are initialized separately. However, zoran_card.c, via i2c_bit_add_bus(), creates one i2c bus for each card in the detection loop, and makes them available system-wide. This means that the saa7185 driver, as the cards are detected in Buz, 6 Eyes, DC10+ order in my computer, is being requested by the zoran driver and initializes itself (not very much to do, as there is not yet any i2c bus). The zoran driver then creates bus 0, and initializes the saa7185 driver once again, it finds bus 0 and a chip at 0x88, which it attaches to.
Now, that bus is visible to the system. The 6 Eyes is being initialized, the bt866 driver loaded, and it initializes itself. Here's the problem: At load, the drivers automatically searches the system for available buses. bt866 finds bus 0, belonging to Buz, and a chip at 0x88, which it promptly attaches to, marking itself as in use.
The zoran driver then creates i2c bus 1, managed by the 6 Eyes, and initializes the bt866 driver again. It, in turn, looks for i2c buses, finds bus 0 and address 0x88, notices in i2c_probe_address() that it's marked as in use, refuses to attach to the chip, proceeds to bus 1 and the chip at 0x88, notices once again that it's marked as in use, and refuses to attach to the chip it's supposed to attach to.
The zoran driver has code that determine if a particular chip indeed is supposed to go with the card it's trying to attach to, but when i2c_probe_address() says the driver is in use, that code is never reached.
The 6 Eyes is left with no video encoder and a bt866 driver that think it's managed to attach successfully, while it in fact is clinging to the wrong bus.
So far the background...
What would be a working approach to fix this situation? I'm woefully unaware of the i2c intricacies in the kernel, and know no immediate fix.
Is it possible to register i2c buses that are not visible to drivers you modprobe? That would prevent the initial scan of the buses, and the misattachments. zoran_card.c explicitly initialize the correct drivers after bus creation anyway.
Is it possible to request_module() a module in a way that will not make it initialize itself, but just load? The same motivation there, with the exception that regular modprobes still would mess things up.
Is it possible to detach a wrongly attached driver, while still technically in i2c_probe(), given only the info in a i2c_driver struct ? That way, zoran_i2c_client_register() in zoran_card.c could gently rectify the over-optimistic attachments to the wrong buses when i2c_probe_address() hands over the initialization work to the chip driver.
Is there an even better way to do this?
/Sam
| |