dri-devel July 2021

dri-devel@lists.freedesktop.org

321 participants
829 discussions

[PATCH] gpu: ttm: fix GPF in ttm_bo_release
by Pavel Skripkin 08 Jul '21

08 Jul '21

My local syzbot instance hit GPF in ttm_bo_release(). Unfortunately, syzbot didn't produce a reproducer for this, but I found out possible scenario: drm_gem_vram_create() <-- drm_gem_vram_object kzalloced (bo embedded in this object) ttm_bo_init() ttm_bo_init_reserved() ttm_resource_alloc() man->func->alloc() <-- allocation failure ttm_bo_put() ttm_bo_release() ttm_mem_io_free() <-- bo->resource == NULL passed as second argument *GPF* So, I've added check in ttm_bo_release() to avoid passing NULL as second argument to ttm_mem_io_free(). Fail log: KASAN: null-ptr-deref in range [0x0000000000000020-0x0000000000000027] CPU: 1 PID: 10419 Comm: syz-executor.3 Not tainted 5.13.0-rc7-next-20210625 #7 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a-rebuilt.opensuse.org 04/01/2014 RIP: 0010:ttm_mem_io_free+0x28/0x170 drivers/gpu/drm/ttm/ttm_bo_util.c:66 Code: b1 90 41 56 41 55 41 54 55 48 89 fd 53 48 89 f3 e8 cd 19 24 fd 4c 8d 6b 20 48 b8 00 00 00 00 00 fc ff df 4c 89 ea 48 c1 ea 03 <80> 3c 02 00 0f 85 2a 01 00 00 4c 8b 63 20 31 ff 4c 89 e6 e8 00 1f RSP: 0018:ffffc900141df968 EFLAGS: 00010202 RAX: dffffc0000000000 RBX: 0000000000000000 RCX: ffffc90010da0000 RDX: 0000000000000004 RSI: ffffffff84513ea3 RDI: ffff888041fbc010 RBP: ffff888041fbc010 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000001 R11: 0000000000000000 R12: 0000000000000000 R13: 0000000000000020 R14: ffff88806b258800 R15: ffff88806b258a38 FS: 00007fa6e9845640(0000) GS:ffff88807ec00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fad61265e18 CR3: 000000005ad79000 CR4: 0000000000350ee0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: ttm_bo_release+0xd94/0x10a0 drivers/gpu/drm/ttm/ttm_bo.c:422 kref_put include/linux/kref.h:65 [inline] ttm_bo_put drivers/gpu/drm/ttm/ttm_bo.c:470 [inline] ttm_bo_init_reserved+0x7cb/0x960 drivers/gpu/drm/ttm/ttm_bo.c:1050 ttm_bo_init+0x105/0x270 drivers/gpu/drm/ttm/ttm_bo.c:1074 drm_gem_vram_create+0x332/0x4c0 drivers/gpu/drm/drm_gem_vram_helper.c:228 Fixes: d3116756a710 ("drm/ttm: rename bo->mem and make it a pointer") Signed-off-by: Pavel Skripkin <paskripkin(a)gmail.com> --- drivers/gpu/drm/ttm/ttm_bo.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c index 1b950b45cf4b..15eb97459eab 100644 --- a/drivers/gpu/drm/ttm/ttm_bo.c +++ b/drivers/gpu/drm/ttm/ttm_bo.c @@ -419,7 +419,8 @@ static void ttm_bo_release(struct kref *kref) bo->bdev->funcs->release_notify(bo); drm_vma_offset_remove(bdev->vma_manager, &bo->base.vma_node); - ttm_mem_io_free(bdev, bo->resource); + if (bo->resource) + ttm_mem_io_free(bdev, bo->resource); } if (!dma_resv_test_signaled(bo->base.resv, true) || -- 2.32.0

2 1

[PATCH RESEND v2 0/2] GPD Win Max display fixes
by Anisse Astier 07 Jul '21

