All of lore.kernel.org
 help / color / mirror / Atom feed
From: Catalin Marinas <catalin.marinas@arm.com>
To: Murali Karicheri <m-karicheri2@ti.com>
Cc: Robin Murphy <Robin.Murphy@arm.com>,
	"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
	Russell King <linux@arm.linux.org.uk>,
	Arnd Bergmann <arnd@arndb.de>,
	"linux-pci@vger.kernel.org" <linux-pci@vger.kernel.org>,
	Joerg Roedel <joro@8bytes.org>, Will Deacon <Will.Deacon@arm.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"grant.likely@linaro.org" <grant.likely@linaro.org>,
	"iommu@lists.linux-foundation.org"
	<iommu@lists.linux-foundation.org>,
	Rob Herring <robh+dt@kernel.org>,
	"suravee.suthikulpanit@amd.com" <suravee.suthikulpanit@amd.com>,
	Bjorn Helgaas <bhelgaas@google.com>,
	"linux-arm-kernel@lists.infradead.org" 
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: [PATCH v4 3/6] of: fix size when dma-range is not used
Date: Thu, 5 Feb 2015 22:44:40 +0000	[thread overview]
Message-ID: <20150205224439.GA19250@e104818-lin.cambridge.arm.com> (raw)
In-Reply-To: <54D3E3C3.1040104@ti.com>

Murali,

On Thu, Feb 05, 2015 at 09:42:27PM +0000, Murali Karicheri wrote:
> On 02/02/2015 07:18 AM, Catalin Marinas wrote:
> > On Fri, Jan 30, 2015 at 06:06:27PM +0000, Murali Karicheri wrote:
> >> On 01/28/2015 12:30 PM, Catalin Marinas wrote:
> >>> I think we can remove this check altogether (we leaved without it for a
> >>> while) but we need to add 1 when calculating the mask:
> >>>
> >>> 	dev->coherent_dma_mask = min(DMA_BIT_MASK(32),
> >>> 				     DMA_BIT_MASK(ilog2(size + 1)));
> >>>
> >> For Keystone, the dma_addr is to be taken care as well to determine the
> >> mask. The above will not work.
> >
> > This was discussed before (not on this thread) and dma_addr should not
> > affect the mask, it only affects the pfn offset.
> >
> >> Based on the discussion so far, this is the function I have come up with
> >> incorporating the suggestions. Please review this and see if I have
> >> missed out any. This works fine on Keystone.
> >>
> >> void of_dma_configure(struct device *dev, struct device_node *np)
> >> {
> >> 	u64 dma_addr = 0, paddr, size;
> >> 	int ret;
> >> 	bool coherent;
> >> 	unsigned long offset = 0;
> >> 	struct iommu_ops *iommu;
> >>
> >> 	/*
> >> 	 * Set default size to cover the 32-bit. Drivers are expected to setup
> >> 	 * the correct size and dma_mask.
> >>     	 */
> >> 	size = 1ULL<<  32;
> >>
> >> 	ret = of_dma_get_range(np,&dma_addr,&paddr,&size);
> >> 	if (!ret) {
> >> 		offset = PFN_DOWN(paddr - dma_addr);
> >> 		if (!size) {
> >> 			dev_err(dev, "Invalid size (%llx)\n",
> >> 				size);
> >> 			return;
> >> 		}
> >> 		if (size&  1) {
> >> 			size = size + 1;
> >> 			dev_warn(dev, "Incorrect usage of size (%llx)\n",
> >> 				 size);
> >> 		}
> >> 		dev_dbg(dev, "dma_pfn_offset(%#08lx)\n", offset);
> >> 	}
> >> 	dev->dma_pfn_offset = offset;
> >>
> >> 	/*
> >> 	 * Coherent DMA masks larger than 32-bit must be explicitly set by the
> >> 	 * driver.
> >> 	 */
> >> 	dev->coherent_dma_mask = min(DMA_BIT_MASK(32),
> >> 				     DMA_BIT_MASK(ilog2(dma_addr + size)));
> >
> > That's not correct, coherent_dma_mask should still be calculated solely
> > based on size, not dma_addr.
> >
> > Functions like swiotlb_dma_supported() use phys_to_dma() which on ARM
> > (32-bit) subtracts the dma_pfn_offset, so the mask based on size works
> > fine.
> >
> > In the arm64 tree, we haven't taken dma_pfn_offset into account for
> > phys_to_dma() yet but if needed for a SoC, we'll add it.
> 
> The size based dma mask calculation itself can be a separate topic 
> patch. This series is adding important fix to get the PCI driver 
> functional and I would like to get this merged as soon as possible.

Well as long as you don't break the existing users of
of_dma_configure() ;).

