[PATCH v12 05/11] edma: config: Enable config options for EDMA

Arnd Bergmann arnd at arndb.de
Tue Jun 25 06:28:23 EST 2013


On Saturday 22 June 2013, Joel A Fernandes wrote:
> 
> >> > config TI_EDMA
> >> >         tristate "TI EDMA support"
> >> >         default m if 'ARCH_DAVINCI || ARCH_OMAP1 || ARCH_OMAP2
> >> >         select DMA_ENGINE
> >> >         select DMA_VIRTUAL_CHANNELS
> >>
> >>
> >> MMC depends on EDMA specially on AM33xx there's no PIO mode AFAIK. The
> >> 'm' option will require some initramfs to load the module when needing
> >> to MMC boot, I suggest lets leave it as y.
> >>
> >
> > Ah, right: you still export a filter function from the edma driver
> > and use it in slave drivers:
> >
> > drivers/mmc/host/davinci_mmc.c:         dma_request_slave_channel_compat(mask, edma_filter_fn,
> > drivers/mmc/host/davinci_mmc.c:         dma_request_slave_channel_compat(mask, edma_filter_fn,
> > drivers/spi/spi-davinci.c:      dspi->dma_rx = dma_request_channel(mask, edma_filter_fn,
> > drivers/spi/spi-davinci.c:      dspi->dma_tx = dma_request_channel(mask, edma_filter_fn,
> >
> > As long as this is the case, you have to be careful with the dependencies
> > to make sure that davinci_mmc and spi-davinci either depend on TI_EDMA, or
> > edma_filter_fn gets defined to NULL when you are building for a DT-only platform.
> 
> Yes sure, right now they are defined  as follows in include/linux/edma.h:
> 
> #if defined(CONFIG_TI_EDMA) || defined(CONFIG_TI_EDMA_MODULE)
> bool edma_filter_fn(struct dma_chan *, void *);
> #else
> static inline bool edma_filter_fn(struct dma_chan *chan, void *param)
> {
> return false;
> }
> #endif

It's best to just define the filter function in the platform
code and pass a pointer to it through platform data. The way you do
it above makes the slave drivers inherently nonportable.

	Arnd


More information about the devicetree-discuss mailing list