dri-devel April 2022

dri-devel@lists.freedesktop.org

351 participants
951 discussions

[PATCH 1/3] drm: Add infrastructure to allow seamless mode switches
by José Roberto de Souza 26 Apr '22

26 Apr '22

Intel hardware supports change between modes with different refresh rates without any glitches or visual artifacts, that feature is called seamless DRRS. So far i915 driver was automatically changing between preferred panel mode and lower refresh rate mode based on idleness but ChromeOS compositor team is requesting to be in control of the mode switch. So for a certain types of content it can switch to mode with a lower refresh rate without user noticing a thing and saving power. This seamless mode switch will be triggered when user-space dispatch a atomic commit with the new mode and clears the DRM_MODE_ATOMIC_ALLOW_MODESET flag. A driver that don't implement atomic_seamless_mode_switch_check function will continue to fail in the atomic check phase with "[CRTC:%d:%s] requires full modeset" debug message. While a driver that implements it and support the seamless change between old and new mode will return 0 otherwise it should return the appropried errno. So here adding basic drm infrastructure to that be supported by i915 and other drivers. Cc: Vidya Srinivas <vidya.srinivas(a)intel.com> Cc: Sean Paul <seanpaul(a)chromium.org> Cc: Ville Syrjälä <ville.syrjala(a)linux.intel.com> Signed-off-by: José Roberto de Souza <jose.souza(a)intel.com> --- drivers/gpu/drm/drm_atomic.c | 1 + drivers/gpu/drm/drm_atomic_helper.c | 16 +++++++++++++++ drivers/gpu/drm/drm_atomic_state_helper.c | 1 + include/drm/drm_crtc.h | 25 +++++++++++++++++++++++ 4 files changed, 43 insertions(+) diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c index 58c0283fb6b0c..21525f9f4b4c1 100644 --- a/drivers/gpu/drm/drm_atomic.c +++ b/drivers/gpu/drm/drm_atomic.c @@ -437,6 +437,7 @@ static void drm_atomic_crtc_print_state(struct drm_printer *p, drm_printf(p, "\tself_refresh_active=%d\n", state->self_refresh_active); drm_printf(p, "\tplanes_changed=%d\n", state->planes_changed); drm_printf(p, "\tmode_changed=%d\n", state->mode_changed); + drm_printf(p, "\tseamless_mode_changed=%d\n", state->seamless_mode_changed); drm_printf(p, "\tactive_changed=%d\n", state->active_changed); drm_printf(p, "\tconnectors_changed=%d\n", state->connectors_changed); drm_printf(p, "\tcolor_mgmt_changed=%d\n", state->color_mgmt_changed); diff --git a/drivers/gpu/drm/drm_atomic_helper.c b/drivers/gpu/drm/drm_atomic_helper.c index 9603193d2fa13..e6f3a966f7b86 100644 --- a/drivers/gpu/drm/drm_atomic_helper.c +++ b/drivers/gpu/drm/drm_atomic_helper.c @@ -631,6 +631,22 @@ drm_atomic_helper_check_modeset(struct drm_device *dev, drm_dbg_atomic(dev, "[CRTC:%d:%s] mode changed\n", crtc->base.id, crtc->name); new_crtc_state->mode_changed = true; + + if (!state->allow_modeset && + crtc->funcs->atomic_seamless_mode_switch_check) { + ret = crtc->funcs->atomic_seamless_mode_switch_check(state, crtc); + if (ret == -EOPNOTSUPP) { + drm_dbg_atomic(dev, "[CRTC:%d:%s] Seamless mode switch not supported\n", + crtc->base.id, crtc->name); + return ret; + } + + if (ret < 0) + return ret; + + new_crtc_state->seamless_mode_changed = true; + new_crtc_state->mode_changed = false; + } } if (old_crtc_state->enable != new_crtc_state->enable) { diff --git a/drivers/gpu/drm/drm_atomic_state_helper.c b/drivers/gpu/drm/drm_atomic_state_helper.c index 3b6d3bdbd0996..c093073ea6e11 100644 --- a/drivers/gpu/drm/drm_atomic_state_helper.c +++ b/drivers/gpu/drm/drm_atomic_state_helper.c @@ -142,6 +142,7 @@ void __drm_atomic_helper_crtc_duplicate_state(struct drm_crtc *crtc, if (state->gamma_lut) drm_property_blob_get(state->gamma_lut); state->mode_changed = false; + state->seamless_mode_changed = false; state->active_changed = false; state->planes_changed = false; state->connectors_changed = false; diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h index a70baea0636ca..b7ce378d679d3 100644 --- a/include/drm/drm_crtc.h +++ b/include/drm/drm_crtc.h @@ -140,6 +140,16 @@ struct drm_crtc_state { */ bool mode_changed : 1; + /** + * @seamless_mode_changed: @mode has been changed but user-space + * is requesting to change to the new mode with a fastset and driver + * supports this request. + * To be used by drivers to steer the atomic commit control flow to + * appropriate paths to change mode without any visual corruption. + * Never set together with @mode_changed. + */ + bool seamless_mode_changed : 1; + /** * @active_changed: @active has been toggled. Used by the atomic * helpers and drivers to steer the atomic commit control flow. See also @@ -939,6 +949,21 @@ struct drm_crtc_funcs { int *max_error, ktime_t *vblank_time, bool in_vblank_irq); + + /** + * @atomic_seamless_mode_switch_check + * + * Called when user-space wants to change mode without do a modeset. + * Drivers can optionally support do a mode switch without any visual + * corruption when changing between certain modes. + * + * Returns: + * Zero if possible to seamless switch mode, -EOPNOTSUPP if not + * supported seamless mode change or appropriate errno if an error + * happened. + */ + int (*atomic_seamless_mode_switch_check)(struct drm_atomic_state *state, + struct drm_crtc *crtc); }; /** -- 2.36.0