> I also want to hear from Arnd about yout comment as we had discussed
> this in the initial discussion of this patch series and 8/8 is
> essentially added based on that discussion. I will add a simple check
> to catch and warn the incorrect size setting in DT for dma-range as
> suggested by Rob Herring and create a new patch to for size based mask
> calculation. I will be sending v6 (expected to be merged soon) today
> and will work to add a new patch. Before that we need to agree on what
> is the content of the patch.
> 
> 1. On keystone, DMA address start at 0x8000_0000 and DMA-able memory is 
> 2G from the above base address. So without taking into account the
> dma_addr, mask calculated will be 0x7fff_ffff where as we need that to 
> be 0xffff_ffff for keystone. So need to use this in the calculation.

Ah, you are right. I confused dma_addr in your patch with the offset.

> 2. W.r.t arm_pfn_offset, this was added to support Keystone as the DDR 
> physical address for LPAE startes at 0x8_0000_0000 and the pfn offset is 
> calculated as the PFN of (0x8_0000_0000 - 0x8000_0000) to do the dma 
> address to DDR address translation.

Indeed.

I'll look at your patches again tomorrow.

-- 
Catalin

WARNING: multiple messages have this Message-ID (diff)
From: Catalin Marinas <catalin.marinas-5wv7dgnIgG8@public.gmane.org>
To: Murali Karicheri <m-karicheri2-l0cyMroinI0@public.gmane.org>
Cc: "devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
	<devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
	Russell King <linux-lFZ/pmaqli7XmaaqVzeoHQ@public.gmane.org>,
	Arnd Bergmann <arnd-r2nGTMty4D4@public.gmane.org>,
	"linux-pci-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
	<linux-pci-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
	Will Deacon <Will.Deacon-5wv7dgnIgG8@public.gmane.org>,
	"linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
	<linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
	Bjorn Helgaas <bhelgaas-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>,
	"iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org"
	<iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org>,
	Rob Herring <robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>,
	"grant.likely-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org"
	<grant.likely-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>,
	"linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org"
	<linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org>
Subject: Re: [PATCH v4 3/6] of: fix size when dma-range is not used
Date: Thu, 5 Feb 2015 22:44:40 +0000	[thread overview]
Message-ID: <20150205224439.GA19250@e104818-lin.cambridge.arm.com> (raw)
In-Reply-To: <54D3E3C3.1040104-l0cyMroinI0@public.gmane.org>

Murali,

On Thu, Feb 05, 2015 at 09:42:27PM +0000, Murali Karicheri wrote:
> On 02/02/2015 07:18 AM, Catalin Marinas wrote:
> > On Fri, Jan 30, 2015 at 06:06:27PM +0000, Murali Karicheri wrote:
> >> On 01/28/2015 12:30 PM, Catalin Marinas wrote:
> >>> I think we can remove this check altogether (we leaved without it for a
> >>> while) but we need to add 1 when calculating the mask:
> >>>
> >>> 	dev->coherent_dma_mask = min(DMA_BIT_MASK(32),
> >>> 				     DMA_BIT_MASK(ilog2(size + 1)));
> >>>
> >> For Keystone, the dma_addr is to be taken care as well to determine the
> >> mask. The above will not work.
> >
> > This was discussed before (not on this thread) and dma_addr should not
> > affect the mask, it only affects the pfn offset.
> >
> >> Based on the discussion so far, this is the function I have come up with
> >> incorporating the suggestions. Please review this and see if I have
> >> missed out any. This works fine on Keystone.
> >>
> >> void of_dma_configure(struct device *dev, struct device_node *np)
> >> {
> >> 	u64 dma_addr = 0, paddr, size;
> >> 	int ret;
> >> 	bool coherent;
> >> 	unsigned long offset = 0;
> >> 	struct iommu_ops *iommu;
> >>
> >> 	/*
> >> 	 * Set default size to cover the 32-bit. Drivers are expected to setup
> >> 	 * the correct size and dma_mask.
> >>     	 */
> >> 	size = 1ULL<<  32;
> >>
> >> 	ret = of_dma_get_range(np,&dma_addr,&paddr,&size);
> >> 	if (!ret) {
> >> 		offset = PFN_DOWN(paddr - dma_addr);
> >> 		if (!size) {
> >> 			dev_err(dev, "Invalid size (%llx)\n",
> >> 				size);
> >> 			return;
> >> 		}
> >> 		if (size&  1) {
> >> 			size = size + 1;
> >> 			dev_warn(dev, "Incorrect usage of size (%llx)\n",
> >> 				 size);
> >> 		}
> >> 		dev_dbg(dev, "dma_pfn_offset(%#08lx)\n", offset);
> >> 	}
> >> 	dev->dma_pfn_offset = offset;
> >>
> >> 	/*
> >> 	 * Coherent DMA masks larger than 32-bit must be explicitly set by the
> >> 	 * driver.
> >> 	 */
> >> 	dev->coherent_dma_mask = min(DMA_BIT_MASK(32),
> >> 				     DMA_BIT_MASK(ilog2(dma_addr + size)));
> >
> > That's not correct, coherent_dma_mask should still be calculated solely
> > based on size, not dma_addr.
> >
> > Functions like swiotlb_dma_supported() use phys_to_dma() which on ARM
> > (32-bit) subtracts the dma_pfn_offset, so the mask based on size works
> > fine.
> >
> > In the arm64 tree, we haven't taken dma_pfn_offset into account for
> > phys_to_dma() yet but if needed for a SoC, we'll add it.
> 
> The size based dma mask calculation itself can be a separate topic 
> patch. This series is adding important fix to get the PCI driver 
> functional and I would like to get this merged as soon as possible.

Well as long as you don't break the existing users of
of_dma_configure() ;).

