All of lore.kernel.org
 help / color / mirror / Atom feed
From: Vinod Koul <vinod.koul@intel.com>
To: 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: Thu, 2 Jun 2016 22:17:11 +0530	[thread overview]
Message-ID: <20160602164711.GS16910@localhost> (raw)
In-Reply-To: <20160602125807.GN8307@bigcity.dyn.berto.se>

On Thu, Jun 02, 2016 at 02:58:07PM +0200, Niklas Söderlund wrote:
> Hi Vinod,
> 
> On 2016-06-01 23:36:11 +0530, Vinod Koul wrote:
> > 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?
> 
> Yes, since the arm specific patch are depending on other parts of the 
> series I was hoping to be able to get Russells Ack on it and then try to 
> get it all in through the dmaengine tree.

Sounds good to me..

> If you see a better way I'm happy to do it that way, let me know what 
> you think. I hold off v8 that adresses the issues Russell brought up a 
> few days untill I know what you think is best.

-- 
~Vinod

WARNING: multiple messages have this Message-ID (diff)
From: Vinod Koul <vinod.koul@intel.com>
To: 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: Thu, 2 Jun 2016 22:17:11 +0530	[thread overview]
Message-ID: <20160602164711.GS16910@localhost> (raw)
In-Reply-To: <20160602125807.GN8307@bigcity.dyn.berto.se>

On Thu, Jun 02, 2016 at 02:58:07PM +0200, Niklas S�derlund wrote:
> Hi Vinod,
> 
> On 2016-06-01 23:36:11 +0530, Vinod Koul wrote:
> > 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?
> 
> Yes, since the arm specific patch are depending on other parts of the 
> series I was hoping to be able to get Russells Ack on it and then try to 
> get it all in through the dmaengine tree.

Sounds good to me..

> If you see a better way I'm happy to do it that way, let me know what 
> you think. I hold off v8 that adresses the issues Russell brought up a 
> few days untill I know what you think is best.

-- 
~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: Thu, 2 Jun 2016 22:17:11 +0530	[thread overview]
Message-ID: <20160602164711.GS16910@localhost> (raw)
In-Reply-To: <20160602125807.GN8307@bigcity.dyn.berto.se>

On Thu, Jun 02, 2016 at 02:58:07PM +0200, Niklas S?derlund wrote:
> Hi Vinod,
> 
> On 2016-06-01 23:36:11 +0530, Vinod Koul wrote:
> > 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?
> 
> Yes, since the arm specific patch are depending on other parts of the 
> series I was hoping to be able to get Russells Ack on it and then try to 
> get it all in through the dmaengine tree.

Sounds good to me..

> If you see a better way I'm happy to do it that way, let me know what 
> you think. I hold off v8 that adresses the issues Russell brought up a 
> few days untill I know what you think is best.

-- 
~Vinod

  reply	other threads:[~2016-06-02 16:47 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 ` [PATCHv7 0/6] " Vinod Koul
2016-06-01 18:06   ` 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 [this message]
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=20160602164711.GS16910@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=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.