* Hiroshi DOYU <Hiroshi.DOYU@xxxxxxxxx> [080815 23:49]: > Hi Richard, > > It sounds to me that you meant that "omapzoom" should be the center of > the bridge development because of TI's internal expertise of this > area. I don't have any explicit objections at all and, at least, I > will pay some respects on omapzoom since originally TI has published > this bridge as GPLv2. > > But, in any case, we need the place to work together efficiently > now in the community. I think that "linux-omap" should have this > bridge code in itself. In that case, one could easily participate in > this bridge development without bridge porting from > "omapzoom". Otherwise, everyone who mainly uses "linux-omap" has to > port the bridge from "omapzoom" to "linux-omap" whenever one tries to > use the bridge. And also "linux-omap" is the most active development > place for omap kernel in public. It would be really nice if TI experts > participate. > > As for the roadmap issue, I think that it's a matter of trade-off. The > more open it is, the more benefit it gets from the community;). At least we need to have the DSP MMU and mailbox stuff in linux-omap tree in a clean way that's also merged to the mainline Linux. After that, it should be possible to build the rest of the DSP code as a module. And not have to deal with the MMU merging pains in multiple places everytime something changes upstream. Regards, Tony > > Hiroshi DOYU > > From: "ext Woodruff, Richard" <r-woodruff2@xxxxxx> > Subject: RE: [RFC] Port TI DSP BRIDGE for a new dedicated branch in linux-omap > Date: Fri, 15 Aug 2008 11:01:31 -0500 > > > Hi, > > > > > From: linux-omap-owner@xxxxxxxxxxxxxxx [mailto:linux-omap- > > > owner@xxxxxxxxxxxxxxx] On Behalf Of Tony Lindgren > > > * Hiroshi DOYU <Hiroshi.DOYU@xxxxxxxxx> [080815 13:34]: > > > > Thank you guys for your comments, > > > > > > > > It seems that some of the patches couldn't be sent to ML because of > > > > the size limitation of vger.kernel.org ML. Now Tony is finding the > > > > place to put the rest up on somewhere for review. I don't know if > > > > reviwing these base code makes so much sense at this momenent, > > > > though..which doesn't mean "no probelm";p > > > > > > I've copied your patches to: > > > > > > http://www.muru.com/linux/tidspbridge/ > > > > > > > I hope that everyone could work together on this branch without any > > > > problems eventually. > > > > > > We need to also figure out who's going to maintain the dspbridge > > > branch. Ideally somebody with experience with dsp and linux.. > > > > Really all the design, maintenance and test experience of that code > > is inside of TI. This has lived for years and derivates have > > shipped in products. Who ever watches over it needs to be able to > > provide a creditable multi-year commitment. > > > > As part of contributing this code there has been a lot of reworking > > of the code. Last I had heard checkpatch and sparse warnings had > > been killed. There was also a lot of work in making sure there would > > be no legal impact to the kernel to clear its ability to be > > contributed. > > > > If people really need it to work and not re-wait for a year, some > > sane strategy needs to be employed. Most people in the mainline > > kernel just won't care about a niche driver like this. As such the > > only real gate for its inclusion is mainly _here_. > > > > As there are many users/customers putting a solid and functional 1.0 > > in place would benefit everyone who needs it and would allow > > cooperative development to ensure it would indeed work starting > > _today_ and continuing into the future. TI users _today_ use and > > need this bridge. > > > > Major interface and functional partitioning changes will happen as > > such a piece of code evolves. This kind of thing seems more like 2.0 > > goals. The point is that is something to be planned in a ToDo list. > > Are their missing functions in what it provides today? > > > > For this kind of piece to be successful it needs support from many > > sides. > > > > TI is willing to support this and has the necessary critical > > technical context, incentive and attention span. Agreement is needed > > on roadmap aspects of the code. If that doesn't happen what will > > result is a lot of local patches on everyone's development tree. > > > > We have been talking about hosting it on zoom as all the originators > > and current experts of that code have direct access. -- 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
