All of lore.kernel.org
 help / color / mirror / Atom feed
From: arnd@arndb.de (Arnd Bergmann)
To: linux-arm-kernel@lists.infradead.org
Subject: [RFC 0/2] ARM: DMA-mapping & IOMMU integration
Date: Mon, 13 Jun 2011 17:46:18 +0200	[thread overview]
Message-ID: <201106131746.18972.arnd@arndb.de> (raw)
In-Reply-To: <BANLkTikR5AE=-wTWzrSJ0TUaks0_rA3mcg@mail.gmail.com>

On Monday 13 June 2011 17:30:44 KyongHo Cho wrote:
> On Tue, Jun 14, 2011 at 12:07 AM, Arnd Bergmann <arnd@arndb.de> wrote:
> > I'm sure that the graphics people will disagree with you on that.
> > Having the frame buffer mapped in write-combine mode is rather
> > important when you want to efficiently output videos from your
> > CPU.
> >
> I agree with you.
> But I am discussing about dma_alloc_writecombine() in ARM.
> You can see that only ARM and AVR32 implement it and there are few
> drivers which use it.
> No function in dma_map_ops corresponds to dma_alloc_writecombine().
> That's why Marek tried to add 'alloc_writecombine' to dma_map_ops.

Yes, and I think Marek's patch is really necessary. The reason we
need dma_alloc_writecombine on ARM is because the page attributes in
the kernel need to match the ones in user space, while other
architectures either handle the writecombine flag outside of the
page table or can have multiple conflicting mappings.

The reason that I suspect AVR32 needs it is to share device drivers
with ARM.

> > I can understand that there are arguments why mapping a DMA buffer into
> > user space doesn't belong into dma_map_ops, but I don't see how the
> > presence of an IOMMU is one of them.
> >
> > The entire purpose of dma_map_ops is to hide from the user whether
> > you have an IOMMU or not, so that would be the main argument for
> > putting it in there, not against doing so.
> >
> I also understand the reasons why dma_map_ops maps a buffer into user space.
> Mapping in device and user space at the same time or in a simple
> approach may look good.
> But I think mapping to user must be and driver-specific.
> Moreover, kernel already provides various ways to map physical memory
> to user space.

I believe the idea of providing dma_mmap_... is to ensure that the
page attributes are not conflicting and the DMA code is the place
that decides on the page attributes for the kernel mapping, so no
other place in the kernel can really know what it should be in user
space.

> And I think that remapping DMA address that is in device address space
> to user space is not a good idea
> because DMA address is not same to physical address semantically if
> features of IOMMU are implemented.

I'm totally not following this argument. This has nothing to do with IOMMU
or not. If you have an IOMMU, the dma code will know where the pages are
anyway, so it can always map them into user space. The dma code might
have an easier way to do it other than follwoing the page tables.

	Arnd

WARNING: multiple messages have this Message-ID (diff)
From: Arnd Bergmann <arnd@arndb.de>
To: linux-arm-kernel@lists.infradead.org
Cc: KyongHo Cho <pullip.cho@samsung.com>,
	Russell King - ARM Linux <linux@arm.linux.org.uk>,
	Joerg Roedel <joro@8bytes.org>,
	linaro-mm-sig@lists.linaro.org, linux-mm@kvack.org,
	Kyungmin Park <kyungmin.park@samsung.com>,
	Marek Szyprowski <m.szyprowski@samsung.com>
Subject: Re: [RFC 0/2] ARM: DMA-mapping & IOMMU integration
Date: Mon, 13 Jun 2011 17:46:18 +0200	[thread overview]
Message-ID: <201106131746.18972.arnd@arndb.de> (raw)
In-Reply-To: <BANLkTikR5AE=-wTWzrSJ0TUaks0_rA3mcg@mail.gmail.com>

On Monday 13 June 2011 17:30:44 KyongHo Cho wrote:
> On Tue, Jun 14, 2011 at 12:07 AM, Arnd Bergmann <arnd@arndb.de> wrote:
> > I'm sure that the graphics people will disagree with you on that.
> > Having the frame buffer mapped in write-combine mode is rather
> > important when you want to efficiently output videos from your
> > CPU.
> >
> I agree with you.
> But I am discussing about dma_alloc_writecombine() in ARM.
> You can see that only ARM and AVR32 implement it and there are few
> drivers which use it.
> No function in dma_map_ops corresponds to dma_alloc_writecombine().
> That's why Marek tried to add 'alloc_writecombine' to dma_map_ops.

