On Tuesday 06 January 2009, Troy Kisky wrote: > > 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.
That'd make sense: edma_channel_set_tc(), mostly for priority side effects. I'd think init-time configuration of TC characteristics might be wanted too ... e.g. to prevent burst big enough to cuse system-wide problems. > > 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. That'd be for DSP coexistence. I understand the current DSP support for EDMA is a small library that expects static allocation to be done (in the sense of: ARM never touches <these>.) You're right, *other* than that, there's no need to allocate specific slots. Probably best to have some explicit DSP glue hooks to just say to the ARM "hands off <these>!". > > 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. I didn't think so, when I looked. MMC does, but it doesn't actually need them -- just error callbacks. (Which it does not handle correctly.) > Our unmerged audio and nand dma drivers use chaining. > But I agree that the "write the whole entry" is fine in that case. good. We seem to have an approach ready to try ... - Dave _______________________________________________ Davinci-linux-open-source mailing list [email protected] http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
