dri-devel August 2019

dri-devel@lists.freedesktop.org

318 participants
2338 discussions

[Bug 110659] pageflipping seems to cause jittering on mouse input when running Hitman 2 in Wine/DXVK with amdgpu.dc=1
by bugzilla-daemon＠freedesktop.org 26 Aug '19

26 Aug '19

https://bugs.freedesktop.org/show_bug.cgi?id=110659 --- Comment #48 from Nicholas Kazlauskas <nicholas.kazlauskas(a)amd.com> --- (In reply to tempel.julian from comment #47) > I got a new 1440p 144 Hz FreeSync display, and as expected, the issue is > unchanged with it. > > With it, I've created a new debug dmesg log for render stutter in Oblivion, > this time with your patch applied to drm-next kernel. > > Perhaps this could be interesting? > > > [ 529.556752] [drm:drm_mode_addfb2 [drm]] [FB:79] > [ 529.557106] [drm:amdgpu_dm_atomic_commit_tail [amdgpu]] VRR packet > update: crtc=47 enabled=1 state=3 > [ 529.557164] [drm:dc_commit_updates_for_stream [amdgpu]] debug: full > update issued > [ 529.564401] [drm:drm_mode_addfb2 [drm]] [FB:86] > [ 531.420971] [drm:drm_mode_addfb2 [drm]] [FB:95] > [ 531.459067] [drm:drm_mode_addfb2 [drm]] [FB:96] > [ 544.144771] [drm:amdgpu_dm_atomic_commit_tail [amdgpu]] VRR packet > update: crtc=47 enabled=0 state=2 > [ 544.145961] [drm:dc_commit_updates_for_stream [amdgpu]] debug: full > update issued > [ 544.169447] [drm:drm_mode_addfb2 [drm]] [FB:79] > [ 544.172953] [drm:drm_mode_addfb2 [drm]] [FB:94] This is normal behavior for toggling into and out of VRR. I was expecting to see was a log with hundreds of full updates issued, but since this isn't the case I think it's something more fundamental with vblank timing though I'm still not quite sure why it I can't reproduce it in my testing. -- You are receiving this mail because: You are the assignee for the bug.

1 0

[Bug 111488] Testing bug
by bugzilla-daemon＠freedesktop.org 26 Aug '19

26 Aug '19

https://bugs.freedesktop.org/show_bug.cgi?id=111488 Bug ID: 111488 Summary: Testing bug Product: DRI Version: unspecified Hardware: All OS: All Status: NEW Severity: blocker Priority: not set Component: General Assignee: dri-devel(a)lists.freedesktop.org Reporter: pradnya(a)appristine.in Test -- You are receiving this mail because: You are the assignee for the bug.

1 0

XGI DRM driver as a practice?
by Ivan D 26 Aug '19

26 Aug '19

I'd like to learn DRM subsystem and GPU driver development and I was thinking about about writing XGI DRM driver as a practice project since: - there's (or was until recently) staging fbdev driver that should hopefully be working - it's still possible to buy thin client HW with XGI Z11 running Linux Does it make sense at all? I do have kernel experience but know very little about DRM and graphics. One issue is absence of documentation, but there could be as well others I'm not even aware of. If there's a better approach than this please drop me a line. Also putting relevant people from commit log to CC, hope it's ok. Thanks, Ivan

3 2

[PULL] drm-hisilicon-hibmc-next-2019-08-26
by xinliang 26 Aug '19

26 Aug '19

