On Thursday 01 April 2010 20:29:52 Devin Heitmueller wrote: > On Thu, Apr 1, 2010 at 1:36 PM, Mauro Carvalho Chehab > <mchehab@xxxxxxxxxx> 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. > > > 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. 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). > > 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. What was the reason behind the asynchronous loading? In general it simplifies things a lot if you load modules up front. Regards, Hans > > Devin > > -- Hans Verkuil - video4linux developer - sponsored by TANDBERG -- 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