5 8

Requests For Proposals for hosting XDC 2023 are now open
by Lyude Paul 26 Apr '22

26 Apr '22

Hello everyone! The X.org board is soliciting proposals to host XDC in 2023. Since XDC 2022 is being held in North America this year, XDC 2023 is expected to be in Europe. However, the board is open to other locations, especially if there's an interesting co-location with another conference. If you're considering hosting XDC, we've assembled a wiki page with what's generally expected and needed: https://www.x.org/wiki/Events/RFP/ When submitting your proposal, please make sure to include at least the key information about the potential location in question, possible dates along with estimated costs. Proposals can be submitted to board at foundation.x.org until the deadline of *September 1st, 2022*. Additionally, an quirk early heads-up to the board if you're considering hosting would be appreciated, in case we need to adjust the schedule a bit. Also, earlier is better since there generally will be a bit of Q&A with organizers. And if you just have some questions about what organizing XDC entails, please feel free to chat with previous organizers, or someone from the board. Best regards, Lyude Paul On behalf of X.org

1 0

XDC 2022: Registration & Call for Proposals now open!
by Lyude Paul 26 Apr '22

26 Apr '22

Hello! The 2022 X.Org Developers Conference is being held in conjunction with the 2022 Wine Developers Conference. This is a meeting to bring together developers working on all things open graphics (Linux kernel, Mesa, DRM, Wayland, X11, etc.) as well as developers for the Wine Project, a key consumer of open graphics. Registration & Call for Proposals are now open for both XDC 2022 and WineConf 2022, which will take place on October 4-6, 2022 in Minneapolis, Minnesota, USA. https://xdc2022.x.org As usual, the conference is free of charge and open to the general public. If you plan on attending, please make sure to register as early as possible! In order to register as attendee, you will therefore need to do it via the XDC website: https://indico.freedesktop.org/event/2/registrations/2/ In addition to registration, the CfP is now open for talks, workshops and demos at XDC 2022. While any serious proposal will be gratefully considered, topics of interest to X.Org and freedesktop.org developers are encouraged. The program focus is on new development, ongoing challenges and anything else that will spark discussions among attendees in the hallway track. We are open to talks across all layers of the graphics stack, from the kernel to desktop environments / graphical applications and about how to make things better for the developers who build them. Head to the CfP page to learn more: https://indico.freedesktop.org/event/2/abstracts/ The deadline for submissions is Monday July 4th, 2022. Check out our Reimbursement Policy to accept speaker expenses for X.Org events like XDC 2022: https://www.x.org/wiki/XorgFoundation/Policies/Reimbursement/ If you have any questions, please send me an email to xdc(a)codeweavers.com, adding on CC the X.org board (board at foundation.x.org). And don't forget, you can follow us on Twitter for all the latest updates and to stay connected: https://twitter.com/XOrgDevConf Best regards, Lyude Paul, on behalf of X.org

