Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752065Ab3FXVHw (ORCPT ); Mon, 24 Jun 2013 17:07:52 -0400 Received: from moutng.kundenserver.de ([212.227.17.8]:50581 "EHLO moutng.kundenserver.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750845Ab3FXVHu (ORCPT ); Mon, 24 Jun 2013 17:07:50 -0400 From: Arnd Bergmann To: Joel A Fernandes Subject: Re: [PATCH v12 05/11] edma: config: Enable config options for EDMA Date: Mon, 24 Jun 2013 23:07:35 +0200 User-Agent: KMail/1.12.2 (Linux/3.8.0-22-generic; KDE/4.3.2; x86_64; ; ) Cc: Sekhar Nori , Joel A Fernandes , Tony Lindgren , Matt Porter , Grant Likely , Rob Herring , Vinod Koul , Mark Brown , Benoit Cousson , 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 References: <1371762407-24544-1-git-send-email-joelagnel@ti.com> <201306242228.23297.arnd@arndb.de> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201306242307.35840.arnd@arndb.de> X-Provags-ID: V02:K0:5ReKlA9Vl6Z5wLLyxxS4hcXqfFe7uoLCM23HgYQTKDi YKldwH6rRnw5XnTfGEw7a4SnuRFNobckj9/ZwWnyYvWEpFRijJ Naylzz2ZzXnmyy/VEWTSo+9h8Px+H7schnsokuFp2BmtLUsweg Hgv9C+Ud0fUv1I8iQmU4LMuxosBwz5Ui8JoZH3Cg1jJGMuPtco 9RemIZQsJVNnGJ/DYUGG6VTIOHYsGPp9tPjD2Y9wpRq3j58cmN FYO1bmubTic2pg+Gcis2KdZHujDdDBfuUbSPltzcp6MzxEBGf4 hAAPOxbyr7QBHLkcge8R68KSfdKU9xAqgBc884ZHSyp2DzI96T 5eEI/6HjftYQpLNib2kA= Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1199 Lines: 31 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. Arnd -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/