On Thursday 01 April 2010 20:56:19 Devin Heitmueller wrote:
> On Thu, Apr 1, 2010 at 2:42 PM, Mauro Carvalho Chehab
> <mche...@redhat.com> wrote:
> > 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.
>
> Most i2c locks typically are only held for the duration of a single
> i2c transaction. What you are proposing would likely result in just
> about every function having to explicitly lock/unlock, which just
> seems bound to be error prone.
>
> >> 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.
>
> I think this is probably a bad idea. The additional granularity
> provides you little benefit, and you could easily end up in situations
> where power is being continuously being toggled on the decoder and
> demodulator as ioctls come in from both analog and digital. The
> solution would probably not be too bad if you're only talking about
> boards where everything is powered up all the time (like most of the
> PCI boards), but this approach would be horrific for any board where
> power management were a concern (e.g. USB devices).
>
> A fairly simple locking scheme at open() would prevent essentially all
> of race conditions, the change would only be in one or two places per
> bridge (as opposed to littering the code with locking logic), and the
> only constraint is that applications would have to be diligent in
> closing the device when its not in use.
I agree. The biggest problem with v4l-dvb devices is driver complexity. It
has never been performance. Reducing that complexity by moving some of that
into the core is a good thing in my view.
> We've got enough power management problems as it is without adding
> lots additional complexity with little benefit and only increasing the
> likelihood of buggy code.
Right.
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 majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
