dri-devel August 2021

dri-devel@lists.freedesktop.org

324 participants
762 discussions

[GIT PULL] mediatek drm next for 5.15
by Chun-Kuang Hu 16 Aug '21

16 Aug '21

Hi, Dave & Daniel: This includes: 1. MT8133 AAL support, adjust rdma fifo threshold formula. 2. Implement mmap as GEM object function. 3. Add support for MT8167. 4. Test component initialization earlier in the function mtk_drm_crtc_create. 5. CMDQ refinement. Regards, Chun-Kuang. The following changes since commit e73f0f0ee7541171d89f2e2491130c7771ba58d3: Linux 5.14-rc1 (2021-07-11 15:07:40 -0700) are available in the Git repository at: https://git.kernel.org/pub/scm/linux/kernel/git/chunkuang.hu/linux.git tags/mediatek-drm-next-5.15 for you to fetch changes up to 6e7dcd92644baebdb137e3af900064ceebcaca23: drm/mediatek: Clear pending flag when cmdq packet is done (2021-08-12 08:16:24 +0800) ---------------------------------------------------------------- Mediatek DRM Next for Linux 5.15 1. MT8133 AAL support, adjust rdma fifo threshold formula. 2. Implement mmap as GEM object function. 3. Add support for MT8167. 4. Test component initialization earlier in the function mtk_drm_crtc_create. 5. CMDQ refinement. ---------------------------------------------------------------- Chun-Kuang Hu (4): drm/mediatek: Use mailbox rx_callback instead of cmdq_task_cb drm/mediatek: Remove struct cmdq_client drm/mediatek: Detect CMDQ execution timeout drm/mediatek: Add cmdq_handle in mtk_crtc Dafna Hirschfeld (1): drm/mediatek: Test component initialization earlier in the function mtk_drm_crtc_create Fabien Parent (2): dt-bindings: display: mediatek: dsi: add documentation for MT8167 SoC drm/mediatek: Add support for main DDP path on MT8167 Thomas Zimmermann (1): drm/mediatek: Implement mmap as GEM object function Yongqiang Niu (4): drm/mediatek: Adjust rdma fifo threshold calculate formula drm/mediatek: Separate aal sub driver drm/mediatek: Add mt8183 aal support drm/mediatek: Clear pending flag when cmdq packet is done .../bindings/display/mediatek/mediatek,dsi.txt | 2 +- drivers/gpu/drm/mediatek/Makefile | 3 +- drivers/gpu/drm/mediatek/mtk_disp_aal.c | 167 ++++++++++++++++++++ drivers/gpu/drm/mediatek/mtk_disp_drv.h | 9 ++ drivers/gpu/drm/mediatek/mtk_disp_rdma.c | 6 +- drivers/gpu/drm/mediatek/mtk_drm_crtc.c | 173 +++++++++++++++++---- drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c | 42 +---- drivers/gpu/drm/mediatek/mtk_drm_drv.c | 59 +++++-- drivers/gpu/drm/mediatek/mtk_drm_drv.h | 1 + drivers/gpu/drm/mediatek/mtk_drm_gem.c | 44 ++---- drivers/gpu/drm/mediatek/mtk_drm_gem.h | 3 - 11 files changed, 386 insertions(+), 123 deletions(-) create mode 100644 drivers/gpu/drm/mediatek/mtk_disp_aal.c

2 2

[GIT PULL v2] mediatek drm next for 5.15
by Chun-Kuang Hu 16 Aug '21

16 Aug '21

