dri-devel August 2021

dri-devel@lists.freedesktop.org

324 participants
762 discussions

RE: [PATCH] drm/sched: fix the bug of time out calculation(v2)
by Liu, Monk 26 Aug '21

26 Aug '21

[AMD Official Use Only] >> All we need to take care of is to cancel_delayed_work() when we know that the job is completed. That's why I want to remove the cancel_delayed_work in the beginning of cleanup_job(), because in that moment we don't know if There is a job completed (sched could be wake up due to new submit, instead of a job signaled) , until we get the job and acknowledged of its signaling. static struct drm_sched_job * drm_sched_get_cleanup_job(struct drm_gpu_scheduler *sched) { struct drm_sched_job *job, *next; /* * Don't destroy jobs while the timeout worker is running OR thread * is being parked and hence assumed to not touch pending_list */ if ((sched->timeout != MAX_SCHEDULE_TIMEOUT && !cancel_delayed_work(&sched->work_tdr)) || //normally if the job is not TO, then he cancel here is incorrect if the job is still running , kthread_should_park()) return NULL; spin_lock(&sched->job_list_lock); job = list_first_entry_or_null(&sched->pending_list, struct drm_sched_job, list); if (job && dma_fence_is_signaled(&job->s_fence->finished)) { /* remove job from pending_list */ list_del_init(&job->list); /* make the scheduled timestamp more accurate */ next = list_first_entry_or_null(&sched->pending_list, typeof(*next), list); if (next) next->s_fence->scheduled.timestamp = job->s_fence->finished.timestamp; } else { job = NULL; /* queue timeout for next job */ drm_sched_start_timeout(sched); //if the job is not signaled, the timer will be retriggered here (counting is restarted ....) , which is wrong .... } spin_unlock(&sched->job_list_lock); return job; } >> This here works as intended as far as I can see and if you start to use mod_delayed_work() you actually break it. Only in the place we find heading job is signaled and there is a next job is the moment that we should cancel the work_tdr for this scheduler , of cause with A new work_tdr queued as the "next" job is already started on HW... that's why I use mod_delayed_work. But I can change it to "cancel and queue" approach if you have concern. Thanks ------------------------------------------ Monk Liu | Cloud-GPU Core team ------------------------------------------ -----Original Message----- From: Christian König <ckoenig.leichtzumerken(a)gmail.com> Sent: Wednesday, August 25, 2021 8:11 PM To: Liu, Monk <Monk.Liu(a)amd.com>; amd-gfx(a)lists.freedesktop.org Subject: Re: [PATCH] drm/sched: fix the bug of time out calculation(v2) No, this would break that logic here. See drm_sched_start_timeout() can be called multiple times, this is intentional and very important! The logic in queue_delayed_work() makes sure that the timer is only started once and then never again. All we need to take care of is to cancel_delayed_work() when we know that the job is completed. This here works as intended as far as I can see and if you start to use mod_delayed_work() you actually break it. Regards, Christian. Am 25.08.21 um 14:01 schrieb Liu, Monk: > [AMD Official Use Only] > > I think we should remove the cancel_delayed_work() in the beginning of the cleanup_job(). > > Because by my patch the "mode_delayed_work" in cleanup_job is already > doing its duty to retrigger the TO timer accordingly > > Thanks > > ------------------------------------------ > Monk Liu | Cloud-GPU Core team > ------------------------------------------ > > -----Original Message----- > From: Liu, Monk > Sent: Wednesday, August 25, 2021 7:55 PM > To: 'Christian König' <ckoenig.leichtzumerken(a)gmail.com>; > amd-gfx(a)lists.freedesktop.org > Subject: RE: [PATCH] drm/sched: fix the bug of time out > calculation(v2) > > [AMD Official Use Only] > >>> The timeout started by queue_delayed_work() in drm_sched_start_timeout() is paired with the cancel_delayed_work() in drm_sched_get_cleanup_job(). > No that's wrong, see that when we are in cleanup_job(), assume we do not have timeout on this sched (we are just keep submitting new jobs to this sched), Then the work_tdr is cancelled, and then we get the heading job, and let's assume the job is not signaled, then we run to the "queue timeout for next job" thus drm_sched_start_timeout() is called, so this heading job's TO timer is actually retriggered ... which is totally wrong. > > With my patch the timer is already retriggered after previous JOB really signaled. > > Can you be more specific on the incorrect part ? > > Thanks > ------------------------------------------ > Monk Liu | Cloud-GPU Core team > ------------------------------------------ > > -----Original Message----- > From: Christian König <ckoenig.leichtzumerken(a)gmail.com> > Sent: Wednesday, August 25, 2021 2:32 PM > To: Liu, Monk <Monk.Liu(a)amd.com>; amd-gfx(a)lists.freedesktop.org > Subject: Re: [PATCH] drm/sched: fix the bug of time out > calculation(v2) > > Well NAK to that approach. First of all your bug analyses is incorrect. > > The timeout started by queue_delayed_work() in drm_sched_start_timeout() is paired with the cancel_delayed_work() in drm_sched_get_cleanup_job(). > > So you must have something else going on here. > > Then please don't use mod_delayed_work(), instead always cancel it and restart it. > > Regards, > Christian. > > Am 25.08.21 um 06:14 schrieb Monk Liu: >> the original logic is wrong that the timeout will not be retriggerd >> after the previous job siganled, and that lead to the scenario that >> all jobs in the same scheduler shares the same timeout timer from the >> very begining job in this scheduler which is wrong. >> >> we should modify the timer everytime a previous job signaled. >> >> v2: >> further cleanup the logic, and do the TDR timer cancelling if the >> signaled job is the last one in its scheduler. >> >> Signed-off-by: Monk Liu <Monk.Liu(a)amd.com> >> --- >> drivers/gpu/drm/scheduler/sched_main.c | 29 ++++++++++++++++++++--------- >> 1 file changed, 20 insertions(+), 9 deletions(-) >> >> diff --git a/drivers/gpu/drm/scheduler/sched_main.c >> b/drivers/gpu/drm/scheduler/sched_main.c >> index a2a9536..8c102ac 100644 >> --- a/drivers/gpu/drm/scheduler/sched_main.c >> +++ b/drivers/gpu/drm/scheduler/sched_main.c >> @@ -305,8 +305,17 @@ static void drm_sched_job_begin(struct drm_sched_job *s_job) >> struct drm_gpu_scheduler *sched = s_job->sched; >> >> spin_lock(&sched->job_list_lock); >> - list_add_tail(&s_job->list, &sched->pending_list); >> - drm_sched_start_timeout(sched); >> + if (list_empty(&sched->pending_list)) { >> + list_add_tail(&s_job->list, &sched->pending_list); >> + drm_sched_start_timeout(sched); >> + } else { >> + /* the old jobs in pending list are not finished yet >> + * no need to restart TDR timer here, it is already >> + * handled by drm_sched_get_cleanup_job >> + */ >> + list_add_tail(&s_job->list, &sched->pending_list); >> + } >> + >> spin_unlock(&sched->job_list_lock); >> } >> >> @@ -693,17 +702,22 @@ drm_sched_get_cleanup_job(struct drm_gpu_scheduler *sched) >> if (job && dma_fence_is_signaled(&job->s_fence->finished)) { >> /* remove job from pending_list */ >> list_del_init(&job->list); >> + >> /* make the scheduled timestamp more accurate */ >> next = list_first_entry_or_null(&sched->pending_list, >> typeof(*next), list); >> - if (next) >> + if (next) { >> + /* if we still have job in pending list we need modify the TDR timer */ >> + mod_delayed_work(system_wq, &sched->work_tdr, sched->timeout); >> next->s_fence->scheduled.timestamp = >> job->s_fence->finished.timestamp; >> + } else { >> + /* cancel the TDR timer if no job in pending list */ >> + cancel_delayed_work(&sched->work_tdr); >> + } >> >> } else { >> job = NULL; >> - /* queue timeout for next job */ >> - drm_sched_start_timeout(sched); >> } >> >> spin_unlock(&sched->job_list_lock); >> @@ -791,11 +805,8 @@ static int drm_sched_main(void *param) >> (entity = drm_sched_select_entity(sched))) || >> kthread_should_stop()); >> >> - if (cleanup_job) { >> + if (cleanup_job) >> sched->ops->free_job(cleanup_job); >> - /* queue timeout for next job */ >> - drm_sched_start_timeout(sched); >> - } >> >> if (!entity) >> continue;

1 0

[PATCH v2 0/5] drm/msm/dp: Allow variation in register regions
by Bjorn Andersson 26 Aug '21

26 Aug '21

It turns out that sc8180x (among others) doesn't have the same internal layout of the 4 subblocks. This series therefor modifies the binding to require all four regions to be described individually and then extends the driver to read these four regions. The driver will fall back to read the old single-reg format and apply the original offsets and sizes. Bjorn Andersson (5): dt-bindings: msm/dp: Change reg definition drm/msm/dp: Use devres for ioremap() drm/msm/dp: Refactor ioremap wrapper drm/msm/dp: Store each subblock in the io region drm/msm/dp: Allow sub-regions to be specified in DT .../bindings/display/msm/dp-controller.yaml | 13 ++- drivers/gpu/drm/msm/dp/dp_catalog.c | 64 ++++------- drivers/gpu/drm/msm/dp/dp_parser.c | 102 ++++++++++-------- drivers/gpu/drm/msm/dp/dp_parser.h | 11 +- 4 files changed, 100 insertions(+), 90 deletions(-) -- 2.29.2

2 7

[PATCH] drm/cma-helper: Set VM_DONTEXPAND for mmap
by Robin Murphy 26 Aug '21

26 Aug '21

drm_gem_cma_mmap() cannot assume every implementation of dma_mmap_wc() will end up calling remap_pfn_range() (which happens to set the relevant vma flag, among others), so in order to make sure expectations around VM_DONTEXPAND are met, let it explicitly set the flag like most other GEM mmap implementations do. This avoids repeated warnings on a small minority of systems where the display is behind an IOMMU, and has a simple driver which does not override drm_gem_cma_default_funcs. Signed-off-by: Robin Murphy <robin.murphy(a)arm.com> --- drivers/gpu/drm/drm_gem_cma_helper.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpu/drm/drm_gem_cma_helper.c b/drivers/gpu/drm/drm_gem_cma_helper.c index d53388199f34..63e48d98263d 100644 --- a/drivers/gpu/drm/drm_gem_cma_helper.c +++ b/drivers/gpu/drm/drm_gem_cma_helper.c @@ -510,6 +510,7 @@ int drm_gem_cma_mmap(struct drm_gem_object *obj, struct vm_area_struct *vma) */ vma->vm_pgoff -= drm_vma_node_start(&obj->vma_node); vma->vm_flags &= ~VM_PFNMAP; + vma->vm_flags |= VM_DONTEXPAND; cma_obj = to_drm_gem_cma_obj(obj); -- 2.25.1

2 1

[PATCH 00/27] Clean up GuC CI failures, simplify locking, and kernel DOC
by Matthew Brost 26 Aug '21

26 Aug '21

Daniel Vetter pointed out that locking in the GuC submission code was overly complicated, let's clean this up a bit before introducing more features in the GuC submission backend. Also fix some CI failures, port fixes from our internal tree, and add a few more selftests for coverage. Lastly, add some kernel DOC explaining how the GuC submission backend works. v2: Fix logic error in 'Workaround reset G2H is received after schedule done G2H', don't propagate errors to dependent fences in execlists submissiom, resolve checkpatch issues, resend to correct lists v3: Fix issue kicking tasklet, drop guc_active, fix ref counting in xarray, add guc_id sub structure, drop inline fuctions, and various other cleanup suggested by Daniel Signed-off-by: Matthew Brost <matthew.brost(a)intel.com> Matthew Brost (27): drm/i915/guc: Fix blocked context accounting drm/i915/guc: Fix outstanding G2H accounting drm/i915/guc: Unwind context requests in reverse order drm/i915/guc: Don't drop ce->guc_active.lock when unwinding context drm/i915/guc: Process all G2H message at once in work queue drm/i915/guc: Workaround reset G2H is received after schedule done G2H Revert "drm/i915/gt: Propagate change in error status to children on unhold" drm/i915/selftests: Add a cancel request selftest that triggers a reset drm/i915/guc: Kick tasklet after queuing a request drm/i915/guc: Don't enable scheduling on a banned context, guc_id invalid, not registered drm/i915/selftests: Fix memory corruption in live_lrc_isolation drm/i915/selftests: Add initial GuC selftest for scrubbing lost G2H drm/i915/guc: Take context ref when cancelling request drm/i915/guc: Don't touch guc_state.sched_state without a lock drm/i915/guc: Reset LRC descriptor if register returns -ENODEV drm/i915: Allocate error capture in nowait context drm/i915/guc: Flush G2H work queue during reset drm/i915/guc: Release submit fence from an irq_work drm/i915/guc: Move guc_blocked fence to struct guc_state drm/i915/guc: Rework and simplify locking drm/i915/guc: Proper xarray usage for contexts_lookup drm/i915/guc: Drop pin count check trick between sched_disable and re-pin drm/i915/guc: Move GuC priority fields in context under guc_active drm/i915/guc: Move fields protected by guc->contexts_lock into sub structure drm/i915/guc: Drop guc_active move everything into guc_state drm/i915/guc: Add GuC kernel doc drm/i915/guc: Drop static inline functions intel_guc_submission.c drivers/gpu/drm/i915/gt/intel_context.c | 19 +- drivers/gpu/drm/i915/gt/intel_context_types.h | 81 +- .../drm/i915/gt/intel_execlists_submission.c | 4 - drivers/gpu/drm/i915/gt/selftest_hangcheck.c | 6 +- drivers/gpu/drm/i915/gt/selftest_lrc.c | 29 +- drivers/gpu/drm/i915/gt/uc/intel_guc.h | 19 +- drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c | 6 +- .../gpu/drm/i915/gt/uc/intel_guc_submission.c | 955 +++++++++++------- drivers/gpu/drm/i915/gt/uc/selftest_guc.c | 126 +++ drivers/gpu/drm/i915/i915_gpu_error.c | 39 +- drivers/gpu/drm/i915/i915_request.h | 23 +- drivers/gpu/drm/i915/i915_trace.h | 12 +- .../drm/i915/selftests/i915_live_selftests.h | 1 + drivers/gpu/drm/i915/selftests/i915_request.c | 100 ++ .../i915/selftests/intel_scheduler_helpers.c | 12 + .../i915/selftests/intel_scheduler_helpers.h | 2 + 16 files changed, 968 insertions(+), 466 deletions(-) create mode 100644 drivers/gpu/drm/i915/gt/uc/selftest_guc.c -- 2.32.0

3 70

[PATCH v3 0/7] Add support to the mmsys driver to be a reset controller
by Enric Balletbo i Serra 26 Aug '21

26 Aug '21

Dear all, The following patchset is a reimplementation of the patch sent by Jitao Shi [1] some time ago. As suggested by Chun-Kuang Hu, this time the reset is done using the reset API, where the mmsys driver is the reset controller and the mtk_dsi driver is the reset consumer. Note that the first patch is kind of unrelated change, it's just a cleanup but is needed if you want to apply all the following patches cleanly. This patchset is important in order to have the DSI panel working on some kukui MT8183 Chromebooks (i.e Lenovo IdeaPad Duet). Without it, you just get a black screen. Best regards, Enric [1] https://lore.kernel.org/linux-arm-kernel/20210420132614.150242-4-jitao.shi@… Changes in v3: - Based on top of the patch that converts mmsys to schema - Fix typo in the commit description Changes in v2: - Fix build test ERROR Reported-by: kernel test robot <lkp(a)intel.com> - Added a new patch to describe the dsi reset optional property. Enric Balletbo i Serra (7): arm64: dts: mediatek: Move reset controller constants into common location dt-bindings: mediatek: Add #reset-cells to mmsys system controller dt-bindings: display: mediatek: add dsi reset optional property arm64: dts: mt8173: Add the mmsys reset bit to reset the dsi0 arm64: dts: mt8183: Add the mmsys reset bit to reset the dsi0 soc: mediatek: mmsys: Add reset controller support drm/mediatek: mtk_dsi: Reset the dsi0 hardware .../bindings/arm/mediatek/mediatek,mmsys.yaml | 4 ++ .../display/mediatek/mediatek,dsi.txt | 6 ++ arch/arm64/boot/dts/mediatek/mt8173.dtsi | 2 + arch/arm64/boot/dts/mediatek/mt8183.dtsi | 5 +- drivers/gpu/drm/mediatek/mtk_dsi.c | 5 +- drivers/soc/mediatek/mtk-mmsys.c | 69 +++++++++++++++++++ drivers/soc/mediatek/mtk-mmsys.h | 2 + drivers/watchdog/mtk_wdt.c | 6 +- .../mt2712-resets.h | 0 include/dt-bindings/reset/mt8173-resets.h | 2 + .../mt8183-resets.h | 3 + .../mt8192-resets.h | 0 12 files changed, 98 insertions(+), 6 deletions(-) rename include/dt-bindings/{reset-controller => reset}/mt2712-resets.h (100%) rename include/dt-bindings/{reset-controller => reset}/mt8183-resets.h (98%) rename include/dt-bindings/{reset-controller => reset}/mt8192-resets.h (100%) -- 2.30.2

2 3

[PATCH] drm/i915: Clean up disabled warnings
by Nathan Chancellor 25 Aug '21

25 Aug '21

i915 enables a wider set of warnings with '-Wall -Wextra' then disables several with cc-disable-warning. If an unknown flag gets added to KBUILD_CFLAGS when building with clang, all subsequent calls to cc-{disable-warning,option} will fail, meaning that all of these warnings do not get disabled [1]. A separate series will address the root cause of the issue by not adding these flags when building with clang [2]; however, the symptom of these extra warnings appearing can be addressed separately by just removing the calls to cc-disable-warning, which makes the build ever so slightly faster because the compiler does not need to be called as much before building. The following warnings are supported by GCC 4.9 and clang 10.0.1, which are the minimum supported versions of these compilers so the call to cc-disable-warning is not necessary. Masahiro cleaned this up for the reset of the kernel in commit 4c8dd95a723d ("kbuild: add some extra warning flags unconditionally"). * -Wmissing-field-initializers * -Wsign-compare * -Wtype-limits * -Wunused-parameter -Wunused-but-set-variable was implemented in clang 13.0.0 and -Wframe-address was implemented in clang 12.0.0 so the cc-disable-warning calls are kept for these two warnings. Lastly, -Winitializer-overrides is clang's version of -Woverride-init, which is disabled for the specific files that are problematic. clang added a compatibility alias in clang 8.0.0 so -Winitializer-overrides can be removed. [1]: https://lore.kernel.org/r/202108210311.CBtcgoUL-lkp@intel.com/ [2]: https://lore.kernel.org/r/20210824022640.2170859-1-nathan@kernel.org/ Signed-off-by: Nathan Chancellor <nathan(a)kernel.org> --- NOTE: This is based on my series to enable -Wsometimes-initialized here: https://lore.kernel.org/r/20210824225427.2065517-1-nathan@kernel.org/ I sent it separately as this can go into whatever release but I would like for that series to go into 5.15. drivers/gpu/drm/i915/Makefile | 10 ++++------ 1 file changed, 4 insertions(+), 6 deletions(-) diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile index 335ba9f43d8f..6b38547543b1 100644 --- a/drivers/gpu/drm/i915/Makefile +++ b/drivers/gpu/drm/i915/Makefile @@ -13,13 +13,11 @@ # will most likely get a sudden build breakage... Hopefully we will fix # new warnings before CI updates! subdir-ccflags-y := -Wall -Wextra -subdir-ccflags-y += $(call cc-disable-warning, unused-parameter) -subdir-ccflags-y += $(call cc-disable-warning, type-limits) -subdir-ccflags-y += $(call cc-disable-warning, missing-field-initializers) +subdir-ccflags-y += -Wno-unused-parameter +subdir-ccflags-y += -Wno-type-limits +subdir-ccflags-y += -Wno-missing-field-initializers +subdir-ccflags-y += -Wno-sign-compare subdir-ccflags-y += $(call cc-disable-warning, unused-but-set-variable) -# clang warnings -subdir-ccflags-y += $(call cc-disable-warning, sign-compare) -subdir-ccflags-y += $(call cc-disable-warning, initializer-overrides) subdir-ccflags-y += $(call cc-disable-warning, frame-address) subdir-ccflags-$(CONFIG_DRM_I915_WERROR) += -Werror base-commit: fb43ebc83e069625cfeeb2490efc3ffa0013bfa4 prerequisite-patch-id: 31c28450ed7e8785dce967a16db6d52eff3d7d6d prerequisite-patch-id: 372dfa0e07249f207acc1942ab0e39b13ff229b2 prerequisite-patch-id: 1a585fa6cda50c32ad1e3ac8235d3cff1b599978 -- 2.33.0

2 2

[RFC][PATCH] dma-buf: system_heap: Avoid warning on mid-order allocations
by John Stultz 25 Aug '21

25 Aug '21

When trying to do mid-order allocations, set __GFP_NOWARN to avoid warning messages if the allocation fails, as we will still fall back to single page allocatitions in that case. This is the similar to what we already do for large order allocations. Cc: Daniel Vetter <daniel(a)ffwll.ch> Cc: Christian Koenig <christian.koenig(a)amd.com> Cc: Sumit Semwal <sumit.semwal(a)linaro.org> Cc: Liam Mark <lmark(a)codeaurora.org> Cc: Chris Goldsworthy <cgoldswo(a)codeaurora.org> Cc: Laura Abbott <labbott(a)kernel.org> Cc: Brian Starkey <Brian.Starkey(a)arm.com> Cc: Hridya Valsaraju <hridya(a)google.com> Cc: Suren Baghdasaryan <surenb(a)google.com> Cc: Sandeep Patil <sspatil(a)google.com> Cc: Daniel Mentz <danielmentz(a)google.com> Cc: Ørjan Eide <orjan.eide(a)arm.com> Cc: Robin Murphy <robin.murphy(a)arm.com> Cc: Ezequiel Garcia <ezequiel(a)collabora.com> Cc: Simon Ser <contact(a)emersion.fr> Cc: James Jones <jajones(a)nvidia.com> Cc: Leo Yan <leo.yan(a)linaro.org> Cc: linux-media(a)vger.kernel.org Cc: dri-devel(a)lists.freedesktop.org Signed-off-by: John Stultz <john.stultz(a)linaro.org> --- drivers/dma-buf/heaps/system_heap.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/drivers/dma-buf/heaps/system_heap.c b/drivers/dma-buf/heaps/system_heap.c index 23a7e74ef966..f57a39ddd063 100644 --- a/drivers/dma-buf/heaps/system_heap.c +++ b/drivers/dma-buf/heaps/system_heap.c @@ -40,11 +40,12 @@ struct dma_heap_attachment { bool mapped; }; +#define LOW_ORDER_GFP (GFP_HIGHUSER | __GFP_ZERO | __GFP_COMP) +#define MID_ORDER_GFP (LOW_ORDER_GFP | __GFP_NOWARN) #define HIGH_ORDER_GFP (((GFP_HIGHUSER | __GFP_ZERO | __GFP_NOWARN \ | __GFP_NORETRY) & ~__GFP_RECLAIM) \ | __GFP_COMP) -#define LOW_ORDER_GFP (GFP_HIGHUSER | __GFP_ZERO | __GFP_COMP) -static gfp_t order_flags[] = {HIGH_ORDER_GFP, LOW_ORDER_GFP, LOW_ORDER_GFP}; +static gfp_t order_flags[] = {HIGH_ORDER_GFP, MID_ORDER_GFP, LOW_ORDER_GFP}; /* * The selection of the orders used for allocation (1MB, 64K, 4K) is designed * to match with the sizes often found in IOMMUs. Using order 4 pages instead -- 2.25.1

1 0

[PATCH][next] drm/amd/display: fix spelling mistake "alidation" -> "validation"
by Colin King 25 Aug '21

25 Aug '21

From: Colin Ian King <colin.king(a)canonical.com> There is a spelling mistake in a DC_LOG_WARNING message. Fix it. Signed-off-by: Colin Ian King <colin.king(a)canonical.com> --- drivers/gpu/drm/amd/display/dc/dcn31/dcn31_resource.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/amd/display/dc/dcn31/dcn31_resource.c b/drivers/gpu/drm/amd/display/dc/dcn31/dcn31_resource.c index 3223a1ff2292..91cbc0922ad4 100644 --- a/drivers/gpu/drm/amd/display/dc/dcn31/dcn31_resource.c +++ b/drivers/gpu/drm/amd/display/dc/dcn31/dcn31_resource.c @@ -1999,7 +1999,7 @@ bool dcn31_validate_bandwidth(struct dc *dc, goto validate_out; validate_fail: - DC_LOG_WARNING("Mode Validation Warning: %s failed alidation.\n", + DC_LOG_WARNING("Mode Validation Warning: %s failed validation.\n", dml_get_status_message(context->bw_ctx.dml.vba.ValidationStatus[context->bw_ctx.dml.vba.soc.num_states])); BW_VAL_TRACE_SKIP(fail); -- 2.32.0

3 2

[PATCH v2 0/4] drm/panfrost: Bug fixes for lock_region
by Alyssa Rosenzweig 25 Aug '21

25 Aug '21

Chris Morgan reported UBSAN errors in panfrost and tracked them down to the size computation in lock_region. This calculation is overcomplicated (cargo culted from kbase) and can be simplified with kernel helpers and some mathematical identities. The first patch in the series rewrites the calculation in a form avoiding undefined behaviour; Chris confirms it placates UBSAN. While researching this function, I noticed a pair of other potential bugs: Bifrost can lock more than 4GiB at a time, but must lock at least 32KiB at a time. The latter patches in the series handle these cases. In review of v1 of this series, Steven pointed out a fourth potential bug: rounding down the iova can truncate the lock region. v2 adds a new patch for this case. The size computation was unit-tested in userspace. Relevant code below, just missing some copypaste definitions for fls64/clamp/etc: #define MIN_LOCK (1ULL << 12) #define MAX_LOCK (1ULL << 48) struct { uint64_t size; uint8_t encoded; } tests[] = { /* Clamping */ { 0, 11 }, { 1, 11 }, { 2, 11 }, { 4095, 11 }, /* Power of two */ { 4096, 11 }, /* Round up */ { 4097, 12 }, { 8192, 12 }, { 16384, 13 }, { 16385, 14 }, /* Maximum */ { ~0ULL, 47 }, }; static uint8_t region_width(uint64_t size) { size = clamp(size, MIN_LOCK, MAX_LOCK); return fls64(size - 1) - 1; } int main(int argc, char **argv) { for (unsigned i = 0; i < ARRAY_SIZE(tests); ++i) { uint64_t test = tests[i].size; uint8_t expected = tests[i].encoded; uint8_t actual = region_width(test); assert(expected == actual); } } Changes in v2: * New patch for non-aligned lock addresses * Commit message improvements. * Add Steven's tags. Alyssa Rosenzweig (4): drm/panfrost: Simplify lock_region calculation drm/panfrost: Use u64 for size in lock_region drm/panfrost: Clamp lock region to Bifrost minimum drm/panfrost: Handle non-aligned lock addresses drivers/gpu/drm/panfrost/panfrost_mmu.c | 32 ++++++++++-------------- drivers/gpu/drm/panfrost/panfrost_regs.h | 2 ++ 2 files changed, 15 insertions(+), 19 deletions(-) -- 2.30.2

4 10

[PATCH v2 01/11] drm/i915: Check for nomodeset in i915_init() first
by Daniel Vetter 25 Aug '21

25 Aug '21

When modesetting (aka the full pci driver, which has nothing to do with disable_display option, which just gives you the full pci driver without the display driver) is disabled, we load nothing and do nothing. So move that check first, for a bit of orderliness. With Jason's module init/exit table this now becomes trivial. Reviewed-by: Jason Ekstrand <jason(a)jlekstrand.net> Cc: Jason Ekstrand <jason(a)jlekstrand.net> Signed-off-by: Daniel Vetter <daniel.vetter(a)intel.com> --- drivers/gpu/drm/i915/i915_pci.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c index f28206484552..eb520fcb32e4 100644 --- a/drivers/gpu/drm/i915/i915_pci.c +++ b/drivers/gpu/drm/i915/i915_pci.c @@ -1293,9 +1293,9 @@ static const struct { int (*init)(void); void (*exit)(void); } init_funcs[] = { + { i915_check_nomodeset, NULL }, { i915_globals_init, i915_globals_exit }, { i915_mock_selftests, NULL }, - { i915_check_nomodeset, NULL }, { i915_pmu_init, i915_pmu_exit }, { i915_register_pci_driver, i915_unregister_pci_driver }, { i915_perf_sysctl_register, i915_perf_sysctl_unregister }, -- 2.32.0

5 15

← Newer
1
...
30
31
32
33
34
35
36
...
77
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

dri-devel August 2021