[prev in list] [next in list] [prev in thread] [next in thread] 

List:       mjpeg-users
Subject:    Re: [Mjpeg-users] [PATCH,
From:       Trent Piepho <xyzzy () speakeasy ! org>
Date:       2008-09-05 19:03:10
Message-ID: Pine.LNX.4.58.0809051157290.2423 () shell2 ! speakeasy ! net
[Download RAW message or body]

On Wed, 3 Sep 2008, Jean Delvare wrote:
> I see the following as a definitive improvement compared to the
> previous situation. It's probably possible to improve it further and I
> welcome comments in that direction. In general I would like to know how
> other Zoran developers and users feel about this change, if there are
> major objections, etc. And of course I welcome reports from testers :)

I remember this comming up before when I wanted to change it.  I think it
makes the most sense to try to use the highmem or bigphysarea first if they
are there, then fall back to kmalloc with no limits.  If kmalloc fails one
can always return ENOMEM.

An option to allocate some buffers on module load might be a good idea.

But going forward, it's probably desirable to convert the driver to use the
video-buf system.  I think Mauro's mentioned this before.  I'm pretty sure
video-buf now has support for contiguous buffers as well as vmalloced
buffers.  But using both at the same time like zr36067 does might cause
problems.

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Mjpeg-users mailing list
Mjpeg-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mjpeg-users
[prev in list] [next in list] [prev in thread] [next in thread]