dri-devel September 2021

dri-devel@lists.freedesktop.org

348 participants
817 discussions

[PATCH v2 13/52] dt-bindings: display: aa104xd12: Remove unused vcc-supply
by Maxime Ripard 03 Sep '21

03 Sep '21

The Mitsubishi AA140XD12 Device Tree Binding was requiring a vcc-supply property. However, neither the existing device trees using that binding, nor the driver were actually using that property which is also redundant with power-supply. Let's just drop it. Cc: dri-devel(a)lists.freedesktop.org Cc: Laurent Pinchart <laurent.pinchart(a)ideasonboard.com> Cc: Sam Ravnborg <sam(a)ravnborg.org> Cc: Thierry Reding <thierry.reding(a)gmail.com> Signed-off-by: Maxime Ripard <maxime(a)cerno.tech> --- .../bindings/display/panel/mitsubishi,aa104xd12.yaml | 5 ----- 1 file changed, 5 deletions(-) diff --git a/Documentation/devicetree/bindings/display/panel/mitsubishi,aa104xd12.yaml b/Documentation/devicetree/bindings/display/panel/mitsubishi,aa104xd12.yaml index b5e7ee230fa6..b595edd58bbb 100644 --- a/Documentation/devicetree/bindings/display/panel/mitsubishi,aa104xd12.yaml +++ b/Documentation/devicetree/bindings/display/panel/mitsubishi,aa104xd12.yaml @@ -19,9 +19,6 @@ properties: - const: mitsubishi,aa104xd12 - {} # panel-lvds, but not listed here to avoid false select - vcc-supply: - description: Reference to the regulator powering the panel VCC pins. - data-mapping: const: jeida-24 @@ -38,14 +35,12 @@ additionalProperties: false required: - compatible - - vcc-supply examples: - |+ panel { compatible = "mitsubishi,aa104xd12", "panel-lvds"; - vcc-supply = <&vcc_3v3>; width-mm = <210>; height-mm = <158>; -- 2.31.1

2 1

[PATCH v2 10/52] dt-bindings: display: Move idk-1110wr to panel-lvds
by Maxime Ripard 03 Sep '21

03 Sep '21

The Advantech IDK-2121WR Device Tree binding doesn't really add any useful content that is not already present in the panel-lvds binding aside from a requirement on the data-mapping. Let's move it to the generic panel-lvds binding Cc: dri-devel(a)lists.freedesktop.org Cc: Laurent Pinchart <laurent.pinchart(a)ideasonboard.com> Cc: Sam Ravnborg <sam(a)ravnborg.org> Cc: Thierry Reding <thierry.reding(a)gmail.com> Signed-off-by: Maxime Ripard <maxime(a)cerno.tech> --- .../display/panel/advantech,idk-1110wr.yaml | 69 ------------------- .../bindings/display/panel/lvds.yaml | 22 ++++-- 2 files changed, 15 insertions(+), 76 deletions(-) delete mode 100644 Documentation/devicetree/bindings/display/panel/advantech,idk-1110wr.yaml diff --git a/Documentation/devicetree/bindings/display/panel/advantech,idk-1110wr.yaml b/Documentation/devicetree/bindings/display/panel/advantech,idk-1110wr.yaml deleted file mode 100644 index 93878c2cd370..000000000000 --- a/Documentation/devicetree/bindings/display/panel/advantech,idk-1110wr.yaml +++ /dev/null @@ -1,69 +0,0 @@ -# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) -%YAML 1.2 ---- -$id: http://devicetree.org/schemas/display/panel/advantech,idk-1110wr.yaml# -$schema: http://devicetree.org/meta-schemas/core.yaml# - -title: Advantech IDK-1110WR 10.1" WSVGA LVDS Display Panel - -maintainers: - - Lad Prabhakar <prabhakar.mahadev-lad.rj(a)bp.renesas.com> - - Thierry Reding <thierry.reding(a)gmail.com> - -allOf: - - $ref: lvds.yaml# - -properties: - compatible: - items: - - const: advantech,idk-1110wr - - {} # panel-lvds, but not listed here to avoid false select - - data-mapping: - const: jeida-24 - - width-mm: - const: 223 - - height-mm: - const: 125 - - panel-timing: true - port: true - -additionalProperties: false - -required: - - compatible - -examples: - - |+ - panel { - compatible = "advantech,idk-1110wr", "panel-lvds"; - - width-mm = <223>; - height-mm = <125>; - - data-mapping = "jeida-24"; - - panel-timing { - /* 1024x600 @60Hz */ - clock-frequency = <51200000>; - hactive = <1024>; - vactive = <600>; - hsync-len = <240>; - hfront-porch = <40>; - hback-porch = <40>; - vsync-len = <10>; - vfront-porch = <15>; - vback-porch = <10>; - }; - - port { - panel_in: endpoint { - remote-endpoint = <&lvds_encoder>; - }; - }; - }; - -... diff --git a/Documentation/devicetree/bindings/display/panel/lvds.yaml b/Documentation/devicetree/bindings/display/panel/lvds.yaml index 49460c9dceea..e4e49e06f302 100644 --- a/Documentation/devicetree/bindings/display/panel/lvds.yaml +++ b/Documentation/devicetree/bindings/display/panel/lvds.yaml @@ -28,15 +28,23 @@ description: |+ allOf: - $ref: panel-common.yaml# + - if: + properties: + compatible: + contains: + const: advantech,idk-1110wr + + then: + properties: + data-mapping: + const: jeida-24 properties: compatible: - contains: - const: panel-lvds - description: - Shall contain "panel-lvds" in addition to a mandatory panel-specific - compatible string defined in individual panel bindings. The "panel-lvds" - value shall never be used on its own. + items: + - enum: + - advantech,idk-1110wr + - const: panel-lvds data-mapping: enum: @@ -112,6 +120,6 @@ oneOf: - required: - ports -additionalProperties: true +unevaluatedProperties: false ... -- 2.31.1