07 Jul '21

This patch series is for making the GPD Win Max display usable with Linux. The GPD Win Max is a small laptop, and its eDP panel does not send an EDID over DPCD; the EDID is instead available in the intel opregion, in mailbox #5 [1] The first patch is based on Jani's patch series [2] adding support for the opregion, with changes. I've changed authorship, but I'd be glad to revert it The second patch is just to fix the orientation of the panel. Changes since v1: - rebased on drm-tip - squashed patch 1 & 2 - picked up Reviewed-by from Hans de Goede (thanks for the review) When v2 was initially sent [3] Ville Syrjälä suggested that it might be a good idea to use the ACPI _DDC method instead to get the EDID, to cover a wider range of hardware. Unfortunately, it doesn't seem available on GPD Win Max, so I think this work should be done independently, and this patch series considered separately. [1]: https://gitlab.freedesktop.org/drm/intel/-/issues/3454 [2]: https://patchwork.kernel.org/project/intel-gfx/patch/20200828061941.17051-1… [3]: https://patchwork.kernel.org/project/intel-gfx/patch/20210531204642.4907-2-… Anisse Astier (2): drm/i915/opregion: add support for mailbox #5 EDID drm: Add orientation quirk for GPD Win Max .../gpu/drm/drm_panel_orientation_quirks.c | 6 ++ drivers/gpu/drm/i915/display/intel_dp.c | 3 + drivers/gpu/drm/i915/display/intel_opregion.c | 69 ++++++++++++++++++- drivers/gpu/drm/i915/display/intel_opregion.h | 8 +++ 4 files changed, 85 insertions(+), 1 deletion(-) -- 2.31.1

1 2

[PATCH 0/3] drm/i915: Nuke GEN macros
by Lucas De Marchi 07 Jul '21

07 Jul '21

Finish the conversion to the new VER macros and nuke the old macros so we don't have more changes sneaking in. Initially I thought about waiting for a backmerge from drm-next in drm-intel-next so I could use a topic branch to finish the conversion and nuke the macro, merging the topic branch in both drm-intel-next and drm-intel-gt-next. After the backmerge landed, I realized that would not be possible anymore as we already have changes on top preventing the merge-base to be used for a topic branch. Therefore the plan is: - Apply patch 1 in drm-intel-gt-next - Apply patches 2 and 3 in drm-intel-next Since patches are tested on drm-tip, CI should flag a build breakage if someone uses the GEN macros. Another possibility is to simply apply the 3rd patch on both branches, but I don't see a real need for that. Lucas De Marchi (3): drm/i915/gt: finish INTEL_GEN and friends conversion drm/i915: finish INTEL_GEN and friends conversion gpu/drm/i915: nuke old GEN macros .../drm/i915/display/intel_display_debugfs.c | 3 ++- drivers/gpu/drm/i915/gt/intel_migrate.c | 20 +++++++++---------- drivers/gpu/drm/i915/i915_debugfs.c | 2 +- drivers/gpu/drm/i915/i915_drv.h | 15 -------------- drivers/gpu/drm/i915/intel_uncore.c | 2 +- 5 files changed, 14 insertions(+), 28 deletions(-) -- 2.31.1

3 8

[PATCH v2 0/2] GPD Win Max display fixes
by Anisse Astier 07 Jul '21

07 Jul '21

