dri-devel June 2021

dri-devel@lists.freedesktop.org

341 participants
878 discussions

[PATCH 1/3] drm/panel: Add connector_type and bus_format for AUO G104SN02 V2 panel
by Stefan Riedmueller 21 Jun '21

21 Jun '21

The AUO G104SN02 V2 is an LVDS display which supports 6 and 8 bpc PSWG. Add the corresponding connector type and 8 bpc as default bus_format. Signed-off-by: Stefan Riedmueller <s.riedmueller(a)phytec.de> --- drivers/gpu/drm/panel/panel-simple.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/gpu/drm/panel/panel-simple.c b/drivers/gpu/drm/panel/panel-simple.c index 4e2dad314c79..44583d0ed902 100644 --- a/drivers/gpu/drm/panel/panel-simple.c +++ b/drivers/gpu/drm/panel/panel-simple.c @@ -1098,6 +1098,8 @@ static const struct panel_desc auo_g104sn02 = { .width = 211, .height = 158, }, + .bus_format = MEDIA_BUS_FMT_RGB888_1X7X4_SPWG, + .connector_type = DRM_MODE_CONNECTOR_LVDS, }; static const struct drm_display_mode auo_g121ean01_mode = { -- 2.25.1

4 7

[PATCH] drm/i915/eb: Fix pagefault disabling in the first slowpath
by Daniel Vetter 21 Jun '21

21 Jun '21

In commit ebc0808fa2da0548a78e715858024cb81cd732bc Author: Chris Wilson <chris(a)chris-wilson.co.uk> Date: Tue Oct 18 13:02:51 2016 +0100 drm/i915: Restrict pagefault disabling to just around copy_from_user() we entirely missed that there's a slow path call to eb_relocate_entry (or i915_gem_execbuffer_relocate_entry as it was called back then) which was left fully wrapped by pagefault_disable/enable() calls. Previously any issues with blocking calls where handled by the following code: /* we can't wait for rendering with pagefaults disabled */ if (pagefault_disabled() && !object_is_idle(obj)) return -EFAULT; Now at this point the prefaulting was still around, which means in normal applications it was very hard to hit this bug. No idea why the regressions in igts weren't caught. Now this all changed big time with 2 patches merged closely together. First commit 2889caa9232109afc8881f29a2205abeb5709d0c Author: Chris Wilson <chris(a)chris-wilson.co.uk> Date: Fri Jun 16 15:05:19 2017 +0100 drm/i915: Eliminate lots of iterations over the execobjects array removes the prefaulting from the first relocation path, pushing it into the first slowpath (of which this patch added a total of 3 escalation levels). This would have really quickly uncovered the above bug, were it not for immediate adding a duct-tape on top with commit 7dd4f6729f9243bd7046c6f04c107a456bda38eb Author: Chris Wilson <chris(a)chris-wilson.co.uk> Date: Fri Jun 16 15:05:24 2017 +0100 drm/i915: Async GPU relocation processing by pushing all all the relocation patching to the gpu if the buffer was busy, which avoided all the possible blocking calls. The entire slowpath was then furthermore ditched in commit 7dc8f1143778a35b190f9413f228b3cf28f67f8d Author: Chris Wilson <chris(a)chris-wilson.co.uk> Date: Wed Mar 11 16:03:10 2020 +0000 drm/i915/gem: Drop relocation slowpath and resurrected in commit fd1500fcd4420eee06e2c7f3aa6067b78ac05871 Author: Maarten Lankhorst <maarten.lankhorst(a)linux.intel.com> Date: Wed Aug 19 16:08:43 2020 +0200 Revert "drm/i915/gem: Drop relocation slowpath". but this did not further impact what's going on. Since pagefault_disable/enable is an atomic section, any sleeping in there is prohibited, and we definitely do that without gpu relocations since we have to wait for the gpu usage to finish before we can patch up the relocations. Signed-off-by: Daniel Vetter <daniel.vetter(a)intel.com> Cc: Jon Bloomfield <jon.bloomfield(a)intel.com> Cc: Chris Wilson <chris(a)chris-wilson.co.uk> Cc: Maarten Lankhorst <maarten.lankhorst(a)linux.intel.com> Cc: Joonas Lahtinen <joonas.lahtinen(a)linux.intel.com> Cc: Daniel Vetter <daniel.vetter(a)ffwll.ch> Cc: "Thomas Hellström" <thomas.hellstrom(a)linux.intel.com> Cc: Matthew Auld <matthew.auld(a)intel.com> Cc: Lionel Landwerlin <lionel.g.landwerlin(a)intel.com> Cc: Dave Airlie <airlied(a)redhat.com> Cc: Jason Ekstrand <jason(a)jlekstrand.net> --- drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c index 6539b82dda54..7ff2fc3c0b2c 100644 --- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c +++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c @@ -2082,9 +2082,7 @@ static noinline int eb_relocate_parse_slow(struct i915_execbuffer *eb, list_for_each_entry(ev, &eb->relocs, reloc_link) { if (!have_copy) { - pagefault_disable(); err = eb_relocate_vma(eb, ev); - pagefault_enable(); if (err) break; } else { -- 2.32.0.rc2

4 3

drm/i915: __GFP_RETRY_MAYFAIL allocations in stable kernels
by Sergey Senozhatsky 21 Jun '21

21 Jun '21

Hi, We are observing some user-space crashes (sigabort, segfaults etc.) under moderate memory pressure (pretty far from severe pressure) which have one thing in common - restrictive GFP mask in setup_scratch_page(). For instance, (stable 4.19) drivers/gpu/drm/i915/i915_gem_gtt.c (trimmed down version) static int gen8_init_scratch(struct i915_address_space *vm) { setup_scratch_page(vm, __GFP_HIGHMEM); vm->scratch_pt = alloc_pt(vm); vm->scratch_pd = alloc_pd(vm); if (use_4lvl(vm)) { vm->scratch_pdp = alloc_pdp(vm); } } gen8_init_scratch() function puts a rather inconsistent restrictions on mm. Looking at it line by line: setup_scratch_page() uses very restrictive gfp mask: __GFP_HIGHMEM | __GFP_ZERO | __GFP_RETRY_MAYFAIL it doesn't try to reclaim anything and fails almost immediately. alloc_pt() - uses more permissive gfp mask: GFP_KERNEL | __GFP_RETRY_MAYFAIL | __GFP_NOWARN alloc_pd() - likewise: GFP_KERNEL | __GFP_RETRY_MAYFAIL | __GFP_NOWARN alloc_pdp() - very permissive gfp mask: GFP_KERNEL So can all allocations in gen8_init_scratch() use GFP_KERNEL | __GFP_RETRY_MAYFAIL | __GFP_NOWARN ? E.g. --- diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c b/drivers/gpu/drm/i915/i915_gem_gtt.c index a12430187108..e862680b9c93 100644 --- a/drivers/gpu/drm/i915/i915_gem_gtt.c +++ b/drivers/gpu/drm/i915/i915_gem_gtt.c @@ -792,7 +792,7 @@ alloc_pdp(struct i915_address_space *vm) GEM_BUG_ON(!use_4lvl(vm)); - pdp = kzalloc(sizeof(*pdp), GFP_KERNEL); + pdp = kzalloc(sizeof(*pdp), I915_GFP_ALLOW_FAIL); if (!pdp) return ERR_PTR(-ENOMEM); @@ -1262,7 +1262,7 @@ static int gen8_init_scratch(struct i915_address_space *vm) { int ret; - ret = setup_scratch_page(vm, __GFP_HIGHMEM); + ret = setup_scratch_page(vm, GFP_KERNEL | __GFP_HIGHMEM); if (ret) return ret; @@ -1972,7 +1972,7 @@ static int gen6_ppgtt_init_scratch(struct gen6_hw_ppgtt *ppgtt) u32 pde; int ret; - ret = setup_scratch_page(vm, __GFP_HIGHMEM); + ret = setup_scratch_page(vm, GFP_KERNEL | __GFP_HIGHMEM); if (ret) return ret; @@ -3078,7 +3078,7 @@ static int ggtt_probe_common(struct i915_ggtt *ggtt, u64 size) return -ENOMEM; } - ret = setup_scratch_page(&ggtt->vm, GFP_DMA32); + ret = setup_scratch_page(&ggtt->vm, GFP_KERNEL | GFP_DMA32); if (ret) { DRM_ERROR("Scratch setup failed\n"); /* iounmap will also get called at remove, but meh */ --- It's quite similar on stable 5.4 - setup_scratch_page() uses restrictive gfp mask again. --- diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c b/drivers/gpu/drm/i915/i915_gem_gtt.c index f614646ed3f9..99d78b1052df 100644 --- a/drivers/gpu/drm/i915/i915_gem_gtt.c +++ b/drivers/gpu/drm/i915/i915_gem_gtt.c @@ -1378,7 +1378,7 @@ static int gen8_init_scratch(struct i915_address_space *vm) return 0; } - ret = setup_scratch_page(vm, __GFP_HIGHMEM); + ret = setup_scratch_page(vm, GFP_KERNEL | __GFP_HIGHMEM); if (ret) return ret; @@ -1753,7 +1753,7 @@ static int gen6_ppgtt_init_scratch(struct gen6_ppgtt *ppgtt) struct i915_page_directory * const pd = ppgtt->base.pd; int ret; - ret = setup_scratch_page(vm, __GFP_HIGHMEM); + ret = setup_scratch_page(vm, GFP_KERNEL | __GFP_HIGHMEM); if (ret) return ret; @@ -2860,7 +2860,7 @@ static int ggtt_probe_common(struct i915_ggtt *ggtt, u64 size) return -ENOMEM; } - ret = setup_scratch_page(&ggtt->vm, GFP_DMA32); + ret = setup_scratch_page(&ggtt->vm, GFP_KERNEL | GFP_DMA32); if (ret) { DRM_ERROR("Scratch setup failed\n"); /* iounmap will also get called at remove, but meh */ ---

3 4

[PATCH 00/10] drm/panfrost: Misc fixes/improvements
by Boris Brezillon 21 Jun '21

21 Jun '21

Hello, Here's is collection of patches addressing some stability issues. The first patch has been submitted a while ago but was lacking a way to kill in-flight jobs when a context is closed; which is now addressed in patch 10. The rest of those patches are improving fault handling (with some code refactoring in the middle). "drm/panfrost: Do the exception -> string translation using a table" still has a TODO. I basically mapped all exception types to EINVAL since most faults are triggered by invalid job/shaders, but there might be some exceptions that should be translated to something else. Any feedback on that aspect is welcome. Regards, Boris Boris Brezillon (10): drm/panfrost: Make sure MMU context lifetime is not bound to panfrost_priv drm/panfrost: Get rid of the unused JS_STATUS_EVENT_ACTIVE definition drm/panfrost: Drop the pfdev argument passed to panfrost_exception_name() drm/panfrost: Expose exception types to userspace drm/panfrost: Disable the AS on unhandled page faults drm/panfrost: Expose a helper to trigger a GPU reset drm/panfrost: Reset the GPU when the AS_ACTIVE bit is stuck drm/panfrost: Do the exception -> string translation using a table drm/panfrost: Don't reset the GPU on job faults unless we really have to drm/panfrost: Kill in-flight jobs on FD close drivers/gpu/drm/panfrost/panfrost_device.c | 143 +++++++++++------ drivers/gpu/drm/panfrost/panfrost_device.h | 21 ++- drivers/gpu/drm/panfrost/panfrost_drv.c | 50 ++---- drivers/gpu/drm/panfrost/panfrost_gem.c | 20 ++- drivers/gpu/drm/panfrost/panfrost_gpu.c | 2 +- drivers/gpu/drm/panfrost/panfrost_job.c | 74 ++++++--- drivers/gpu/drm/panfrost/panfrost_mmu.c | 173 ++++++++++++++------- drivers/gpu/drm/panfrost/panfrost_mmu.h | 5 +- drivers/gpu/drm/panfrost/panfrost_regs.h | 3 - include/uapi/drm/panfrost_drm.h | 65 ++++++++ 10 files changed, 371 insertions(+), 185 deletions(-) -- 2.31.1

2 11

[PATCH] drm: mxsfb: Use bus_format from the nearest bridge if present
by Marek Vasut 21 Jun '21

21 Jun '21

In case there is a bridge connected to the LCDIF, use bus_format from the bridge, otherwise behave as before and use bus_format from the connector. This way, even if there are multiple bridges in the display pipeline, the LCDIF will use the correct format. Signed-off-by: Marek Vasut <marex(a)denx.de> Cc: Daniel Abrecht <public(a)danielabrecht.ch> Cc: Emil Velikov <emil.l.velikov(a)gmail.com> Cc: Laurent Pinchart <laurent.pinchart(a)ideasonboard.com> Cc: Lucas Stach <l.stach(a)pengutronix.de> Cc: Stefan Agner <stefan(a)agner.ch> --- drivers/gpu/drm/mxsfb/mxsfb_kms.c | 33 +++++++++++++++++++++++-------- 1 file changed, 25 insertions(+), 8 deletions(-) diff --git a/drivers/gpu/drm/mxsfb/mxsfb_kms.c b/drivers/gpu/drm/mxsfb/mxsfb_kms.c index 5bcc06c1ac0b..98d8ba0bae84 100644 --- a/drivers/gpu/drm/mxsfb/mxsfb_kms.c +++ b/drivers/gpu/drm/mxsfb/mxsfb_kms.c @@ -47,16 +47,13 @@ static u32 set_hsync_pulse_width(struct mxsfb_drm_private *mxsfb, u32 val) * Setup the MXSFB registers for decoding the pixels out of the framebuffer and * outputting them on the bus. */ -static void mxsfb_set_formats(struct mxsfb_drm_private *mxsfb) +static void mxsfb_set_formats(struct mxsfb_drm_private *mxsfb, + const u32 bus_format) { struct drm_device *drm = mxsfb->drm; const u32 format = mxsfb->crtc.primary->state->fb->format->format; - u32 bus_format = MEDIA_BUS_FMT_RGB888_1X24; u32 ctrl, ctrl1; - if (mxsfb->connector->display_info.num_bus_formats) - bus_format = mxsfb->connector->display_info.bus_formats[0]; - DRM_DEV_DEBUG_DRIVER(drm->dev, "Using bus_format: 0x%08X\n", bus_format); @@ -222,7 +219,8 @@ static dma_addr_t mxsfb_get_fb_paddr(struct drm_plane *plane) return gem->paddr; } -static void mxsfb_crtc_mode_set_nofb(struct mxsfb_drm_private *mxsfb) +static void mxsfb_crtc_mode_set_nofb(struct mxsfb_drm_private *mxsfb, + const u32 bus_format) { struct drm_device *drm = mxsfb->crtc.dev; struct drm_display_mode *m = &mxsfb->crtc.state->adjusted_mode; @@ -247,7 +245,7 @@ static void mxsfb_crtc_mode_set_nofb(struct mxsfb_drm_private *mxsfb) if (mxsfb->devdata->has_overlay) writel(0, mxsfb->base + LCDC_AS_CTRL); - mxsfb_set_formats(mxsfb); + mxsfb_set_formats(mxsfb, bus_format); clk_set_rate(mxsfb->clk, m->crtc_clock * 1000); @@ -345,7 +343,9 @@ static void mxsfb_crtc_atomic_enable(struct drm_crtc *crtc, struct drm_atomic_state *state) { struct mxsfb_drm_private *mxsfb = to_mxsfb_drm_private(crtc->dev); + struct drm_bridge_state *bridge_state; struct drm_device *drm = mxsfb->drm; + u32 bus_format = 0; dma_addr_t paddr; pm_runtime_get_sync(drm->dev); @@ -353,7 +353,24 @@ static void mxsfb_crtc_atomic_enable(struct drm_crtc *crtc, drm_crtc_vblank_on(crtc); - mxsfb_crtc_mode_set_nofb(mxsfb); + /* If there is a bridge attached to the LCDIF, use its bus format */ + if (mxsfb->bridge && state) { + bridge_state = + drm_atomic_get_new_bridge_state(state, + mxsfb->bridge); + if (bridge_state) + bus_format = bridge_state->input_bus_cfg.format; + } + + /* If there is no bridge, use bus format from connector */ + if (!bus_format && mxsfb->connector->display_info.num_bus_formats) + bus_format = mxsfb->connector->display_info.bus_formats[0]; + + /* If all else fails, default to RGB888_1X24 */ + if (!bus_format) + bus_format = MEDIA_BUS_FMT_RGB888_1X24; + + mxsfb_crtc_mode_set_nofb(mxsfb, bus_format); /* Write cur_buf as well to avoid an initial corrupt frame */ paddr = mxsfb_get_fb_paddr(crtc->primary); -- 2.30.2

3 2

[PATCH v2 1/2] backlight: lm3630a: fix return code of .update_status() callback
by Uwe Kleine-König 21 Jun '21

21 Jun '21

According to <linux/backlight.h> .update_status() is supposed to return 0 on success and a negative error code otherwise. Adapt lm3630a_bank_a_update_status() to actually do it. While touching that also add the error code to the failure message. Signed-off-by: Uwe Kleine-König <u.kleine-koenig(a)pengutronix.de> --- drivers/video/backlight/lm3630a_bl.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/video/backlight/lm3630a_bl.c b/drivers/video/backlight/lm3630a_bl.c index e88a2b0e5904..16a2658a72e1 100644 --- a/drivers/video/backlight/lm3630a_bl.c +++ b/drivers/video/backlight/lm3630a_bl.c @@ -190,7 +190,7 @@ static int lm3630a_bank_a_update_status(struct backlight_device *bl) if ((pwm_ctrl & LM3630A_PWM_BANK_A) != 0) { lm3630a_pwm_ctrl(pchip, bl->props.brightness, bl->props.max_brightness); - return bl->props.brightness; + return 0; } /* disable sleep */ @@ -210,8 +210,8 @@ static int lm3630a_bank_a_update_status(struct backlight_device *bl) return 0; out_i2c_err: - dev_err(pchip->dev, "i2c failed to access\n"); - return bl->props.brightness; + dev_err(pchip->dev, "i2c failed to access (%pe)\n", ERR_PTR(ret)); + return ret; } static int lm3630a_bank_a_get_brightness(struct backlight_device *bl) base-commit: 6efb943b8616ec53a5e444193dccf1af9ad627b5 -- 2.30.2

2 4

[PATCH v6, 0/2] soc: mediatek: mmsys: add mt8192 mmsys support
by Yongqiang Niu 21 Jun '21

21 Jun '21

base 5.13-rc1 Change since v5: - squash ddp component into one patch - add 8192 mmsys compatible data Yongqiang Niu (2): soc: mediatek: mmsys: add comp OVL_2L2/POSTMASK/RDMA4 soc: mediatek: mmsys: Add mt8192 mmsys routing table drivers/soc/mediatek/mt8192-mmsys.h | 68 ++++++++++++++++++++++++++++++++++ drivers/soc/mediatek/mtk-mmsys.c | 11 ++++++ include/linux/soc/mediatek/mtk-mmsys.h | 3 ++ 3 files changed, 82 insertions(+) create mode 100644 drivers/soc/mediatek/mt8192-mmsys.h -- 1.8.1.1.dirty

2 3

[PATCH v4] drm/i915: Document the Virtual Engine uAPI
by Tvrtko Ursulin 21 Jun '21

21 Jun '21

From: Tvrtko Ursulin <tvrtko.ursulin(a)intel.com> A little bit of documentation covering the topics of engine discovery, context engine maps and virtual engines. It is not very detailed but supposed to be a starting point of giving a brief high level overview of general principles and intended use cases. v2: * Have the text in uapi header and link from there. v4: * Link from driver-uapi.rst. Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin(a)intel.com> Cc: Daniel Vetter <daniel(a)ffwll.ch> --- Documentation/gpu/driver-uapi.rst | 21 ++++ include/uapi/drm/i915_drm.h | 188 ++++++++++++++++++++++++++++++ 2 files changed, 209 insertions(+) diff --git a/Documentation/gpu/driver-uapi.rst b/Documentation/gpu/driver-uapi.rst index 4411e6919a3d..27d0fbe33e87 100644 --- a/Documentation/gpu/driver-uapi.rst +++ b/Documentation/gpu/driver-uapi.rst @@ -5,4 +5,25 @@ DRM Driver uAPI drm/i915 uAPI ============= +Engine Discovery uAPI +--------------------- + +.. kernel-doc:: include/uapi/drm/i915_drm.h + :doc: Engine Discovery uAPI + +Context Engine Map uAPI +----------------------- + +.. kernel-doc:: include/uapi/drm/i915_drm.h + :doc: Context Engine Map uAPI + +Virtual Engine uAPI +------------------- + +.. kernel-doc:: include/uapi/drm/i915_drm.h + :doc: Virtual Engine uAPI + +i915_drm.h +---------- .. kernel-doc:: include/uapi/drm/i915_drm.h + :internal: diff --git a/include/uapi/drm/i915_drm.h b/include/uapi/drm/i915_drm.h index a1cb4aa035a9..2f70c48567c0 100644 --- a/include/uapi/drm/i915_drm.h +++ b/include/uapi/drm/i915_drm.h @@ -1806,6 +1806,69 @@ struct drm_i915_gem_context_param_sseu { __u32 rsvd; }; +/** + * DOC: Virtual Engine uAPI + * + * Virtual engine is a concept where userspace is able to configure a set of + * physical engines, submit a batch buffer, and let the driver execute it on any + * engine from the set as it sees fit. + * + * This is primarily useful on parts which have multiple instances of a same + * class engine, like for example GT3+ Skylake parts with their two VCS engines. + * + * For instance userspace can enumerate all engines of a certain class using the + * previously described `Engine Discovery uAPI`_. After that userspace can + * create a GEM context with a placeholder slot for the virtual engine (using + * `I915_ENGINE_CLASS_INVALID` and `I915_ENGINE_CLASS_INVALID_NONE` for class + * and instance respectively) and finally using the + * `I915_CONTEXT_ENGINES_EXT_LOAD_BALANCE` extension place a virtual engine in + * the same reserved slot. + * + * Example of creating a virtual engine and submitting a batch buffer to it: + * + * .. code-block:: C + * + * I915_DEFINE_CONTEXT_ENGINES_LOAD_BALANCE(virtual, 2) = { + * .base.name = I915_CONTEXT_ENGINES_EXT_LOAD_BALANCE, + * .engine_index = 0, // Place this virtual engine into engine map slot 0 + * .num_siblings = 2, + * .engines = { { I915_ENGINE_CLASS_VIDEO, 0 }, + * { I915_ENGINE_CLASS_VIDEO, 1 }, }, + * }; + * I915_DEFINE_CONTEXT_PARAM_ENGINES(engines, 1) = { + * .engines = { { I915_ENGINE_CLASS_INVALID, + * I915_ENGINE_CLASS_INVALID_NONE } }, + * .extensions = to_user_pointer(&virtual), // Chains after load_balance extension + * }; + * struct drm_i915_gem_context_create_ext_setparam p_engines = { + * .base = { + * .name = I915_CONTEXT_CREATE_EXT_SETPARAM, + * }, + * .param = { + * .param = I915_CONTEXT_PARAM_ENGINES, + * .value = to_user_pointer(&engines), + * .size = sizeof(engines), + * }, + * }; + * struct drm_i915_gem_context_create_ext create = { + * .flags = I915_CONTEXT_CREATE_FLAGS_USE_EXTENSIONS, + * .extensions = to_user_pointer(&p_engines); + * }; + * + * ctx_id = gem_context_create_ext(drm_fd, &create); + * + * // Now we have created a GEM context with its engine map containing a + * // single virtual engine. Submissions to this slot can go either to + * // vcs0 or vcs1, depending on the load balancing algorithm used inside + * // the driver. The load balancing is dynamic from one batch buffer to + * // another and transparent to userspace. + * + * ... + * execbuf.rsvd1 = ctx_id; + * execbuf.flags = 0; // Submits to index 0 which is the virtual engine + * gem_execbuf(drm_fd, &execbuf); + */ + /* * i915_context_engines_load_balance: * @@ -1882,6 +1945,61 @@ struct i915_context_engines_bond { struct i915_engine_class_instance engines[N__]; \ } __attribute__((packed)) name__ +/** + * DOC: Context Engine Map uAPI + * + * Context engine map is a new way of addressing engines when submitting batch- + * buffers, replacing the existing way of using identifiers like `I915_EXEC_BLT` + * inside the flags field of `struct drm_i915_gem_execbuffer2`. + * + * To use it created GEM contexts need to be configured with a list of engines + * the user is intending to submit to. This is accomplished using the + * `I915_CONTEXT_PARAM_ENGINES` parameter and `struct + * i915_context_param_engines`. + * + * For such contexts the `I915_EXEC_RING_MASK` field becomes an index into the + * configured map. + * + * Example of creating such context and submitting against it: + * + * .. code-block:: C + * + * I915_DEFINE_CONTEXT_PARAM_ENGINES(engines, 2) = { + * .engines = { { I915_ENGINE_CLASS_RENDER, 0 }, + * { I915_ENGINE_CLASS_COPY, 0 } } + * }; + * struct drm_i915_gem_context_create_ext_setparam p_engines = { + * .base = { + * .name = I915_CONTEXT_CREATE_EXT_SETPARAM, + * }, + * .param = { + * .param = I915_CONTEXT_PARAM_ENGINES, + * .value = to_user_pointer(&engines), + * .size = sizeof(engines), + * }, + * }; + * struct drm_i915_gem_context_create_ext create = { + * .flags = I915_CONTEXT_CREATE_FLAGS_USE_EXTENSIONS, + * .extensions = to_user_pointer(&p_engines); + * }; + * + * ctx_id = gem_context_create_ext(drm_fd, &create); + * + * // We have now created a GEM context with two engines in the map: + * // Index 0 points to rcs0 while index 1 points to bcs0. Other engines + * // will not be accessible from this context. + * + * ... + * execbuf.rsvd1 = ctx_id; + * execbuf.flags = 0; // Submits to index 0, which is rcs0 for this context + * gem_execbuf(drm_fd, &execbuf); + * + * ... + * execbuf.rsvd1 = ctx_id; + * execbuf.flags = 1; // Submits to index 0, which is bcs0 for this context + * gem_execbuf(drm_fd, &execbuf); + */ + struct i915_context_param_engines { __u64 extensions; /* linked chain of extension blocks, 0 terminates */ #define I915_CONTEXT_ENGINES_EXT_LOAD_BALANCE 0 /* see i915_context_engines_load_balance */ @@ -2375,6 +2493,76 @@ struct drm_i915_query_topology_info { __u8 data[]; }; +/** + * DOC: Engine Discovery uAPI + * + * Engine discovery uAPI is a way of enumerating physical engines present in a + * GPU associated with an open i915 DRM file descriptor. This supersedes the old + * way of using `DRM_IOCTL_I915_GETPARAM` and engine identifiers like + * `I915_PARAM_HAS_BLT`. + * + * The need for this interface came starting with Icelake and newer GPUs, which + * started to establish a pattern of having multiple engines of a same class, + * where not all instances were always completely functionally equivalent. + * + * Entry point for this uapi is `DRM_IOCTL_I915_QUERY` with the + * `DRM_I915_QUERY_ENGINE_INFO` as the queried item id. + * + * Example for getting the list of engines: + * + * .. code-block:: C + * + * struct drm_i915_query_engine_info *info; + * struct drm_i915_query_item item = { + * .query_id = DRM_I915_QUERY_ENGINE_INFO; + * }; + * struct drm_i915_query query = { + * .num_items = 1, + * .items_ptr = (uintptr_t)&item, + * }; + * int err, i; + * + * // First query the size of the blob we need, this needs to be large + * // enough to hold our array of engines. The kernel will fill out the + * // item.length for us, which is the number of bytes we need. + * // + * // Alternatively a large buffer can be allocated straight away enabling + * // querying in one pass, in which case item.length should contain the + * // length of the provided buffer. + * err = ioctl(fd, DRM_IOCTL_I915_QUERY, &query); + * if (err) ... + * + * info = calloc(1, item.length); + * // Now that we allocated the required number of bytes, we call the ioctl + * // again, this time with the data_ptr pointing to our newly allocated + * // blob, which the kernel can then populate with info on all engines. + * item.data_ptr = (uintptr_t)&info, + * + * err = ioctl(fd, DRM_IOCTL_I915_QUERY, &query); + * if (err) ... + * + * // We can now access each engine in the array + * for (i = 0; i < info->num_engines; i++) { + * struct drm_i915_engine_info einfo = info->engines[i]; + * u16 class = einfo.engine.class; + * u16 instance = einfo.engine.instance; + * .... + * } + * + * free(info); + * + * Each of the enumerated engines, apart from being defined by its class and + * instance (see `struct i915_engine_class_instance`), also can have flags and + * capabilities defined as documented in i915_drm.h. + * + * For instance video engines which support HEVC encoding will have the + * `I915_VIDEO_CLASS_CAPABILITY_HEVC` capability bit set. + * + * Engine discovery only fully comes to its own when combined with the new way + * of addressing engines when submitting batch buffers using contexts with + * engine maps configured. + */ + /** * struct drm_i915_engine_info * -- 2.30.2

2 2

[PATCH v2] drm/mediatek: force hsa hbp hfp packets multiple of lanenum to avoid screen shift
by Jitao Shi 21 Jun '21

21 Jun '21

The bridge chip "ANX7625" requires the packets on lanes to aligne at the end, or ANX7625 will shift the screen. Signed-off-by: Jitao Shi <jitao.shi(a)mediatek.com> --- drivers/gpu/drm/mediatek/mtk_dsi.c | 13 +++++++++++++ 1 file changed, 13 insertions(+) diff --git a/drivers/gpu/drm/mediatek/mtk_dsi.c b/drivers/gpu/drm/mediatek/mtk_dsi.c index ae403c67cbd9..4735e0092ffe 100644 --- a/drivers/gpu/drm/mediatek/mtk_dsi.c +++ b/drivers/gpu/drm/mediatek/mtk_dsi.c @@ -194,6 +194,8 @@ struct mtk_dsi { struct clk *hs_clk; u32 data_rate; + /* force dsi line end without dsi_null data */ + bool force_dsi_end_without_null; unsigned long mode_flags; enum mipi_dsi_pixel_format format; @@ -499,6 +501,13 @@ static void mtk_dsi_config_vdo_timing(struct mtk_dsi *dsi) DRM_WARN("HFP + HBP less than d-phy, FPS will under 60Hz\n"); } + if (dsi->force_dsi_end_without_null) { + horizontal_sync_active_byte = roundup(horizontal_sync_active_byte, dsi->lanes) - 2; + horizontal_frontporch_byte = roundup(horizontal_frontporch_byte, dsi->lanes) - 2; + horizontal_backporch_byte = roundup(horizontal_backporch_byte, dsi->lanes) - 2; + horizontal_backporch_byte -= (vm->hactive * dsi_tmp_buf_bpp + 2) % dsi->lanes; + } + writel(horizontal_sync_active_byte, dsi->regs + DSI_HSA_WC); writel(horizontal_backporch_byte, dsi->regs + DSI_HBP_WC); writel(horizontal_frontporch_byte, dsi->regs + DSI_HFP_WC); @@ -1095,6 +1104,10 @@ static int mtk_dsi_probe(struct platform_device *pdev) dsi->bridge.of_node = dev->of_node; dsi->bridge.type = DRM_MODE_CONNECTOR_DSI; + if (dsi->next_bridge) + dsi->force_dsi_end_without_null = of_property_read_bool(dsi->next_bridge->of_node, + "force_dsi_end_without_null"); + drm_bridge_add(&dsi->bridge); ret = component_add(&pdev->dev, &mtk_dsi_component_ops); -- 2.25.1

2 1

[PATCH v3] Documentation: gpu: Mention the requirements for new properties
by Maxime Ripard 21 Jun '21

21 Jun '21

New KMS properties come with a bunch of requirements to avoid each driver from running their own, inconsistent, set of properties, eventually leading to issues like property conflicts, inconsistencies between drivers and semantics, etc. Let's document what we expect. Cc: Alexandre Belloni <alexandre.belloni(a)bootlin.com> Cc: Alexandre Torgue <alexandre.torgue(a)foss.st.com> Cc: Alex Deucher <alexander.deucher(a)amd.com> Cc: Alison Wang <alison.wang(a)nxp.com> Cc: Alyssa Rosenzweig <alyssa.rosenzweig(a)collabora.com> Cc: Andrew Jeffery <andrew(a)aj.id.au> Cc: Andrzej Hajda <a.hajda(a)samsung.com> Cc: Anitha Chrisanthus <anitha.chrisanthus(a)intel.com> Cc: Benjamin Gaignard <benjamin.gaignard(a)linaro.org> Cc: Ben Skeggs <bskeggs(a)redhat.com> Cc: Boris Brezillon <bbrezillon(a)kernel.org> Cc: Brian Starkey <brian.starkey(a)arm.com> Cc: Chen Feng <puck.chen(a)hisilicon.com> Cc: Chen-Yu Tsai <wens(a)csie.org> Cc: Christian Gmeiner <christian.gmeiner(a)gmail.com> Cc: "Christian König" <christian.koenig(a)amd.com> Cc: Chun-Kuang Hu <chunkuang.hu(a)kernel.org> Cc: Edmund Dea <edmund.j.dea(a)intel.com> Cc: Eric Anholt <eric(a)anholt.net> Cc: Fabio Estevam <festevam(a)gmail.com> Cc: Gerd Hoffmann <kraxel(a)redhat.com> Cc: Haneen Mohammed <hamohammed.sa(a)gmail.com> Cc: Hans de Goede <hdegoede(a)redhat.com> Cc: "Heiko Stübner" <heiko(a)sntech.de> Cc: Huang Rui <ray.huang(a)amd.com> Cc: Hyun Kwon <hyun.kwon(a)xilinx.com> Cc: Inki Dae <inki.dae(a)samsung.com> Cc: Jani Nikula <jani.nikula(a)linux.intel.com> Cc: Jernej Skrabec <jernej.skrabec(a)siol.net> Cc: Jerome Brunet <jbrunet(a)baylibre.com> Cc: Joel Stanley <joel(a)jms.id.au> Cc: John Stultz <john.stultz(a)linaro.org> Cc: Jonas Karlman <jonas(a)kwiboo.se> Cc: Jonathan Hunter <jonathanh(a)nvidia.com> Cc: Joonas Lahtinen <joonas.lahtinen(a)linux.intel.com> Cc: Joonyoung Shim <jy0922.shim(a)samsung.com> Cc: Jyri Sarha <jyri.sarha(a)iki.fi> Cc: Kevin Hilman <khilman(a)baylibre.com> Cc: Kieran Bingham <kieran.bingham+renesas(a)ideasonboard.com> Cc: Krzysztof Kozlowski <krzysztof.kozlowski(a)canonical.com> Cc: Kyungmin Park <kyungmin.park(a)samsung.com> Cc: Laurent Pinchart <Laurent.pinchart(a)ideasonboard.com> Cc: Linus Walleij <linus.walleij(a)linaro.org> Cc: Liviu Dudau <liviu.dudau(a)arm.com> Cc: Lucas Stach <l.stach(a)pengutronix.de> Cc: Ludovic Desroches <ludovic.desroches(a)microchip.com> Cc: Marek Vasut <marex(a)denx.de> Cc: Martin Blumenstingl <martin.blumenstingl(a)googlemail.com> Cc: Matthias Brugger <matthias.bgg(a)gmail.com> Cc: Maxime Coquelin <mcoquelin.stm32(a)gmail.com> Cc: Maxime Ripard <mripard(a)kernel.org> Cc: Melissa Wen <melissa.srw(a)gmail.com> Cc: Neil Armstrong <narmstrong(a)baylibre.com> Cc: Nicolas Ferre <nicolas.ferre(a)microchip.com> Cc: "Noralf Trønnes" <noralf(a)tronnes.org> Cc: NXP Linux Team <linux-imx(a)nxp.com> Cc: Oleksandr Andrushchenko <oleksandr_andrushchenko(a)epam.com> Cc: Patrik Jakobsson <patrik.r.jakobsson(a)gmail.com> Cc: Paul Cercueil <paul(a)crapouillou.net> Cc: Pengutronix Kernel Team <kernel(a)pengutronix.de> Cc: Philippe Cornu <philippe.cornu(a)foss.st.com> Cc: Philipp Zabel <p.zabel(a)pengutronix.de> Cc: Qiang Yu <yuq825(a)gmail.com> Cc: Rob Clark <robdclark(a)gmail.com> Cc: Robert Foss <robert.foss(a)linaro.org> Cc: Rob Herring <robh(a)kernel.org> Cc: Rodrigo Siqueira <rodrigosiqueiramelo(a)gmail.com> Cc: Rodrigo Vivi <rodrigo.vivi(a)intel.com> Cc: Roland Scheidegger <sroland(a)vmware.com> Cc: Russell King <linux(a)armlinux.org.uk> Cc: Sam Ravnborg <sam(a)ravnborg.org> Cc: Sandy Huang <hjc(a)rock-chips.com> Cc: Sascha Hauer <s.hauer(a)pengutronix.de> Cc: Sean Paul <sean(a)poorly.run> Cc: Seung-Woo Kim <sw0312.kim(a)samsung.com> Cc: Shawn Guo <shawnguo(a)kernel.org> Cc: Stefan Agner <stefan(a)agner.ch> Cc: Steven Price <steven.price(a)arm.com> Cc: Sumit Semwal <sumit.semwal(a)linaro.org> Cc: Thierry Reding <thierry.reding(a)gmail.com> Cc: Tian Tao <tiantao6(a)hisilicon.com> Cc: Tomeu Vizoso <tomeu.vizoso(a)collabora.com> Cc: Tomi Valkeinen <tomba(a)kernel.org> Cc: VMware Graphics <linux-graphics-maintainer(a)vmware.com> Cc: Xinliang Liu <xinliang.liu(a)linaro.org> Cc: Xinwei Kong <kong.kongxinwei(a)hisilicon.com> Cc: Yannick Fertre <yannick.fertre(a)foss.st.com> Cc: Zack Rusin <zackr(a)vmware.com> Reviewed-by: Daniel Vetter <daniel.vetter(a)ffwll.ch> Signed-off-by: Maxime Ripard <maxime(a)cerno.tech> --- Changes from v2: - Take into account the feedback from Laurent and Lidiu to no longer force generic properties, but prefix vendor-specific properties with the vendor name Changes from v1: - Typos and wording reported by Daniel and Alex --- Documentation/gpu/drm-kms.rst | 27 +++++++++++++++++++++++++++ 1 file changed, 27 insertions(+) diff --git a/Documentation/gpu/drm-kms.rst b/Documentation/gpu/drm-kms.rst index 87e5023e3f55..bbe254dca635 100644 --- a/Documentation/gpu/drm-kms.rst +++ b/Documentation/gpu/drm-kms.rst @@ -463,6 +463,33 @@ KMS Properties This section of the documentation is primarily aimed at user-space developers. For the driver APIs, see the other sections. +Requirements +------------ + +KMS drivers might need to add extra properties to support new features. +Each new property introduced in a driver need to meet a few +requirements, in addition to the one mentioned above.: + +- Before the introduction of any vendor-specific properties, they must + be first checked against the generic ones to avoid any conflict or + redundancy. + +- Vendor-specific properties must be prefixed by the vendor's name, + following the syntax "$vendor:$property". + +- Generic properties must be standardized, with some documentation to + describe how the property can be used. + +- Generic properties must provide a generic helper in the core code to + register that property on the object it attaches to. + +- Generic properties content must be decoded by the core and provided in + the object's associated state structure. That includes anything + drivers might want to precompute, like :c:type:`struct drm_clip_rect + <drm_clip_rect>` for planes. + +- An IGT test should be submitted. + Property Types and Blob Property Support ---------------------------------------- -- 2.31.1

10 32

← Newer
1
...
35
36
37
38
39
40
41
...
88
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

dri-devel June 2021