2 1

[PATCH 0/3] dma-buf: Add missing dependencies on DMA_SHARED_BUFFER
by Geert Uytterhoeven 03 Sep '21

03 Sep '21

Hi Sumit, Christian, This patch series adds missing dependencies on DMA_SHARED_BUFFER to various options of DMA-BUF, and drops a bogus select. As drivers/dma-buf/Kconfig contains interleaved options that select or depend on DMA_SHARED_BUFFER, they can't be wrapped inside a big "if DMA_SHARED_BUFFER / endif" block. Thanks! Geert Uytterhoeven (3): dma-buf: DMABUF_MOVE_NOTIFY should depend on DMA_SHARED_BUFFER dma-buf: DMABUF_DEBUG should depend on DMA_SHARED_BUFFER dma-buf: DMABUF_SYSFS_STATS should depend on DMA_SHARED_BUFFER drivers/dma-buf/Kconfig | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) -- 2.25.1 Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert(a)linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds

2 4

[PATCH] drm/i915/gtt: add some flushing for the 64K GTT path
by Matthew Auld 03 Sep '21

03 Sep '21

If we need to mark the PDE as operating in 64K GTT mode, we should be paranoid and flush the extra writes, like we already do for the PTEs. On some platforms the clflush can apparently add the just the right amount of magical delay to force the GPU to see the updated entry. Signed-off-by: Matthew Auld <matthew.auld(a)intel.com> Cc: Mika Kuoppala <mika.kuoppala(a)linux.intel.com> --- drivers/gpu/drm/i915/gt/gen8_ppgtt.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/gpu/drm/i915/gt/gen8_ppgtt.c b/drivers/gpu/drm/i915/gt/gen8_ppgtt.c index 6e0e52eeb87a..6a5af995f5b1 100644 --- a/drivers/gpu/drm/i915/gt/gen8_ppgtt.c +++ b/drivers/gpu/drm/i915/gt/gen8_ppgtt.c @@ -548,6 +548,7 @@ static void gen8_ppgtt_insert_huge(struct i915_vma *vma, I915_GTT_PAGE_SIZE_2M)))) { vaddr = px_vaddr(pd); vaddr[maybe_64K] |= GEN8_PDE_IPS_64K; + clflush_cache_range(vaddr, PAGE_SIZE); page_size = I915_GTT_PAGE_SIZE_64K; /* @@ -568,6 +569,7 @@ static void gen8_ppgtt_insert_huge(struct i915_vma *vma, for (i = 1; i < index; i += 16) memset64(vaddr + i, encode, 15); + clflush_cache_range(vaddr, PAGE_SIZE); } } -- 2.26.3

2 1

[PATCH 01/11] drm/i915: Release i915_gem_context from a worker
by Daniel Vetter 03 Sep '21

03 Sep '21

The only reason for this really is the i915_gem_engines->fence callback engines_notify(), which exists purely as a fairly funky reference counting scheme for that. Otherwise all other callers are from process context, and generally fairly benign locking context. Unfortunately untangling that requires some major surgery, and we have a few i915_gem_context reference counting bugs that need fixing, and they blow in the current hardirq calling context, so we need a stop-gap measure. Put a FIXME comment in when this should be removable again. 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_context.c | 13 +++++++++++-- drivers/gpu/drm/i915/gem/i915_gem_context_types.h | 12 ++++++++++++ 2 files changed, 23 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c b/drivers/gpu/drm/i915/gem/i915_gem_context.c index fd169cf2f75a..051bc357ff65 100644 --- a/drivers/gpu/drm/i915/gem/i915_gem_context.c +++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c @@ -986,9 +986,10 @@ static struct i915_gem_engines *user_engines(struct i915_gem_context *ctx, return err; } -void i915_gem_context_release(struct kref *ref) +static void i915_gem_context_release_work(struct work_struct *work) { - struct i915_gem_context *ctx = container_of(ref, typeof(*ctx), ref); + struct i915_gem_context *ctx = container_of(work, typeof(*ctx), + release_work); trace_i915_context_free(ctx); GEM_BUG_ON(!i915_gem_context_is_closed(ctx)); @@ -1002,6 +1003,13 @@ void i915_gem_context_release(struct kref *ref) kfree_rcu(ctx, rcu); } +void i915_gem_context_release(struct kref *ref) +{ + struct i915_gem_context *ctx = container_of(ref, typeof(*ctx), ref); + + queue_work(ctx->i915->wq, &ctx->release_work); +} + static inline struct i915_gem_engines * __context_engines_static(const struct i915_gem_context *ctx) { @@ -1303,6 +1311,7 @@ i915_gem_create_context(struct drm_i915_private *i915, ctx->sched = pc->sched; mutex_init(&ctx->mutex); INIT_LIST_HEAD(&ctx->link); + INIT_WORK(&ctx->release_work, i915_gem_context_release_work); spin_lock_init(&ctx->stale.lock); INIT_LIST_HEAD(&ctx->stale.engines); diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context_types.h b/drivers/gpu/drm/i915/gem/i915_gem_context_types.h index 94c03a97cb77..0c38789bd4a8 100644 --- a/drivers/gpu/drm/i915/gem/i915_gem_context_types.h +++ b/drivers/gpu/drm/i915/gem/i915_gem_context_types.h @@ -288,6 +288,18 @@ struct i915_gem_context { */ struct kref ref; + /** + * @release_work: + * + * Work item for deferred cleanup, since i915_gem_context_put() tends to + * be called from hardirq context. + * + * FIXME: The only real reason for this is &i915_gem_engines.fence, all + * other callers are from process context and need at most some mild + * shuffling to pull the i915_gem_context_put() call out of a spinlock. + */ + struct work_struct release_work; + /** * @rcu: rcu_head for deferred freeing. */ -- 2.32.0

4 22

[PULL] drm-misc-next-fixes
by Maarten Lankhorst 03 Sep '21

03 Sep '21

drm-misc-next-fixes-2021-09-03: drm-misc-next-fixes for v5.15: - Fix ttm_bo_move_memcpy() when ttm_resource is subclassed. - Small fixes to panfrost, mgag200, vc4. - Small ttm compilation fixes. The following changes since commit 2819cf0e7dbe45a2bccf2f6c60fe6a27b299cc3e: Merge tag 'drm-misc-next-2021-08-12' of git://anongit.freedesktop.org/drm/drm-misc into drm-next (2021-08-16 12:57:33 +1000) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm-misc tags/drm-misc-next-fixes-2021-09-03 for you to fetch changes up to efcefc7127290e7e9fa98dea029163ad8eda8fb3: drm/ttm: Fix ttm_bo_move_memcpy() for subclassed struct ttm_resource (2021-08-31 10:48:26 +0200) ---------------------------------------------------------------- drm-misc-next-fixes for v5.15: - Fix ttm_bo_move_memcpy() when ttm_resource is subclassed. - Small fixes to panfrost, mgag200, vc4. - Small ttm compilation fixes. ---------------------------------------------------------------- Alyssa Rosenzweig (3): drm/panfrost: Simplify lock_region calculation drm/panfrost: Use u64 for size in lock_region drm/panfrost: Clamp lock region to Bifrost minimum Colin Ian King (1): drm/mgag200: Fix uninitialized variable delta Jason Ekstrand (2): drm/ttm: ttm_bo_device is now ttm_device drm/ttm: Include pagemap.h from ttm_tt.h Jiapeng Chong (1): drm/vc4: hdmi: make vc4_hdmi_codec_pdata static Thomas Hellström (1): drm/ttm: Fix ttm_bo_move_memcpy() for subclassed struct ttm_resource Documentation/gpu/drm-mm.rst | 2 +- drivers/gpu/drm/mgag200/mgag200_pll.c | 1 + drivers/gpu/drm/panfrost/panfrost_mmu.c | 31 +++++++++++-------------------- drivers/gpu/drm/panfrost/panfrost_regs.h | 2 ++ drivers/gpu/drm/ttm/ttm_bo_util.c | 7 +++---- drivers/gpu/drm/ttm/ttm_tt.c | 1 - drivers/gpu/drm/vc4/vc4_hdmi.c | 2 +- include/drm/ttm/ttm_tt.h | 3 ++- 8 files changed, 21 insertions(+), 28 deletions(-)

1 0

Re: [PATCH v4] drm: Improve the output_poll_changed description
by Daniel Vetter 03 Sep '21

03 Sep '21

On Fri, Sep 03, 2021 at 11:24:02AM +0800, ZhiJie.Zhang wrote: > From: zhangzhijie <zhangzhijie(a)loongson.cn> > > this callback was used by drm_kms_helper_hotplug_event() > > V2: (Thanks for Daniel's suggestions) > - remove the FIXME below.since with the drm_client > - infrastructure and the generic fbdev emulation we've > - resolved this all very neatly now. > > V3: Add comments that This hook is deprecated > - new implementation methods instead of this hook > > v4: used by drm_kms_helper_hotplug_event() > - drm_fb_helper_hotplug_changed() is not found > instead by drm_kms_helper_hotplug_event() > > Signed-off-by: ZhiJie.Zhang <zhangzhijie(a)loongson.cn> Applied to drm-misc-next, thanks for the patch. -Daniel > --- > include/drm/drm_mode_config.h | 13 ++++++------- > 1 file changed, 6 insertions(+), 7 deletions(-) > > diff --git a/include/drm/drm_mode_config.h b/include/drm/drm_mode_config.h > index 1ddf7783fdf7..48b7de80daf5 100644 > --- a/include/drm/drm_mode_config.h > +++ b/include/drm/drm_mode_config.h > @@ -103,14 +103,13 @@ struct drm_mode_config_funcs { > * Callback used by helpers to inform the driver of output configuration > * changes. > * > - * Drivers implementing fbdev emulation with the helpers can call > - * drm_fb_helper_hotplug_changed from this hook to inform the fbdev > - * helper of output changes. > + * Drivers implementing fbdev emulation use drm_kms_helper_hotplug_event() > + * to call this hook to inform the fbdev helper of output changes. > * > - * FIXME: > - * > - * Except that there's no vtable for device-level helper callbacks > - * there's no reason this is a core function. > + * This hook is deprecated, drivers should instead use > + * drm_fbdev_generic_setup() which takes care of any necessary > + * hotplug event forwarding already without further involvement by > + * the driver. > */ > void (*output_poll_changed)(struct drm_device *dev); > > -- > 2.33.0 > -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch

1 0

[PATCH] drm/panfrost: Calculate lock region size correctly
by Steven Price 03 Sep '21

03 Sep '21

It turns out that when locking a region, the region must be a naturally aligned power of 2. The upshot of this is that if the desired region crosses a 'large boundary' the region size must be increased significantly to ensure that the locked region completely covers the desired region. Previous calculations (including in kbase for the proprietary driver) failed to take this into account. Since it's known that the lock region must be naturally aligned we can compute the required size by looking at the highest bit position which changes between the start/end of the lock region (subtracting 1 from the end because the end address is exclusive). The start address is then aligned based on the size (this is technically unnecessary as the hardware will ignore these bits, but the spec advises to do this "to avoid confusion"). Signed-off-by: Steven Price <steven.price(a)arm.com> --- See previous discussion[1] for more details. This bug also existed in the 'kbase' driver, so it's unlikely to actually hit very often. This patch is based on drm-misc-next-fixes as it builds on top of Alyssa's changes to lock_region. [1] https://lore.kernel.org/dri-devel/6fe675c4-d22b-22da-ba3c-f6d33419b9ed@arm.… drivers/gpu/drm/panfrost/panfrost_mmu.c | 33 +++++++++++++++++++------ 1 file changed, 26 insertions(+), 7 deletions(-) diff --git a/drivers/gpu/drm/panfrost/panfrost_mmu.c b/drivers/gpu/drm/panfrost/panfrost_mmu.c index dfe5f1d29763..afec15bb3db5 100644 --- a/drivers/gpu/drm/panfrost/panfrost_mmu.c +++ b/drivers/gpu/drm/panfrost/panfrost_mmu.c @@ -58,17 +58,36 @@ static int write_cmd(struct panfrost_device *pfdev, u32 as_nr, u32 cmd) } static void lock_region(struct panfrost_device *pfdev, u32 as_nr, - u64 iova, u64 size) + u64 region_start, u64 size) { u8 region_width; - u64 region = iova & PAGE_MASK; + u64 region; + u64 region_size; + u64 region_end = region_start + size; - /* The size is encoded as ceil(log2) minus(1), which may be calculated - * with fls. The size must be clamped to hardware bounds. + if (!size) + return; + + /* + * The locked region is a naturally aligned power of 2 block encoded as + * log2 minus(1). + * Calculate the desired start/end and look for the highest bit which + * differs. The smallest naturally aligned block must include this bit + * change the desired region starts with this bit (and subsequent bits) + * zeroed and ends with the bit (and subsequent bits) set to one. + * */ - size = max_t(u64, size, AS_LOCK_REGION_MIN_SIZE); - region_width = fls64(size - 1) - 1; - region |= region_width; + region_size = region_start ^ (region_end - 1); + region_width = max(fls64(region_size), + const_ilog2(AS_LOCK_REGION_MIN_SIZE)) - 1; + + /* + * Mask off the low bits of region_start (which would be ignored by + * the hardware anyway) + */ + region_start &= GENMASK_ULL(63, region_width); + + region = region_width | region_start; /* Lock the region that needs to be updated */ mmu_write(pfdev, AS_LOCKADDR_LO(as_nr), region & 0xFFFFFFFFUL); -- 2.30.2

2 2

[PATCH 1/2] drm/ttm: Fix a deadlock if the target BO is not idle during swap
by Pan, Xinhui 03 Sep '21

03 Sep '21

The ret value might be -EBUSY, caller will think lru lock is still locked but actually NOT. So return -ENOSPC instead. Otherwise we hit list corruption. ttm_bo_cleanup_refs might fail too if BO is not idle. If we return 0, caller(ttm_tt_populate -> ttm_global_swapout ->ttm_device_swapout) will be stuck as we actually did not free any BO memory. This usually happens when the fence is not signaled for a long time. Signed-off-by: xinhui pan <xinhui.pan(a)amd.com> --- drivers/gpu/drm/ttm/ttm_bo.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c index 1fedd0eb67ba..f1367107925b 100644 --- a/drivers/gpu/drm/ttm/ttm_bo.c +++ b/drivers/gpu/drm/ttm/ttm_bo.c @@ -1159,9 +1159,9 @@ int ttm_bo_swapout(struct ttm_buffer_object *bo, struct ttm_operation_ctx *ctx, } if (bo->deleted) { - ttm_bo_cleanup_refs(bo, false, false, locked); + ret = ttm_bo_cleanup_refs(bo, false, false, locked); ttm_bo_put(bo); - return 0; + return ret == -EBUSY ? -ENOSPC : ret; } ttm_bo_move_to_pinned(bo); @@ -1215,7 +1215,7 @@ int ttm_bo_swapout(struct ttm_buffer_object *bo, struct ttm_operation_ctx *ctx, if (locked) dma_resv_unlock(bo->base.resv); ttm_bo_put(bo); - return ret; + return ret == -EBUSY ? -ENOSPC : ret; } void ttm_bo_tt_destroy(struct ttm_buffer_object *bo) -- 2.25.1

3 2

Harden the dma-fence documentation a bit more
by Christian König 03 Sep '21

03 Sep '21

Hi guys, while it is in most cases technically possible to not have a reference to the dma_fence when adding a callback it is usually a good idea to make sure to always have a reference anyway. Otherwise we can indeed see cases where this doesn't really work as intended like for example in the now fixed EPOLL code. Regards, Christian.

2 5

← Newer
1
...
74
75
76
77
78
79
80
81
82
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

dri-devel September 2021