similar to: [PATCH 0/3] drm/tegra: Add support for fence FDs

From: Mikko Perttunen <mperttunen at nvidia.com> Add an implementation of DMA fences backed by Host1x syncpoints, an interface to specify a prefence for job submissions. Before submission, prefences containing only Host1x syncpoints are waited by pushing wait commands to CDMA, whereas other fences are CPU-waited. Signed-off-by: Mikko Perttunen <mperttunen at nvidia.com>

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

From: Thierry Reding <treding at nvidia.com> This small series of patches implements support for waiting on and emitting fence FDs on kickoff. This enables explicit fencing and can be used for example to synchronize buffer accesses between the display engine and the GPU on Tegra. The first patch lays the groundwork by splitting up nouveau_fence_sync() to allow reuse. Patch 2 is where the

From: Thierry Reding <treding at nvidia.com> Hi, This series implements a new IOCTL to submit push buffers that can optionally return a sync FD or sync object to userspace. This is useful in cases where userspace wants to synchronize operations between the GPU and another driver (such as KMS for display). Among other things this allows extensions such as eglDupNativeFenceFDANDROID to be

On Fri, Jan 12, 2018 at 03:38:56PM +0000, Chris Wilson wrote: > Quoting Thierry Reding (2018-01-12 15:14:38) > > 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

Hello, There is a trouble on ARM with DMA allocations made by device drivers, the trouble is that DMA allocations are getting implicitly backed with IOMMU mapping by the driver core if IOMMU presents in a system and IOMMU could handle device. This is an undesired behaviour for drivers that manage IOMMU by themselves, like NVIDIA Tegra GPU driver. On arm32 the implicit backing happens if

I ran into this exact issue last night - http://www.iotti.biz/?p=433 When a computer is connected via IPv4 but the IPv4 a repo host connects to is not available, yum then tries the IPv6 address and will fail with a confusing message telling you it failed to connect to the IPv6 address. I don't know if there is a way for yum to figure out whether the current network connection to the

Thanks Daniel for your input! On Mon, Sep 29, 2014 at 09:43:02AM +0200, Daniel Vetter wrote: > On Fri, Sep 26, 2014 at 01:00:05PM +0300, Lauri Peltonen wrote: > > (2) Stop automatically storing fences to the buffers that user space wants to > > synchronize explicitly. > > The problem with this approach is that you then need hw faulting to make > sure the memory is

There is currently a mixture of octal and symbolic permissions uses in files in drivers/gpu/drm and one file in drivers/gpu. There are ~270 existing octal uses and ~115 S_<FOO> uses. Convert all the S_<FOO> symbolic permissions to their octal equivalents as using octal and not symbolic permissions is preferred by many as more readable. see: https://lkml.org/lkml/2016/8/2/1945 Done

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

+Rom who seems to be presenting about mainlining android sync at linux plumbers On Wed, Oct 01, 2014 at 05:58:52PM +0200, Maarten Lankhorst wrote: > You could neuter implicit fences by always attaching the fences as > shared when explicit syncing is used. This would work correctly with > eviction, and wouldn't cause any unneeded syncing. :) Yes, that will probably work! So, just

On 12/28/2015 02:10 PM, Marcelo Roccasalva wrote: > On Mon, Dec 28, 2015 at 5:24 PM, Alice Wonder <alice at domblogger.net> wrote: >> >> I ran into this exact issue last night - >> >> http://www.iotti.biz/?p=433 >> >> When a computer is connected via IPv4 but the IPv4 a repo host connects to is not available, yum then tries the IPv6 address and will

On 26.04.2018 15:41, Thierry Reding wrote: > On Wed, Apr 25, 2018 at 09:28:49AM -0600, Jordan Crouse wrote: >> On Wed, Apr 25, 2018 at 12:10:47PM +0200, Thierry Reding wrote: >>> From: Thierry Reding <treding at nvidia.com> >>> >>> Depending on the kernel configuration, early ARM architecture setup code >>> may have attached the GPU to a DMA/IOMMU

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

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,