Re: [RFC][DRAFT] TODO list for TI DSP BRIDGE

[Sakari Ailus <sakari.ailus@nokia.com>]

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@nokia.com