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 majord...@vger.kernel.org
>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 majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to