public inbox for linux-arm-kernel@lists.infradead.org
 help / color / mirror / Atom feed
From: yong.wu@mediatek.com (Yong Wu)
To: linux-arm-kernel@lists.infradead.org
Subject: [RFC PATCH 0/5] arm64: IOMMU-backed DMA mapping
Date: Fri, 16 Jan 2015 15:21:32 +0800	[thread overview]
Message-ID: <1421392892.19175.6.camel@mhfsdcap03> (raw)
In-Reply-To: <54B80857.7060407@arm.com>

On Thu, 2015-01-15 at 18:35 +0000, Robin Murphy wrote:
> On 13/01/15 08:02, Yingjoe Chen wrote:
> > On Mon, 2015-01-12 at 20:48 +0000, Robin Murphy wrote:
> >> Hi all,
> >>
> >> Whilst it's a long way off perfect, this has reached the point of being
> >> functional and stable enough to be useful, so here it is. The core
> >> consists of the meat of the arch/arm implementation modified to remove
> >> the assumption of PAGE_SIZE pages and ported over to the Intel IOVA
> >> allocator instead of the bitmap-based one. For that, this series depends
> >> on my "Genericise the IOVA allocator" series posted earlier[1].
> >
> > Hi Robin,
> >
> > We'd to give it a try. Do you have a public git tree contains both
> > series?
> >
> > Joe.C
> 
> Now that the server seems to be properly accessible again, I've made a 
> branch with both series available here:
> 
>    git://linux-arm.org/linux-rm iommu/dma
> 
> Note that in the current state it also depends on having the ARM SMMU 
> driver selected in the config, due to an oversight on my part :(
> 
> Robin.
> 
Dear Robin,

     We have test this patch on our SOC(mt8173),which have our own iommu
HW(it is not ARM SMMU), the patch could work well.
Tested-by:Yong Wu <yong.wu@mediatek.com>

 And I have some questiones about the usage:

1) If we create a iommu domain by ?arch_setup_dma_ops", then we would
like to call the standard iommu interface, like
?iommu_set_fault_handle?,
How can we get the "struct iommu_domain *"? (the ?dev_domain? is
static.)

2) If a device A call ?arch_setup_dma_ops? to create a iommu domain, and
a client device B would like to join this iommu domain, 
so it call ?iommu_dma_attach_device?. then the device B want to alloc
the iommu memory, it call ?dma_alloc_attrs? whose first parameter should
be the ?struct device *?of device A. Is it designed like this in this
patch?
    (In arch/arm, ?dev->archdata.dma_ops = &iommu_dma_ops? is in
?arm_iommu_attach_devce?;
     In this patch, this sentence is in ?arch_setup_dma_ops?).

3)  void arch_setup_dma_ops(struct device *dev, u64 dma_base, u64 size,
struct iommu_ops *iommu, bool coherent)
    In this function, the second and third parameter are the dma address
base and size, can they work currently?
(take a example, I set the dma_base is 0, size is 0x40000000 while
calling arch_setup_dma_ops, 
 then I alloc a range iova whose size is 50*SZ_4K, the return iova is
0xfffce000, it is over 0x40000000.)

  reply	other threads:[~2015-01-16  7:21 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-01-12 20:48 [RFC PATCH 0/5] arm64: IOMMU-backed DMA mapping Robin Murphy
2015-01-12 20:48 ` [RFC PATCH 1/5] arm64: Combine coherent and non-coherent swiotlb dma_ops Robin Murphy
2015-01-12 20:48 ` [RFC PATCH 2/5] arm64: implement generic IOMMU configuration Robin Murphy
2015-01-12 20:48 ` [RFC PATCH 3/5] iommu: implement common IOMMU ops for DMA mapping Robin Murphy
2015-01-23 17:42   ` Laura Abbott
2015-01-23 18:14     ` Robin Murphy
2015-01-27  0:21   ` Joerg Roedel
2015-01-27 12:27     ` Robin Murphy
2015-01-27 12:38       ` Joerg Roedel
2015-01-28 13:53         ` Will Deacon
2015-01-12 20:48 ` [RFC PATCH 4/5] arm64: add IOMMU dma_ops Robin Murphy
2015-01-23 15:26   ` Will Deacon
2015-01-23 17:33     ` Robin Murphy
2015-01-26  3:25   ` Joseph Lo
2015-01-27 17:30     ` Robin Murphy
2015-01-26  9:10   ` Joseph Lo
2015-01-28  2:22   ` Joseph Lo
2015-03-05 14:31   ` Marek Szyprowski
2015-01-12 20:48 ` [RFC PATCH 5/5] arm64: hook up " Robin Murphy
2015-01-13  8:02 ` [RFC PATCH 0/5] arm64: IOMMU-backed DMA mapping Yingjoe Chen
2015-01-13 12:07   ` Robin Murphy
2015-01-15 18:35   ` Robin Murphy
2015-01-16  7:21     ` Yong Wu [this message]
2015-01-16 20:12       ` Robin Murphy
2015-01-13 11:08 ` Stefano Stabellini
2015-01-13 11:45   ` Robin Murphy
2015-01-23 16:47 ` Catalin Marinas
2015-01-23 17:41   ` Robin Murphy
2015-03-05 14:31 ` Marek Szyprowski
2015-03-05 16:42   ` Robin Murphy

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=1421392892.19175.6.camel@mhfsdcap03 \
    --to=yong.wu@mediatek.com \
    --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