Hi, Dave & Daniel: This includes: 1. MT8133 AAL support, adjust rdma fifo threshold formula. 2. Implement mmap as GEM object function. 3. Add support for MT8167. 4. Test component initialization earlier in the function mtk_drm_crtc_create. 5. CMDQ refinement. Regards, Chun-Kuang. The following changes since commit e73f0f0ee7541171d89f2e2491130c7771ba58d3: Linux 5.14-rc1 (2021-07-11 15:07:40 -0700) are available in the Git repository at: https://git.kernel.org/pub/scm/linux/kernel/git/chunkuang.hu/linux.git tags/mediatek-drm-next-5.15 for you to fetch changes up to 9efb16c2fdd647d3888fd8dae84509f485cd554e: drm/mediatek: Clear pending flag when cmdq packet is done (2021-08-17 07:08:54 +0800) ---------------------------------------------------------------- Mediatek DRM Next for Linux 5.15 1. MT8133 AAL support, adjust rdma fifo threshold formula. 2. Implement mmap as GEM object function. 3. Add support for MT8167. 4. Test component initialization earlier in the function mtk_drm_crtc_create. 5. CMDQ refinement. ---------------------------------------------------------------- Chun-Kuang Hu (4): drm/mediatek: Use mailbox rx_callback instead of cmdq_task_cb drm/mediatek: Remove struct cmdq_client drm/mediatek: Detect CMDQ execution timeout drm/mediatek: Add cmdq_handle in mtk_crtc Dafna Hirschfeld (1): drm/mediatek: Test component initialization earlier in the function mtk_drm_crtc_create Fabien Parent (2): dt-bindings: display: mediatek: dsi: add documentation for MT8167 SoC drm/mediatek: Add support for main DDP path on MT8167 Thomas Zimmermann (1): drm/mediatek: Implement mmap as GEM object function Yongqiang Niu (4): drm/mediatek: Adjust rdma fifo threshold calculate formula drm/mediatek: Separate aal sub driver drm/mediatek: Add mt8183 aal support drm/mediatek: Clear pending flag when cmdq packet is done .../bindings/display/mediatek/mediatek,dsi.txt | 2 +- drivers/gpu/drm/mediatek/Makefile | 3 +- drivers/gpu/drm/mediatek/mtk_disp_aal.c | 167 ++++++++++++++++++++ drivers/gpu/drm/mediatek/mtk_disp_drv.h | 9 ++ drivers/gpu/drm/mediatek/mtk_disp_rdma.c | 6 +- drivers/gpu/drm/mediatek/mtk_drm_crtc.c | 173 +++++++++++++++++---- drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c | 42 +---- drivers/gpu/drm/mediatek/mtk_drm_drv.c | 59 +++++-- drivers/gpu/drm/mediatek/mtk_drm_drv.h | 1 + drivers/gpu/drm/mediatek/mtk_drm_gem.c | 44 ++---- drivers/gpu/drm/mediatek/mtk_drm_gem.h | 3 - 11 files changed, 386 insertions(+), 123 deletions(-) create mode 100644 drivers/gpu/drm/mediatek/mtk_disp_aal.c

1 0

Re: [PATCH v6 08/13] mm: call pgmap->ops->page_free for DEVICE_GENERIC pages
by Felix Kuehling 16 Aug '21

16 Aug '21

