Hans, I am bit confused about your usage of "davinci". Are you referring to vpfe capture driver and dm6467 display driver vs OMAP ? I know at least in these drivers it doesn’t allocate buffer at init time, but only on REQBUF. I need to add this support (buffer allocation at init time) in the driver. One way to allocate buffer in driver at init time is to use dma_declare_coherent_memory() and pass physical memory address (outside the kernel memory space) to this API. I am not aware of any other way of doing this. Please let me know If there are alternate ways of doing this. Also which OMAP file I can refer to understand the implementation you are referring to? Murali Karicheri Software Design Engineer Texas Instruments Inc. Germantown, MD 20874 email: m-karicheri2@xxxxxx >-----Original Message----- >From: linux-media-owner@xxxxxxxxxxxxxxx [mailto:linux-media- >owner@xxxxxxxxxxxxxxx] On Behalf Of Hans Verkuil >Sent: Wednesday, July 29, 2009 5:52 PM >To: Karicheri, Muralidharan >Cc: Laurent Pinchart; Mauro Carvalho Chehab; Dongsoo, Nathaniel Kim; >v4l2_linux; Dongsoo Kim; 박경민; jm105.lee@xxxxxxxxxxx; ì�´ì„¸ë¬¸; >대ì�¸ê¸°; 김형준 >Subject: Re: How to save number of times using memcpy? > >On Wednesday 29 July 2009 21:06:17 Karicheri, Muralidharan wrote: >> Hans, >> >> >True. However, my experience is that this approach isn't needed in most >> >cases as long as the v4l driver is compiled into the kernel. In that >> > case it is called early enough in the boot sequence that there is still >> > enough unfragmented memory available. This should definitely be the >> > default case for drivers merged into v4l-dvb. >> >> In my understanding, the buffer is allocated in the video buffer layer >> when driver makes the videobuf_reqbufs() call. > >That depends completely on the driver implementation. In the case of the >davinci driver it will allocate memory for X buffers when the driver is >first initialized and it will use those when the application calls reqbufs. >If the app wants more than X buffers the driver will attempt to dynamically >allocate additional buffers, but those are usually hard to obtain. > >In my experience there is no problem for the driver to allocate the >required >memory if it is done during driver initialization and if the driver is >compiled into the kernel. > >> Since this happens after >> the kernel is up, this is indeed a serious issue when we require HD >> resolution buffers. When I have tested vpfe capture from MT9T031 with >> 2048x1536 resolution buffer, the video buffer layer gives an oops due to >> failure to allocate buffer( I think video buffer layer is not handling >> error case when there are not enough buffers to allocate). Since buffer >> allocation happens very late (not at initialization), it is unlikely to >> succeed due to fragmentation issue. > >That is really a driver problem: omap should use the same allocation scheme >as davinci does. That works pretty reliably. Of course, if someone tries to >squeeze the last drop out of their system, then they still may have to use >nasty tricks to get it to work (like using the mem= kernel option). But >such tricks are a last resort in my opinion. > >> So I have added support for USERPTR >> IO in vpfe capture to handle high resolution capture. This requires a >> kernel module to allocate contiguous buffer and the same is returned to >> application using an IOCTL. The physical/logical address can then be >> given to driver through USERPTR IO. > >What exactly is the point of doing this? I gather it is used to pass the >same physical memory from e.g. a capture device to e.g. a resizer device, >right? Otherwise I see no benefit to doing this as opposed to regular mmap >I/O. > >Regards, > > Hans > >> Another way this can be done, when using mmap IO, is to allocate device >> memory (I have not tried it myself, but this seems to work in SOC Camera >> drivers) using dma_declare_coherent_memory() (Thanks to Guennadi >> Liakhovetski for the suggestion). This function takes physical memory >> address outside the kernel memory space. Then when dma_alloc_coherent() >> is called by video buffer layer, the buffer is allocated from the above >> pre-allocated device memory and will succeed always. But for this, the >> target architecture require support for consistent memory allocation. >> >> Murali >> >> >Regards, >> > >> > Hans >> > >> >-- >> >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 >> >> -- >> 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 > > > >-- >Hans Verkuil - video4linux developer - sponsored by TANDBERG Telecom >-- >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 ��.n��������+%������w��{.n�����{��g����^n�r������&��z�ޗ�zf���h���~����������_��+v���)ߣ�m
