From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755115Ab3AKUNb (ORCPT ); Fri, 11 Jan 2013 15:13:31 -0500 Received: from moutng.kundenserver.de ([212.227.126.187]:62546 "EHLO moutng.kundenserver.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753467Ab3AKUN0 (ORCPT ); Fri, 11 Jan 2013 15:13:26 -0500 From: Arnd Bergmann To: Matt Porter Subject: Re: [PATCH v4 00/14] DMA Engine support for AM33XX Date: Fri, 11 Jan 2013 20:12:45 +0000 User-Agent: KMail/1.12.2 (Linux/3.7.0-7-generic; KDE/4.3.2; x86_64; ; ) Cc: Tony Lindgren , Sekhar Nori , Grant Likely , Mark Brown , Benoit Cousson , Russell King , Vinod Koul , Rob Landley , Chris Ball , 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 , Dan Williams , Rob Herring References: <1357883330-5364-1-git-send-email-mporter@ti.com> <201301111140.41584.arnd@arndb.de> <20130111183349.GA14660@beef> In-Reply-To: <20130111183349.GA14660@beef> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201301112012.45981.arnd@arndb.de> X-Provags-ID: V02:K0:HSKsK2T889o+Vm9S00NCQ7mmaDU9G5fAV0ZqnFheqOr 8GnaRe4L2UmQBD4LuPxYDHtTy1YULRxtYK11cn4WxD9VvSJQNu JC1uqEF+LsCT9nHqo2HW0gVEU/ltBqBq4SAF3boaFAF0ApZ8o8 Dri7CRA3F4U3uxDwuvOvPJT7b1sUVwun4kSS3XkbCxnEYZ59Gx WfuccCNbVPFh3yfeP/chRuGVqR7E79WgujjCj30t5lTD9A0Fd6 4nEJPDYCxMp+eqz80XjIv1dMQz8WBvRSicF5UGLuBsbiZnMEou Qv4ncxjhx5THmpTOEVj17V/20bOdhduuQg+ib04TC/g3fx8EJ2 SYTPbWkNc8SNHUpGda40= Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Friday 11 January 2013, Matt Porter wrote: > We have tightly coupled the link-time dependency for > omap_dma_filter_fn by going down the path of using > dma_request_slave_channel_compat() as Tony suggested to avoid extra > ifdefry. > > That dependency will go away naturally if all the "legacy" OMAP platforms > were required to only boot from DT...just as a newly added SoCs are. > > Are you suggesting unwinding the _compat() approach? No, I was thinking we could define omap_dma_filter_fn to NULL for the DT-only case. Arnd