Hans Verkuil wrote:
>> Hans Verkuil wrote:
>> - performance is important only for the ioctl's that directly handles
>> the streaming (dbuf/dqbuf & friends);
>
> What performance? These calls just block waiting for a frame. How the hell
> am I suppose to test performance anyway on something l
> Hans Verkuil wrote:
>> On Tuesday 06 April 2010 00:58:54 Hans Verkuil wrote:
>>> On Tuesday 06 April 2010 00:46:11 Laurent Pinchart wrote:
On Sunday 04 April 2010 05:14:17 David Ellingsworth wrote:
> After looking at the proposed solution, I personally find the
> suggestion for a se
Hans Verkuil wrote:
> On Tuesday 06 April 2010 00:58:54 Hans Verkuil wrote:
>> On Tuesday 06 April 2010 00:46:11 Laurent Pinchart wrote:
>>> On Sunday 04 April 2010 05:14:17 David Ellingsworth wrote:
After looking at the proposed solution, I personally find the
suggestion for a serializat
On Tuesday 06 April 2010 00:58:54 Hans Verkuil wrote:
> On Tuesday 06 April 2010 00:46:11 Laurent Pinchart wrote:
> > On Sunday 04 April 2010 05:14:17 David Ellingsworth wrote:
> > > After looking at the proposed solution, I personally find the
> > > suggestion for a serialization flag to be quite
On Tuesday 06 April 2010 00:46:11 Laurent Pinchart wrote:
> On Sunday 04 April 2010 05:14:17 David Ellingsworth wrote:
> > After looking at the proposed solution, I personally find the
> > suggestion for a serialization flag to be quite ridiculous. As others
> > have mentioned, the mere presence of
On Sunday 04 April 2010 05:14:17 David Ellingsworth wrote:
> After looking at the proposed solution, I personally find the
> suggestion for a serialization flag to be quite ridiculous. As others
> have mentioned, the mere presence of the flag means that driver
> writers will gloss over any concurre
After looking at the proposed solution, I personally find the
suggestion for a serialization flag to be quite ridiculous. As others
have mentioned, the mere presence of the flag means that driver
writers will gloss over any concurrency issues that might exist in
their driver on the mere assumption
- Original Nachricht
Von: Andy Walls
An: Mauro Carvalho Chehab
Datum: 03.04.2010 02:47
Betreff: Re: [RFC] Serialization flag example
> On Fri, 2010-04-02 at 18:15 -0300, Mauro Carvalho Chehab wrote:
> > Devin Heitmueller wrote:
>
> > In the case of a
On Fri, 2010-04-02 at 18:15 -0300, Mauro Carvalho Chehab wrote:
> Devin Heitmueller wrote:
> In the case of a V4L x DVB type of lock, this is not to protect some memory,
> but,
> instead, to limit the usage of a hardware that is not capable of
> simultaneously
> provide V4L and DVB streams. This
On Fri, 2010-04-02 at 10:57 +0200, Hans Verkuil wrote:
> If needed one could allow drivers to override this function. But again, start
> simple and only make it more complex if we really need to. Overengineering is
> one of the worst mistakes one can make. I have seen too many projects fail
> beca
Devin Heitmueller wrote:
> On Fri, Apr 2, 2010 at 1:43 PM, Manu Abraham wrote:
>> IMO, A framework shouldn't lock.
Current DVB framework is locked with BKL. I agree that an unconditional
lock like this is very bad. We need to get rid of it as soon as possible.
> Hello Manu,
>
> The argument I
On Fri, Apr 2, 2010 at 2:24 PM, Manu Abraham wrote:
> Hi Devin,
>
>> Hello Manu,
>>
>> The argument I am trying to make is that there are numerous cases
>> where you should not be able to use both a particular DVB and V4L
>> device at the same time. The implementation of such locking should be
>>
Hi Devin,
> Hello Manu,
>
> The argument I am trying to make is that there are numerous cases
> where you should not be able to use both a particular DVB and V4L
> device at the same time. The implementation of such locking should be
> handled by the v4l-dvb core, but the definition of the relati
On Fri, Apr 2, 2010 at 1:43 PM, Manu Abraham wrote:
> On Thu, Apr 1, 2010 at 10:24 PM, Mauro Carvalho Chehab
> wrote:
>
>> You'll have issues also with -alsa and -dvb parts that are present on the
>> drivers.
>>
>> Also, drivers like cx88 have another PCI device for mpeg-encoded streams. It
>>
On Thu, Apr 1, 2010 at 10:24 PM, Mauro Carvalho Chehab
wrote:
> You'll have issues also with -alsa and -dvb parts that are present on the
> drivers.
>
> Also, drivers like cx88 have another PCI device for mpeg-encoded streams. It
> behaves
> like two separate drivers (each with its own bind cod
Hans Verkuil wrote:
> On Thursday 01 April 2010 23:32:33 Mauro Carvalho Chehab wrote:
>> Hans Verkuil wrote:
Maybe a better alternative would be to pass to the V4L2 core, optionally,
some lock,
used internally on the driver. This approach will still be pedantic, as
all ioctls
On Thursday 01 April 2010 23:32:33 Mauro Carvalho Chehab wrote:
> Hans Verkuil wrote:
> >> Maybe a better alternative would be to pass to the V4L2 core, optionally,
> >> some lock,
> >> used internally on the driver. This approach will still be pedantic, as
> >> all ioctls will
> >> keep being se
Hans Verkuil wrote:
>> Maybe a better alternative would be to pass to the V4L2 core, optionally,
>> some lock,
>> used internally on the driver. This approach will still be pedantic, as all
>> ioctls will
>> keep being serialized, but at least the driver will need to explicitly
>> handle the loc
On Thursday 01 April 2010 20:24:12 Mauro Carvalho Chehab wrote:
> Hans,
>
>
> Hans Verkuil wrote:
> > I made a quick implementation which is available here:
> >
> > http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-serialize
> >
> > It's pretty easy to use and it also gives you a very simple way to b
Hans,
Hans Verkuil wrote:
> I made a quick implementation which is available here:
>
> http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-serialize
>
> It's pretty easy to use and it also gives you a very simple way to block
> access to the video device nodes until all have been allocated by simply
>
I made a quick implementation which is available here:
http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-serialize
It's pretty easy to use and it also gives you a very simple way to block
access to the video device nodes until all have been allocated by simply
taking the serialization lock and holding
21 matches
Mail list logo
