Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1758155AbbLBNjS (ORCPT ); Wed, 2 Dec 2015 08:39:18 -0500 Received: from mout.kundenserver.de ([217.72.192.75]:59500 "EHLO mout.kundenserver.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932138AbbLBNjQ (ORCPT ); Wed, 2 Dec 2015 08:39:16 -0500 From: Arnd Bergmann To: Peter Ujfalusi Cc: Andy Shevchenko , Vinod Koul , "linux-kernel@vger.kernel.org" , dmaengine , Linux OMAP Mailing List , linux-arm Mailing List , "linux-mmc@vger.kernel.org" , Sekhar Nori , linux-spi Subject: Re: [RFC v02 00/15] dmaengine: New 'universal' API for requesting channel Date: Wed, 02 Dec 2015 14:38:39 +0100 Message-ID: <15116008.0PghG2Imaa@wuerfel> User-Agent: KMail/4.11.5 (Linux/3.16.0-10-generic; KDE/4.11.5; x86_64; ; ) In-Reply-To: <565ECD3F.3070500@ti.com> References: <1448891145-10766-1-git-send-email-peter.ujfalusi@ti.com> <103520159.g0xhtFsXUi@wuerfel> <565ECD3F.3070500@ti.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Provags-ID: V03:K0:rzT66/i4Mdz8KRk4/2nl6Y1U6Ay/KlKP87Ao5VnnMWZpYd3zk4t 4yjn1n2zD20Xj064Ukg3A17CH0Tac2SE5V0GaTGsG48AbWEG50sSABNMyEezJBiX/YL1e9r dfY3mxa4jPtO7YQbL67biqtxE3LADImJolWcawd7iLWYTVjvPh6DBXh8nhuocMeBYq6B6dd C7BSQdfLQZhc7QlUqSApg== X-UI-Out-Filterresults: notjunk:1;V01:K0:wGunUkQYVcc=:GhnzAVAeoTykPCqh7Zlkhs H5qg/gqD1+UqaNY3eom0CspFBITSBiBKg4i3eDYQfOHget8qIL3ueqkvzfgRa9c2LszK23ESr J1xLeYSUFK38lue52O6YDhNUbvUry+dXfUeyoQxx/qHRi+NQNkqDfsGhM9U0BnotHdPbESWAt 36JWcHCTbI18svvTYtOktHD7SiLYhIkbjmrvD8Qi6abkYDCKZEp0N5uNnQLSZgZ5AeVyHgiXZ N6UCbZNeBiyFfPBrIWo+TY2Nt+Pdc9I7Oz9hZEKPw7KjEdZ8doQtgQnJlFYLxwSV4wurVEVvW Qybi1usgxAk5hwvNWIwkSh/QWJlGzTq6uEy2+Woo80haeZubf0RfbnmRSjXimazkmBGYPgK+M dLC5lcPRFV9uzWdAnL8uDFAMdC1YJbqnTZruYU7BaVrsNfpRR+xCcwB1IbVntYjBbK6+uIhzP CYhCiQ+cMxlWAVswxxgTVVJGpuvduI/KT8G3UTZVVxfrL+YXwVZRh1ENQzj7Vl3DsWDryyZvS BPsSzECH8w9fqeNY42u3229a2eULtRN6el1iStZbf1eDbU0+2DmTbf9rYBBQUNnji34GWB4LE smKs57Qv8NHTTykuvWNg5bZ+3c+qBdmCszSwm4Dp+/TuEIMPrtsDJ3f/sADI43w1CdKB81l9P EnuzaOfgQ3A0U7kOcMx3e8WSUcVipuWWuNFb1N1c/FvZjx0fVpr8kEfJ3gfu8yxy2imTgfL8p K01QATh0awtckzAk Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2841 Lines: 51 On Wednesday 02 December 2015 12:51:43 Peter Ujfalusi wrote: > On 12/01/2015 04:24 PM, Arnd Bergmann wrote: > > On Tuesday 01 December 2015 15:45:32 Peter Ujfalusi wrote: > >>>> static struct dma_filter_map da830_edma_map[] = { > >>>> DMA_FILTER_ENTRY("davinci-mcasp.0", "rx", EDMA_CTLR_CHAN(0, 0)), > >>>> DMA_FILTER_ENTRY("davinci-mcasp.0", "tx", EDMA_CTLR_CHAN(0, 1)), > >>>> DMA_FILTER_ENTRY("davinci-mcasp.1", "rx", EDMA_CTLR_CHAN(0, 2)), > >>>> DMA_FILTER_ENTRY("davinci-mcasp.1", "tx", EDMA_CTLR_CHAN(0, 3)), > >>>> DMA_FILTER_ENTRY("davinci-mcasp.2", "rx", EDMA_CTLR_CHAN(0, 4)), > >>>> DMA_FILTER_ENTRY("davinci-mcasp.2", "tx", EDMA_CTLR_CHAN(0, 5)), > >>>> DMA_FILTER_ENTRY("spi_davinci.0", "rx", EDMA_CTLR_CHAN(0, 14)), > >>>> DMA_FILTER_ENTRY("spi_davinci.0", "tx", EDMA_CTLR_CHAN(0, 15)), > >>>> DMA_FILTER_ENTRY("da830-mmc.0", "rx", EDMA_CTLR_CHAN(0, 16)), > >>>> DMA_FILTER_ENTRY("da830-mmc.0", "tx", EDMA_CTLR_CHAN(0, 17)), > >>>> DMA_FILTER_ENTRY("spi_davinci.1", "rx", EDMA_CTLR_CHAN(0, 18)), > >>>> DMA_FILTER_ENTRY("spi_davinci.1", "tx", EDMA_CTLR_CHAN(0, 19)), > >>> > >>> Does this ".2" and so prevent driver to use auto ID for platform devices? > >> > >> Yes, as all the infra around the traditional board files with platform_device > >> creation does. Ideally we could have 'phandle' pointing from this table to the > >> device in question (or other way around), but I'm not aware of anything we can > >> use. > > > > I was thinking that we could use a pointer to the device structure, but > > if you have that, you can also just read the name from it. > > Hrm to have pdev pointer instead of the devname string? In the core we could > get the pdev from the caller's device with to_platform_device(dev) and simply > compare the pointers... > > One of the issue I see (in mach-davinci and mach-omap1/2) is that the pdevs > are scattered around in the c files so gathering the pointers to a place where > we can see them to be able to use it in the dma_filter_map is not going to be > light weight task. > Furthermore we have the omap_hwmod for OMAP2+ which creates the actual pdevs > and resources from the omap_hwmod data structures so getting out the DMA event > numbers there is not going to be easy either... > > I'll hold back the RFC v3 to see if we should switch to pdev pointer or stay > with the devname strings here. Sorry, what I meant to say above is that I had already concluded that using device pointers was a bad idea and we should stay with names. 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/