1 0

[PATCH] drm/nouveau: fix returnvar.cocci warning
by Guo Zhengkui 26 Apr '22

26 Apr '22

Fix the following coccicheck warning: drivers/gpu/drm/nouveau/nvkm/subdev/devinit/gt215.c:71:5-12: Unneeded variable: "disable". Return "0ULL" on line 85. Signed-off-by: Guo Zhengkui <guozhengkui(a)vivo.com> --- drivers/gpu/drm/nouveau/nvkm/subdev/devinit/gt215.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/devinit/gt215.c b/drivers/gpu/drm/nouveau/nvkm/subdev/devinit/gt215.c index dc026ac1b595..3d0ab86c3115 100644 --- a/drivers/gpu/drm/nouveau/nvkm/subdev/devinit/gt215.c +++ b/drivers/gpu/drm/nouveau/nvkm/subdev/devinit/gt215.c @@ -68,7 +68,6 @@ gt215_devinit_disable(struct nvkm_devinit *init) struct nvkm_device *device = init->subdev.device; u32 r001540 = nvkm_rd32(device, 0x001540); u32 r00154c = nvkm_rd32(device, 0x00154c); - u64 disable = 0ULL; if (!(r001540 & 0x40000000)) { nvkm_subdev_disable(device, NVKM_ENGINE_MSPDEC, 0); @@ -82,7 +81,7 @@ gt215_devinit_disable(struct nvkm_devinit *init) if (!(r00154c & 0x00000200)) nvkm_subdev_disable(device, NVKM_ENGINE_CE, 0); - return disable; + return 0ULL; } static u32 -- 2.20.1

2 1

[PATCH v3 0/2] fix DP phy compliance test
by Kuogee Hsieh 26 Apr '22

26 Apr '22

Current DP phy compliance test failed due to test pattern generation was terminated premature. Kuogee Hsieh (2): drm/msm/dp: reset DP controller before transmit phy test pattern drm/msm/dp: do not stop transmitting phy test pattern during DP phy compliance test drivers/gpu/drm/msm/dp/dp_ctrl.c | 16 +++++++--------- 1 file changed, 7 insertions(+), 9 deletions(-) -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project

1 2

[PATCH] drm/nouveau/disp/gv100: make gv100_disp_wndw and gv100_disp_wndw_mthd static
by Tom Rix 26 Apr '22

26 Apr '22

