public inbox for linux-arm-kernel@lists.infradead.org
 help / color / mirror / Atom feed
From: g.liakhovetski@gmx.de (Guennadi Liakhovetski)
To: linux-arm-kernel@lists.infradead.org
Subject: DMA channels (was Re: [PATCH 2/2] ARM: shmobile: sdhi: remove DMA hardware dependencies)
Date: Wed, 26 Jun 2013 12:10:29 +0200 (CEST)	[thread overview]
Message-ID: <Pine.LNX.4.64.1306261024280.8856@axis700.grange> (raw)
In-Reply-To: <201306192351.50804.arnd@arndb.de>

Hi Arnd

I think it would be good to come to a certain conclusion regarding the 
current dmaengine channel selection and configuration API and its possibly 
desired amendments.

On Wed, 19 Jun 2013, Arnd Bergmann wrote:

[snip]

> The problem with this is that on a lot of dma engines you have one channel
> per slave (in particular with virt-dma.c), so the slave-id has to be
> part of the filter data. Since the slave driver cannot know what kind
> of DMA engine it is connected to, it has to assume that the slave-id
> is inherent to the channel an cannot change.
> Also, the DT binding is built around the idea that you identify the
> channel or request line with the specifier in whichever form the
> dma engine requires, and there is no general way for the slave driver
> to find out a slave id. Setting it with dma_slave_config is inherently
> nonportable, and we should stop doing that.

Don't you think, that this situation, where without DT a filter function 
has to be used, which has to be provided by the platform and is just a 
kind of a platform callback; and with DT channels are selected and 
configured by a reference to suitable DMAC instances and a hardware- 
specific data set is suboptimal? Wouldn't it be better to unify it?

If yes, the unification would go in the direction of DT compatibility, 
i.e. dropping filter functions and just directly referencing required 
DMACs and using DMAC-specific configuration? Wouldn't a channel requesting 
API, similar to that for requesting clocks, pinmux settings be a better 
option, than the current filtering procedure? Something like

	dma_request_slave_channel(dev, "tx", "dmac0", config);

in a simple case of just one suitable DMAC, or a NULL if DMACs should be 
able to figure out themselves, whether they can serve this slave, or 
something like "dmamux0" if there is a multiplexer, for which a driver has 
to be available, and in which case "config" would be that multiplexer 
driver's configuration?

Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/

  reply	other threads:[~2013-06-26 10:10 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-05-31 13:56 [PATCH 1/2] ARM: shmobile: sdhi: pass DMA filter from platform code Arnd Bergmann
2013-05-31 13:56 ` [PATCH 2/2] ARM: shmobile: sdhi: remove DMA hardware dependencies Arnd Bergmann
2013-05-31 13:58   ` Arnd Bergmann
2013-06-07 10:22   ` Guennadi Liakhovetski
2013-06-07 12:59     ` Arnd Bergmann
2013-06-07 13:12       ` Guennadi Liakhovetski
2013-06-07 14:53         ` Arnd Bergmann
2013-06-07 15:32           ` Guennadi Liakhovetski
2013-06-07 16:06             ` Arnd Bergmann
2013-06-19 19:51               ` Guennadi Liakhovetski
2013-06-19 21:51                 ` Arnd Bergmann
2013-06-26 10:10                   ` Guennadi Liakhovetski [this message]
2013-06-26 14:35                     ` DMA channels (was Re: [PATCH 2/2] ARM: shmobile: sdhi: remove DMA hardware dependencies) Arnd Bergmann
2013-06-26 15:48                       ` Vinod Koul
2013-05-31 14:52 ` [PATCH 1/2] ARM: shmobile: sdhi: pass DMA filter from platform code Guennadi Liakhovetski
2013-05-31 15:11   ` Arnd Bergmann
2013-05-31 15:30     ` Guennadi Liakhovetski
2013-05-31 16:02       ` Arnd Bergmann
2013-06-05  8:28         ` Guennadi Liakhovetski
2013-06-07 10:25 ` Guennadi Liakhovetski
2013-06-07 12:52   ` Arnd Bergmann
2013-06-07 13:01     ` 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.1306261024280.8856@axis700.grange \
    --to=g.liakhovetski@gmx.de \
    --cc=linux-arm-kernel@lists.infradead.org \
    /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: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox