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