Sparse reports these issues wndwgv100.c:120:1: warning: symbol 'gv100_disp_wndw_mthd' was not declared. Should it be static? wndwgv100.c:140:1: warning: symbol 'gv100_disp_wndw' was not declared. Should it be static? These variable are only used in wndwgv100.c. Single file variables should be static. So use static as their storage-class specifiers. Signed-off-by: Tom Rix <trix(a)redhat.com> --- drivers/gpu/drm/nouveau/nvkm/engine/disp/wndwgv100.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/nouveau/nvkm/engine/disp/wndwgv100.c b/drivers/gpu/drm/nouveau/nvkm/engine/disp/wndwgv100.c index 5d3b641dbb14..e635247d794f 100644 --- a/drivers/gpu/drm/nouveau/nvkm/engine/disp/wndwgv100.c +++ b/drivers/gpu/drm/nouveau/nvkm/engine/disp/wndwgv100.c @@ -116,7 +116,7 @@ gv100_disp_wndw_mthd_base = { } }; -const struct nv50_disp_chan_mthd +static const struct nv50_disp_chan_mthd gv100_disp_wndw_mthd = { .name = "Window", .addr = 0x001000, @@ -136,7 +136,7 @@ gv100_disp_wndw_intr(struct nv50_disp_chan *chan, bool en) nvkm_mask(device, 0x611da4, mask, data); } -const struct nv50_disp_chan_func +static const struct nv50_disp_chan_func gv100_disp_wndw = { .init = gv100_disp_dmac_init, .fini = gv100_disp_dmac_fini, -- 2.27.0

2 1

[PATCH] drm/nouveau/disp/gv100: make gv100_disp_wimm static
by Tom Rix 26 Apr '22

26 Apr '22

Sparse reports this issue wimmgv100.c:39:1: warning: symbol 'gv100_disp_wimm' was not declared. Should it be static? This variable is only used in wimmgv100.c. Single file variables should be static. So use static as its storage-class specifier. Signed-off-by: Tom Rix <trix(a)redhat.com> --- drivers/gpu/drm/nouveau/nvkm/engine/disp/wimmgv100.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/nouveau/nvkm/engine/disp/wimmgv100.c b/drivers/gpu/drm/nouveau/nvkm/engine/disp/wimmgv100.c index 89d783368b4f..bb4db6351ddf 100644 --- a/drivers/gpu/drm/nouveau/nvkm/engine/disp/wimmgv100.c +++ b/drivers/gpu/drm/nouveau/nvkm/engine/disp/wimmgv100.c @@ -35,7 +35,7 @@ gv100_disp_wimm_intr(struct nv50_disp_chan *chan, bool en) nvkm_mask(device, 0x611da8, mask, data); } -const struct nv50_disp_chan_func +static const struct nv50_disp_chan_func gv100_disp_wimm = { .init = gv100_disp_dmac_init, .fini = gv100_disp_dmac_fini, -- 2.27.0

2 1

[PATCH] drm/nouveau/kms/gv100: use static for gv100_disp_core_mthd_[base|sor]
by Tom Rix 26 Apr '22

26 Apr '22

Sparse reports these issues coregv100.c:27:1: warning: symbol 'gv100_disp_core_mthd_base' was not declared. Should it be static? coregv100.c:43:1: warning: symbol 'gv100_disp_core_mthd_sor' was not declared. Should it be static? These variables are only used in coregv100.c. Single file use variables should be static, so add static to their storage-class specifier. Signed-off-by: Tom Rix <trix(a)redhat.com> --- drivers/gpu/drm/nouveau/nvkm/engine/disp/coregv100.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/nouveau/nvkm/engine/disp/coregv100.c b/drivers/gpu/drm/nouveau/nvkm/engine/disp/coregv100.c index 448a515057c7..1d333c484a49 100644 --- a/drivers/gpu/drm/nouveau/nvkm/engine/disp/coregv100.c +++ b/drivers/gpu/drm/nouveau/nvkm/engine/disp/coregv100.c @@ -23,7 +23,7 @@ #include <subdev/timer.h> -const struct nv50_disp_mthd_list +static const struct nv50_disp_mthd_list gv100_disp_core_mthd_base = { .mthd = 0x0000, .addr = 0x000000, @@ -39,7 +39,7 @@ gv100_disp_core_mthd_base = { } }; -const struct nv50_disp_mthd_list +static const struct nv50_disp_mthd_list gv100_disp_core_mthd_sor = { .mthd = 0x0020, .addr = 0x000020, -- 2.27.0

2 1

[PATCH] dma-buf: remove trace_dma_fence_emit
by Christian König 26 Apr '22

26 Apr '22

There was never any significant difference between trace_dma_fence_emit() and trace_dma_fence_init() and the only place where it would made a significant difference was never implemented. So remove trace_dma_fence_emit() since we have an repeating issue that people are trying to use it for visualization and are surprised that it actually doesn't work for most drivers. Signed-off-by: Christian König <christian.koenig(a)amd.com> --- drivers/dma-buf/dma-fence.c | 1 - drivers/gpu/drm/nouveau/nouveau_fence.c | 1 - drivers/gpu/drm/qxl/qxl_release.c | 1 - drivers/gpu/drm/virtio/virtgpu_fence.c | 2 -- include/trace/events/dma_fence.h | 7 ------- 5 files changed, 12 deletions(-) diff --git a/drivers/dma-buf/dma-fence.c b/drivers/dma-buf/dma-fence.c index 066400ed8841..d0d704f3edae 100644 --- a/drivers/dma-buf/dma-fence.c +++ b/drivers/dma-buf/dma-fence.c @@ -20,7 +20,6 @@ #define CREATE_TRACE_POINTS #include <trace/events/dma_fence.h> -EXPORT_TRACEPOINT_SYMBOL(dma_fence_emit); EXPORT_TRACEPOINT_SYMBOL(dma_fence_enable_signal); EXPORT_TRACEPOINT_SYMBOL(dma_fence_signaled); diff --git a/drivers/gpu/drm/nouveau/nouveau_fence.c b/drivers/gpu/drm/nouveau/nouveau_fence.c index 7f01dcf81fab..abcac7db4347 100644 --- a/drivers/gpu/drm/nouveau/nouveau_fence.c +++ b/drivers/gpu/drm/nouveau/nouveau_fence.c @@ -224,7 +224,6 @@ nouveau_fence_emit(struct nouveau_fence *fence, struct nouveau_channel *chan) &fctx->lock, fctx->context, ++fctx->sequence); kref_get(&fctx->fence_ref); - trace_dma_fence_emit(&fence->base); ret = fctx->emit(fence); if (!ret) { dma_fence_get(&fence->base); diff --git a/drivers/gpu/drm/qxl/qxl_release.c b/drivers/gpu/drm/qxl/qxl_release.c index 368d26da0d6a..cb9f27771f32 100644 --- a/drivers/gpu/drm/qxl/qxl_release.c +++ b/drivers/gpu/drm/qxl/qxl_release.c @@ -424,7 +424,6 @@ void qxl_release_fence_buffer_objects(struct qxl_release *release) */ dma_fence_init(&release->base, &qxl_fence_ops, &qdev->release_lock, release->id | 0xf0000000, release->base.seqno); - trace_dma_fence_emit(&release->base); list_for_each_entry(entry, &release->bos, head) { bo = entry->bo; diff --git a/drivers/gpu/drm/virtio/virtgpu_fence.c b/drivers/gpu/drm/virtio/virtgpu_fence.c index f28357dbde35..e8b6dec37977 100644 --- a/drivers/gpu/drm/virtio/virtgpu_fence.c +++ b/drivers/gpu/drm/virtio/virtgpu_fence.c @@ -111,8 +111,6 @@ void virtio_gpu_fence_emit(struct virtio_gpu_device *vgdev, list_add_tail(&fence->node, &drv->fences); spin_unlock_irqrestore(&drv->lock, irq_flags); - trace_dma_fence_emit(&fence->f); - cmd_hdr->flags |= cpu_to_le32(VIRTIO_GPU_FLAG_FENCE); cmd_hdr->fence_id = cpu_to_le64(fence->fence_id); diff --git a/include/trace/events/dma_fence.h b/include/trace/events/dma_fence.h index 3963e79ca7b4..eb744a6aca49 100644 --- a/include/trace/events/dma_fence.h +++ b/include/trace/events/dma_fence.h @@ -34,13 +34,6 @@ DECLARE_EVENT_CLASS(dma_fence, __entry->seqno) ); -DEFINE_EVENT(dma_fence, dma_fence_emit, - - TP_PROTO(struct dma_fence *fence), - - TP_ARGS(fence) -); - DEFINE_EVENT(dma_fence, dma_fence_init, TP_PROTO(struct dma_fence *fence), -- 2.25.1

1 1

[PATCH v3 0/7] drm/i915: Use the memcpy_from_wc function from drm
by Balasubramani Vivekanandan 26 Apr '22

26 Apr '22

drm_memcpy_from_wc() performs fast copy from WC memory type using non-temporal instructions. Now there are two similar implementations of this function. One exists in drm_cache.c as drm_memcpy_from_wc() and another implementation in i915/i915_memcpy.c as i915_memcpy_from_wc(). drm_memcpy_from_wc() was the recent addition through the series https://patchwork.freedesktop.org/patch/436276/?series=90681&rev=6 The goal of this patch series is to change all users of i915_memcpy_from_wc() to drm_memcpy_from_wc() and a have common implementation in drm and eventually remove the copy from i915. Another benefit of using memcpy functions from drm is that drm_memcpy_from_wc() is available for non-x86 architectures. i915_memcpy_from_wc() is implemented only for x86 and prevents building i915 for ARM64. drm_memcpy_from_wc() does fast copy using non-temporal instructions for x86 and for other architectures makes use of memcpy() family of functions as fallback. Another major difference is unlike i915_memcpy_from_wc(), drm_memcpy_from_wc() will not fail if the passed address argument is not alignment to be used with non-temporal load instructions or if the platform lacks support for those instructions (non-temporal load instructions are provided through SSE4.1 instruction set extension). Instead drm_memcpy_from_wc() continues with fallback functions to complete the copy. This relieves the caller from checking the return value of i915_memcpy_from_wc() and explicitly using a fallback. Follow up series will be created to remove the memcpy_from_wc functions from i915 once the dependency is completely removed. v2: Fixed missing check to find if the address is from system memory or io memory and use the right initialization function to construct the iosys_map structure (Review feedback from Lucas) v3: "drm/i915/guc: use the memcpy_from_wc call from the drm" replaced by patch "drm/i915/guc: use iosys_map abstraction to access GuC log". New patch does a wider change compared to the old patch. It completely changes the access to GuC log using iosys_map abstraction, in addition to using drm_memcpy_from_wc. Cc: Jani Nikula <jani.nikula(a)intel.com> Cc: Lucas De Marchi <lucas.demarchi(a)intel.com> Cc: David Airlie <airlied(a)linux.ie> Cc: Daniel Vetter <daniel(a)ffwll.ch> Cc: Chris Wilson <chris.p.wilson(a)intel.com> Cc: Thomas Hellstr_m <thomas.hellstrom(a)linux.intel.com> Cc: Joonas Lahtinen <joonas.lahtinen(a)linux.intel.com> Cc: Rodrigo Vivi <rodrigo.vivi(a)intel.com> Cc: Tvrtko Ursulin <tvrtko.ursulin(a)linux.intel.com> Cc: Nirmoy Das <nirmoy.das(a)intel.com> Balasubramani Vivekanandan (7): drm: Relax alignment constraint for destination address drm: Add drm_memcpy_from_wc() variant which accepts destination address drm/i915: use the memcpy_from_wc call from the drm drm/i915/guc: use iosys_map abstraction to access GuC log drm/i915/selftests: use the memcpy_from_wc call from the drm drm/i915/gt: Avoid direct dereferencing of io memory drm/i915: Avoid dereferencing io mapped memory drivers/gpu/drm/drm_cache.c | 99 +++++++++++++++++-- drivers/gpu/drm/i915/gem/i915_gem_object.c | 8 +- drivers/gpu/drm/i915/gt/selftest_reset.c | 21 ++-- drivers/gpu/drm/i915/gt/uc/guc_capture_fwif.h | 2 +- .../gpu/drm/i915/gt/uc/intel_guc_capture.c | 52 +++++++--- drivers/gpu/drm/i915/gt/uc/intel_guc_log.c | 77 +++++++++++---- drivers/gpu/drm/i915/gt/uc/intel_guc_log.h | 3 +- drivers/gpu/drm/i915/i915_gpu_error.c | 45 +++++---- .../drm/i915/selftests/intel_memory_region.c | 41 +++++--- include/drm/drm_cache.h | 3 + 10 files changed, 261 insertions(+), 90 deletions(-) -- 2.25.1

1 7

← Newer
1
...
25
26
27
28
29
30
31
...
96
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

dri-devel April 2022