Re: V4L-DVB drivers and BKL

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thursday 01 April 2010 20:56:19 Devin Heitmueller wrote:
> On Thu, Apr 1, 2010 at 2:42 PM, Mauro Carvalho Chehab
> <mchehab@xxxxxxxxxx> 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 majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Linux Input]     [Video for Linux]     [Gstreamer Embedded]     [Mplayer Users]     [Linux USB Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [Yosemite Backpacking]
  Powered by Linux