Lorenzo Lutti wrote: > From: "Kevin Hilman" <[EMAIL PROTECTED]> > >> Your work on both of these areas would be much >> appreciated. Please keep >> the list updated on your progress as I know there are >> others interested >> in SPI. > > Ok, I will do it. I'm currently writing a very simple SPI driver, just for > HW testing purposes (bitbanged, totally synchronous, not using the kernel > SPI infrastructure, etc...), then I'll try to port the OMAP SPI driver.
Sounds good. Of course, the use of the new kernel SPI infrastructure in the git tree is the preferred method in the long term. >> Hope that helps answer you questions. > > You have been clear, thank you! This "two branches" approach is good, but it > has a drawback: the bleeding-edge/experimental tree should be an extension > of the stable tree, i.e. it should include all the functionalities of the > stable tree; > in this way, the developers can work on the experimental tree > without loosing functionalities. I agree with the ideal, but that requires a few more people contributing to the development git tree. That being said, The only things I know of that are missing from the git tree that are in the stable tree are - Video-in / VPFE driver - NAND flash driver - MMC driver (code is there, but doesn't compile) Do you know of others? But that's not the whole story. Dont' forget that the experimental tree has some things that are not in the stable tree. These are either community contributed, or made easier with kernel changes in 2.6.18. - MTD NOR driver - GPIO driver - updated USB driver (merged with OMAP2430 driver) - new RTC driver - lots of cleanup, reorganization > If for example I'm developing a new > feature, but I also need a functionality that is only present in the stable > branch, I have three possibilities: I'm curious what features are missing that prevent you from doing work on the experimental branch? > 1) Port the stable branch functionality to the experimental branch, then > develop my new features on the experimental; > 2) Develop my new features on the stable branch; > 3) Develop my new features on the experimental branch, then wait for > TI/Montavista to port it to the next stable revision. 4) Develop on experimental branch, and port them to stable branch 5) Complain that feature X is not on experimental branch and "someone" may just do it. 6) Develop on experimental branch. > To make this kind of decisions, it would be very useful to have an idea of > the "official" time schedules of TI/Montavista (that are currently a little > obscure): are there any extimated release dates for the next minor/major > revision? Which new functionalities will be included? And so on. :) I wouldn't expect anything related to dates to be anything but obscure. This is the benefit of open-source. You have all the source, you don't have to wait for anyone. You can do it yourself or beg/hire someone else to do the work. > P.S. Just out of curiosity: is there actually any major contributor/project > maintainer from TI, or this project is basically carried over completely by > Montavista? I think you are doing a great work at MV, but "officially" TI > should take care of the support for this project (there is a special license > agreement if I understood correctly), therefore I was wondering who was your > "alter ego" at TI. :-) The stable branch is developed jointly by MontaVista and TI. TI is doing the support for the stable/released product as it involves not just he kernel but other TI software (DSPLink, codecs, etc.) The experimental branch is a forward port of the stable branch to the latest community kernels, done by MontaVista (me) with notable contributions from Komal Shah and David Brownell. There is no "support" for the experimental branch, other than this mailing list. It is currently maintained by me, but the hope is that a kernel developer community will develop around the experimental tree as has happened with the OMAP git tree, such that no one person/company is controlling the project. Kevin _______________________________________________ Davinci-linux-open-source mailing list [email protected] http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
