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...
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
[email protected]
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
