On Thursday 01 April 2010 20:29:52 Devin Heitmueller wrote:
> On Thu, Apr 1, 2010 at 1:36 PM, Mauro Carvalho Chehab
> <[email protected]> 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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
