David Brownell wrote: > 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. >
Maybe kill the enum dma_event_q, and add a function to select a queue if you're picky about which queue it uses. > 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. I can't imagine wanting to request a specific reload slot. I think no parameters would be better. > > 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.) > I think the current audio uses completion interrupts. Our unmerged audio and nand dma drivers use chaining. But I agree that the "write the whole entry" is fine in that case. Troy _______________________________________________ Davinci-linux-open-source mailing list [email protected] http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
