All of lore.kernel.org
 help / color / mirror / Atom feed
From: Vinod Koul <vinod.koul@intel.com>
To: "Niklas Söderlund" <niklas.soderlund+renesas@ragnatech.se>
Cc: hch@infradead.org, linux-renesas-soc@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org, dmaengine@vger.kernel.org,
	iommu@lists.linux-foundation.org, dan.j.williams@intel.com,
	robin.murphy@arm.com, laurent.pinchart@ideasonboard.com,
	linus.walleij@linaro.org, arnd@arndb.de
Subject: Re: [PATCHv7 0/6] dmaengine: rcar-dmac: add iommu support for slave transfers
Date: Wed, 1 Jun 2016 23:36:11 +0530	[thread overview]
Message-ID: <20160601180610.GV16910@localhost> (raw)
In-Reply-To: <1464794549-6601-1-git-send-email-niklas.soderlund+renesas@ragnatech.se>

On Wed, Jun 01, 2016 at 05:22:23PM +0200, Niklas Söderlund wrote:
> Hi,
> 
> [In this v7 series I have tried to address the questions raised by Christoph 
> Hellwig and I hope it can awnser your concernes regarding dma-debug.]
> 
> This series tries to solve the problem with DMA with device registers
> (MMIO registers) that are behind an IOMMU for the rcar-dmac driver. A
> recent patch '9575632 (dmaengine: make slave address physical)'
> clarifies that DMA slave address provided by clients is the physical
> address. This puts the task of mapping the DMA slave address from a
> phys_addr_t to a dma_addr_t on the DMA engine.
> 
> Without an IOMMU this is easy since the phys_addr_t and dma_addr_t are
> the same and no special care is needed. However if you have a IOMMU you
> need to map the DMA slave phys_addr_t to a dma_addr_t using something
> like this.
> 
> This series is based on top of v4.7-rc1.

The dmanegine bits looks okay to me. Btw how is the merge planned for this?
Do you wnat this to be merged thru dmaengine tree or something else?

-- 
~Vinod

WARNING: multiple messages have this Message-ID (diff)
From: Vinod Koul <vinod.koul@intel.com>
To: "Niklas Söderlund" <niklas.soderlund+renesas@ragnatech.se>
Cc: hch@infradead.org, linux-renesas-soc@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org, dmaengine@vger.kernel.org,
	iommu@lists.linux-foundation.org, dan.j.williams@intel.com,
	robin.murphy@arm.com, laurent.pinchart@ideasonboard.com,
	linus.walleij@linaro.org, arnd@arndb.de
Subject: Re: [PATCHv7 0/6] dmaengine: rcar-dmac: add iommu support for slave transfers
Date: Wed, 1 Jun 2016 23:36:11 +0530	[thread overview]
Message-ID: <20160601180610.GV16910@localhost> (raw)
In-Reply-To: <1464794549-6601-1-git-send-email-niklas.soderlund+renesas@ragnatech.se>

On Wed, Jun 01, 2016 at 05:22:23PM +0200, Niklas S�derlund wrote:
> Hi,
> 
> [In this v7 series I have tried to address the questions raised by Christoph 
> Hellwig and I hope it can awnser your concernes regarding dma-debug.]
> 
> This series tries to solve the problem with DMA with device registers
> (MMIO registers) that are behind an IOMMU for the rcar-dmac driver. A
> recent patch '9575632 (dmaengine: make slave address physical)'
> clarifies that DMA slave address provided by clients is the physical
> address. This puts the task of mapping the DMA slave address from a
> phys_addr_t to a dma_addr_t on the DMA engine.
> 
> Without an IOMMU this is easy since the phys_addr_t and dma_addr_t are
> the same and no special care is needed. However if you have a IOMMU you
> need to map the DMA slave phys_addr_t to a dma_addr_t using something
> like this.
> 
> This series is based on top of v4.7-rc1.

The dmanegine bits looks okay to me. Btw how is the merge planned for this?
Do you wnat this to be merged thru dmaengine tree or something else?

-- 
~Vinod

WARNING: multiple messages have this Message-ID (diff)
From: vinod.koul@intel.com (Vinod Koul)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCHv7 0/6] dmaengine: rcar-dmac: add iommu support for slave transfers
Date: Wed, 1 Jun 2016 23:36:11 +0530	[thread overview]
Message-ID: <20160601180610.GV16910@localhost> (raw)
In-Reply-To: <1464794549-6601-1-git-send-email-niklas.soderlund+renesas@ragnatech.se>

