All of lore.kernel.org
 help / color / mirror / Atom feed
From: Arnd Bergmann <arnd@arndb.de>
To: linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH 2/2] ARM: shmobile: sdhi: remove DMA hardware dependencies
Date: Fri, 07 Jun 2013 14:53:21 +0000	[thread overview]
Message-ID: <201306071653.21668.arnd@arndb.de> (raw)
In-Reply-To: <Pine.LNX.4.64.1306071507060.11277@axis700.grange>

On Friday 07 June 2013, Guennadi Liakhovetski wrote:
> > I think that is a flaw in the dmaengine driver. I don't actually know how
> > any dma-engine driver could use dmaengine_slave_config to pick the request
> > line, since that is something the driver should not know at the time
> > it calls dmaengine_slave_config().
> > 
> > It's probably best to change the shdma driver to just ignore the slave_id
> > value in slave_config, like most other drivers to.
> 
> This is how shdma driver used to work. We used to pass the slave ID (DMA 
> request line ID) to shdma from clients from the filter. This was 
> considered bad and we were asked to switch to using 
> dmaengine_slave_config(), which is the current preferred API, IIUC.

I think you misunderstood the requirement. All other configuration,
i.e. slave port address, burst size, bus width, really should be
configured using dmaengine_slave_config, since this is data that
is known by the /driver/, independent of the DMA engine in use and
unknown to the platform. The request line number is something that
the driver cannot know, since it is a property of the DMA engine.

> > I don't see how that
> > could possibly work when used from a portable slave driver.
> 
> A DMA slave ID (DMA request line) is considered to be a portable 
> parameter. I.e. on every platform your DMA slave has to request a DMA 
> request line to the DMAC and that line can be coded with an int. That's 
> the current assumption, I think.

In a lot of cases you actually need more than one number here, e.g.
to configure which master port of the DMA engine is being used.
That's why the dmaengine DT binding needs a variable #dma-cells
property that is specific to the dma engine being used.

	Arnd

WARNING: multiple messages have this Message-ID (diff)
From: arnd@arndb.de (Arnd Bergmann)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 2/2] ARM: shmobile: sdhi: remove DMA hardware dependencies
Date: Fri, 7 Jun 2013 16:53:21 +0200	[thread overview]
Message-ID: <201306071653.21668.arnd@arndb.de> (raw)
In-Reply-To: <Pine.LNX.4.64.1306071507060.11277@axis700.grange>

On Friday 07 June 2013, Guennadi Liakhovetski wrote:
> > I think that is a flaw in the dmaengine driver. I don't actually know how
> > any dma-engine driver could use dmaengine_slave_config to pick the request
> > line, since that is something the driver should not know at the time
> > it calls dmaengine_slave_config().
> > 
> > It's probably best to change the shdma driver to just ignore the slave_id
> > value in slave_config, like most other drivers to.
> 
> This is how shdma driver used to work. We used to pass the slave ID (DMA 
> request line ID) to shdma from clients from the filter. This was 
> considered bad and we were asked to switch to using 
> dmaengine_slave_config(), which is the current preferred API, IIUC.

I think you misunderstood the requirement. All other configuration,
i.e. slave port address, burst size, bus width, really should be
configured using dmaengine_slave_config, since this is data that
is known by the /driver/, independent of the DMA engine in use and
unknown to the platform. The request line number is something that
the driver cannot know, since it is a property of the DMA engine.

> > I don't see how that
> > could possibly work when used from a portable slave driver.
> 
> A DMA slave ID (DMA request line) is considered to be a portable 
> parameter. I.e. on every platform your DMA slave has to request a DMA 
> request line to the DMAC and that line can be coded with an int. That's 
> the current assumption, I think.

In a lot of cases you actually need more than one number here, e.g.
to configure which master port of the DMA engine is being used.
That's why the dmaengine DT binding needs a variable #dma-cells
property that is specific to the dma engine being used.

	Arnd

  reply	other threads:[~2013-06-07 14:53 UTC|newest]

Thread overview: 44+ 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 ` Arnd Bergmann
2013-05-31 13:56 ` [PATCH 2/2] ARM: shmobile: sdhi: remove DMA hardware dependencies Arnd Bergmann
2013-05-31 13:56   ` Arnd Bergmann
2013-05-31 13:58   ` Arnd Bergmann
2013-05-31 13:58     ` Arnd Bergmann
2013-06-07 10:22   ` Guennadi Liakhovetski
2013-06-07 10:22     ` Guennadi Liakhovetski
2013-06-07 12:59     ` Arnd Bergmann
2013-06-07 12:59       ` Arnd Bergmann
2013-06-07 13:12       ` Guennadi Liakhovetski
2013-06-07 13:12         ` Guennadi Liakhovetski
2013-06-07 14:53         ` Arnd Bergmann [this message]
2013-06-07 14:53           ` Arnd Bergmann
2013-06-07 15:32           ` Guennadi Liakhovetski
2013-06-07 15:32             ` Guennadi Liakhovetski
2013-06-07 16:06             ` Arnd Bergmann
2013-06-07 16:06               ` Arnd Bergmann
2013-06-19 19:51               ` Guennadi Liakhovetski
2013-06-19 19:51                 ` Guennadi Liakhovetski
2013-06-19 21:51                 ` Arnd Bergmann
2013-06-19 21:51                   ` Arnd Bergmann
2013-06-26 10:10                   ` DMA channels (was Re: [PATCH 2/2] ARM: shmobile: sdhi: remove DMA hardware dependencies) Guennadi Liakhovetski
2013-06-26 10:10                     ` Guennadi Liakhovetski
2013-06-26 14:35                     ` Arnd Bergmann
2013-06-26 14:35                       ` Arnd Bergmann
2013-06-26 15:48                       ` Vinod Koul
2013-06-26 16:00                         ` Vinod Koul
2013-05-31 14:52 ` [PATCH 1/2] ARM: shmobile: sdhi: pass DMA filter from platform code Guennadi Liakhovetski
2013-05-31 14:52   ` Guennadi Liakhovetski
2013-05-31 15:11   ` Arnd Bergmann
2013-05-31 15:11     ` Arnd Bergmann
2013-05-31 15:30     ` Guennadi Liakhovetski
2013-05-31 15:30       ` Guennadi Liakhovetski
2013-05-31 16:02       ` Arnd Bergmann
2013-05-31 16:02         ` Arnd Bergmann
2013-06-05  8:28         ` Guennadi Liakhovetski
2013-06-05  8:28           ` Guennadi Liakhovetski
2013-06-07 10:25 ` Guennadi Liakhovetski
2013-06-07 10:25   ` Guennadi Liakhovetski
2013-06-07 12:52   ` Arnd Bergmann
2013-06-07 12:52     ` Arnd Bergmann
2013-06-07 13:01     ` Guennadi Liakhovetski
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=201306071653.21668.arnd@arndb.de \
    --to=arnd@arndb.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 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.