Re: [PATCH v16 2/5] iommu/arm-smmu: Invoke pm_runtime during probe, add/remove device

2018-10-01 Thread Vivek Gautam
On Tue, Oct 2, 2018 at 9:44 AM Vivek Gautam wrote: > > Hi Will, > > On Mon, Oct 1, 2018 at 6:29 PM Will Deacon wrote: > > > > Hi Vivek, > > > > On Thu, Aug 30, 2018 at 08:15:38PM +0530, Vivek Gautam wrote: > > > From: Sricharan R > > > > > > The smmu device probe/remove and add/remove master dev

Re: [PATCH v16 2/5] iommu/arm-smmu: Invoke pm_runtime during probe, add/remove device

2018-10-01 Thread Vivek Gautam
Hi Will, On Mon, Oct 1, 2018 at 6:29 PM Will Deacon wrote: > > Hi Vivek, > > On Thu, Aug 30, 2018 at 08:15:38PM +0530, Vivek Gautam wrote: > > From: Sricharan R > > > > The smmu device probe/remove and add/remove master device callbacks > > gets called when the smmu is not linked to its master,

add_device vs attach_device

2018-10-01 Thread Yang Yang
Hi all, I have a very basic question, what's the difference betwee arm_smmu_attach_dev() and arm_smmu_add_device() in ARM SMMUv3 driver? When should I use which method? Thanks, - y ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.lin

Re: [PATCH] dma-direct: document the zone selection logic

2018-10-01 Thread Randy Dunlap
On 10/1/18 1:10 PM, Christoph Hellwig wrote: > What we are doing here isn't quite obvious, so add a comment explaining > it. > > Signed-off-by: Christoph Hellwig > --- > kernel/dma/direct.c | 9 - > 1 file changed, 8 insertions(+), 1 deletion(-) > > diff --git a/kernel/dma/direct.c b/ke

fix up nowarn confusion in the dma mapping layer

2018-10-01 Thread Christoph Hellwig
Hi all, this series sorts out how we deal with the nowarn flags in the dma mapping code. We still support __GFP_NOWARN for the legacy APIs that don't support passing the dma specific flags, but we generally want every implementation to actually check DMA_ATTR_NO_WARN instead.

[PATCH, RFC] swiotlb: don't dip into swiotlb pool for coherent allocations

2018-10-01 Thread Christoph Hellwig
All architectures that support swiotlb also have a zone that backs up these less than full addressing allocations (usually ZONE_DMA32). Because of that it is rather pointless to fall back to the global swiotlb buffer if the normal dma direct allocation failed - the only thing this will do is to ea

[PATCH 1/2] dma-mapping: translate __GFP_NOFAIL to DMA_ATTR_NO_WARN

2018-10-01 Thread Christoph Hellwig
This allows all dma_map_ops instances to entirely rely on DMA_ATTR_NO_WARN going forward. Signed-off-by: Christoph Hellwig --- include/linux/dma-mapping.h | 14 ++ 1 file changed, 10 insertions(+), 4 deletions(-) diff --git a/include/linux/dma-mapping.h b/include/linux/dma-mapping.h

[PATCH 2/2] dma-direct: respect DMA_ATTR_NO_WARN

2018-10-01 Thread Christoph Hellwig
Respect the DMA_ATTR_NO_WARN flags for allocations in dma-direct. Signed-off-by: Christoph Hellwig --- kernel/dma/direct.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/kernel/dma/direct.c b/kernel/dma/direct.c index 170bd322a94a..ba6f5956a291 100644 --- a/kernel/dma/direct.c +++ b/kern

[PATCH] dma-direct: document the zone selection logic

2018-10-01 Thread Christoph Hellwig
What we are doing here isn't quite obvious, so add a comment explaining it. Signed-off-by: Christoph Hellwig --- kernel/dma/direct.c | 9 - 1 file changed, 8 insertions(+), 1 deletion(-) diff --git a/kernel/dma/direct.c b/kernel/dma/direct.c index ba6f5956a291..14b966e2349a 100644 --- a

document dma-direct zone selection

2018-10-01 Thread Christoph Hellwig
Hi all, this patch documents the dma-direct zone selection, as it doesn't seem quite obvuious enough. ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu

Re: dma mask related fixups (including full bus_dma_mask support) v2

2018-10-01 Thread Benjamin Herrenschmidt
On Mon, 2018-10-01 at 16:32 +0200, Christoph Hellwig wrote: > FYI, I've pulled this into the dma-mapping tree to make forward > progress. All but oatch 4 had formal ACKs, and for that one Robin > was fine even without and explicit ack. I'll also send a patch to > better document the zone selectio

[PATCH v2] dma-debug: Check for drivers mapping invalid addresses in dma_map_single()

2018-10-01 Thread Stephen Boyd
I recently debugged a DMA mapping oops where a driver was trying to map a buffer returned from request_firmware() with dma_map_single(). Memory returned from request_firmware() is mapped into the vmalloc region and this isn't a valid region to map with dma_map_single() per the DMA documentation's "