Hello. Kevin Hilman 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.
Kevin
WBR, Sergei _______________________________________________ Davinci-linux-open-source mailing list [email protected] http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
