David,
I'd like to make a few comments just to be sure that you understand a few
things related to items you removed.
1) EDMA3 resources. There are several different resources that are shared
among all users of EDMA3 (i.e. ARM, DSP, etc.).
A) Channels - Each channel has a hard-coded event associated with it,
e.g. McBSP0 RX, etc.
B) Parameter RAMs - Generally speaking a single channel will utilize
multiple parameter RAM entries. One of them is the "active" entry and others
are utilized as "reload" entries, e.g. you could implement ping pong buffering
with zero CPU overhad in this way. Furthermore, some devices actually allow
you to map the "active" entry to any channel you want, i.e. it is programmable.
C) TCCs (Transfer Completion Codes) - The TCCs are used in a couple
different ways.
a. Interrupts - although there are 64 channels and 64
interrupts they are not necessarily a one-to-one mapping. This is programmable
through the TCC field.
b. Chaining - The completion of one channel can initiate a
transfer on another channel. For example, if you were transferring planar YUV
video data you could set it up such that the completion of the 'Y' transfer
initiates the 'U' transfer which then initiates the 'V' transfer. The channel
you initiate is again specified by the TCC code (same as interrupt).
2) QDMA - the QDMA is intended for memory to memory copies. It can be a
little quicker to kick off one of these transfers.
Note, that I'm not necessarily disagreeing with changes you made (though I
haven't fully reviewed). There is a tradeoff here. If you consolidate some of
these parameters you are shrinking/simplifying the code, but you are also
potentially limiting yourself in what you can do with the EDMA3 peripheral.
I'll let you (and the community) make the final decision as to what is the
right balance, though I wanted to make sure you knew why some of those things
were in the code to begin with.
Brad
> -----Original Message-----
> From: davinci-linux-open-source-boun...@linux.davincidsp.com
> [mailto:davinci-linux-open-source-boun...@linux.davincidsp.com] On Behalf
> Of David Brownell
> Sent: Monday, January 05, 2009 1:40 AM
> To: DaVinci
> Subject: [patch 2.6.28-rc8-davinci1-git+ 0/8] EDMA cleanup/shrinkage
>
> I notice Troy's set of EDMA cleanups came at the beginning
> of December ... another month, another set of EDMA patches? :)
>
>
> These patches began with some frustration when I was trying
> to make sense of the current EDMA code. Basically, there's
> just **NO** excuse for it to be so complex.
>
> Result: object code down by over 55%; source by over 30%.
> (Compared to what's in current GIT.)
>
> - Remove QDMA; it's got a poor and unused interface
> - Remove duplicative IRQ bitmap, and related cleanup
> - Remove needless "ARM-side" hacks and unused fields
> - Remove duplicative "in_use" field; use atomic bitops
> - Misc cleanup after those patches
> - Messaging tweaks, switch most stuff to kerneldoc
> - Remove some unused calls
> - Shrink the object code a bit more
>
> I'm thinking this gets it a lot closer to something that
> could go to mainline...
>
>
> These go on top of the DM355 MMC and DMA patches I sent
> before the holidays. It's been sanity tested with MMC and
> audio, the only two drivers in the GIT tree that use DMA.
>
>
>
> _______________________________________________
> 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
