Displaying 20 results from an estimated 1100 matches similar to: "[RFC PATCH v1 0/6] Resolve unwanted DMA backing with IOMMU"
2023 May 03
1
[PATCH v6 0/3] Add sync object UAPI support to VirtIO-GPU driver
On Mon, May 1, 2023 at 8:38?AM Dmitry Osipenko <
dmitry.osipenko at collabora.com> wrote:
> On 4/16/23 14:52, Dmitry Osipenko wrote:
> > We have multiple Vulkan context types that are awaiting for the addition
> > of the sync object DRM UAPI support to the VirtIO-GPU kernel driver:
> >
> > 1. Venus context
> > 2. Native contexts (virtio-freedreno,
2023 May 08
1
[PATCH v6 0/3] Add sync object UAPI support to VirtIO-GPU driver
On Wed, May 3, 2023 at 10:07?AM Gurchetan Singh
<gurchetansingh at chromium.org> wrote:
>
>
>
> On Mon, May 1, 2023 at 8:38?AM Dmitry Osipenko <dmitry.osipenko at collabora.com> wrote:
>>
>> On 4/16/23 14:52, Dmitry Osipenko wrote:
>> > We have multiple Vulkan context types that are awaiting for the addition
>> > of the sync object DRM UAPI
2018 Jan 11
6
[PATCH 0/3] drm/tegra: Add support for fence FDs
From: Thierry Reding <treding at nvidia.com>
This set of patches adds support for fences to Tegra DRM and complements
the fence FD support for Nouveau. Technically this isn't necessary for a
fence-based synchronization loop with Nouveau because the KMS core takes
care of all that, but engines behind host1x can use the IOCTL extensions
provided here to emit fence FDs that in turn can be
2018 Jul 27
3
[RFC PATCH v1 0/6] Resolve unwanted DMA backing with IOMMU
On Friday, 27 July 2018 20:03:26 MSK Jordan Crouse wrote:
> On Fri, Jul 27, 2018 at 05:02:37PM +0100, Robin Murphy wrote:
> > On 27/07/18 15:10, Dmitry Osipenko wrote:
> > >On Friday, 27 July 2018 12:03:28 MSK Will Deacon wrote:
> > >>On Fri, Jul 27, 2018 at 10:25:13AM +0200, Joerg Roedel wrote:
> > >>>On Fri, Jul 27, 2018 at 02:16:18AM +0300, Dmitry
2018 Jul 27
3
[RFC PATCH v1 0/6] Resolve unwanted DMA backing with IOMMU
On Fri, Jul 27, 2018 at 10:25:13AM +0200, Joerg Roedel wrote:
> On Fri, Jul 27, 2018 at 02:16:18AM +0300, Dmitry Osipenko wrote:
> > The proposed solution adds a new option to the base device driver
> > structure that allows device drivers to explicitly convey to the drivers
> > core that the implicit IOMMU backing for devices must not happen.
>
> Why is IOMMU mapping a
2018 Aug 15
2
[RFC PATCH v1 0/6] Resolve unwanted DMA backing with IOMMU
On Friday, 3 August 2018 18:43:41 MSK Robin Murphy wrote:
> On 02/08/18 19:24, Dmitry Osipenko wrote:
> > On Friday, 27 July 2018 20:16:53 MSK Dmitry Osipenko wrote:
> >> On Friday, 27 July 2018 20:03:26 MSK Jordan Crouse wrote:
> >>> On Fri, Jul 27, 2018 at 05:02:37PM +0100, Robin Murphy wrote:
> >>>> On 27/07/18 15:10, Dmitry Osipenko wrote:
>
2018 Aug 02
2
[RFC PATCH v1 0/6] Resolve unwanted DMA backing with IOMMU
On Friday, 27 July 2018 20:16:53 MSK Dmitry Osipenko wrote:
> On Friday, 27 July 2018 20:03:26 MSK Jordan Crouse wrote:
> > On Fri, Jul 27, 2018 at 05:02:37PM +0100, Robin Murphy wrote:
> > > On 27/07/18 15:10, Dmitry Osipenko wrote:
> > > >On Friday, 27 July 2018 12:03:28 MSK Will Deacon wrote:
> > > >>On Fri, Jul 27, 2018 at 10:25:13AM +0200, Joerg
2018 Jul 27
2
[RFC PATCH v1 0/6] Resolve unwanted DMA backing with IOMMU
On 27/07/18 15:10, Dmitry Osipenko wrote:
> On Friday, 27 July 2018 12:03:28 MSK Will Deacon wrote:
>> On Fri, Jul 27, 2018 at 10:25:13AM +0200, Joerg Roedel wrote:
>>> On Fri, Jul 27, 2018 at 02:16:18AM +0300, Dmitry Osipenko wrote:
>>>> The proposed solution adds a new option to the base device driver
>>>> structure that allows device drivers to
2015 Jul 28
3
[PATCH] virtio_mmio: add ACPI probing
Added the match table and pointers for ACPI probing to the driver.
This uses the same identifier for virt devices as being used for qemu
ARM64 ACPI support.
http://git.linaro.org/people/shannon.zhao/qemu.git/commit/d0bf1955a3ecbab4b51d46f8c5dda02b7e14a17e
Signed-off-by: Graeme Gregory <graeme.gregory at linaro.org>
---
drivers/virtio/virtio_mmio.c | 10 ++++++++++
1 file changed, 10
2015 Jul 28
3
[PATCH] virtio_mmio: add ACPI probing
Added the match table and pointers for ACPI probing to the driver.
This uses the same identifier for virt devices as being used for qemu
ARM64 ACPI support.
http://git.linaro.org/people/shannon.zhao/qemu.git/commit/d0bf1955a3ecbab4b51d46f8c5dda02b7e14a17e
Signed-off-by: Graeme Gregory <graeme.gregory at linaro.org>
---
drivers/virtio/virtio_mmio.c | 10 ++++++++++
1 file changed, 10
2023 Jan 06
3
[PATCH 1/8] iommu: Add a gfp parameter to iommu_map()
The internal mechanisms support this, but instead of exposting the gfp to
the caller it wrappers it into iommu_map() and iommu_map_atomic()
Fix this instead of adding more variants for GFP_KERNEL_ACCOUNT.
Signed-off-by: Jason Gunthorpe <jgg at nvidia.com>
---
arch/arm/mm/dma-mapping.c | 11 +++++++----
.../gpu/drm/nouveau/nvkm/subdev/instmem/gk20a.c | 3 ++-
2023 Jan 06
3
[PATCH 1/8] iommu: Add a gfp parameter to iommu_map()
The internal mechanisms support this, but instead of exposting the gfp to
the caller it wrappers it into iommu_map() and iommu_map_atomic()
Fix this instead of adding more variants for GFP_KERNEL_ACCOUNT.
Signed-off-by: Jason Gunthorpe <jgg at nvidia.com>
---
arch/arm/mm/dma-mapping.c | 11 +++++++----
.../gpu/drm/nouveau/nvkm/subdev/instmem/gk20a.c | 3 ++-
2023 Jan 06
3
[PATCH 1/8] iommu: Add a gfp parameter to iommu_map()
The internal mechanisms support this, but instead of exposting the gfp to
the caller it wrappers it into iommu_map() and iommu_map_atomic()
Fix this instead of adding more variants for GFP_KERNEL_ACCOUNT.
Signed-off-by: Jason Gunthorpe <jgg at nvidia.com>
---
arch/arm/mm/dma-mapping.c | 11 +++++++----
.../gpu/drm/nouveau/nvkm/subdev/instmem/gk20a.c | 3 ++-
2017 Dec 21
2
[bug report] null ptr deref in nouveau_platform_probe (tegra186-p2771-0000)
Hi Thierry,
Thanks for the patch. I applied on top of linux-next-2017-12-14.
Different output this time.
[ 11.862495] WARNING: CPU: 1 PID: 254 at
drivers/gpu/drm/nouveau/nvkm/subdev/mmu/vmmgf100.c:391
gf100_vmm_new_+0x60/0x128 [nouveau]
[ 11.863458] tegra-dpaux 155c0000.dpaux: 155c0000.dpaux supply vdd
not found, using dummy regulator
[ 11.866197] tegra-sor 15580000.sor: failed to probe
2017 Nov 21
2
GP10B regression
Thanks to Thierry for finding this - applying
index e14643615698..00eeaaffeae5 100644
--- a/drivers/gpu/drm/nouveau/nvkm/engine/device/base.c
+++ b/drivers/gpu/drm/nouveau/nvkm/engine/device/base.c
@@ -2369,7 +2369,7 @@ nv13b_chipset = {
.imem = gk20a_instmem_new,
.ltc = gp100_ltc_new,
.mc = gp10b_mc_new,
- .mmu = gf100_mmu_new,
+ .mmu = gp10b_mmu_new,
2023 Jan 06
8
[PATCH 0/8] Let iommufd charge IOPTE allocations to the memory cgroup
iommufd follows the same design as KVM and uses memory cgroups to limit
the amount of kernel memory a iommufd file descriptor can pin down. The
various internal data structures already use GFP_KERNEL_ACCOUNT to charge
its own memory.
However, one of the biggest consumers of kernel memory is the IOPTEs
stored under the iommu_domain and these allocations are not tracked.
This series is the first
2023 Jan 06
8
[PATCH 0/8] Let iommufd charge IOPTE allocations to the memory cgroup
iommufd follows the same design as KVM and uses memory cgroups to limit
the amount of kernel memory a iommufd file descriptor can pin down. The
various internal data structures already use GFP_KERNEL_ACCOUNT to charge
its own memory.
However, one of the biggest consumers of kernel memory is the IOPTEs
stored under the iommu_domain and these allocations are not tracked.
This series is the first
2023 Jan 06
8
[PATCH 0/8] Let iommufd charge IOPTE allocations to the memory cgroup
iommufd follows the same design as KVM and uses memory cgroups to limit
the amount of kernel memory a iommufd file descriptor can pin down. The
various internal data structures already use GFP_KERNEL_ACCOUNT to charge
its own memory.
However, one of the biggest consumers of kernel memory is the IOPTEs
stored under the iommu_domain and these allocations are not tracked.
This series is the first
2014 Jun 26
6
[PATCH v3 0/3] drm/nouveau: support for probing platform devices
This series adds support for probing platform devices on Nouveau, as well as
the DT bindings for GK20A. It doesn't enable the GPU yet on Tegra boards since
a few extra things need to be supported before that.
This version is mostly identical to v2 but fixes an important issue: the drvdata
must be set to the drm_device for sysfs to work, so the platform device
structure now includes the
2018 Jan 12
2
[PATCH 0/3] drm/tegra: Add support for fence FDs
On Fri, Jan 12, 2018 at 10:40:16AM +0000, Chris Wilson wrote:
> Quoting Thierry Reding (2018-01-11 22:22:46)
> > From: Thierry Reding <treding at nvidia.com>
> >
> > This set of patches adds support for fences to Tegra DRM and complements
> > the fence FD support for Nouveau. Technically this isn't necessary for a
> > fence-based synchronization loop