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
Hi Alex,
On 22.09.2020 01:15, Alex Goins wrote:
> Tested-by: Alex Goins
>
> This change fixes a regression with drm_prime_sg_to_page_addr_arrays() and
> AMDGPU in v5.9.
Thanks for testing!
> Commit 39913934 similarly revamped AMDGPU to use sgtable helper functions.
> When
> it changed from dma
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/arm-smmu/arm-smmu.c | 17 +
drivers/iommu/a
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 Prak
Fix the checkpatch warning for space required before the open
parenthesis.
Signed-off-by: Sai Prakash Ranjan
---
drivers/iommu/arm/arm-smmu/arm-smmu-impl.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/iommu/arm/arm-smmu/arm-smmu-impl.c
b/drivers/iommu/arm/arm-smmu
Hi Will,
On 2020-09-21 23:33, Will Deacon wrote:
On Fri, Sep 11, 2020 at 07:57:18PM +0530, Sai Prakash Ranjan wrote:
Add a quirk IO_PGTABLE_QUIRK_SYS_CACHE to override the
attributes set in TCR for the page table walker when
using system cache.
I wonder if the panfrost folks can reuse this fo
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 the
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 deletion
Use table and of_match_node() to match qcom implementation
instead of multiple of_device_compatible() calls for each
QCOM SMMU implementation.
Signed-off-by: Sai Prakash Ranjan
---
drivers/iommu/arm/arm-smmu/arm-smmu-impl.c | 12
1 file changed, 8 insertions(+), 4 deletions(-)
diff
Hi Jorge and Alex,
A description of this patch series could be found here.
https://lore.kernel.org/linux-iommu/20200901033422.22249-1-baolu...@linux.intel.com/
This version adds some changes according to Alex's review comments.
- Add comments and naming rule for subdevices.
https://lore.kernel.
The device driver needs an API to get its aux-domain. A typical usage
scenario is:
unsigned long pasid;
struct iommu_domain *domain;
struct device *dev = mdev_dev(mdev);
struct device *iommu_device = vfio_mdev_get_iommu_device(dev);
domain = iommu_aux_get_d
With subdevice information opt-in through iommu_ops.aux_at(de)tach_dev()
interfaces, the vendor iommu driver is able to learn the knowledge about
the relationships between the subdevices and the aux-domains. Implement
is_aux_domain() support based on the relationship knowledges.
Signed-off-by: Lu
This adds two new APIs for the use cases like vfio/mdev where subdevices
derived from physical devices are created and put in an iommu_group. The
new IOMMU API interfaces mimic the vfio_mdev_at(de)tach_domain() directly,
testing whether the resulting device supports IOMMU_DEV_FEAT_AUX and using
an
In the vfio/mdev use case of aux-domain, the subdevices are created from
the physical devices with IOMMU_DEV_FEAT_AUX enabled and the aux-domains
are attached to the subdevices through the iommu_ops.aux_attach_dev()
interface.
Current iommu_ops.aux_at(de)tach_dev() design only takes the aux-domain
Replace iommu_aux_at(de)tach_device() with iommu_at(de)tach_subdev_group().
Signed-off-by: Lu Baolu
---
drivers/vfio/vfio_iommu_type1.c | 43 +
1 file changed, 6 insertions(+), 37 deletions(-)
diff --git a/drivers/vfio/vfio_iommu_type1.c b/drivers/vfio/vfio_iommu
If there are multiple NUMA domains but the RHSA is missing in ACPI/DMAR
table, we could default to the device NUMA domain as fall back.
Signed-off-by: Lu Baolu
Reviewed-by: Kevin Tian
Cc: Jacob Pan
Cc: Kevin Tian
Cc: Ashok Raj
Link: https://lore.kernel.org/r/20200904010303.2961-1-baolu...@lin
Hi Joerg,
Below patch is ready for v5.10. It includes:
- Use device numa domain if RHSA is missing
Can you please consider them for v5.10?
Best regards,
Lu Baolu
Lu Baolu (1):
iommu/vt-d: Use device numa domain if RHSA is missing
drivers/iommu/intel/iommu.c | 37 ++
On Mon, Sep 21, 2020 at 10:30:57PM +0100, Will Deacon wrote:
> On Sat, Sep 05, 2020 at 01:04:06PM -0700, Rob Clark wrote:
> > 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
On Mon, Sep 21, 2020 at 2:31 PM Will Deacon wrote:
>
> On Sat, Sep 05, 2020 at 01:04:06PM -0700, Rob Clark wrote:
> > 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 /
Hi Logan,
On 9/21/20 11:48 PM, Logan Gunthorpe wrote:
On 2020-09-20 12:36 a.m., Lu Baolu wrote:
Hi Logan,
On 2020/9/19 4:47, Logan Gunthorpe wrote:
Hi Lu,
On 2020-09-11 9:21 p.m., Lu Baolu wrote:
Tom Murphy has almost done all the work. His latest patch series was
posted here.
https://lo
Tested-by: Alex Goins
This change fixes a regression with drm_prime_sg_to_page_addr_arrays() and
AMDGPU in v5.9.
Commit 39913934 similarly revamped AMDGPU to use sgtable helper functions. When
it changed from dma_map_sg_attrs() to dma_map_sgtable(), as a side effect it
started correctly updating
On Mon, Sep 21, 2020 at 10:53:23PM +0100, Robin Murphy wrote:
> On 2020-09-21 18:57, Will Deacon wrote:
> > On Wed, Sep 16, 2020 at 12:51:05AM +0100, Robin Murphy wrote:
> > > Midgard GPUs have ACE-Lite master interfaces which allows systems to
> > > integrate them in an I/O-coherent manner. It see
On Mon, Sep 21, 2020 at 11:03:49PM +0100, Robin Murphy wrote:
> On 2020-09-21 19:03, Will Deacon wrote:
> > On Fri, Sep 11, 2020 at 07:57:18PM +0530, Sai Prakash Ranjan wrote:
> > > Add a quirk IO_PGTABLE_QUIRK_SYS_CACHE to override the
> > > attributes set in TCR for the page table walker when
> >
On 2020-09-21 19:03, Will Deacon wrote:
On Fri, Sep 11, 2020 at 07:57:18PM +0530, Sai Prakash Ranjan wrote:
Add a quirk IO_PGTABLE_QUIRK_SYS_CACHE to override the
attributes set in TCR for the page table walker when
using system cache.
I wonder if the panfrost folks can reuse this for the issu
On 2020-09-21 18:57, Will Deacon wrote:
On Wed, Sep 16, 2020 at 12:51:05AM +0100, Robin Murphy wrote:
Midgard GPUs have ACE-Lite master interfaces which allows systems to
integrate them in an I/O-coherent manner. It seems that from the GPU's
viewpoint, the rest of the system is its outer shareab
On Sat, Sep 05, 2020 at 01:04:06PM -0700, Rob Clark wrote:
> 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 ms
On Sat, Sep 12, 2020 at 10:25:59PM -0500, Bjorn Andersson wrote:
> On Fri 11 Sep 12:13 CDT 2020, Robin Murphy wrote:
> > On 2020-09-04 16:55, Bjorn Andersson wrote:
> > > Add a new operation to allow platform implementations to inherit any
> > > stream mappings from the boot loader.
> >
> > Is the
On Tue, Sep 22, 2020 at 03:13:53AM +0800, kernel test robot wrote:
> Thank you for the patch! Perhaps something to improve:
>
> [auto build test WARNING on iommu/next]
> [also build test WARNING on linus/master v5.9-rc6 next-20200921]
> [cannot apply to robclark/msm-next]
>
On Mon, Sep 14, 2020 at 11:13:07AM -0700, Vennila Megavannan wrote:
> From: Srinath Mannam
>
> Add provision to change default value of MSI IOVA base to platform's
> suitable IOVA using module parameter. The present hardcoded MSI IOVA base
> may not be the accessible IOVA ranges of platform.
>
>
Hi Yu,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on iommu/next]
[also build test WARNING on linus/master v5.9-rc6 next-20200921]
[cannot apply to robclark/msm-next]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting
Hello Joerg,
We are seeing a kdump kernel boot failure in test on an HP DL325 Gen10
and it was tracked down to 387caf0b759a ("iommu/amd: Treat per-device
exclusion ranges as r/w unity-mapped regions"). Reproduced on 5.9-rc5
and goes away with revert of the commit. There is a follow on commit
tha
On Mon, Sep 21, 2020 at 11:27 AM Rob Clark wrote:
>
> On Mon, Sep 21, 2020 at 10:50 AM Will Deacon wrote:
> >
> > On Fri, Sep 18, 2020 at 09:13:57AM +0800, Yu Kuai wrote:
> > > if of_find_device_by_node() succeed, qcom_iommu_of_xlate() doesn't have
> > > a corresponding put_device(). Thus add put
On Mon, Sep 21, 2020 at 10:50 AM Will Deacon wrote:
>
> On Fri, Sep 18, 2020 at 09:13:57AM +0800, Yu Kuai wrote:
> > if of_find_device_by_node() succeed, qcom_iommu_of_xlate() doesn't have
> > a corresponding put_device(). Thus add put_device() to fix the exception
> > handling for this function i
On Fri, 18 Sep 2020 16:18:57 +0200, Jean-Philippe Brucker wrote:
> When building with C=1, sparse reports some issues regarding endianness
> annotations:
>
> arm-smmu-v3.c:221:26: warning: cast to restricted __le64
> arm-smmu-v3.c:221:24: warning: incorrect type in assignment (different base
> ty
On Fri, Sep 11, 2020 at 07:57:18PM +0530, Sai Prakash Ranjan wrote:
> Add a quirk IO_PGTABLE_QUIRK_SYS_CACHE to override the
> attributes set in TCR for the page table walker when
> using system cache.
I wonder if the panfrost folks can reuse this for the issue discussed
over at:
https://lore.ker
On Wed, Sep 16, 2020 at 12:51:05AM +0100, Robin Murphy wrote:
> Midgard GPUs have ACE-Lite master interfaces which allows systems to
> integrate them in an I/O-coherent manner. It seems that from the GPU's
> viewpoint, the rest of the system is its outer shareable domain, and so
> even when snoop s
On Fri, Sep 18, 2020 at 09:13:57AM +0800, Yu Kuai wrote:
> if of_find_device_by_node() succeed, qcom_iommu_of_xlate() doesn't have
> a corresponding put_device(). Thus add put_device() to fix the exception
> handling for this function implementation.
>
> Fixes: e86d1aa8b60f ("iommu/arm-smmu: Move
On Mon, Sep 21, 2020 at 04:08:01PM +0100, Robin Murphy wrote:
> Checking for a nonzero dma_pfn_offset was a quick shortcut to validate
> whether the DMA == phys assumption could hold at all. Checking for a
> non-NULL dma_range_map is not quite equivalent, since a map may be
> present to describe a
On 2020-09-20 12:36 a.m., Lu Baolu wrote:
> Hi Logan,
>
> On 2020/9/19 4:47, Logan Gunthorpe wrote:
>> Hi Lu,
>>
>> On 2020-09-11 9:21 p.m., Lu Baolu wrote:
>>> Tom Murphy has almost done all the work. His latest patch series was
>>> posted here.
>>>
>>> https://lore.kernel.org/linux-iommu/2020
Checking for a nonzero dma_pfn_offset was a quick shortcut to validate
whether the DMA == phys assumption could hold at all. Checking for a
non-NULL dma_range_map is not quite equivalent, since a map may be
present to describe a limited DMA window even without an offset, and
thus this check can now
2.302618] CM = 0, WnR = 0
[2.305581] [] user address but active_mm is swapper
[2.311941] Internal error: Oops: 9604 [#1] PREEMPT SMP
[2.317512] Modules linked in:
[2.320566] CPU: 1 PID: 1 Comm: swapper/0 Tainted: GW
5.9.0-rc5-next-20200921 #1
[2.3
Thanks,
applied to the dma-mapping for-next tree.
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
On 21/09/2020 14:43, Will Deacon wrote:
On Fri, Aug 21, 2020 at 09:54:20PM +0800, John Garry wrote:
As mentioned in [0], the CPU may consume many cycles processing
arm_smmu_cmdq_issue_cmdlist(). One issue we find is the cmpxchg() loop to
get space on the queue takes a lot of time once we start g
arm64 Freescale Layerscape 2088A RDB Board boot failed with linux-next
5.9.0-rc5-next-20200921 kernel tag version. The kernel warning and then
kernel panic happened.
Reported-by: Naresh Kamboju
metadata:
git branch: master
git repo: https://gitlab.com/Linaro/lkft/mirrors/next/linux-next
On Fri, Aug 21, 2020 at 09:54:20PM +0800, John Garry wrote:
> As mentioned in [0], the CPU may consume many cycles processing
> arm_smmu_cmdq_issue_cmdlist(). One issue we find is the cmpxchg() loop to
> get space on the queue takes a lot of time once we start getting many
> CPUs contending - from
Hi Jean,
> -Original Message-
> From: iommu [mailto:iommu-boun...@lists.linux-foundation.org] On Behalf Of
> Jean-Philippe Brucker
> Sent: 18 September 2020 11:19
> To: iommu@lists.linux-foundation.org; linux-arm-ker...@lists.infradead.org;
> linux...@kvack.org
> Cc: fenghua...@intel.com;
Replace a comma between expression statements by a semicolon.
Signed-off-by: Xu Wang
---
kernel/dma/debug.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/kernel/dma/debug.c b/kernel/dma/debug.c
index 8e9f7b301c6d..126ada40ef09 100644
--- a/kernel/dma/debug.c
+++ b/kerne
47 matches
Mail list logo
