- Jul 01, 2022
-
-
Add some missing i915 uapi documentation which the new i915 VM_BIND feature documentation will be refer to. Signed-off-by:
Niranjana Vishwanathapura <niranjana.vishwanathapura@intel.com> Reviewed-by:
Matthew Auld <matthew.auld@intel.com> Reviewed-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by:
Matt Roper <matthew.d.roper@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220701003110.24843-3-niranjana.vishwanathapura@intel.com
-
Matt Roper authored
Small BAR support has now landed, which allows us to add the PCI IDs that correspond to add-in card designs of DG2 and ATS-M. There's also one additional MB-down PCI ID that recently appeared (0x5698) so we add it too. Cc: Lucas De Marchi <lucas.demarchi@intel.com> Signed-off-by:
Lucas De Marchi <lucas.demarchi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220701152231.529511-2-matthew.d.roper@intel.com
-
Matthew Auld authored
If set, force the allocation to be placed in the mappable portion of I915_MEMORY_CLASS_DEVICE. One big restriction here is that system memory (i.e I915_MEMORY_CLASS_SYSTEM) must be given as a potential placement for the object, that way we can always spill the object into system memory if we can't make space. Testcase: igt@gem-create@create-ext-cpu-access-sanity-check Testcase: igt@gem-create@create-ext-cpu-access-big Signed-off-by:
Nirmoy Das <nirmoy.das@intel.com> Reviewed-by:
Thomas Hellström <thomas.hellstrom@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220629174350.384910-6-matthew.auld@intel.com
-
Matthew Auld authored
Vulkan would like to have a rough measure of how much device memory can in theory be allocated. Also add unallocated_cpu_visible_size to track the visible portion, in case the device is using small BAR. Also tweak the locking so we nice consistent values for both the mm->avail and the visible tracking. v2: tweak the locking slightly so we update the mm->avail and visible tracking as one atomic operation, such that userspace doesn't get strange values when sampling the values. Testcase: igt@i915_query@query-regions-unallocated Testcase: igt@i915_query@query-regions-sanity-check Signed-off-by:
-
Matthew Auld authored
Userspace wants to know the size of CPU visible portion of device local-memory, and on small BAR devices the probed_size is no longer enough. In Vulkan, for example, it would like to know the size in bytes for CPU visible VkMemoryHeap. We already track the io_size for each region, so plumb that through to the region query. v2: Drop the ( -1 = unknown ) stuff, which is confusing since nothing can currently ever return such a value. Testcase: igt@i915_query@query-regions-sanity-check Signed-off-by:
-
- Jun 22, 2022
-
-
Lucas De Marchi authored
Exporting the symbols like intel_gtt_* creates some confusion inside i915 that has symbols named similarly. In an attempt to isolate platforms needing intel-gtt.ko, commit 7a5c9223 ("drm/i915/gt: Split intel-gtt functions by arch") moved way too much inside gt/intel_gt_gmch.c, even the functions that don't callout to this module. Rename the symbols to make the separation clear. Signed-off-by:
Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220617230559.2109427-1-lucas.demarchi@intel.com
-
- May 18, 2022
-
-
Ramalingam C authored
Capture the impact of memory region preference list of the objects, on their memory residency and Flat-CCS capability. v2: Fix the Flat-CCS capability of an obj with {lmem, smem} preference list [Thomas] v3: Reworded the doc [Matt] v4: Fixed Typos and spelling mistakes [Tvrtko, Joonas] Signed-off-by:Ramalingam C <ramalingam.c@intel.com> cc: Matthew Auld <matthew.auld@intel.com> cc: Thomas Hellstrom <thomas.hellstrom@linux.intel.com> cc: Daniel Vetter <daniel.vetter@ffwll.ch> cc: Jon Bloomfield <jon.bloomfield@intel.com> cc: Lionel Landwerlin <lionel.g.landwerlin@intel.com> cc: Kenneth Graunke <kenneth@whitecape.org> cc: mesa-dev@lists.freedesktop.org cc: Jordan Justen <jordan.l.justen@intel.com> cc: Tony Ye <tony.ye@intel.com> Reviewed-by:
Jordan Justen <jordan.l.justen@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220502141508.2327-1-ramalingam.c@intel.com
-
- Apr 29, 2022
-
-
Matt Roper authored
We're now ready to start exposing compute engines to userspace. v2: - Move kerneldoc for other engine classes to a separate patch. (Andi) Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com> Cc: Vinay Belgaumkar <vinay.belgaumkar@intel.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Szymon Morek <szymon.morek@intel.com> UMD (mesa): mesa/mesa!14395 Signed-off-by:
Andi Shyti <andi.shyti@linux.intel.com> Reviewed-by:
-
Matt Roper authored
We'll be adding a new type of engine soon. Let's document the existing engine classes first to help make it clear what each type of engine is used for. Cc: Andi Shyti <andi.shyti@linux.intel.com> Signed-off-by:
-
- Apr 27, 2022
-
-
Matt Roper authored
The IDs added here are the subset reserved for 'motherboard down' designs of DG2. We have all the necessary support upstream to enable these now (although they'll continue to require force_probe until the usual requirements are met). The remaining DG2 IDs for add-in cards will come in a future patch once some additional required functionality has fully landed. Bspec: 44477 Cc: Lucas De Marchi <lucas.demarchi@intel.com> Cc: Daniel Vetter <daniel@ffwll.ch> Cc: Dave Airlie <airlied@gmail.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Jani Nikula <jani.nikula@intel.com> Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com> Signed-off-by:
-
- Apr 21, 2022
-
-
GSC is a graphics system controller, it provides a chassis controller for graphics discrete cards. There are two MEI interfaces in GSC: HECI1 and HECI2. Both interfaces are on the BAR0 at offsets 0x00258000 and 0x00259000. GSC is a GT Engine (class 4: instance 6). HECI1 interrupt is signaled via bit 15 and HECI2 via bit 14 in the interrupt register. This patch exports GSC as auxiliary device for mei driver to bind to for HECI2 interface and prepares for HECI1 interface as it will follow up soon. CC: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by:
Tomas Winkler <tomas.winkler@intel.com> Signed-off-by:
Vitaly Lubart <vitaly.lubart@intel.com> Signed-off-by:
Alexander Usyskin <alexander.usyskin@intel.com> Acked-by:
Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Signed-off-by:
-
Jason Gunthorpe authored
This is no longer used, remove it. All usages were moved over to either use container_of() from a vfio_device or to use dev_drvdata() directly on the mdev. Signed-off-by:
Jason Gunthorpe <jgg@nvidia.com> Signed-off-by:
Christoph Hellwig <hch@lst.de> Signed-off-by:
Zhi Wang <zhi.a.wang@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20220411141403.86980-35-hch@lst.de Reviewed-by:
Kirti Wankhede <kwankhede@nvidia.com> Reviewed-by:
-
Jason Gunthorpe authored
The last useful member in this struct is the supported_type_groups, move it to the mdev_driver and delete mdev_parent_ops. Replace it with mdev_driver as an argument to mdev_register_device() Signed-off-by:
-
Jason Gunthorpe authored
This is only used by one sample to print a fixed string that is pointless. In general, having a device driver attach sysfs attributes to the parent is horrific. This should never happen, and always leads to some kind of liftime bug as it become very difficult for the sysfs attribute to go back to any data owned by the device driver. Remove the general mechanism to create this abuse. Signed-off-by:
-
Jason Gunthorpe authored
Now that all mdev drivers directly create their own mdev_device driver and directly register with the vfio core's vfio_device_ops this is all dead code. Delete vfio_mdev.c and the mdev_parent_ops members that are connected to it. Signed-off-by:
-
Zack Rusin authored
Drivers duplicate the code required to add debugfs entries for various ttm resource managers. To fix it add common TTM resource manager debugfs code that each driver can reuse. Specific resource managers can overwrite ttm_resource_manager_func::debug to get more information from those debugfs entries. Signed-off-by:
Zack Rusin <zackr@vmware.com> Cc: Huang Rui <ray.huang@amd.com> Cc: David Airlie <airlied@linux.ie> Cc: Daniel Vetter <daniel@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20220412033526.369115-2-zack@kde.org Reviewed-by:
Christian König <christian.koenig@amd.com>
-
- Apr 20, 2022
-
-
Adding initial PCI ids for RPL-P. RPL-P behaves identically to ADL-P from i915's point of view. Changes since V1 : - SUBPLATFORM ADL_N and RPL_P clash as both are ADLP based - Matthew R Bspec: 55376 Signed-off-by:
Matt Atwood <matthew.s.atwood@intel.com> Signed-off-by:
Madhumitha Tolakanahalli Pradeep <madhumitha.tolakanahalli.pradeep@intel.com> Signed-off-by:
Tejas Upadhyay <tejaskumarx.surendrakumar.upadhyay@intel.com> [mattrope: Corrected comment formatting to match coding style] Signed-off-by:
-
- Apr 19, 2022
-
-
General Parallel Audio (GPA) interface is one of the supported audio interface for synopsys HDMI module, which has verified for i.MX8MPlus platform. This is initial version for GPA. Signed-off-by:
Shengjiu Wang <shengjiu.wang@nxp.com> Signed-off-by:
Sandor Yu <Sandor.yu@nxp.com> Reviewed-by:
Neil Armstrong <narmstrong@baylibre.com> Signed-off-by:
Robert Foss <robert.foss@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/f21ba3e8c4d9d028ac74c6f3c588ddbffe739399.1649989179.git.Sandor.yu@nxp.com
-
PHY reset register(MC_PHYRSTZ) active high reset control for PHY GEN2, and active low reset control for PHY GEN1. Rename function dw_hdmi_phy_reset to dw_hdmi_phy_gen2_reset. Add dw_hdmi_phy_gen1_reset function for PHY GEN1. Signed-off-by:
Jernej Skrabec <jernej.skrabec@gmail.com> Signed-off-by:
-
- Apr 15, 2022
-
-
Newer platforms have DSS that aren't necessarily available for both geometry and compute, two queries will need to exist. This introduces the first, when passing a valid engine class and engine instance in the flags returns a topology describing geometry. Based on past discussion, we currently only support this new query item on Xe_HP and beyond; earlier platforms do not need to worry about geometry and compute pipelines having access to different topology and should continue to use the existing topology query. v2: fix white space errors v3: change flags from hosting 2 8 bit numbers to holding a i915_engine_class_instance struct v4: add error if non rcs engine passed. v5 (by MattR): - Improve kerneldoc and cross references to related structs/enums. (Daniel) - Clarify that geometry query is only supported on render engines (Francisco) - Clarify that the new query is only supported on Xe_HP+. - Fix checkpatch warnings. Cc: Ashutosh Dixit <ashutosh.dixit@intel.com> Cc: Matt Roper <matthew.d.roper@intel.com> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Francisco Jerez <currojerez@riseup.net> UMD (mesa): mesa/mesa!14143 Testcase: igt@i915_query@test-query-geometry-subslices Signed-off-by:
Francisco Jerez <currojerez@riseup.net> Link: https://patchwork.freedesktop.org/patch/msgid/20220414192230.749771-4-matthew.d.roper@intel.com
-
Matt Roper authored
Document the possible options for drm_i915_query_item.query_id with links to the corresponding uapi structures. Signed-off-by:
-
Matt Roper authored
Convert the comments for drm_i915_query_perf_config and drm_i915_perf_oa_config to kerneldoc so that they will show up in the generated documentation. Also correct a couple places that referred to query_id when they actually meant to refer to query_item.flags. Signed-off-by:
-
Matt Roper authored
This structure has a great comment describing the fields, but it's not currently in kerneldoc form and does not show up in the generated documentation. Let's fix that and also clarify the description of what "subslice" refers to on gen12 platforms and beyond and that "slice" is no longer meaningful on Xe_HP and beyond. Signed-off-by:
-
- Apr 14, 2022
-
-
Imre Deak authored
Factor out from drm_dp_dpcd_read() a function to probe a DPCD address with a 1-byte read access. This will be needed by the next patch doing a read from an LTTPR address, which must happen without the preceding wake-up read in drm_dp_dpcd_read(). While at it add tracing for the 1 byte read even if the read was successful. v2: Add a probe function instead of exporting drm_dp_dpcd_access(). (Jani) v3: Add tracing for the 1-byte read even if the read was successful. (Khaled) Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Khaled Almahallawy <khaled.almahallawy@intel.com> Cc: dri-devel@lists.freedesktop.org Signed-off-by:
Imre Deak <imre.deak@intel.com> Reviewed-by:
Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220411132539.984647-1-imre.deak@intel.com
-
- Apr 13, 2022
-
-
Christian König authored
Update the kerneldoc for the members as well. Signed-off-by:
-
- Apr 12, 2022
-
-
If we hit the sync case, like when skipping clearing for kernel internal objects, or when falling back to cpu clearing, like in i915, we end up trying to add a NULL fence, but with some recent changes in this area this now just results in NULL deref in dma_resv_add_fence: <1>[ 5.466383] BUG: kernel NULL pointer dereference, address: 0000000000000008 <1>[ 5.466384] #PF: supervisor read access in kernel mode <1>[ 5.466385] #PF: error_code(0x0000) - not-present page <6>[ 5.466386] PGD 0 P4D 0 <4>[ 5.466387] Oops: 0000 [#1] PREEMPT SMP NOPTI <4>[ 5.466389] CPU: 5 PID: 267 Comm: modprobe Not tainted 5.18.0-rc2-CI-CI_DRM_11481+ #1 <4>[ 5.466391] RIP: 0010:dma_resv_add_fence+0x63/0x260 <4>[ 5.466395] Code: 38 85 c0 0f 84 df 01 00 00 0f 88 e8 01 00 00 83 c0 01 0f 88 df 01 00 00 8b 05 35 89 10 01 49 8d 5e 68 85 c0 0f 85 45 01 00 00 <48> 8b 45 08 48 3d c0 a5 0a 82 0f 84 5c 01 00 00 48 3d 60 a5 0a 82 <4>[ 5.466396] RSP: 0018:ffffc90000e974f8 EFLAGS: 00010202 <4>[ 5.466397] RAX: 0000000000000001 RBX: ffff888123e88b28 RCX: 00000000ffffffff <4>[ 5.466398] RDX: 0000000000000001 RSI: ffffffff822e4f50 RDI: ffffffff8233f087 <4>[ 5.466399] RBP: 0000000000000000 R08: ffff8881313dbc80 R09: 0000000000000001 <4>[ 5.466399] R10: 0000000000000001 R11: 00000000da354294 R12: 0000000000000000 <4>[ 5.466400] R13: ffff88810927dc58 R14: ffff888123e88ac0 R15: ffff88810a88d600 <4>[ 5.466401] FS: 00007f5fa1193540(0000) GS:ffff88845d880000(0000) knlGS:0000000000000000 <4>[ 5.466402] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 <4>[ 5.466402] CR2: 0000000000000008 CR3: 0000000106dd6003 CR4: 00000000003706e0 <4>[ 5.466403] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 <4>[ 5.466404] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 <4>[ 5.466404] Call Trace: <4>[ 5.466405] <TASK> <4>[ 5.466406] ttm_bo_move_accel_cleanup+0x62/0x270 [ttm] <4>[ 5.466411] ? i915_rsgt_from_buddy_resource+0x185/0x1e0 [i915] <4>[ 5.466529] i915_ttm_move+0xfd/0x430 [i915] <4>[ 5.466833] ? dma_resv_reserve_fences+0x4e/0x320 <4>[ 5.466836] ? ttm_bo_add_move_fence.constprop.20+0xf7/0x140 [ttm] <4>[ 5.466841] ttm_bo_handle_move_mem+0xa1/0x140 [ttm] <4>[ 5.466845] ttm_bo_validate+0xee/0x160 [ttm] <4>[ 5.466849] __i915_ttm_get_pages+0x4f/0x210 [i915] <4>[ 5.466976] i915_ttm_get_pages+0xad/0x140 [i915] <4>[ 5.467094] ____i915_gem_object_get_pages+0x32/0xf0 [i915] <4>[ 5.467210] __i915_gem_object_get_pages+0x89/0xa0 [i915] <4>[ 5.467323] i915_vma_get_pages+0x114/0x1d0 [i915] <4>[ 5.467446] i915_vma_pin_ww+0xd3/0xa90 [i915] <4>[ 5.467570] i915_vma_pin.constprop.10+0x119/0x1b0 [i915] <4>[ 5.467700] ? __mutex_unlock_slowpath+0x3e/0x2b0 <4>[ 5.467704] intel_alloc_initial_plane_obj.isra.6+0x1a9/0x390 [i915] <4>[ 5.467833] intel_crtc_initial_plane_config+0x83/0x340 [i915] In the ttm_bo_move_sync_cleanup() case it seems we only really care about calling ttm_bo_wait_free_node(), so let's instead just call that directly. Signed-off-by:
-
DG2 clear color render compression uses Tile4 layout. Therefore, we need to define a new format modifier for uAPI to support clear color rendering. v2: Display version is fixed. [Imre] KDoc is enhanced for cc modifier. [Nanley & Lionel] v3: Split out the modifier addition to a separate patch. Clarify the modifier layout description. Cc: dri-devel@lists.freedesktop.org Signed-off-by:
Mika Kahola <mika.kahola@intel.com> cc: Anshuman Gupta <anshuman.gupta@intel.com> Signed-off-by:
Juha-Pekka Heikkilä <juha-pekka.heikkila@intel.com> Signed-off-by:
Nanley Chery <nanley.g.chery@intel.com> Reviewed-by:
Juha-Pekka Heikkila <juhapekka.heikkila@gmail.com> Acked-by:
Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220411143405.1073845-4-imre.deak@intel.com
-
The render/media engines on DG2 unify render compression and media compression into a single format for the first time, using the Tile 4 layout for main surfaces. The compression algorithm is different from any previous platform and the display engine must still be configured to decompress either a render or media compressed surface; as such, we need new RC and MC framebuffer modifiers to represent buffers in this format. v2: Clarify modifier layout description. Cc: dri-devel@lists.freedesktop.org Signed-off-by:
-
- Apr 09, 2022
-
-
Waiman Long authored
The gcc 12 compiler reports a "'mem_section' will never be NULL" warning on the following code: static inline struct mem_section *__nr_to_section(unsigned long nr) { #ifdef CONFIG_SPARSEMEM_EXTREME if (!mem_section) return NULL; #endif if (!mem_section[SECTION_NR_TO_ROOT(nr)]) return NULL; : It happens with CONFIG_SPARSEMEM_EXTREME off. The mem_section definition is #ifdef CONFIG_SPARSEMEM_EXTREME extern struct mem_section **mem_section; #else extern struct mem_section mem_section[NR_SECTION_ROOTS][SECTIONS_PER_ROOT]; #endif In the !CONFIG_SPARSEMEM_EXTREME case, mem_section is a static 2-dimensional array and so the check "!mem_section[SECTION_NR_TO_ROOT(nr)]" doesn't make sense. Fix this warning by moving the "!mem_section[SECTION_NR_TO_ROOT(nr)]" check up inside the CONFIG_SPARSEMEM_EXTREME block and adding an explicit NR_SECTION_ROOTS check to make sure that there is no out-of-bound array access. Link: https://lkml.kernel.org/r/20220331180246.2746210-1-longman@redhat.com Fixes: 3e347261 ("sparsemem extreme implementation") Signed-off-by:Waiman Long <longman@redhat.com> Reported-by:
Justin Forbes <jforbes@redhat.com> Cc: "Kirill A . Shutemov" <kirill.shutemov@linux.intel.com> Cc: Ingo Molnar <mingo@kernel.org> Cc: Rafael Aquini <aquini@redhat.com> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org>
-
- Apr 08, 2022
-
-
Wolfram Sang authored
To make it unambiguous that mmc_hw_reset() is for cards and not for controllers, we make the function argument mmc_card instead of mmc_host. Also, all users are converted. Suggested-by:
Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by:
Wolfram Sang <wsa+renesas@sang-engineering.com> Acked-by:
Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20220408080045.6497-2-wsa+renesas@sang-engineering.com Signed-off-by:
-
- Apr 07, 2022
-
-
Trond Myklebust authored
Ensure the call to rpc_run_task() cannot fail by preallocating the rpc_task. Fixes: 910ad386 ("NFS: Fix memory allocation in rpc_alloc_task()") Signed-off-by:
Trond Myklebust <trond.myklebust@hammerspace.com>
-
Trond Myklebust authored
We must ensure that all sockets are closed before we call xprt_free() and release the reference to the net namespace. The problem is that calling fput() will defer closing the socket until delayed_fput() gets called. Let's fix the situation by allowing rpciod and the transport teardown code (which runs on the system wq) to call __fput_sync(), and directly close the socket. Reported-by:
Felix Fu <foyjog@gmail.com> Acked-by:
Al Viro <viro@zeniv.linux.org.uk> Fixes: a73881c9 ("SUNRPC: Fix an Oops in udp_poll()") Cc: stable@vger.kernel.org # 5.1.x: 3be232f1: SUNRPC: Prevent immediate close+reconnect Cc: stable@vger.kernel.org # 5.1.x: 89f42494: SUNRPC: Don't call connect() more than once on a TCP socket Cc: stable@vger.kernel.org # 5.1.x Signed-off-by:
-
Simona Vetter authored
It was only used by fbcon, and that now switched to its own, private work. Acked-by:
Sam Ravnborg <sam@ravnborg.org> Acked-by:
Thomas Zimmermann <tzimmermann@suse.de> Signed-off-by:
Daniel Vetter <daniel.vetter@intel.com> Cc: Helge Deller <deller@gmx.de> Cc: linux-fbdev@vger.kernel.org Link: https://patchwork.freedesktop.org/patch/msgid/20220405210335.3434130-9-daniel.vetter@ffwll.ch
-
Matthew Wilcox (Oracle) authored
This wrapper around alloc_pages_vma() calls prep_transhuge_page(), removing the obligation from the caller. This is in the same spirit as __folio_alloc(). Signed-off-by:
Matthew Wilcox (Oracle) <willy@infradead.org> Reviewed-by:
Zi Yan <ziy@nvidia.com> Reviewed-by:
William Kucharski <william.kucharski@oracle.com>
-
Christian König authored
Daniel pointed out that this series removes the last user of seqcount_ww_mutex_t, so let's drop this. Signed-off-by:
Peter Zijlstra (Intel) <peterz@infradead.org> Reviewed-by:
-
Christian König authored
This should be possible now since we don't have the distinction between exclusive and shared fences any more. The only possible pitfall is that a dma_fence would be reused during the RCU grace period, but even that could be handled with a single extra check. Signed-off-by:
-
Christian König authored
This is now handled by the DMA-buf framework in the dma_resv obj. Also remove the workaround inside VMWGFX to update the moving fence. Signed-off-by:
-
Christian König authored
Add an usage for submissions independent of implicit sync but still interesting for memory management. v2: cleanup the kerneldoc a bit v3: separate amdgpu changes from this Signed-off-by:
-
Christian König authored
Add an usage for kernel submissions. Waiting for those are mandatory for dynamic DMA-bufs. As a precaution this patch also changes all occurrences where fences are added as part of memory management in TTM, VMWGFX and i915 to use the new value because it now becomes possible for drivers to ignore fences with the WRITE usage. v2: use "must" in documentation, fix whitespaces v3: separate out some driver changes and better document why some changes should still be part of this patch. Signed-off-by: -
Christian König authored
Rework the internals of the dma_resv object to allow adding more than one write fence and remember for each fence what purpose it had. This allows removing the workaround from amdgpu which used a container for this instead. Signed-off-by:
-
