On Wednesday 29 July 2009 20:36:25 Karicheri, Muralidharan wrote: > <Snip> > > > > the details, but I think the strategy were to pass a parameter during > > > kernel boot, for it to reserve some amount of memory that would later be > > > claimed by the V4L device. > > > > It's actually a pretty common strategy for embedded hardware (the > > "general- purpose machine" case doesn't - for now - make much sense on an > > OMAP processor for instance). A memory chunk would be reserved at boot > > time at the end of the physical memory by passing the mem= parameter to > > the kernel. Video applications would then mmap() /dev/mem to access that > > memory (I'd have to check the details on that one, that's from my memory), > > and pass the pointer the the v4l2 driver using userptr I/O. This requires > > root privileges, and people usually don't care about that when the final > > application is a camera (usually embedded in some device like a media > > player, an IP camera, ...). > > Yes. This is exactly what we are doing in the case of davinci processors. > We have a kernel module that uses memory from the end of SDRAM space and > mmap it to application through a set of APIs. They allocate contiguous > memory pools and return the same to application through IOCTLs. I have > tested vpfe capture using this approach (but yet to push the same to v4l2 > community for review). The same approach may be used across other platforms > as well. So doesn't it make sense to add this kernel module to the kernel > tree so that everyone can use it? What's wrong with mmap()'ing /dev/mem ? Why do you need a special driver ? Regards, Laurent Pinchart -- 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
