dri-devel May 2022

dri-devel@lists.freedesktop.org

344 participants
736 discussions

Re: [PATCH] drm/i915: Change semantics of context isolation reporting to UM
by Daniel Vetter 05 May '22

05 May '22

On Fri, 29 Apr 2022 at 17:11, Adrian Larumbe <adrian.larumbe(a)collabora.com> wrote: > I915_PARAM_HAS_CONTEXT_ISOLATION was already being used as a boolean by > both Iris and Vulkan , and stood for the guarantee that, when creating a > new context, all state set by it will not leak to any other context. > > However the actual return value was a bitmask where every bit stood for an > initialised engine, and IGT test gem_ctx_isolation makes use of this mask > for deciding on the actual context engine isolation status. > > However, we do not provide UAPI for IGT tests, so the value returned by the > PARAM ioctl has to reflect Mesa usage as a boolean. > > This change only made sense after compute engine support was added to the > driver in commit 944823c9463916dd53f3 ("drm/i915/xehp: Define compute class > and engine") because no context isolation can be assumed on any device with > both RCS annd CCS engines. > > Signed-off-by: Adrian Larumbe <adrian.larumbe(a)collabora.com> Top level post and adding Matt Roper and dri-devel. This was meant as a simple cleanup after CCS enabling in upstream, but that CCS enabling seems to have gone wrong. What I thought we should be done for CCS enabling is the following: - actually have some igt-side hardcoded assumption about how much engines are isolated from each another, which is a hw property. I think some of that landed, but it's very incomplete - convert all igt tests over to that. At least gem_ctx_isolation.c is not converted over, as Adrian pointed out. - once igt stopped using this context isolation getparam (we do not, ever, create uapi just for testcases), fix up the uapi to what iris actually needs, which is _only_ a boolean which indicates whether the kernel's context setup code leaks register state from existing contexts to newly created ones. Which is the bug iris works around here, where using iris caused gpu hangs in libva. Iow, the kernel should always and unconditionally return true here. Check out iris history for details please, actual iris usage has nothing to do with any other cross-context or cross-engine isolation guarantee we're making, it's purely about whether our hw ctx code is buggy or not and leaks state between clients, because we accidentally used the currently running ctx as template instead of a fixed one created once at driver load. Matt, since the CCS enabling on the igt validation side looks very incomplete I'm leaning very much towards "pls revert, try again". Cheers, Daniel > --- > drivers/gpu/drm/i915/gt/intel_engine_user.c | 13 ++++++++++++- > drivers/gpu/drm/i915/gt/intel_engine_user.h | 1 + > drivers/gpu/drm/i915/i915_drm_client.h | 2 +- > drivers/gpu/drm/i915/i915_getparam.c | 2 +- > include/uapi/drm/i915_drm.h | 14 +++----------- > 5 files changed, 18 insertions(+), 14 deletions(-) > > diff --git a/drivers/gpu/drm/i915/gt/intel_engine_user.c b/drivers/gpu/drm/i915/gt/intel_engine_user.c > index 0f6cd96b459f..2d6bd36d6150 100644 > --- a/drivers/gpu/drm/i915/gt/intel_engine_user.c > +++ b/drivers/gpu/drm/i915/gt/intel_engine_user.c > @@ -47,7 +47,7 @@ static const u8 uabi_classes[] = { > [COPY_ENGINE_CLASS] = I915_ENGINE_CLASS_COPY, > [VIDEO_DECODE_CLASS] = I915_ENGINE_CLASS_VIDEO, > [VIDEO_ENHANCEMENT_CLASS] = I915_ENGINE_CLASS_VIDEO_ENHANCE, > - /* TODO: Add COMPUTE_CLASS mapping once ABI is available */ > + [COMPUTE_CLASS] = I915_ENGINE_CLASS_COMPUTE, > }; > > static int engine_cmp(void *priv, const struct list_head *A, > @@ -306,3 +306,14 @@ unsigned int intel_engines_has_context_isolation(struct drm_i915_private *i915) > > return which; > } > + > +bool intel_cross_engine_isolated(struct drm_i915_private *i915) > +{ > + unsigned int which = intel_engines_has_context_isolation(i915); > + > + if ((which & BIT(I915_ENGINE_CLASS_RENDER)) && > + (which & BIT(I915_ENGINE_CLASS_COMPUTE))) > + return false; > + > + return !!which; > +} > diff --git a/drivers/gpu/drm/i915/gt/intel_engine_user.h b/drivers/gpu/drm/i915/gt/intel_engine_user.h > index 3dc7e8ab9fbc..ff21349db4d4 100644 > --- a/drivers/gpu/drm/i915/gt/intel_engine_user.h > +++ b/drivers/gpu/drm/i915/gt/intel_engine_user.h > @@ -15,6 +15,7 @@ struct intel_engine_cs * > intel_engine_lookup_user(struct drm_i915_private *i915, u8 class, u8 instance); > > unsigned int intel_engines_has_context_isolation(struct drm_i915_private *i915); > +bool intel_cross_engine_isolated(struct drm_i915_private *i915); > > void intel_engine_add_user(struct intel_engine_cs *engine); > void intel_engines_driver_register(struct drm_i915_private *i915); > diff --git a/drivers/gpu/drm/i915/i915_drm_client.h b/drivers/gpu/drm/i915/i915_drm_client.h > index 5f5b02b01ba0..f796c5e8e060 100644 > --- a/drivers/gpu/drm/i915/i915_drm_client.h > +++ b/drivers/gpu/drm/i915/i915_drm_client.h > @@ -13,7 +13,7 @@ > > #include "gt/intel_engine_types.h" > > -#define I915_LAST_UABI_ENGINE_CLASS I915_ENGINE_CLASS_VIDEO_ENHANCE > +#define I915_LAST_UABI_ENGINE_CLASS I915_ENGINE_CLASS_COMPUTE > > struct drm_i915_private; > > diff --git a/drivers/gpu/drm/i915/i915_getparam.c b/drivers/gpu/drm/i915/i915_getparam.c > index c12a0adefda5..3d5120d2d78a 100644 > --- a/drivers/gpu/drm/i915/i915_getparam.c > +++ b/drivers/gpu/drm/i915/i915_getparam.c > @@ -145,7 +145,7 @@ int i915_getparam_ioctl(struct drm_device *dev, void *data, > value = 1; > break; > case I915_PARAM_HAS_CONTEXT_ISOLATION: > - value = intel_engines_has_context_isolation(i915); > + value = intel_cross_engine_isolated(i915); > break; > case I915_PARAM_SLICE_MASK: > value = sseu->slice_mask; > diff --git a/include/uapi/drm/i915_drm.h b/include/uapi/drm/i915_drm.h > index 35ca528803fd..84c0af77cc1f 100644 > --- a/include/uapi/drm/i915_drm.h > +++ b/include/uapi/drm/i915_drm.h > @@ -166,6 +166,7 @@ enum drm_i915_gem_engine_class { > I915_ENGINE_CLASS_COPY = 1, > I915_ENGINE_CLASS_VIDEO = 2, > I915_ENGINE_CLASS_VIDEO_ENHANCE = 3, > + I915_ENGINE_CLASS_COMPUTE = 4, > > /* should be kept compact */ > > @@ -635,17 +636,8 @@ typedef struct drm_i915_irq_wait { > #define I915_PARAM_HAS_EXEC_FENCE_ARRAY 49 > > /* > - * Query whether every context (both per-file default and user created) is > - * isolated (insofar as HW supports). If this parameter is not true, then > - * freshly created contexts may inherit values from an existing context, > - * rather than default HW values. If true, it also ensures (insofar as HW > - * supports) that all state set by this context will not leak to any other > - * context. > - * > - * As not every engine across every gen support contexts, the returned > - * value reports the support of context isolation for individual engines by > - * returning a bitmask of each engine class set to true if that class supports > - * isolation. > + * Query whether the device can make cross-engine isolation guarantees for > + * all the engines whose default state has been initialised. > */ > #define I915_PARAM_HAS_CONTEXT_ISOLATION 50 > > -- > 2.35.1 > -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch

