similar to: [RFC PATCH v1 0/6] Resolve unwanted DMA backing with IOMMU

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,

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

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

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

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

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: >

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

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

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

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

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 ++-

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 ++-

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 ++-

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

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,

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

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

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

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

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