dri-devel January 2022

dri-devel@lists.freedesktop.org

373 participants
842 discussions

[Bug 206475] New: amdgpu under load drop signal to monitor until hard reset
by bugzilla-daemon＠bugzilla.kernel.org 06 Jan '22

06 Jan '22

https://bugzilla.kernel.org/show_bug.cgi?id=206475 Bug ID: 206475 Summary: amdgpu under load drop signal to monitor until hard reset Product: Drivers Version: 2.5 Kernel Version: 5.5.2 Hardware: All OS: Linux Tree: Mainline Status: NEW Severity: normal Priority: P1 Component: Video(DRI - non Intel) Assignee: drivers_video-dri(a)kernel-bugs.osdl.org Reporter: rodomar705(a)protonmail.com Regression: No Created attachment 287265 --> https://bugzilla.kernel.org/attachment.cgi?id=287265&action=edit dmesg for the amdgpu hardware freeze While gaming the monitor goes blank randomly, only with this error in the logs of the system kernel: amdgpu: [powerplay] last message was failed ret is 65535 kernel: amdgpu: [powerplay] failed to send message 200 ret is 65535 kernel: amdgpu: [powerplay] last message was failed ret is 65535 kernel: amdgpu: [powerplay] failed to send message 282 ret is 65535 kernel: amdgpu: [powerplay] last message was failed ret is 65535 kernel: amdgpu: [powerplay] failed to send message 201 ret is 65535 with the occasional kernel: [drm:drm_atomic_helper_wait_for_flip_done [drm_kms_helper]] *ERROR* [CRTC:47:crtc-0] flip_done timed out kernel: [drm:amdgpu_job_timedout [amdgpu]] *ERROR* ring gfx timeout, signaled seq=5275264, emitted seq=5275266 kernel: [drm:amdgpu_job_timedout [amdgpu]] *ERROR* Process information: process Hand of Fate 2. pid 682062 thread Hand of Fa:cs0 pid 682064 kernel: amdgpu 0000:06:00.0: GPU reset begin! over and over again. If I reset the system no video output is seen until the system is fully shut off. B450 chipset + Ryzen 5 2600 + Radeon RX580 GPU Full log is attached to this post. Can anyone at AMD give me some pointers to what the problem is? Thanks, Marco. -- You are receiving this mail because: You are watching the assignee of the bug.

1 22

Re: [PATCH v6 2/6] drm: improve drm_buddy_alloc function
by Arunpravin 06 Jan '22

06 Jan '22

