On 02/06/2015 10:12 AM, Catalin Marinas wrote:
On Fri, Feb 06, 2015 at 02:54:23PM +, Murali Karicheri wrote:
On 02/06/2015 09:38 AM, Catalin Marinas wrote:
On Thu, Feb 05, 2015 at 09:52:55PM +, Murali Karicheri wrote:
Fix the dma-range size when the DT attribute is missing. i.e set si
On 02/06/2015 12:53 PM, Bjorn Helgaas wrote:
On Fri, Feb 6, 2015 at 9:28 AM, Murali Karicheri wrote:
On 02/06/2015 10:15 AM, Catalin Marinas wrote:
On Thu, Feb 05, 2015 at 09:52:52PM +, Murali Karicheri wrote:
This patch add an important capability to PCI driver on Keystone. I hope
to
h
Hi Laura,
As a heads up, I'm still vainly hoping to move the ARM SMMU driver
entirely over to the generic framework - there's an iommu/dev branch on
top of the iommu/dma branch I pushed earlier[1] which you might want to
take a peek at to check if we're likely to end up pulling in different
d
Hi Thierry,
On 02/06/2015 04:44 AM, Thierry Reding wrote:
> From: Thierry Reding
>
> Hi Joerg,
>
> Here are a couple of urgent fixes for a regression on old Tegra devices
> related to IOMMU support. The issue is that many drivers think it's a
> good idea to register IOMMU support unconditionall
On Fri, Feb 6, 2015 at 9:28 AM, Murali Karicheri wrote:
> On 02/06/2015 10:15 AM, Catalin Marinas wrote:
>>
>> On Thu, Feb 05, 2015 at 09:52:52PM +, Murali Karicheri wrote:
>>>
>>> This patch add an important capability to PCI driver on Keystone. I hope
>>> to
>>> have this merged to the upstr
On 02/06/2015 10:15 AM, Catalin Marinas wrote:
On Thu, Feb 05, 2015 at 09:52:52PM +, Murali Karicheri wrote:
This patch add an important capability to PCI driver on Keystone. I hope to
have this merged to the upstream branch so that it is available for v3.20.
It's very late for 3.20 and the
This patch was produced using Coccinelle. A simplified version of the
semantic patch is:
@r exists@
identifier f;
local idexpression u8 x;
identifier xname;
@@
f(...) {
...when any
(
x@xname = 1;
|
x@xname = 0;
)
...when any
}
@bad exists@
identifier r.f;
local idexpression u8 r.x
expression
On Thu, Feb 05, 2015 at 09:52:52PM +, Murali Karicheri wrote:
> This patch add an important capability to PCI driver on Keystone. I hope to
> have this merged to the upstream branch so that it is available for v3.20.
It's very late for 3.20 and the code hasn't been in linux-next at all
(but it
On Fri, Feb 06, 2015 at 02:54:23PM +, Murali Karicheri wrote:
> On 02/06/2015 09:38 AM, Catalin Marinas wrote:
> > On Thu, Feb 05, 2015 at 09:52:55PM +, Murali Karicheri wrote:
> >> Fix the dma-range size when the DT attribute is missing. i.e set size to
> >> dev->coherent_dma_mask + 1 ins
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 this RFC series is aimed at enabling arm64, once any remaining
obvious issues in the commo
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 | 11 ++-
arch/arm64/mm/dma-mapping.c | 15
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 | 17 ++
arch/arm64/mm/dma-mapping.c
Hi all,
This is an updated RFC to address some of the initial comments[1].
The first two patches of the original posting, along with the IOVA
series, are now in -next so aren't included here.
If this is starting to look tidy enough, then I'll get to work on
porting arch/arm as well so I can repos
On 02/06/2015 09:38 AM, Catalin Marinas wrote:
On Thu, Feb 05, 2015 at 09:52:55PM +, Murali Karicheri wrote:
Fix the dma-range size when the DT attribute is missing. i.e set size to
dev->coherent_dma_mask + 1 instead of dev->coherent_dma_mask. Also add
code to check invalid values of size c
On Thu, Feb 05, 2015 at 09:52:55PM +, Murali Karicheri wrote:
> Fix the dma-range size when the DT attribute is missing. i.e set size to
> dev->coherent_dma_mask + 1 instead of dev->coherent_dma_mask. Also add
> code to check invalid values of size configured in DT and log error.
>
> Cc: Joer
Hello Hann,
On Fri, Feb 06, 2015 at 11:45:55AM +0800, Hann Huang wrote:
> Hi all,
>
> I did some experiment which needs two-stage address translation (GVA->GPA->
> SPA).
> After setting the mode bit in DTE to 100b, I got lots of IO_PAGE_FAULT event
> but no any PPR request.
Did you also install
On Wed, Feb 04, 2015 at 11:37:52AM -0600, Suman Anna wrote:
> Hi Thierry,
>
> On 02/04/2015 08:31 AM, Laurent Pinchart wrote:
> > Hi Thierry,
> >
> > Thank you for the patch.
> >
> > On Wednesday 04 February 2015 08:58:08 Thierry Reding wrote:
> >> From: Thierry Reding
> >>
> >> The OMAP IOMMU
On Wed, Feb 04, 2015 at 04:31:55PM +0200, Laurent Pinchart wrote:
> Hi Thierry,
>
> Thank you for the patch.
>
> On Wednesday 04 February 2015 08:58:08 Thierry Reding wrote:
> > From: Thierry Reding
> >
> > The OMAP IOMMU driver unconditionally executes code and registers a
> > struct iommu_ops
From: Thierry Reding
The MSM IOMMU driver unconditionally calls bus_set_iommu(), which is a
very stupid thing to do on multi-platform kernels. While marking the
driver BROKEN may seem a little extreme, there is no other way to make
the driver skip initialization. One of the problems is that it do
From: Thierry Reding
The Rockchip IOMMU driver unconditionally executes code and registers a
struct iommu_ops with the platform bus irrespective of whether it runs
on a Rockchip SoC or not. This causes problems in multi-platform kernels
where drivers for other SoCs will no longer be able to regis
From: Thierry Reding
The OMAP IOMMU driver unconditionally executes code and registers a
struct iommu_ops with the platform bus irrespective of whether it runs
on an OMAP SoC or not. This causes problems in multi-platform kernels
where drivers for other SoCs will no longer be able to register the
From: Thierry Reding
The Exynos System MMU driver unconditionally executes code and registers
a struct iommu_ops with the platform bus irrespective of whether it runs
on an Exynos SoC or not. This causes problems in multi-platform kernels
where drivers for other SoCs will no longer be able to reg
From: Thierry Reding
Hi Joerg,
Here are a couple of urgent fixes for a regression on old Tegra devices
related to IOMMU support. The issue is that many drivers think it's a
good idea to register IOMMU support unconditionally, which is not the
smart thing to do at all on multi-platform kernels. T
23 matches
Mail list logo
