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
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,
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
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
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.
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
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
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
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
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
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
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 "
12 matches
Mail list logo