Hi Mauro, Trent, On Fri, 16 Jan 2009 00:02:52 -0200, Mauro Carvalho Chehab wrote: > On Thu, 15 Jan 2009 10:33:15 -0800 (PST) > Trent Piepho <xyzzy@xxxxxxxxxxxxx> wrote: > > > On Thu, 15 Jan 2009, Mauro Carvalho Chehab wrote: > > > It has nothing to do with the load order. It is related to i2c binding. With > > > the current approach (before Hans patch), the i2c core will try to bind the > > > tuner after having 2 conditions satisfied: > > > 1) I2C bus were registered; > > > 2) tuner code is available. > > > > > > So, if you load tuner before saa7134 (or have it compiled in-kernel), the code > > > will try to probe tuners at the moment you register i2c bus. Otherwise, it will > > > try to bind only when request_module is handled. > > > > > > Some devices with DVB has an internal i2c gate. For a subset of these, the i2c > > > gate is inside the tuner. So, you need to bind the tuner device before probing > > > for the frontends. On the other set of devices, the gate is inside the demod. > > > So, you need to turn the i2c gate before running the i2c address seek for tuner. > > > > I wonder if a better way to fix these problems is to use virtual I2C busses > > for the gate? > > For now, we should finish the Hans approach, since it also helps to stop using > the legacy i2c methods. After having all drivers using it, we can do some > cleanup at the drivers. > > However, I like the idea of providing a better support for those buses that > have an i2c switch inside (I don't like to call it "virtual" - it is a real i2c > bus, where part of the bus is controlled by a switch). I second this, the term "virtual" to qualify these buses is improper. Better speak in terms of I2C segments, multiplexers and gates. Gates can be seen as a degenerated form of multiplexers, but this is not necessarily the best approach. > > When a device has some kind of i2c gate, it creates a new > > I2C adapter for the devices behind the gate. The code for this virtual i2c > > adapter can just open the gate, pass of the request to the main i2c > > adapter, then close the gate. Creating a new i2c adapter should trigger > > the i2c drivers that scan to do so and find new devices behind the gate. > > > > It seems like this would solve the scan order problem, since the bus the > > tuner/demod/whatever is on won't exist until the gate it is behind can be > > properly controlled. Well, the scanning order problem is IMHO better resolved by instantiating the devices explicitly instead of letting the i2c subsystem probe for them. Everything is already in place to do this, and a number of drivers are already being converted in this direction. > > There are a number of additional benefits too. There are many devices that > > can be behind many different kinds of gates. So we have all these gate > > control functions that must be called manually from all over the place. > > This adds bloat and developers are always forgetting to call them, which > > doesn't cause any problem they notice because their card doesn't have a > > gate. > > > > With manual gate control, we must remember to close the gate when done with > > the device. But this isn't always done and the gate is left open. These > > gates are there for a reason, to shield RF devices from noise created by > > the I2C bus, and so leaving them opens impairs RF performance. > > > > And when the gate is only controlled by the driver in the kernel, it is > > hard to manually debug/test i2c devices from userspace with i2c-dev. > > I'm not sure if we should implement it inside v4l core, or at i2c-core. This is an excellent question, I don't know for sure myself. > Maybe the latter could be more appropriate, since maybe some other devices could have > similar issues, like the embedded processor/controllers, where you have an i2c > bus there connected to several different devices, like those used on cellular > phones. > > I bet that some embedded devices uses the same i2c bus for more than > one subsystem (like having a radio and/or a webcam and some temperature/battery > sensors). In this case, a virtual i2c support could be interesting. > > Maybe Jean could give us some suggestions about the better approach for such cases. Support for I2C segments and multiplexers is needed for other systems, yes. Some embedded systems have such multiplexers, and even some PC motherboards do. The goal can be to isolate some portions of the I2C bus, but in most cases it is simply a way to have more than one I2C device with the same I2C address on a given bus. Support for these multiplexers still isn't in the kernel so we are free to imagine how an implementation could look like. As far as the gate issue is concerned, the key point is whether multiplexers would always have at least one "outer" segment selected, or not. In terms of performance, that would be preferable, so that consecutive accesses to a given chip on any outer segment are fast (no mux change). But then we can't treat gates as muxes, because for gates we want the outer segment isolated when we don't use it. This might be an option of the mux driver... That being said, this is only one way to implement gates. I can think of 2 other: * At I2C bus driver level. We can have a pre-transfer handler and a post-transfer handler, which does what needs to be done (like opening and closing a gate) based on the address of the device that is being accessed. I had discussed this approach with Michael Krufky long ago. That would be pretty easy to implement at the i2c-algo-bit level for bit-banged adapters. For other adapters, presumably this can be done directly in the master_xfer method, you don't even need me. This approach has the same advantage of transparency as the bus segment one: access through i2c-dev for example is done as if the gate did not exist, and the gate can't accidentally be left open. I think this approach has my preference, because it is cheap and can be implemented right now. * At the chip driver level, using a custom API. I think this is what is done right now? You lose transparency, but performance may be better: if you have many commands to send to a device behind the gate, you can open the gate, batch them, then close the gate. With the transparent models, the gate is opened and closed again for every I2C transfer. I don't know if this is a big problem in practice, as presumably this only happens once at initialization time? -- Jean Delvare -- 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
