Hi,
On 01/13/2015 01:09 AM, Javier Martinez Canillas wrote:
> Hello Joonyoung,
>
> On 01/12/2015 07:40 AM, Joonyoung Shim wrote:
>>> And also making changes to the clocks in the clk-exynos5420 driver. Can
>>> you please explain the rationale for those changes? I'm asking because
>>> without your
On 01/12/2015 11:18 PM, Joerg Roedel wrote:
On Mon, Jan 12, 2015 at 03:06:19PM +0800, Li, Zhen-Hua wrote:
Allow specification of the domain-id for the new domain.
This patch only adds the 'did' parameter to iommu_attach_domain()
and modifies all of its callers to specify the default value of -1
> -Original Message-
> From: Paolo Bonzini [mailto:pbonz...@redhat.com]
> Sent: Friday, January 09, 2015 10:56 PM
> To: Radim Krčmář; Wu, Feng
> Cc: t...@linutronix.de; mi...@redhat.com; h...@zytor.com; x...@kernel.org;
> g...@kernel.org; dw...@infradead.org; j...@8bytes.org;
> alex.willi
Taking some inspiration from the arch/arm code, implement the
arch-specific side of the DMA mapping ops using the new IOMMU-DMA layer.
Signed-off-by: Robin Murphy
---
arch/arm64/include/asm/device.h | 3 +
arch/arm64/include/asm/dma-mapping.h | 12 ++
arch/arm64/mm/dma-mapping.c
Add the necessary call to of_iommu_init.
Signed-off-by: Robin Murphy
---
arch/arm64/kernel/setup.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm64/kernel/setup.c b/arch/arm64/kernel/setup.c
index b809911..8304141 100644
--- a/arch/arm64/kernel/setup.c
+++ b/arch/arm64/kernel/set
Taking inspiration from the existing arch/arm code, break out some
generic functions to interface the DMA-API to the IOMMU-API. This will
do the bulk of the heavy lifting for IOMMU-backed dma-mapping.
Whilst the target is arm64, rather than introduce yet another private
implementation, place this
From: Catalin Marinas
Since dev_archdata now has a dma_coherent state, combine the two
coherent and non-coherent operations and remove their declaration,
together with set_dma_ops, from the arch dma-mapping.h file.
Signed-off-by: Catalin Marinas
---
arch/arm64/include/asm/dma-mapping.h | 11 +
With iommu_dma_ops in place, hook them up to the configuration code, so
IOMMU-fronted devices will get them automatically.
Signed-off-by: Robin Murphy
---
arch/arm64/Kconfig | 1 +
arch/arm64/include/asm/dma-mapping.h | 10 +-
arch/arm64/mm/dma-mapping.c | 22
Hi all,
Whilst it's a long way off perfect, this has reached the point of being
functional and stable enough to be useful, so here it is. The core
consists of the meat of the arch/arm implementation modified to remove
the assumption of PAGE_SIZE pages and ported over to the Intel IOVA
allocator in
To share the IOVA allocator with other architectures, it needs to
accommodate more general aperture restrictions; move the lower limit
from a compile-time constant to a runtime domain property to allow
IOVA domains with different requirements to co-exist.
Also reword the slightly unclear descripti
In order to share the IOVA allocator with other architectures, break
the unnecssary dependency on the Intel IOMMU driver and move the
remaining IOVA internals to iova.c
Signed-off-by: Robin Murphy
---
drivers/iommu/intel-iommu.c | 33 ++---
drivers/iommu/iova.c
Hi all,
Here's an update of my previous RFC[1] in preparation for hooking the
IOVA allocator up to the arm64 DMA mapping API, rebased onto 3.19-rc3.
I tried rebasing patches 3 and 4 onto Sakari's RFC series[2] (the merge
conflict is pretty trivial), however I found that series applied to rc3
caus
Systems may contain heterogeneous IOMMUs supporting differing minimum
page sizes, which may also not be common with the CPU page size.
Thus it is practical to have an explicit notion of IOVA granularity
to simplify handling of mapping and allocation constraints.
As an initial step, move the IOVA p
In preparation for sharing the IOVA allocator, split it out under its
own Kconfig symbol.
Signed-off-by: Robin Murphy
---
drivers/iommu/Kconfig | 4
drivers/iommu/Makefile | 3 ++-
2 files changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/iommu/Kconfig b/drivers/iommu/Kconfig
i
On Mon, Jan 12, 2015 at 11:15:38AM -0500, Vivek Goyal wrote:
> On Mon, Jan 12, 2015 at 05:06:46PM +0100, Joerg Roedel wrote:
> > On Mon, Jan 12, 2015 at 10:29:19AM -0500, Vivek Goyal wrote:
> > > Kdump has the notion of backup region. Where certain parts of old kernels
> > > memory can be moved to
On Mon, Jan 12, 2015 at 05:06:46PM +0100, Joerg Roedel wrote:
> On Mon, Jan 12, 2015 at 10:29:19AM -0500, Vivek Goyal wrote:
> > Kdump has the notion of backup region. Where certain parts of old kernels
> > memory can be moved to a different location (first 640K on x86 as of now)
> > and new kernel
Hello Joonyoung,
On 01/12/2015 07:40 AM, Joonyoung Shim wrote:
>> And also making changes to the clocks in the clk-exynos5420 driver. Can
>> you please explain the rationale for those changes? I'm asking because
>> without your clock changes (only adding the DISP1 pd and making the
>> devices as c
On Mon, Jan 12, 2015 at 10:29:19AM -0500, Vivek Goyal wrote:
> Kdump has the notion of backup region. Where certain parts of old kernels
> memory can be moved to a different location (first 640K on x86 as of now)
> and new kernel can make use of this memory now.
>
> So we will have to just make su
Hi Joerg,
On 12/01/15 15:52, Joerg Roedel wrote:
[...]
Thanks for doing this, I like this patch-set.
I would also appreciate if someone from Intel could have a look at it,
David?
Besides, can you please re-post this patch-set rebased to latest
upstream with the better versions of patch 1 and
Hi Oded,
On Mon, Dec 22, 2014 at 12:23:44PM +0200, Oded Gabbay wrote:
> The drm guys suggested we move iommu/ subsystem before gpu/
> subsystem in drivers/Makefile instead of the above patch (and the
> complementing patch-set in amdkfd).
> I did that and it works, so please see this patch as disca
Hi Robin,
On Tue, Nov 25, 2014 at 05:27:24PM +, Robin Murphy wrote:
> Hi all,
>
> I've been implementing IOMMU DMA mapping for arm64, based on tidied-up
> parts of the existing arch/arm/mm/dma-mapping.c with a clear divide
> between the arch-specific parts and the general DMA-API to IOMMU-API
On Thu, 2015-01-08 at 09:15 -0700, Bjorn Helgaas wrote:
> On Fri, Nov 21, 2014 at 03:08:27PM -0700, Alex Williamson wrote:
> > I'd like to make vfio-pci capable of manipulating the device exposed
> > to the user such that if the host can only support a single MSI
> > vector then we hide the fact th
On Mon, Jan 12, 2015 at 04:22:08PM +0100, Joerg Roedel wrote:
> On Mon, Jan 12, 2015 at 03:06:20PM +0800, Li, Zhen-Hua wrote:
> > +
> > +#ifdef CONFIG_CRASH_DUMP
> > +
> > +/*
> > + * Fix Crashdump failure caused by leftover DMA through a hardware IOMMU
> > + *
> > + * Fixes the crashdump kernel to
On Mon, Jan 12, 2015 at 03:06:20PM +0800, Li, Zhen-Hua wrote:
> +
> +#ifdef CONFIG_CRASH_DUMP
> +
> +/*
> + * Fix Crashdump failure caused by leftover DMA through a hardware IOMMU
> + *
> + * Fixes the crashdump kernel to deal with an active iommu and legacy
> + * DMA from the (old) panicked kernel
On Mon, Jan 12, 2015 at 03:06:19PM +0800, Li, Zhen-Hua wrote:
> Allow specification of the domain-id for the new domain.
> This patch only adds the 'did' parameter to iommu_attach_domain()
> and modifies all of its callers to specify the default value of -1
> which says "no did specified, allocate
On 09/01/15 19:45, Arnd Bergmann wrote:
On Friday 09 January 2015 16:56:03 Robin Murphy wrote:
This one's a bit tricky to find a home for - I think technically it's
probably an IOMMU patch, but then the long-underlying problem doesn't
seem to have blown up anything until arm64, and my motivatio
On Fri, Jan 09, 2015 at 07:45:49PM +, Arnd Bergmann wrote:
> On Friday 09 January 2015 16:56:03 Robin Murphy wrote:
> >
> > This one's a bit tricky to find a home for - I think technically it's
> > probably an IOMMU patch, but then the long-underlying problem doesn't
> > seem to have blown up
Hello Hongbo,
On Mon, Jan 12, 2015 at 11:51 AM, Hongbo Zhang wrote:
> On 9 January 2015 at 23:34, Javier Martinez Canillas
>>
>> Yes, please take a look to Marek series [0]. Keep in mind that the
>> series does not support all sysmmu revisions so IOMMU is not supported
>> for some SoCs (e.g: Exyn
On 9 January 2015 at 23:34, Javier Martinez Canillas
wrote:
> [adding Marek, Sjoerd and Joonyoung that were discussing about iommu
> support in another thread]
Thank you Javier.
>
> Hello Hongbo,
>
> On Fri, Jan 9, 2015 at 8:31 AM, Hongbo Zhang wrote:
>> Add linux-samsung-...@vger.kernel.org ma
Hi,
On 01/12/2015 03:40 PM, Joonyoung Shim wrote:
> Hi,
>
> On 01/09/2015 01:42 AM, Javier Martinez Canillas wrote:
>> Hello Joonyoung,
>>
>> On 01/07/2015 10:55 AM, Joonyoung Shim wrote:
>
> I don't think iommu support and power domain issue are related. I also
> get displaying strip
On 01/12/2015 05:07 PM, Baoquan He wrote:
On 01/12/15 at 04:00pm, Li, ZhenHua wrote:
Comparing to v7, this version adds only a few lines code:
In function copy_page_table,
+ __iommu_flush_cache(iommu, phys_to_virt(dma_pte_next),
+ VTD_PAGE_SIZE);
S
On 01/12/15 at 04:00pm, Li, ZhenHua wrote:
> Comparing to v7, this version adds only a few lines code:
>
> In function copy_page_table,
>
> + __iommu_flush_cache(iommu, phys_to_virt(dma_pte_next),
> + VTD_PAGE_SIZE);
So this adding fixs the reported dmar f
Comparing to v7, this version adds only a few lines code:
In function copy_page_table,
+ __iommu_flush_cache(iommu, phys_to_virt(dma_pte_next),
+ VTD_PAGE_SIZE);
On 01/12/2015 03:06 PM, Li, Zhen-Hua wrote:
This patchset is an update of Bill Sumner's
33 matches
Mail list logo
