On Tuesday 20 January 2009, David Brownell wrote: Hi David & Kevin.
[My apologies for being out of the loop on this. I just subscribed a few mins ago and still catching up on the emails.] > On Tuesday 20 January 2009, Sergei Shtylyov wrote: > > > Either way, the lack of a complete proposal (not necessarily > > > in the form of patches) makes it hard to get anywhere with > > > such OMAP-L1xx discussions... > > > > I think I've expressed it clear enough: common shared code is > > to be moved to plat-davinci/ and OMAP-L1x support is to be > > added into new mach- directory. > > And yet Kevin felt that was missing details (not complete)... > > While that sounds plausible to me at this point, it's also > clear that the missing details could make a big difference. > > I suspect that until patches appear, discussion can get no > further. Plus, if it's going to be "mach-omap-L1" it'd > be good to have enough detail that the OMAP team (and RMK) > can see why it should pair with "plat-davinci" instead of > the more obvious "plat-omap". Regarding the name ------------------ I really don't like the omap creep that's happening. The da830 is based on davinci and not at all on an omap so I'd like to keep it contained as possible. TI has expressed a strong desire to have both so our current plan is the rename the defconfig to "da830_omapl137_defconfig" and menuconfig text options to say "DA830/OMAP-L137...". I don't know if this will be acceptable to the community. Regarding the code split ------------------------ I agree, I don't think there has been a convincing argument yet. I'll try to make one... First some background. We originally put the da8xx code (what we've called it but da830 may be a better name) in mach-davinci. We fought with that for quite some time but all the #ifdef's and other ugly things continued to add up as we learned more nits about the hardware that made it more & more different than a true davinci. So, we ended up splitting the code. The biggest drivers for splitting the code (that I remember ATM) were: 1) Reduce the amount of #ifdef-ery and other ugliness; however we didn't split include/asm-arm/arch-davinci (but neither did omap). 2) Remove unnecessary bloat from davinci code & data laying around but entirely useless to us. 3) There was a precedent set by the omap code so we followed the basics of how that split was made. Some more notes: - We (or at least *I*) had no desire to have the same kernel binary run on both a da8xx and a davinci. So, cutting out the davinci runtime code & data that was wasting memory was "A Good Thing (tm)". - We put the common code in plat-davinci and took the da8xx code out of mach-davinci and put into a new dir, mach-da8xx. Basically following the model of the omap code. - Split clock.c. The main reason was different base addrs for the psc & pll cntrl base. - devices.c contents has virtually no common code between the two. - 'struct map_desc' data in io.c is different. da8xx has 2 entries and different addresses than the davincis. Could probably solve at runtime instead, if that was necessary. - Need different Makefile.boot files because of different phys addrs for system memory. - Split time.c. Again different base addresses was main reason for the split. - The SPI setup code is quite different. - Entirely different interrupt controller. - Entirely different dma controller. - There are probably others that I've forgotten. None of these by themselves are all that convincing but they add up to a mess if they aren't split. Either way, we need some sort of factoring out of common code so the question is, do we keep the da8xx and common code in the same directory or not? IMHO, there's enough complete different stuff on the da8xx that it warrants its own directory (and therefore common code should go in a plat-<xx> directory). Otherwise, we're just putting two different things in the same bucket for no valid reason. This is debatable, of course. MHO would change if there really was a strong desire to have the same kernel binary run on both types of SoC's. Is there? Mark -- _______________________________________________ Davinci-linux-open-source mailing list [email protected] http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
