On Thu, Apr 1, 2010 at 11:02 AM, Mauro Carvalho Chehab
<mchehab@xxxxxxxxxx> wrote:
> I remember I had to do it on em28xx:
>
> This is the init code for it:
> ...
> mutex_init(&dev->lock);
> mutex_lock(&dev->lock);
> em28xx_init_dev(&dev, udev, interface, nr);
> ...
> request_modules(dev);
>
> /* Should be the last thing to do, to avoid newer udev's to
> open the device before fully initializing it
> */
> mutex_unlock(&dev->lock);
> ...
>
> And this is the open code:
>
> static int em28xx_v4l2_open(struct file *filp)
> {
> ...
> mutex_lock(&dev->lock);
> ...
> mutex_unlock(&dev->lock);
>
It's probably worth noting that this change is actually pretty badly
broken. Because the modules are loading asynchronously, there is a
high probability that the em28xx-dvb driver will still be loading when
hald connects in to the v4l device. That's the big reason people
often see things like tvp5150 i2c errors when the driver is first
loaded up.
It's a good idea in theory, but pretty fatally flawed due to the async
loading (as to make it work properly you would have to do something
like locking the mutex in em28xx and clearing it in em28xx-dvb at the
end of its initialization).
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
