From mboxrd@z Thu Jan 1 00:00:00 1970 From: Tony Lindgren Subject: Re: Pending March patches -- OMAP DPSGW code migration Date: Fri, 20 Apr 2007 21:31:44 +0000 Message-ID: <20070420213144.GC25938@atomide.com> References: <20070404130449.GB29129@atomide.com> <20070404.171005.129442185.Hiroshi.DOYU@nokia.com> <20070404143651.GD29129@atomide.com> <20070410.103625.110115446.Hiroshi.DOYU@nokia.com> <20070410195648.GA19808@linux-sh.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Content-Disposition: inline In-Reply-To: <20070410195648.GA19808@linux-sh.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: linux-omap-open-source-bounces@linux.omap.com Errors-To: linux-omap-open-source-bounces@linux.omap.com To: Paul Mundt Cc: Toshihiro.Kobayashi@nokia.com, linux-omap-open-source@linux.omap.com, Komal.shah802003@gmail.com, Hiroshi DOYU List-Id: linux-omap@vger.kernel.org Hi, * Paul Mundt [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