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: linux-renesas-soc@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org, dmaengine@vger.kernel.org,
	iommu@lists.linux-foundation.org, linux@armlinux.org.uk,
	hch@infradead.org, dan.j.williams@intel.com,
	robin.murphy@arm.com, laurent.pinchart@ideasonboard.com,
	linus.walleij@linaro.org, arnd@arndb.de
Subject: Re: [PATCHv9 0/6] dmaengine: rcar-dmac: add iommu support for slave transfers
Date: Mon, 26 Sep 2016 22:17:22 +0530	[thread overview]
Message-ID: <20160926164722.GB2467@localhost> (raw)
In-Reply-To: <20160810112219.17964-1-niklas.soderlund+renesas@ragnatech.se>

On Wed, Aug 10, 2016 at 01:22:13PM +0200, Niklas Söderlund wrote:
> Hi,
> 
> 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.8-rc1. And I'm hoping to be able to collect a
> Ack from Russell King on patch 4/6 that adds the ARM specific part and then be
> able to take the whole series through the dmaengine tree. If this is not the
> best route I'm more then happy to do it another way.
> 
> It's tested on a Koelsch with CONFIG_IPMMU_VMSA and by enabling the
> ipmmu_ds node in r8a7791.dtsi. I verified operation by interacting with
> /dev/mmcblk1, i2c and the serial console which are devices behind the
> iommu.
> 
> Furthermore I have audited to the best of my ability all call paths
> involved to make sure that the dma_addr_t obtained from
> dma_map_resource() to is not used in a way where it would be expected
> for the mapping to be RAM (have a struct page). Many thanks to Christoph
> Hellwig and Laurent Pinchart for there input in this effort.

Applied, thanks

-- 
~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: linux-renesas-soc@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org, dmaengine@vger.kernel.org,
	iommu@lists.linux-foundation.org, linux@armlinux.org.uk,
	hch@infradead.org, dan.j.williams@intel.com,
	robin.murphy@arm.com, laurent.pinchart@ideasonboard.com,
	linus.walleij@linaro.org, arnd@arndb.de
Subject: Re: [PATCHv9 0/6] dmaengine: rcar-dmac: add iommu support for slave transfers
Date: Mon, 26 Sep 2016 22:17:22 +0530	[thread overview]
Message-ID: <20160926164722.GB2467@localhost> (raw)
In-Reply-To: <20160810112219.17964-1-niklas.soderlund+renesas@ragnatech.se>

On Wed, Aug 10, 2016 at 01:22:13PM +0200, Niklas S�derlund wrote:
> Hi,
> 
> 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.8-rc1. And I'm hoping to be able to collect a
> Ack from Russell King on patch 4/6 that adds the ARM specific part and then be
> able to take the whole series through the dmaengine tree. If this is not the
> best route I'm more then happy to do it another way.
> 
> It's tested on a Koelsch with CONFIG_IPMMU_VMSA and by enabling the
> ipmmu_ds node in r8a7791.dtsi. I verified operation by interacting with
> /dev/mmcblk1, i2c and the serial console which are devices behind the
> iommu.
> 
> Furthermore I have audited to the best of my ability all call paths
> involved to make sure that the dma_addr_t obtained from
> dma_map_resource() to is not used in a way where it would be expected
> for the mapping to be RAM (have a struct page). Many thanks to Christoph
> Hellwig and Laurent Pinchart for there input in this effort.

Applied, thanks

-- 
~Vinod

WARNING: multiple messages have this Message-ID (diff)
From: vinod.koul@intel.com (Vinod Koul)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCHv9 0/6] dmaengine: rcar-dmac: add iommu support for slave transfers
Date: Mon, 26 Sep 2016 22:17:22 +0530	[thread overview]
Message-ID: <20160926164722.GB2467@localhost> (raw)
In-Reply-To: <20160810112219.17964-1-niklas.soderlund+renesas@ragnatech.se>

On Wed, Aug 10, 2016 at 01:22:13PM +0200, Niklas S?derlund wrote:
> Hi,
> 
> 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.8-rc1. And I'm hoping to be able to collect a
> Ack from Russell King on patch 4/6 that adds the ARM specific part and then be
> able to take the whole series through the dmaengine tree. If this is not the
> best route I'm more then happy to do it another way.
> 
> It's tested on a Koelsch with CONFIG_IPMMU_VMSA and by enabling the
> ipmmu_ds node in r8a7791.dtsi. I verified operation by interacting with
> /dev/mmcblk1, i2c and the serial console which are devices behind the
> iommu.
> 
> Furthermore I have audited to the best of my ability all call paths
> involved to make sure that the dma_addr_t obtained from
> dma_map_resource() to is not used in a way where it would be expected
> for the mapping to be RAM (have a struct page). Many thanks to Christoph
> Hellwig and Laurent Pinchart for there input in this effort.

Applied, thanks

-- 
~Vinod

  parent reply	other threads:[~2016-09-26 16:47 UTC|newest]