Hi Dave and Daniel, Three small cleanup and fix patches for 5.4 hisilicon hibmc driver. I have tested and verified on taishan 2280v1/v2 machines. As my drm-misc ssh account request[1] is not finish yet, I still send the pull this time. Please pull, thanks. [1] https://gitlab.freedesktop.org/freedesktop/freedesktop/issues/183 Best, Xinliang The following changes since commit 34044cd2955b54fb9141be31d12500bb589aa6c8: Merge branch 'linux-5.4' of git://github.com/skeggsb/linux into drm-next (2019-08-23 13:23:43 +1000) are available in the Git repository at: https://github.com/xin3liang/linux.git tags/drm-hisilicon-hibmc-next-2019-08-26 for you to fetch changes up to feeb07d0ca5ad0d6edb5bb728e33e2e86118529d: drm/hisilicon/hibmc: Make CONFIG_DRM_HISI_HIBMC depend on ARM64 (2019-08-26 15:21:34 +0800) ---------------------------------------------------------------- Chuhong Yuan (1): drm/hisilicon: Use dev_get_drvdata Matthew Ruffell (1): drm/hisilicon/hibmc: Make CONFIG_DRM_HISI_HIBMC depend on ARM64 YueHaibing (1): drm/hisilicon/hibmc: Using module_pci_driver. drivers/gpu/drm/hisilicon/hibmc/Kconfig | 2 +- drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c | 19 +++---------------- 2 files changed, 4 insertions(+), 17 deletions(-)

1 0

[PATCH] drm/hisilicon: Use dev_get_drvdata
by Chuhong Yuan 26 Aug '19

26 Aug '19

