linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: arnd@arndb.de (Arnd Bergmann)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v6 6/7] PCI: update dma configuration from DT
Date: Wed, 25 Feb 2015 17:09:41 +0100	[thread overview]
Message-ID: <4781283.CC9oFpsHLJ@wuerfel> (raw)
In-Reply-To: <54EDF236.40101@ti.com>

On Wednesday 25 February 2015 11:03:02 Murali Karicheri wrote:
> 
> > (I don't know exactly how these patches all fit together, so that's
> > probably not accurate, but that's the *sort* of thing I'd like to include.)
> >
> > If that actually *is* what's going on, I have to wonder why this isn't
> > implemented as a very simple IOMMU instead of adding dma_pfn_offset,
> > which is present on all arches but only used on ARM.  In some sense that
> > offset is parallel but incompatible with an IOMMU: they both translate DMA
> > addresses into system RAM addresses.
> 
> I don't have much history on any previous discussion on the subject you 
> are referring to. I assume it would have happened when 
> of_dma_configure() was first introduced. On Keystone, we don't have 
> IOMMU support and dma_pfn_offset is needed to translate DMA address to 
> System RAM address and vice-versa. So this has to be supported for 
> Keystone. There can be enhancement for IOMMU with out impacting this 
> feature for Keystone.

The direction we are taking with IOMMU in general is opposite to what Bjorn
is suggesting: I believe what he wants to say is that we should use the
traditional approach of having a specialized dma_map_ops implementation
for this, just like we do for IOMMU implementations on x86, IA64 or PowerPC.

However, with the recent explosion of IOMMU implementations on ARM, we
are moving towards having a single dma_map_ops structure for all of them,
and that structure does not work with the keystone hardware. Instead,
the normal ARM dma_map_ops have been changed to handle the offset,
which is the same thing we do on PowerPC.

	Arnd

  reply	other threads:[~2015-02-25 16:09 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-02-05 21:52 [PATCH v6 0/7] PCI: get DMA configuration from parent device Murali Karicheri
2015-02-05 21:52 ` [PATCH v6 1/7] of: iommu: add ptr to OF node arg to of_iommu_configure() Murali Karicheri
2015-02-05 21:52 ` [PATCH v6 2/7] of: move of_dma_configure() to device.c to help re-use Murali Karicheri
2015-02-05 21:52 ` [PATCH v6 3/7] of: fix size when dma-range is not used Murali Karicheri
2015-02-06 14:38   ` Catalin Marinas
2015-02-06 14:54     ` Murali Karicheri
2015-02-06 15:12       ` Catalin Marinas
2015-02-06 20:26         ` Murali Karicheri
2015-02-05 21:52 ` [PATCH v6 4/7] PCI: add helper functions pci_get[put]_host_bridge_device() Murali Karicheri
2015-02-05 21:52 ` [PATCH v6 5/7] of/pci: add of_pci_dma_configure() update dma configuration Murali Karicheri
2015-02-05 21:52 ` [PATCH v6 6/7] PCI: update dma configuration from DT Murali Karicheri
2015-02-25  1:53   ` Bjorn Helgaas
2015-02-25 16:03     ` Murali Karicheri
2015-02-25 16:09       ` Arnd Bergmann [this message]
2015-02-25 20:45         ` Murali Karicheri
2015-02-05 21:52 ` [PATCH v6 7/7] arm: dma-mapping: limit iommu mapping size Murali Karicheri
2015-02-05 21:59 ` [PATCH v6 0/7] PCI: get DMA configuration from parent device Murali Karicheri
2015-02-06 15:15 ` Catalin Marinas
2015-02-06 15:28   ` Murali Karicheri
2015-02-06 17:53     ` Bjorn Helgaas
2015-02-06 18:36       ` Murali Karicheri
2015-02-11 16:54         ` Murali Karicheri
2015-02-11 16:58           ` Murali Karicheri
2015-02-23 22:08             ` Murali Karicheri
2015-02-23 22:15               ` Bjorn Helgaas
2015-02-23 22:44                 ` Murali Karicheri
2015-02-09  5:23 ` Suravee Suthikulpanit
2015-02-09 17:26   ` Murali Karicheri
2015-02-09  5:48 ` Will Deacon
2015-02-25 22:20 ` Bjorn Helgaas

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=4781283.CC9oFpsHLJ@wuerfel \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).