dri-devel July 2021

dri-devel@lists.freedesktop.org

321 participants
829 discussions

[PATCH -next] drm/bochs: Fix missing pci_disable_device() on error in bochs_pci_probe()
by Yang Yingliang 14 Jul '21

14 Jul '21

Fix the missing pci_disable_device() before return from bochs_pci_probe() in the error handling case. Reported-by: Hulk Robot <hulkci(a)huawei.com> Signed-off-by: Yang Yingliang <yangyingliang(a)huawei.com> --- drivers/gpu/drm/tiny/bochs.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpu/drm/tiny/bochs.c b/drivers/gpu/drm/tiny/bochs.c index a2cfecfa8556..74832b9d3eae 100644 --- a/drivers/gpu/drm/tiny/bochs.c +++ b/drivers/gpu/drm/tiny/bochs.c @@ -666,6 +666,7 @@ static int bochs_pci_probe(struct pci_dev *pdev, const struct pci_device_id *ent return ret; err_free_dev: + pci_disable_device(pdev); drm_dev_put(dev); return ret; } -- 2.25.1

2 1

[PATCH] dma-buf: add kernel count for dma_buf
by guangming.cao＠mediatek.com 14 Jul '21

14 Jul '21

From: Guangming Cao <Guangming.Cao(a)mediatek.com> Add a refcount for kernel to prevent UAF(Use After Free) issue. We can assume a case like below: 1. kernel space alloc dma_buf(file count = 1) 2. kernel use dma_buf to get fd(file count = 1) 3. userspace use fd to do mapping (file count = 2) 4. kernel call dma_buf_put (file count = 1) 5. userpsace close buffer fd(file count = 0) 6. at this time, buffer is released, but va is valid!! So we still can read/write buffer via mmap va, it maybe cause memory leak, or kernel exception. And also, if we use "ls -ll" to watch corresponding process fd link info, it also will cause kernel exception. Another case: Using dma_buf_fd to generate more than 1 fd, because dma_buf_fd will not increase file count, thus, when close the second fd, it maybe occurs error. Solution: Add a kernel count for dma_buf, and make sure the file count of dma_buf.file hold by kernel is 1. Notes: For this solution, kref couldn't work because kernel ref maybe added from 0, but kref don't allow it. Signed-off-by: Guangming Cao <Guangming.Cao(a)mediatek.com> --- drivers/dma-buf/dma-buf.c | 23 +++++++++++++++++++---- include/linux/dma-buf.h | 6 ++++-- 2 files changed, 23 insertions(+), 6 deletions(-) diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c index 511fe0d217a0..04ee92aac8b9 100644 --- a/drivers/dma-buf/dma-buf.c +++ b/drivers/dma-buf/dma-buf.c @@ -62,6 +62,7 @@ static void dma_buf_release(struct dentry *dentry) if (unlikely(!dmabuf)) return; + WARN_ON(atomic64_read(&dmabuf->kernel_ref)); BUG_ON(dmabuf->vmapping_counter); /* @@ -555,6 +556,7 @@ struct dma_buf *dma_buf_export(const struct dma_buf_export_info *exp_info) goto err_module; } + atomic64_set(&dmabuf->kernel_ref, 1); dmabuf->priv = exp_info->priv; dmabuf->ops = exp_info->ops; dmabuf->size = exp_info->size; @@ -617,6 +619,9 @@ int dma_buf_fd(struct dma_buf *dmabuf, int flags) fd_install(fd, dmabuf->file); + /* Add file cnt for each new fd */ + get_file(dmabuf->file); + return fd; } EXPORT_SYMBOL_GPL(dma_buf_fd); @@ -626,12 +631,13 @@ EXPORT_SYMBOL_GPL(dma_buf_fd); * @fd: [in] fd associated with the struct dma_buf to be returned * * On success, returns the struct dma_buf associated with an fd; uses - * file's refcounting done by fget to increase refcount. returns ERR_PTR - * otherwise. + * dmabuf's ref refcounting done by kref_get to increase refcount. + * Returns ERR_PTR otherwise. */ struct dma_buf *dma_buf_get(int fd) { struct file *file; + struct dma_buf *dmabuf; file = fget(fd); @@ -643,7 +649,12 @@ struct dma_buf *dma_buf_get(int fd) return ERR_PTR(-EINVAL); } - return file->private_data; + dmabuf = file->private_data; + /* replace file count increase as ref increase for kernel user */ + get_dma_buf(dmabuf); + fput(file); + + return dmabuf; } EXPORT_SYMBOL_GPL(dma_buf_get); @@ -662,7 +673,11 @@ void dma_buf_put(struct dma_buf *dmabuf) if (WARN_ON(!dmabuf || !dmabuf->file)) return; - fput(dmabuf->file); + if (WARN_ON(!atomic64_read(&dmabuf->kernel_ref))) + return; + + if (!atomic64_dec_return(&dmabuf->kernel_ref)) + fput(dmabuf->file); } EXPORT_SYMBOL_GPL(dma_buf_put); diff --git a/include/linux/dma-buf.h b/include/linux/dma-buf.h index efdc56b9d95f..bc790cb028eb 100644 --- a/include/linux/dma-buf.h +++ b/include/linux/dma-buf.h @@ -308,6 +308,7 @@ struct dma_buf_ops { struct dma_buf { size_t size; struct file *file; + atomic64_t kernel_ref; struct list_head attachments; const struct dma_buf_ops *ops; struct mutex lock; @@ -436,7 +437,7 @@ struct dma_buf_export_info { .owner = THIS_MODULE } /** - * get_dma_buf - convenience wrapper for get_file. + * get_dma_buf - increase a kernel ref of dma-buf * @dmabuf: [in] pointer to dma_buf * * Increments the reference count on the dma-buf, needed in case of drivers @@ -446,7 +447,8 @@ struct dma_buf_export_info { */ static inline void get_dma_buf(struct dma_buf *dmabuf) { - get_file(dmabuf->file); + if (atomic64_inc_return(&dmabuf->kernel_ref) == 1) + get_file(dmabuf->file); } /** -- 2.17.1

3 2

[PATCH v1 1/1] drm: bridge: Mark mode_fixup deprecated
by Sam Ravnborg 14 Jul '21

14 Jul '21

Make it obvious that mode_fixup is deprecated and new drivers shall use atomic_check. Signed-off-by: Sam Ravnborg <sam(a)ravnborg.org> Cc: Laurent Pinchart <laurent.pinchart(a)ideasonboard.com> Cc: Andrzej Hajda <a.hajda(a)samsung.com> Cc: Maarten Lankhorst <maarten.lankhorst(a)linux.intel.com> Cc: Maxime Ripard <mripard(a)kernel.org> Cc: Thomas Zimmermann <tzimmermann(a)suse.de> Cc: David Airlie <airlied(a)linux.ie> Cc: Daniel Vetter <daniel(a)ffwll.ch> --- include/drm/drm_bridge.h | 3 +++ 1 file changed, 3 insertions(+) diff --git a/include/drm/drm_bridge.h b/include/drm/drm_bridge.h index 46bdfa48c413..668f14234459 100644 --- a/include/drm/drm_bridge.h +++ b/include/drm/drm_bridge.h @@ -136,6 +136,9 @@ struct drm_bridge_funcs { * * NOTE: * + * This is deprecated, do not use! + * New drivers shall use &drm_bridge_funcs.atomic_check. + * * This function is called in the check phase of atomic modesets, which * can be aborted for any reason (including on userspace's request to * just check whether a configuration would be possible). Drivers MUST -- 2.30.2

3 2

[PATCH v1 0/4] Mainline imx6 based SKOV boards
by Oleksij Rempel 14 Jul '21

14 Jul '21

Mainline imx6 based DTs for SKOV A/S boards Oleksij Rempel (3): dt-bindings: display: simple: add some Logic Technologies and Multi-Inno panels dt-bindings: vendor-prefixes: Add an entry for SKOV A/S dt-bindings: arm: fsl: add SKOV imx6q and imx6dl based boards Sam Ravnborg (1): ARM: dts: add SKOV imx6q and imx6dl based boards .../devicetree/bindings/arm/fsl.yaml | 5 + .../bindings/display/panel/panel-simple.yaml | 6 + .../devicetree/bindings/vendor-prefixes.yaml | 2 + arch/arm/boot/dts/Makefile | 5 + arch/arm/boot/dts/imx6dl-skov-revc-lt2.dts | 13 + arch/arm/boot/dts/imx6dl-skov-revc-lt6.dts | 108 ++++ arch/arm/boot/dts/imx6q-skov-revc-lt2.dts | 36 ++ arch/arm/boot/dts/imx6q-skov-revc-lt6.dts | 128 +++++ .../dts/imx6q-skov-reve-mi1010ait-1cp1.dts | 127 +++++ arch/arm/boot/dts/imx6qdl-skov-cpu-revc.dtsi | 58 +++ arch/arm/boot/dts/imx6qdl-skov-cpu.dtsi | 476 ++++++++++++++++++ 11 files changed, 964 insertions(+) create mode 100644 arch/arm/boot/dts/imx6dl-skov-revc-lt2.dts create mode 100644 arch/arm/boot/dts/imx6dl-skov-revc-lt6.dts create mode 100644 arch/arm/boot/dts/imx6q-skov-revc-lt2.dts create mode 100644 arch/arm/boot/dts/imx6q-skov-revc-lt6.dts create mode 100644 arch/arm/boot/dts/imx6q-skov-reve-mi1010ait-1cp1.dts create mode 100644 arch/arm/boot/dts/imx6qdl-skov-cpu-revc.dtsi create mode 100644 arch/arm/boot/dts/imx6qdl-skov-cpu.dtsi -- 2.29.2

4 9

Re: [PATCH v15 06/12] swiotlb: Use is_swiotlb_force_bounce for swiotlb data bouncing
by Konrad Rzeszutek Wilk 14 Jul '21

14 Jul '21

On Tue, Jul 06, 2021 at 04:05:13PM +0200, Christoph Hellwig wrote: > On Tue, Jul 06, 2021 at 03:01:04PM +0100, Robin Murphy wrote: > > FWIW I was pondering the question of whether to do something along those > > lines or just scrap the default assignment entirely, so since I hadn't got > > round to saying that I've gone ahead and hacked up the alternative > > (similarly untested) for comparison :) > > > > TBH I'm still not sure which one I prefer... > > Claire did implement something like your suggestion originally, but > I don't really like it as it doesn't scale for adding multiple global > pools, e.g. for the 64-bit addressable one for the various encrypted > secure guest schemes. Couple of things: - I am not pushing to Linus the Claire's patchset until we have a resolution on this. I hope you all agree that is a sensible way forward as much as I hate doing that. - I like Robin's fix as it is simplest looking. Would love to see if it does fix the problem. - Christopher - we can always add multiple pools as the next milestone and just focus on this feature getting tested extensively during this release. - Would it be worth (for future or maybe in another tiny fix) to also add a printk in swiotlb when we de-allocate the buffer so when someone looks through the `dmesg` it becomes much easier to diagnose issues?

3 4

Re: [Intel-gfx] [PATCH] drm/i915/gt: Fix -EDEADLK handling regression
by Daniel Vetter 13 Jul '21

13 Jul '21

On Thu, Jul 1, 2021 at 9:07 AM Maarten Lankhorst <maarten.lankhorst(a)linux.intel.com> wrote: > Op 30-06-2021 om 18:44 schreef Ville Syrjala: > > From: Ville Syrjälä <ville.syrjala(a)linux.intel.com> > > > > The conversion to ww mutexes failed to address the fence code which > > already returns -EDEADLK when we run out of fences. Ww mutexes on > > the other hand treat -EDEADLK as an internal errno value indicating > > a need to restart the operation due to a deadlock. So now when the > > fence code returns -EDEADLK the higher level code erroneously > > restarts everything instead of returning the error to userspace > > as is expected. > > > > To remedy this let's switch the fence code to use a different errno > > value for this. -ENOBUFS seems like a semi-reasonable unique choice. > > Apart from igt the only user of this I could find is sna, and even > > there all we do is dump the current fence registers from debugfs > > into the X server log. So no user visible functionality is affected. > > If we really cared about preserving this we could of course convert > > back to -EDEADLK higher up, but doesn't seem like that's worth > > the hassle here. > > > > Not quite sure which commit specifically broke this, but I'll > > just attribute it to the general gem ww mutex work. > > > > Cc: stable(a)vger.kernel.org > > Cc: Maarten Lankhorst <maarten.lankhorst(a)linux.intel.com> > > Cc: Thomas Hellström <thomas.hellstrom(a)intel.com> > > Testcase: igt/gem_pread/exhaustion > > Testcase: igt/gem_pwrite/basic-exhaustion > > Testcase: igt/gem_fenced_exec_thrash/too-many-fences > > Fixes: 80f0b679d6f0 ("drm/i915: Add an implementation for i915_gem_ww_ctx locking, v2.") > > Signed-off-by: Ville Syrjälä <ville.syrjala(a)linux.intel.com> > > --- > > drivers/gpu/drm/i915/gt/intel_ggtt_fencing.c | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/drivers/gpu/drm/i915/gt/intel_ggtt_fencing.c b/drivers/gpu/drm/i915/gt/intel_ggtt_fencing.c > > index cac7f3f44642..f8948de72036 100644 > > --- a/drivers/gpu/drm/i915/gt/intel_ggtt_fencing.c > > +++ b/drivers/gpu/drm/i915/gt/intel_ggtt_fencing.c > > @@ -348,7 +348,7 @@ static struct i915_fence_reg *fence_find(struct i915_ggtt *ggtt) > > if (intel_has_pending_fb_unpin(ggtt->vm.i915)) > > return ERR_PTR(-EAGAIN); > > > > - return ERR_PTR(-EDEADLK); > > + return ERR_PTR(-ENOBUFS); > > } > > > > int __i915_vma_pin_fence(struct i915_vma *vma) > > Makes sense.. > > Reviewed-by: Maarten Lankhorst <maarten.lankhorst(a)linux.intel.com> > > Is it a slightly more reent commit? Might probably be the part that converts execbuffer to use ww locks. - please cc: dri-devel on anything gem/gt related. - this should probably be ENOSPC or something like that for at least a seeming retention of errno consistentcy: https://dri.freedesktop.org/docs/drm/gpu/drm-uapi.html#recommended-ioctl-re… Cheers, Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch

3 3

[PATCH] dim/drm-misc: Add rule to not push patches with issues
by Daniel Vetter 13 Jul '21

13 Jul '21

We kinda left this out, and I like the wording from the drm-intel side, so add that. Motivated by a discussion with Christian. Cc: Christian König <christian.koenig(a)amd.com> Cc: Maarten Lankhorst <maarten.lankhorst(a)linux.intel.com> Cc: Maxime Ripard <mripard(a)kernel.org> Cc: Thomas Zimmermann <tzimmermann(a)suse.de> Signed-off-by: Daniel Vetter <daniel.vetter(a)intel.com> --- committer-drm-misc.rst | 3 +++ 1 file changed, 3 insertions(+) diff --git a/committer-drm-misc.rst b/committer-drm-misc.rst index 9497a5d26a9d..110ca8b0525e 100644 --- a/committer-drm-misc.rst +++ b/committer-drm-misc.rst @@ -21,6 +21,9 @@ Merge Criteria Right now the only hard merge criteria are: +* There must not be open issues or unresolved or conflicting feedback from + anyone. Clear them up first. Defer to maintainers as needed. + * Patch is properly reviewed or at least Ack, i.e. don't just push your own stuff directly. This rule holds even more for bugfix patches - it would be embarrassing if the bugfix contains a small gotcha that review would have -- 2.32.0

4 4

[PATCH] video: fbdev: kyrofb: fix a DoS bug by restricting user input
by Zheyu Ma 13 Jul '21

13 Jul '21

The user can pass in any value to the driver through the 'ioctl' interface. The driver dost not check, which may cause DoS bugs. Fix this by checking if the divisor is 0 The following log reveals it: divide error: 0000 [#1] PREEMPT SMP KASAN PTI RIP: 0010:SetOverlayViewPort+0x133/0x5f0 drivers/video/fbdev/kyro/STG4000OverlayDevice.c:476 Call Trace: kyro_dev_overlay_viewport_set drivers/video/fbdev/kyro/fbdev.c:378 [inline] kyrofb_ioctl+0x2eb/0x330 drivers/video/fbdev/kyro/fbdev.c:603 do_fb_ioctl+0x1f3/0x700 drivers/video/fbdev/core/fbmem.c:1171 fb_ioctl+0xeb/0x130 drivers/video/fbdev/core/fbmem.c:1185 vfs_ioctl fs/ioctl.c:48 [inline] __do_sys_ioctl fs/ioctl.c:753 [inline] __se_sys_ioctl fs/ioctl.c:739 [inline] __x64_sys_ioctl+0x19b/0x220 fs/ioctl.c:739 do_syscall_64+0x32/0x80 arch/x86/entry/common.c:46 entry_SYSCALL_64_after_hwframe+0x44/0xae Signed-off-by: Zheyu Ma <zheyuma97(a)gmail.com> --- drivers/video/fbdev/kyro/STG4000OverlayDevice.c | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/drivers/video/fbdev/kyro/STG4000OverlayDevice.c b/drivers/video/fbdev/kyro/STG4000OverlayDevice.c index 9fde0e3b69ec..29d692fe5e75 100644 --- a/drivers/video/fbdev/kyro/STG4000OverlayDevice.c +++ b/drivers/video/fbdev/kyro/STG4000OverlayDevice.c @@ -407,6 +407,9 @@ int SetOverlayViewPort(volatile STG4000REG __iomem *pSTGReg, ulVertDecFactor = 1; } + if ((ulDest + 1) == 0) + return -EINVAL; + ulDacYScale = ((ulSrc - 1) * 2048) / (ulDest + 1); tmp = STG_READ_REG(DACOverlayVtDec); /* Decimation */ @@ -471,6 +474,9 @@ int SetOverlayViewPort(volatile STG4000REG __iomem *pSTGReg, */ ulScaleLeft = ulSrcLeft; + if ((ulRight - ulLeft + 2) == 0) + return -EINVAL; + /* shift fxscale until it is in the range of the scaler */ ulhDecim = 0; ulScale = (((ulSrcRight - ulSrcLeft) - 1) << (11 - ulhDecim)) / (ulRight - ulLeft + 2); -- 2.17.6

2 1

[RFC] drm: return int error code from mode_fixup
by Grace An 13 Jul '21

13 Jul '21

When CONFIG_PROVE_LOCKING is defined, the kernel randomly injects -EDEADLK errors for all the ww_mutex. This results in drm_atomic_get_private_obj_state randomly returning -EDEADLK. However, the mode_fixup functions do not propagate these error codes and return false, causing the atomic commit to fail with -EINVAL instead of retrying. Change encoder, crtc, and bridge mode_fixup functions to return an int instead of a boolean to indicate success or failure. If any of these functions fail, the mode_fixup function now returns the provided integer error code instead of -EINVAL. This change needs modifications across drivers, but before submitting the entire change, we want to get feedback on this RFC. Signed-off-by: Grace An <gracan(a)codeaurora.org> --- drivers/gpu/drm/drm_atomic_helper.c | 8 ++++---- drivers/gpu/drm/drm_bridge.c | 4 ++-- include/drm/drm_bridge.h | 2 +- include/drm/drm_modeset_helper_vtables.h | 4 ++-- 4 files changed, 9 insertions(+), 9 deletions(-) diff --git a/drivers/gpu/drm/drm_atomic_helper.c b/drivers/gpu/drm/drm_atomic_helper.c index f2b3e28..d75f09a 100644 --- a/drivers/gpu/drm/drm_atomic_helper.c +++ b/drivers/gpu/drm/drm_atomic_helper.c @@ -457,10 +457,10 @@ mode_fixup(struct drm_atomic_state *state) } else if (funcs && funcs->mode_fixup) { ret = funcs->mode_fixup(encoder, &new_crtc_state->mode, &new_crtc_state->adjusted_mode); - if (!ret) { + if (ret) { DRM_DEBUG_ATOMIC("[ENCODER:%d:%s] fixup failed\n", encoder->base.id, encoder->name); - return -EINVAL; + return ret; } } } @@ -481,10 +481,10 @@ mode_fixup(struct drm_atomic_state *state) ret = funcs->mode_fixup(crtc, &new_crtc_state->mode, &new_crtc_state->adjusted_mode); - if (!ret) { + if (ret) { DRM_DEBUG_ATOMIC("[CRTC:%d:%s] fixup failed\n", crtc->base.id, crtc->name); - return -EINVAL; + return ret; } } diff --git a/drivers/gpu/drm/drm_bridge.c b/drivers/gpu/drm/drm_bridge.c index 64f0eff..3ad16b5 100644 --- a/drivers/gpu/drm/drm_bridge.c +++ b/drivers/gpu/drm/drm_bridge.c @@ -736,9 +736,9 @@ static int drm_atomic_bridge_check(struct drm_bridge *bridge, if (ret) return ret; } else if (bridge->funcs->mode_fixup) { - if (!bridge->funcs->mode_fixup(bridge, &crtc_state->mode, + if (bridge->funcs->mode_fixup(bridge, &crtc_state->mode, &crtc_state->adjusted_mode)) - return -EINVAL; + return ret; } return 0; diff --git a/include/drm/drm_bridge.h b/include/drm/drm_bridge.h index 2195daa..5d02dfc 100644 --- a/include/drm/drm_bridge.h +++ b/include/drm/drm_bridge.h @@ -153,7 +153,7 @@ struct drm_bridge_funcs { * True if an acceptable configuration is possible, false if the modeset * operation should be rejected. */ - bool (*mode_fixup)(struct drm_bridge *bridge, + int (*mode_fixup)(struct drm_bridge *bridge, const struct drm_display_mode *mode, struct drm_display_mode *adjusted_mode); /** diff --git a/include/drm/drm_modeset_helper_vtables.h b/include/drm/drm_modeset_helper_vtables.h index f3a4b47..e305c97 100644 --- a/include/drm/drm_modeset_helper_vtables.h +++ b/include/drm/drm_modeset_helper_vtables.h @@ -184,7 +184,7 @@ struct drm_crtc_helper_funcs { * True if an acceptable configuration is possible, false if the modeset * operation should be rejected. */ - bool (*mode_fixup)(struct drm_crtc *crtc, + int (*mode_fixup)(struct drm_crtc *crtc, const struct drm_display_mode *mode, struct drm_display_mode *adjusted_mode); @@ -599,7 +599,7 @@ struct drm_encoder_helper_funcs { * True if an acceptable configuration is possible, false if the modeset * operation should be rejected. */ - bool (*mode_fixup)(struct drm_encoder *encoder, + int (*mode_fixup)(struct drm_encoder *encoder, const struct drm_display_mode *mode, struct drm_display_mode *adjusted_mode); -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project

3 2

[PATCH v3 1/5] drm/i915: use consistent CPU mappings for pin_map users
by Matthew Auld 13 Jul '21

13 Jul '21

For discrete, users of pin_map() needs to obey the same rules at the TTM backend, where we map system only objects as WB, and everything else as WC. The simplest for now is to just force the correct mapping type as per the new rules for discrete. Suggested-by: Thomas Hellström <thomas.hellstrom(a)linux.intel.com> Signed-off-by: Matthew Auld <matthew.auld(a)intel.com> Cc: Thomas Hellström <thomas.hellstrom(a)linux.intel.com> Cc: Maarten Lankhorst <maarten.lankhorst(a)linux.intel.com> Cc: Daniel Vetter <daniel.vetter(a)ffwll.ch> Cc: Ramalingam C <ramalingam.c(a)intel.com> --- drivers/gpu/drm/i915/gem/i915_gem_object.c | 34 ++++++++++++++++++++++ drivers/gpu/drm/i915/gem/i915_gem_object.h | 4 +++ drivers/gpu/drm/i915/gem/i915_gem_pages.c | 22 ++++++++++++-- 3 files changed, 58 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object.c b/drivers/gpu/drm/i915/gem/i915_gem_object.c index 547cc9dad90d..9da7b288b7ed 100644 --- a/drivers/gpu/drm/i915/gem/i915_gem_object.c +++ b/drivers/gpu/drm/i915/gem/i915_gem_object.c @@ -625,6 +625,40 @@ int i915_gem_object_migrate(struct drm_i915_gem_object *obj, return obj->ops->migrate(obj, mr); } +/** + * i915_gem_object_placement_possible - Check whether the object can be + * placed at certain memory type + * @obj: Pointer to the object + * @type: The memory type to check + * + * Return: True if the object can be placed in @type. False otherwise. + */ +bool i915_gem_object_placement_possible(struct drm_i915_gem_object *obj, + enum intel_memory_type type) +{ + unsigned int i; + + if (!obj->mm.n_placements) { + switch (type) { + case INTEL_MEMORY_LOCAL: + return i915_gem_object_has_iomem(obj); + case INTEL_MEMORY_SYSTEM: + return i915_gem_object_has_pages(obj); + default: + /* Ignore stolen for now */ + GEM_BUG_ON(1); + return false; + } + } + + for (i = 0; i < obj->mm.n_placements; i++) { + if (obj->mm.placements[i]->type == type) + return true; + } + + return false; +} + void i915_gem_init__objects(struct drm_i915_private *i915) { INIT_WORK(&i915->mm.free_work, __i915_gem_free_work); diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object.h b/drivers/gpu/drm/i915/gem/i915_gem_object.h index d423d8cac4f2..8be4fadeee48 100644 --- a/drivers/gpu/drm/i915/gem/i915_gem_object.h +++ b/drivers/gpu/drm/i915/gem/i915_gem_object.h @@ -12,6 +12,7 @@ #include <drm/drm_device.h> #include "display/intel_frontbuffer.h" +#include "intel_memory_region.h" #include "i915_gem_object_types.h" #include "i915_gem_gtt.h" #include "i915_gem_ww.h" @@ -607,6 +608,9 @@ bool i915_gem_object_can_migrate(struct drm_i915_gem_object *obj, int i915_gem_object_wait_migration(struct drm_i915_gem_object *obj, unsigned int flags); +bool i915_gem_object_placement_possible(struct drm_i915_gem_object *obj, + enum intel_memory_type type); + #ifdef CONFIG_MMU_NOTIFIER static inline bool i915_gem_object_is_userptr(struct drm_i915_gem_object *obj) diff --git a/drivers/gpu/drm/i915/gem/i915_gem_pages.c b/drivers/gpu/drm/i915/gem/i915_gem_pages.c index f2f850e31b8e..810a157a18f8 100644 --- a/drivers/gpu/drm/i915/gem/i915_gem_pages.c +++ b/drivers/gpu/drm/i915/gem/i915_gem_pages.c @@ -321,8 +321,7 @@ static void *i915_gem_object_map_pfn(struct drm_i915_gem_object *obj, dma_addr_t addr; void *vaddr; - if (type != I915_MAP_WC) - return ERR_PTR(-ENODEV); + GEM_BUG_ON(type != I915_MAP_WC); if (n_pfn > ARRAY_SIZE(stack)) { /* Too big for stack -- allocate temporary array instead */ @@ -374,6 +373,25 @@ void *i915_gem_object_pin_map(struct drm_i915_gem_object *obj, } GEM_BUG_ON(!i915_gem_object_has_pages(obj)); + /* + * For discrete our CPU mappings needs to be consistent in order to + * function correctly on !x86. When mapping things through TTM, we use + * the same rules to determine the caching type. + * + * Internal users of lmem are already expected to get this right, so no + * fudging needed there. + */ + if (i915_gem_object_placement_possible(obj, INTEL_MEMORY_LOCAL)) { + if (type != I915_MAP_WC && !obj->mm.n_placements) { + ptr = ERR_PTR(-ENODEV); + goto err_unpin; + } + + type = I915_MAP_WC; + } else if (IS_DGFX(to_i915(obj->base.dev))) { + type = I915_MAP_WB; + } + ptr = page_unpack_bits(obj->mm.mapping, &has_type); if (ptr && has_type != type) { if (pinned) { -- 2.26.3

4 11

← Newer
1
...
59
60
61
62
63
64
65
...
83
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

dri-devel July 2021