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

Hiroshi DOYU
2008-08-18T13:35:52Z

Hi all,

This is a draft proposal for the bridge TODO list just as a
starter. For the details, lots of comments could be added and
discussed here.

The basic concept is that, at first, we will make every components
a little bit more basic, small, primitive and independent(small kernel
modules), pushing out the kind of operating policies from modules to
more upper layers, and then reconstruct the system again with the
above primitive components to be more *unix-like* way. This may be the
bottom up approach, replacing every component **step by step** with
the always working system and finally we will get the new one. This
may allow us always to keep the working system and also be more
flexible to have multiple implementation(bridge, dspgateway and
something new) easily, on the top of the above basic
components. Ideally it would be nice if some of components were pushed
out in userland, but there may be the trade-off of performance.

The major points are listed below:

Small cleanups
--------------
There are still quite lots of trivial things, naming convention,
etc. In detail, please check:

- Documentation/CodingStyle
- Documentation/SubmitChecklist
- Documentation/SubmittingPatches

This can be cleaned up along with the other changes gradually.

Replace home-brewed APIs by native kernel APIs
----------------------------------------------

Most of the files under "drivers/dsp/bridge/services" and
"drivers/dsp/bridge/gen" seem just to provide the almost same
basic in-OS functionalities as Linux in-kernel APIs provided, like
"list", "ISR", "softIRQ", "Notifier", "locking", "bitmap", "clk" and
so on with some bridge specific debug tracing feature. The fundamental
kernel APIs should be covered by native Linux kernel APIs.

In-kernel APIs(ex: PRCM) should be used, instead of direct access for
registers.

I expect that this task would reduces the code size quite a lot.

Use "arch/arm/plat-omap/mmu.o" as generic mmu operations
---------------------------------------------------------
The "dspgateway" has to be modified a little, too. IVA[1,2], C5x and
Camera can use the same algorithm with this driver.

Use "arch/arm/plat-omap/mailbox.o" as generic mailbox operations
-----------------------------------------------------------------
The "dspgateway" has to be modified a little, too.

Make communication "protocol" more independent
-----------------------------------------------
<TBD>
The communication which "shared memory" and "interrupt based mailbox"
provide shouldn't impose any operation policies on the above "mmu" and
"mailbox" drivers.

Push out some components into userland
---------------------------------------
At least, The "doff loader" should be pushed out because it reads
files from in-kernel. There's already sample implementation which
Trilok has done before. Need to evaluate the performance again.

Define bridge Interfaces
------------------------
<TBD>
This was already described in the following thread:
http://linux.omap.com/pipermail/linux-omap-open-source/2007-April/009540.html
I think that this is also tightly related to TI's roadmap, support
plan and so on.....

Probably I missed lots of things here, any comments/corrections would
be appreciated. I'd like to get the rough impression of feasibility of
the above items from TI.

If people have to think about the multi OS support, then that would be
the first to discuss. It may be beyond my imagination, though....

BTW: The latest update from omapzoom has been updated in the bridge patches:

http://www.muru.com/linux/tidspbridge/

Hiroshi DOYU