Hello, From: Sergei Shtylyov Sent: Wednesday, January 21, 2009 5:42 PM > > Hello. > > Mark A. Greer 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.] > > > > Kind of my fault too -- I kept forgetting to CC Mark in the heat of > the argument... > > >> 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 > > > > Who does? :-) > > > 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. > > > > I'm afraid there's nothing explaining why it's DA830 now, with chip > marking having been changed to XD830 and that model name not being > mentioned anywhere in documentation... >
The part is being called DA830 in TI websites (http://focus.ti.com/apps/docs/gencontent.tsp?contentId=52385&appId=1). I am not sure if documentation with DA830 name is going to be made public. I can ask around. Thanks, Sekhar > > 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). > > > > Sigh, that actually hasn't permitted to get rid of the much #ifdef'ery... > > > 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)". > > > > Kevin seems the only person interested in ahving the same kernel > binary, not clear why though... > > > - Split clock.c. The main reason was different base addrs for the > > psc & pll cntrl base. > > > > And different # of PSCs of course. > > > - devices.c contents has virtually no common code between the two. > > > > Yeah, the base addresses and IRQs have almost all changed from DaVinci. > > > - '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. > > > > Not quite so: the 1st 'struct map_desc' is identical, the 2nd is > needed for mapping cp_intc... > > > - The SPI setup code is quite different. > > > > IIUC that is largely the board specific code. It's just badly placed > with generic and board specific (SPI devices) data being intermixed in > one file... > > > - Entirely different interrupt controller. > > > > - Entirely different dma controller. > > > > No, EDMA is the same, just 32 channels vs DaVinci's 64. There is also > CPPI 4.1 DMAC though -- contained withing MUSB module (in OMAP-L1x > implementation). It requires additional code that doesn't apply to DaVinci. > > > Mark > > -- > > > > WBR, Sergei > > > > _______________________________________________ > Davinci-linux-open-source mailing list > Davinci-linux-open-source@linux.davincidsp.com > http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source _______________________________________________ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
