Karicheri, Muralidharan wrote:
Murali Karicheri
Software Design Engineer
Texas Instruments Inc.
Germantown, MD 20874
Phone : 301-515-3736
email: [EMAIL PROTECTED]
------------------------------------------------------------------------
*From:* Stephen Berry [mailto:[EMAIL PROTECTED]
*Sent:* Tuesday, September 02, 2008 10:37 AM
*To:* Karicheri, Muralidharan
*Cc:* pavelhan; davinci-linux-open-source
*Subject:* Re: Ipipe req_bufs failed
There are a bunch of issues using kernel memory space. Even when you
do have enough to use for a large 5Mpix buffer (which is 10MB) it
seems to get fragmented over time. So while you might be able to
allocate it once, once it gets freed all bets are off the next time
you want to use it.
In addition there is a problem with buffers that large to begin with.
There is a #define in the kernel, the name of which escapes me at the
moment, which defines the largest page size you can allocate, and it's
too small. Changing it recompiles everything in the kenel, and was
just a little scary...
Also, I remember that I've had issues with CMEM and V4l2. Last time I
tried to pass in a USERPTR to the V4L2 (and vpfe) all of my DQBUF
calls failed.
*/[MK] Have you tried increasing the size of kernel buffers allocated
by V4L2 capture? This will allocate at init time and reserve the
pages. You could then use the ptr from DQBUF to pass to ipipe driver.
V4L2 capture currently support only mmaped IO./*
I have tried this, but there is a drawback to this method. The V4l2
driver will not let me only allocate only 1 buffer - the minimum is two.
This is a fairly large waste of memory when I only need one buffer for
still 5MP captures. I also need to be flexible with resolutions, since I
want to be able to capture video at vga & HD, so I will need 3 buffers -
but they don't need to be 10MB each!!
I'll figure away around this (like subdividing up a large buffer for the
lower res), but it's not as nice as feeding memory pointers into the V4l2...
Are there any examples on how to use CMEM with V4l2?
Steve
Karicheri, Muralidharan wrote:
Hello,
You are actually reducing the memory available to kernel by setting
mem=80M. What you might want to do is to allocate memory using CMEM
and use it instead of req_buf. Request buffer allocates memory from
kernel memory space. Otherwise, use bigger kernel memory instead of
reducing it.
*From:* [EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>
[mailto:[EMAIL PROTECTED] *On
Behalf Of *pavelhan
*Sent:* Tuesday, September 02, 2008 5:52 AM
*To:* davinci-linux-open-source
*Subject:* Ipipe req_bufs failed
Hi everyone!
I want to get a full resolution 5MP(2592x1944) picture from my MT9p031
sensor.
but I failed when I req_buffers in the ipipe initialization procedure.
I allocate a 80M memory to my linux in the bootargs(mem=80M),so I
think there is
a enough space for I allocate 1 5MP ipipe buffer from linux(which will
require about
10M bytes),but when I execute the program, I only get the following
errors:
starting mt9p001_ipipe_init
IPIPE idm355_ipipe dm355_ipipe.2: 4.request_buffer:not
enough memory
nit
IPIPE_REQBUF fail
IPIPE init fail
what should I do to get the problem solved?
any help will be appreciated!
Thank you!
2008-09-02
------------------------------------------------------------------------
Pavel Han
Oplinx Co.,Ltd
Address:Hanggang Fuchun Business Mansion 2116# Futian, Shenzhen 518041,PRC
Tel: (086)0755-88359865
Website:www.oplinx.com.cn
E-mail: [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>
------------------------------------------------------------------------
_______________________________________________
Davinci-linux-open-source mailing list
[email protected]
<mailto:[email protected]>
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
--
Integral Design and Development
312 Great Rd, Littleton MA 01460
voice: 978 501 7658 fax: 603-679-3988
This e-mail and any files transmitted with it are confidential and intended solely for the use of the individual or entity to which they are addressed. If you have received this e-mail in error please notify the originator immediately. The addressee is formally notified hereby that this e-mail and any attachments are to be treated as confidential.
_______________________________________________
Davinci-linux-open-source mailing list
[email protected]
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