This patch series is for making the GPD Win Max display usable with Linux. The GPD Win Max is a small laptop, and its eDP panel does not send an EDID over DPCD; the EDID is instead available in the intel opregion, in mailbox #5 [1] The first patch is based on Jani's patch series [2] adding support for the opregion, with changes. I've changed authorship, but I'd be glad to revert it The second patch is just to fix the orientation of the panel. Changes since v1: - rebased on drm-tip - squashed patch 1 & 2 - picked up Reviewed-by from Hans de Goede (thanks for the review) [1]: https://gitlab.freedesktop.org/drm/intel/-/issues/3454 [2]: https://patchwork.kernel.org/project/intel-gfx/patch/20200828061941.17051-1… Anisse Astier (2): drm/i915/opregion: add support for mailbox #5 EDID drm: Add orientation quirk for GPD Win Max .../gpu/drm/drm_panel_orientation_quirks.c | 6 ++ drivers/gpu/drm/i915/display/intel_dp.c | 3 + drivers/gpu/drm/i915/display/intel_opregion.c | 69 ++++++++++++++++++- drivers/gpu/drm/i915/display/intel_opregion.h | 8 +++ 4 files changed, 85 insertions(+), 1 deletion(-) -- 2.31.1

3 6

Re: page pools, was Re: [PATCH v9 1/5] drm: Add a sharable drm page-pool implementation
by John Stultz 07 Jul '21

07 Jul '21

On Wed, Jul 7, 2021 at 12:15 AM Christoph Hellwig <hch(a)infradead.org> wrote: > > On Wed, Jul 07, 2021 at 09:10:26AM +0200, Christian K??nig wrote: > > Well, the original code all this is based on already had the comment that > > this really belong into the page allocator. > > > > The key point is traditionally only GPUs used uncached and write-combined > > memory in such large quantities that having a pool for them makes sense. > > > > Because of this we had this separately to reduce the complexity in the page > > allocator to handle another set of complexity of allocation types. > > > > For the upside, for those use cases it means huge performance improvements > > for those drivers. See the numbers John provided in the cover letter. > > > > But essentially at least I would be totally fine moving this into the page > > allocator, but moving it outside of TTM already helps with this goal. So > > this patch set is certainly a step into the right direction. > > Unless I'm badly misreading the patch and this series there is nothing > about cache attributes in this code. It just allocates pages, zeroes > them, eventually hands them out to a consumer and registers a shrinker > for its freelist. > > If OTOH it actually dealt with cachability that should be documented > in the commit log and probably also the naming of the implementation. So the cache attributes are still managed in the tmm_pool code. This series just pulls the pool/shrinker management out into common code so we can use it in the dmabuf heap code without duplicating things. thanks -john

1 0

Re: page pools, was Re: [PATCH v9 1/5] drm: Add a sharable drm page-pool implementation
by John Stultz 07 Jul '21

07 Jul '21

On Tue, Jul 6, 2021 at 11:38 PM Christoph Hellwig <hch(a)infradead.org> wrote: > On Wed, Jun 30, 2021 at 01:34:17AM +0000, John Stultz wrote: > > This adds a shrinker controlled page pool, extracted > > out of the ttm_pool logic, and abstracted out a bit > > so it can be used by other non-ttm drivers. > > Can you explain in detail why you need a differnt page pool over the one > maintained by the page allocator? Fragmenting the memory into all kinds > of pools has lots of downsides, so the upsides need to be explained in > detail. So, as Christian mentioned, on the TTM side it's useful, as they are trying to avoid TLB flushes when changing caching attributes. For the dmabuf system heap purposes, the main benefit is moving the page zeroing to the free path, rather than the allocation path. This on its own doesn't save much, but allows us to defer frees (and thus the zeroing) to the background, which can get that work out of the hot path. thanks -john

1 0

[PATCH v5 0/5] iommu/arm-smmu: adreno-smmu page fault handling
by Rob Clark 07 Jul '21

07 Jul '21

