On Tuesday 06 January 2009, David Brownell wrote:
> After Kevin gets back and merges most of the patches that
> have been submitted (or NAKs them for whatever reason),
> it'll be time to think about fixing this deeper goofage.
Note that the terminology issue fits with Troy's comment
about davinci_request_dma() being way too complex:
int davinci_request_dma(int dev_id, const char *dev_name,
void (*callback)(int lch, unsigned short ch_status, void *data),
void *data, int *lch, int *tcc, enum dma_event_q);
Might better be something like
int edma_request_channel(int id,
void (*callback)(unsigned id, enum whatsit status, void *data),
void *data, enum dma_event_q);
... allocates channel and its PaRAM slot, returning the
channel ID or negative errno. Negative "id" means to choose
some channel not mapped to a hardware event.
int edma_request_p_ram(int slot);
... allocates PaRAM slot not bound to a channel, returning
that or negative errno. Negative "slot" (typical case)
means to just choose one.
Then if a driver wants to use TCCs to get DMA completion IRQs or
use event chaining, they can write the PaRAM "opt" field using
the "write the whole PaRAM entry" calls, or some new PaRAM update
calls could be added. (None of the current drivers need to use
completion IRQs, or try to use chaining.)
Similarly, the DMA start calls should have two variants: one to
just enable hardware triggering (failing if the channel doesn't
support it), the other doing a software trigger on the channel.
- Dave
_______________________________________________
Davinci-linux-open-source mailing list
[email protected]
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
