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. 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. 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. 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
