Hi Paul, On Dec 4, 2007 1:54 PM, Paul Mundt <lethal@xxxxxxxxxxxx> wrote: > On Tue, Dec 04, 2007 at 12:04:25PM +0530, Trilok Soni wrote: > > On Dec 4, 2007 3:56 AM, Tony Lindgren <tony@xxxxxxxxxxx> wrote: > > > I'm preparing the MMU patches for submission to arm-linux mailing > > > list, and Paul Mundt requested changing the MMU license to be > > > GPLv2. Can you please take a look at the attached patch and ack? > > > > Good to see that MMU fwk going mainline, but I am concerned about the > > users of MMU fwk as of now, dspgw looks like may not be accepted to > > mainline yet, and OMAP2 camera driver is still not using the MMU fwk > > for it's MMU and IVA driver is no where in sight, in this case I don't > > know what purpose MMU fwk will serve in mainline code? > > > Whether the IVA stuff ever materializes or whether the dspgateway > implementation and the camera driver ever become useful to the point of > merging or not are pretty separate issues in this regard. The main thing > here is that by exposing coherent interfaces for the MMUs in these parts, > it's possible for people to actually do something with the underlying > peripherals (as far as mapping things in and out of their respective > address spaces, and so on). So I would consider it useful from a > peripheral enabling point of view wholly independently from the rest. Good. Agreed. > > Practically speaking, the toolchain mess for IVA and the DSP already mean > that there are significant barriers for people being able to easily do > anything with these blocks openly, and if there were actual motivation > for that to happen by the vendors pushing this, it would have happened a > long time ago. It's worth providing as much of an open interface to > playing with these various blocks as possible just so people have the > option of doing _something_ with them. During the TI Developer Conference and pre-conf business meetings, Bangalore last week top TI guys gave a sign of releasing DSPBridge ARM kernel driver part, where DSP BIOS side will still be closed. If you relate this to the hints from Richard on low-cost OMAP2/3 boards which are going to come in near future, it might happen that toolchains along with bridge driver for IVA2.0 + C64x DSP will be released along with that boards, like it happened int the case of OMAP1 OSK kit. > > Additionally, if such a thing is never integrated, there's also zero push > for getting the guilty parties (ie, OMAP2 camera driver) playing well > with others. At this point I think the MMU framework stands by itself, > and I think you're taking a fairly optimistic outlook if you believe the > other drivers will get cleaned up first -- especially as the current > situation is not so different from where things were a couple of years > ago :-) > True, not so different yet. Let's wait for TI to re-think on how their dsp's and baby accelerators wants to get supported and maintained in future along with Linux community, as OMAP is very much getting non-wireless move. -- --Trilok Soni - 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
