From: Arnd Bergmann <arnd-r2nGTMty4D4@public.gmane.org>
To: Murali Karicheri <m-karicheri2-l0cyMroinI0@public.gmane.org>
Cc: Rob Herring <robherring2-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
Will Deacon <will.deacon-5wv7dgnIgG8@public.gmane.org>,
Russell King - ARM Linux
<linux-lFZ/pmaqli7XmaaqVzeoHQ@public.gmane.org>,
"linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org"
<linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org>,
"linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
<linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
Grant Likely
<grant.likely-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>,
Rob Herring <robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>,
"devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
<devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
Bjorn Helgaas <bhelgaas-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>,
"linux-pci-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
<linux-pci-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>
Subject: Re: [PATCH v2 1/2] of/pci: add of_pci_dma_configure() update dma configuration
Date: Sat, 03 Jan 2015 22:37:09 +0100 [thread overview]
Message-ID: <2019516.ehiuEv0rdL@wuerfel> (raw)
In-Reply-To: <54A71CD1.4070107-l0cyMroinI0@public.gmane.org>
On Friday 02 January 2015 17:33:53 Murali Karicheri wrote:
>
> I have no experience with IOMMU and may not offer much help here as I
> originally wrote above. Will Deacon has added this API and probably able
> to offer some help in this discussion.
>
> Will Deacon,
>
> Any comment?
It's complicated :(
> Looking at the iommu documentation and of_iommu.c, I get a feeling that
> this API is not really used at present as there are no callers of
> of_iommu_set_ops() and I assume this is a WIP.
Right, but we have patches for some iommu drivers based on this API,
and we should migrate all of them eventually.
> I believe the way it is
> expected to work is to have the iommu driver of the master IOMMU devices
> call of_iommu_set_ops(). The device node of this master IOMMU device is
> specified as a phandle in the OF node of the device (various bus devices
> such as platform, PCI etc). This allow to retrieve the iommu ops though
> the of_iommu_configure() API and use it in arch_setup_dma_ops(). So my
> gut feeling is that for PCI devices, as there are no DT node, the root
> bus node may specify iommus phandle to IOMMU master OF nodes.
Yes, but we also need to pass a PCI device specific identifier along
with the root bus node, because some iommu drivers take the PCI
bus/device/function number into account for creating per-function
i/o page tables.
> W.r.t your comment "We may want to address the comment in
> of_iommu_configure about parent nodes. We should be sure these changes
> work with how we would do searching parent nodes",
>
> I believe, the parent node search itself should work the same way in the
> case of PCI as with platform bus case. PCI's case, we are providing the
> OF node of the root bus host bridge. Why should this be any different in
> terms of search?
>
> I see a potential issue with dma-ranges as described in the notes below.
> As noted below the usage of dma-range for iommu is to be determined. For
> keystone, the of_iommu_configure() always return false as we don't use
> the iommu. But don't know if this has any consequences for other
> platforms. Or I got your questions wrong. Any help here from others on
> the list?
>
> ========================================================================
> One possible extension to the above is to use an "iommus" property along
> with a "dma-ranges" property in a bus device node (such as PCI host
> bridges). This can be useful to describe how children on the bus relate
> to the IOMMU if they are not explicitly listed in the device tree (e.g.
> PCI devices). However, the requirements of that use-case haven't been
> fully determined yet. Implementing this is therefore not recommended
> without further discussion and extension of this binding.
> =========================================================================
This probably won't ever apply to PCI devices, so let's ignore it for now.
For the moment (and for PCI), we should assume that we either configure
an iommu directly or we use dma-ranges if no iommu is in use.
Arnd
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
next prev parent reply other threads:[~2015-01-03 21:37 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-12-24 22:11 [PATCH v2 0/2] PCI: get DMA configuration from parent device Murali Karicheri
2014-12-24 22:11 ` [PATCH v2 1/2] of/pci: add of_pci_dma_configure() update dma configuration Murali Karicheri
2014-12-26 19:33 ` Rob Herring
2015-01-02 17:20 ` Murali Karicheri
2015-01-02 20:45 ` Rob Herring
2015-01-02 22:33 ` Murali Karicheri
[not found] ` <54A71CD1.4070107-l0cyMroinI0@public.gmane.org>
2015-01-03 21:37 ` Arnd Bergmann [this message]
2015-01-05 20:06 ` Murali Karicheri
2015-01-05 22:26 ` Arnd Bergmann
2015-01-05 23:35 ` Murali Karicheri
2015-01-06 19:50 ` Will Deacon
2015-01-06 21:08 ` Murali Karicheri
2015-01-02 20:57 ` Arnd Bergmann
2015-01-02 21:12 ` Murali Karicheri
[not found] ` <1419459099-6667-1-git-send-email-m-karicheri2-l0cyMroinI0@public.gmane.org>
2014-12-24 22:11 ` [PATCH v2 2/2] PCI: update dma configuration from DT Murali Karicheri
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=2019516.ehiuEv0rdL@wuerfel \
--to=arnd-r2ngtmty4d4@public.gmane.org \
--cc=bhelgaas-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org \
--cc=devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=grant.likely-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org \
--cc=linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org \
--cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=linux-lFZ/pmaqli7XmaaqVzeoHQ@public.gmane.org \
--cc=linux-pci-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=m-karicheri2-l0cyMroinI0@public.gmane.org \
--cc=robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org \
--cc=robherring2-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org \
--cc=will.deacon-5wv7dgnIgG8@public.gmane.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).