> -----Original Message----- > From: amd-gfx <amd-gfx-bounces(a)lists.freedesktop.org> On Behalf Of Matthew Auld > Sent: Tuesday, January 4, 2022 7:32 PM > To: Paneer Selvam, Arunpravin <Arunpravin.PaneerSelvam(a)amd.com>; dri-devel(a)lists.freedesktop.org; intel-gfx(a)lists.freedesktop.org; amd-gfx(a)lists.freedesktop.org > Cc: Deucher, Alexander <Alexander.Deucher(a)amd.com>; tzimmermann(a)suse.de; jani.nikula(a)linux.intel.com; Koenig, Christian <Christian.Koenig(a)amd.com>; daniel(a)ffwll.ch > Subject: Re: [PATCH v6 2/6] drm: improve drm_buddy_alloc function > > On 26/12/2021 22:24, Arunpravin wrote: >> - Make drm_buddy_alloc a single function to handle >> range allocation and non-range allocation demands >> >> - Implemented a new function alloc_range() which allocates >> the requested power-of-two block comply with range limitations >> >> - Moved order computation and memory alignment logic from >> i915 driver to drm buddy >> >> v2: >> merged below changes to keep the build unbroken >> - drm_buddy_alloc_range() becomes obsolete and may be removed >> - enable ttm range allocation (fpfn / lpfn) support in i915 driver >> - apply enhanced drm_buddy_alloc() function to i915 driver >> >> v3(Matthew Auld): >> - Fix alignment issues and remove unnecessary list_empty check >> - add more validation checks for input arguments >> - make alloc_range() block allocations as bottom-up >> - optimize order computation logic >> - replace uint64_t with u64, which is preferred in the kernel >> >> v4(Matthew Auld): >> - keep drm_buddy_alloc_range() function implementation for generic >> actual range allocations >> - keep alloc_range() implementation for end bias allocations >> >> Signed-off-by: Arunpravin <Arunpravin.PaneerSelvam(a)amd.com> > > <snip> > >> @@ -73,34 +83,16 @@ static int i915_ttm_buddy_man_alloc(struct ttm_resource_manager *man, >> >> n_pages = size >> ilog2(mm->chunk_size); >> >> - do { >> - struct drm_buddy_block *block; >> - unsigned int order; >> - >> - order = fls(n_pages) - 1; >> - GEM_BUG_ON(order > mm->max_order); >> - GEM_BUG_ON(order < min_order); >> - >> - do { >> - mutex_lock(&bman->lock); >> - block = drm_buddy_alloc(mm, order); >> - mutex_unlock(&bman->lock); >> - if (!IS_ERR(block)) >> - break; >> - >> - if (order-- == min_order) { >> - err = -ENOSPC; >> - goto err_free_blocks; >> - } >> - } while (1); >> - >> - n_pages -= BIT(order); >> - >> - list_add_tail(&block->link, &bman_res->blocks); >> - >> - if (!n_pages) >> - break; >> - } while (1); >> + mutex_lock(&bman->lock); >> + err = drm_buddy_alloc(mm, (u64)place->fpfn << PAGE_SHIFT, >> + (u64)place->lpfn << PAGE_SHIFT, > > place->lpfn will currently always be zero for i915, AFAIK. I assume here > we want s/place->lpfn/lpfn/? I replaced place->lpfn with lpfn as below >> + err = drm_buddy_alloc(mm, (u64)place->fpfn << PAGE_SHIFT, >> + (u64)lpfn << PAGE_SHIFT, AFAIK, we need to change only at above location, hope this fixes the firmware allocation issue. > > Also something in this series is preventing i915 from loading on > discrete devices, according to CI. Hopefully that is just the lpfn > issue...which might explain seeing -EINVAL here[1] when allocating some > vram for the firmware. > > [1] > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fintel-gfx… > > >> + (u64)n_pages << PAGE_SHIFT, >> + min_page_size, >> + &bman_res->blocks, >> + bman_res->flags); >> + mutex_unlock(&bman->lock); >> + if (unlikely(err)) >> + goto err_free_blocks; >> >> *res = &bman_res->base; >> return 0; >> @@ -266,10 +258,17 @@ int i915_ttm_buddy_man_reserve(struct ttm_resource_manager *man, >> { >> struct i915_ttm_buddy_manager *bman = to_buddy_manager(man); >> struct drm_buddy_mm *mm = &bman->mm; >> + unsigned long flags = 0; >> int ret; >> >> + flags |= DRM_BUDDY_RANGE_ALLOCATION; >> + >> mutex_lock(&bman->lock); >> - ret = drm_buddy_alloc_range(mm, &bman->reserved, start, size); >> + ret = drm_buddy_alloc(mm, start, >> + start + size, >> + size, mm->chunk_size, >> + &bman->reserved, >> + flags); >> mutex_unlock(&bman->lock); >> >> return ret; >> diff --git a/drivers/gpu/drm/i915/i915_ttm_buddy_manager.h b/drivers/gpu/drm/i915/i915_ttm_buddy_manager.h >> index fa644b512c2e..5ba490875f66 100644 >> --- a/drivers/gpu/drm/i915/i915_ttm_buddy_manager.h >> +++ b/drivers/gpu/drm/i915/i915_ttm_buddy_manager.h >> @@ -20,6 +20,7 @@ struct drm_buddy_mm; >> * >> * @base: struct ttm_resource base class we extend >> * @blocks: the list of struct i915_buddy_block for this resource/allocation >> + * @flags: DRM_BUDDY_*_ALLOCATION flags >> * @mm: the struct i915_buddy_mm for this resource >> * >> * Extends the struct ttm_resource to manage an address space allocation with >> @@ -28,6 +29,7 @@ struct drm_buddy_mm; >> struct i915_ttm_buddy_resource { >> struct ttm_resource base; >> struct list_head blocks; >> + unsigned long flags; >> struct drm_buddy_mm *mm; >> }; >> >> diff --git a/include/drm/drm_buddy.h b/include/drm/drm_buddy.h >> index 09d73328c268..4368acaad222 100644 >> --- a/include/drm/drm_buddy.h >> +++ b/include/drm/drm_buddy.h >> @@ -13,15 +13,22 @@ >> >> #include <drm/drm_print.h> >> >> -#define range_overflows(start, size, max) ({ \ >> +#define check_range_overflow(start, end, size, max) ({ \ >> typeof(start) start__ = (start); \ >> + typeof(end) end__ = (end);\ >> typeof(size) size__ = (size); \ >> typeof(max) max__ = (max); \ >> (void)(&start__ == &size__); \ >> (void)(&start__ == &max__); \ >> - start__ >= max__ || size__ > max__ - start__; \ >> + (void)(&start__ == &end__); \ >> + (void)(&end__ == &size__); \ >> + (void)(&end__ == &max__); \ >> + start__ >= max__ || end__ > max__ || \ >> + size__ > end__ - start__; \ >> }) >> >> +#define DRM_BUDDY_RANGE_ALLOCATION (1 << 0) >> + >> struct drm_buddy_block { >> #define DRM_BUDDY_HEADER_OFFSET GENMASK_ULL(63, 12) >> #define DRM_BUDDY_HEADER_STATE GENMASK_ULL(11, 10) >> @@ -132,12 +139,11 @@ int drm_buddy_init(struct drm_buddy_mm *mm, u64 size, u64 chunk_size); >> >> void drm_buddy_fini(struct drm_buddy_mm *mm); >> >> -struct drm_buddy_block * >> -drm_buddy_alloc(struct drm_buddy_mm *mm, unsigned int order); >> - >> -int drm_buddy_alloc_range(struct drm_buddy_mm *mm, >> - struct list_head *blocks, >> - u64 start, u64 size); >> +int drm_buddy_alloc(struct drm_buddy_mm *mm, >> + u64 start, u64 end, u64 size, >> + u64 min_page_size, >> + struct list_head *blocks, >> + unsigned long flags); >> >> void drm_buddy_free(struct drm_buddy_mm *mm, struct drm_buddy_block *block); >> >>

1 0

[PATCH v4] drm/msm/dp: populate connector of struct dp_panel
by Kuogee Hsieh 06 Jan '22

06 Jan '22

DP CTS test case 4.2.2.6 has valid edid with bad checksum on purpose and expect DP source return correct checksum. During drm edid read, correct edid checksum is calculated and stored at connector::real_edid_checksum. The problem is struct dp_panel::connector never be assigned, instead the connector is stored in struct msm_dp::connector. When we run compliance testing test case 4.2.2.6 dp_panel_handle_sink_request() won't have a valid edid set in struct dp_panel::edid so we'll try to use the connectors real_edid_checksum and hit a NULL pointer dereference error because the connector pointer is never assigned. Changes in V2: -- populate panel connector at msm_dp_modeset_init() instead of at dp_panel_read_sink_caps() Changes in V3: -- remove unhelpful kernel crash trace commit text -- remove renaming dp_display parameter to dp Changes in V4: -- add more details to commit text Fixes: 7948fe12d47 ("drm/msm/dp: return correct edid checksum after corrupted edid checksum read") Signee-off-by: Kuogee Hsieh <quic_khsieh(a)quicinc.com> --- drivers/gpu/drm/msm/dp/dp_display.c | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/drivers/gpu/drm/msm/dp/dp_display.c b/drivers/gpu/drm/msm/dp/dp_display.c index 3449d3f..40a059d 100644 --- a/drivers/gpu/drm/msm/dp/dp_display.c +++ b/drivers/gpu/drm/msm/dp/dp_display.c @@ -1499,6 +1499,7 @@ int msm_dp_modeset_init(struct msm_dp *dp_display, struct drm_device *dev, struct drm_encoder *encoder) { struct msm_drm_private *priv; + struct dp_display_private *dp_priv; int ret; if (WARN_ON(!encoder) || WARN_ON(!dp_display) || WARN_ON(!dev)) @@ -1507,6 +1508,8 @@ int msm_dp_modeset_init(struct msm_dp *dp_display, struct drm_device *dev, priv = dev->dev_private; dp_display->drm_dev = dev; + dp_priv = container_of(dp_display, struct dp_display_private, dp_display); + ret = dp_display_request_irq(dp_display); if (ret) { DRM_ERROR("request_irq failed, ret=%d\n", ret); @@ -1524,6 +1527,8 @@ int msm_dp_modeset_init(struct msm_dp *dp_display, struct drm_device *dev, return ret; } + dp_priv->panel->connector = dp_display->connector; + priv->connectors[priv->num_connectors++] = dp_display->connector; return 0; } -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project

1 0

[PATCH v3] drm/msm/dp: populate connector of struct dp_panel
by Kuogee Hsieh 06 Jan '22

06 Jan '22

We never assign struct dp_panel::connector, instead the connector is stored in struct msm_dp::connector. When we run compliance testing test case 4.2.2.6 dp_panel_handle_sink_request() won't have a valid edid set in struct dp_panel::edid so we'll try to use the connectors real_edid_checksum and hit a NULL pointer dereference error because the connector pointer is never assigned. Changes in V2: -- populate panel connector at msm_dp_modeset_init() instead of at dp_panel_read_sink_caps() Changes in V3: -- remove unhelpful kernel crash trace commit text -- remove renaming dp_display parameter to dp Fixes: 7948fe12d47 ("drm/msm/dp: return correct edid checksum after corrupted edid checksum read") Signee-off-by: Kuogee Hsieh <quic_khsieh(a)quicinc.com> --- drivers/gpu/drm/msm/dp/dp_display.c | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/drivers/gpu/drm/msm/dp/dp_display.c b/drivers/gpu/drm/msm/dp/dp_display.c index 3449d3f..40a059d 100644 --- a/drivers/gpu/drm/msm/dp/dp_display.c +++ b/drivers/gpu/drm/msm/dp/dp_display.c @@ -1499,6 +1499,7 @@ int msm_dp_modeset_init(struct msm_dp *dp_display, struct drm_device *dev, struct drm_encoder *encoder) { struct msm_drm_private *priv; + struct dp_display_private *dp_priv; int ret; if (WARN_ON(!encoder) || WARN_ON(!dp_display) || WARN_ON(!dev)) @@ -1507,6 +1508,8 @@ int msm_dp_modeset_init(struct msm_dp *dp_display, struct drm_device *dev, priv = dev->dev_private; dp_display->drm_dev = dev; + dp_priv = container_of(dp_display, struct dp_display_private, dp_display); + ret = dp_display_request_irq(dp_display); if (ret) { DRM_ERROR("request_irq failed, ret=%d\n", ret); @@ -1524,6 +1527,8 @@ int msm_dp_modeset_init(struct msm_dp *dp_display, struct drm_device *dev, return ret; } + dp_priv->panel->connector = dp_display->connector; + priv->connectors[priv->num_connectors++] = dp_display->connector; return 0; } -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project

2 1

[PATCH] drm: omapdrm: Fix implicit dma_buf fencing
by Ivaylo Dimitrov 06 Jan '22

06 Jan '22

Currently omapdrm driver does not initialize dma_buf_export_info resv member, which leads to a new dma_resv being allocated and attached to the exported dma_buf. This leads to the issue that fences created on dma_buf objects imported by other drivers are ignored by omapdrm, as only fences in gem object resv are waited on. This leads to various issues like displaying incomplete frames. Fix that by initializing dma_buf resv to the resv of the gem object being exported. Signed-off-by: Ivaylo Dimitrov <ivo.g.dimitrov.75(a)gmail.com> --- drivers/gpu/drm/omapdrm/omap_gem_dmabuf.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpu/drm/omapdrm/omap_gem_dmabuf.c b/drivers/gpu/drm/omapdrm/omap_gem_dmabuf.c index f1f93cabb61e..a111e5c91925 100644 --- a/drivers/gpu/drm/omapdrm/omap_gem_dmabuf.c +++ b/drivers/gpu/drm/omapdrm/omap_gem_dmabuf.c @@ -88,6 +88,7 @@ struct dma_buf *omap_gem_prime_export(struct drm_gem_object *obj, int flags) exp_info.size = omap_gem_mmap_size(obj); exp_info.flags = flags; exp_info.priv = obj; + exp_info.resv = obj->resv; return drm_gem_dmabuf_export(obj->dev, &exp_info); } -- 2.20.1

5 5

[PATCH v2] drm/msm/dp: populate connector of struct dp_panel
by Kuogee Hsieh 06 Jan '22

06 Jan '22

There is kernel crashed due to unable to handle kernel NULL pointer dereference of dp_panel->connector while running DP link layer compliance test case 4.2.2.6 (EDID Corruption Detection). This patch fixes this problem by populating connector of dp_panel. [drm:dp_panel_read_sink_caps] *ERROR* panel edid read failed Unable to handle kernel NULL pointer dereference at virtual address 00000000000006e1 Mem abort info: ESR = 0x96000006 EC = 0x25: DABT (current EL), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 Data abort info: ISV = 0, ISS = 0x00000006 CM = 0, WnR = 0 user pgtable: 4k pages, 39-bit VAs, pgdp=0000000115f25000 [00000000000006e1] pgd=00000001174fe003, p4d=00000001174fe003, pud=00000001174fe003, pmd=0000000000000000 Internal error: Oops: 96000006 [#1] PREEMPT SMP {...] Changes in V2: -- populate panel connector at msm_dp_modeset_init() instead of at dp_panel_read_sink_caps() Fixes: 7948fe12d47 ("drm/msm/dp: return correct edid checksum after corrupted edid checksum read") Signee-off-by: Kuogee Hsieh <quic_khsieh(a)quicinc.com> --- drivers/gpu/drm/msm/dp/dp_display.c | 25 +++++++++++++++---------- 1 file changed, 15 insertions(+), 10 deletions(-) diff --git a/drivers/gpu/drm/msm/dp/dp_display.c b/drivers/gpu/drm/msm/dp/dp_display.c index 3449d3f..c282bbf 100644 --- a/drivers/gpu/drm/msm/dp/dp_display.c +++ b/drivers/gpu/drm/msm/dp/dp_display.c @@ -1495,36 +1495,41 @@ void msm_dp_debugfs_init(struct msm_dp *dp_display, struct drm_minor *minor) } } -int msm_dp_modeset_init(struct msm_dp *dp_display, struct drm_device *dev, +int msm_dp_modeset_init(struct msm_dp *dp, struct drm_device *dev, struct drm_encoder *encoder) { struct msm_drm_private *priv; + struct dp_display_private *dp_display; int ret; - if (WARN_ON(!encoder) || WARN_ON(!dp_display) || WARN_ON(!dev)) + if (WARN_ON(!encoder) || WARN_ON(!dp) || WARN_ON(!dev)) return -EINVAL; priv = dev->dev_private; - dp_display->drm_dev = dev; + dp->drm_dev = dev; + + dp_display = container_of(dp, struct dp_display_private, dp_display); - ret = dp_display_request_irq(dp_display); + ret = dp_display_request_irq(dp); if (ret) { DRM_ERROR("request_irq failed, ret=%d\n", ret); return ret; } - dp_display->encoder = encoder; + dp->encoder = encoder; - dp_display->connector = dp_drm_connector_init(dp_display); - if (IS_ERR(dp_display->connector)) { - ret = PTR_ERR(dp_display->connector); + dp->connector = dp_drm_connector_init(dp); + if (IS_ERR(dp->connector)) { + ret = PTR_ERR(dp->connector); DRM_DEV_ERROR(dev->dev, "failed to create dp connector: %d\n", ret); - dp_display->connector = NULL; + dp->connector = NULL; return ret; } - priv->connectors[priv->num_connectors++] = dp_display->connector; + dp_display->panel->connector = dp->connector; + + priv->connectors[priv->num_connectors++] = dp->connector; return 0; } -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project

2 2

[PATCH] drm/i915: Lock timeline mutex directly in error path of eb_pin_timeline
by Matthew Brost 06 Jan '22

06 Jan '22

Don't use the interruptable version of the timeline mutex lock in the error path of eb_pin_timeline as the cleanup must always happen. v2: (John Harrison) - Don't check for interrupt during mutex lock Fixes: 544460c33821 ("drm/i915: Multi-BB execbuf") Signed-off-by: Matthew Brost <matthew.brost(a)intel.com> --- drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c index e9541244027a..e96e133cbb1f 100644 --- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c +++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c @@ -2516,9 +2516,9 @@ static int eb_pin_timeline(struct i915_execbuffer *eb, struct intel_context *ce, timeout) < 0) { i915_request_put(rq); - tl = intel_context_timeline_lock(ce); + mutex_lock(&ce->timeline->mutex); intel_context_exit(ce); - intel_context_timeline_unlock(tl); + mutex_unlock(&ce->timeline->mutex); if (nonblock) return -EWOULDBLOCK; -- 2.34.1

2 6

[PATCH v5 0/6] drm/i915: Asynchronous vma unbinding
by Thomas Hellström 06 Jan '22

06 Jan '22

This patch series introduces infrastructure for asynchronous vma unbinding. The single enabled use-case is initially at buffer object migration where we otherwise sync when unbinding vmas before migration. This in theory allows us to pipeline any number of migrations, but in practice the number is restricted by a sync wait when filling the migration context ring. We might want to look at that moving forward if needed. The other main use-case is to be able to pipeline vma evictions, for example with softpinning where a new vma wants to reuse the vm range of an already active vma. We can't support this just yet because we need dma_resv locking around vma eviction for that, which is under implementation. Patch 1 introduces vma resource first for error capture purposes Patch 2 changes the vm backend interface to take vma resources rather than vmas Patch 3 removes and unneeded page pinning Patch 4 introduces the async unbinding itself, and finally Patch 5 introduces a selftest Patch 6 realizes we have duplicated functionality and removes the vma snapshots v2: -- Some kernel test robot reports addressed. -- kmem cache for vma resources, See patch 4 -- Various fixes all over the place. See separate commit messages. v3: -- Re-add a missing i915_vma_resource_put() -- Remove a stray debug printout v4: -- Patch series split in two. This is the second part. -- Take cache coloring into account when searching for vma_resources pending unbind. (Matthew Auld) v5: -- Add a selftest. -- Remove page pinning while sync binding. -- A couple of fixes in i915_vma_resource_bind_dep_await() Thomas Hellström (6): drm/i915: Initial introduction of vma resources drm/i915: Use the vma resource as argument for gtt binding / unbinding drm/i915: Don't pin the object pages during pending vma binds drm/i915: Use vma resources for async unbinding drm/i915: Asynchronous migration selftest drm/i915: Use struct vma_resource instead of struct vma_snapshot drivers/gpu/drm/i915/Makefile | 2 +- drivers/gpu/drm/i915/display/intel_dpt.c | 27 +- .../gpu/drm/i915/gem/i915_gem_execbuffer.c | 17 +- drivers/gpu/drm/i915/gem/i915_gem_object.c | 12 + drivers/gpu/drm/i915/gem/i915_gem_object.h | 3 + .../gpu/drm/i915/gem/i915_gem_object_types.h | 27 +- drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c | 11 +- .../gpu/drm/i915/gem/selftests/huge_pages.c | 37 +- .../drm/i915/gem/selftests/i915_gem_migrate.c | 192 +++++++- drivers/gpu/drm/i915/gt/gen6_ppgtt.c | 19 +- drivers/gpu/drm/i915/gt/gen8_ppgtt.c | 37 +- drivers/gpu/drm/i915/gt/intel_engine_cs.c | 9 +- drivers/gpu/drm/i915/gt/intel_ggtt.c | 72 +-- drivers/gpu/drm/i915/gt/intel_gtt.c | 4 + drivers/gpu/drm/i915/gt/intel_gtt.h | 19 +- drivers/gpu/drm/i915/gt/intel_ppgtt.c | 22 +- drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c | 13 +- drivers/gpu/drm/i915/gt/uc/intel_uc_fw.h | 2 +- drivers/gpu/drm/i915/i915_debugfs.c | 3 +- drivers/gpu/drm/i915/i915_drv.h | 1 + drivers/gpu/drm/i915/i915_gem.c | 12 +- drivers/gpu/drm/i915/i915_gpu_error.c | 87 ++-- drivers/gpu/drm/i915/i915_module.c | 3 + drivers/gpu/drm/i915/i915_request.c | 12 +- drivers/gpu/drm/i915/i915_request.h | 6 +- drivers/gpu/drm/i915/i915_vma.c | 240 +++++++++- drivers/gpu/drm/i915/i915_vma.h | 33 +- drivers/gpu/drm/i915/i915_vma_resource.c | 417 ++++++++++++++++++ drivers/gpu/drm/i915/i915_vma_resource.h | 235 ++++++++++ drivers/gpu/drm/i915/i915_vma_snapshot.c | 134 ------ drivers/gpu/drm/i915/i915_vma_snapshot.h | 112 ----- drivers/gpu/drm/i915/i915_vma_types.h | 5 + drivers/gpu/drm/i915/selftests/i915_gem_gtt.c | 159 ++++--- drivers/gpu/drm/i915/selftests/mock_gtt.c | 12 +- 34 files changed, 1415 insertions(+), 581 deletions(-) create mode 100644 drivers/gpu/drm/i915/i915_vma_resource.c create mode 100644 drivers/gpu/drm/i915/i915_vma_resource.h delete mode 100644 drivers/gpu/drm/i915/i915_vma_snapshot.c delete mode 100644 drivers/gpu/drm/i915/i915_vma_snapshot.h -- 2.31.1

2 12

[Bug 215001] Regression in 5.15, Firmware-initialized graphics console selects FB_VGA16, screen corruption
by bugzilla-daemon＠bugzilla.kernel.org 06 Jan '22

06 Jan '22

https://bugzilla.kernel.org/show_bug.cgi?id=215001 The Linux kernel's regression tracker (Thorsten Leemhuis) (regressions(a)leemhuis.info) changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |regressions(a)leemhuis.info --- Comment #4 from The Linux kernel's regression tracker (Thorsten Leemhuis) (regressions(a)leemhuis.info) --- (In reply to Kris Karas from comment #3) > I just bisected this bug. "First bad commit" is > d391c58271072d0b0fad93c82018d495b2633448 Just to be sure: did you recheck if the issue still occurs with 5.16-rc or the latest 5.15.y release? There was another regression caused by this commit fixed a few weeks ago: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -- You may reply to this email to add a comment. You are receiving this mail because: You are on the CC list for the bug.

1 0

[PATCH] phy: mediatek: Fix missing check in mtk_mipi_tx_probe
by Miaoqian Lin 06 Jan '22

06 Jan '22

The of_device_get_match_data() function may return NULL. Add check to prevent potential null dereference. Signed-off-by: Miaoqian Lin <linmq006(a)gmail.com> --- drivers/phy/mediatek/phy-mtk-mipi-dsi.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/phy/mediatek/phy-mtk-mipi-dsi.c b/drivers/phy/mediatek/phy-mtk-mipi-dsi.c index 28ad9403c441..67b005d5b9e3 100644 --- a/drivers/phy/mediatek/phy-mtk-mipi-dsi.c +++ b/drivers/phy/mediatek/phy-mtk-mipi-dsi.c @@ -146,6 +146,8 @@ static int mtk_mipi_tx_probe(struct platform_device *pdev) return -ENOMEM; mipi_tx->driver_data = of_device_get_match_data(dev); + if (!mipi_tx->driver_data) + return -ENODEV; mipi_tx->regs = devm_platform_ioremap_resource(pdev, 0); if (IS_ERR(mipi_tx->regs)) -- 2.17.1

4 4

← Newer
1
...
73
74
75
76
77
78
79
...
85
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

dri-devel January 2022