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

[Fernandes, Joel A]

> -----Original Message-----
> From: Arnd Bergmann [mailto:arnd@xxxxxxxx]
> Sent: Monday, June 24, 2013 4:08 PM
> To: Joel A Fernandes
> Cc: Nori, Sekhar; Fernandes, Joel A; Tony Lindgren; Matt Porter; Grant Likely;
> Rob Herring; Vinod Koul; Mark Brown; Cousson, Benoit; Russell King; Rob
> Landley; Andrew Morton; Jason Kridner; Koen Kooi; Devicetree Discuss; Linux
> OMAP List; Linux ARM Kernel List; Linux DaVinci Kernel List; Linux Kernel
> Mailing List; Linux Documentation List; Linux MMC List; Linux SPI Devel List
> Subject: Re: [PATCH v12 05/11] edma: config: Enable config options for EDMA
> 
> On Monday 24 June 2013, Joel A Fernandes wrote:
> > >> 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.
> >
> > But with DT-only platforms, can you really do that?
> 
> The nice thing about this is that with a DT-only platform, the filter function will
> automatically go away: you have no platform_data, which means that if you
> are using dma_request_slave_channel_compat, you just pass NULL as the filter
> and the filter-data, same as just calling dma_request_slave_channel.
> 
 
[Joel] Ah yes! Thanks for that. Right, edma_filter_fn is not passed explicitly for DT case.

Thanks,
Joel
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/