From: Guennadi Liakhovetski <g.liakhovetski@gmx.de> To: Paul Mundt <lethal@linux-sh.org> Cc: Magnus Damm <magnus.damm@gmail.com>, Vinod Koul <vinod.koul@intel.com>, linux-sh@vger.kernel.org, linux-mmc@vger.kernel.org, Chris Ball <cjb@laptop.org>, linux-kernel@vger.kernel.org Subject: Re: [PATCH 3/4] dma: sh: provide a migration path for slave drivers to stop using .private Date: Thu, 12 Jul 2012 08:34:49 +0000 [thread overview] Message-ID: <Pine.LNX.4.64.1207121025020.19866@axis700.grange> (raw) In-Reply-To: <20120712040018.GB11440@linux-sh.org> Hi Paul, Magnus On Thu, 12 Jul 2012, Paul Mundt wrote: > On Thu, Jul 12, 2012 at 06:55:32AM +0900, Magnus Damm wrote: > > Hi Guennadi, > > > > [CC Paul] > > > > On Thu, Jul 5, 2012 at 1:17 AM, Guennadi Liakhovetski > > <g.liakhovetski@gmx.de> wrote: > > > This patch extends the sh dmaengine driver to support the preferred channel > > > selection and configuration method, instead of using the "private" field > > > from struct dma_chan. We add a standard filter function to be used by > > > slave drivers instead of implementing their own ones, and add support for > > > the DMA_SLAVE_CONFIG control operation, which must accompany the new > > > channel selection method. We still support the legacy .private channel > > > allocation method to cater for a smooth driver migration. > > > > > > Signed-off-by: Guennadi Liakhovetski <g.liakhovetski@gmx.de> > > > --- > > > > Thanks for your efforts on this. Something that caught my eye in this > > patch is this portion: > > > > +bool shdma_chan_filter(struct dma_chan *chan, void *arg); > > > > If we would use this function in our DMA Engine slave drivers (MMCIF, > > SDHI, SCIF, FSI, SIU and so on) then wouldn't we add a strict > > dependency on this symbol provided by this particular DMA Engine > > driver implementation for the DMAC hardware (that your patch > > modifies)? This dependency is nothing new. Now all those drivers depend on shdma too, though, in a softer way - by using struct sh_dmae_slave. That struct is defined in include/linux/sh_dma.h and so we _could_ reuse it between several sh(-mobile) DMAC variants, but IIUC, there's currently no truly reliable way to make DMA slave drive drivers completely generic. And this will remain this way as long as DMA channel filtering is relying on an opaque argument, specific to each DMAC driver. Russell has shown in a mail, how this hard dependency can be sort of eliminated by passing a string as a filter parameter. But then again - this _only_ works with drivers, that use this method. Similarly any non hardware-specific type could be used, e.g., an integer slave ID. Moreover, I've been told explicitly, that exporting filter functions from respective DMAC drivers _is_ the correct way to use the current API... > > And what do we do if we want to use the same DMA Engine slave driver > > with a different DMA Engine driver implementation? > > > > From my point of view, there must be some better way to not have such > > tight dependencies between the DMA Engine slave consumer and the DMA > > Engine driver. Not sure what that looks like though. This symbol > > dependency is pretty far from great IMO. > > > I vaguely recall this coming up before, and it wasn't acceptable then > either. > > We will by no means be adding driver-specific hooks in to other drivers > that really couldn't care less what the underlying DMA engine driving > them is. > > We already have CPUs with different DMA engines that can be used by the > same drivers. As I said the last time, this needs to be fixed in the > dmaengine framework, period. Sure, that's what my DMA mux-driver idea [1] is aiming to achieve. Thanks Guennadi [1] http://article.gmane.org/gmane.linux.ports.arm.omap/80357 --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/
WARNING: multiple messages have this Message-ID (diff)
From: Guennadi Liakhovetski <g.liakhovetski@gmx.de> To: Paul Mundt <lethal@linux-sh.org> Cc: Magnus Damm <magnus.damm@gmail.com>, Vinod Koul <vinod.koul@intel.com>, linux-sh@vger.kernel.org, linux-mmc@vger.kernel.org, Chris Ball <cjb@laptop.org>, linux-kernel@vger.kernel.org Subject: Re: [PATCH 3/4] dma: sh: provide a migration path for slave drivers to stop using .private Date: Thu, 12 Jul 2012 10:34:49 +0200 (CEST) [thread overview] Message-ID: <Pine.LNX.4.64.1207121025020.19866@axis700.grange> (raw) In-Reply-To: <20120712040018.GB11440@linux-sh.org> Hi Paul, Magnus On Thu, 12 Jul 2012, Paul Mundt wrote: > On Thu, Jul 12, 2012 at 06:55:32AM +0900, Magnus Damm wrote: > > Hi Guennadi, > > > > [CC Paul] > > > > On Thu, Jul 5, 2012 at 1:17 AM, Guennadi Liakhovetski > > <g.liakhovetski@gmx.de> wrote: > > > This patch extends the sh dmaengine driver to support the preferred channel > > > selection and configuration method, instead of using the "private" field > > > from struct dma_chan. We add a standard filter function to be used by > > > slave drivers instead of implementing their own ones, and add support for > > > the DMA_SLAVE_CONFIG control operation, which must accompany the new > > > channel selection method. We still support the legacy .private channel > > > allocation method to cater for a smooth driver migration. > > > > > > Signed-off-by: Guennadi Liakhovetski <g.liakhovetski@gmx.de> > > > --- > > > > Thanks for your efforts on this. Something that caught my eye in this > > patch is this portion: > > > > +bool shdma_chan_filter(struct dma_chan *chan, void *arg); > > > > If we would use this function in our DMA Engine slave drivers (MMCIF, > > SDHI, SCIF, FSI, SIU and so on) then wouldn't we add a strict > > dependency on this symbol provided by this particular DMA Engine > > driver implementation for the DMAC hardware (that your patch > > modifies)? This dependency is nothing new. Now all those drivers depend on shdma too, though, in a softer way - by using struct sh_dmae_slave. That struct is defined in include/linux/sh_dma.h and so we _could_ reuse it between several sh(-mobile) DMAC variants, but IIUC, there's currently no truly reliable way to make DMA slave drive drivers completely generic. And this will remain this way as long as DMA channel filtering is relying on an opaque argument, specific to each DMAC driver. Russell has shown in a mail, how this hard dependency can be sort of eliminated by passing a string as a filter parameter. But then again - this _only_ works with drivers, that use this method. Similarly any non hardware-specific type could be used, e.g., an integer slave ID. Moreover, I've been told explicitly, that exporting filter functions from respective DMAC drivers _is_ the correct way to use the current API... > > And what do we do if we want to use the same DMA Engine slave driver > > with a different DMA Engine driver implementation? > > > > From my point of view, there must be some better way to not have such > > tight dependencies between the DMA Engine slave consumer and the DMA > > Engine driver. Not sure what that looks like though. This symbol > > dependency is pretty far from great IMO. > > > I vaguely recall this coming up before, and it wasn't acceptable then > either. > > We will by no means be adding driver-specific hooks in to other drivers > that really couldn't care less what the underlying DMA engine driving > them is. > > We already have CPUs with different DMA engines that can be used by the > same drivers. As I said the last time, this needs to be fixed in the > dmaengine framework, period. Sure, that's what my DMA mux-driver idea [1] is aiming to achieve. Thanks Guennadi [1] http://article.gmane.org/gmane.linux.ports.arm.omap/80357 --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/
next prev parent reply other threads:[~2012-07-12 8:34 UTC|newest] Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top 2012-07-04 16:17 [PATCH 0/4] dma: sh: stop using .private Guennadi Liakhovetski 2012-07-04 16:17 ` Guennadi Liakhovetski 2012-07-04 16:17 ` [PATCH 1/4] dmaengine: shdma: prepare to stop using struct dma_chan::private Guennadi Liakhovetski 2012-07-04 16:17 ` Guennadi Liakhovetski 2012-07-04 16:17 ` [PATCH 2/4] dma: sh: use an integer slave ID to improve API compatibility Guennadi Liakhovetski 2012-07-04 16:17 ` Guennadi Liakhovetski 2012-07-04 16:17 ` [PATCH 3/4] dma: sh: provide a migration path for slave drivers to stop using .private Guennadi Liakhovetski 2012-07-04 16:17 ` Guennadi Liakhovetski 2012-07-11 21:55 ` Magnus Damm 2012-07-11 21:55 ` Magnus Damm 2012-07-12 4:00 ` Paul Mundt 2012-07-12 4:00 ` Paul Mundt 2012-07-12 8:34 ` Guennadi Liakhovetski [this message] 2012-07-12 8:34 ` Guennadi Liakhovetski 2012-07-04 16:17 ` [PATCH 4/4] mmc: sh_mmcif: switch to the new DMA channel allocation and configuration Guennadi Liakhovetski 2012-07-04 16:17 ` Guennadi Liakhovetski
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=Pine.LNX.4.64.1207121025020.19866@axis700.grange \ --to=g.liakhovetski@gmx.de \ --cc=cjb@laptop.org \ --cc=lethal@linux-sh.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-mmc@vger.kernel.org \ --cc=linux-sh@vger.kernel.org \ --cc=magnus.damm@gmail.com \ --cc=vinod.koul@intel.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.