Am 2021-08-15 um 11:40 a.m. schrieb Christoph Hellwig: > On Fri, Aug 13, 2021 at 01:31:45AM -0500, Alex Sierra wrote: >> Add MEMORY_DEVICE_GENERIC case to free_zone_device_page callback. >> Device generic type memory case is now able to free its pages properly. > How is this going to work for the two existing MEMORY_DEVICE_GENERIC > that now change behavior? And which don't have a ->page_free callback > at all? That's a good catch. Existing drivers shouldn't need a page_free callback if they didn't have one before. That means we need to add a NULL-pointer check in free_device_page. Regards, Felix > >> Signed-off-by: Alex Sierra <alex.sierra(a)amd.com> >> --- >> mm/memremap.c | 5 +++-- >> 1 file changed, 3 insertions(+), 2 deletions(-) >> >> diff --git a/mm/memremap.c b/mm/memremap.c >> index 5aa8163fd948..5773e15b6ac9 100644 >> --- a/mm/memremap.c >> +++ b/mm/memremap.c >> @@ -459,7 +459,7 @@ struct dev_pagemap *get_dev_pagemap(unsigned long pfn, >> EXPORT_SYMBOL_GPL(get_dev_pagemap); >> >> #ifdef CONFIG_DEV_PAGEMAP_OPS >> -static void free_device_private_page(struct page *page) >> +static void free_device_page(struct page *page) >> { >> >> __ClearPageWaiters(page); >> @@ -498,7 +498,8 @@ void free_zone_device_page(struct page *page) >> wake_up_var(&page->_refcount); >> return; >> case MEMORY_DEVICE_PRIVATE: >> - free_device_private_page(page); >> + case MEMORY_DEVICE_GENERIC: >> + free_device_page(page); >> return; >> default: >> return; >> -- >> 2.32.0 > ---end quoted text--- >

1 0

Re: [PATCH v6 04/13] drm/amdkfd: add SPM support for SVM
by Felix Kuehling 16 Aug '21

16 Aug '21

Am 2021-08-15 um 5:10 a.m. schrieb Christoph Hellwig: >> @@ -880,17 +881,22 @@ int svm_migrate_init(struct amdgpu_device *adev) >> * should remove reserved size >> */ >> size = ALIGN(adev->gmc.real_vram_size, 2ULL << 20); >> - res = devm_request_free_mem_region(adev->dev, &iomem_resource, size); >> + if (xgmi_connected_to_cpu) >> + res = lookup_resource(&iomem_resource, adev->gmc.aper_base); >> + else >> + res = devm_request_free_mem_region(adev->dev, &iomem_resource, size); >> + > Can you explain what the point of the lookup_resource is here? res->start > is obviously identical to the start value you pass in. So this is used > as a way to query the length, but I'm pretty sure the driver must > already know that as it inserted the resource itself, right? I think you're right. We only need the start and end address from lookup_resource and we already know that anyway. It means we can drop patch 3 from the series. Just to be sure, we'll confirm that the end address determined by our driver matches the one from lookup_resource (coming from the system address map in the system BIOS). If there were a mismatch, it would probably be a bug (in the driver or the BIOS) that we'd need to fix anyway. > > On a slightly higher level comment svm_migrate_init is a bit of a mess > with all the if/else already, and with the above addressed will become > a bit more. I think splitting it into a device private and device > generic case would probably help people finding it to understand the code > much better later on. Even more so with a useful comment. I don't really see the "mess" you're talking about. Including the above, there are only 3 conditional statements in that function that are not error-handling related: /* Page migration works on Vega10 or newer */ if (kfddev->device_info->asic_family < CHIP_VEGA10) return -EINVAL; ... if (xgmi_connected_to_cpu) res = lookup_resource(&iomem_resource, adev->gmc.aper_base); else res = devm_request_free_mem_region(adev->dev, &iomem_resource, size); ... pgmap->type = xgmi_connected_to_cpu ? MEMORY_DEVICE_GENERIC : MEMORY_DEVICE_PRIVATE; Regards, Felix

1 0

[PATCH] drm/radeon: Add break to switch statement in radeonfb_create_pinned_object()
by Nathan Chancellor 16 Aug '21

16 Aug '21

Clang + -Wimplicit-fallthrough warns: drivers/gpu/drm/radeon/radeon_fb.c:170:2: warning: unannotated fall-through between switch labels [-Wimplicit-fallthrough] default: ^ drivers/gpu/drm/radeon/radeon_fb.c:170:2: note: insert 'break;' to avoid fall-through default: ^ break; 1 warning generated. Clang's version of this warning is a little bit more pedantic than GCC's. Add the missing break to satisfy it to match what has been done all over the kernel tree. Signed-off-by: Nathan Chancellor <nathan(a)kernel.org> --- drivers/gpu/drm/radeon/radeon_fb.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpu/drm/radeon/radeon_fb.c b/drivers/gpu/drm/radeon/radeon_fb.c index 0b206b052972..c8b545181497 100644 --- a/drivers/gpu/drm/radeon/radeon_fb.c +++ b/drivers/gpu/drm/radeon/radeon_fb.c @@ -167,6 +167,7 @@ static int radeonfb_create_pinned_object(struct radeon_fbdev *rfbdev, break; case 2: tiling_flags |= RADEON_TILING_SWAP_16BIT; + break; default: break; } base-commit: ba31f97d43be41ca99ab72a6131d7c226306865f -- 2.33.0.rc2

3 2

[PATCH] drm/i915/dp: Use max params for older panels
by Kai-Heng Feng 16 Aug '21

16 Aug '21

Users reported that after commit 2bbd6dba84d4 ("drm/i915: Try to use fast+narrow link on eDP again and fall back to the old max strategy on failure"), the screen starts to have wobbly effect. Commit a5c936add6a2 ("drm/i915/dp: Use slow and wide link training for everything") doesn't help either, that means the affected panels only work with max params. The panels are all DP 1.1 ones, so apply max params to them to resolve the issue. Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/3714 Fixes: 2bbd6dba84d4 ("drm/i915: Try to use fast+narrow link on eDP again and fall back to the old max strategy on failure") Fixes: a5c936add6a2 ("drm/i915/dp: Use slow and wide link training for everything") Signed-off-by: Kai-Heng Feng <kai.heng.feng(a)canonical.com> --- drivers/gpu/drm/i915/display/intel_dp.c | 12 +++++++----- 1 file changed, 7 insertions(+), 5 deletions(-) diff --git a/drivers/gpu/drm/i915/display/intel_dp.c b/drivers/gpu/drm/i915/display/intel_dp.c index 75d4ebc669411..e64bab4b016e1 100644 --- a/drivers/gpu/drm/i915/display/intel_dp.c +++ b/drivers/gpu/drm/i915/display/intel_dp.c @@ -1330,14 +1330,16 @@ intel_dp_compute_link_config(struct intel_encoder *encoder, limits.min_bpp = intel_dp_min_bpp(pipe_config->output_format); limits.max_bpp = intel_dp_max_bpp(intel_dp, pipe_config); - if (intel_dp->use_max_params) { + if (intel_dp->use_max_params || + intel_dp->dpcd[DP_DPCD_REV] <= DP_DPCD_REV_11) { /* * Use the maximum clock and number of lanes the eDP panel * advertizes being capable of in case the initial fast - * optimal params failed us. The panels are generally - * designed to support only a single clock and lane - * configuration, and typically on older panels these - * values correspond to the native resolution of the panel. + * optimal params failed us or the panel is DP 1.1 or earlier. + * The panels are generally designed to support only a single + * clock and lane configuration, and typically on older panels + * these values correspond to the native resolution of the + * panel. */ limits.min_lane_count = limits.max_lane_count; limits.min_clock = limits.max_clock; -- 2.31.1

2 1

[PATCH 0/9] Clean up some CI failures for GuC submission
by Matthew Brost 16 Aug '21

16 Aug '21

Resets are notoriously hard to get fully working and notoriously racey, especially with selftests / IGTs that do all sorts of wild things that would be near impossible to hit during normal use cases. Even though likely impossible to hit, anything selftests / IGTs uncover needs to be fixed. This series addresses 7 such issues, adds a workaround to a selftest, and add another selftest to prove scrubbing of G2H during a reset works. v2: (Daniel Vetter) - Split fixes into individual patches - A kernel doc - A VLK ref for selftest workaround (Checkpatch) - Fix warnings Signed-off-by: Matthew Brost <matthew.brost(a)intel.com> Matthew Brost (9): drm/i915/guc: Fix blocked context accounting drm/i915/guc: 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: Flush the work queue for GuC generated G2H drm/i915/guc: Do not clear enable during reset in an enable is inflight drm/i915/guc: Don't enable scheduling on a banned context drm/i915/selftests: Fix memory corruption in live_lrc_isolation drm/i915/selftests: Add initial GuC selftest for scrubbing lost G2H drivers/gpu/drm/i915/gt/intel_context_types.h | 18 +++ drivers/gpu/drm/i915/gt/selftest_lrc.c | 29 +++- .../gpu/drm/i915/gt/uc/intel_guc_submission.c | 69 +++++++--- drivers/gpu/drm/i915/gt/uc/selftest_guc.c | 126 ++++++++++++++++++ .../drm/i915/selftests/i915_live_selftests.h | 1 + .../i915/selftests/intel_scheduler_helpers.c | 12 ++ .../i915/selftests/intel_scheduler_helpers.h | 2 + 7 files changed, 239 insertions(+), 18 deletions(-) create mode 100644 drivers/gpu/drm/i915/gt/uc/selftest_guc.c -- 2.32.0

2 18

Re: [Linaro-mm-sig] IIO, dmabuf, io_uring
by Daniel Vetter 16 Aug '21

16 Aug '21

On Sat, Aug 14, 2021 at 09:30:19AM +0200, Christoph Hellwig wrote: > On Fri, Aug 13, 2021 at 01:41:26PM +0200, Paul Cercueil wrote: > > Hi, > > > > A few months ago we (ADI) tried to upstream the interface we use with our > > high-speed ADCs and DACs. It is a system with custom ioctls on the iio > > device node to dequeue and enqueue buffers (allocated with > > dma_alloc_coherent), that can then be mmap'd by userspace applications. > > Anyway, it was ultimately denied entry [1]; this API was okay in ~2014 when > > it was designed but it feels like re-inventing the wheel in 2021. > > > > Back to the drawing table, and we'd like to design something that we can > > actually upstream. This high-speed interface looks awfully similar to > > DMABUF, so we may try to implement a DMABUF interface for IIO, unless > > someone has a better idea. > > To me this does sound a lot like a dma buf use case. The interesting > question to me is how to signal arrival of new data, or readyness to > consume more data. I suspect that people that are actually using > dmabuf heavily at the moment (dri/media folks) might be able to chime > in a little more on that. One option is to just block in userspace (on poll, or an ioctl, or whatever) and then latch the next stage in the pipeline. That's what media does right now (because the dma-fence proposal never got anywhere). In drm we use dma_fences to tie up the stages, and the current recommendation for uapi is to use the drm_syncobj container (not the sync_file container, that was a bit an awkward iteration on that problem). With that you can tie together all the pipeline stages within the kernel (and at least sometimes directly in hw). The downside is (well imo it's not a downside, but some people see it as hta) that once you use dma-fence dri-devel folks really consider your stuff a gpu driver and expect all the gpu driver review/merge criteria to be fulfilled. Specifically about the userspace side too: https://dri.freedesktop.org/docs/drm/gpu/drm-uapi.html#open-source-userspac… At least one driver is trying to play some very clever games here and that's not a solid way to make friends ... -Daniel > > > Our first usecase is, we want userspace applications to be able to dequeue > > buffers of samples (from ADCs), and/or enqueue buffers of samples (for > > DACs), and to be able to manipulate them (mmapped buffers). With a DMABUF > > interface, I guess the userspace application would dequeue a dma buffer > > from the driver, mmap it, read/write the data, unmap it, then enqueue it to > > the IIO driver again so that it can be disposed of. Does that sound sane? > > > > Our second usecase is - and that's where things get tricky - to be able to > > stream the samples to another computer for processing, over Ethernet or > > USB. Our typical setup is a high-speed ADC/DAC on a dev board with a FPGA > > and a weak soft-core or low-power CPU; processing the data in-situ is not > > an option. Copying the data from one buffer to another is not an option > > either (way too slow), so we absolutely want zero-copy. > > > > Usual userspace zero-copy techniques (vmsplice+splice, MSG_ZEROCOPY etc) > > don't really work with mmapped kernel buffers allocated for DMA [2] and/or > > have a huge overhead, so the way I see it, we would also need DMABUF > > support in both the Ethernet stack and USB (functionfs) stack. However, as > > far as I understood, DMABUF is mostly a DRM/V4L2 thing, so I am really not > > sure we have the right idea here. > > > > And finally, there is the new kid in town, io_uring. I am not very literate > > about the topic, but it does not seem to be able to handle DMA buffers > > (yet?). The idea that we could dequeue a buffer of samples from the IIO > > device and send it over the network in one single syscall is appealing, > > though. > > Think of io_uring really just as an async syscall layer. It doesn't > replace DMA buffers, but can be used as a different and for some > workloads more efficient way to dispatch syscalls. > _______________________________________________ > Linaro-mm-sig mailing list > Linaro-mm-sig(a)lists.linaro.org > https://lists.linaro.org/mailman/listinfo/linaro-mm-sig -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch

1 0

[PATCH 0/1] Fix DRM driver initialization failure in kernel v5.14
by Dan Moulding 16 Aug '21

16 Aug '21

After trying out kernel v5.14-rc5 on my system, I no longer get any display output. Checking dmesg, I found it's because my DRM driver (nouveau) is failing at ttm_device_init. That is failing because of a behavior change in ttm_global_init with respect to debugfs. debugfs is disabled on my system, which causes ttm_global_init to fail. The following patch fixes the issue by ignoring the debugfs failure, which is expected, rather than allowing it to cause ttm_global_init to fail. Dan Moulding (1): drm: ttm: Don't bail from ttm_global_init if debugfs_create_dir fails drivers/gpu/drm/ttm/ttm_device.c | 2 -- 1 file changed, 2 deletions(-) -- 2.31.1

5 8

[PATCH] drm/i915: Ditch the i915_gem_ww_ctx loop member
by Thomas Hellström 16 Aug '21

16 Aug '21

It's only used by the for_i915_gem_ww() macro and we can use the (typically) on-stack _err variable in its place. While initially setting the _err variable to -EDEADLK to enter the loop, we clear it before actually entering using fetch_and_zero() to avoid empty loops or code not setting the _err variable running forever. Suggested-by: Maarten Lankhorst <maarten.lankhorst(a)linux.intel.com> Signed-off-by: Thomas Hellström <thomas.hellstrom(a)linux.intel.com> --- drivers/gpu/drm/i915/i915_gem_ww.h | 23 ++++++++--------------- 1 file changed, 8 insertions(+), 15 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_gem_ww.h b/drivers/gpu/drm/i915/i915_gem_ww.h index f6b1a796667b..98348b1e6182 100644 --- a/drivers/gpu/drm/i915/i915_gem_ww.h +++ b/drivers/gpu/drm/i915/i915_gem_ww.h @@ -7,12 +7,13 @@ #include <drm/drm_drv.h> +#include "i915_utils.h" + struct i915_gem_ww_ctx { struct ww_acquire_ctx ctx; struct list_head obj_list; struct drm_i915_gem_object *contended; - unsigned short intr; - unsigned short loop; + bool intr; }; void i915_gem_ww_ctx_init(struct i915_gem_ww_ctx *ctx, bool intr); @@ -23,28 +24,20 @@ void i915_gem_ww_unlock_single(struct drm_i915_gem_object *obj); /* Internal functions used by the inlines! Don't use. */ static inline int __i915_gem_ww_fini(struct i915_gem_ww_ctx *ww, int err) { - ww->loop = 0; if (err == -EDEADLK) { err = i915_gem_ww_ctx_backoff(ww); if (!err) - ww->loop = 1; + err = -EDEADLK; } - if (!ww->loop) + if (err != -EDEADLK) i915_gem_ww_ctx_fini(ww); return err; } -static inline void -__i915_gem_ww_init(struct i915_gem_ww_ctx *ww, bool intr) -{ - i915_gem_ww_ctx_init(ww, intr); - ww->loop = 1; -} - -#define for_i915_gem_ww(_ww, _err, _intr) \ - for (__i915_gem_ww_init(_ww, _intr); (_ww)->loop; \ +#define for_i915_gem_ww(_ww, _err, _intr) \ + for (i915_gem_ww_ctx_init(_ww, _intr), (_err) = -EDEADLK; \ + fetch_and_zero(&_err) == -EDEADLK; \ _err = __i915_gem_ww_fini(_ww, _err)) - #endif -- 2.31.1

3 4

← Newer
1
...
47
48
49
50
51
52
53
...
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