Yes, and I think Marek's patch is really necessary. The reason we
need dma_alloc_writecombine on ARM is because the page attributes in
the kernel need to match the ones in user space, while other
architectures either handle the writecombine flag outside of the
page table or can have multiple conflicting mappings.

The reason that I suspect AVR32 needs it is to share device drivers
with ARM.

> > I can understand that there are arguments why mapping a DMA buffer into
> > user space doesn't belong into dma_map_ops, but I don't see how the
> > presence of an IOMMU is one of them.
> >
> > The entire purpose of dma_map_ops is to hide from the user whether
> > you have an IOMMU or not, so that would be the main argument for
> > putting it in there, not against doing so.
> >
> I also understand the reasons why dma_map_ops maps a buffer into user space.
> Mapping in device and user space at the same time or in a simple
> approach may look good.
> But I think mapping to user must be and driver-specific.
> Moreover, kernel already provides various ways to map physical memory
> to user space.

I believe the idea of providing dma_mmap_... is to ensure that the
page attributes are not conflicting and the DMA code is the place
that decides on the page attributes for the kernel mapping, so no
other place in the kernel can really know what it should be in user
space.

> And I think that remapping DMA address that is in device address space
> to user space is not a good idea
> because DMA address is not same to physical address semantically if
> features of IOMMU are implemented.

I'm totally not following this argument. This has nothing to do with IOMMU
or not. If you have an IOMMU, the dma code will know where the pages are
anyway, so it can always map them into user space. The dma code might
have an easier way to do it other than follwoing the page tables.

	Arnd

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

  parent reply	other threads:[~2011-06-13 15:46 UTC|newest]

Thread overview: 40+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-05-25  7:35 [RFC 0/2] ARM: DMA-mapping & IOMMU integration Marek Szyprowski
2011-05-25  7:35 ` Marek Szyprowski
2011-05-25  7:35 ` [RFC 1/2] ARM: Move dma related inlines into arm_dma_ops methods Marek Szyprowski
2011-05-25  7:35 ` [RFC 2/2] ARM: initial proof-of-concept IOMMU mapper for DMA-mapping Marek Szyprowski
2011-06-04 16:13 ` [RFC 0/2] ARM: DMA-mapping & IOMMU integration Ohad Ben-Cohen
2011-06-06  6:09   ` Marek Szyprowski
2011-06-13 14:12 ` KyongHo Cho
2011-06-13 14:12   ` KyongHo Cho
2011-06-13 15:07   ` Arnd Bergmann
2011-06-13 15:07     ` Arnd Bergmann
2011-06-13 15:30     ` KyongHo Cho
2011-06-13 15:30       ` KyongHo Cho
2011-06-13 15:40       ` Catalin Marinas
2011-06-13 15:40         ` Catalin Marinas
2011-06-13 16:00         ` [Linaro-mm-sig] " KyongHo Cho
2011-06-13 16:00           ` KyongHo Cho
2011-06-13 17:55           ` Michael K. Edwards
2011-06-13 17:55             ` Michael K. Edwards
2011-06-13 18:54             ` Jesse Barnes
2011-06-13 18:54               ` Jesse Barnes
2011-06-14 18:15               ` Michael K. Edwards
2011-06-14 18:15                 ` Michael K. Edwards
2011-06-14 18:21                 ` Jesse Barnes
2011-06-14 18:21                   ` Jesse Barnes
2011-06-14 19:10                   ` Zach Pfeffer
2011-06-14 19:10                     ` Zach Pfeffer
2011-06-14 20:59                   ` Michael K. Edwards
2011-06-14 20:59                     ` Michael K. Edwards
2011-06-13 18:01           ` Catalin Marinas
2011-06-13 18:01             ` Catalin Marinas
2011-06-13 15:46       ` Arnd Bergmann [this message]
2011-06-13 15:46         ` Arnd Bergmann
2011-06-13 15:58         ` [Linaro-mm-sig] " KyongHo Cho
2011-06-13 15:58           ` KyongHo Cho
2011-06-14  7:46       ` Marek Szyprowski
2011-06-14  7:46         ` Marek Szyprowski
2011-06-20 14:31 ` Subash Patel
2011-06-20 14:31   ` Subash Patel
2011-06-20 14:59   ` Marek Szyprowski
2011-06-20 14:59     ` Marek Szyprowski

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=201106131746.18972.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.