Thread overview: 80+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-08-10 11:22 [PATCHv9 0/6] dmaengine: rcar-dmac: add iommu support for slave transfers Niklas Söderlund
2016-08-10 11:22 ` Niklas Söderlund
2016-08-10 11:22 ` Niklas Söderlund
2016-08-10 11:22 ` [PATCHv9 1/6] dma-mapping: add {map,unmap}_resource to dma_map_ops Niklas Söderlund
2016-08-10 11:22   ` Niklas Söderlund
2016-08-10 11:22   ` Niklas Söderlund
2016-08-10 11:22 ` [PATCHv9 2/6] dma-debug: add support for resource mappings Niklas Söderlund
2016-08-10 11:22   ` Niklas Söderlund
2016-08-10 11:22   ` Niklas Söderlund
2016-09-05  9:39   ` Laurent Pinchart
2016-09-05  9:39     ` Laurent Pinchart
2016-08-10 11:22 ` [PATCHv9 3/6] dma-mapping: add dma_{map,unmap}_resource Niklas Söderlund
2016-08-10 11:22   ` Niklas Söderlund
2016-08-10 11:22   ` Niklas Söderlund
     [not found]   ` <20160810112219.17964-4-niklas.soderlund+renesas-1zkq55x86MTxsAP9Fp7wbw@public.gmane.org>
2016-09-05  9:46     ` Laurent Pinchart
2016-09-05  9:46       ` Laurent Pinchart
2016-09-05  9:46       ` Laurent Pinchart
2016-08-10 11:22 ` [PATCHv9 4/6] arm: dma-mapping: add {map, unmap}_resource for iommu ops Niklas Söderlund
2016-08-10 11:22   ` Niklas Söderlund
2016-08-10 11:22   ` [PATCHv9 4/6] arm: dma-mapping: add {map,unmap}_resource " Niklas Söderlund
     [not found]   ` <20160810112219.17964-5-niklas.soderlund+renesas-1zkq55x86MTxsAP9Fp7wbw@public.gmane.org>
2016-08-23 15:31     ` Niklas Söderlund
2016-08-23 15:31       ` Niklas Söderlund
2016-08-23 15:31       ` Niklas Söderlund
2016-09-05  9:54       ` Laurent Pinchart
2016-09-05  9:54         ` [PATCHv9 4/6] arm: dma-mapping: add {map, unmap}_resource " Laurent Pinchart
2016-08-10 11:22 ` [PATCHv9 5/6] dmaengine: rcar-dmac: group slave configuration Niklas Söderlund
2016-08-10 11:22   ` Niklas Söderlund
2016-08-10 11:22   ` Niklas Söderlund
2016-08-10 11:22 ` [PATCHv9 6/6] dmaengine: rcar-dmac: add iommu support for slave transfers Niklas Söderlund
2016-08-10 11:22   ` Niklas Söderlund
2016-08-10 11:22   ` Niklas Söderlund
2016-09-05  9:52   ` Laurent Pinchart
2016-09-05  9:52     ` Laurent Pinchart
2016-09-05 10:37     ` Robin Murphy
2016-09-05 10:37       ` Robin Murphy
2016-09-05 10:37       ` Robin Murphy
2017-01-01 23:08     ` Laurent Pinchart
2017-01-01 23:08       ` Laurent Pinchart
2017-01-01 23:08       ` Laurent Pinchart
2017-01-09 15:42       ` Niklas Söderlund
2017-01-09 15:42         ` Niklas Söderlund
2017-01-09 15:42         ` Niklas Söderlund
     [not found] ` <20160810112219.17964-1-niklas.soderlund+renesas-1zkq55x86MTxsAP9Fp7wbw@public.gmane.org>
2016-08-10 17:37   ` [PATCHv9 0/6] " Vinod Koul
2016-08-10 17:37     ` Vinod Koul
2016-08-10 17:37     ` Vinod Koul
2016-09-15 16:26     ` Vinod Koul
2016-09-15 16:26       ` Vinod Koul
2016-09-15 16:26       ` Vinod Koul
2016-09-16  9:07       ` Arnd Bergmann
2016-09-16  9:07         ` Arnd Bergmann
2016-09-16  9:07         ` Arnd Bergmann
2016-09-16  9:48         ` Laurent Pinchart
2016-09-16  9:48           ` Laurent Pinchart
2016-09-16 10:36           ` Robin Murphy
2016-09-16 10:36             ` Robin Murphy
2016-09-16 10:36             ` Robin Murphy
2016-09-16 12:05             ` Laurent Pinchart
2016-09-16 12:05               ` Laurent Pinchart
2016-09-16 12:49               ` Robin Murphy
2016-09-16 12:49                 ` Robin Murphy
2016-09-16 12:49                 ` Robin Murphy
     [not found]                 ` <cea119f1-18d5-675d-ee33-c22b0c8e7693-5wv7dgnIgG8@public.gmane.org>
2016-09-16 13:01                   ` Laurent Pinchart
2016-09-16 13:01                     ` Laurent Pinchart
2016-09-16 13:01                     ` Laurent Pinchart
2016-09-16 12:02           ` Arnd Bergmann
2016-09-16 12:02             ` Arnd Bergmann
2016-09-16 12:02             ` Arnd Bergmann
2016-09-16 12:09             ` Laurent Pinchart
2016-09-16 12:09               ` Laurent Pinchart
2016-09-16 12:22               ` Arnd Bergmann
2016-09-16 12:22                 ` Arnd Bergmann
2016-09-16 12:58                 ` Laurent Pinchart
2016-09-16 12:58                   ` Laurent Pinchart
2016-09-23  7:25       ` Niklas Söderlund
2016-09-23  7:25         ` Niklas Söderlund
2016-09-23  7:25         ` Niklas Söderlund
2016-08-29 13:11   ` Haggai Eran
2016-09-26 16:47 ` Vinod Koul [this message]
2016-09-26 16:47   ` Vinod Koul
2016-09-26 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=20160926164722.GB2467@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=linux@armlinux.org.uk \
    --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.