From: Rob Clark <robdclark(a)chromium.org> This picks up an earlier series[1] from Jordan, and adds additional support needed to generate GPU devcore dumps on iova faults. Original description: This is a stack to add an Adreno GPU specific handler for pagefaults. The first patch starts by wiring up report_iommu_fault for arm-smmu. The next patch adds a adreno-smmu-priv function hook to capture a handful of important debugging registers such as TTBR0, CONTEXTIDR, FSYNR0 and others. This is used by the third patch to print more detailed information on page fault such as the TTBR0 for the pagetable that caused the fault and the source of the fault as determined by a combination of the FSYNR1 register and an internal GPU register. This code provides a solid base that we can expand on later for even more extensive GPU side page fault debugging capabilities. v5: [Rob] Use RBBM_STATUS3.SMMU_STALLED_ON_FAULT to detect case where GPU snapshotting needs to avoid crashdumper, and check the RBBM_STATUS3.SMMU_STALLED_ON_FAULT in GPU hang irq paths v4: [Rob] Add support to stall SMMU on fault, and let the GPU driver resume translation after it has had a chance to snapshot the GPUs state v3: Always clear FSR even if the target driver is going to handle resume v2: Fix comment wording and function pointer check per Rob Clark [1] https://lore.kernel.org/dri-devel/20210225175135.91922-1-jcrouse@codeaurora… Jordan Crouse (3): iommu/arm-smmu: Add support for driver IOMMU fault handlers iommu/arm-smmu-qcom: Add an adreno-smmu-priv callback to get pagefault info drm/msm: Improve the a6xx page fault handler Rob Clark (2): iommu/arm-smmu-qcom: Add stall support drm/msm: devcoredump iommu fault support drivers/gpu/drm/msm/adreno/a5xx_gpu.c | 23 +++- drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 110 +++++++++++++++++++- drivers/gpu/drm/msm/adreno/a6xx_gpu_state.c | 42 ++++++-- drivers/gpu/drm/msm/adreno/adreno_gpu.c | 15 +++ drivers/gpu/drm/msm/msm_gem.h | 1 + drivers/gpu/drm/msm/msm_gem_submit.c | 1 + drivers/gpu/drm/msm/msm_gpu.c | 48 +++++++++ drivers/gpu/drm/msm/msm_gpu.h | 17 +++ drivers/gpu/drm/msm/msm_gpummu.c | 5 + drivers/gpu/drm/msm/msm_iommu.c | 22 +++- drivers/gpu/drm/msm/msm_mmu.h | 5 +- drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c | 50 +++++++++ drivers/iommu/arm/arm-smmu/arm-smmu.c | 9 +- drivers/iommu/arm/arm-smmu/arm-smmu.h | 2 + include/linux/adreno-smmu-priv.h | 38 ++++++- 15 files changed, 367 insertions(+), 21 deletions(-) -- 2.31.1

7 19

re: drm/amdkfd: implement counters for vm fault and migration
by Colin Ian King 07 Jul '21

07 Jul '21

