On Fri, Jan 29, 2010 at 2:59 PM, Mauro Carvalho Chehab <mchehab@xxxxxxxxxx> wrote: > The asynchronous load were added not to improve the boot load time, but to > avoid some troubles that happens when the load is synchronous. > I don't remember what were the exact trouble, but I suspect that it was > something related to i2c. The result was that, sometimes, the driver > used to enter into a deadlock state (something like driver A waits for driver B > to load, but, as driver B needs functions provided by driver A, both are put > into sleep). It would be good if you could locate some specifics in terms of what prompted this. > Also, reducing the driver load time is a good thing. The asynchronous load > is very interesting for devices where the firmware load takes a very long time. I do not believe that loading the module synchronously will have any impact on the actual load time, since other modules can be loading in parallel to the initialization of the em28xx device (regardless of whether it is a single module, or three modules loading synchronously or asynchronously). Also, for xc3028 in particular, we could defer firmware loading until first use like we do with xc5000 - doing the firmware load at driver init isn't very useful anyway since we load the firmware and then immediately and put the device to sleep. > Maybe one alternative would be to register the interfaces asynchronously > also, as a deferred task that is started only after the driver enters into > a sane state. Potentially. I feel this should really only be done though in response to an actual problem/bug. Otherwise it adds additional complexity with no real benefit. > As the problem is common, the better is to provide a global way to avoid > device open while the initialization is not complete, at the v4l core. I would be in favor of this, although I am not sure how practical it is given the diversity in the way different bridges are implemented. Also, we would need to take into account how this would work with DVB, since many of the races we run into are applications attempting to use both the v4l and dvb interfaces of a hybrid device. Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- 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
