> From: Liu, Yi L
> Sent: Saturday, June 27, 2020 2:53 PM
>
> Hi Robin,
>
> > From: Robin Murphy
> > Sent: Saturday, June 27, 2020 12:05 AM
> >
> > On 2020-06-26 08:47, Jean-Philippe Brucker wrote:
> > > On Wed, Jun 24, 2020 at 01:55:15AM -0700, Liu Yi L wrote:
> > >> IOMMUs that support
Add a new (optional) field to denote the physical location of a device
in the system, and expose it in sysfs. This was discussed here:
https://lore.kernel.org/linux-acpi/20200618184621.ga446...@kroah.com/
(The primary choice for attribute name i.e. "location" is already
exposed as an ABI
> From: Jacob Pan
> Sent: Tuesday, June 30, 2020 7:05 AM
>
> On Fri, 26 Jun 2020 16:19:23 -0600
> Alex Williamson wrote:
>
> > On Tue, 23 Jun 2020 10:03:53 -0700
> > Jacob Pan wrote:
> >
> > > IOMMU UAPI is newly introduced to support communications between
> > > guest virtual IOMMU and host
On Thu, 25 Jun 2020 15:25:57 +0800
Lu Baolu wrote:
> On 2020/6/23 23:43, Jacob Pan wrote:
> > DevTLB flush can be used for both DMA request with and without
> > PASIDs. The former uses PASID#0 (RID2PASID), latter uses non-zero
> > PASID for SVA usage.
> >
> > This patch adds a check for PASID
Currently this is being looked up at a number of places. Read and store it
once at bootup so that it can be used by all later.
Signed-off-by: Rajat Jain
---
v2: Commit log cosmetic changes
drivers/pci/p2pdma.c | 2 +-
drivers/pci/pci.c| 21 +
drivers/pci/pci.h| 2
The firmware was provinding "ExternalFacing" attribute on PCI root ports,
to allow the kernel to mark devices behind it as external. Note that the
firmware provides an immutable, read-only property, i.e. the location of
the device.
The use of (external) device location as hint for (dis)trust, is
The "ExternalFacing" devices (root ports) are still internal devices that
sit on the internal system fabric and thus trusted. Currently they were
being marked untrusted.
This patch uses the platform flag to identify the external facing devices
and then use it to mark any downstream devices as
This is a set of loosely related patches most of whom emerged out of
discussion in the following threads. In a nutshell the goal was to allow
an administrator to specify which driver he wants to allow on external
ports, and a strategy was chalked out:
>> +static irqreturn_t nvidia_smmu_context_fault_bank(int irq,
>> + void __iomem *cb_base = nvidia_smmu_page(smmu, inst,
>> + smmu->numpage + idx);
[...]
>> + fsr = arm_smmu_cb_read(smmu, idx, ARM_SMMU_CB_FSR);
[...]
>> + writel_relaxed(fsr, cb_base + ARM_SMMU_CB_FSR);
>It reads FSR
On Fri, 26 Jun 2020, Michael S. Tsirkin wrote:
> On Thu, Jun 25, 2020 at 10:31:27AM -0700, Stefano Stabellini wrote:
> > On Wed, 24 Jun 2020, Michael S. Tsirkin wrote:
> > > On Wed, Jun 24, 2020 at 02:53:54PM -0700, Stefano Stabellini wrote:
> > > > On Wed, 24 Jun 2020, Michael S. Tsirkin wrote:
>
On Mon, Jun 29, 2020 at 05:10:51PM -0700, Krishna Reddy wrote:
> Add global/context fault hooks to allow NVIDIA SMMU implementation
> handle faults across multiple SMMUs.
>
> Signed-off-by: Krishna Reddy
Reviewed-by: Nicolin Chen
___
iommu mailing
On 2020/6/29 17:05, Lorenzo Pieralisi wrote:
On Mon, Jun 29, 2020 at 12:24:43PM +0800, Hanjun Guo wrote:
Hi Lorenzo,
On 2020/6/19 16:20, Lorenzo Pieralisi wrote:
When the iort_match_node_callback is invoked for a named component
the match should be executed upon a device with an ACPI
On Tue, 30 Jun 2020 03:01:29 +
"Tian, Kevin" wrote:
> > From: Lu Baolu
> > Sent: Thursday, June 25, 2020 3:26 PM
> >
> > On 2020/6/23 23:43, Jacob Pan wrote:
> > > DevTLB flush can be used for both DMA request with and without
> > > PASIDs. The former uses PASID#0 (RID2PASID), latter
When enabling ACS, enable translation blocking for external facing ports
and untrusted devices.
Signed-off-by: Rajat Jain
---
v2: Commit log change
drivers/pci/pci.c| 4
drivers/pci/quirks.c | 11 +++
2 files changed, 15 insertions(+)
diff --git a/drivers/pci/pci.c
device_attach() returning failure indicates a driver error while trying to
probe the device. In such a scenario, the PCI device should still be added
in the system and be visible to the user.
This patch partially reverts:
commit ab1a187bba5c ("PCI: Check device_attach() return value always")
Hi Robin,
On 6/29/20 7:56 PM, Robin Murphy wrote:
On 2020-06-27 04:15, Lu Baolu wrote:
The hardware assistant vfio mediated device is a use case of iommu
aux-domain. The interactions between vfio/mdev and iommu during mdev
creation and passthr are:
- Create a group for mdev with
> Subject: RE: [PATCH] xen: introduce xen_vring_use_dma
>
> On Mon, 29 Jun 2020, Peng Fan wrote:
> > > > If that is the case, how is it possible that virtio breaks on ARM
> > > > using the default dma_ops? The breakage is not Xen related (except
> > > > that Xen turns dma_ops on). The original
On Mon, Jun 29, 2020 at 10:49:31PM +, Krishna Reddy wrote:
> >> + if (!nvidia_smmu->bases[0])
> >> + nvidia_smmu->bases[0] = smmu->base;
> >> +
> >> + return nvidia_smmu->bases[inst] + (page << smmu->pgshift); }
>
> >Not critical -- just a nit: why not put the bases[0] in
Changes in v8:
Fixed incorrect CB_FSR read issue during context bank fault.
Rebased and validated patches on top of
git://git.kernel.org/pub/scm/linux/kernel/git/joro/iommu.git next
v7 - https://lkml.org/lkml/2020/6/28/347
v6 - https://lkml.org/lkml/2020/6/4/1018
v5 -
NVIDIA's Tegra194 SoC uses two ARM MMU-500s together to interleave
IOVA accesses across them.
Add NVIDIA implementation for dual ARM MMU-500s and add new compatible
string for Tegra194 SoC SMMU topology.
Signed-off-by: Krishna Reddy
---
MAINTAINERS | 2 +
Add global/context fault hooks to allow NVIDIA SMMU implementation
handle faults across multiple SMMUs.
Signed-off-by: Krishna Reddy
---
drivers/iommu/arm-smmu-nvidia.c | 98 +
drivers/iommu/arm-smmu.c| 17 +-
drivers/iommu/arm-smmu.h| 3 +
3
Add binding for NVIDIA's Tegra194 SoC SMMU topology that is based
on ARM MMU-500.
Signed-off-by: Krishna Reddy
---
Documentation/devicetree/bindings/iommu/arm,smmu.yaml | 5 +
1 file changed, 5 insertions(+)
diff --git a/Documentation/devicetree/bindings/iommu/arm,smmu.yaml
> From: Lu Baolu
> Sent: Thursday, June 25, 2020 3:26 PM
>
> On 2020/6/23 23:43, Jacob Pan wrote:
> > DevTLB flush can be used for both DMA request with and without PASIDs.
> > The former uses PASID#0 (RID2PASID), latter uses non-zero PASID for SVA
> > usage.
> >
> > This patch adds a check for
> From: Tian, Kevin
> Sent: Tuesday, June 30, 2020 10:01 AM
>
> > From: Liu, Yi L
> > Sent: Monday, June 29, 2020 8:23 PM
> >
> > Hi Stefan,
> >
> > > From: Stefan Hajnoczi
> > > Sent: Monday, June 29, 2020 5:25 PM
> > >
> > > On Wed, Jun 24, 2020 at 01:55:15AM -0700, Liu Yi L wrote:
> > > >
On Mon, 29 Jun 2020, Peng Fan wrote:
> > > If that is the case, how is it possible that virtio breaks on ARM
> > > using the default dma_ops? The breakage is not Xen related (except
> > > that Xen turns dma_ops on). The original message from Peng was:
> > >
> > > vring_map_one_sg ->
On Mon, Jun 29, 2020 at 05:10:49PM -0700, Krishna Reddy wrote:
> NVIDIA's Tegra194 SoC uses two ARM MMU-500s together to interleave
> IOVA accesses across them.
> Add NVIDIA implementation for dual ARM MMU-500s and add new compatible
> string for Tegra194 SoC SMMU topology.
>
> Signed-off-by:
> From: Liu, Yi L
> Sent: Monday, June 29, 2020 8:23 PM
>
> Hi Stefan,
>
> > From: Stefan Hajnoczi
> > Sent: Monday, June 29, 2020 5:25 PM
> >
> > On Wed, Jun 24, 2020 at 01:55:15AM -0700, Liu Yi L wrote:
> > > +/*
> > > + * struct iommu_nesting_info - Information for nesting-capable IOMMU.
>
Introduce a PCI parameter that disables the automatic attachment of
external devices to their drivers.
This is needed to allow an admin to control which drivers he wants to
allow on external ports. For more context, see threads at:
On Mon, Jun 29, 2020 at 05:18:38PM +0200, Daniel Borkmann wrote:
> On 6/29/20 5:10 PM, Björn Töpel wrote:
>> On 2020-06-29 15:52, Daniel Borkmann wrote:
>>>
>>> Ok, fair enough, please work with DMA folks to get this properly integrated
>>> and
>>> restored then. Applied, thanks!
>>
>> Daniel,
On Sun, Jun 28, 2020 at 07:28:38PM -0700, Krishna Reddy wrote:
> Add global/context fault hooks to allow NVIDIA SMMU implementation
> handle faults across multiple SMMUs.
>
> Signed-off-by: Krishna Reddy
> +static irqreturn_t nvidia_smmu_global_fault_inst(int irq,
> +
>> + if (!nvidia_smmu->bases[0])
>> + nvidia_smmu->bases[0] = smmu->base;
>> +
>> + return nvidia_smmu->bases[inst] + (page << smmu->pgshift); }
>Not critical -- just a nit: why not put the bases[0] in init()?
smmu->base is not available during nvidia_smmu_impl_init() call.
On Fri, 26 Jun 2020 16:19:23 -0600
Alex Williamson wrote:
> On Tue, 23 Jun 2020 10:03:53 -0700
> Jacob Pan wrote:
>
> > IOMMU UAPI is newly introduced to support communications between
> > guest virtual IOMMU and host IOMMU. There has been lots of
> > discussions on how it should work with
On Sun, Jun 28, 2020 at 07:28:36PM -0700, Krishna Reddy wrote:
> NVIDIA's Tegra194 SoC uses two ARM MMU-500s together to interleave
> IOVA accesses across them.
> Add NVIDIA implementation for dual ARM MMU-500s and add new compatible
> string for Tegra194 SoC SMMU topology.
>
> Signed-off-by:
On Mon, Jun 29, 2020 at 03:05:19AM +, Peng Fan wrote:
> > Subject: Re: [PATCH] xen: introduce xen_vring_use_dma
> >
> > On Thu, Jun 25, 2020 at 10:31:27AM -0700, Stefano Stabellini wrote:
> > > On Wed, 24 Jun 2020, Michael S. Tsirkin wrote:
> > > > On Wed, Jun 24, 2020 at 02:53:54PM -0700,
On Mon, Jun 29, 2020 at 12:24:43PM +0800, Hanjun Guo wrote:
> Hi Lorenzo,
>
> On 2020/6/19 16:20, Lorenzo Pieralisi wrote:
> > When the iort_match_node_callback is invoked for a named component
> > the match should be executed upon a device with an ACPI companion.
> >
> > For devices with no
> From: Stefan Hajnoczi
> Sent: Monday, June 29, 2020 5:22 PM
>
> On Wed, Jun 24, 2020 at 01:55:26AM -0700, Liu Yi L wrote:
> > +Details can be found in Documentation/userspace-api/iommu.rst. For
> > +Intel VT-d, each stage 1 page table is bound to host by:
> > +
> > +nesting_op->flags =
On Wed, Jun 24, 2020 at 01:55:15AM -0700, Liu Yi L wrote:
> +/*
> + * struct iommu_nesting_info - Information for nesting-capable IOMMU.
> + * user space should check it before using
> + * nesting capability.
> + *
> + * @size:size of the
> Subject: Re: [PATCH] xen: introduce xen_vring_use_dma
>
> On Mon, Jun 29, 2020 at 03:05:19AM +, Peng Fan wrote:
> > > Subject: Re: [PATCH] xen: introduce xen_vring_use_dma
> > >
> > > On Thu, Jun 25, 2020 at 10:31:27AM -0700, Stefano Stabellini wrote:
> > > > On Wed, 24 Jun 2020, Michael S.
On 29/06/2020 09:13, Chao Hao wrote:
> Add F_MMU_IN_ORDER_WR_EN and F_MMU_STANDARD_AXI_MODE_BIT definition
> in MISC_CTRL register.
> F_MMU_STANDARD_AXI_MODE_BIT:
> If we set F_MMU_STANDARD_AXI_MODE_BIT(bit[3][19] = 0, not follow
> standard AXI protocol), iommu will send urgent read command
> Subject: Re: [PATCH] xen: introduce xen_vring_use_dma
>
> On Mon, Jun 29, 2020 at 06:25:41AM +, Peng Fan wrote:
> > > > > > Anyway, re-reading the last messages of the original thread
> > > > > > [1], it looks like Peng had a clear idea on how to fix the general
> > > > > > issue.
> > > >
For mt6779, MMU_INV_SEL register's offset is changed from
0x38 to 0x2c, so we can put inv_sel_reg in the plat_data to
use it.
In addition, we renamed it to REG_MMU_INV_SEL_GEN1 and use it
before mt6779.
Cc: Yong Wu
Signed-off-by: Chao Hao
Reviewed-by: Matthias Brugger
---
Some platforms(ex: mt6779) need to improve performance by setting
REG_MMU_WR_LEN register. And we can use WR_THROT_EN macro to control
whether we need to set the register. If the register uses default value,
iommu will send command to EMI without restriction, when the number of
commands become
This patch adds description for MT6779 IOMMU.
MT6779 has two iommus, they are mm_iommu and apu_iommu which
both use ARM Short-Descriptor translation format.
In addition, mm_iommu and apu_iommu are two independent HW instance
, we need to set them separately.
The MT6779 IOMMU hardware diagram is
MT8173 is different from other SoCs for MMU_CTRL register.
For mt8173, its bit9 is in_order_write_en and doesn't use its
default 1'b1.
For other SoCs, bit[12] represents victim_tlb_en feature and
victim_tlb is enable defaultly(bit[12]=1), if we use
"regval = F_MMU_TF_PROT_TO_PROGRAM_ADDR",
Joerg Roedel writes:
> From: Joerg Roedel
>
> There are no users left, so remove the pointer and save some memory.
>
> Signed-off-by: Joerg Roedel
> ---
> arch/powerpc/include/asm/device.h | 3 ---
> 1 file changed, 3 deletions(-)
It's a little hard to confirm there are no users left just
On Mon, Jun 29, 2020 at 06:25:41AM +, Peng Fan wrote:
> > > > > Anyway, re-reading the last messages of the original thread [1],
> > > > > it looks like Peng had a clear idea on how to fix the general issue.
> > > > > Peng, what happened with that?
> > >
> > > We shrinked the rpmsg reserved
On 25.06.2020 15:08, Joerg Roedel wrote:
> From: Joerg Roedel
>
> Remove the use of dev->archdata.iommu and use the private per-device
> pointer provided by IOMMU core code instead.
>
> Signed-off-by: Joerg Roedel
Acked-by: Marek Szyprowski
> ---
> drivers/iommu/exynos-iommu.c
On Sat, Jun 27, 2020 at 09:25:21PM -0700, David Rientjes wrote:
> Thanks Guenter. Christoph, does it make sense to apply this patch since
> there may not be an artifact left behind in the kernel log on allocation
> failure by the caller?
Sorry, this fell through the cracks. I've added it to
On 29/06/2020 09:13, Chao Hao wrote:
> Given the fact that we are adding more and more plat_data bool values,
> it would make sense to use a u32 flags register and add the appropriate
> macro definitions to set and check for a flag present.
> No functional change.
>
> Suggested-by: Matthias
On Sat, Jun 27, 2020 at 06:13:43PM +0200, Marion & Christophe JAILLET wrote:
> I'm sorry, but I will not send pci_ --> dma_ conversion for this driver.
> I'm a bit puzzled by some choice of GFP_KERNEL and GFP_ATOMIC that not all
> that obvious to me.
>
> I'll try to send some patches for other
This patchset adds mt6779 iommu support.
mt6779 has two iommus, they are MM_IOMMU(M4U) and APU_IOMMU which used ARM
Short-Descriptor translation format.
The mt6779's MM_IOMMU-SMI and APU_IOMMU HW diagram is as below, it is only a
brief diagram:
EMI
Given the fact that we are adding more and more plat_data bool values,
it would make sense to use a u32 flags register and add the appropriate
macro definitions to set and check for a flag present.
No functional change.
Suggested-by: Matthias Brugger
Signed-off-by: Chao Hao
---
The max larb number that a iommu HW support is 8(larb0~larb7 in the below
diagram).
If the larb's number is over 8, we use a sub_common for merging
several larbs into one larb. At this case, we will extend larb_id:
bit[11:9] means common-id;
bit[8:7] means subcommon-id;
>From these two variables,
Starting with mt6779, iommu needs to extend to 256 bytes from 128
bytes which can send the max number of data for memory protection
pa alignment. So we can use a separate patch to modify it.
Suggested-by: Matthias Brugger
Signed-off-by: Chao Hao
---
drivers/iommu/mtk_iommu.c | 2 +-
1 file
Add F_MMU_IN_ORDER_WR_EN and F_MMU_STANDARD_AXI_MODE_BIT definition
in MISC_CTRL register.
F_MMU_STANDARD_AXI_MODE_BIT:
If we set F_MMU_STANDARD_AXI_MODE_BIT(bit[3][19] = 0, not follow
standard AXI protocol), iommu will send urgent read command firstly
compare with normal read command to improve
1. Start from mt6779, INVLDT_SEL move to offset=0x2c, so we add
REG_MMU_INV_SEL_GEN2 definition and mt6779 uses it.
2. Add mt6779_data to support mm_iommu HW init.
Cc: Yong Wu
Cc: Matthias Brugger
Signed-off-by: Chao Hao
---
drivers/iommu/mtk_iommu.c | 11 +++
For iommu offset=0x48 register, only the previous mt8173/mt8183 use the
name STANDARD_AXI_MODE, all the latest SoC extend the register more
feature by different bits, for example: axi_mode, in_order_en, coherent_en
and so on. So rename REG_MMU_MISC_CTRL may be more proper.
This patch only rename
On Wed, Jun 24, 2020 at 01:55:26AM -0700, Liu Yi L wrote:
> +Details can be found in Documentation/userspace-api/iommu.rst. For Intel
> +VT-d, each stage 1 page table is bound to host by:
> +
> +nesting_op->flags = VFIO_IOMMU_NESTING_OP_BIND_PGTBL;
> +memcpy(_op->data, _data,
On 29/06/2020 09:13, Chao Hao wrote:
> Some platforms(ex: mt6779) need to improve performance by setting
> REG_MMU_WR_LEN register. And we can use WR_THROT_EN macro to control
> whether we need to set the register. If the register uses default value,
> iommu will send command to EMI without
On 29/06/2020 09:13, Chao Hao wrote:
> Starting with mt6779, iommu needs to extend to 256 bytes from 128
> bytes which can send the max number of data for memory protection
> pa alignment. So we can use a separate patch to modify it.
>
> Suggested-by: Matthias Brugger
> Signed-off-by: Chao
On 29/06/2020 09:13, Chao Hao wrote:
> 1. Start from mt6779, INVLDT_SEL move to offset=0x2c, so we add
>REG_MMU_INV_SEL_GEN2 definition and mt6779 uses it.
> 2. Add mt6779_data to support mm_iommu HW init.
>
> Cc: Yong Wu
> Cc: Matthias Brugger
> Signed-off-by: Chao Hao
Reviewed by:
On 29/06/2020 09:13, Chao Hao wrote:
> MT8173 is different from other SoCs for MMU_CTRL register.
> For mt8173, its bit9 is in_order_write_en and doesn't use its
> default 1'b1.> For other SoCs, bit[12] represents victim_tlb_en feature and
> victim_tlb is enable defaultly(bit[12]=1), if we use
On 2020-06-27 04:15, Lu Baolu wrote:
The hardware assistant vfio mediated device is a use case of iommu
aux-domain. The interactions between vfio/mdev and iommu during mdev
creation and passthr are:
- Create a group for mdev with iommu_group_alloc();
- Add the device to the group with
Hi Stefan,
> From: Stefan Hajnoczi
> Sent: Monday, June 29, 2020 5:25 PM
>
> On Wed, Jun 24, 2020 at 01:55:15AM -0700, Liu Yi L wrote:
> > +/*
> > + * struct iommu_nesting_info - Information for nesting-capable IOMMU.
> > + * user space should check it before using
> > +
On 2020-06-27 08:02, Christoph Hellwig wrote:
On Fri, Jun 26, 2020 at 01:54:12PM -0700, Jonathan Lemon wrote:
On Fri, Jun 26, 2020 at 09:47:25AM +0200, Christoph Hellwig wrote:
Note that this is somewhat urgent, as various of the APIs that the code
is abusing are slated to go away for Linux
On 6/28/20 7:16 PM, Björn Töpel wrote:
On 2020-06-27 09:04, Christoph Hellwig wrote:
On Sat, Jun 27, 2020 at 01:00:19AM +0200, Daniel Borkmann wrote:
Given there is roughly a ~5 weeks window at max where this removal could
still be applied in the worst case, could we come up with a fix /
Hi all,
this series lifts the somewhat hacky checks in the XSK code if a DMA
streaming mapping needs dma_sync_single_for_{device,cpu} calls to the
DMA API.
Diffstat:
Documentation/core-api/dma-api.rst |8 +
include/linux/dma-direct.h |1
include/linux/dma-mapping.h
Use the dma_need_sync helper instead of (not always entirely correctly)
poking into the dma-mapping internals.
Signed-off-by: Christoph Hellwig
---
net/xdp/xsk_buff_pool.c | 50 +++--
1 file changed, 3 insertions(+), 47 deletions(-)
diff --git
Invert the polarity and better name the flag so that the use case is
properly documented.
Signed-off-by: Christoph Hellwig
---
include/net/xsk_buff_pool.h | 6 +++---
net/xdp/xsk_buff_pool.c | 5 ++---
2 files changed, 5 insertions(+), 6 deletions(-)
diff --git
Add a new API to check if calls to dma_sync_single_for_{device,cpu} are
required for a given DMA streaming mapping.
Signed-off-by: Christoph Hellwig
---
Documentation/core-api/dma-api.rst | 8
include/linux/dma-direct.h | 1 +
include/linux/dma-mapping.h| 5 +
->dev is already assigned at the top of the function, remove the duplicate
one at the end.
Signed-off-by: Christoph Hellwig
---
net/xdp/xsk_buff_pool.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/net/xdp/xsk_buff_pool.c b/net/xdp/xsk_buff_pool.c
index 9fe84c797a7060..6733e2c59e4835
On Mon, Jun 29, 2020 at 02:11:46PM +0200, Geert Uytterhoeven wrote:
> If NO_DMA=y (e.g. Sun-3 all{mod,yes}-config):
>
> drivers/iommu/dma-iommu.o: In function `iommu_dma_mmap':
> dma-iommu.c:(.text+0x92e): undefined reference to `dma_pgprot'
>
> IOMMU_DMA must not be selected, unless
On 2020-06-29 15:03, Christoph Hellwig wrote:
Hi all,
this series lifts the somewhat hacky checks in the XSK code if a DMA
streaming mapping needs dma_sync_single_for_{device,cpu} calls to the
DMA API.
Thanks a lot for working on, and fixing this, Christoph!
I took the series for a spin,
If NO_DMA=y (e.g. Sun-3 all{mod,yes}-config):
drivers/iommu/dma-iommu.o: In function `iommu_dma_mmap':
dma-iommu.c:(.text+0x92e): undefined reference to `dma_pgprot'
IOMMU_DMA must not be selected, unless HAS_DMA=y.
Hence fix this by making SUN50I_IOMMU depend on HAS_DMA.
Fixes:
> On May 18, 2020, at 23:32, Kai-Heng Feng wrote:
>
>
>
>> On May 18, 2020, at 22:05, Kai-Heng Feng wrote:
>>
>>
>>
>>> On May 18, 2020, at 21:32, Joerg Roedel wrote:
>>>
>>> On Mon, May 18, 2020 at 05:06:45PM +0800, Kai-Heng Feng wrote:
Particularly, as soon as the spinlock is
On 2020-06-29 15:52, Daniel Borkmann wrote:
Ok, fair enough, please work with DMA folks to get this properly
integrated and
restored then. Applied, thanks!
Daniel, you were too quick! Please revert this one; Christoph just
submitted a 4-patch-series that addresses both the DMA API, and the
On 2020-06-28 18:16, Björn Töpel wrote:
On 2020-06-27 09:04, Christoph Hellwig wrote:
On Sat, Jun 27, 2020 at 01:00:19AM +0200, Daniel Borkmann wrote:
Given there is roughly a ~5 weeks window at max where this removal could
still be applied in the worst case, could we come up with a fix /
Use of_match_node() to match qcom implementation instead
of multiple of_device_compatible() calls for each qcom
implementation.
Signed-off-by: Sai Prakash Ranjan
---
drivers/iommu/arm-smmu-impl.c | 9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git
Add iommu domain attribute for using system cache aka last level
cache by client drivers like GPU to set right attributes for caching
the hardware pagetables into the system cache.
Signed-off-by: Sai Prakash Ranjan
---
drivers/iommu/arm-smmu.c | 17 +
drivers/iommu/arm-smmu.h |
From: Sharat Masetty
The last level system cache can be partitioned to 32 different
slices of which GPU has two slices preallocated. One slice is
used for caching GPU buffers and the other slice is used for
caching the GPU SMMU pagetables. This talks to the core system
cache driver to acquire
From: Sharat Masetty
The register read-modify-write construct is generic enough
that it can be used by other subsystems as needed, create
a more generic rmw() function and have the gpu_rmw() use
this new function.
Signed-off-by: Sharat Masetty
Reviewed-by: Jordan Crouse
Signed-off-by: Sai
There are few places in arm-smmu-impl where there are
extra blank lines, remove them and while at it fix the
checkpatch warning for space required before the open
parenthesis.
Signed-off-by: Sai Prakash Ranjan
---
drivers/iommu/arm-smmu-impl.c | 6 +-
1 file changed, 1 insertion(+), 5
Add a quirk IO_PGTABLE_QUIRK_SYS_CACHE to override the
attributes set in TCR for the page table walker when
using system cache.
Signed-off-by: Sai Prakash Ranjan
---
drivers/iommu/io-pgtable-arm.c | 7 ++-
include/linux/io-pgtable.h | 4
2 files changed, 10 insertions(+), 1
From: Jordan Crouse
Add a new implementation hook to allow the implementation specific code
to tweek the context bank configuration just before it gets written.
The first user will be the Adreno GPU implementation to turn on
SCTLR.HUPCF to ensure that a page fault doesn't terminating pending
On 2020-06-29 13:11, Geert Uytterhoeven wrote:
If NO_DMA=y (e.g. Sun-3 all{mod,yes}-config):
drivers/iommu/dma-iommu.o: In function `iommu_dma_mmap':
dma-iommu.c:(.text+0x92e): undefined reference to `dma_pgprot'
IOMMU_DMA must not be selected, unless HAS_DMA=y.
Wait, no, IOMMU_DMA
On Sat, Jun 27, 2020 at 01:11:14PM -0700, Rob Clark wrote:
> On Sat, Jun 27, 2020 at 12:56 PM Rob Clark wrote:
> >
> > On Fri, Jun 26, 2020 at 1:04 PM Jordan Crouse
> > wrote:
> > >
> > > Add support for using per-instance pagetables if all the dependencies are
> > > available.
> > >
> > >
On Mon, Jun 29, 2020 at 03:39:01PM +0200, Björn Töpel wrote:
> On 2020-06-29 15:03, Christoph Hellwig wrote:
>> Hi all,
>>
>> this series lifts the somewhat hacky checks in the XSK code if a DMA
>> streaming mapping needs dma_sync_single_for_{device,cpu} calls to the
>> DMA API.
>>
>
> Thanks a
On Sat, Jun 27, 2020 at 10:10:14AM -0700, Rob Clark wrote:
> On Fri, Jun 26, 2020 at 1:01 PM Jordan Crouse wrote:
> >
> > 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
On 6/29/20 5:10 PM, Björn Töpel wrote:
On 2020-06-29 15:52, Daniel Borkmann wrote:
Ok, fair enough, please work with DMA folks to get this properly integrated and
restored then. Applied, thanks!
Daniel, you were too quick! Please revert this one; Christoph just submitted a
4-patch-series
Some hardware variants contain a system cache or the last level
cache(llc). This cache is typically a large block which is shared
by multiple clients on the SOC. GPU uses the system cache to cache
both the GPU data buffers(like textures) as well the SMMU pagetables.
This helps with improved render
On 2020-06-29 17:18, Daniel Borkmann wrote:
Nice, tossed from bpf tree then! (Looks like it didn't land on the bpf
list yet,
but seems other mails are currently stuck as well on vger. I presume it
will be
routed to Linus via Christoph?)
Thanks!
Christoph (according to the other mail) was
91 matches
Mail list logo
