to a soft dependency.
Hm, to 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
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 fac
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 prop
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
>
> T
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 Lukas,
&
: 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 request
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 ar
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/etnaviv/etna
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
series is correct, Etnaviv is just fine
with the changed semantics of the unsynchronized map/unmap calls.
Regards,
Lucas
>
> Cc: Lucas Stach
> Cc: Russell King
> Cc: Christian Gmeiner
> Cc: David Airlie
> Cc: etna...@lists.freedesktop.org
> Cc: dri-de...@lists.freedeskt
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
Acked-by: Vlastimil Babka
Acked-by: Michal Hocko
---
arch/arm/mm/dma-mapping.c
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
Acked-by: Michal Hocko
---
v2: add memalloc_noio restriction
---
include/linux/gfp.h | 2
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
---
include/linux/gfp.h | 2 +-
mm/cma.c| 3 ++-
mm/hugetlb.c| 3 ++-
mm
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
---
arch/arm/mm/dma-mapping.c | 16 +---
arch/arm64/mm/dma-mapping.c
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
---
drivers/iommu/amd_iommu_init.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/iommu/amd_iommu_init.c b
he IOMMU driver. M4U is the IOMMU unit. The SMI
unit is more of a bridge control for the internal buses where you can
control various properties for the masters on the bus.
One notable property (and why this driver is part of the IOMMU series)
is the control weather a master should g
st option.
Having the IOMMU node enabled in DT with no driver available to the
kernel seems like an invalid configuration which should be expected to
break. Exactly the same thing as with componentized devices...
Regards,
Lucas
--
Pengutronix e.K.
.
>
> Oh, sorry, I found designware and rcar use pci_scan_root_bus(), so we can not
> simply
> assign msi chip to root bus in all host drivers's scan functions.
Designware will switch away from pci_scan_root_bus() in the 3.18 cycle
and I would think it would
Am Dienstag, den 16.09.2014, 09:30 +0800 schrieb Yijing Wang:
> On 2014/9/15 22:00, Lucas Stach wrote:
> > Am Freitag, den 05.09.2014, 18:09 +0800 schrieb Yijing Wang:
> >> Currently, pcie-designware, pcie-rcar, pci-tegra drivers
> >> use irq chip_data to save
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
Reviewed-by: Lucas Stach
> ---
> drivers/iommu/irq_remapping.c |
to refactor all 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
This change looks good to me:
Reviewed-by: Lucas Stach
> ---
&g
msi_chip *chip = arch_find_msi_chip(dev);
> int err;
>
> if (!chip || !chip->setup_irq)
--
Pengutronix e.K. | Lucas Stach |
Industrial Linux Solutions | http://www.pengutronix.de/ |
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
_msi_irq() expects to find the msi_chip in the irq
chip_data field. As this means drivers 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 t
Am Samstag, den 30.06.2012, 20:01 +0200 schrieb Thierry Reding:
> On Fri, Jun 29, 2012 at 04:20:31PM +0300, Terje Bergström wrote:
> > On 28.06.2012 20:19, Lucas Stach wrote:
> > > TTM though solves more advanced matters, like buffer synchronisation
> > > between 3D
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
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 wrote:
>
> > > > > > Rather than introducing a new property, how about using
> > > > > > "coherent_po
Hi all,
I'm not sure what your exact plans are for the direction in which the
DRM driver should head, as I'm still a bit out of the loop as many of
those matters were only discussed internally at NVIDIA or with some NDA
developers. But I'll still try to get into the discussion.
Am Mittwoch, den 2
Am Donnerstag, den 28.06.2012, 10:51 -0600 schrieb Stephen Warren:
> On 06/28/2012 05:12 AM, Thierry Reding wrote:
> > On Wed, Jun 27, 2012 at 05:59:55PM +0200, Lucas Stach wrote:
> >> Am Mittwoch, den 27.06.2012, 16:44 +0200 schrieb Thierry Reding:
> ...
> >>>
Hi Thierry,
Am Donnerstag, den 28.06.2012, 13:12 +0200 schrieb Thierry Reding:
> On Wed, Jun 27, 2012 at 05:59:55PM +0200, Lucas Stach wrote:
> > Am Mittwoch, den 27.06.2012, 16:44 +0200 schrieb Thierry Reding:
> > > On Wed, Jun 27, 2012 at 05:29:14PM +0300, Hiroshi Doyu wrote:
Am Mittwoch, den 27.06.2012, 16:44 +0200 schrieb Thierry Reding:
> On Wed, Jun 27, 2012 at 05:29:14PM +0300, Hiroshi Doyu wrote:
> > On Wed, 27 Jun 2012 16:08:10 +0200
> > Thierry Reding wrote:
> >
> > > * PGP Signed by an unknown key
> > >
> > > On Wed, Jun 27, 2012 at 03:59:07PM +0300, Hiroshi
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 wrote:
>
> > Am Montag, den 21.05.2012, 19:31 +0200 schrieb Thierry Reding:
> > > * Stephen Warren wrote:
> > >
Am Freitag, den 20.04.2012, 07:02 +0200 schrieb Thierry Reding:
> * Jon Mayo wrote:
> > On 04/19/2012 01:40 PM, Thierry Reding wrote:
> [...]
> > >So would it be possible to get a basic dumb KMS driver into mainline
> > >(non-staging) and phase in acceleration later on, with ABI guarantees? I
> > >
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 real
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, T
This must have been messed up while merging, the intention was
clearly to unlock there.
Signed-off-by: Lucas Stach
---
drivers/iommu/tegra-gart.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/iommu/tegra-gart.c b/drivers/iommu/tegra-gart.c
index b21598f
43 matches
Mail list logo