Instead of using to_pci_dev + pci_get_drvdata, use dev_get_drvdata to make code simpler. Signed-off-by: Chuhong Yuan <hslester96(a)gmail.com> --- drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c | 6 ++---- 1 file changed, 2 insertions(+), 4 deletions(-) diff --git a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c index ce89e56937b0..f0be263feff5 100644 --- a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c +++ b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c @@ -60,16 +60,14 @@ static struct drm_driver hibmc_driver = { static int __maybe_unused hibmc_pm_suspend(struct device *dev) { - struct pci_dev *pdev = to_pci_dev(dev); - struct drm_device *drm_dev = pci_get_drvdata(pdev); + struct drm_device *drm_dev = dev_get_drvdata(dev); return drm_mode_config_helper_suspend(drm_dev); } static int __maybe_unused hibmc_pm_resume(struct device *dev) { - struct pci_dev *pdev = to_pci_dev(dev); - struct drm_device *drm_dev = pci_get_drvdata(pdev); + struct drm_device *drm_dev = dev_get_drvdata(dev); return drm_mode_config_helper_resume(drm_dev); } -- 2.20.1

2 1

Re: [PATCH v18 15/15] selftests, arm64: add a selftest for passing tagged pointers to kernel
by Amit Kachhap 26 Aug '19

26 Aug '19

Hi, On 8/23/19 11:19 PM, Cristian Marussi wrote: > > Hi > > On 23/08/2019 18:16, Andrey Konovalov wrote: >> On Fri, Aug 23, 2019 at 3:56 PM Cristian Marussi >> <cristian.marussi(a)arm.com> wrote: >>> >>> Hi Andrey >>> >>> On 24/06/2019 15:33, Andrey Konovalov wrote: >>>> This patch is a part of a series that extends kernel ABI to allow to pass >>>> tagged user pointers (with the top byte set to something else other than >>>> 0x00) as syscall arguments. >>>> >>>> This patch adds a simple test, that calls the uname syscall with a >>>> tagged user pointer as an argument. Without the kernel accepting tagged >>>> user pointers the test fails with EFAULT. >>>> >>>> Signed-off-by: Andrey Konovalov <andreyknvl(a)google.com> >>>> --- >>>> tools/testing/selftests/arm64/.gitignore | 1 + >>>> tools/testing/selftests/arm64/Makefile | 11 +++++++ >>>> .../testing/selftests/arm64/run_tags_test.sh | 12 ++++++++ >>>> tools/testing/selftests/arm64/tags_test.c | 29 +++++++++++++++++++ >>>> 4 files changed, 53 insertions(+) >>>> create mode 100644 tools/testing/selftests/arm64/.gitignore >>>> create mode 100644 tools/testing/selftests/arm64/Makefile >>>> create mode 100755 tools/testing/selftests/arm64/run_tags_test.sh >>>> create mode 100644 tools/testing/selftests/arm64/tags_test.c >>> >>> After building a fresh Kernel from arm64/for-next-core from scratch at: >>> >>> commit 239ab658bea3b387424501e7c416640d6752dc0c >>> Merge: 6bfa3134bd3a 42d038c4fb00 1243cb6a676f d55c5f28afaf d06fa5a118f1 34b5560db40d >>> Author: Will Deacon <will(a)kernel.org> >>> Date: Thu Aug 22 18:23:53 2019 +0100 >>> >>> Merge branches 'for-next/error-injection', 'for-next/tbi', 'for-next/psci-cpuidle', 'for-next/cpu-topology' and 'for-next/52-bit-kva' into for-next/core >>> >>> >>> KSFT arm64 tests build is broken for me, both setting or not KBUILD_OUTPUT= >>> >>> 13:30 $ make TARGETS=arm64 kselftest-clean >>> make[1]: Entering directory '/home/crimar01/ARM/dev/src/pdsw/out_linux' >>> rm -f -r /home/crimar01/ARM/dev/src/pdsw/out_linux//kselftest/arm64/tags_test >>> make[1]: Leaving directory '/home/crimar01/ARM/dev/src/pdsw/out_linux' >>> >>> ✔ ~/ARM/dev/src/pdsw/linux [arm64_for_next_core|…8⚑ 23] >>> >>> 13:30 $ make TARGETS=arm64 kselftest >>> make[1]: Entering directory '/home/crimar01/ARM/dev/src/pdsw/out_linux' >>> arch/arm64/Makefile:56: CROSS_COMPILE_COMPAT not defined or empty, the compat vDSO will not be built >>> make --no-builtin-rules INSTALL_HDR_PATH=$BUILD/usr \ >>> ARCH=arm64 -C ../../.. headers_install >>> HOSTCC scripts/basic/fixdep >>> HOSTCC scripts/unifdef >>> ... >>> ... >>> HDRINST usr/include/asm/msgbuf.h >>> HDRINST usr/include/asm/shmbuf.h >>> INSTALL /home/crimar01/ARM/dev/src/pdsw/out_linux//kselftest/usr/include >>> /opt/toolchains/gcc-arm-8.3-2019.03-x86_64-aarch64-linux-gnu/bin/aarch64-linux-gnu-gcc tags_test.c -o /home/crimar01/ARM/dev/src/pdsw/out_linux//kselftest/arm64/tags_test >>> tags_test.c: In function ‘main’: >>> tags_test.c:21:12: error: ‘PR_SET_TAGGED_ADDR_CTRL’ undeclared (first use in this function); did you mean ‘PR_GET_TID_ADDRESS’? >>> if (prctl(PR_SET_TAGGED_ADDR_CTRL, PR_TAGGED_ADDR_ENABLE, 0, 0, 0) == 0) >>> ^~~~~~~~~~~~~~~~~~~~~~~ >>> PR_GET_TID_ADDRESS >>> tags_test.c:21:12: note: each undeclared identifier is reported only once for each function it appears in >>> tags_test.c:21:37: error: ‘PR_TAGGED_ADDR_ENABLE’ undeclared (first use in this function); did you mean ‘PR_GET_DUMPABLE’? >>> if (prctl(PR_SET_TAGGED_ADDR_CTRL, PR_TAGGED_ADDR_ENABLE, 0, 0, 0) == 0) >>> ^~~~~~~~~~~~~~~~~~~~~ >>> PR_GET_DUMPABLE >>> ../lib.mk:138: recipe for target '/home/crimar01/ARM/dev/src/pdsw/out_linux//kselftest/arm64/tags_test' failed >>> make[3]: *** [/home/crimar01/ARM/dev/src/pdsw/out_linux//kselftest/arm64/tags_test] Error 1 >>> Makefile:136: recipe for target 'all' failed >>> make[2]: *** [all] Error 2 >>> /home/crimar01/ARM/dev/src/pdsw/linux/Makefile:1237: recipe for target 'kselftest' failed >>> make[1]: *** [kselftest] Error 2 >>> make[1]: Leaving directory '/home/crimar01/ARM/dev/src/pdsw/out_linux' >>> Makefile:179: recipe for target 'sub-make' failed >>> make: *** [sub-make] Error 2 >>> >>> Despite seeing KSFT installing Kernel Headers, they cannot be found. >>> >>> Fixing this patch like this make it work for me: >>> >>> diff --git a/tools/testing/selftests/arm64/Makefile b/tools/testing/selftests/arm64/Makefile >>> index a61b2e743e99..f9f79fb272f0 100644 >>> --- a/tools/testing/selftests/arm64/Makefile >>> +++ b/tools/testing/selftests/arm64/Makefile >>> @@ -4,6 +4,7 @@ >>> ARCH ?= $(shell uname -m 2>/dev/null || echo not) >>> >>> ifneq (,$(filter $(ARCH),aarch64 arm64)) >>> +CFLAGS += -I../../../../usr/include/ >>> TEST_GEN_PROGS := tags_test >>> TEST_PROGS := run_tags_test.sh >>> endif >>> >>> but is not really a proper fix since it does NOT account for case in which you have >>> installed the Kernel Headers in a non standard location like when you use KBUILD_OUTPUT. >>> >>> Am I missing something ? >> >> Hm, PR_SET_TAGGED_ADDR_CTRL is defined in include/uapi/linux/prctl.h, >> and the test has #include <sys/prctl.h> so as long as you've updated >> your kernel headers this should work. >> >> (I'm OOO next week, I'll see if I can reproduce this once I'm back). > > Ok. Thanks for the reply. > > I think I've got it in my local tree having cloned arm64/for-next-core: > > 18:32 $ egrep -A 10 PR_SET_TAG ./include/uapi/linux/prctl.h > #define PR_SET_TAGGED_ADDR_CTRL 55 > #define PR_GET_TAGGED_ADDR_CTRL 56 > # define PR_TAGGED_ADDR_ENABLE (1UL << 0) > > #endif /* _LINUX_PRCTL_H */ > > and Kernel header are locally installed in my kernel src dir (by KSFT indeed) > > 18:34 $ egrep -RA 10 PR_SET_TAG usr/include/ > usr/include/linux/prctl.h:#define PR_SET_TAGGED_ADDR_CTRL 55 > usr/include/linux/prctl.h-#define PR_GET_TAGGED_ADDR_CTRL 56 > usr/include/linux/prctl.h-# define PR_TAGGED_ADDR_ENABLE (1UL << 0) > usr/include/linux/prctl.h- > usr/include/linux/prctl.h-#endif /* _LINUX_PRCTL_H */ > > but how are they supposed to be found if nor the test Makefile > neither the KSFT Makefile who installs them pass any -I options to the > compiler ? > I suppose <sys/prctl.h> tries to include arch specific headers from the regular system path, > but when you are cross-compiling ? I guess for cross-compiling it picks from cross_compiler path include headers path without explicitly displaying it in compilation logs. > > 18:34 $ make TARGETS=arm64 kselftest > make[1]: Entering directory '/home/crimar01/ARM/dev/src/pdsw/out_linux' > arch/arm64/Makefile:56: CROSS_COMPILE_COMPAT not defined or empty, the compat vDSO will not be built > make --no-builtin-rules INSTALL_HDR_PATH=$BUILD/usr \ > ARCH=arm64 -C ../../.. headers_install > INSTALL /home/crimar01/ARM/dev/src/pdsw/out_linux/kselftest/usr/include > /opt/toolchains/gcc-arm-8.3-2019.03-x86_64-aarch64-linux-gnu/bin/aarch64-linux-gnu-gcc -Wall -O2 -g tags_test.c -o /home/crimar01/ARM/dev/src/pdsw/out_linux/kselftest/arm64/tags/tags_test > tags_test.c: In function ‘main’: > tags_test.c:20:12: error: ‘PR_SET_TAGGED_ADDR_CTRL’ undeclared (first use in this function); did you mean ‘PR_GET_TID_ADDRESS’? > if (prctl(PR_SET_TAGGED_ADDR_CTRL, PR_TAGGED_ADDR_ENABLE, 0, 0, 0) == 0) > ^~~~~~~~~~~~~~~~~~~~~~~ > PR_GET_TID_ADDRESS > tags_test.c:20:12: note: each undeclared identifier is reported only once for each function it appears in > tags_test.c:20:37: error: ‘PR_TAGGED_ADDR_ENABLE’ undeclared (first use in this function); did you mean ‘PR_GET_DUMPABLE’? > if (prctl(PR_SET_TAGGED_ADDR_CTRL, PR_TAGGED_ADDR_ENABLE, 0, 0, 0) == 0) > ^~~~~~~~~~~~~~~~~~~~~ > PR_GET_DUMPABLE > ../../lib.mk:138: recipe for target '/home/crimar01/ARM/dev/src/pdsw/out_linux/kselftest/arm64/tags/tags_test' failed > make[4]: *** [/home/crimar01/ARM/dev/src/pdsw/out_linux/kselftest/arm64/tags/tags_test] Error 1 > Makefile:19: recipe for target 'all' failed > make[3]: *** [all] Error 2 > Makefile:137: recipe for target 'all' failed > make[2]: *** [all] Error 2 > /home/crimar01/ARM/dev/src/pdsw/linux/Makefile:1236: recipe for target 'kselftest' failed > make[1]: *** [kselftest] Error 2 > make[1]: Leaving directory '/home/crimar01/ARM/dev/src/pdsw/out_linux' > Makefile:179: recipe for target 'sub-make' failed > make: *** [sub-make] Error 2 > > > In fact many KSFT testcases seems to brutally add default headers path: > > tools/testing/selftests/memfd/Makefile:CFLAGS += -I../../../../include/uapi/ > tools/testing/selftests/memfd/Makefile:CFLAGS += -I../../../../include/ > tools/testing/selftests/memfd/Makefile:CFLAGS += -I../../../../usr/include/ > tools/testing/selftests/net/Makefile:CFLAGS += -I../../../../usr/include/ > tools/testing/selftests/membarrier/Makefile:CFLAGS += -g -I../../../../usr/include/ Agree with Cristian that including like this is better as it allows freedom from toolchain with latest kernel headers. Anyway there are many places where "/sys/prctl.h" is used. //Amit > ... > > Cheers > > Cristian >> >> >> >>> >>> Thanks >>> >>> Cristian >>> >>>> >>>> diff --git a/tools/testing/selftests/arm64/.gitignore b/tools/testing/selftests/arm64/.gitignore >>>> new file mode 100644 >>>> index 000000000000..e8fae8d61ed6 >>>> --- /dev/null >>>> +++ b/tools/testing/selftests/arm64/.gitignore >>>> @@ -0,0 +1 @@ >>>> +tags_test >>>> diff --git a/tools/testing/selftests/arm64/Makefile b/tools/testing/selftests/arm64/Makefile >>>> new file mode 100644 >>>> index 000000000000..a61b2e743e99 >>>> --- /dev/null >>>> +++ b/tools/testing/selftests/arm64/Makefile >>>> @@ -0,0 +1,11 @@ >>>> +# SPDX-License-Identifier: GPL-2.0 >>>> + >>>> +# ARCH can be overridden by the user for cross compiling >>>> +ARCH ?= $(shell uname -m 2>/dev/null || echo not) >>>> + >>>> +ifneq (,$(filter $(ARCH),aarch64 arm64)) >>>> +TEST_GEN_PROGS := tags_test >>>> +TEST_PROGS := run_tags_test.sh >>>> +endif >>>> + >>>> +include ../lib.mk >>>> diff --git a/tools/testing/selftests/arm64/run_tags_test.sh b/tools/testing/selftests/arm64/run_tags_test.sh >>>> new file mode 100755 >>>> index 000000000000..745f11379930 >>>> --- /dev/null >>>> +++ b/tools/testing/selftests/arm64/run_tags_test.sh >>>> @@ -0,0 +1,12 @@ >>>> +#!/bin/sh >>>> +# SPDX-License-Identifier: GPL-2.0 >>>> + >>>> +echo "--------------------" >>>> +echo "running tags test" >>>> +echo "--------------------" >>>> +./tags_test >>>> +if [ $? -ne 0 ]; then >>>> + echo "[FAIL]" >>>> +else >>>> + echo "[PASS]" >>>> +fi >>>> diff --git a/tools/testing/selftests/arm64/tags_test.c b/tools/testing/selftests/arm64/tags_test.c >>>> new file mode 100644 >>>> index 000000000000..22a1b266e373 >>>> --- /dev/null >>>> +++ b/tools/testing/selftests/arm64/tags_test.c >>>> @@ -0,0 +1,29 @@ >>>> +// SPDX-License-Identifier: GPL-2.0 >>>> + >>>> +#include <stdio.h> >>>> +#include <stdlib.h> >>>> +#include <unistd.h> >>>> +#include <stdint.h> >>>> +#include <sys/prctl.h> >>>> +#include <sys/utsname.h> >>>> + >>>> +#define SHIFT_TAG(tag) ((uint64_t)(tag) << 56) >>>> +#define SET_TAG(ptr, tag) (((uint64_t)(ptr) & ~SHIFT_TAG(0xff)) | \ >>>> + SHIFT_TAG(tag)) >>>> + >>>> +int main(void) >>>> +{ >>>> + static int tbi_enabled = 0; >>>> + struct utsname *ptr, *tagged_ptr; >>>> + int err; >>>> + >>>> + if (prctl(PR_SET_TAGGED_ADDR_CTRL, PR_TAGGED_ADDR_ENABLE, 0, 0, 0) == 0) >>>> + tbi_enabled = 1; >>>> + ptr = (struct utsname *)malloc(sizeof(*ptr)); >>>> + if (tbi_enabled) >>>> + tagged_ptr = (struct utsname *)SET_TAG(ptr, 0x42); >>>> + err = uname(tagged_ptr); >>>> + free(ptr); >>>> + >>>> + return err; >>>> +} >>>> >>> > > > _______________________________________________ > linux-arm-kernel mailing list > linux-arm-kernel(a)lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel > IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

1 0

[PATCH 0/3] drm/syncobj: add protection against timeline resets
by Lionel Landwerlin 26 Aug '19

26 Aug '19

Hi all, Following Jason's suggestion on another thread adding timeline documentation [1], here is a small series adding a creation flag to syncobjs so that users are prevented to drop the existing timeline fences in the syncobj, effectivelly ensuring a user always adds to the dma_fence_chain instead of replacing it. We still allow explicit reset. Apart from the fact we need to enforce this policy in each driver's submission path, I haven't run into odds things yet. Cheers, [1] : https://lists.freedesktop.org/archives/dri-devel/2019-August/232700.html Lionel Landwerlin (3): drm/syncobj: protect timeline syncobjs drm/amd/amdgpu: disallow replacing fences in timeline syncobjs drm/i915: disallow replacing fences of timeline syncobjs drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 2 ++ drivers/gpu/drm/drm_syncobj.c | 30 ++++++++++++++++++- .../gpu/drm/i915/gem/i915_gem_execbuffer.c | 8 +++++ include/drm/drm_syncobj.h | 8 +++++ include/uapi/drm/drm.h | 1 + 5 files changed, 48 insertions(+), 1 deletion(-) -- 2.23.0

1 3

linux-next: manual merge of the drm tree with Linus' tree
by Stephen Rothwell 26 Aug '19

26 Aug '19

Hi all, Today's linux-next merge of the drm tree got a conflict in: drivers/gpu/drm/mediatek/mtk_drm_drv.c between commit: 7837951a12fd ("drm/mediatek: include dma-mapping header") from Linus' tree and commit: 9aef5867c86c ("drm/mediatek: drop use of drmP.h") from the drm tree. I fixed it up (see below) and can carry the fix as necessary. This is now fixed as far as linux-next is concerned, but any non trivial conflicts should be mentioned to your upstream maintainer when your tree is submitted for merging. You may also want to consider cooperating with the maintainer of the conflicting tree to minimise any particularly complex conflicts. -- Cheers, Stephen Rothwell diff --cc drivers/gpu/drm/mediatek/mtk_drm_drv.c index 945bc20f1d33,2ee809a6f3dc..000000000000 --- a/drivers/gpu/drm/mediatek/mtk_drm_drv.c +++ b/drivers/gpu/drm/mediatek/mtk_drm_drv.c @@@ -4,9 -4,16 +4,17 @@@ * Author: YT SHEN <yt.shen(a)mediatek.com> */ - #include <drm/drmP.h> + #include <linux/component.h> + #include <linux/iommu.h> + #include <linux/module.h> + #include <linux/of_address.h> + #include <linux/of_platform.h> + #include <linux/pm_runtime.h> ++#include <linux/dma-mapping.h> + #include <drm/drm_atomic.h> #include <drm/drm_atomic_helper.h> + #include <drm/drm_drv.h> #include <drm/drm_fb_helper.h> #include <drm/drm_gem.h> #include <drm/drm_gem_cma_helper.h> @@@ -352,21 -314,8 +346,20 @@@ static const struct file_operations mtk .compat_ioctl = drm_compat_ioctl, }; +/* + * We need to override this because the device used to import the memory is + * not dev->dev, as drm_gem_prime_import() expects. + */ +struct drm_gem_object *mtk_drm_gem_prime_import(struct drm_device *dev, + struct dma_buf *dma_buf) +{ + struct mtk_drm_private *private = dev->dev_private; + + return drm_gem_prime_import_dev(dev, dma_buf, private->dma_dev); +} + static struct drm_driver mtk_drm_driver = { - .driver_features = DRIVER_MODESET | DRIVER_GEM | DRIVER_PRIME | - DRIVER_ATOMIC, + .driver_features = DRIVER_MODESET | DRIVER_GEM | DRIVER_ATOMIC, .gem_free_object_unlocked = mtk_drm_gem_free_object, .gem_vm_ops = &drm_gem_cma_vm_ops, @@@ -374,8 -323,6 +367,7 @@@ .prime_handle_to_fd = drm_gem_prime_handle_to_fd, .prime_fd_to_handle = drm_gem_prime_fd_to_handle, - .gem_prime_export = drm_gem_prime_export, + .gem_prime_import = mtk_drm_gem_prime_import, .gem_prime_get_sg_table = mtk_gem_prime_get_sg_table, .gem_prime_import_sg_table = mtk_gem_prime_import_sg_table, .gem_prime_mmap = mtk_drm_gem_mmap_buf,

1 0

[Bug 111448] [AMD TAHITI XT] IO_PAGE_FAULT
by bugzilla-daemon＠freedesktop.org 25 Aug '19

25 Aug '19

https://bugs.freedesktop.org/show_bug.cgi?id=111448 Bug ID: 111448 Summary: [AMD TAHITI XT] IO_PAGE_FAULT Product: DRI Version: DRI git Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: normal Priority: medium Component: DRM/AMDgpu Assignee: dri-devel(a)lists.freedesktop.org Reporter: sylvain.bertrand(a)gmail.com Updated my gfx stack this week, and in the kernel log I get tons of IO_PAGE_FAULT . Everything git from last sunday/monday. linux amd-staging-drm-next 6c7a8d5c0772d8a389997cd5e35e8fa83f830f41 drm 14922551aa33e7592d2421cc89cf20a860a65310 llvm c81cf445a3132cf48fbe8f75f0314cbd346d87ab mesa c550d367a747472ee71ed4c99e210174730aa82b xserver aed62f8fbea3f618f97ee0105b2d430c8cddf8f5 xf86-video-amdgpu e6fce59a071220967fcd4e2c9e4a262c72870761 -- You are receiving this mail because: You are the assignee for the bug.

1 3

[PATCH] dma-buf: Give dma-fence-array distinct lockclasses
by Chris Wilson 25 Aug '19

25 Aug '19

In order to allow dma-fence-array as a generic container for fences, we need to allow for it to contain other dma-fence-arrays. By giving each dma-fence-array construction their own lockclass, we allow different types of dma-fence-array to nest, but still do not allow on class of dma-fence-array to contain itself (even though they have distinct locks). In practice, this means that each subsystem gets its own dma-fence-array class and we can freely use dma-fence-arrays as containers within the dmabuf core without angering lockdep. Signed-off-by: Chris Wilson <chris(a)chris-wilson.co.uk> Cc: Christian König <christian.koenig(a)amd.com> Cc: Daniel Vetter <daniel(a)ffwll.ch> --- drivers/dma-buf/dma-fence-array.c | 13 ++++++++----- include/linux/dma-fence-array.h | 16 ++++++++++++---- 2 files changed, 20 insertions(+), 9 deletions(-) diff --git a/drivers/dma-buf/dma-fence-array.c b/drivers/dma-buf/dma-fence-array.c index d3fbd950be94..d9bcdbb66d46 100644 --- a/drivers/dma-buf/dma-fence-array.c +++ b/drivers/dma-buf/dma-fence-array.c @@ -147,10 +147,11 @@ EXPORT_SYMBOL(dma_fence_array_ops); * If @signal_on_any is true the fence array signals if any fence in the array * signals, otherwise it signals when all fences in the array signal. */ -struct dma_fence_array *dma_fence_array_create(int num_fences, - struct dma_fence **fences, - u64 context, unsigned seqno, - bool signal_on_any) +struct dma_fence_array *__dma_fence_array_create(int num_fences, + struct dma_fence **fences, + u64 context, unsigned seqno, + bool signal_on_any, + struct lock_class_key *key) { struct dma_fence_array *array; size_t size = sizeof(*array); @@ -162,6 +163,8 @@ struct dma_fence_array *dma_fence_array_create(int num_fences, return NULL; spin_lock_init(&array->lock); + lockdep_set_class(&array->lock, key); + dma_fence_init(&array->base, &dma_fence_array_ops, &array->lock, context, seqno); init_irq_work(&array->work, irq_dma_fence_array_work); @@ -174,7 +177,7 @@ struct dma_fence_array *dma_fence_array_create(int num_fences, return array; } -EXPORT_SYMBOL(dma_fence_array_create); +EXPORT_SYMBOL(__dma_fence_array_create); /** * dma_fence_match_context - Check if all fences are from the given context diff --git a/include/linux/dma-fence-array.h b/include/linux/dma-fence-array.h index 303dd712220f..1395f9428cdb 100644 --- a/include/linux/dma-fence-array.h +++ b/include/linux/dma-fence-array.h @@ -74,10 +74,18 @@ to_dma_fence_array(struct dma_fence *fence) return container_of(fence, struct dma_fence_array, base); } -struct dma_fence_array *dma_fence_array_create(int num_fences, - struct dma_fence **fences, - u64 context, unsigned seqno, - bool signal_on_any); +#define dma_fence_array_create(num, fences, context, seqno, any) ({ \ + static struct lock_class_key __key; \ + \ + __dma_fence_array_create((num), (fences), (context), (seqno), (any), \ + &__key); \ +}) + +struct dma_fence_array *__dma_fence_array_create(int num_fences, + struct dma_fence **fences, + u64 context, unsigned seqno, + bool signal_on_any, + struct lock_class_key *key); bool dma_fence_match_context(struct dma_fence *fence, u64 context); -- 2.23.0

3 4

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

dri-devel August 2019