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.
A new interrupt controller can simply be added with a new 'cp_intc.c'
in current mach-davinci. IIRC, this is how it was done in the initial
port.
Have you read my prior mails? It's not even ARM specific, let alone not
OMAP-L1x specific. I've moved it into arch/arm/common/ for now in the internal
tree...
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?
IIRC, Steve Chen found a simple way to do this by creating a virtual
mapping that maps both INTC areas to the same range, and having a
check in entry-macro.S.
We've have ditched that horror. This code is supposed to be fast and
simple, not peeking registers in order to (hopefully) determine what
controller it should use.
This idea can be extended such that if the kernel is not built for
multiple devices, the optimized, chip specific version can be used.
As promised, I'm stopping the discussion at this point...
Kevin
WBR, Sergei
_______________________________________________
Davinci-linux-open-source mailing list
[email protected]
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
