Hello, I wrote:
Some of the comments about my earlier EDMA patches touched on
issues
in that programming interface, like:
- The single call to allocate DMA resources is overly complex.
- Its programming model doesn't match the hardware well: talking
about master vs. slave, not channels and parameter RAM; confusing
those two resource types (especially when allocating); etc.
- Since the calls used a "davinci_" prefix, they wouldn't be very
appropriate for the DMA in the OMAP-L137 chip.
We were going to move the generic part of
arch/arm/mach-davinci/dma.c (alomg with other common code b/w so
called OMAP-L1x and DaVinci) to arch/arm/plat-davinci/ but the
rename
seems reasonable anyway.
I keep hearing things like this, but have not yet seen any
patches, or
technical arguments for doing so.
The technical argument is simple: sharing the code for two similar
platforms, the EDMA code in particular.
The code already is shared.
How? You're not supposed to looks for the shared code in other
mach-*/ dirs, are you?
I'm talking about DaVinci git tree here, not TI/MV trees. There is
no plat-davinci, only a mach-davinci.
The current DMA code is shared across the various devices currently
supported in DaVinci git.
The point I'm trying to make is that I still do not agree with the
need to create a plat-davinci for "common" code. The reasons I've
heard so far have not been convincing.
So, you want e.g. EDMA code duplicated, right?
Um, no. You are the one who seems to be implying a new mach-*
directory for a new platform which would require duplication.
The way I currently see things is a single mach-davinci with support
for dm644x, dm355, dm646x, omapl1x7, etc.
MV too have clinged to the idea of "parasitising" on the DaVinci code
till the last possibility but then finally ditched it.
Until technical reasons for the creation of a new mach-* directory are
proposed and discussed on the list, that's the way I plan to continue
things.
If completely different interrupt controller doesn't sound as
sufficient technical reason, I think I won't be wasting any more time on
this argument. Hopefully others will be able to provide better
arguments. I've been tired enough by the internal discussion already.
Just one last argument, to be as technical as possible: entry-macro.S will
need either #ifdef'ery (thus defying your presumed idea of having the single
binary to boot on all DaVinci like platfroms) or some kind of runtime check
(at one point we did implement that) in order to function on both platfroms.
Are you sure we need all that?
Kevin
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
