Hi, > From: [EMAIL PROTECTED] [mailto:linux-omap- > [EMAIL PROTECTED] On Behalf Of Tony Lindgren > * Hiroshi DOYU <[EMAIL PROTECTED]> [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. Regards, Richard W. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
