Re: V4L-DVB drivers and BKL

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

Devin Heitmueller wrote:
> On Thu, Apr 1, 2010 at 1:36 PM, Mauro Carvalho Chehab
> <mchehab@redhat.com> wrote:
>> 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.
> 
> Yes, that is correct.  The problem effects both dvb and alsa, although
> empirically it is more visible with the dvb case.

In the case of the initialization, the lock is needed, even if we fing a
way to load the module synchronously.

> 
>> 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.
> 
> The problem is because hald sees the new device and is making v4l2
> calls against the tvp5150 even though the gpio has been toggled over
> to digital mode.  Hence an i2c lock won't help. 

If the i2c lock was toggled to digital mode, then it means that the i2c
code is being in use simultaneously by analog and digital mode. It also
means that an i2c IR device, or alsa will have troubles also. So, we
really need one i2c lock that will protect the access to the I2C bus as
a hole, including the i2c gate.

> We would need to implement proper locking of analog versus digital mode, 
> which unfortunately would either result in hald getting back -EBUSY on open
> of the V4L device or the DVB module loading being deferred while the
> v4l side of the board is in use (neither of which is a very good
> solution).

Yes, this is also needed: we shouldn't let simultaneous stream access to the
analog and digital mode at the same time, but I don't see, by itself, any problem
on having both analog and digital nodes opened at the same time. So, the solution
seems to lock some resources between digital/analog access.
 
> This is what got me thinking a few weeks ago that perhaps the
> submodules should not be loaded asynchronously.  In that case, at
> least the main em28xx module could continue to hold the lock while the
> submodules are still being loaded.
> 
> Devin
> 


-- 

Cheers,
Mauro