On Fri, Aug 15, 2008 at 10:20 PM, Felipe Contreras <[EMAIL PROTECTED]> wrote: > On Fri, Aug 15, 2008 at 7:01 PM, Woodruff, Richard <[EMAIL PROTECTED]> wrote: >> 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. > > Not true: 13 errors, 246 warnings. > >> 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. > > What TI has offered so far is code, and the comments have been on this > code. You seem to want maintainers to understand that this is code > that works "today", but I don't think the code can be tested right now > since the tools (CE/Link) are not available out in the open.
Err, I got confused about the CE/Link, I meant the xdctools... or whatever is needed to compile DSP nodes. AFAIK the DSP compiler is not enough. -- Felipe Contreras -- 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
