The tegra_smmu_probe_device() handles only the first IOMMU device-tree
phandle, skipping the rest. Devices like 3D module on Tegra30 have
multiple IOMMU phandles, one for each h/w block, and thus, only one
IOMMU phandle is added to fwspec for the 3D module, breaking GPU.
Previously this problem
On 2021-03-12 8:52 a.m., Robin Murphy wrote:
>> +
>> sg->dma_address = dma_direct_map_page(dev, sg_page(sg),
>> sg->offset, sg->length, dir, attrs);
>> if (sg->dma_address == DMA_MAPPING_ERROR)
>> @@ -411,7 +440,7 @@ int dma_direct_map_sg(struct device *dev,
On 2021-03-12 8:52 a.m., Robin Murphy wrote:
> On 2021-03-11 23:31, Logan Gunthorpe wrote:
>> When a PCI P2PDMA page is seen, set the IOVA length of the segment
>> to zero so that it is not mapped into the IOVA. Then, in finalise_sg(),
>> apply the appropriate bus address to the segment. The
On 2021-03-11 23:31, Logan Gunthorpe wrote:
When a PCI P2PDMA page is seen, set the IOVA length of the segment
to zero so that it is not mapped into the IOVA. Then, in finalise_sg(),
apply the appropriate bus address to the segment. The IOVA is not
created if the scatterlist only consists of
On 2021-03-12 8:51 a.m., Robin Murphy wrote:
> On 2021-03-11 23:31, Logan Gunthorpe wrote:
>> Hi,
>>
>> This is a rework of the first half of my RFC for doing P2PDMA in
>> userspace
>> with O_DIRECT[1].
>>
>> The largest issue with that series was the gross way of flagging P2PDMA
>> SGL
On 2021-03-11 08:26, Christoph Hellwig wrote:
On Wed, Mar 10, 2021 at 06:39:57PM +, Robin Murphy wrote:
Actually... Just mirroring the iommu_dma_strict value into
struct iommu_domain should solve all of that with very little
boilerplate code.
Yes, my initial thought was to directly
On 3/3/21 10:55 PM, Jean-Philippe Brucker wrote:
On Fri, Jan 15, 2021 at 05:43:40PM +0530, Vivek Gautam wrote:
[...]
+static int viommu_setup_pgtable(struct viommu_endpoint *vdev,
+ struct viommu_domain *vdomain)
+{
+ int ret, id;
+ u32 asid;
+
On Thu, Mar 11, 2021 at 02:55:34PM -0800, Jacob Pan wrote:
> Hi Jason,
>
> Thanks for the review.
>
> On Wed, 10 Mar 2021 15:23:01 -0400, Jason Gunthorpe wrote:
>
> > On Sat, Feb 27, 2021 at 02:01:26PM -0800, Jacob Pan wrote:
> >
> > > +/* IOCTLs for IOASID file descriptor
On 2021-03-11 23:31, Logan Gunthorpe wrote:
Add PCI P2PDMA support for dma_direct_map_sg() so that it can map
PCI P2PDMA pages directly without a hack in the callers. This allows
for heterogeneous SGLs that contain both P2PDMA and regular pages.
SGL segments that contain PCI bus addresses are
On 2021-03-11 23:31, Logan Gunthorpe wrote:
Hi,
This is a rework of the first half of my RFC for doing P2PDMA in userspace
with O_DIRECT[1].
The largest issue with that series was the gross way of flagging P2PDMA
SGL segments. This RFC proposes a different approach, (suggested by
Dan
On 2021-03-12 17:03, Logan Gunthorpe wrote:
On 2021-03-12 8:52 a.m., Robin Murphy wrote:
On 2021-03-11 23:31, Logan Gunthorpe wrote:
When a PCI P2PDMA page is seen, set the IOVA length of the segment
to zero so that it is not mapped into the IOVA. Then, in finalise_sg(),
apply the
On 2021-03-12 16:18, Logan Gunthorpe wrote:
On 2021-03-12 8:51 a.m., Robin Murphy wrote:
On 2021-03-11 23:31, Logan Gunthorpe wrote:
Hi,
This is a rework of the first half of my RFC for doing P2PDMA in
userspace
with O_DIRECT[1].
The largest issue with that series was the gross way of
On 2021-03-12 1:39 p.m., Bjorn Helgaas wrote:
On Thu, Mar 11, 2021 at 04:31:31PM -0700, Logan Gunthorpe wrote:
In order to call this function from a dma_map function, it must not sleep.
The only reason it does sleep so to allocate the seqbuf to print
which devices are within the ACS path.
On 2021-03-12 11:11 a.m., Robin Murphy wrote:
> On 2021-03-12 16:24, Logan Gunthorpe wrote:
>>
>>
>> On 2021-03-12 8:52 a.m., Robin Murphy wrote:
+
sg->dma_address = dma_direct_map_page(dev, sg_page(sg),
sg->offset, sg->length, dir, attrs);
On Thu, Mar 11, 2021 at 04:31:32PM -0700, Logan Gunthorpe wrote:
> In order to use upstream_bridge_distance_warn() from a dma_map function,
> it must not sleep. However, pci_get_slot() takes the pci_bus_sem so it
> might sleep.
>
> In order to avoid this, try to get the host bridge's device from
On 2021-03-12 10:46 a.m., Robin Murphy wrote:
> On 2021-03-12 16:18, Logan Gunthorpe wrote:
>>
>>
>> On 2021-03-12 8:51 a.m., Robin Murphy wrote:
>>> On 2021-03-11 23:31, Logan Gunthorpe wrote:
Hi,
This is a rework of the first half of my RFC for doing P2PDMA in
userspace
On 2021-03-12 1:57 p.m., Bjorn Helgaas wrote:
> On Thu, Mar 11, 2021 at 04:31:32PM -0700, Logan Gunthorpe wrote:
>> In order to use upstream_bridge_distance_warn() from a dma_map function,
>> it must not sleep. However, pci_get_slot() takes the pci_bus_sem so it
>> might sleep.
>>
>> In order
On 2021-03-12 16:24, Logan Gunthorpe wrote:
On 2021-03-12 8:52 a.m., Robin Murphy wrote:
+
sg->dma_address = dma_direct_map_page(dev, sg_page(sg),
sg->offset, sg->length, dir, attrs);
if (sg->dma_address == DMA_MAPPING_ERROR)
@@ -411,7 +440,7 @@ int
On 2021-03-12 12:47 p.m., Robin Murphy wrote:
{
struct scatterlist *s, *cur = sg;
unsigned long seg_mask = dma_get_seg_boundary(dev);
@@ -864,6 +865,20 @@ static int __finalise_sg(struct device *dev,
struct scatterlist *sg, int nents,
sg_dma_address(s) =
On Thu, Mar 11, 2021 at 04:31:31PM -0700, Logan Gunthorpe wrote:
> In order to call this function from a dma_map function, it must not sleep.
> The only reason it does sleep so to allocate the seqbuf to print
> which devices are within the ACS path.
s/this
Hi Ricardo,
Thank you for the patch.
On Fri, Mar 12, 2021 at 01:57:09PM +0100, Ricardo Ribalda wrote:
> On architectures where there is no coherent caching such as ARM use the
> dma_alloc_noncontiguous API and handle manually the cache flushing using
> dma_sync_sgtable().
You're actually
Hi Laurent
Thanks a lot for the review
On Fri, Mar 12, 2021 at 10:19 PM Laurent Pinchart
wrote:
>
> Hi Ricardo,
>
> Thank you for the patch.
>
> On Fri, Mar 12, 2021 at 01:57:09PM +0100, Ricardo Ribalda wrote:
> > On architectures where there is no coherent caching such as ARM use the
> >
Hi Ricardo,
On Fri, Mar 12, 2021 at 11:15:46PM +0100, Ricardo Ribalda Delgado wrote:
> On Fri, Mar 12, 2021 at 10:19 PM Laurent Pinchart wrote:
> > On Fri, Mar 12, 2021 at 01:57:09PM +0100, Ricardo Ribalda wrote:
> > > On architectures where there is no coherent caching such as ARM use the
> > >
Hi Ricardo,
Thank you for the patch.
On Fri, Mar 12, 2021 at 11:25:39PM +0100, Ricardo Ribalda wrote:
> On architectures where there is no coherent caching such as ARM use the
> dma_alloc_noncontiguous API and handle manually the cache flushing using
> dma_sync_sgtable().
Maybe updating this
On Thu, Mar 11, 2021 at 04:31:37PM -0700, Logan Gunthorpe wrote:
> +int dma_pci_p2pdma_supported(struct device *dev)
^^^
bool?
> +{
> + const struct dma_map_ops *ops = get_dma_ops(dev);
> +
> + return !ops || ops->flags & DMA_F_PCI_P2PDMA_SUPPORTED;
Is this logic correct? I would
On architectures where there is no coherent caching such as ARM use the
dma_alloc_noncontiguous API and handle manually the cache flushing using
dma_sync_sgtable().
With this patch on the affected architectures we can measure up to 20x
performance improvement in uvc_video_copy_data_work().
Eg:
On Thu, Mar 11, 2021 at 04:31:34PM -0700, Logan Gunthorpe wrote:
> Introduce pci_p2pdma_should_map_bus() which is meant to be called by
^
pci_p2pdma_dma_map_type() ???
FWIW I find this name confusing with pci_p2pdma_map_type() and looking at the
On architectures where there is no coherent caching such as ARM use the
dma_alloc_noncontiguous API and handle manually the cache flushing using
dma_sync_sgtable().
If the architechture has coherent cache, the API falls back to
alloc_dma_pages, so we can remove the coherent caching code-path from
On Thu, Mar 11, 2021 at 04:31:34PM -0700, Logan Gunthorpe wrote:
> Introduce pci_p2pdma_should_map_bus() which is meant to be called by
> DMA map functions to determine how to map a given p2pdma page.
>
> pci_p2pdma_bus_offset() is also added to allow callers to get the bus
> offset if they need
Currently, PPR/ATS can be enabled only if the domain is type
identity mapping. However, when we allow the IOMMU v2 page table
to be used for DMA-API, the sanity check needs to be updated to
only apply for the case when using AMD_IOMMU_V1 page table mode.
Signed-off-by: Suravee Suthikulpanit
---
This series introduces a new usage model for the v2 page table, where it
can be used to implement support for DMA-API by adopting the generic
IO page table framework.
One of the target usecases is to support nested IO page tables
where the guest uses the guest IO page table (v2) for translating
Introduce IO page table framework support for AMD IOMMU v2 page table.
Signed-off-by: Suravee Suthikulpanit
---
drivers/iommu/amd/Makefile | 2 +-
drivers/iommu/amd/amd_iommu_types.h | 2 +
drivers/iommu/amd/io_pgtable_v2.c | 239
The current function to enable IOMMU v2 also lock the domain.
In order to reuse the same code in different code path, in which
the domain has already been locked, refactor the function to separate
the locking from the enabling logic.
Signed-off-by: Suravee Suthikulpanit
---
AMD IOMMU introduces support for Guest I/O protection where the request
from the I/O device without a PASID are treated as if they have PASID 0.
Signed-off-by: Suravee Suthikulpanit
---
drivers/iommu/amd/amd_iommu_types.h | 3 +++
drivers/iommu/amd/init.c| 8
To allow specification whether to use v1 or v2 IOMMU pagetable for
DMA remapping when calling kernel DMA-API.
Signed-off-by: Suravee Suthikulpanit
---
Documentation/admin-guide/kernel-parameters.txt | 6 ++
drivers/iommu/amd/init.c| 15 +++
2 files
Currently, the function to enable iommu v2 (GT) assumes PPR log
must also be enabled. This is no longer the case since the IOMMU
v2 page table can be enabled without PRR support (for DMA-API
use case).
Therefore, separate the enabling logic for PPR and GT.
There is no functional change.
Introduce init function for setting up DMA domain for DMA-API with
the IOMMU v2 page table.
Signed-off-by: Suravee Suthikulpanit
---
drivers/iommu/amd/iommu.c | 21 +
1 file changed, 21 insertions(+)
diff --git a/drivers/iommu/amd/iommu.c b/drivers/iommu/amd/iommu.c
index
Hi Jean,
On 3/3/21 10:44 PM, Jean-Philippe Brucker wrote:
On Fri, Jan 15, 2021 at 05:43:31PM +0530, Vivek Gautam wrote:
Update base address information in vendor pasid table info to pass that
to user-space for stage1 table management.
Signed-off-by: Vivek Gautam
Cc: Joerg Roedel
Cc: Will
Hi Jean,
On 3/3/21 10:41 PM, Jean-Philippe Brucker wrote:
Hi Vivek,
Thanks again for working on this. I have a few comments but it looks
sensible overall.
Thanks a lot for reviewing the patch-series. Please find my responses
inline below.
Regarding the overall design, I was initially
On 3/3/21 10:45 PM, Jean-Philippe Brucker wrote:
On Fri, Jan 15, 2021 at 05:43:32PM +0530, Vivek Gautam wrote:
Te change allows different consumers of arm-smmu-v3-cd-lib to set
their respective sync op for pasid entries.
Signed-off-by: Vivek Gautam
Cc: Joerg Roedel
Cc: Will Deacon
Cc:
On 3/3/21 10:47 PM, Jean-Philippe Brucker wrote:
On Fri, Jan 15, 2021 at 05:43:33PM +0530, Vivek Gautam wrote:
From: Jean-Philippe Brucker
Add required UAPI defines for probing table format for underlying
iommu hardware. The device may provide information about hardware
tables and
On architectures where there is no coherent caching such as ARM use the
dma_alloc_noncontiguous API and handle manually the cache flushing using
dma_sync_sgtable().
With this patch on the affected architectures we can measure up to 20x
performance improvement in uvc_video_copy_data_work().
Eg:
On 3/3/21 10:48 PM, Jean-Philippe Brucker wrote:
On Fri, Jan 15, 2021 at 05:43:35PM +0530, Vivek Gautam wrote:
aisd_bits data is required to prepare stage-1 tables for arm-smmu-v3.
Signed-off-by: Vivek Gautam
Cc: Joerg Roedel
Cc: Will Deacon
Cc: Robin Murphy
Cc: Jean-Philippe Brucker
On 3/3/21 10:51 PM, Jean-Philippe Brucker wrote:
On Fri, Jan 15, 2021 at 05:43:36PM +0530, Vivek Gautam wrote:
Add info about asid_bits and additional flags to table format
probing header.
Signed-off-by: Vivek Gautam
Cc: Joerg Roedel
Cc: Will Deacon
Cc: Michael S. Tsirkin
Cc: Robin
On 3/3/21 10:55 PM, Jean-Philippe Brucker wrote:
On Fri, Jan 15, 2021 at 05:43:42PM +0530, Vivek Gautam wrote:
Fault type information can tell about a page request fault or
an unreceoverable fault, and further additions to fault reasons
and the related PASID information can help in handling
45 matches
Mail list logo
