me this sounds much like the reasoning for the etnaviv
dependency. There is no actual build dependency, as the allocations are
done through the DMA API, but for the allocations to succeed you most
likely want CMA to be enabled. But that's just an observation from the
outside, I have no real clue about
lmost always, hides references to the
> nents and orig_nents entries, making the code robust, easier to follow
> and copy/paste safe.
>
> Signed-off-by: Marek Szyprowski
> Reviewed-by: Robin Murphy
Acked-by: Lucas Stach
> ---
> drivers/gpu/drm/etnaviv/etnaviv_gem.c | 12
On Mi, 2020-02-26 at 15:51 +, Robin Murphy wrote:
> On 26/02/2020 3:44 pm, Lucas Stach wrote:
> > Hi all,
> >
> > I'm currently struggling with how to properly check for restricted DMA
> > addressing from a device driver side. The basic issue I'm facing is
>
Hi all,
I'm currently struggling with how to properly check for restricted DMA
addressing from a device driver side. The basic issue I'm facing is
that I have a embedded GPU, which isn't able to address all system
memory due to interconnect being restricted to 32bit addressing. The
limits are
Am Freitag, den 29.11.2019, 22:21 +0800 schrieb Kai-Heng Feng:
> Serious screen flickering when Stoney Ridge outputs to a 4K monitor.
>
> According to Alex Deucher, IOMMU isn't enabled on Windows, so let's do
> the same here to avoid screen flickering on 4K monitor.
This doesn't seem like a good
Am Dienstag, den 06.08.2019, 17:44 +0200 schrieb Christoph Hellwig:
> On Tue, Aug 06, 2019 at 04:06:58PM +0200, Lucas Stach wrote:
> >
> > dma_direct_free_pages() then needs the same check, as otherwise the cpu
> > address is treated as a cookie instead of a real address a
Am Dienstag, den 06.08.2019, 16:04 +0200 schrieb Christoph Hellwig:
> Ok, does this work?
>
> --
> From 34d35f335a98f515f2516b515051e12eae744c8d Mon Sep 17 00:00:00 2001
> > From: Christoph Hellwig
> Date: Tue, 6 Aug 2019 14:33:23 +0300
> Subject: dma-direct: fix DMA_ATTR_NO_KERNEL_MAPPING
>
>
Am Dienstag, den 06.08.2019, 13:33 +0200 schrieb Christoph Hellwig:
> On Tue, Aug 06, 2019 at 11:13:29AM +0200, Lucas Stach wrote:
> > Hi Christoph,
> >
> > I just found a regression where my NVMe device is no longer able to
> > set
> > up its H
Hi Christoph,
I just found a regression where my NVMe device is no longer able to set
up its HMB.
After subject commit dma_direct_alloc_pages() is no longer initializing
dma_handle properly when DMA_ATTR_NO_KERNEL_MAPPING is set, as the
function is now returning too early.
Now this could easily
Hi Christoph,
Am Donnerstag, den 01.08.2019, 16:00 +0200 schrieb Christoph Hellwig:
> On Thu, Aug 01, 2019 at 10:35:02AM +0200, Lucas Stach wrote:
> > Hi Christoph,
> >
> > Am Donnerstag, den 01.08.2019, 09:29 +0200 schrieb Christoph Hellwig:
> > > Hi Luka
: b4ebe6063204 (dma-direct: implement complete bus_dma_mask handling)
Signed-off-by: Lucas Stach
---
kernel/dma/direct.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/kernel/dma/direct.c b/kernel/dma/direct.c
index 59bdceea3737..7ba3480fc546 100644
--- a/kernel/dma/direct.c
+++ b/kernel/dma
Hi Christoph,
Am Donnerstag, den 01.08.2019, 09:29 +0200 schrieb Christoph Hellwig:
> Hi Lukas,
>
> have you tried the latest 5.3-rc kernel, where we limited the NVMe
> I/O size based on the swiotlb buffer size?
Yes, the issue was reproduced on 5.3-rc2. I now see your commit
limiting the
Hi all,
I'm currently looking at an issue with an NVMe device, which isn't
working properly under some specific conditions.
The issue comes down to my platform having DMA addressing restrictions,
with only 3 of the total 4GiB of RAM being device addressable, which
means a bunch of DMA mappings
Am Donnerstag, den 17.08.2017, 16:18 +0200 schrieb Joerg Roedel:
> On Thu, Aug 17, 2017 at 04:03:54PM +0200, Lucas Stach wrote:
> > There is no IOMMU driver in use. Etnaviv just uses part of the IOMMU API
> > to manage the GPU internal MMU, see
> > drivers/gpu/drm/et
Am Donnerstag, den 17.08.2017, 15:45 +0200 schrieb Joerg Roedel:
> Hi Lucas,
>
> On Thu, Aug 17, 2017 at 03:32:38PM +0200, Lucas Stach wrote:
> > I don't think this is necessary. Etnaviv has managed and batched up TLB
> > flushes from day 1, as they don't happen through t
ng of this series is correct, Etnaviv is just fine
with the changed semantics of the unsynchronized map/unmap calls.
Regards,
Lucas
>
> Cc: Lucas Stach <l.st...@pengutronix.de>
> Cc: Russell King <linux+etna...@armlinux.org.uk>
> Cc: Christian Gmeiner <chris
The callers of the DMA alloc functions already provide the proper
context GFP flags. Make sure to pass them through to the CMA
allocator, to make the CMA compaction context aware.
Signed-off-by: Lucas Stach <l.st...@pengutronix.de>
Acked-by: Vlastimil Babka <vba...@suse.cz>
Acked-by:
Most users of this interface just want to use it with the default
GFP_KERNEL flags, but for cases where DMA memory is allocated it may
be called from a different context.
No functional change yet, just passing through the flag to the
underlying alloc_contig_range function.
Signed-off-by: Lucas
the function prototype, to allow for passing through the
GFP mask set by upper layers.
Also respect global restrictions by applying memalloc_noio_flags
to the passed in flags.
Signed-off-by: Lucas Stach <l.st...@pengutronix.de>
Acked-by: Michal Hocko <mho...@suse.com>
---
v2: add m
Most users of this interface just want to use it with the default
GFP_KERNEL flags, but for cases where DMA memory is allocated it may
be called from a different context.
No functional change yet, just passing through the flag to the
underlying alloc_contig_range function.
Signed-off-by: Lucas
the function prototype, to allow for passing through the
GFP mask set by upper layers. No functional change in this patch,
just making the assumptions a bit more obvious.
Signed-off-by: Lucas Stach <l.st...@pengutronix.de>
---
include/linux/gfp.h | 2 +-
mm/cma.c| 3 ++-
mm/hug
The callers of the DMA alloc functions already provide the proper
context GFP flags. Make sure to pass them through to the CMA
allocator, to make the CMA compaction context aware.
Signed-off-by: Lucas Stach <l.st...@pengutronix.de>
---
arch/arm/mm/dma-mapping.c | 16 +---
This will get rid of a lot false positives caused by kmemleak being
unaware of the irq_remap_table. Based on a suggestion from Catalin Marinas.
Signed-off-by: Lucas Stach <d...@lynxeye.de>
---
drivers/iommu/amd_iommu_init.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers
)
is the control weather a master should go through the M4U unit for
translation or bypass it and talk directly to external memory
controller.
Regards,
Lucas
--
Pengutronix e.K. | Lucas Stach |
Industrial Linux Solutions | http://www.pengutronix.de
which should be expected to
break. Exactly the same thing as with componentized devices...
Regards,
Lucas
--
Pengutronix e.K. | Lucas Stach |
Industrial Linux Solutions | http://www.pengutronix.de/ |
___
iommu mailing list
() in the 3.18 cycle
and I would think it would be no problem to to the same with rcar.
Regards,
Lucas
--
Pengutronix e.K. | Lucas Stach |
Industrial Linux Solutions | http://www.pengutronix.de/ |
___
iommu mailing list
iommu
don't have any reasonable other
possibility to stuff things into this field, I think it would make sense
to do the cleanup the other way around: keep the irq_set_chip_data
arch_setup_msi_irq() and rip it out of the individual drivers.
Regards,
Lucas
--
Pengutronix e.K. | Lucas Stach
. | Lucas Stach |
Industrial Linux Solutions | http://www.pengutronix.de/ |
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
other platform MSI
arch code to eliminate weak arch MSI functions. This patch add
.restore_irq() and .setup_irqs() to make it become more common.
Signed-off-by: Yijing Wang wangyij...@huawei.com
This change looks good to me:
Reviewed-by: Lucas Stach l.st...@pengutronix.de
---
drivers/pci
Am Freitag, den 05.09.2014, 18:10 +0800 schrieb Yijing Wang:
Now we use struct msi_chip in all platforms to configure
MSI/MSI-X. We can clean up the unused arch functions.
Signed-off-by: Yijing Wang wangyij...@huawei.com
Reviewed-by: Lucas Stach l.st...@pengutronix.de
---
drivers/iommu
Am Freitag, den 29.06.2012, 16:20 +0300 schrieb Terje Bergström:
On 28.06.2012 20:19, Lucas Stach wrote:
TTM though solves more advanced matters, like buffer synchronisation
between 3D and 2D block of hardware or syncing buffer access between GPU
and CPU.
One of the most interesting
Am Donnerstag, den 28.06.2012, 09:06 +0300 schrieb Hiroshi Doyu:
Hi Lucas,
On Wed, 27 Jun 2012 17:59:55 +0200
Lucas Stach d...@lynxeye.de wrote:
Rather than introducing a new property, how about using
coherent_pool=??M in the kernel command line if necessary? I think
Hello Hiroshi,
Am Montag, den 18.06.2012, 13:37 +0300 schrieb Hiroshi Doyu:
Hi Lucas,
On Mon, 21 May 2012 19:38:28 +0200
Lucas Stach d...@lynxeye.de wrote:
Am Montag, den 21.05.2012, 19:31 +0200 schrieb Thierry Reding:
* Stephen Warren wrote:
On 05/21/2012 11:05 AM, Lucas Stach
Hi Joerg and others,
sorry for not providing a proper thread reference, but I'm not
subscribed to this list long enough.
I wonder what happened to the DOMAIN_ATTR_GEOMETRY patchset. Did it got
dropped by accident or are there some reasons which are preventing this
from going in?
It would be
Am Mittwoch, den 11.04.2012, 15:18 + schrieb Arnd Bergmann:
On Wednesday 11 April 2012, Thierry Reding wrote:
* Daniel Vetter wrote:
On Wed, Apr 11, 2012 at 03:23:26PM +0200, Thierry Reding wrote:
* Daniel Vetter wrote:
On Wed, Apr 11, 2012 at 02:10:30PM +0200, Thierry Reding
35 matches
Mail list logo
