Displaying 3 results from an estimated 3 matches for "mm_exit".
Did you mean:
mc_exit
2019 Nov 02
0
[PATCH v2 2/9] iommu: Add dummy dev_iommu_fwspec_get() helper
...+++++++++++++++++++++-------------------
1 file changed, 26 insertions(+), 21 deletions(-)
diff --git a/include/linux/iommu.h b/include/linux/iommu.h
index 7bf038b371b8..b092e73b2c86 100644
--- a/include/linux/iommu.h
+++ b/include/linux/iommu.h
@@ -190,6 +190,27 @@ struct iommu_sva_ops {
iommu_mm_exit_handler_t mm_exit;
};
+/**
+ * struct iommu_fwspec - per-device IOMMU instance data
+ * @ops: ops for this device's IOMMU
+ * @iommu_fwnode: firmware handle for this device's IOMMU
+ * @iommu_priv: IOMMU driver private data for this device
+ * @flags: IOMMU flags associated with this dev...
2019 Nov 02
13
[PATCH v2 0/9] drm/nouveau: Various fixes for GP10B
From: Thierry Reding <treding at nvidia.com>
Hi Ben,
here's a revised subset of the patches I had sent out a couple of weeks
ago. I've reworked the BAR2 accesses in the way that you had suggested,
which at least for GP10B turned out to be fairly trivial to do. I have
not looked in detail at this for GV11B yet, but a cursory look showed
that BAR2 is accessed in more places, so the
2019 Dec 09
11
[PATCH v3 0/9] drm/nouveau: Various fixes for GP10B
From: Thierry Reding <treding at nvidia.com>
Hi Ben,
here's a revised subset of the patches I had sent out a couple of weeks
ago. I've reworked the BAR2 accesses in the way that you had suggested,
which at least for GP10B turned out to be fairly trivial to do. I have
not looked in detail at this for GV11B yet, but a cursory look showed
that BAR2 is accessed in more places, so the