On Fri, 2009-01-16 at 11:07 +0100, Jean Delvare wrote: > 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. I tend to think of them as I2C bus segments. A mental model I've used is a crude analogy to the PCI bus. Hierarchical bus segements with "transparent bridges" (I2C gates) except the "bridges" (I2C gates) on the I2C bus can be enabled and disabled. I guess that would make the adapter the "host bridge". > > > 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. I'd think i2c-core, if it can be used outside of v4l-dvb. Somehow I would expect master_xfer() to be able to call some gate control decision logic callback (do I open, close or leave alone) and actual gate control callback (do the open, do the close) both provided by the driver that instantiates the adapter. > > 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... Why not? I would think gates and multiplexers are isomorpohisms of each other: A gate could be viewed as a trivial mux. It could be represented with two outer segments: the real one, and a logical "null" one. Then it's a matter of setting the default outer segment for all muxes. One could also look at a mux as two (or more) gates on the same bus segment. Steering the mux is equivalent to configuring the gates so that one (or none) are open at any one time. Regards, Andy -- 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
