Re: Pending March patches -- OMAP DPSGW code migration

[Tony Lindgren <tony@atomide.com>]

Hi,

* Paul Mundt <lethal@linux-sh.org> [070410 20:00]:
> On Tue, Apr 10, 2007 at 10:36:25AM +0300, Hiroshi DOYU wrote:
> > > OK. I'll drop the "ARM: OMAP: Add DSP common code" patch from
> > > omap-upstream for now. Then we can put together the minimal DSP init
> > > patch later on for 2.6.23 or something. The omap-upstream queue is
> > > already painfully big :)
> > >
> > > What do you think we should keep in plat-omap?
> > >
> > > Maybe just something to power up and idle the DSP, and allow using McBSP
> > > for audio?
> > 
> > Yes, it may be like that.
> > 
> It's probably worth pushing the MMU framework bits also, since it will
> also be required for things like the camera MMU. Though it's not worth
> pushing infrastructure if there are no in-tree users.

Yeah, the MMU framework could be pushed after 2.6.22.

> > Now there are some H/W combinations coming, like ARM+IVA1, ARM?+IVA2,
> > , OMAP730, ARM?+?. Also there exists TI's S/W bridge implementation
> > and TI's middlewares on the top of that. All of them uses the same
> > kind of "interrupt based mailbox", "shared memory" and "MMU control"
> > to communicate between MPU and DSP, though their implementations are
> > somewhat different. So, now the situation is getting complicated
> > because there are the several kind of S/W and H/W combinations.
> > 
> The other thing to consider also is how generic these sorts of things can
> be made. We're in a position now where both spufs and dspgw take very
> different approaches to a fairly common problem. Trying to maintain API
> or ABI compatability with the old code is likely not worth the trouble in
> the long run, particularly as that's not something that has a lot of
> chance of being merged upstream.
> 
> > For "BASIC S/W COMPONENTS", at least, there may be following modules
> > 
> >   - OMAP non-MPU MMU FW
> >   - MAILBOX
> >   - IPC message protocol
> >   - Shared memory management
> >   - DSP processor management/control
> 
> It should be possible to do these generically from an API level at least.

I'd say let's only keep the minimum to boot omap under
arch/arm/plat-omap:

- Minimal DSP support to idle the DSP
- Support for enabling audio McBSP clocks
- MMU framework as it is shared with camera

The rest can go to drivers/dsp/omap.

> >   - DSP TASK/NODE, STREAM management
> 
> This has to be platform specific.
> 
> >   - DSP COFF/DOFF loader
> > 
> And this can mostly be in userspace. Other platforms for instance do use
> in-kernel loaders, but generally only for ELF. The MIPS VPEs are an
> example of this, albeit for a slightly different usecase.
> 
> >   - character device interface "/dev/dsptask?"	(ex: DSPGW)
> >   - user defined "ioctl()" messages		(ex: TI's bridge)
> >   - DSP specified filesystem, "DSPFS"		(most reasonable one)
> >   - userland device driver
> >   - nice fancy interfaces?                      (no idea for me, now)
> > 
> I would like to see a consolidation between dspfs and process context as
> per the RidgeRun TaskBridge. Rolling a special library and interfaces
> makes little sense for places where regular system calls will suffice
> just fine. The SPU libraries end up doing this via pthreads, but I
> suppose kernel threads will be required for most of these cases (this is
> what TaskBridge did also).

As far as I remember, the RidgeRun bridge had a cool feature of piping
data to the DSP processes :)

> > The above interfaces can be wrapped by userland library API to keep
> > the compatibility for the existing middleware interfaces.
> > 
> That's another problem entirely. Writing userspace wrappers around this
> stuff for API compatability is of course an option, but it's not worth
> carrying extra weight around on the kernel side to try and accomodate
> this sort of thing, especially if there's a better way to do codec
> manipulation.

Regards,

Tony