> I also want to hear from Arnd about yout comment as we had discussed
> this in the initial discussion of this patch series and 8/8 is
> essentially added based on that discussion. I will add a simple check
> to catch and warn the incorrect size setting in DT for dma-range as
> suggested by Rob Herring and create a new patch to for size based mask
> calculation. I will be sending v6 (expected to be merged soon) today
> and will work to add a new patch. Before that we need to agree on what
> is the content of the patch.
> 
> 1. On keystone, DMA address start at 0x8000_0000 and DMA-able memory is 
> 2G from the above base address. So without taking into account the
> dma_addr, mask calculated will be 0x7fff_ffff where as we need that to 
> be 0xffff_ffff for keystone. So need to use this in the calculation.

Ah, you are right. I confused dma_addr in your patch with the offset.

> 2. W.r.t arm_pfn_offset, this was added to support Keystone as the DDR 
> physical address for LPAE startes at 0x8_0000_0000 and the pfn offset is 
> calculated as the PFN of (0x8_0000_0000 - 0x8000_0000) to do the dma 
> address to DDR address translation.

Indeed.

I'll look at your patches again tomorrow.

-- 
Catalin

WARNING: multiple messages have this Message-ID (diff)
From: catalin.marinas@arm.com (Catalin Marinas)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v4 3/6] of: fix size when dma-range is not used
Date: Thu, 5 Feb 2015 22:44:40 +0000	[thread overview]
Message-ID: <20150205224439.GA19250@e104818-lin.cambridge.arm.com> (raw)
In-Reply-To: <54D3E3C3.1040104@ti.com>

Murali,

