aboutsummaryrefslogtreecommitdiff
path: root/drivers/gpu
AgeCommit message (Collapse)AuthorFilesLines
2022-03-01drm/i915/ttm: mappable migration on faultMatthew Auld1-6/+48
The end goal is to have userspace tell the kernel what buffers will require CPU access, however if we ever reach the CPU fault handler, and the current resource is not mappable, then we should attempt to migrate the buffer to the mappable portion of LMEM, or even system memory, if the allowable placements permit it. Signed-off-by: Matthew Auld <[email protected]> Cc: Thomas Hellström <[email protected]> Reviewed-by: Thomas Hellström <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2022-03-01drm/i915/ttm: make eviction mappable awareMatthew Auld1-2/+63
If we need to make room for some mappable object, then we should only victimize objects that have one or pages that occupy the visible portion of LMEM. Let's also create a new priority hint for objects that are placed in mappable memory, where we know that CPU access was requested, that way we hopefully victimize these last. v2(Thomas): s/TTM_PL_PRIV/I915_PL_LMEM0/ Signed-off-by: Matthew Auld <[email protected]> Cc: Thomas Hellström <[email protected]> Reviewed-by: Thomas Hellström <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2022-03-01Merge tag 'amd-drm-next-5.18-2022-02-25' of ↵Dave Airlie110-713/+201293
https://gitlab.freedesktop.org/agd5f/linux into drm-next amd-drm-next-5.18-2022-02-25: amdgpu: - Raven2 suspend/resume fix - SDMA 5.2.6 updates - VCN 3.1.2 updates - SMU 13.0.5 updates - DCN 3.1.5 updates - Virtual display fixes - SMU code cleanup - Harvest fixes - Expose benchmark tests via debugfs - Drop no longer relevant gart aperture tests - More RAS restructuring - W=1 fixes - PSR rework - DP/VGA adapter fixes - DP MST fixes - GPUVM eviction fix - GPU reset debugfs register dumping support - Misc display fixes - SR-IOV fix - Aldebaran mGPU fix - Add module parameter to disable XGMI for testing amdkfd: - IH ring overflow logging fixes - CRIU fixes - Misc fixes Signed-off-by: Dave Airlie <[email protected]> From: Alex Deucher <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2022-02-28drm/bridge: it6505: Fix the read buffer array boundHsin-Yi Wang1-2/+2
The size of read_buf is READ_BUFFER_SIZE (200), so we can't access it with read_buf + PAGE_SIZE (4096). Extend the READ_BUFFER_SIZE to 400 and set the end position to read_buf + READ_BUFFER_SIZE. Fixes: b5c84a9edcd418 ("drm/bridge: add it6505 driver") Reported-by: Mark Brown <[email protected]> Signed-off-by: Hsin-Yi Wang <[email protected]> Signed-off-by: Robert Foss <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2022-02-28drm/i915: Clarify vma lifetimeThomas Hellström5-33/+79
It's unclear what reference the initial vma kref reference refers to. A vma can have multiple weak references, the object vma list, the vm's bound list and the GT's closed_list, and the initial vma reference can be put from lookups of all these lists. With the current implementation this means that any holder of yet another vma refcount (currently only i915_gem_object_unbind()) needs to be holding two of either *) An object refcount, *) A vm open count *) A vma open count in order for us to not risk leaking a reference by having the initial vma reference being put twice. Address this by re-introducing i915_vma_destroy() which removes all weak references of the vma and *then* puts the initial vma refcount. This makes a strong vma reference hold on to the vma unconditionally. Perhaps a better name would be i915_vma_revoke() or i915_vma_zombify(), since other callers may still hold a refcount, but with the prospect of being able to replace the vma refcount with the object lock in the near future, let's stick with i915_vma_destroy(). Finally this commit fixes a race in that previously i915_vma_release() and now i915_vma_destroy() could destroy a vma without taking the vm->mutex after an advisory check that the vma mm_node was not allocated. This would race with the ungrab_vma() function creating a trace similar to the below one. This was fixed in one of the __i915_vma_put() callsites in commit bc1922e5d349 ("drm/i915: Fix a race between vma / object destruction and unbinding") but although not seemingly triggered by CI, that is not sufficient. This patch is needed to fix that properly. [823.012188] Console: switching to colour dummy device 80x25 [823.012422] [IGT] gem_ppgtt: executing [823.016667] [IGT] gem_ppgtt: starting subtest blt-vs-render-ctx0 [852.436465] stack segment: 0000 [#1] PREEMPT SMP NOPTI [852.436480] CPU: 0 PID: 3200 Comm: gem_ppgtt Not tainted 5.16.0-CI-CI_DRM_11115+ #1 [852.436489] Hardware name: Intel Corporation Alder Lake Client Platform/AlderLake-P DDR5 RVP, BIOS ADLPFWI1.R00.2422.A00.2110131104 10/13/2021 [852.436499] RIP: 0010:ungrab_vma+0x9/0x80 [i915] [852.436711] Code: ef e8 4b 85 cf e0 e8 36 a3 d6 e0 8b 83 f8 9c 00 00 85 c0 75 e1 5b 5d 41 5c 41 5d c3 e9 d6 fd 14 00 55 53 48 8b af c0 00 00 00 <8b> 45 00 85 c0 75 03 5b 5d c3 48 8b 85 a0 02 00 00 48 89 fb 48 8b [852.436727] RSP: 0018:ffffc90006db7880 EFLAGS: 00010246 [852.436734] RAX: 0000000000000000 RBX: ffffc90006db7598 RCX: 0000000000000000 [852.436742] RDX: ffff88815349e898 RSI: ffff88815349e858 RDI: ffff88810a284140 [852.436748] RBP: 6b6b6b6b6b6b6b6b R08: ffff88815349e898 R09: ffff88815349e8e8 [852.436754] R10: 0000000000000001 R11: 0000000051ef1141 R12: ffff88810a284140 [852.436762] R13: 0000000000000000 R14: ffff88815349e868 R15: ffff88810a284458 [852.436770] FS: 00007f5c04b04e40(0000) GS:ffff88849f000000(0000) knlGS:0000000000000000 [852.436781] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [852.436788] CR2: 00007f5c04b38fe0 CR3: 000000010a6e8001 CR4: 0000000000770ef0 [852.436797] PKRU: 55555554 [852.436801] Call Trace: [852.436806] <TASK> [852.436811] i915_gem_evict_for_node+0x33c/0x3c0 [i915] [852.437014] i915_gem_gtt_reserve+0x106/0x130 [i915] [852.437211] i915_vma_pin_ww+0x8f4/0xb60 [i915] [852.437412] eb_validate_vmas+0x688/0x860 [i915] [852.437596] i915_gem_do_execbuffer+0xc0e/0x25b0 [i915] [852.437770] ? deactivate_slab+0x5f2/0x7d0 [852.437778] ? _raw_spin_unlock_irqrestore+0x50/0x60 [852.437789] ? i915_gem_execbuffer2_ioctl+0xc6/0x2c0 [i915] [852.437944] ? init_object+0x49/0x80 [852.437950] ? __lock_acquire+0x5e6/0x2580 [852.437963] i915_gem_execbuffer2_ioctl+0x116/0x2c0 [i915] [852.438129] ? i915_gem_do_execbuffer+0x25b0/0x25b0 [i915] [852.438300] drm_ioctl_kernel+0xac/0x140 [852.438310] drm_ioctl+0x201/0x3d0 [852.438316] ? i915_gem_do_execbuffer+0x25b0/0x25b0 [i915] [852.438490] __x64_sys_ioctl+0x6a/0xa0 [852.438498] do_syscall_64+0x37/0xb0 [852.438507] entry_SYSCALL_64_after_hwframe+0x44/0xae [852.438515] RIP: 0033:0x7f5c0415b317 [852.438523] Code: b3 66 90 48 8b 05 71 4b 2d 00 64 c7 00 26 00 00 00 48 c7 c0 ff ff ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 b8 10 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 41 4b 2d 00 f7 d8 64 89 01 48 [852.438542] RSP: 002b:00007ffd765039a8 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 [852.438553] RAX: ffffffffffffffda RBX: 000055e4d7829dd0 RCX: 00007f5c0415b317 [852.438562] RDX: 00007ffd76503a00 RSI: 00000000c0406469 RDI: 0000000000000017 [852.438571] RBP: 00007ffd76503a00 R08: 0000000000000000 R09: 0000000000000081 [852.438579] R10: 00000000ffffff7f R11: 0000000000000246 R12: 00000000c0406469 [852.438587] R13: 0000000000000017 R14: 00007ffd76503a00 R15: 0000000000000000 [852.438598] </TASK> [852.438602] Modules linked in: snd_hda_codec_hdmi i915 mei_hdcp x86_pkg_temp_thermal snd_hda_intel snd_intel_dspcfg drm_buddy coretemp crct10dif_pclmul crc32_pclmul snd_hda_codec ttm ghash_clmulni_intel snd_hwdep snd_hda_core e1000e drm_dp_helper ptp snd_pcm mei_me drm_kms_helper pps_core mei syscopyarea sysfillrect sysimgblt fb_sys_fops prime_numbers intel_lpss_pci smsc75xx usbnet mii [852.440310] ---[ end trace e52cdd2fe4fd911c ]--- v2: Fix typos in the commit message. Fixes: 7e00897be8bf ("drm/i915: Add object locking to i915_gem_evict_for_node and i915_gem_evict_something, v2.") Fixes: bc1922e5d349 ("drm/i915: Fix a race between vma / object destruction and unbinding") Cc: Maarten Lankhorst <[email protected]> Signed-off-by: Thomas Hellström <[email protected]> Reviewed-by: Matthew Auld <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2022-02-28drm/panel: simple: Initialize bpc in RK101II01D-CT panel descriptorRahul T R1-0/+1
Initialize bpc while creating panel_desc structure for RK101II01D-CT Below warning is triggered since bpc is not being initialized WARNING: CPU: 2 PID: 47 at drivers/gpu/drm/panel/panel-simple.c:614 panel_simple_probe+0x1b0/0x3c8 Signed-off-by: Rahul T R <[email protected]> Reviewed-by: Tomi Valkeinen <[email protected]> Signed-off-by: Tomi Valkeinen <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2022-02-28drm/bridge: cdns-dsi: Make sure to to create proper aliases for dtNishanth Menon1-0/+1
Add MODULE_DEVICE_TABLE to the device tree table to create required aliases needed for module to be loaded with device tree based platform. Fixes: e19233955d9e ("drm/bridge: Add Cadence DSI driver") Signed-off-by: Nishanth Menon <[email protected]> Reviewed-by: Tomi Valkeinen <[email protected]> Reviewed-by: Laurent Pinchart <[email protected]> Signed-off-by: Tomi Valkeinen <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2022-02-28drm/tiny: Add MIPI DBI compatible SPI driverNoralf Trønnes3-0/+414
Add a driver that will work with most MIPI DBI compatible SPI panels. This avoids adding a driver for every new MIPI DBI compatible controller that is to be used by Linux. The 'compatible' Device Tree property with a '.bin' suffix will be used to load a firmware file that contains the controller configuration. Example (driver will load sainsmart18.bin): display@0 { compatible = "sainsmart18", "panel-mipi-dbi-spi"; ... }; v5: - kconfig: s/DRM_KMS_CMA_HELPER/DRM_GEM_CMA_HELPER/ (Sam) - kconfig: Add select VIDEOMODE_HELPERS (Sam) - kconfig: Add wiki url in the description (Sam) - Split out and use of_get_drm_panel_display_mode()(Sam) - Only use the first compatible to look for a firmware file since the binding mandates 2 compatibles. - Make having a firmware file mandatory so we can print an error message if it's missing to improve the user experience. It's very unlikely that a controller doesn't need to be initialized and if it doesn't, it's possible to have a firmware file containing only a DCS NOP. v4: - Move driver to drm/tiny where the other drivers of its kind are located. The driver module will not be shared with a future DPI driver after all. v3: - Move properties to DT (Maxime) - The MIPI DPI spec has optional support for DPI where the controller is configured over DBI. Rework the command functions so they can be moved to drm_mipi_dbi and shared with a future panel-mipi-dpi-spi driver v2: - Drop model property and use compatible instead (Rob) - Add wiki entry in MAINTAINERS Acked-by: Maxime Ripard <[email protected]> Reviewed-by: Sam Ravnborg <[email protected]> Signed-off-by: Noralf Trønnes <[email protected]> Signed-off-by: Maxime Ripard <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2022-02-28drm/modes: Add of_get_drm_panel_display_mode()Noralf Trønnes1-0/+49
Add a function to get a drm_display_mode from a panel-timing device tree subnode. Suggested-by: Sam Ravnborg <[email protected]> Reviewed-by: Sam Ravnborg <[email protected]> Signed-off-by: Noralf Trønnes <[email protected]> Signed-off-by: Maxime Ripard <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2022-02-28drm/modes: Remove trailing whitespaceNoralf Trønnes1-1/+1
Remove trailing whitespace from a comment. Acked-by: Sam Ravnborg <[email protected]> Signed-off-by: Noralf Trønnes <[email protected]> Signed-off-by: Maxime Ripard <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2022-02-28drm/i915/selftests: mock test io_sizeMatthew Auld1-0/+143
Check that mappable vs non-mappable matches our expectations. Signed-off-by: Matthew Auld <[email protected]> Cc: Thomas Hellström <[email protected]> Reviewed-by: Thomas Hellström <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2022-02-28drm/i915/buddy: tweak 2big checkMatthew Auld1-1/+1
Otherwise we get -EINVAL, instead of the more useful -E2BIG if the allocation doesn't fit within the pfn range, like with mappable lmem. The hugepages selftest, for example, needs this to know if a smaller size is needed. Signed-off-by: Matthew Auld <[email protected]> Cc: Thomas Hellström <[email protected]> Reviewed-by: Thomas Hellström <[email protected]> Acked-by: Nirmoy Das <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2022-02-28drm/i915/buddy: adjust res->startMatthew Auld1-0/+7
Differentiate between mappable vs non-mappable resources, also if this is an actual range allocation ensure we set res->start as the starting pfn. Later when we need to do non-mappable -> mappable moves then we want TTM to see that the current placement is not compatible, which should result in an actual move, instead of being turned into a noop. Signed-off-by: Matthew Auld <[email protected]> Cc: Thomas Hellström <[email protected]> Reviewed-by: Thomas Hellström <[email protected]> Acked-by: Nirmoy Das <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2022-02-28drm/i915/buddy: track available visible sizeMatthew Auld3-2/+75
Track the total amount of available visible memory, and also track per-resource the amount of used visible memory. For now this is useful for our debug output, and deciding if it is even worth calling into the buddy allocator. In the future tracking the per-resource visible usage will be useful for when deciding if we should attempt to evict certain buffers. v2: - s/place->lpfn/lpfn/, that way we can avoid scanning the list if the entire range is already mappable. - Move the end declaration inside the if block(Thomas). - Make sure to also account for reserved memory. Signed-off-by: Matthew Auld <[email protected]> Cc: Thomas Hellström <[email protected]> Reviewed-by: Thomas Hellström <[email protected]> Acked-by: Nirmoy Das <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2022-02-28drm/i915: add I915_BO_ALLOC_GPU_ONLYMatthew Auld8-18/+45
If the user doesn't require CPU access for the buffer, then ALLOC_GPU_ONLY should be used, in order to prioritise allocating in the non-mappable portion of LMEM, on devices with small BAR. v2(Thomas): - The BO_ALLOC_TOPDOWN naming here is poor, since this is pure lies on systems that don't even have small BAR. A better name is GPU_ONLY, which is accurate regardless of the configuration. Signed-off-by: Matthew Auld <[email protected]> Cc: Thomas Hellström <[email protected]> Reviewed-by: Thomas Hellström <[email protected]> Acked-by: Nirmoy Das <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2022-02-28drm/i915/ttm: require mappable by defaultMatthew Auld2-0/+9
On devices with non-mappable LMEM ensure we always allocate the pages within the mappable portion. For now we assume that all LMEM buffers will require CPU access, which is also inline with pretty much all current kernel internal users. In the next patch we will introduce a new flag to override this behaviour. Signed-off-by: Matthew Auld <[email protected]> Cc: Thomas Hellström <[email protected]> Reviewed-by: Thomas Hellström <[email protected]> Acked-by: Nirmoy Das <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2022-02-28drm/i915: add io_size plumbingMatthew Auld11-17/+29
With small LMEM-BAR we need to be able to differentiate between the total size of LMEM, and how much of it is CPU mappable. The end goal is to be able to utilize the entire range, even if part of is it not CPU accessible. v2: also update intelfb_create Signed-off-by: Matthew Auld <[email protected]> Cc: Thomas Hellström <[email protected]> Reviewed-by: Thomas Hellström <[email protected]> Acked-by: Nirmoy Das <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2022-02-28Backmerge tag 'v5.17-rc6' into drm-nextDave Airlie20-132/+149
This backmerges v5.17-rc6 so I can merge some amdgpu and some tegra changes on top. Signed-off-by: Dave Airlie <[email protected]>
2022-02-28Merge tag 'mediatek-drm-next-5.18' of ↵Dave Airlie2-9/+36
https://git.kernel.org/pub/scm/linux/kernel/git/chunkuang.hu/linux into drm-next Mediatek DRM Next for Linux 5.18 1. Transfer display binding document to yaml format. 2. Add mt8195 display device binding. 3. Allow commands to be sent during video mode. 4. Add wait_for_event for crtc disable by cmdq. Signed-off-by: Dave Airlie <[email protected]> From: Chun-Kuang Hu <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2022-02-27drm/mediatek: Add wait_for_event for crtc disable by cmdqjason-jh.lin1-0/+12
mtk_drm_crtc_atomic_disable will send an async cmd to cmdq driver, so it may not finish when cmdq_suspend is called sometimes. Add wait_for_event after sending async disable plane cmd to make sure the lastest cmd is done before cmdq_suspend. Signed-off-by: jason-jh.lin <[email protected]> Signed-off-by: Chun-Kuang Hu <[email protected]> Link: https://patchwork.kernel.org/project/linux-mediatek/patch/[email protected]/
2022-02-25drm/i915: apply PM_EARLY for non-GTT mappable objectsMatthew Auld1-0/+11
On DG2 we allow objects that are smaller than the min_page_size, under the premise that these are never mapped by the GTT, like with the paging structures. Currently the suspend-resume path will try to map such objects through the migration vm, which hits: [ 560.529217] kernel BUG at drivers/gpu/drm/i915/gt/intel_migrate.c:431! [ 560.536081] invalid opcode: 0000 [#1] PREEMPT SMP NOPTI [ 560.541629] CPU: 4 PID: 2062 Comm: rtcwake Tainted: G W 5.17.0-rc5-demarchi+ #175 [ 560.550716] Hardware name: Intel Corporation CoffeeLake Client Platform/CoffeeLake S UDIMM RVP, BIOS CNLSFWR1.R00.X220.B00.2103302221 03/30/2021 [ 560.563627] RIP: 0010:emit_pte+0x2e7/0x380 [i915] [ 560.568665] Code: ee 02 48 89 69 04 83 c6 05 83 c0 05 39 f0 0f 4f c6 48 8b 73 08 39 d0 0f 4f c2 44 89 f2 4c 8d 4a ff 49 85 f1 0f 84 62 fe ff ff <0f> 0b 48 c7 03 00 00 00 00 4d 89 c6 8b 01 48 29 ce 48 8d 57 0c 48 [ 560.587691] RSP: 0018:ffffc9000104f8a0 EFLAGS: 00010206 [ 560.592906] RAX: 0000000000000040 RBX: ffffc9000104f908 RCX: ffffc900025114d0 [ 560.600024] RDX: 0000000000010000 RSI: 00000003f9fe2000 RDI: ffffc900025114dc [ 560.607458] RBP: 0000000001840000 R08: ffff88810f335540 R09: 000000000000ffff [ 560.614865] R10: 000000000000081b R11: 0000000000000001 R12: 000000000000081b [ 560.622300] R13: 0000000000000000 R14: 0000000000010000 R15: ffff888107c3e240 [ 560.629716] FS: 00007f5b7c086580(0000) GS:ffff88846dc00000(0000) knlGS:0000000000000000 [ 560.638090] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 560.644132] CR2: 00007f3ab0a133a8 CR3: 000000010a43e003 CR4: 00000000003706e0 [ 560.651590] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 560.659002] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 560.666438] Call Trace: [ 560.668885] <TASK> [ 560.670983] intel_context_migrate_copy+0x1b1/0x4c0 [i915] [ 560.676794] __i915_ttm_move+0x628/0x790 [i915] [ 560.681704] ? dma_resv_iter_next+0x8f/0xb0 [ 560.686223] ? dma_resv_iter_first+0xe5/0x140 [ 560.690894] ? i915_deps_add_resv+0x4b/0x110 [i915] [ 560.696147] ? dma_resv_reserve_shared+0x161/0x310 [ 560.701228] i915_gem_obj_copy_ttm+0x10f/0x220 [i915] [ 560.706650] i915_ttm_backup+0x191/0x2f0 [i915] [ 560.711558] i915_gem_process_region+0x266/0x3b0 [i915] [ 560.717153] ? verify_cpu+0xf0/0x100 [ 560.721040] ? pci_pm_resume_early+0x20/0x20 [ 560.725603] i915_ttm_backup_region+0x47/0x70 [i915] [ 560.730927] i915_gem_backup_suspend+0x141/0x170 [i91 For now let's just force the memcpy path for such objects during suspend-resume. Fixes: 00e27ad85bc9 ("drm/i915/migrate: add acceleration support for DG2") Reported-by: Lucas De Marchi <[email protected]> Signed-off-by: Matthew Auld <[email protected]> Cc: Thomas Hellström <[email protected]> Reviewed-by: Thomas Hellström <[email protected]> Reviewed-by: Lucas De Marchi <[email protected]> Signed-off-by: Lucas De Marchi <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2022-02-25drm/i915/guc: Remove plain ads_blob pointerLucas De Marchi2-6/+5
Now we have the access to content of GuC ADS either using iosys_map API or using a temporary buffer. Remove guc->ads_blob as there shouldn't be updates using the bare pointer anymore. Cc: Matt Roper <[email protected]> Cc: Thomas Hellström <[email protected]> Cc: Daniel Vetter <[email protected]> Cc: John Harrison <[email protected]> Cc: Matthew Brost <[email protected]> Cc: Daniele Ceraolo Spurio <[email protected]> Signed-off-by: Lucas De Marchi <[email protected]> Reviewed-by: Matthew Brost <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2022-02-25drm/i915/guc: Convert __guc_ads_init to iosys_mapLucas De Marchi1-11/+14
Now that all the called functions from __guc_ads_init() are converted to use ads_map, stop using ads_blob in __guc_ads_init(). Cc: Matt Roper <[email protected]> Cc: Thomas Hellström <[email protected]> Cc: Daniel Vetter <[email protected]> Cc: John Harrison <[email protected]> Cc: Matthew Brost <[email protected]> Cc: Daniele Ceraolo Spurio <[email protected]> Signed-off-by: Lucas De Marchi <[email protected]> Reviewed-by: Matthew Brost <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2022-02-25drm/i915/guc: Convert guc_mmio_reg_state_init to iosys_mapLucas De Marchi1-12/+16
Now that the regset list is prepared, convert guc_mmio_reg_state_init() to use iosys_map to copy the array to the final location and initialize additional fields in ads.reg_state_list. v2: Just use an offset instead of temporary iosys_map. Cc: Matt Roper <[email protected]> Cc: Thomas Hellström <[email protected]> Cc: Daniel Vetter <[email protected]> Cc: John Harrison <[email protected]> Cc: Matthew Brost <[email protected]> Cc: Daniele Ceraolo Spurio <[email protected]> Signed-off-by: Lucas De Marchi <[email protected]> Reviewed-by: Matthew Brost <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2022-02-25drm/i915/guc: Convert capture list to iosys_mapLucas De Marchi1-5/+5
Use iosys_map to write the fields ads.capture_*. Cc: Matt Roper <[email protected]> Cc: Thomas Hellström <[email protected]> Cc: Daniel Vetter <[email protected]> Cc: John Harrison <[email protected]> Cc: Matthew Brost <[email protected]> Cc: Daniele Ceraolo Spurio <[email protected]> Signed-off-by: Lucas De Marchi <[email protected]> Reviewed-by: Matthew Brost <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2022-02-25drm/i915/guc: Convert mapping table to iosys_mapLucas De Marchi1-6/+6
Use iosys_map to write the fields system_info.mapping_table[][]. Since we already have the info_map around where needed, just use it instead of going through guc->ads_map. Cc: Matt Roper <[email protected]> Cc: Thomas Hellström <[email protected]> Cc: Daniel Vetter <[email protected]> Cc: John Harrison <[email protected]> Cc: Matthew Brost <[email protected]> Cc: Daniele Ceraolo Spurio <[email protected]> Signed-off-by: Lucas De Marchi <[email protected]> Reviewed-by: Matthew Brost <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2022-02-25drm/i915/guc: Replace check for golden context sizeLucas De Marchi1-3/+3
In the other places in this function, guc->ads_map is being protected from access when it's not yet set. However the last check is actually about guc->ads_golden_ctxt_size been set before. These checks should always match as the size is initialized on the first call to guc_prep_golden_context(), but it's clearer if we have a single return and check for guc->ads_golden_ctxt_size. This is just a readability improvement, no change in behavior. Cc: Matt Roper <[email protected]> Cc: Thomas Hellström <[email protected]> Cc: Daniel Vetter <[email protected]> Cc: John Harrison <[email protected]> Cc: Matthew Brost <[email protected]> Cc: Daniele Ceraolo Spurio <[email protected]> Signed-off-by: Lucas De Marchi <[email protected]> Reviewed-by: Matthew Brost <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2022-02-25drm/i915/guc: Convert golden context prep to iosys_mapLucas De Marchi1-20/+32
Use the saved ads_map to prepare the golden context. One difference from the init context is that this function can be called before there is a gem object (and thus the guc->ads_map) to calculare the size of the golden context that should be allocated for that object. So in this case the function needs to be prepared for not having the system_info with enabled engines filled out. To accomplish that an info_map is prepared on the side to point either to the gem object or the local variable on the stack. This allows making fill_engine_enable_masks() operate always with a iosys_map argument. Cc: Matt Roper <[email protected]> Cc: Thomas Hellström <[email protected]> Cc: Daniel Vetter <[email protected]> Cc: John Harrison <[email protected]> Cc: Matthew Brost <[email protected]> Cc: Daniele Ceraolo Spurio <[email protected]> Signed-off-by: Lucas De Marchi <[email protected]> Reviewed-by: Matthew Brost <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2022-02-25drm/i915/guc: Convert guc_ads_private_data_reset to iosys_mapLucas De Marchi1-2/+2
Use iosys_map_memset() to zero the private data as ADS may be either on system or IO memory. Cc: Matt Roper <[email protected]> Cc: Thomas Hellström <[email protected]> Cc: Daniel Vetter <[email protected]> Cc: John Harrison <[email protected]> Cc: Matthew Brost <[email protected]> Cc: Daniele Ceraolo Spurio <[email protected]> Signed-off-by: Lucas De Marchi <[email protected]> Reviewed-by: Matthew Brost <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2022-02-25drm/i915/guc: Convert engine record to iosys_mapLucas De Marchi3-16/+18
Use iosys_map to read fields from the dma_blob so access to IO and system memory is abstracted away. Cc: Matt Roper <[email protected]> Cc: Thomas Hellström <[email protected]> Cc: Daniel Vetter <[email protected]> Cc: John Harrison <[email protected]> Cc: Matthew Brost <[email protected]> Cc: Daniele Ceraolo Spurio <[email protected]> Signed-off-by: Lucas De Marchi <[email protected]> Reviewed-by: Matt Atwood<[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2022-02-25drm/i915/guc: Convert policies update to iosys_mapLucas De Marchi1-18/+23
Use iosys_map to write the policies update so access to IO and system memory is abstracted away. Cc: Matt Roper <[email protected]> Cc: Thomas Hellström <[email protected]> Cc: Daniel Vetter <[email protected]> Cc: John Harrison <[email protected]> Cc: Matthew Brost <[email protected]> Cc: Daniele Ceraolo Spurio <[email protected]> Signed-off-by: Lucas De Marchi <[email protected]> Reviewed-by: Matt Atwood <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2022-02-25drm/i915/guc: Convert golden context init to iosys_mapLucas De Marchi1-14/+12
Now the map is saved during creation, so use it to initialize the golden context, reading from shmem and writing to either system or IO memory. v2: Do not use a map iterator: add an offset to keep track of destination Cc: Matt Roper <[email protected]> Cc: Thomas Hellström <[email protected]> Cc: Daniel Vetter <[email protected]> Cc: John Harrison <[email protected]> Cc: Matthew Brost <[email protected]> Cc: Daniele Ceraolo Spurio <[email protected]> Signed-off-by: Lucas De Marchi <[email protected]> Reviewed-by: Matt Atwood <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2022-02-25drm/i915/guc: Add read/write helpers for ADS blobLucas De Marchi1-0/+7
Add helpers on top of iosys_map_read_field() / iosys_map_write_field() functions so they always use the right arguments and make code easier to read. Cc: Matt Roper <[email protected]> Cc: Thomas Hellström <[email protected]> Cc: Daniel Vetter <[email protected]> Cc: John Harrison <[email protected]> Cc: Matthew Brost <[email protected]> Cc: Daniele Ceraolo Spurio <[email protected]> Signed-off-by: Lucas De Marchi <[email protected]> Reviewed-by: Matt Atwood <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2022-02-25drm/i915/guc: Keep iosys_map of ads_blob aroundLucas De Marchi2-1/+9
Convert intel_guc_ads_create() and initialization to use iosys_map rather than plain pointer and save it in the guc struct. This will help with additional updates to the ads_blob after the creation/initialization by abstracting the IO vs system memory. Cc: Matt Roper <[email protected]> Cc: Thomas Hellström <[email protected]> Cc: Daniel Vetter <[email protected]> Cc: John Harrison <[email protected]> Cc: Matthew Brost <[email protected]> Cc: Daniele Ceraolo Spurio <[email protected]> Signed-off-by: Lucas De Marchi <[email protected]> Reviewed-by: Matt Atwood <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2022-02-25drm/i915/gt: Add helper for shmem copy to iosys_mapLucas De Marchi2-0/+35
Add a variant of shmem_read() that takes a iosys_map pointer rather than a plain pointer as argument. It's mostly a copy __shmem_rw() but adapting the api and removing the write support since there's currently only need to use iosys_map as destination. Reworking __shmem_rw() to share the implementation was tempting, but finding a good balance between reuse and clarity pushed towards a little code duplication. Since the function is small, just add the similar function with a copy/paste/adapt approach. v2: Add an offset as argument and instead of using a map iterator, use the offset to keep track of where we are writing data to. Cc: Matt Roper <[email protected]> Cc: Joonas Lahtinen <[email protected]> Cc: Tvrtko Ursulin <[email protected]> Cc: David Airlie <[email protected]> Cc: Daniel Vetter <[email protected]> Cc: Matthew Auld <[email protected]> Cc: Thomas Hellström <[email protected]> Cc: Maarten Lankhorst <[email protected]> Signed-off-by: Lucas De Marchi <[email protected]> Reviewed-by: Matt Atwood <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2022-02-25drm/msm/adreno: Expose speedbin to userspaceAkhil P Oommen3-6/+21
Expose speedbin through MSM_PARAM_CHIP_ID parameter to help userspace identify the sku. Signed-off-by: Akhil P Oommen <[email protected]> Link: https://lore.kernel.org/r/20220226005021.v2.4.I86c32730e08cba9e5c83f02ec17885124d45fa56@changeid Signed-off-by: Rob Clark <[email protected]>
2022-02-25drm/msm/a6xx: Add support for 7c3 SKUsAkhil P Oommen1-0/+15
Add support for 7c3 SKU detection using speedbin fuse. Signed-off-by: Akhil P Oommen <[email protected]> Link: https://lore.kernel.org/r/20220226005021.v2.3.I6e89c014eb17f090f716fba662bdd33073920804@changeid Signed-off-by: Rob Clark <[email protected]>
2022-02-25drm/msm/adreno: Generate name from chipid for 7c3Akhil P Oommen2-3/+13
Use a gpu name which is sprintf'ed from the chipid for 7c3 gpu instead of hardcoding one. This helps to avoid code churn in case of a gpu rename. Signed-off-by: Akhil P Oommen <[email protected]> Link: https://lore.kernel.org/r/20220226005021.v2.2.I9436e0e300f76b2e6c34136a0b902e8cfd73e0d6@changeid Signed-off-by: Rob Clark <[email protected]>
2022-02-25drm/msm: Use generic name for gpu resourcesAkhil P Oommen1-2/+2
Use generic name for resources like irq and kthread instead of hardware specific name to make it easier to grep. Signed-off-by: Akhil P Oommen <[email protected]> Link: https://lore.kernel.org/r/20220226005021.v2.1.Id3d2e7391192c86d0783aeb307d3f9fb61f9efee@changeid Signed-off-by: Rob Clark <[email protected]>
2022-02-25drm/i915/dg2: add Wa_14014947963Clint Taylor2-0/+8
BSPEC: 46123 v2: Address review feedback [MattR] v3: move register definition to gt_regs [MattR] Cc: Matt Roper <[email protected]> Signed-off-by: Clint Taylor <[email protected]> Reviewed-by: Matt Roper <[email protected]> Signed-off-by: Matt Roper <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2022-02-25drm/omap: plane: Remove redundant color encoding and range initialisationMaxime Ripard1-3/+0
The omap KMS driver will call drm_plane_create_color_properties() with a default encoding and range values of BT601 and Full Range, respectively. Since the initial value wasn't carried over in the state, the driver had to set it again in omap_plane_reset(). However, the helpers have been adjusted to set it properly at reset, so this is not needed anymore. Reviewed-by: Tomi Valkeinen <[email protected]> Signed-off-by: Maxime Ripard <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2022-02-25drm/object: Add default color encoding and range value at resetDave Stevenson1-0/+14
The drm_plane_create_color_properties() function asks for an initial value for the color encoding and range, and will set the associated plane state variable with that value if a state is present. However, that function is usually called at a time where there's no state yet. Since the drm_plane_state reset helper doesn't take care of reading that value when it's called, it means that in most cases the initial value will be 0 (so DRM_COLOR_YCBCR_BT601 and DRM_COLOR_YCBCR_LIMITED_RANGE, respectively), or the drivers will have to work around it. Let's add some code in __drm_atomic_helper_plane_state_reset() to get the initial encoding and range value if the property has been attached in order to fix this. Reviewed-by: Harry Wentland <[email protected]> Signed-off-by: Dave Stevenson <[email protected]> Signed-off-by: Maxime Ripard <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2022-02-25drm/sun4i: layer: Remove redundant zpos initialisationMaxime Ripard1-9/+7
The sun4i KMS driver will call drm_plane_create_zpos_property() with an init value depending on the plane type. Since the initial value wasn't carried over in the state, the driver had to set it again in sun4i_backend_layer_reset(). However, the helpers have been adjusted to set it properly at reset, so this is not needed anymore. Cc: [email protected] Cc: [email protected] Cc: Chen-Yu Tsai <[email protected]> Reviewed-by: Jernej Skrabec <[email protected]> Signed-off-by: Maxime Ripard <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2022-02-25drm/sti: plane: Remove redundant zpos initialisationMaxime Ripard5-10/+3
The sti KMS driver will call drm_plane_create_zpos_property() with an init value depending on the plane type. Since the initial value wasn't carried over in the state, the driver had to set it again in sti_plane_reset(). However, the helpers have been adjusted to set it properly at reset, so this is not needed anymore. Reviewed-by: Alain Volmat <[email protected]> Reviewed-by: Philippe Cornu <[email protected]> Signed-off-by: Maxime Ripard <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2022-02-25drm/rcar: plane: Remove redundant zpos initialisationMaxime Ripard2-2/+0
The rcar-du KMS driver will call drm_plane_create_zpos_property() with an init value depending on the plane type. Since the initial value wasn't carried over in the state, the driver had to set it again in rcar_du_plane_reset() and rcar_du_vsp_plane_reset(). However, the helpers have been adjusted to set it properly at reset, so this is not needed anymore. Cc: [email protected] Reviewed-by: Kieran Bingham <[email protected]> Reviewed-by: Laurent Pinchart <[email protected]> Signed-off-by: Maxime Ripard <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2022-02-25drm/omap: plane: Remove redundant zpos initialisationMaxime Ripard1-7/+0
The omap KMS driver will call drm_plane_create_zpos_property() with an init value of the plane index and the plane type. Since the initial value wasn't carried over in the state, the driver had to set it again in omap_plane_reset(). However, the helpers have been adjusted to set it properly at reset, so this is not needed anymore. Reviewed-by: Tomi Valkeinen <[email protected]> Signed-off-by: Maxime Ripard <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2022-02-25drm/nouveau/kms: Remove redundant zpos initialisationMaxime Ripard1-2/+0
The nouveau KMS driver will call drm_plane_create_zpos_property() with an init value depending on the plane purpose. Since the initial value wasn't carried over in the state, the driver had to set it again in nv50_wndw_reset(). However, the helpers have been adjusted to set it properly at reset, so this is not needed anymore. Cc: [email protected] Cc: Ben Skeggs <[email protected]> Cc: Karol Herbst <[email protected]> Cc: Lyude Paul <[email protected]> Signed-off-by: Maxime Ripard <[email protected]> Reviewed-by: Karol Herbst <[email protected]> Reviewed-by: Lyude Paul <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2022-02-25drm/msm/mdp5: Remove redundant zpos initialisationMaxime Ripard1-8/+8
The mdp KMS driver will call drm_plane_create_zpos_property() with an init value depending on the plane purpose. Since the initial value wasn't carried over in the state, the driver had to set it again in mdp5_plane_reset(). However, the helpers have been adjusted to set it properly at reset, so this is not needed anymore. Cc: [email protected] Cc: [email protected] Cc: Abhinav Kumar <[email protected]> Cc: Rob Clark <[email protected]> Cc: Sean Paul <[email protected]> Reviewed-by: Dmitry Baryshkov <[email protected]> Signed-off-by: Maxime Ripard <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2022-02-25drm/object: Add default zpos value at resetDave Stevenson1-0/+11
The drm_plane_create_zpos_property() function asks for an initial value, and will set the associated plane state variable with that value if a state is present. However, that function is usually called at a time where there's no state yet. Since the drm_plane_state reset helper doesn't take care of reading that value when it's called, it means that in most cases the initial value will be 0, or the drivers will have to work around it. Let's add some code in __drm_atomic_helper_plane_state_reset() to get the initial zpos value if the property has been attached in order to fix this. Reviewed-by: Harry Wentland <[email protected]> Reviewed-by: Laurent Pinchart <[email protected]> Signed-off-by: Dave Stevenson <[email protected]> Signed-off-by: Maxime Ripard <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2022-02-25drm/object: Add drm_object_property_get_default_value() functionDave Stevenson1-10/+43
Some functions to create properties (drm_plane_create_zpos_property or drm_plane_create_color_properties for example) will ask for a range of acceptable value and an initial one. This initial value is then stored in the values array for that property. Let's provide an helper to access this property. Acked-by: Daniel Vetter <[email protected]> Reviewed-by: Laurent Pinchart <[email protected]> Signed-off-by: Dave Stevenson <[email protected]> Signed-off-by: Maxime Ripard <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
Powered by cgit, Gruvboxed by Blaster4385.