On Wed, Jun 01, 2016 at 05:22:23PM +0200, Niklas S?derlund wrote:
> Hi,
> 
> [In this v7 series I have tried to address the questions raised by Christoph 
> Hellwig and I hope it can awnser your concernes regarding dma-debug.]
> 
> This series tries to solve the problem with DMA with device registers
> (MMIO registers) that are behind an IOMMU for the rcar-dmac driver. A
> recent patch '9575632 (dmaengine: make slave address physical)'
> clarifies that DMA slave address provided by clients is the physical
> address. This puts the task of mapping the DMA slave address from a
> phys_addr_t to a dma_addr_t on the DMA engine.
> 
> Without an IOMMU this is easy since the phys_addr_t and dma_addr_t are
> the same and no special care is needed. However if you have a IOMMU you
> need to map the DMA slave phys_addr_t to a dma_addr_t using something
> like this.
> 
> This series is based on top of v4.7-rc1.

The dmanegine bits looks okay to me. Btw how is the merge planned for this?
Do you wnat this to be merged thru dmaengine tree or something else?

-- 
~Vinod

  parent reply	other threads:[~2016-06-01 18:06 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-06-01 15:22 [PATCHv7 0/6] dmaengine: rcar-dmac: add iommu support for slave transfers Niklas Söderlund
2016-06-01 15:22 ` Niklas Söderlund
2016-06-01 15:22 ` [PATCHv7 1/6] dma-mapping: add {map,unmap}_resource to dma_map_ops Niklas Söderlund
2016-06-01 15:22   ` Niklas Söderlund
2016-06-01 15:22 ` [PATCHv7 2/6] dma-debug: add support for resource mappings Niklas Söderlund
2016-06-01 15:22   ` Niklas Söderlund
2016-06-01 15:22 ` [PATCHv7 3/6] dma-mapping: add dma_{map,unmap}_resource Niklas Söderlund
2016-06-01 15:22   ` Niklas Söderlund
2016-06-01 15:22 ` [PATCHv7 4/6] arm: dma-mapping: add {map,unmap}_resource for iommu ops Niklas Söderlund
2016-06-01 15:22   ` [PATCHv7 4/6] arm: dma-mapping: add {map, unmap}_resource " Niklas Söderlund
2016-06-01 16:16   ` Russell King - ARM Linux
2016-06-01 16:16     ` Russell King - ARM Linux
2016-06-01 16:16     ` Russell King - ARM Linux
     [not found]     ` <20160601161605.GA19428-l+eeeJia6m9vn6HldHNs0ANdhmdF6hFW@public.gmane.org>
2016-06-02 12:50       ` Niklas Söderlund
2016-06-02 12:50         ` Niklas Söderlund
2016-06-02 12:50         ` Niklas Söderlund
2016-06-01 15:22 ` [PATCHv7 5/6] dmaengine: rcar-dmac: group slave configuration Niklas Söderlund
2016-06-01 15:22   ` Niklas Söderlund
2016-06-01 15:22 ` [PATCHv7 6/6] dmaengine: rcar-dmac: add iommu support for slave transfers Niklas Söderlund
2016-06-01 15:22   ` Niklas Söderlund
2016-06-01 18:06 ` Vinod Koul [this message]
2016-06-01 18:06   ` [PATCHv7 0/6] " Vinod Koul
2016-06-01 18:06   ` Vinod Koul
2016-06-02 12:58   ` Niklas Söderlund
2016-06-02 12:58     ` Niklas Söderlund
2016-06-02 12:58     ` Niklas Söderlund
2016-06-02 16:47     ` Vinod Koul
2016-06-02 16:47       ` Vinod Koul
2016-06-02 16:47       ` Vinod Koul

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=20160601180610.GV16910@localhost \
    --to=vinod.koul@intel.com \
    --cc=arnd@arndb.de \
    --cc=dan.j.williams@intel.com \
    --cc=dmaengine@vger.kernel.org \
    --cc=hch@infradead.org \
    --cc=iommu@lists.linux-foundation.org \
    --cc=laurent.pinchart@ideasonboard.com \
    --cc=linus.walleij@linaro.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-renesas-soc@vger.kernel.org \
    --cc=niklas.soderlund+renesas@ragnatech.se \
    --cc=robin.murphy@arm.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: 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.