From: Arnd Bergmann <arnd@arndb.de> To: linux-arm-kernel@lists.infradead.org Cc: Joerg Roedel <jroedel@suse.de>, Will Deacon <will.deacon@arm.com>, Rob Clark <robdclark@gmail.com>, "iommu@lists.linux-foundation.org" <iommu@lists.linux-foundation.org>, Thierry Reding <thierry.reding@gmail.com>, Laurent Pinchart <laurent.pinchart@ideasonboard.com>, Varun Sethi <Varun.Sethi@freescale.com>, David Woodhouse <dwmw2@infradead.org> Subject: Re: [PATCH v6 6/8] dma-mapping: detect and configure IOMMU in of_dma_configure Date: Wed, 17 Dec 2014 16:35:29 +0100 [thread overview] Message-ID: <2299294.lPnEQgl4lK@wuerfel> (raw) In-Reply-To: <20141217144518.GE870@arm.com> On Wednesday 17 December 2014 14:45:18 Will Deacon wrote: > On Wed, Dec 17, 2014 at 02:15:12PM +0000, Arnd Bergmann wrote: > > On Wednesday 17 December 2014 12:09:49 Will Deacon wrote: > > > On Tue, Dec 16, 2014 at 12:08:15PM +0000, Arnd Bergmann wrote: > > > > On Monday 15 December 2014 18:09:33 Will Deacon wrote: > > > For iommu_group creation, that could be done in the of code by treating the > > > master IDs as bus IDs on a per-IOMMU bus; when a new device is probed, we > > > can look at the set of devices with intersecting IDs and create a group > > > containing those. This is similar to walking a PCI topology to establish DMA > > > aliases. > > > > > > The problem with all of this is how we distinguish the different ID formats > > > in the `iommus' device-tree property. For the ARM SMMU, we could have: > > > > > > (1) [easy case] A device has a list of StreamIDs > > > > > > (2) A device has a list of SMR mask/value pairs > > > > I was under the impression that using the format from (2), we could > > describe all devices that fall into (1). In the worst case, we would > > create an iommu group that is somewhat larger than one using discrete > > StreamID values, but I would hope that this does not cause actual > > troubles. > > The icky part is that an ARM SMMU can have one of two indexing schemes in > hardware: > > (1) The StreamID is used as a linear index into an (MMIO) table, which > has pointers to contexts (translation tables) > > (2) The StreamID is matched against a mask/value pair, which generates > an index into the same table mentioned above > > Currently, the driver probes ID registers at runtime to figure out which > indexing scheme is implemented. If we start encoding scheme-specific data in > the device-tree, then the binding will differ based on hardware properties > that aren't otherwise described. Is there precedent for this sort of thing > elsewhere? We should probably have different compatible strings in that case. Is it always hardwired which scheme gets used, or can the SMMU be reconfigured between the two? > > If all devices on each iommu fall into either 1 or 2, but you never mix > > the two on one iommu, this could be handled by supporting either > > #iommu-cells=<1> or <2> in the smmu driver. That way, the xlate function > > will know which method to apply by looking at the iommu's #iommu-cells > > property. > > Yes, that would work if you're ok with the above (i.e. we never see a mix > on the same IOMMU instance). Ok > > > (3) A (bus) device has a range translation for a downstream bus (e.g. > > > a PCI host controller which needs to convert RequesterID to StreamID). > > > > > > From the SMMU driver's perspective, they will all look like of_xlate calls > > > unless we augment the generic IOMMU bindings with extra properties to > > > identify the format. It also makes it difficult to pick a sensible value for > > > #iommu-cells, as it depends on the format. > > > > I would hope that PCI is the only case we need to worry about for a while. > > This means we just need to come up with another property or a set of properties > > that we can put into a PCI host controller device node in order to describe > > the mapping. These properties could be iommu-specific, so we add something > > to the PCI core that calls a new iommu callback function that takes the > > device node of the PCI host and the bus/device/function number as inputs. > > > > In arm_setup_iommu_dma_ops(), we can then do something like > > > > if (dev_is_pci(dev)) { > > struct pci_dev *pdev = to_pci_dev(dev); > > struct device_node *node; > > unsigned int bdf; > > > > node = find_pci_host_bridge(pdev->bus)->parent->of_node; > > bdf = PCI_DEVID(pdev->bus->number, dev->devfn); > > > > iommu_setup_pci_dev(pdev, node, bdf); > > } > > The other way to do this is have the IOMMU driver check dev_is_pci(dev) > in add_device, then call an of_xlate_pci_bdf library function which could > do the translation on-demand. We'd still need to find the device node for the host controller in common code, otherwise we don't have an of_xlate function to call. Arnd
WARNING: multiple messages have this Message-ID (diff)
From: arnd@arndb.de (Arnd Bergmann) To: linux-arm-kernel@lists.infradead.org Subject: [PATCH v6 6/8] dma-mapping: detect and configure IOMMU in of_dma_configure Date: Wed, 17 Dec 2014 16:35:29 +0100 [thread overview] Message-ID: <2299294.lPnEQgl4lK@wuerfel> (raw) In-Reply-To: <20141217144518.GE870@arm.com> On Wednesday 17 December 2014 14:45:18 Will Deacon wrote: > On Wed, Dec 17, 2014 at 02:15:12PM +0000, Arnd Bergmann wrote: > > On Wednesday 17 December 2014 12:09:49 Will Deacon wrote: > > > On Tue, Dec 16, 2014 at 12:08:15PM +0000, Arnd Bergmann wrote: > > > > On Monday 15 December 2014 18:09:33 Will Deacon wrote: > > > For iommu_group creation, that could be done in the of code by treating the > > > master IDs as bus IDs on a per-IOMMU bus; when a new device is probed, we > > > can look at the set of devices with intersecting IDs and create a group > > > containing those. This is similar to walking a PCI topology to establish DMA > > > aliases. > > > > > > The problem with all of this is how we distinguish the different ID formats > > > in the `iommus' device-tree property. For the ARM SMMU, we could have: > > > > > > (1) [easy case] A device has a list of StreamIDs > > > > > > (2) A device has a list of SMR mask/value pairs > > > > I was under the impression that using the format from (2), we could > > describe all devices that fall into (1). In the worst case, we would > > create an iommu group that is somewhat larger than one using discrete > > StreamID values, but I would hope that this does not cause actual > > troubles. > > The icky part is that an ARM SMMU can have one of two indexing schemes in > hardware: > > (1) The StreamID is used as a linear index into an (MMIO) table, which > has pointers to contexts (translation tables) > > (2) The StreamID is matched against a mask/value pair, which generates > an index into the same table mentioned above > > Currently, the driver probes ID registers at runtime to figure out which > indexing scheme is implemented. If we start encoding scheme-specific data in > the device-tree, then the binding will differ based on hardware properties > that aren't otherwise described. Is there precedent for this sort of thing > elsewhere? We should probably have different compatible strings in that case. Is it always hardwired which scheme gets used, or can the SMMU be reconfigured between the two? > > If all devices on each iommu fall into either 1 or 2, but you never mix > > the two on one iommu, this could be handled by supporting either > > #iommu-cells=<1> or <2> in the smmu driver. That way, the xlate function > > will know which method to apply by looking at the iommu's #iommu-cells > > property. > > Yes, that would work if you're ok with the above (i.e. we never see a mix > on the same IOMMU instance). Ok > > > (3) A (bus) device has a range translation for a downstream bus (e.g. > > > a PCI host controller which needs to convert RequesterID to StreamID). > > > > > > From the SMMU driver's perspective, they will all look like of_xlate calls > > > unless we augment the generic IOMMU bindings with extra properties to > > > identify the format. It also makes it difficult to pick a sensible value for > > > #iommu-cells, as it depends on the format. > > > > I would hope that PCI is the only case we need to worry about for a while. > > This means we just need to come up with another property or a set of properties > > that we can put into a PCI host controller device node in order to describe > > the mapping. These properties could be iommu-specific, so we add something > > to the PCI core that calls a new iommu callback function that takes the > > device node of the PCI host and the bus/device/function number as inputs. > > > > In arm_setup_iommu_dma_ops(), we can then do something like > > > > if (dev_is_pci(dev)) { > > struct pci_dev *pdev = to_pci_dev(dev); > > struct device_node *node; > > unsigned int bdf; > > > > node = find_pci_host_bridge(pdev->bus)->parent->of_node; > > bdf = PCI_DEVID(pdev->bus->number, dev->devfn); > > > > iommu_setup_pci_dev(pdev, node, bdf); > > } > > The other way to do this is have the IOMMU driver check dev_is_pci(dev) > in add_device, then call an of_xlate_pci_bdf library function which could > do the translation on-demand. We'd still need to find the device node for the host controller in common code, otherwise we don't have an of_xlate function to call. Arnd
next prev parent reply other threads:[~2014-12-17 15:35 UTC|newest] Thread overview: 220+ messages / expand[flat|nested] mbox.gz Atom feed top 2014-12-01 16:57 [PATCH v6 0/8] Introduce automatic DMA configuration for IOMMU masters Will Deacon 2014-12-01 16:57 ` Will Deacon [not found] ` <1417453034-21379-1-git-send-email-will.deacon-5wv7dgnIgG8@public.gmane.org> 2014-12-01 16:57 ` [PATCH v6 1/8] iommu: provide early initialisation hook for IOMMU drivers Will Deacon 2014-12-01 16:57 ` Will Deacon [not found] ` <1417453034-21379-2-git-send-email-will.deacon-5wv7dgnIgG8@public.gmane.org> 2014-12-01 23:54 ` Rob Herring 2014-12-01 23:54 ` Rob Herring [not found] ` <CAL_JsqKHvh9KSTYrrs1Pts5Kg=8dA1V6NiW57_2vdDH173qQGg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> 2014-12-02 9:23 ` Marek Szyprowski 2014-12-02 9:23 ` Marek Szyprowski [not found] ` <547D84F4.8030204-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org> 2014-12-02 9:36 ` Arnd Bergmann 2014-12-02 9:36 ` Arnd Bergmann 2014-12-02 9:43 ` Will Deacon 2014-12-02 9:43 ` Will Deacon 2014-12-02 12:05 ` Thierry Reding 2014-12-02 12:05 ` Thierry Reding 2014-12-02 14:16 ` Grant Likely 2014-12-02 14:16 ` Grant Likely [not found] ` <CACxGe6vyMkyE9ZRj_FQzi19ESEo7OV_RQoVV65xBYpdQV8cRGQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> 2014-12-03 19:57 ` Arnd Bergmann 2014-12-03 19:57 ` Arnd Bergmann 2014-12-04 9:49 ` Will Deacon 2014-12-04 9:49 ` Will Deacon [not found] ` <20141204094953.GA13224-5wv7dgnIgG8@public.gmane.org> 2014-12-04 10:10 ` Arnd Bergmann 2014-12-04 10:10 ` Arnd Bergmann 2014-12-04 10:21 ` Will Deacon 2014-12-04 10:21 ` Will Deacon [not found] ` <20141204102127.GF13224-5wv7dgnIgG8@public.gmane.org> 2014-12-04 11:19 ` Arnd Bergmann 2014-12-04 11:19 ` Arnd Bergmann 2014-12-04 11:25 ` Grant Likely 2014-12-04 11:25 ` Grant Likely [not found] ` <CACxGe6v4ZVHHGcc3Lhp8+FgKakyCkJFRAT2ufj-3DGWa=wmGkA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> 2014-12-04 11:52 ` Will Deacon 2014-12-04 11:52 ` Will Deacon [not found] ` <20141204115254.GF14519-5wv7dgnIgG8@public.gmane.org> 2014-12-04 12:43 ` Grant Likely 2014-12-04 12:43 ` Grant Likely 2014-12-04 12:26 ` Robin Murphy 2014-12-04 12:26 ` Robin Murphy [not found] ` <54805312.6000402-5wv7dgnIgG8@public.gmane.org> 2014-12-04 12:42 ` Grant Likely 2014-12-04 12:42 ` Grant Likely [not found] ` <CACxGe6uR5J4Cjdh_xYhBPoQRgeYwHPv5=AnuRmQKSD3yZrMK9Q-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> 2014-12-04 13:43 ` Robin Murphy 2014-12-04 13:43 ` Robin Murphy [not found] ` <54806504.20507-5wv7dgnIgG8@public.gmane.org> 2014-12-04 13:58 ` Grant Likely 2014-12-04 13:58 ` Grant Likely 2014-12-04 14:49 ` Thierry Reding 2014-12-04 14:49 ` Thierry Reding [not found] ` <20141204144925.GB31464-AwZRO8vwLAwmlAP/+Wk3EA@public.gmane.org> 2014-12-04 17:42 ` Robin Murphy 2014-12-04 17:42 ` Robin Murphy [not found] ` <54809D09.2050406-5wv7dgnIgG8@public.gmane.org> 2014-12-04 17:58 ` Grant Likely 2014-12-04 17:58 ` Grant Likely [not found] ` <CACxGe6tpFHdP1-5NWiNVAqzXx-diN1xfRbu0AQDyVJ6AU_4RXg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> 2014-12-04 19:42 ` Robin Murphy 2014-12-04 19:42 ` Robin Murphy [not found] ` <5480B924.2010205-5wv7dgnIgG8@public.gmane.org> 2014-12-05 12:10 ` Will Deacon 2014-12-05 12:10 ` Will Deacon [not found] ` <20141205121037.GI1630-5wv7dgnIgG8@public.gmane.org> 2014-12-05 12:21 ` Arnd Bergmann 2014-12-05 12:21 ` Arnd Bergmann 2014-12-05 12:35 ` Robin Murphy 2014-12-05 12:35 ` Robin Murphy [not found] ` <5481A688.4030606-5wv7dgnIgG8@public.gmane.org> 2014-12-05 13:06 ` Grant Likely 2014-12-05 13:06 ` Grant Likely [not found] ` <CACxGe6vppOQj-hJnqEEtLwDuSr4bzcbTgEFj8=x4ULu=yxswpg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> 2014-12-05 13:18 ` Thierry Reding 2014-12-05 13:18 ` Thierry Reding [not found] ` <20141205131815.GA18747-AwZRO8vwLAwmlAP/+Wk3EA@public.gmane.org> 2014-12-05 13:21 ` Grant Likely 2014-12-05 13:21 ` Grant Likely [not found] ` <CACxGe6vqstoCBiJ7TLvhNt+40TUJRB2ORoRKKtorhM-ETHXu0A-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> 2014-12-05 13:31 ` Thierry Reding 2014-12-05 13:31 ` Thierry Reding 2014-12-05 13:49 ` Marek Szyprowski 2014-12-05 13:49 ` Marek Szyprowski 2014-12-04 12:51 ` Arnd Bergmann 2014-12-04 12:51 ` Arnd Bergmann 2014-12-02 10:30 ` Pantelis Antoniou 2014-12-02 10:30 ` Pantelis Antoniou 2014-12-01 16:57 ` [PATCH v6 2/8] dma-mapping: replace set_arch_dma_coherent_ops with arch_setup_dma_ops Will Deacon 2014-12-01 16:57 ` Will Deacon [not found] ` <1417453034-21379-3-git-send-email-will.deacon-5wv7dgnIgG8@public.gmane.org> 2014-12-01 22:58 ` Rob Herring 2014-12-01 22:58 ` Rob Herring [not found] ` <CAL_JsqLtN3euwXHM4BzYxkXsgE=Dmn05aXzL+kr_8x23voneZA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> 2014-12-02 9:16 ` Arnd Bergmann 2014-12-02 9:16 ` Arnd Bergmann 2014-12-01 16:57 ` [PATCH v6 3/8] iommu: add new iommu_ops callback for adding an OF device Will Deacon 2014-12-01 16:57 ` Will Deacon 2014-12-01 16:57 ` [PATCH v6 4/8] iommu: provide helper function to configure an IOMMU for an of master Will Deacon 2014-12-01 16:57 ` Will Deacon 2014-12-01 16:57 ` [PATCH v6 5/8] iommu: fix initialization without 'add_device' callback Will Deacon 2014-12-01 16:57 ` Will Deacon 2014-12-01 16:57 ` [PATCH v6 6/8] dma-mapping: detect and configure IOMMU in of_dma_configure Will Deacon 2014-12-01 16:57 ` Will Deacon [not found] ` <1417453034-21379-7-git-send-email-will.deacon-5wv7dgnIgG8@public.gmane.org> 2014-12-01 23:06 ` Rob Herring 2014-12-01 23:06 ` Rob Herring 2014-12-10 14:52 ` Rob Clark 2014-12-10 14:52 ` Rob Clark [not found] ` <CAF6AEGs6dZauq1QxY_OqBPUs0xHYjjGTi+H7Vm-mNvJtmTAHRA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> 2014-12-10 15:08 ` Will Deacon 2014-12-10 15:08 ` Will Deacon [not found] ` <20141210150853.GH23639-5wv7dgnIgG8@public.gmane.org> 2014-12-10 15:54 ` Robin Murphy 2014-12-10 15:54 ` Robin Murphy [not found] ` <54886CA2.3040406-5wv7dgnIgG8@public.gmane.org> 2014-12-10 15:56 ` Laurent Pinchart 2014-12-10 15:56 ` Laurent Pinchart 2014-12-14 15:49 ` Laurent Pinchart 2014-12-14 15:49 ` Laurent Pinchart 2014-12-14 15:59 ` Laurent Pinchart 2014-12-14 15:59 ` Laurent Pinchart 2014-12-15 17:10 ` Will Deacon 2014-12-15 17:10 ` Will Deacon 2014-12-15 16:40 ` Will Deacon 2014-12-15 16:40 ` Will Deacon [not found] ` <20141215164041.GN20738-5wv7dgnIgG8@public.gmane.org> 2014-12-15 17:16 ` Laurent Pinchart 2014-12-15 17:16 ` Laurent Pinchart 2014-12-15 18:09 ` Will Deacon 2014-12-15 18:09 ` Will Deacon [not found] ` <20141215180933.GW20738-5wv7dgnIgG8@public.gmane.org> 2014-12-16 12:08 ` Arnd Bergmann 2014-12-16 12:08 ` Arnd Bergmann 2014-12-17 12:09 ` Will Deacon 2014-12-17 12:09 ` Will Deacon [not found] ` <20141217120948.GB870-5wv7dgnIgG8@public.gmane.org> 2014-12-17 14:15 ` Arnd Bergmann 2014-12-17 14:15 ` Arnd Bergmann 2014-12-17 14:45 ` Will Deacon 2014-12-17 14:45 ` Will Deacon 2014-12-17 15:35 ` Arnd Bergmann [this message] 2014-12-17 15:35 ` Arnd Bergmann 2014-12-17 17:17 ` Will Deacon 2014-12-17 17:17 ` Will Deacon [not found] ` <20141217171752.GB30307-5wv7dgnIgG8@public.gmane.org> 2014-12-17 19:48 ` Arnd Bergmann 2014-12-17 19:48 ` Arnd Bergmann 2014-12-21 10:04 ` Will Deacon 2014-12-21 10:04 ` Will Deacon [not found] ` <20141221100451.GA23242-5wv7dgnIgG8@public.gmane.org> 2014-12-22 13:36 ` Arnd Bergmann 2014-12-22 13:36 ` Arnd Bergmann 2015-01-07 18:57 ` Will Deacon 2015-01-07 18:57 ` Will Deacon [not found] ` <20150107185704.GV7485-5wv7dgnIgG8@public.gmane.org> 2015-01-07 19:29 ` Arnd Bergmann 2015-01-07 19:29 ` Arnd Bergmann 2015-01-08 10:53 ` Will Deacon 2015-01-08 10:53 ` Will Deacon 2014-12-17 14:27 ` Robin Murphy 2014-12-17 14:27 ` Robin Murphy [not found] ` <549192D2.10008-5wv7dgnIgG8@public.gmane.org> 2014-12-17 15:01 ` Will Deacon 2014-12-17 15:01 ` Will Deacon [not found] ` <20141217150158.GF870-5wv7dgnIgG8@public.gmane.org> 2014-12-17 15:38 ` Arnd Bergmann 2014-12-17 15:38 ` Arnd Bergmann 2014-12-17 17:20 ` Will Deacon 2014-12-17 17:20 ` Will Deacon 2014-12-17 0:05 ` Laurent Pinchart 2014-12-17 0:05 ` Laurent Pinchart 2014-12-14 15:51 ` Laurent Pinchart 2014-12-14 15:51 ` Laurent Pinchart 2014-12-15 11:32 ` Will Deacon 2014-12-15 11:32 ` Will Deacon [not found] ` <20141215113252.GH20738-5wv7dgnIgG8@public.gmane.org> 2014-12-17 0:19 ` Laurent Pinchart 2014-12-17 0:19 ` Laurent Pinchart 2014-12-17 11:14 ` Will Deacon 2014-12-17 11:14 ` Will Deacon 2014-12-01 16:57 ` [PATCH v6 7/8] arm: call iommu_init before of_platform_populate Will Deacon 2014-12-01 16:57 ` Will Deacon 2014-12-01 16:57 ` [PATCH v6 8/8] arm: dma-mapping: plumb our iommu mapping ops into arch_setup_dma_ops Will Deacon 2014-12-01 16:57 ` Will Deacon [not found] ` <1417453034-21379-9-git-send-email-will.deacon-5wv7dgnIgG8@public.gmane.org> 2015-01-14 9:00 ` Alexandre Courbot 2015-01-14 9:00 ` Alexandre Courbot [not found] ` <54B63028.3090701-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org> 2015-01-14 10:46 ` Will Deacon 2015-01-14 10:46 ` Will Deacon 2015-01-14 13:51 ` Heiko Stübner 2015-01-14 13:51 ` Heiko Stübner 2015-01-14 19:17 ` Will Deacon 2015-01-14 19:17 ` Will Deacon [not found] ` <20150114191749.GL4050-5wv7dgnIgG8@public.gmane.org> 2015-01-15 8:30 ` Thierry Reding 2015-01-15 8:30 ` Thierry Reding 2015-01-15 11:13 ` Will Deacon 2015-01-15 11:13 ` Will Deacon [not found] ` <20150114104610.GC4050-5wv7dgnIgG8@public.gmane.org> 2015-01-15 2:57 ` Alexandre Courbot 2015-01-15 2:57 ` Alexandre Courbot 2015-01-15 8:28 ` Thierry Reding 2015-01-15 8:28 ` Thierry Reding 2015-01-15 11:12 ` Will Deacon 2015-01-15 11:12 ` Will Deacon [not found] ` <20150115111211.GF23475-5wv7dgnIgG8@public.gmane.org> 2015-01-15 23:18 ` Laurent Pinchart 2015-01-15 23:18 ` Laurent Pinchart 2015-01-18 6:54 ` Alexandre Courbot 2015-01-18 6:54 ` Alexandre Courbot [not found] ` <54BB58AA.5070407-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org> 2015-01-18 11:18 ` Laurent Pinchart 2015-01-18 11:18 ` Laurent Pinchart 2015-01-19 11:12 ` Will Deacon 2015-01-19 11:12 ` Will Deacon [not found] ` <20150119111202.GD32131-5wv7dgnIgG8@public.gmane.org> 2015-01-19 11:34 ` Laurent Pinchart 2015-01-19 11:34 ` Laurent Pinchart 2015-01-19 12:31 ` Thierry Reding 2015-01-19 12:31 ` Thierry Reding [not found] ` <20150119123058.GA7312-AwZRO8vwLAwmlAP/+Wk3EA@public.gmane.org> 2015-01-20 15:14 ` Laurent Pinchart 2015-01-20 15:14 ` Laurent Pinchart 2015-01-20 15:19 ` Will Deacon 2015-01-20 15:19 ` Will Deacon [not found] ` <20150120151910.GD1549-5wv7dgnIgG8@public.gmane.org> 2015-01-20 15:21 ` Will Deacon 2015-01-20 15:21 ` Will Deacon 2015-01-20 15:35 ` Laurent Pinchart 2015-01-20 15:35 ` Laurent Pinchart 2015-01-19 12:43 ` Thierry Reding 2015-01-19 12:43 ` Thierry Reding [not found] ` <20150119124305.GC7312-AwZRO8vwLAwmlAP/+Wk3EA@public.gmane.org> 2015-01-19 12:50 ` Will Deacon 2015-01-19 12:50 ` Will Deacon [not found] ` <20150119125051.GI32131-5wv7dgnIgG8@public.gmane.org> 2015-01-19 13:36 ` Thierry Reding 2015-01-19 13:36 ` Thierry Reding [not found] ` <20150119133633.GA23778-AwZRO8vwLAwmlAP/+Wk3EA@public.gmane.org> 2015-01-20 13:50 ` Laurent Pinchart 2015-01-20 13:50 ` Laurent Pinchart 2015-01-19 16:13 ` Arnd Bergmann 2015-01-19 16:13 ` Arnd Bergmann 2015-01-20 16:41 ` Laurent Pinchart 2015-01-20 16:41 ` Laurent Pinchart 2015-01-19 12:36 ` Thierry Reding 2015-01-19 12:36 ` Thierry Reding [not found] ` <20150119123623.GB7312-AwZRO8vwLAwmlAP/+Wk3EA@public.gmane.org> 2015-01-19 15:52 ` Arnd Bergmann 2015-01-19 15:52 ` Arnd Bergmann 2015-01-19 16:21 ` Thierry Reding 2015-01-19 16:21 ` Thierry Reding [not found] ` <20150119162111.GA7751-AwZRO8vwLAwmlAP/+Wk3EA@public.gmane.org> 2015-01-19 17:02 ` Arnd Bergmann 2015-01-19 17:02 ` Arnd Bergmann 2015-01-20 13:47 ` Laurent Pinchart 2015-01-20 13:47 ` Laurent Pinchart 2015-01-19 12:49 ` Thierry Reding 2015-01-19 12:49 ` Thierry Reding [not found] ` <20150119124934.GD7312-AwZRO8vwLAwmlAP/+Wk3EA@public.gmane.org> 2015-01-20 14:05 ` Laurent Pinchart 2015-01-20 14:05 ` Laurent Pinchart 2014-12-05 7:12 ` [PATCH v6 0/8] Introduce automatic DMA configuration for IOMMU masters Olof Johansson 2014-12-05 7:12 ` Olof Johansson [not found] ` <CAOesGMg9BpL3AyDjuAvH_H5fOm-uga+_CZuJZ5p8zpHpJLg0qA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> 2014-12-05 12:11 ` Will Deacon 2014-12-05 12:11 ` Will Deacon 2014-12-15 0:24 ` [PATCH/RFC] iommu/ipmmu-vmsa: Use DT-based instantiation Laurent Pinchart 2014-12-15 0:24 ` Laurent Pinchart
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=2299294.lPnEQgl4lK@wuerfel \ --to=arnd@arndb.de \ --cc=Varun.Sethi@freescale.com \ --cc=dwmw2@infradead.org \ --cc=iommu@lists.linux-foundation.org \ --cc=jroedel@suse.de \ --cc=laurent.pinchart@ideasonboard.com \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=robdclark@gmail.com \ --cc=thierry.reding@gmail.com \ --cc=will.deacon@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: linkBe 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.