2 4

[PATCH 1/4] drm: handle kernel fences in drm_gem_plane_helper_prepare_fb v2
by Christian König 05 May '22

05 May '22

drm_gem_plane_helper_prepare_fb() was using drm_atomic_set_fence_for_plane() which ignores all implicit fences when an explicit fence is already set. That's rather unfortunate when the fb still has a kernel fence we need to wait for to avoid presenting garbage on the screen. So instead update the fence in the plane state directly. While at it also take care of all potential GEM objects and not just the first one. Also remove the now unused drm_atomic_set_fence_for_plane() function, new drivers should probably use the atomic helpers directly. v2: improve kerneldoc, use local variable and num_planes, WARN_ON_ONCE on missing planes. Signed-off-by: Christian König <christian.koenig(a)amd.com> Reviewed-by: Daniel Vetter <daniel.vetter(a)ffwll.ch> (v1) Acked-by: Thomas Zimmermann <tzimmermann(a)suse.de> --- drivers/gpu/drm/drm_atomic_uapi.c | 47 ++-------------- drivers/gpu/drm/drm_gem_atomic_helper.c | 73 +++++++++++++++++++------ include/drm/drm_atomic_uapi.h | 2 - include/drm/drm_plane.h | 4 +- 4 files changed, 62 insertions(+), 64 deletions(-) diff --git a/drivers/gpu/drm/drm_atomic_uapi.c b/drivers/gpu/drm/drm_atomic_uapi.c index c6394ba13b24..434f3d4cb8a2 100644 --- a/drivers/gpu/drm/drm_atomic_uapi.c +++ b/drivers/gpu/drm/drm_atomic_uapi.c @@ -254,43 +254,6 @@ drm_atomic_set_fb_for_plane(struct drm_plane_state *plane_state, } EXPORT_SYMBOL(drm_atomic_set_fb_for_plane); -/** - * drm_atomic_set_fence_for_plane - set fence for plane - * @plane_state: atomic state object for the plane - * @fence: dma_fence to use for the plane - * - * Helper to setup the plane_state fence in case it is not set yet. - * By using this drivers doesn't need to worry if the user choose - * implicit or explicit fencing. - * - * This function will not set the fence to the state if it was set - * via explicit fencing interfaces on the atomic ioctl. In that case it will - * drop the reference to the fence as we are not storing it anywhere. - * Otherwise, if &drm_plane_state.fence is not set this function we just set it - * with the received implicit fence. In both cases this function consumes a - * reference for @fence. - * - * This way explicit fencing can be used to overrule implicit fencing, which is - * important to make explicit fencing use-cases work: One example is using one - * buffer for 2 screens with different refresh rates. Implicit fencing will - * clamp rendering to the refresh rate of the slower screen, whereas explicit - * fence allows 2 independent render and display loops on a single buffer. If a - * driver allows obeys both implicit and explicit fences for plane updates, then - * it will break all the benefits of explicit fencing. - */ -void -drm_atomic_set_fence_for_plane(struct drm_plane_state *plane_state, - struct dma_fence *fence) -{ - if (plane_state->fence) { - dma_fence_put(fence); - return; - } - - plane_state->fence = fence; -} -EXPORT_SYMBOL(drm_atomic_set_fence_for_plane); - /** * drm_atomic_set_crtc_for_connector - set CRTC for connector * @conn_state: atomic state object for the connector @@ -1077,10 +1040,10 @@ int drm_atomic_set_property(struct drm_atomic_state *state, * * As a contrast, with implicit fencing the kernel keeps track of any * ongoing rendering, and automatically ensures that the atomic update waits - * for any pending rendering to complete. For shared buffers represented with - * a &struct dma_buf this is tracked in &struct dma_resv. - * Implicit syncing is how Linux traditionally worked (e.g. DRI2/3 on X.org), - * whereas explicit fencing is what Android wants. + * for any pending rendering to complete. This is usually tracked in &struct + * dma_resv which can also contain mandatory kernel fences. Implicit syncing + * is how Linux traditionally worked (e.g. DRI2/3 on X.org), whereas explicit + * fencing is what Android wants. * * "IN_FENCE_FD”: * Use this property to pass a fence that DRM should wait on before @@ -1095,7 +1058,7 @@ int drm_atomic_set_property(struct drm_atomic_state *state, * * On the driver side the fence is stored on the @fence parameter of * &struct drm_plane_state. Drivers which also support implicit fencing - * should set the implicit fence using drm_atomic_set_fence_for_plane(), + * should extract the implicit fence using drm_gem_plane_helper_prepare_fb(), * to make sure there's consistent behaviour between drivers in precedence * of implicit vs. explicit fencing. * diff --git a/drivers/gpu/drm/drm_gem_atomic_helper.c b/drivers/gpu/drm/drm_gem_atomic_helper.c index a6d89aed0bda..a5026f617739 100644 --- a/drivers/gpu/drm/drm_gem_atomic_helper.c +++ b/drivers/gpu/drm/drm_gem_atomic_helper.c @@ -1,6 +1,7 @@ // SPDX-License-Identifier: GPL-2.0-or-later #include <linux/dma-resv.h> +#include <linux/dma-fence-chain.h> #include <drm/drm_atomic_state_helper.h> #include <drm/drm_atomic_uapi.h> @@ -137,29 +138,67 @@ * * This function is the default implementation for GEM drivers of * &drm_plane_helper_funcs.prepare_fb if no callback is provided. - * - * See drm_atomic_set_fence_for_plane() for a discussion of implicit and - * explicit fencing in atomic modeset updates. */ -int drm_gem_plane_helper_prepare_fb(struct drm_plane *plane, struct drm_plane_state *state) +int drm_gem_plane_helper_prepare_fb(struct drm_plane *plane, + struct drm_plane_state *state) { - struct drm_gem_object *obj; - struct dma_fence *fence; + struct dma_fence *fence = dma_fence_get(state->fence); + enum dma_resv_usage usage; + size_t i; int ret; if (!state->fb) return 0; - obj = drm_gem_fb_get_obj(state->fb, 0); - ret = dma_resv_get_singleton(obj->resv, DMA_RESV_USAGE_WRITE, &fence); - if (ret) - return ret; - - /* TODO: drm_atomic_set_fence_for_plane() should be changed to be able - * to handle more fences in general for multiple BOs per fb. + /* + * Only add the kernel fences here if there is already a fence set via + * explicit fencing interfaces on the atomic ioctl. + * + * This way explicit fencing can be used to overrule implicit fencing, + * which is important to make explicit fencing use-cases work: One + * example is using one buffer for 2 screens with different refresh + * rates. Implicit fencing will clamp rendering to the refresh rate of + * the slower screen, whereas explicit fence allows 2 independent + * render and display loops on a single buffer. If a driver allows + * obeys both implicit and explicit fences for plane updates, then it + * will break all the benefits of explicit fencing. */ - drm_atomic_set_fence_for_plane(state, fence); + usage = fence ? DMA_RESV_USAGE_KERNEL : DMA_RESV_USAGE_WRITE; + + for (i = 0; i < state->fb->format->num_planes; ++i) { + struct drm_gem_object *obj = drm_gem_fb_get_obj(state->fb, i); + struct dma_fence *new; + + if (WARN_ON_ONCE(!obj)) + continue; + + ret = dma_resv_get_singleton(obj->resv, usage, &new); + if (ret) + goto error; + + if (new && fence) { + struct dma_fence_chain *chain = dma_fence_chain_alloc(); + + if (!chain) { + ret = -ENOMEM; + goto error; + } + + dma_fence_chain_init(chain, fence, new, 1); + fence = &chain->base; + + } else if (new) { + fence = new; + } + } + + dma_fence_put(state->fence); + state->fence = fence; return 0; + +error: + dma_fence_put(fence); + return ret; } EXPORT_SYMBOL_GPL(drm_gem_plane_helper_prepare_fb); @@ -168,13 +207,13 @@ EXPORT_SYMBOL_GPL(drm_gem_plane_helper_prepare_fb); * @pipe: Simple display pipe * @plane_state: Plane state * - * This function uses drm_gem_plane_helper_prepare_fb() to extract the exclusive fence - * from &drm_gem_object.resv and attaches it to plane state for the atomic + * This function uses drm_gem_plane_helper_prepare_fb() to extract the fences + * from &drm_gem_object.resv and attaches them to the plane state for the atomic * helper to wait on. This is necessary to correctly implement implicit * synchronization for any buffers shared as a struct &dma_buf. Drivers can use * this as their &drm_simple_display_pipe_funcs.prepare_fb callback. * - * See drm_atomic_set_fence_for_plane() for a discussion of implicit and + * See drm_gem_plane_helper_prepare_fb() for a discussion of implicit and * explicit fencing in atomic modeset updates. */ int drm_gem_simple_display_pipe_prepare_fb(struct drm_simple_display_pipe *pipe, diff --git a/include/drm/drm_atomic_uapi.h b/include/drm/drm_atomic_uapi.h index 8cec52ad1277..4c6d39d7bdb2 100644 --- a/include/drm/drm_atomic_uapi.h +++ b/include/drm/drm_atomic_uapi.h @@ -49,8 +49,6 @@ drm_atomic_set_crtc_for_plane(struct drm_plane_state *plane_state, struct drm_crtc *crtc); void drm_atomic_set_fb_for_plane(struct drm_plane_state *plane_state, struct drm_framebuffer *fb); -void drm_atomic_set_fence_for_plane(struct drm_plane_state *plane_state, - struct dma_fence *fence); int __must_check drm_atomic_set_crtc_for_connector(struct drm_connector_state *conn_state, struct drm_crtc *crtc); diff --git a/include/drm/drm_plane.h b/include/drm/drm_plane.h index 2628c7cde2da..89ea54652e87 100644 --- a/include/drm/drm_plane.h +++ b/include/drm/drm_plane.h @@ -74,9 +74,7 @@ struct drm_plane_state { * * Optional fence to wait for before scanning out @fb. The core atomic * code will set this when userspace is using explicit fencing. Do not - * write this field directly for a driver's implicit fence, use - * drm_atomic_set_fence_for_plane() to ensure that an explicit fence is - * preserved. + * write this field directly for a driver's implicit fence. * * Drivers should store any implicit fence in this from their * &drm_plane_helper_funcs.prepare_fb callback. See drm_gem_plane_helper_prepare_fb() -- 2.25.1

4 7

[CI 1/2] drm/i915: Don't use DRM_DEBUG_WARN_ON for unexpected l3bank/mslice config
by Tvrtko Ursulin 05 May '22

05 May '22

From: Tvrtko Ursulin <tvrtko.ursulin(a)intel.com> DRM_DEBUG_WARN_ON should only be used when we are certain CI is guaranteed to exercise a certain code path, so in case of values coming from MMIO reads we cannot be sure CI will have all the possible SKUs and parts. Use drm_warn instead and move logging to init phase while at it. v2: * GEM_WARN_ON in intel_gt_get_valid_steering. Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin(a)intel.com> Cc: Matt Roper <matthew.d.roper(a)intel.com> Cc: Jani Nikula <jani.nikula(a)intel.com> Reviewed-by: Matt Roper <matthew.d.roper(a)intel.com> --- drivers/gpu/drm/i915/gt/intel_gt.c | 15 ++++++++------- 1 file changed, 8 insertions(+), 7 deletions(-) diff --git a/drivers/gpu/drm/i915/gt/intel_gt.c b/drivers/gpu/drm/i915/gt/intel_gt.c index 53307ca0eed0..034182f85501 100644 --- a/drivers/gpu/drm/i915/gt/intel_gt.c +++ b/drivers/gpu/drm/i915/gt/intel_gt.c @@ -153,11 +153,14 @@ int intel_gt_init_mmio(struct intel_gt *gt) * An mslice is unavailable only if both the meml3 for the slice is * disabled *and* all of the DSS in the slice (quadrant) are disabled. */ - if (HAS_MSLICES(i915)) + if (HAS_MSLICES(i915)) { gt->info.mslice_mask = slicemask(gt, GEN_DSS_PER_MSLICE) | (intel_uncore_read(gt->uncore, GEN10_MIRROR_FUSE3) & GEN12_MEML3_EN_MASK); + if (!gt->info.mslice_mask) /* should be impossible! */ + drm_warn(&i915->drm, "mslice mask all zero!\n"); + } if (IS_DG2(i915)) { gt->steering_table[MSLICE] = xehpsdv_mslice_steering_table; @@ -171,6 +174,8 @@ int intel_gt_init_mmio(struct intel_gt *gt) gt->info.l3bank_mask = ~intel_uncore_read(gt->uncore, GEN10_MIRROR_FUSE3) & GEN10_L3BANK_MASK; + if (!gt->info.l3bank_mask) /* should be impossible! */ + drm_warn(&i915->drm, "L3 bank mask is all zero!\n"); } else if (HAS_MSLICES(i915)) { MISSING_CASE(INTEL_INFO(i915)->platform); } @@ -882,24 +887,20 @@ static void intel_gt_get_valid_steering(struct intel_gt *gt, { switch (type) { case L3BANK: - GEM_DEBUG_WARN_ON(!gt->info.l3bank_mask); /* should be impossible! */ - *sliceid = 0; /* unused */ *subsliceid = __ffs(gt->info.l3bank_mask); break; case MSLICE: - GEM_DEBUG_WARN_ON(!gt->info.mslice_mask); /* should be impossible! */ - + GEM_WARN_ON(!HAS_MSLICES(gt->i915)); *sliceid = __ffs(gt->info.mslice_mask); *subsliceid = 0; /* unused */ break; case LNCF: - GEM_DEBUG_WARN_ON(!gt->info.mslice_mask); /* should be impossible! */ - /* * An LNCF is always present if its mslice is present, so we * can safely just steer to LNCF 0 in all cases. */ + GEM_WARN_ON(!HAS_MSLICES(gt->i915)); *sliceid = __ffs(gt->info.mslice_mask) << 1; *subsliceid = 0; /* unused */ break; -- 2.32.0

1 1

[PATCH -next 1/2] drm/i915: Remove duplicated include in intel_sseu.c
by Yang Li 05 May '22

05 May '22

Fix following includecheck warning: ./drivers/gpu/drm/i915/gt/intel_sseu.c: linux/string_helpers.h is included more than once. Reported-by: Abaci Robot <abaci(a)linux.alibaba.com> Signed-off-by: Yang Li <yang.lee(a)linux.alibaba.com> --- drivers/gpu/drm/i915/gt/intel_sseu.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/drivers/gpu/drm/i915/gt/intel_sseu.c b/drivers/gpu/drm/i915/gt/intel_sseu.c index 9881a6790574..fdd25691beda 100644 --- a/drivers/gpu/drm/i915/gt/intel_sseu.c +++ b/drivers/gpu/drm/i915/gt/intel_sseu.c @@ -10,8 +10,6 @@ #include "intel_gt_regs.h" #include "intel_sseu.h" -#include "linux/string_helpers.h" - void intel_sseu_set_info(struct sseu_dev_info *sseu, u8 max_slices, u8 max_subslices, u8 max_eus_per_subslice) { -- 2.20.1.7.g153144c

2 2

[PATCH v4 1/4] dt-bindings: display: simple: Add DataImage FG1001L0DSSWMG01 compatible string
by Philip Oberfichtner 05 May '22

05 May '22

Add DataImage FG1001L0DSSWMG01 10.1" 1280x800 TFT LCD panel compatible string. Signed-off-by: Philip Oberfichtner <pro(a)denx.de> Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski(a)linaro.org> --- Cc: Thierry Reding <thierry.reding(a)gmail.com> Cc: Sam Ravnborg <sam(a)ravnborg.org> Cc: David Airlie <airlied(a)linux.ie> Cc: Daniel Vetter <daniel(a)ffwll.ch> Cc: Rob Herring <robh+dt(a)kernel.org> Cc: Krzysztof Kozlowski <krzk+dt(a)kernel.org> Cc: dri-devel(a)lists.freedesktop.org Cc: devicetree(a)vger.kernel.org Cc: linux-kernel(a)vger.kernel.org Cc: matthias.winker(a)de.bosch.com --- Changes in v4: Acked-by Krzysztof Changes in v3: new --- .../devicetree/bindings/display/panel/panel-simple.yaml | 2 ++ 1 file changed, 2 insertions(+) diff --git a/Documentation/devicetree/bindings/display/panel/panel-simple.yaml b/Documentation/devicetree/bindings/display/panel/panel-simple.yaml index 1eb9dd4f8f58..a6db3eff3b1a 100644 --- a/Documentation/devicetree/bindings/display/panel/panel-simple.yaml +++ b/Documentation/devicetree/bindings/display/panel/panel-simple.yaml @@ -105,6 +105,8 @@ properties: - chunghwa,claa101wb01 # Chunghwa Picture Tubes Ltd. 10.1" WXGA TFT LCD panel - chunghwa,claa101wb03 + # DataImage, Inc. 10.1" WXGA (1280×800) TFT LCD panel + - dataimage,fg1001l0dsswmg01 # DataImage, Inc. 7" WVGA (800x480) TFT LCD panel with 24-bit parallel interface. - dataimage,scf0700c48ggu18 # DLC Display Co. DLC1010GIG 10.1" WXGA TFT LCD Panel -- 2.34.1

1 1

[PATCH] drm/i915: simplify the return expression of i915_driver_open()
by cgel.zte＠gmail.com 05 May '22

05 May '22

From: Minghao Chi <chi.minghao(a)zte.com.cn> Simplify the return expression. Reported-by: Zeal Robot <zealci(a)zte.com.cn> Signed-off-by: Minghao Chi <chi.minghao(a)zte.com.cn> --- drivers/gpu/drm/i915/i915_driver.c | 7 +------ 1 file changed, 1 insertion(+), 6 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_driver.c b/drivers/gpu/drm/i915/i915_driver.c index 09de45d3e274..d11a7445909a 100644 --- a/drivers/gpu/drm/i915/i915_driver.c +++ b/drivers/gpu/drm/i915/i915_driver.c @@ -977,13 +977,8 @@ static void i915_driver_release(struct drm_device *dev) static int i915_driver_open(struct drm_device *dev, struct drm_file *file) { struct drm_i915_private *i915 = to_i915(dev); - int ret; - ret = i915_gem_open(i915, file); - if (ret) - return ret; - - return 0; + return i915_gem_open(i915, file); } /** -- 2.25.1

2 1

[PATCH] drm/todo: Add entry for using kunit in the subsystem
by Javier Martinez Canillas 05 May '22

05 May '22

The Kernel Unit Testing (KUnit) framework provides a common framework for unit tests within the Linux kernel. Having a test suite would allow to identify regressions earlier. Signed-off-by: Javier Martinez Canillas <javierm(a)redhat.com> --- Documentation/gpu/todo.rst | 14 ++++++++++++++ 1 file changed, 14 insertions(+) diff --git a/Documentation/gpu/todo.rst b/Documentation/gpu/todo.rst index 127e76ee0b2d..10bfb50908d1 100644 --- a/Documentation/gpu/todo.rst +++ b/Documentation/gpu/todo.rst @@ -603,6 +603,20 @@ Level: Advanced Better Testing ============== +Add unit tests using the Kernel Unit Testing (KUnit) framework +-------------------------------------------------------------- + +The `KUnit <https://www.kernel.org/doc/html/latest/dev-tools/kunit/index.html>`_ +provides a common framework for unit tests within the Linux kernel. Having a +test suite would allow to identify regressions earlier. + +A good candidate for the first unit tests are the format-conversion helpers in +``drm_format_helper.c``. + +Contact: Javier Martinez Canillas <javierm(a)redhat.com> + +Level: Intermediate + Enable trinity for DRM ---------------------- -- 2.35.1

4 6

[PATCH] drm: drm_gem.h: Add explicit includes for DEFINE_DRM_GEM_FOPS
by Jeffrey Hugo 05 May '22

05 May '22

DEFINE_DRM_GEM_FOPS() references drm functions from other headers. For example drm_open() is defined in drm_file.h and drm_ioctl() is defined in drm_ioctl.h. Since drm_gem.h doesn't include these headers, it relies on an implicit include from the .c file to have included these required headers before DEFINE_DRM_GEM_FOPS() gets used. Relying on these implicit includes can cause build failures for new code that doesn't know about these requirements, and can lead to future problems if the headers ever get restructured as there will be a need to update every downstream file that includes drm_gem.h. Lets fix this explicitly including the required headers in drm_gem.h so that code that includes drm_gem.h does not need to worry about these implicit dependencies. Signed-off-by: Jeffrey Hugo <quic_jhugo(a)quicinc.com> --- include/drm/drm_gem.h | 2 ++ 1 file changed, 2 insertions(+) diff --git a/include/drm/drm_gem.h b/include/drm/drm_gem.h index 9d7c61a..1cbe3d8 100644 --- a/include/drm/drm_gem.h +++ b/include/drm/drm_gem.h @@ -37,6 +37,8 @@ #include <linux/kref.h> #include <linux/dma-resv.h> +#include <drm/drm_file.h> +#include <drm/drm_ioctl.h> #include <drm/drm_vma_manager.h> struct iosys_map; -- 2.7.4

3 4

[PATCH] drm: simplify the return expression of ast_drm_resume()
by cgel.zte＠gmail.com 05 May '22

05 May '22

From: Minghao Chi <chi.minghao(a)zte.com.cn> Simplify the return expression. Reported-by: Zeal Robot <zealci(a)zte.com.cn> Signed-off-by: Minghao Chi <chi.minghao(a)zte.com.cn> --- drivers/gpu/drm/ast/ast_drv.c | 7 +------ 1 file changed, 1 insertion(+), 6 deletions(-) diff --git a/drivers/gpu/drm/ast/ast_drv.c b/drivers/gpu/drm/ast/ast_drv.c index 7465c4f0156a..760b27971557 100644 --- a/drivers/gpu/drm/ast/ast_drv.c +++ b/drivers/gpu/drm/ast/ast_drv.c @@ -159,15 +159,10 @@ static int ast_drm_thaw(struct drm_device *dev) static int ast_drm_resume(struct drm_device *dev) { - int ret; - if (pci_enable_device(to_pci_dev(dev->dev))) return -EIO; - ret = ast_drm_thaw(dev); - if (ret) - return ret; - return 0; + return ast_drm_thaw(dev); } static int ast_pm_suspend(struct device *dev) -- 2.25.1

2 1

[PULL] drm-intel-gt-next
by Tvrtko Ursulin 05 May '22

05 May '22

Hi Dave, Daniel, Here goes the final drm-intel-gt-next PR towards 5.19. A fix for a security issue affecting Tigerlake onwards and a plain fix for a race in VMA handling have landed since the previous pull. Also last two bits of DG2 enablement are included - GuC firmware version has been defined and compute command streamers have been exposed to userspace. Else just a handful of small cleanups and selftest fixes. There are initial Ponte Vecchio definitions but no impact oustside development branch management. Regards, Tvrtko drm-intel-gt-next-2022-05-05: UAPI Changes: - Add kerneldoc for engine class enum (Matt Roper) - Add compute engine ABI (Matt Roper) Driver Changes: - Define GuC firmware version for DG2 (John Harrison) - Clear SET_PREDICATE_RESULT prior to executing the ring (Chris Wilson) - Fix race in __i915_vma_remove_closed (Karol Herbst) - Add register for compute engine's MMIO-based TLB invalidation (Matt Roper) - Xe_HP SDV and DG2 have up to 4 CCS engines (Daniele Ceraolo Spurio) - Add initial Ponte Vecchio definitions (Stuart Summers) - Document the eviction of the Flat-CCS objects (Ramalingam C) - Use existing uncore helper to read gpm_timestamp (Umesh Nerlige Ramappa) - Fix issue with LRI relative addressing (Akeem G Abodunrin) - Skip poisoning SET_PREDICATE_RESULT on dg2 (Chris Wilson) - Optimize the ccs_sz calculation per chunk (Ramalingam C) - Remove superfluous string helper include (Jani Nikula) - Fix assert in i915_ggtt_pin (Tvrtko Ursulin) - Use IOMEM_ERR_PTR() directly (Kefeng Wang) The following changes since commit f15856d7de914595d0daa2c706f53a693b48e228: drm/i915/dg2: add gsc with special gsc bar offsets (2022-04-21 11:34:39 -0700) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm-intel tags/drm-intel-gt-next-2022-05-05 for you to fetch changes up to 1df1c79cbb7ac9bf148930be3418973c76ba8dde: drm/i915: Fix race in __i915_vma_remove_closed (2022-05-04 16:22:13 +0100) ---------------------------------------------------------------- UAPI Changes: - Add kerneldoc for engine class enum (Matt Roper) - Add compute engine ABI (Matt Roper) Driver Changes: - Define GuC firmware version for DG2 (John Harrison) - Clear SET_PREDICATE_RESULT prior to executing the ring (Chris Wilson) - Fix race in __i915_vma_remove_closed (Karol Herbst) - Add register for compute engine's MMIO-based TLB invalidation (Matt Roper) - Xe_HP SDV and DG2 have up to 4 CCS engines (Daniele Ceraolo Spurio) - Add initial Ponte Vecchio definitions (Stuart Summers) - Document the eviction of the Flat-CCS objects (Ramalingam C) - Use existing uncore helper to read gpm_timestamp (Umesh Nerlige Ramappa) - Fix issue with LRI relative addressing (Akeem G Abodunrin) - Skip poisoning SET_PREDICATE_RESULT on dg2 (Chris Wilson) - Optimize the ccs_sz calculation per chunk (Ramalingam C) - Remove superfluous string helper include (Jani Nikula) - Fix assert in i915_ggtt_pin (Tvrtko Ursulin) - Use IOMEM_ERR_PTR() directly (Kefeng Wang) ---------------------------------------------------------------- Akeem G Abodunrin (1): drm/i915/xehpsdv/dg1/tgl: Fix issue with LRI relative addressing Chris Wilson (2): drm/i915/selftests: Skip poisoning SET_PREDICATE_RESULT on dg2 drm/i915/gt: Clear SET_PREDICATE_RESULT prior to executing the ring Daniele Ceraolo Spurio (1): drm/i915: Xe_HP SDV and DG2 have up to 4 CCS engines Jani Nikula (1): drm/i915: remove superfluous string helper include John Harrison (1): drm/i915/dg2: Define GuC firmware version for DG2 Karol Herbst (1): drm/i915: Fix race in __i915_vma_remove_closed Kefeng Wang (1): drm/i915: use IOMEM_ERR_PTR() directly Matt Roper (3): drm/i915/uapi: Add kerneldoc for engine class enum drm/i915/xehp: Add register for compute engine's MMIO-based TLB invalidation drm/i915/xehp: Add compute engine ABI Ramalingam C (2): drm/i915/gt: optimize the ccs_sz calculation per chunk drm/i915/gt: Document the eviction of the Flat-CCS objects Stuart Summers (1): drm/i915/pvc: add initial Ponte Vecchio definitions Tvrtko Ursulin (1): drm/i915: Fix assert in i915_ggtt_pin Umesh Nerlige Ramappa (1): drm/i915/pmu: Use existing uncore helper to read gpm_timestamp drivers/gpu/drm/i915/gt/gen8_engine_cs.c | 54 ++++++++++++++++ drivers/gpu/drm/i915/gt/gen8_engine_cs.h | 7 ++ drivers/gpu/drm/i915/gt/intel_engine_regs.h | 2 + drivers/gpu/drm/i915/gt/intel_engine_user.c | 2 +- .../gpu/drm/i915/gt/intel_execlists_submission.c | 15 +++-- drivers/gpu/drm/i915/gt/intel_gpu_commands.h | 2 + drivers/gpu/drm/i915/gt/intel_gt.c | 1 + drivers/gpu/drm/i915/gt/intel_gt_regs.h | 1 + drivers/gpu/drm/i915/gt/intel_lrc.c | 75 ++++++++++++++++------ drivers/gpu/drm/i915/gt/intel_lrc.h | 5 ++ drivers/gpu/drm/i915/gt/intel_migrate.c | 59 ++++++++--------- drivers/gpu/drm/i915/gt/intel_sseu.c | 2 - drivers/gpu/drm/i915/gt/selftest_lrc.c | 53 ++++++++++++++- drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c | 19 ++---- drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c | 1 + drivers/gpu/drm/i915/i915_drm_client.c | 1 + drivers/gpu/drm/i915/i915_drm_client.h | 2 +- drivers/gpu/drm/i915/i915_drv.h | 2 + drivers/gpu/drm/i915/i915_pci.c | 27 +++++++- drivers/gpu/drm/i915/i915_vma.c | 19 +++--- drivers/gpu/drm/i915/i915_vma.h | 1 - drivers/gpu/drm/i915/intel_device_info.c | 1 + drivers/gpu/drm/i915/intel_device_info.h | 1 + include/uapi/drm/i915_drm.h | 62 ++++++++++++++++-- 24 files changed, 319 insertions(+), 95 deletions(-)

1 0

← Newer
1
...
61
62
63
64
65
66
67
...
74
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

dri-devel May 2022