Hi, Static analysis with Coverity on linux-next has found a potential null pointer dereference in function svm_range_restore_pages in drivers/gpu/drm/amd/amdkfd/kfd_svm.c from the following commit: commit d4ebc2007040a0aff01bfe1b194085d3867328fd Author: Philip Yang <Philip.Yang(a)amd.com> Date: Tue Jun 22 00:12:32 2021 -0400 drm/amdkfd: implement counters for vm fault and migration The analysis is as follows: 2397 int 2398 svm_range_restore_pages(struct amdgpu_device *adev, unsigned int pasid, 2399 uint64_t addr) 2400{ 2401 struct mm_struct *mm = NULL; 2402 struct svm_range_list *svms; 2403 struct svm_range *prange; 2404 struct kfd_process *p; 2405 uint64_t timestamp; 2406 int32_t best_loc; 2407 int32_t gpuidx = MAX_GPU_INSTANCE; 2408 bool write_locked = false; 2409 int r = 0; 2410 1. Condition !(adev->kfd.dev->pgmap.type != 0), taking false branch. 2411 if (!KFD_IS_SVM_API_SUPPORTED(adev->kfd.dev)) { 2412 pr_debug("device does not support SVM\n"); 2413 return -EFAULT; 2414 } 2415 2416 p = kfd_lookup_process_by_pasid(pasid); 2. Condition !p, taking false branch. 2417 if (!p) { 2418 pr_debug("kfd process not founded pasid 0x%x\n", pasid); 2419 return -ESRCH; 2420 } 3. Condition !p->xnack_enabled, taking false branch. 2421 if (!p->xnack_enabled) { 2422 pr_debug("XNACK not enabled for pasid 0x%x\n", pasid); 2423 return -EFAULT; 2424 } 2425 svms = &p->svms; 2426 4. Condition 0 /* __builtin_types_compatible_p() */, taking false branch. 5. Condition 1 /* __builtin_types_compatible_p() */, taking true branch. 6. Falling through to end of if statement. 7. Condition !!branch, taking false branch. 8. Condition ({...; !!branch;}), taking false branch. 2427 pr_debug("restoring svms 0x%p fault address 0x%llx\n", svms, addr); 2428 2429 mm = get_task_mm(p->lead_thread); 9. Condition !mm, taking false branch. 2430 if (!mm) { 2431 pr_debug("svms 0x%p failed to get mm\n", svms); 2432 r = -ESRCH; 2433 goto out; 2434 } 2435 2436 mmap_read_lock(mm); 2437retry_write_locked: 2438 mutex_lock(&svms->lock); 2439 prange = svm_range_from_addr(svms, addr, NULL); 10. Condition !prange, taking true branch. 18. Condition !prange, taking true branch. 2440 if (!prange) { 11. Condition 0 /* __builtin_types_compatible_p() */, taking false branch. 12. Condition 1 /* __builtin_types_compatible_p() */, taking true branch. 13. Falling through to end of if statement. 14. Condition !!branch, taking false branch. 15. Condition ({...; !!branch;}), taking false branch. 19. Condition 0 /* __builtin_types_compatible_p() */, taking false branch. 20. Condition 1 /* __builtin_types_compatible_p() */, taking true branch. 21. Falling through to end of if statement. 22. Condition !!branch, taking false branch. 23. Condition ({...; !!branch;}), taking false branch. 2441 pr_debug("failed to find prange svms 0x%p address [0x%llx]\n", 2442 svms, addr); 16. Condition !write_locked, taking true branch. 24. Condition !write_locked, taking false branch. 2443 if (!write_locked) { 2444 /* Need the write lock to create new range with MMU notifier. 2445 * Also flush pending deferred work to make sure the interval 2446 * tree is up to date before we add a new range 2447 */ 2448 mutex_unlock(&svms->lock); 2449 mmap_read_unlock(mm); 2450 mmap_write_lock(mm); 2451 write_locked = true; 17. Jumping to label retry_write_locked. 2452 goto retry_write_locked; 2453 } 2454 prange = svm_range_create_unregistered_range(adev, p, mm, addr); 25. Condition !prange, taking true branch. 26. var_compare_op: Comparing prange to null implies that prange might be null. 2455 if (!prange) { 27. Condition 0 /* __builtin_types_compatible_p() */, taking false branch. 28. Condition 1 /* __builtin_types_compatible_p() */, taking true branch. 29. Falling through to end of if statement. 30. Condition !!branch, taking false branch. 31. Condition ({...; !!branch;}), taking false branch. 2456 pr_debug("failed to create unregistered range svms 0x%p address [0x%llx]\n", 2457 svms, addr); 2458 mmap_write_downgrade(mm); 2459 r = -EFAULT; 32. Jumping to label out_unlock_svms. 2460 goto out_unlock_svms; 2461 } 2462 } 2463 if (write_locked) 2464 mmap_write_downgrade(mm); 2465 2466 mutex_lock(&prange->migrate_mutex); 2467 2468 if (svm_range_skip_recover(prange)) { 2469 amdgpu_gmc_filter_faults_remove(adev, addr, pasid); 2470 goto out_unlock_range; 2471 } 2472 2473 timestamp = ktime_to_us(ktime_get()) - prange->validate_timestamp; 2474 /* skip duplicate vm fault on different pages of same range */ 2475 if (timestamp < AMDGPU_SVM_RANGE_RETRY_FAULT_PENDING) { 2476 pr_debug("svms 0x%p [0x%lx %lx] already restored\n", 2477 svms, prange->start, prange->last); 2478 goto out_unlock_range; 2479 } 2480 2481 best_loc = svm_range_best_restore_location(prange, adev, &gpuidx); 2482 if (best_loc == -1) { 2483 pr_debug("svms %p failed get best restore loc [0x%lx 0x%lx]\n", 2484 svms, prange->start, prange->last); 2485 r = -EACCES; 2486 goto out_unlock_range; 2487 } 2488 2489 pr_debug("svms %p [0x%lx 0x%lx] best restore 0x%x, actual loc 0x%x\n", 2490 svms, prange->start, prange->last, best_loc, 2491 prange->actual_loc); 2492 2493 if (prange->actual_loc != best_loc) { 2494 if (best_loc) { 2495 r = svm_migrate_to_vram(prange, best_loc, mm); 2496 if (r) { 2497 pr_debug("svm_migrate_to_vram failed (%d) at %llx, falling back to system memory\n", 2498 r, addr); 2499 /* Fallback to system memory if migration to 2500 * VRAM failed 2501 */ 2502 if (prange->actual_loc) 2503 r = svm_migrate_vram_to_ram(prange, mm); 2504 else 2505 r = 0; 2506 } 2507 } else { 2508 r = svm_migrate_vram_to_ram(prange, mm); 2509 } 2510 if (r) { 2511 pr_debug("failed %d to migrate svms %p [0x%lx 0x%lx]\n", 2512 r, svms, prange->start, prange->last); 2513 goto out_unlock_range; 2514 } 2515 } 2516 2517 r = svm_range_validate_and_map(mm, prange, gpuidx, false, false); 2518 if (r) 2519 pr_debug("failed %d to map svms 0x%p [0x%lx 0x%lx] to gpus\n", 2520 r, svms, prange->start, prange->last); 2521 2522out_unlock_range: 2523 mutex_unlock(&prange->migrate_mutex); 2524out_unlock_svms: 2525 mutex_unlock(&svms->lock); 2526 mmap_read_unlock(mm); 2527 Dereference after null check (FORWARD_NULL) 33. var_deref_model: Passing null pointer prange to svm_range_count_fault, which dereferences it. 2528 svm_range_count_fault(adev, p, prange, gpuidx); The jump in line 2460 to out_unlock_svms will occur if prange is null, however, calling svm_range_count_fault with a null prange will cause a null pointer deference when it calls svm_range_get_pdd_by_adev and dereferences the pointer as follows: p = container_of(prange->svms, struct kfd_process, svms); Colin

3 3

[PATCH] drm/vkms: Create vkms_config_debufs in vkms_drv.c
by Beatriz Martins de Carvalho 07 Jul '21

07 Jul '21

Development vkms_config_debufs in vkms_drv.c for the long term plan of making vkms configurable and have multiple different instances it's useful to be able to get at the config of each instance in debugfs Signed-off-by: Beatriz Martins de Carvalho <martinsdecarvalhobeatriz(a)gmail.com> --- drivers/gpu/drm/vkms/vkms_drv.c | 28 ++++++++++++++++++++++++++++ 1 file changed, 28 insertions(+) diff --git a/drivers/gpu/drm/vkms/vkms_drv.c b/drivers/gpu/drm/vkms/vkms_drv.c index 027ffe759440..c81fba6c72f0 100644 --- a/drivers/gpu/drm/vkms/vkms_drv.c +++ b/drivers/gpu/drm/vkms/vkms_drv.c @@ -28,6 +28,9 @@ #include "vkms_drv.h" +#include <drm/drm_print.h> +#include <drm/drm_debugfs.h> + #define DRIVER_NAME "vkms" #define DRIVER_DESC "Virtual Kernel Mode Setting" #define DRIVER_DATE "20180514" @@ -86,12 +89,37 @@ static void vkms_atomic_commit_tail(struct drm_atomic_state *old_state) drm_atomic_helper_cleanup_planes(dev, old_state); } +static int vkms_config_show(struct seq_file *m, void *data) +{ + struct drm_info_node *node = (struct drm_info_node *)m->private; + struct drm_device *dev = node->minor->dev; + struct vkms_device *vkmsdev = drm_device_to_vkms_device(dev); + + seq_printf(m, "writeback=%d\n", vkmsdev->config->writeback); + seq_printf(m, "cursor=%d\n", vkmsdev->config->cursor); + seq_printf(m, "overlay=%d\n", vkmsdev->config->overlay); + + return 0; +} + +static const struct drm_info_list vkms_config_debugfs_list[] = { + { "vkms_config", vkms_config_show, 0 }, +}; + +static void vkms_config_debugfs_init(struct drm_minor *minor) +{ + drm_debugfs_create_files(vkms_config_debugfs_list, ARRAY_SIZE(vkms_config_debugfs_list), + minor->debugfs_root, minor); +} + static const struct drm_driver vkms_driver = { .driver_features = DRIVER_MODESET | DRIVER_ATOMIC | DRIVER_GEM, .release = vkms_release, .fops = &vkms_driver_fops, DRM_GEM_SHMEM_DRIVER_OPS, + .debugfs_init = vkms_config_debugfs_init, + .name = DRIVER_NAME, .desc = DRIVER_DESC, .date = DRIVER_DATE, -- 2.25.1

2 1

[PULL] drm-intel-next-fixes
by Rodrigo Vivi 07 Jul '21

07 Jul '21

Hi Dave and Daniel, Here goes drm-intel-next-fixes-2021-07-07: One fix targeting stable for display DP VSC, plus DG1 display fix and a bug fix of IRQs usages and cleanup references to the DRM IRQ midlayer. Thanks, Rodrigo. The following changes since commit 8a02ea42bc1d4c448caf1bab0e05899dad503f74: Merge tag 'drm-intel-next-fixes-2021-06-29' of git://anongit.freedesktop.org/drm/drm-intel into drm-next (2021-06-30 15:42:05 +1000) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm-intel tags/drm-intel-next-fixes-2021-07-07 for you to fetch changes up to 3dd6c11b60d2f1e4082221a8831f91093c4494aa: drm/i915: Drop all references to DRM IRQ midlayer (2021-07-06 15:10:58 -0400) ---------------------------------------------------------------- One fix targeting stable for display DP VSC, plus DG1 display fix and a bug fix of IRQs usages and cleanup references to the DRM IRQ midlayer. ---------------------------------------------------------------- José Roberto de Souza (1): drm/i915/display/dg1: Correctly map DPLLs during state readout Kees Cook (1): drm/i915/display: Do not zero past infoframes.vsc Thomas Zimmermann (2): drm/i915: Use the correct IRQ during resume drm/i915: Drop all references to DRM IRQ midlayer drivers/gpu/drm/i915/display/intel_ddi.c | 19 ++++++++++++++++--- drivers/gpu/drm/i915/display/intel_dp.c | 2 +- drivers/gpu/drm/i915/gt/intel_engine_cs.c | 2 +- drivers/gpu/drm/i915/gt/intel_ring_submission.c | 7 +++++-- drivers/gpu/drm/i915/i915_drv.c | 1 - drivers/gpu/drm/i915/i915_irq.c | 10 +++++----- drivers/gpu/drm/i915/i915_irq.h | 1 + drivers/gpu/drm/i915/i915_reg.h | 3 --- 8 files changed, 29 insertions(+), 16 deletions(-)

1 0

← Newer
1
...
71
72
73
74
75
76
77
...
83
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

dri-devel July 2021