On Thu, Feb 05, 2015 at 09:42:27PM +0000, Murali Karicheri wrote:
> On 02/02/2015 07:18 AM, Catalin Marinas wrote:
> > On Fri, Jan 30, 2015 at 06:06:27PM +0000, Murali Karicheri wrote:
> >> On 01/28/2015 12:30 PM, Catalin Marinas wrote:
> >>> I think we can remove this check altogether (we leaved without it for a
> >>> while) but we need to add 1 when calculating the mask:
> >>>
> >>> 	dev->coherent_dma_mask = min(DMA_BIT_MASK(32),
> >>> 				     DMA_BIT_MASK(ilog2(size + 1)));
> >>>
> >> For Keystone, the dma_addr is to be taken care as well to determine the
> >> mask. The above will not work.
> >
> > This was discussed before (not on this thread) and dma_addr should not
> > affect the mask, it only affects the pfn offset.
> >
> >> Based on the discussion so far, this is the function I have come up with
> >> incorporating the suggestions. Please review this and see if I have
> >> missed out any. This works fine on Keystone.
> >>
> >> void of_dma_configure(struct device *dev, struct device_node *np)
> >> {
> >> 	u64 dma_addr = 0, paddr, size;
> >> 	int ret;
> >> 	bool coherent;
> >> 	unsigned long offset = 0;
> >> 	struct iommu_ops *iommu;
> >>
> >> 	/*
> >> 	 * Set default size to cover the 32-bit. Drivers are expected to setup
> >> 	 * the correct size and dma_mask.
> >>     	 */
> >> 	size = 1ULL<<  32;
> >>
> >> 	ret = of_dma_get_range(np,&dma_addr,&paddr,&size);
> >> 	if (!ret) {
> >> 		offset = PFN_DOWN(paddr - dma_addr);
> >> 		if (!size) {
> >> 			dev_err(dev, "Invalid size (%llx)\n",
> >> 				size);
> >> 			return;
> >> 		}
> >> 		if (size&  1) {
> >> 			size = size + 1;
> >> 			dev_warn(dev, "Incorrect usage of size (%llx)\n",
> >> 				 size);
> >> 		}
> >> 		dev_dbg(dev, "dma_pfn_offset(%#08lx)\n", offset);
> >> 	}
> >> 	dev->dma_pfn_offset = offset;
> >>
> >> 	/*
> >> 	 * Coherent DMA masks larger than 32-bit must be explicitly set by the
> >> 	 * driver.
> >> 	 */
> >> 	dev->coherent_dma_mask = min(DMA_BIT_MASK(32),
> >> 				     DMA_BIT_MASK(ilog2(dma_addr + size)));
> >
> > That's not correct, coherent_dma_mask should still be calculated solely
> > based on size, not dma_addr.
> >
> > Functions like swiotlb_dma_supported() use phys_to_dma() which on ARM
> > (32-bit) subtracts the dma_pfn_offset, so the mask based on size works
> > fine.
> >
> > In the arm64 tree, we haven't taken dma_pfn_offset into account for
> > phys_to_dma() yet but if needed for a SoC, we'll add it.
> 
> The size based dma mask calculation itself can be a separate topic 
> patch. This series is adding important fix to get the PCI driver 
> functional and I would like to get this merged as soon as possible.

Well as long as you don't break the existing users of
of_dma_configure() ;).

> I also want to hear from Arnd about yout comment as we had discussed
> this in the initial discussion of this patch series and 8/8 is
> essentially added based on that discussion. I will add a simple check
> to catch and warn the incorrect size setting in DT for dma-range as
> suggested by Rob Herring and create a new patch to for size based mask
> calculation. I will be sending v6 (expected to be merged soon) today
> and will work to add a new patch. Before that we need to agree on what
> is the content of the patch.
> 
> 1. On keystone, DMA address start at 0x8000_0000 and DMA-able memory is 
> 2G from the above base address. So without taking into account the
> dma_addr, mask calculated will be 0x7fff_ffff where as we need that to 
> be 0xffff_ffff for keystone. So need to use this in the calculation.

Ah, you are right. I confused dma_addr in your patch with the offset.

> 2. W.r.t arm_pfn_offset, this was added to support Keystone as the DDR 
> physical address for LPAE startes at 0x8_0000_0000 and the pfn offset is 
> calculated as the PFN of (0x8_0000_0000 - 0x8000_0000) to do the dma 
> address to DDR address translation.

Indeed.

I'll look at your patches again tomorrow.

-- 
Catalin

  reply	other threads:[~2015-02-05 22:44 UTC|newest]

