Hi,
ext Woodruff, Richard wrote:
I think recently some one from TI posted OMAP3 camera driver at
linux-v4l2 mailing list and which I think was using camera MMU,
but not the common MMU framework it seems from the description.
They should first start converting to the common MMU
infrastructure then.
http://lists-archives.org/video4linux/23215-omap3-camera-driver.html
We must make the MMU framework generic for the coprocessors,
otherwise maintenance will be a nightmare and the code will never
get merged upstream.
I agree with Tony.
Many implementations are more likely have more bugs than one, too.
Main issues are at outer interfaces which deal with OS memory system
interaction. The other aspects of the code have been self contained.
The local MMU usages are not maintenance intensive like linux PTE
structures as Linux more strongly couples with the hardware table
representations.
Seems some of the subsystems like v4l2 do provide local abstractions
but there isn't always global ones (vmalloc to sg list for example).
The V4L2 provides functions for mapping the video buffers to kernel
memory, but that's not the point. The OMAP 3 ISP driver for example
would benefit from common MMU framework directly as it just wants to map
the video buffers continuously to some address and sometimes flush them.
Creating page tables for the mappings is necessary in practice.
This sounds very much like something that would be useful for a number
of drivers for OMAP 3 in addition to the ISP driver.
If there was a generic way for asking the MMU to map the buffer it
would be simple for the ISP driver to use that.
(Besides, it'd be easy to add MMU support for the OMAP 2 camera driver
as well if there was a generic framework. Aren't the MMUs similar or
even the same?? :))
(I'm adding Mohit Jalori to Cc:.)
Regards,
--
Sakari Ailus
sakari.ailus@xxxxxxxxx
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
