Multiple cards
Martin Samuelsson <[email protected]> Fri, 30 May 2008 20:53:37 +0200
| Newsgroups | gmane.comp.video.mjpeg.devel |
|---|---|
| Message-ID | <[email protected]> |
Hello, developers! 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: If I combine the Buz and 6-Eyes, the video encoder of the 6-Eyes doesn't work. If the Buz is detected first, that is; otherwise it's the Buz video encoder that doesn't work. The Buz one is an saa7185, while 6-Eyes uses a bt866. The problem is that they are accessed at the same address, 0x88, though at different i2c buses. I've done some digging in the affected drivers, and this is what seem to happen: In the beginning, there is no i2c bus. The Buz is detected. It knows it's using an saa7185, and loads the appropriate driver, which initializes itself at load. It then proceeds to register a new i2c bus, #0. Then the saa7185 register itself on bus #0. All is well. There is one i2c bus, #0. The 6-Eyes is detected. It knows it's using a bt866, and loads the appropriate driver, which initializes itself at load. Among the things a driver does when initializing seem to be finding all i2c buses and scanning them. This means that the bt866 driver finds bus #0, and on that a chip at 0x88, and marks itself as in use. But that address is already in use by the saa7185... On the wrong bus! The 6-Eyes then registers a new i2c bus, #1. Then the bt866 register itself on bus #1. It finds a chip at 0x88, which would be perfect to attach to, apart from the fact that the driver already is marked as in use at bus #0:0x88. Thus, it can't register, and fail to attach. If the order of the Buz and 6-Eyes is reversed, so is the registering mess, leaving 6-Eyes with an attached bt866 and the Buz with a failed saa7185. The function that actually knows chich chip belongs to which card is zoran_i2c_client_register(), and will refuse to register the wrong chip to the wrong card. It is not reached when i2c_probe(), called from the module init code, decides that the driver already is in use, and fails. Would it be possible to enhance zoran_i2c_client_register() with some detach code when it notices the mistake? Is the zoran driver supposed to publish the i2c buses for the module init code to see? (It seems to explicitly initialize the i2c driver after creating the new bus anyway.) What would be the best way around this? Did you try two identical cards in the same machine? Dit it work? /Sam ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/