Thread overview: 159+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-01-23 22:32 [PATCH v4 0/6] PCI: get DMA configuration from parent device Murali Karicheri
2015-01-23 22:32 ` Murali Karicheri
2015-01-23 22:32 ` Murali Karicheri
2015-01-23 22:32 ` [PATCH v4 1/6] of: iommu: add ptr to OF node arg to of_iommu_configure() Murali Karicheri
2015-01-23 22:32   ` Murali Karicheri
2015-01-23 22:32   ` Murali Karicheri
2015-01-25 13:32   ` Laurent Pinchart
2015-01-25 13:32     ` Laurent Pinchart
2015-01-25 13:32     ` Laurent Pinchart
2015-01-26 18:49     ` Murali Karicheri
2015-01-26 18:49       ` Murali Karicheri
2015-01-26 18:49       ` Murali Karicheri
2015-01-28 11:33       ` Will Deacon
2015-01-28 11:33         ` Will Deacon
2015-01-28 11:33         ` Will Deacon
2015-01-28 11:33         ` Will Deacon
2015-01-28 12:23         ` Laurent Pinchart
2015-01-28 12:23           ` Laurent Pinchart
2015-01-28 12:23           ` Laurent Pinchart
2015-01-28 12:23           ` Laurent Pinchart
2015-01-28 12:29           ` Will Deacon
2015-01-28 12:29             ` Will Deacon
2015-01-28 12:29             ` Will Deacon
2015-01-28 12:29             ` Will Deacon
2015-01-28 13:15             ` Laurent Pinchart
2015-01-28 13:15               ` Laurent Pinchart
2015-01-28 13:15               ` Laurent Pinchart
2015-01-28 13:15               ` Laurent Pinchart
2015-01-28 13:32               ` Will Deacon
2015-01-28 13:32                 ` Will Deacon
2015-01-28 13:32                 ` Will Deacon
2015-01-28 13:32                 ` Will Deacon
2015-01-28 15:21                 ` Murali Karicheri
2015-01-28 15:21                   ` Murali Karicheri
2015-01-28 15:21                   ` Murali Karicheri
2015-01-28 15:21                   ` Murali Karicheri
2015-01-28 23:32                 ` Laurent Pinchart
2015-01-28 23:32                   ` Laurent Pinchart
2015-01-28 23:32                   ` Laurent Pinchart
2015-01-28 23:32                   ` Laurent Pinchart
2015-01-29 14:59                   ` Murali Karicheri
2015-01-29 14:59                     ` Murali Karicheri
2015-01-29 14:59                     ` Murali Karicheri
2015-01-29 14:59                     ` Murali Karicheri
2015-01-29 16:49                   ` Rob Herring
2015-01-29 16:49                     ` Rob Herring
2015-01-29 16:49                     ` Rob Herring
2015-01-29 16:49                     ` Rob Herring
2015-01-30  0:24                     ` Laurent Pinchart
2015-01-30  0:24                       ` Laurent Pinchart
2015-01-30  0:24                       ` Laurent Pinchart
2015-01-30  0:24                       ` Laurent Pinchart
2015-01-30 15:23                       ` Murali Karicheri
2015-01-30 15:23                         ` Murali Karicheri
2015-01-30 15:23                         ` Murali Karicheri
2015-01-30 15:23                         ` Murali Karicheri
2015-01-23 22:32 ` [PATCH v4 2/6] of: move of_dma_configure() to device.c to help re-use Murali Karicheri
2015-01-23 22:32   ` Murali Karicheri
2015-01-23 22:32   ` Murali Karicheri
2015-01-23 22:32 ` [PATCH v4 3/6] of: fix size when dma-range is not used Murali Karicheri
2015-01-23 22:32   ` Murali Karicheri
2015-01-23 22:32   ` Murali Karicheri
2015-01-27 11:27   ` Robin Murphy
2015-01-27 11:27     ` Robin Murphy
2015-01-27 11:27     ` Robin Murphy
2015-01-27 15:44     ` Murali Karicheri
2015-01-27 15:44       ` Murali Karicheri
2015-01-27 15:44       ` Murali Karicheri
2015-01-27 18:55     ` Murali Karicheri
2015-01-27 18:55       ` Murali Karicheri
2015-01-27 18:55       ` Murali Karicheri
2015-01-27 18:55       ` Murali Karicheri
2015-01-28 11:05       ` Catalin Marinas
2015-01-28 11:05         ` Catalin Marinas
2015-01-28 11:05         ` Catalin Marinas
2015-01-28 11:05         ` Catalin Marinas
2015-01-28 15:45         ` Rob Herring
2015-01-28 15:45           ` Rob Herring
2015-01-28 15:45           ` Rob Herring
2015-01-28 15:45           ` Rob Herring
2015-01-28 17:23           ` Catalin Marinas
2015-01-28 17:23             ` Catalin Marinas
2015-01-28 17:23             ` Catalin Marinas
2015-01-28 17:23             ` Catalin Marinas
2015-01-28 17:34           ` Murali Karicheri
2015-01-28 17:34             ` Murali Karicheri
2015-01-28 17:34             ` Murali Karicheri
2015-01-28 17:34             ` Murali Karicheri
2015-01-28 15:55         ` Robin Murphy
2015-01-28 15:55           ` Robin Murphy
2015-01-28 15:55           ` Robin Murphy
2015-01-28 15:55           ` Robin Murphy
2015-01-28 17:30           ` Catalin Marinas
2015-01-28 17:30             ` Catalin Marinas
2015-01-28 17:30             ` Catalin Marinas
2015-01-28 17:30             ` Catalin Marinas
2015-01-30 18:06             ` Murali Karicheri
2015-01-30 18:06               ` Murali Karicheri
2015-01-30 18:06               ` Murali Karicheri
2015-02-02 12:18               ` Catalin Marinas
2015-02-02 12:18                 ` Catalin Marinas
2015-02-02 12:18                 ` Catalin Marinas
2015-02-02 12:18                 ` Catalin Marinas
2015-02-02 16:10                 ` Murali Karicheri
2015-02-02 16:10                   ` Murali Karicheri
2015-02-02 16:10                   ` Murali Karicheri
2015-02-02 16:10                   ` Murali Karicheri
2015-02-05 21:42                 ` Murali Karicheri
2015-02-05 21:42                   ` Murali Karicheri
2015-02-05 21:42                   ` Murali Karicheri
2015-02-05 22:44                   ` Catalin Marinas [this message]
2015-02-05 22:44                     ` Catalin Marinas
2015-02-05 22:44                     ` Catalin Marinas
2015-02-05 22:44                     ` Catalin Marinas
2015-01-23 22:32 ` [PATCH v4 4/6] of/pci: add of_pci_dma_configure() update dma configuration Murali Karicheri
2015-01-23 22:32   ` Murali Karicheri
2015-01-23 22:32   ` Murali Karicheri
2015-01-23 23:41   ` Bjorn Helgaas
2015-01-23 23:41     ` Bjorn Helgaas
2015-01-23 23:41     ` Bjorn Helgaas
2015-01-26 23:25     ` Murali Karicheri
2015-01-26 23:25       ` Murali Karicheri
2015-01-26 23:25       ` Murali Karicheri
2015-01-26 23:59       ` Bjorn Helgaas
2015-01-26 23:59         ` Bjorn Helgaas
2015-01-26 23:59         ` Bjorn Helgaas
2015-01-27 18:14         ` Murali Karicheri
2015-01-27 18:14           ` Murali Karicheri
2015-01-27 18:14           ` Murali Karicheri
2015-01-27 18:42           ` Bjorn Helgaas
2015-01-27 18:42             ` Bjorn Helgaas
2015-01-27 18:42             ` Bjorn Helgaas
2015-01-27 18:45             ` Murali Karicheri
2015-01-27 18:45               ` Murali Karicheri
2015-01-27 18:45               ` Murali Karicheri
2015-01-23 22:32 ` [PATCH v4 5/6] PCI: update dma configuration from DT Murali Karicheri
2015-01-23 22:32   ` Murali Karicheri
2015-01-23 22:32   ` Murali Karicheri
2015-01-23 23:27   ` Bjorn Helgaas
2015-01-23 23:27     ` Bjorn Helgaas
2015-01-23 23:27     ` Bjorn Helgaas
2015-01-26 23:28     ` Murali Karicheri
2015-01-26 23:28       ` Murali Karicheri
2015-01-26 23:28       ` Murali Karicheri
2015-01-23 22:32 ` [PATCH v4 6/6] arm: dma-mapping: updates to limit dma_mask and iommu mapping size Murali Karicheri
2015-01-23 22:32   ` Murali Karicheri
2015-01-23 22:32   ` Murali Karicheri
2015-01-27 11:12   ` Robin Murphy
2015-01-27 11:12     ` Robin Murphy
2015-01-27 11:12     ` Robin Murphy
2015-01-27 11:12     ` Robin Murphy
2015-01-27 11:34     ` Catalin Marinas
2015-01-27 11:34       ` Catalin Marinas
2015-01-27 11:34       ` Catalin Marinas
2015-01-27 11:34       ` Catalin Marinas
2015-01-27 15:19       ` Murali Karicheri
2015-01-27 15:19         ` Murali Karicheri
2015-01-27 15:19         ` Murali Karicheri
2015-01-27 15:19         ` 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=20150205224439.GA19250@e104818-lin.cambridge.arm.com \
    --to=catalin.marinas@arm.com \
    --cc=Robin.Murphy@arm.com \
    --cc=Will.Deacon@arm.com \
    --cc=arnd@arndb.de \
    --cc=bhelgaas@google.com \
    --cc=devicetree@vger.kernel.org \
    --cc=grant.likely@linaro.org \
    --cc=iommu@lists.linux-foundation.org \
    --cc=joro@8bytes.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=linux@arm.linux.org.uk \
    --cc=m-karicheri2@ti.com \
    --cc=robh+dt@kernel.org \
    --cc=suravee.suthikulpanit@amd.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: 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.