Re: V4L-DVB drivers and BKL

[Mauro Carvalho Chehab <mchehab@redhat.com>]

Devin Heitmueller wrote:
> On Thu, Apr 1, 2010 at 11:02 AM, Mauro Carvalho Chehab
> <mchehab@redhat.com> 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).

If you take a look at em28xx-dvb, it is not lock-protected. If the bug is due
to the async load, we'll need to add the same locking at *alsa and *dvb
parts of em28xx.

Yet, in this specific case, as the errors are due to the reception of
wrong data from tvp5150, maybe the problem is due to the lack of a 
proper lock at the i2c access. 


> 
> Devin
> 


-- 

Cheers,
Mauro