hi baolu,
> So you have a hidden device (invisible to host kernel). But you need to
>setup some identity mappings for this device, so that the firmware
>could keep working, right?
>The platform designs this by putting that range in the RMRR table and
>expecting the OS kernel to setup identity
Hi Felix,
On 8/27/20 6:02 PM, FelixCuioc wrote:
Some ACPI devices need to issue dma requests to access
the reserved memory area.BIOS uses the device scope type
ACPI_NAMESPACE_DEVICE in RMRR to report these ACPI devices.
This patch add support for detecting ACPI devices in RMRR.
Signed-off-by:
Hi Thomas,
On Wed, Aug 26, 2020 at 01:16:28PM +0200, Thomas Gleixner wrote:
[...]
>
> The whole lot is also available from git:
>
>git://git.kernel.org/pub/scm/linux/kernel/git/tglx/devel.git device-msi
>
> This has been tested on Intel/AMD/KVM but lacks testing on:
>
> - HYPERV
hi baolu ,
These ACPI devices can be retrieved from the kernel and
there is no bound device driver .
Best regards
Felixcui-oc
发件人: Lu Baolu
发送时间: 2020年9月1日 14:12:34
收件人: FelixCui-oc; Joerg Roedel; iommu@lists.linux-foundation.org;
Hi Felix,
On 8/27/20 6:02 PM, FelixCuioc wrote:
After acpi device in RMRR is detected,it is necessary
to establish a mapping for these devices.
In acpi_device_create_direct_mappings(),create a mapping
for the acpi device in RMRR.
Add a helper to achieve the acpi namespace device can
access the
hi baolu,
The function dmar_rmrr_add_acpi_dev() is defined in
intel/iommu.c because struct dmar_rmrr_unit {} is defined in intel/iommu.c.
And dmar_parse_one_rmrr() is also defined here, so we think
it should be defined in iommu.c.
Best regards
Thanks,
applied to the dma-mapping tree.
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
I've applied this to the dma-mapping tree.
I had to resolve a conflict in drivers/of/address.c with a recent
mainline commit. I also applied the minor tweaks Andy pointed out
plus a few more style changes. A real change is that I changed the
prototype for dma_copy_dma_range_map to require less
Hi, Marek:
Marek Szyprowski 於 2020年8月26日 週三 下午2:35寫道：
>
> Use common helper for checking the contiguity of the imported dma-buf and
> do this check before allocating resources, so the error path is simpler.
>
Acked-by: Chun-Kuang Hu
> Signed-off-by: Marek Szyprowski
> ---
>
Robin Murphy 於 2020年9月2日 週三 上午2:55寫道：
>
> On 2020-08-26 07:32, Marek Szyprowski wrote:
> > Use common helper for converting a sg_table object into struct
> > page pointer array.
>
> Reviewed-by: Robin Murphy
>
> Side note: is mtk_drm_gem_prime_vmap() missing a call to
> sg_free_table(sgt) before
Hi Torsten,
On 9/1/20 10:41 PM, Torsten Hilbrich wrote:
On 01.09.20 04:02, Lu Baolu wrote:
[...]
This looks more like a generic issue, used-before-allocated, and should
be fixed in iommu.c instead of VT-d driver. How about
diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c
index
hi Torsten,
On 9/1/20 10:41 PM, Torsten Hilbrich wrote:
On 01.09.20 04:02, Lu Baolu wrote:
[...]
This looks more like a generic issue, used-before-allocated, and should
be fixed in iommu.c instead of VT-d driver. How about
diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c
index
On Tue, Sep 1, 2020 at 12:14 PM Robin Murphy wrote:
>
> On 2020-08-26 07:32, Marek Szyprowski wrote:
> > The Documentation/DMA-API-HOWTO.txt states that the dma_map_sg() function
> > returns the number of the created entries in the DMA address space.
> > However the subsequent calls to the
hi baolu ,
Add pr_info(), there will be a problem.
dmar_acpi_bus_add_dev() will call
dmar_acpi_insert_dev_scope() twice. So it will print two identical logs. This
is similar to dmar_pci_bus_add_dev(). What do you think?
On 9/1/20 5:13 PM, FelixCui-oc wrote:
hi baolu ,
These ACPI devices can be retrieved from the kernel
and there is no bound device driver .
So you have a hidden device (invisible to host kernel). But you need to
setup some identity mappings for this device, so that the
Hi,
On 9/2/20 5:28 AM, Jacob Pan wrote:
On Mon, 24 Aug 2020 10:24:11 +0800
Lu Baolu wrote:
Hi Jacob,
On 8/22/20 12:35 PM, Jacob Pan wrote:
ioasid_set was introduced as an arbitrary token that are shared by a
group of IOASIDs. For example, if IOASID #1 and #2 are allocated
via the same
After updating from v5.8 to v5.9-rc2 I noticed some problems when
booting a system with kernel cmdline "intel_iommu=on,igfx_off".
The following stacktrace was produced:
<6>[0.00] Command line: BOOT_IMAGE=/isolinux/bzImage console=tty1
intel_iommu=on,igfx_off
...
<6>[3.341682] DMAR:
When using 128-bit interrupt-remapping table entry (IRTE) (a.k.a GA mode),
current driver disables interrupt remapping when it updates the IRTE
so that the upper and lower 64-bit values can be updated safely.
However, this creates a small window, where the interrupt could
arrive and result in
> -Original Message-
> From: linux-kernel-ow...@vger.kernel.org
> [mailto:linux-kernel-ow...@vger.kernel.org] On Behalf Of John Garry
> Sent: Saturday, August 22, 2020 1:54 AM
> To: w...@kernel.org; robin.mur...@arm.com
> Cc: j...@8bytes.org; linux-arm-ker...@lists.infradead.org;
>
Hi Jacob,
On 8/22/20 6:35 AM, Jacob Pan wrote:
> ioasid_set was introduced as an arbitrary token that are shared by a
that is
> group of IOASIDs. For example, if IOASID #1 and #2 are allocated via the
> same ioasid_set*, they are viewed as to belong to the same set.
two IOASIDs allocated via the
Hi jacob,
On 8/22/20 6:35 AM, Jacob Pan wrote:
> Rename ioasid_set_data() to ioasid_attach_data() to avoid confusion with
> struct ioasid_set. ioasid_set is a group of IOASIDs that share a common
> token.
>
> Signed-off-by: Jacob Pan
Reviewed-by: Eric Auger
Eric
> ---
>
Hi Jacob,
On 8/22/20 6:35 AM, Jacob Pan wrote:
> There can be multiple users of an IOASID, each user could have hardware
> contexts associated with the IOASID. In order to align lifecycles,
> reference counting is introduced in this patch. It is expected that when
> an IOASID is being freed, each
On Thu, Aug 20, 2020 at 07:33:48PM +0200, Tomasz Figa wrote:
> > It wasn't meant to be too insulting, but I found this out when trying
> > to figure out how to just disable it. But it also ends up using
> > the actual dma attr flags for it's own consistency checks, so just
> > not setting the
On 2020-08-26 07:32, Marek Szyprowski wrote:
Replace the current hand-crafted code for extracting pages and DMA
addresses from the given scatterlist by the much more robust
code based on the generic scatterlist iterators and recently
introduced sg_table-based wrappers. The resulting code is
On 2020-08-26 07:32, Marek Szyprowski wrote:
It is a common operation done by DRM drivers to check the contiguity
of the DMA-mapped buffer described by a scatterlist in the
sg_table object. Let's add a common helper for this operation.
I still think this could be hoisted even further out to
On Tue, Sep 01, 2020 at 07:16:27PM +0200, Christoph Hellwig wrote:
> Well, if IP22 doesn't speculate (which I'm pretty sure is the case),
> dma_sync_single_for_cpu should indeeed be a no-op. But then there
> also shouldn't be anything in the cache, as the previous
> dma_sync_single_for_device
On 2020-08-26 07:32, Marek Szyprowski wrote:
The Documentation/DMA-API-HOWTO.txt states that the dma_map_sg() function
returns the number of the created entries in the DMA address space.
However the subsequent calls to the dma_sync_sg_for_{device,cpu}() and
dma_unmap_sg must be called with the
On Wed, Aug 19, 2020 at 08:55:49AM +0200, Christoph Hellwig wrote:
> Use the proper modern API to transfer cache ownership for incoherent DMA.
>
> Signed-off-by: Christoph Hellwig
> ---
> drivers/net/ethernet/seeq/sgiseeq.c | 12
> 1 file changed, 8 insertions(+), 4 deletions(-)
>
On 01.09.20 17:22, James Bottomley wrote:
> On Tue, 2020-09-01 at 16:05 +0100, Matthew Wilcox wrote:
>> On Tue, Sep 01, 2020 at 07:52:40AM -0700, James Bottomley wrote:
>>> I think this looks mostly OK, except for one misnamed parameter
>>> below. Unfortunately, the last non-coherent parisc was
From: Rob Clark
In a later patch, the drvdata will not directly be 'struct msm_gpu *',
so add a helper to reduce the churn.
Signed-off-by: Rob Clark
Reviewed-by: Jordan Crouse
Reviewed-by: Bjorn Andersson
---
drivers/gpu/drm/msm/adreno/adreno_device.c | 10 --
From: Rob Clark
This interface will be used for drm/msm to coordinate with the
qcom_adreno_smmu_impl to enable/disable TTBR0 translation.
Once TTBR0 translation is enabled, the GPU's CP (Command Processor)
will directly switch TTBR0 pgtables (and do the necessary TLB inv)
synchronized to the
From: Rob Clark
This will be populated by adreno-smmu, to provide a way for coordinating
enabling/disabling TTBR0 translation.
Signed-off-by: Rob Clark
Reviewed-by: Jordan Crouse
Reviewed-by: Bjorn Andersson
---
drivers/gpu/drm/msm/adreno/adreno_device.c | 2 --
From: Jordan Crouse
Use the aperture settings from the IOMMU domain to set up the virtual
address range for the GPU. This allows us to transparently deal with
IOMMU side features (like split pagetables).
Signed-off-by: Jordan Crouse
Signed-off-by: Rob Clark
Reviewed-by: Bjorn Andersson
---
From: Jordan Crouse
Add support to create a io-pgtable for use by targets that support
per-instance pagetables. In order to support per-instance pagetables the
GPU SMMU device needs to have the qcom,adreno-smmu compatible string and
split pagetables enabled.
Signed-off-by: Jordan Crouse
From: Jordan Crouse
Add support for allocating private address space instances. Targets that
support per-context pagetables should implement their own function to
allocate private address spaces.
The default will return a pointer to the global address space.
Signed-off-by: Jordan Crouse
From: Jordan Crouse
Each submitqueue is attached to a context. Add a pointer to the
context to the submitqueue at create time and refcount it so
that it stays around through the life of the queue.
Co-developed-by: Rob Clark
Signed-off-by: Jordan Crouse
Signed-off-by: Rob Clark
Reviewed-by:
From: Rob Clark
For the Adreno GPU's SMMU, we want SCTLR.HUPCF set to ensure that
pending translations are not terminated on iova fault. Otherwise
a terminated CP read could hang the GPU by returning invalid
command-stream data.
Signed-off-by: Rob Clark
Reviewed-by: Bjorn Andersson
---
From: Rob Clark
In $debugfs/gem we already show any vma(s) associated with an object.
Also show process names if the vma's address space is a per-process
address space.
Signed-off-by: Rob Clark
Reviewed-by: Jordan Crouse
Reviewed-by: Bjorn Andersson
---
drivers/gpu/drm/msm/msm_drv.c |
From: Jordan Crouse
Add a special implementation for the SMMU attached to most Adreno GPU
target triggered from the qcom,adreno-smmu compatible string.
The new Adreno SMMU implementation will enable split pagetables
(TTBR1) for the domain attached to the GPU device (SID 0) and
hard code it
From: Jordan Crouse
Every Qcom Adreno GPU has an embedded SMMU for its own use. These
devices depend on unique features such as split pagetables,
different stall/halt requirements and other settings. Identify them
with a compatible string so that they can be identified in the
arm-smmu
From: Rob Clark
Set the qcom,adreno-smmu compatible string for the GPU SMMU to enable
split pagetables and per-instance pagetables for drm/msm.
Signed-off-by: Rob Clark
---
arch/arm64/boot/dts/qcom/sc7180.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
From: Jordan Crouse
Add support for using per-instance pagetables if all the dependencies are
available.
Signed-off-by: Jordan Crouse
Signed-off-by: Rob Clark
Reviewed-by: Akhil P Oommen
---
drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 63 +++
From: Jordan Crouse
Set the qcom,adreno-smmu compatible string for the GPU SMMU to enable
split pagetables and per-instance pagetables for drm/msm.
Signed-off-by: Jordan Crouse
Signed-off-by: Rob Clark
---
arch/arm64/boot/dts/qcom/sdm845-cheza.dtsi | 9 +
From: Jordan Crouse
Enable TTBR1 for a context bank if IO_PGTABLE_QUIRK_ARM_TTBR1 is selected
by the io-pgtable configuration.
Signed-off-by: Jordan Crouse
Signed-off-by: Rob Clark
Reviewed-by: Bjorn Andersson
---
drivers/iommu/arm/arm-smmu/arm-smmu.c | 19 +++
From: Rob Clark
NOTE: I have re-ordered the series, and propose that we could merge this
series in the following order:
1) 01-11 - merge via drm / msm-next
2) 12-15 - merge via iommu, no dependency on msm-next pull req
3) 16-18 - patch 16 has a dependency on 02 and
From: Jordan Crouse
Construct the io-pgtable config before calling the implementation specific
init_context function and pass it so the implementation specific function
can get a chance to change it before the io-pgtable is created.
Signed-off-by: Jordan Crouse
Signed-off-by: Rob Clark
From: Jordan Crouse
Do a bit of prep work to add the upcoming adreno-smmu implementation.
Add an hook to allow the implementation to choose which context banks
to allocate.
Move some of the common structs to arm-smmu.h in anticipation of them
being used by the implementations and update some
From: Rob Clark
Sprinkle a few `const`s where helpers don't need write access.
Signed-off-by: Rob Clark
Reviewed-by: Bjorn Andersson
---
drivers/iommu/arm/arm-smmu/arm-smmu.h | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/iommu/arm/arm-smmu/arm-smmu.h
Hi Eric,
On Thu, 27 Aug 2020 18:21:07 +0200
Auger Eric wrote:
> Hi Jacob,
> On 8/24/20 12:32 PM, Jean-Philippe Brucker wrote:
> > On Fri, Aug 21, 2020 at 09:35:10PM -0700, Jacob Pan wrote:
> >> IOASID is used to identify address spaces that can be targeted by
> >> device DMA. It is a
Hi Jacob,
On 8/22/20 6:35 AM, Jacob Pan wrote:
> On Intel Scalable I/O Virtualization (SIOV) enabled platforms, IOMMU
> driver is one of the users of IOASIDs. In normal flow, callers will
> perform IOASID allocation, bind, unbind, and free in order. However, for
> guest SVA, IOASID free could
Hi Jacob,
On 8/22/20 6:35 AM, Jacob Pan wrote:
> IOASID core maintains the guest-host mapping in the form of SPID and
> IOASID. This patch assigns the guest PASID (if valid) as SPID while
> binding guest page table with a host PASID. This mapping will be used
> for lookup and notifications.
>
>
Hi Jacob,
On 8/22/20 6:35 AM, Jacob Pan wrote:
> Relations among IOASID users largely follow a publisher-subscriber
> pattern. E.g. to support guest SVA on Intel Scalable I/O Virtualization
> (SIOV) enabled platforms, VFIO, IOMMU, device drivers, KVM are all users
> of IOASIDs. When a state
On Tue, Sep 01, 2020 at 06:41:12PM +0200, Helge Deller wrote:
> > I still have a zoo of machines running for such testing, including a
> > 715/64 and two 730.
> > I'm going to test this git tree on the 715/64:
The 715/64 is a 7100LC machine though. I think you need to boot on
the 730 to test the
On Tue, Sep 01, 2020 at 05:22:09PM +0200, Thomas Bogendoerfer wrote:
> On Wed, Aug 19, 2020 at 08:55:49AM +0200, Christoph Hellwig wrote:
> > Use the proper modern API to transfer cache ownership for incoherent DMA.
> >
> > Signed-off-by: Christoph Hellwig
> > ---
> >
On Tue, Sep 01, 2020 at 07:12:41PM +0200, Thomas Bogendoerfer wrote:
> On Tue, Sep 01, 2020 at 05:22:09PM +0200, Thomas Bogendoerfer wrote:
> > On Wed, Aug 19, 2020 at 08:55:49AM +0200, Christoph Hellwig wrote:
> > > Use the proper modern API to transfer cache ownership for incoherent DMA.
> > >
On Tue, 2020-09-01 at 16:05 +0100, Matthew Wilcox wrote:
> On Tue, Sep 01, 2020 at 07:52:40AM -0700, James Bottomley wrote:
> > I think this looks mostly OK, except for one misnamed parameter
> > below. Unfortunately, the last non-coherent parisc was the 700
> > series and I no longer own a box,
Hi Jacob,
On 8/22/20 6:35 AM, Jacob Pan wrote:
> When an IOASID set is used for guest SVA, each VM will acquire its
> ioasid_set for IOASID allocations. IOASIDs within the VM must have a
> host/physical IOASID backing, mapping between guest and host IOASIDs can
> be non-identical. IOASID set
On 01.09.20 18:21, Helge Deller wrote:
> On 01.09.20 17:22, James Bottomley wrote:
>> On Tue, 2020-09-01 at 16:05 +0100, Matthew Wilcox wrote:
>>> On Tue, Sep 01, 2020 at 07:52:40AM -0700, James Bottomley wrote:
I think this looks mostly OK, except for one misnamed parameter
below.
From: Jordan Crouse
Now that we can get the ctx from the submitqueue, the extra arg is
redundant.
Signed-off-by: Jordan Crouse
[split out of previous patch to reduce churny noise]
Signed-off-by: Rob Clark
Reviewed-by: Bjorn Andersson
---
drivers/gpu/drm/msm/adreno/a5xx_gpu.c | 12
From: Rob Clark
Currently it doesn't matter, since we free the ctx immediately. But
when we start refcnt'ing the ctx, we don't want old dangling list
entries to hang around.
Signed-off-by: Rob Clark
Reviewed-by: Jordan Crouse
Reviewed-by: Bjorn Andersson
---
On Mon, Aug 31, 2020 at 9:32 PM Bjorn Andersson
wrote:
>
> On Thu 13 Aug 21:41 CDT 2020, Rob Clark wrote:
>
> > From: Rob Clark
> >
> > In a later patch, the drvdata will not directly be 'struct msm_gpu *',
> > so add a helper to reduce the churn.
> >
> > Signed-off-by: Rob Clark
> > ---
> >
On Wed, Aug 19, 2020 at 08:55:36AM +0200, Christoph Hellwig wrote:
> Signed-off-by: Christoph Hellwig
> ---
> arch/mips/include/asm/jazzdma.h | 2 -
> arch/mips/jazz/jazzdma.c| 70 -
> 2 files changed, 72 deletions(-)
Acked-by: Thomas Bogendoerfer
--
On Wed, Aug 19, 2020 at 08:55:37AM +0200, Christoph Hellwig wrote:
> The jazzdma ops implement support for a very basic IOMMU. Thus we really
> should not use the dma-direct code that takes physical address limits
> into account. This survived through the great MIPS DMA ops cleanup mostly
>
On Wed, Aug 19, 2020 at 08:55:35AM +0200, Christoph Hellwig wrote:
> When transferring DMA ownership back to the CPU there should never
> be any writeback from the cache, as the buffer was owned by the
> device until now. Instead it should just be invalidated for the
> mapping directions where
On 01.09.20 04:02, Lu Baolu wrote:
[...]
> This looks more like a generic issue, used-before-allocated, and should
> be fixed in iommu.c instead of VT-d driver. How about
>
> diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c
> index 8fd93a5b8764..a599da87eb60 100644
> ---
On Wed, 2020-08-19 at 08:55 +0200, Christoph Hellwig wrote:
> Switch the 53c700 driver to only use non-coherent descriptor memory
> if it really has to because dma_alloc_coherent fails. This doesn't
> matter for any of the platforms it runs on currently, but that will
> change soon.
>
> To help
On Tue, Sep 1, 2020 at 1:06 PM Christoph Hellwig wrote:
>
> On Thu, Aug 20, 2020 at 07:33:48PM +0200, Tomasz Figa wrote:
> > > It wasn't meant to be too insulting, but I found this out when trying
> > > to figure out how to just disable it. But it also ends up using
> > > the actual dma attr
On Wed, Aug 19, 2020 at 08:55:33AM +0200, Christoph Hellwig wrote:
> This allows us to get rid of the LIB82596_DMA_ATTR defined and prepare
> for untangling the coherent vs non-coherent DMA allocation API.
>
> Signed-off-by: Christoph Hellwig
> ---
> drivers/net/ethernet/i825xx/lasi_82596.c |
On Tue, Sep 01, 2020 at 07:52:40AM -0700, James Bottomley wrote:
> I think this looks mostly OK, except for one misnamed parameter below.
> Unfortunately, the last non-coherent parisc was the 700 series and I no
> longer own a box, so I can't test that part of it (I can fire up the
> C360 to test
On 2020-08-26 07:32, Marek Szyprowski wrote:
The Documentation/DMA-API-HOWTO.txt states that the dma_map_sg() function
returns the number of the created entries in the DMA address space.
However the subsequent calls to the dma_sync_sg_for_{device,cpu}() and
dma_unmap_sg must be called with the
On 2020-08-26 07:32, Marek Szyprowski wrote:
The Documentation/DMA-API-HOWTO.txt states that the dma_map_sg() function
returns the number of the created entries in the DMA address space.
However the subsequent calls to the dma_sync_sg_for_{device,cpu}() and
dma_unmap_sg must be called with the
On 2020-08-26 07:32, Marek Szyprowski wrote:
Use common helper for checking the contiguity of the imported dma-buf and
do this check before allocating resources, so the error path is simpler.
Reviewed-by: Robin Murphy
Signed-off-by: Marek Szyprowski
---
On 2020-08-26 07:32, Marek Szyprowski wrote:
The Documentation/DMA-API-HOWTO.txt states that the dma_map_sg() function
returns the number of the created entries in the DMA address space.
However the subsequent calls to the dma_sync_sg_for_{device,cpu}() and
dma_unmap_sg must be called with the
>-Original Message-
>From: Intel-gfx On Behalf Of
>Marek Szyprowski
>Sent: Wednesday, August 26, 2020 2:33 AM
>To: dri-de...@lists.freedesktop.org; iommu@lists.linux-foundation.org;
>linaro-mm-...@lists.linaro.org; linux-ker...@vger.kernel.org
>Cc: Bartlomiej Zolnierkiewicz ; David Airlie
On 2020-09-01 20:38, Ruhl, Michael J wrote:
-Original Message-
From: Intel-gfx On Behalf Of
Marek Szyprowski
Sent: Wednesday, August 26, 2020 2:33 AM
To: dri-de...@lists.freedesktop.org; iommu@lists.linux-foundation.org;
linaro-mm-...@lists.linaro.org; linux-ker...@vger.kernel.org
Cc:
On 2020-08-26 07:33, Marek Szyprowski wrote:
The Documentation/DMA-API-HOWTO.txt states that the dma_map_sg() function
returns the number of the created entries in the DMA address space.
However the subsequent calls to the dma_sync_sg_for_{device,cpu}() and
dma_unmap_sg must be called with the
On 2020-08-26 07:33, Marek Szyprowski wrote:
The Documentation/DMA-API-HOWTO.txt states that the dma_map_sg() function
returns the number of the created entries in the DMA address space.
However the subsequent calls to the dma_sync_sg_for_{device,cpu}() and
dma_unmap_sg must be called with the
On 2020-08-26 07:33, Marek Szyprowski wrote:
The Documentation/DMA-API-HOWTO.txt states that the dma_map_sg() function
returns the number of the created entries in the DMA address space.
However the subsequent calls to the dma_sync_sg_for_{device,cpu}() and
dma_unmap_sg must be called with the
On 2020-08-26 07:32, Marek Szyprowski wrote:
The Documentation/DMA-API-HOWTO.txt states that the dma_map_sg() function
returns the number of the created entries in the DMA address space.
However the subsequent calls to the dma_sync_sg_for_{device,cpu}() and
dma_unmap_sg must be called with the
On 2020-08-26 07:32, Marek Szyprowski wrote:
The Documentation/DMA-API-HOWTO.txt states that the dma_map_sg() function
returns the number of the created entries in the DMA address space.
However the subsequent calls to the dma_sync_sg_for_{device,cpu}() and
dma_unmap_sg must be called with the
On 2020-08-26 07:33, Marek Szyprowski wrote:
Use common helper for checking the contiguity of the imported dma-buf.
Reviewed-by: Robin Murphy
Signed-off-by: Marek Szyprowski
---
drivers/gpu/drm/rockchip/rockchip_drm_gem.c | 19 +--
1 file changed, 1 insertion(+), 18
On 2020-08-26 07:33, Marek Szyprowski wrote:
The Documentation/DMA-API-HOWTO.txt states that the dma_map_sg() function
returns the number of the created entries in the DMA address space.
However the subsequent calls to the dma_sync_sg_for_{device,cpu}() and
dma_unmap_sg must be called with the
On 2020-08-26 07:33, Marek Szyprowski wrote:
The Documentation/DMA-API-HOWTO.txt states that the dma_map_sg() function
returns the number of the created entries in the DMA address space.
However the subsequent calls to the dma_sync_sg_for_{device,cpu}() and
dma_unmap_sg must be called with the
01.09.2020 20:13, Dmitry Osipenko пишет:
...
> + /*
> + * In order to prevent exhaustion of the atomic memory pool, we
> + * allocate page in a sleeping context if GFP flags permit. Hence
> + * spinlock needs to be unlocked and re-locked after allocation.
> + */
> + if
On 2020-08-26 07:32, Marek Szyprowski wrote:
Use common helper for converting a sg_table object into struct
page pointer array.
Reviewed-by: Robin Murphy
Side note: is mtk_drm_gem_prime_vmap() missing a call to
sg_free_table(sgt) before its kfree(sgt)?
Signed-off-by: Marek Szyprowski
On 2020-08-26 07:32, Marek Szyprowski wrote:
Use common helper for converting a sg_table object into struct
page pointer array.
Signed-off-by: Marek Szyprowski
---
drivers/gpu/drm/omapdrm/omap_gem.c | 14 --
1 file changed, 4 insertions(+), 10 deletions(-)
diff --git
On 2020-08-26 07:33, Marek Szyprowski wrote:
The Documentation/DMA-API-HOWTO.txt states that the dma_map_sg() function
returns the number of the created entries in the DMA address space.
However the subsequent calls to the dma_sync_sg_for_{device,cpu}() and
dma_unmap_sg must be called with the
On 2020-08-26 07:33, Marek Szyprowski wrote:
Use recently introduced common wrappers operating directly on the struct
sg_table objects and scatterlist page iterators to make the code a bit
more compact, robust, easier to follow and copy/paste safe.
No functional change, because the code already
On 2020-08-26 07:33, Marek Szyprowski wrote:
The Documentation/DMA-API-HOWTO.txt states that dma_map_sg returns the
numer of the created entries in the DMA address space. However the
subsequent calls to dma_sync_sg_for_{device,cpu} and dma_unmap_sg must be
called with the original number of
>-Original Message-
>From: Robin Murphy
>Sent: Tuesday, September 1, 2020 3:54 PM
>To: Ruhl, Michael J ; Marek Szyprowski
>; dri-de...@lists.freedesktop.org;
>iommu@lists.linux-foundation.org; linaro-mm-...@lists.linaro.org; linux-
>ker...@vger.kernel.org
>Cc: Bartlomiej Zolnierkiewicz ;
The mapping operations of the Tegra SMMU driver are subjected to a race
condition issues because SMMU Address Space isn't allocated and freed
atomically, while it should be. This patch makes the mapping operations
atomic, it fixes an accidentally released Host1x Address Space problem
which happens
On Mon, 24 Aug 2020 10:24:11 +0800
Lu Baolu wrote:
> Hi Jacob,
>
> On 8/22/20 12:35 PM, Jacob Pan wrote:
> > ioasid_set was introduced as an arbitrary token that are shared by a
> > group of IOASIDs. For example, if IOASID #1 and #2 are allocated
> > via the same ioasid_set*, they are viewed as
92 matches
Mail list logo
