Re: V4L-DVB drivers and BKL

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

 



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.

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.

Devin

-- 
Devin J. Heitmueller - Kernel Labs
http://www.kernellabs.com
--
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