dri-devel August 2019

dri-devel@lists.freedesktop.org

318 participants
2338 discussions

Re: Threaded submission & semaphore sharing
by Koenig, Christian 02 Aug '19

02 Aug '19

Am 02.08.2019 07:38 schrieb Lionel Landwerlin <lionel.g.landwerlin(a)intel.com>: On 02/08/2019 08:21, Koenig, Christian wrote: Am 02.08.2019 07:17 schrieb Lionel Landwerlin <lionel.g.landwerlin(a)intel.com><mailto:lionel.g.landwerlin@intel.com>: On 02/08/2019 08:08, Koenig, Christian wrote: Hi Lionel, Well that looks more like your test case is buggy. According to the code the ctx1 queue always waits for sem1 and ctx2 queue always waits for sem2. That's supposed to be the same underlying syncobj because it's exported from one VkDevice as opaque FD from sem1 and imported into sem2. Well than that's still buggy and won't synchronize at all. When ctx1 waits for a semaphore and then signals the same semaphore there is no guarantee that ctx2 will run in between jobs. It's perfectly valid in this case to first run all jobs from ctx1 and then all jobs from ctx2. That's not really how I see the semaphores working. The spec describe VkSemaphore as an interface to an internal payload opaque to the application. When ctx1 waits on the semaphore, it waits on the payload put there by the previous iteration. And who says that it's not waiting for it's own previous payload? See if the payload is a counter this won't work either. Keep in mind that this has the semantic of a semaphore. Whoever grabs the semaphore first wins and can run, everybody else has to wait. Then it proceeds to signal it by replacing the internal payload. That's an implementation detail of our sync objects, but I don't think that this behavior is part of the Vulkan specification. Regards, Christian. ctx2 then waits on that and replaces the payload again with the new internal synchronization object. The internal payload is a dma fence in our case and signaling just replaces a dma fence by another or puts one where there was none before. So we should have created a dependecy link between all the submissions and then should be executed in the order of QueueSubmit() calls. -Lionel It only prevents running both at the same time and as far as I can see that still works even with threaded submission. You need at least two semaphores for a tandem submission. Regards, Christian. This way there can't be any Synchronisation between the two. Regards, Christian. Am 02.08.2019 06:55 schrieb Lionel Landwerlin <lionel.g.landwerlin(a)intel.com><mailto:lionel.g.landwerlin@intel.com>: Hey Christian, The problem boils down to the fact that we don't immediately create dma fences when calling vkQueueSubmit(). This is delayed to a thread. From a single application thread, you can QueueSubmit() to 2 queues from 2 different devices. Each QueueSubmit to one queue has a dependency on the previous QueueSubmit on the other queue through an exported/imported semaphore. From the API point of view the state of the semaphore should be changed after each QueueSubmit(). The problem is that it's not because of the thread and because you might have those 2 submission threads tied to different VkDevice/VkInstance or even different applications (synchronizing themselves outside the vulkan API). Hope that makes sense. It's not really easy to explain by mail, the best explanation is probably reading the test : https://gitlab.freedesktop.org/mesa/crucible/blob/master/src/tests/func/syn… Like David mentioned you're not running into that issue right now, because you only dispatch to the thread under specific conditions. But I could build a case to force that and likely run into the same issue. -Lionel On 02/08/2019 07:33, Koenig, Christian wrote: Hi Lionel, Well could you describe once more what the problem is? Cause I don't fully understand why a rather normal tandem submission with two semaphores should fail in any way. Regards, Christian. Am 02.08.2019 06:28 schrieb Lionel Landwerlin <lionel.g.landwerlin(a)intel.com><mailto:lionel.g.landwerlin@intel.com>: There aren't CTS tests covering the issue I was mentioning. But we could add them. I don't have all the details regarding your implementation but even with the "semaphore thread", I could see it running into the same issues. What if a mix of binary & timeline semaphores are handed to vkQueueSubmit()? For example with queueA & queueB from 2 different VkDevice : vkQueueSubmit(queueA, signal semA); vkQueueSubmit(queueA, wait on [semA, timelineSemB]); with timelineSemB triggering a wait before signal. vkQueueSubmit(queueB, signal semA); -Lionel On 02/08/2019 06:18, Zhou, David(ChunMing) wrote: > Hi Lionel, > > By the Queue thread is a heavy thread, which is always resident in driver during application running, our guys don't like that. So we switch to Semaphore Thread, only when waitBeforeSignal of timeline happens, we spawn a thread to handle that wait. So we don't have your this issue. > By the way, I already pass all your CTS cases for now. I suggest you to switch to Semaphore Thread instead of Queue Thread as well. It works very well. > > -David > > -----Original Message----- > From: Lionel Landwerlin <lionel.g.landwerlin(a)intel.com><mailto:lionel.g.landwerlin@intel.com> > Sent: Friday, August 2, 2019 4:52 AM > To: dri-devel <dri-devel(a)lists.freedesktop.org><mailto:dri-devel@lists.freedesktop.org>; Koenig, Christian <Christian.Koenig(a)amd.com><mailto:Christian.Koenig@amd.com>; Zhou, David(ChunMing) <David1.Zhou(a)amd.com><mailto:David1.Zhou@amd.com>; Jason Ekstrand <jason(a)jlekstrand.net><mailto:jason@jlekstrand.net> > Subject: Threaded submission & semaphore sharing > > Hi Christian, David, > > Sorry to report this so late in the process, but I think we found an issue not directly related to syncobj timelines themselves but with a side effect of the threaded submissions. > > Essentially we're failing a test in crucible : > func.sync.semaphore-fd.opaque-fd > This test create a single binary semaphore, shares it between 2 VkDevice/VkQueue. > Then in a loop it proceeds to submit workload alternating between the 2 VkQueue with one submit depending on the other. > It does so by waiting on the VkSemaphore signaled in the previous iteration and resignaling it. > > The problem for us is that once things are dispatched to the submission thread, the ordering of the submission is lost. > Because we have 2 devices and they both have their own submission thread. > > Jason suggested that we reestablish the ordering by having semaphores/syncobjs carry an additional uint64_t payload. > This 64bit integer would represent be an identifier that submission threads will WAIT_FOR_AVAILABLE on. > > The scenario would look like this : > - vkQueueSubmit(queueA, signal on semA); > - in the caller thread, this would increment the syncobj additional u64 payload and return it to userspace. > - at some point the submission thread of queueA submits the workload and signal the syncobj of semA with value returned in the caller thread of vkQueueSubmit(). > - vkQueueSubmit(queueB, wait on semA); > - in the caller thread, this would read the syncobj additional > u64 payload > - at some point the submission thread of queueB will try to submit the work, but first it will WAIT_FOR_AVAILABLE the u64 value returned in the step above > > Because we want the binary semaphores to be shared across processes and would like this to remain a single FD, the simplest location to store this additional u64 payload would be the DRM syncobj. > It would need an additional ioctl to read & increment the value. > > What do you think? > > -Lionel

3 5

[PATCH] drm/imx: Drop unused imx-ipuv3-crtc.o build
by Guido Günther 02 Aug '19

02 Aug '19

Since commit 3d1df96ad468 ("drm/imx: merge imx-drm-core and ipuv3-crtc in one module") imx-ipuv3-crtc.o is built via imxdrm-objs. So there's no need to keep an extra entry with a non existing config value (CONFIG_DRM_IMX_IPUV3). Signed-off-by: Guido Günther <agx(a)sigxcpu.org> --- drivers/gpu/drm/imx/Makefile | 1 - 1 file changed, 1 deletion(-) diff --git a/drivers/gpu/drm/imx/Makefile b/drivers/gpu/drm/imx/Makefile index ab6c83caceb7..21cdcc2faabc 100644 --- a/drivers/gpu/drm/imx/Makefile +++ b/drivers/gpu/drm/imx/Makefile @@ -8,5 +8,4 @@ obj-$(CONFIG_DRM_IMX_PARALLEL_DISPLAY) += parallel-display.o obj-$(CONFIG_DRM_IMX_TVE) += imx-tve.o obj-$(CONFIG_DRM_IMX_LDB) += imx-ldb.o -obj-$(CONFIG_DRM_IMX_IPUV3) += imx-ipuv3-crtc.o obj-$(CONFIG_DRM_IMX_HDMI) += dw_hdmi-imx.o -- 2.20.1

3 2

[PATCH] etnaviv: fix whitespace errors
by Christian Gmeiner 02 Aug '19

02 Aug '19

Signed-off-by: Christian Gmeiner <christian.gmeiner(a)gmail.com> --- drivers/gpu/drm/etnaviv/etnaviv_perfmon.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/etnaviv/etnaviv_perfmon.c b/drivers/gpu/drm/etnaviv/etnaviv_perfmon.c index 4227a4006c34..06e6d3ee1c34 100644 --- a/drivers/gpu/drm/etnaviv/etnaviv_perfmon.c +++ b/drivers/gpu/drm/etnaviv/etnaviv_perfmon.c @@ -15,8 +15,8 @@ struct etnaviv_pm_signal { u32 data; u32 (*sample)(struct etnaviv_gpu *gpu, - const struct etnaviv_pm_domain *domain, - const struct etnaviv_pm_signal *signal); + const struct etnaviv_pm_domain *domain, + const struct etnaviv_pm_signal *signal); }; struct etnaviv_pm_domain { -- 2.21.0

2 2

Re: [PATCH v19 02/15] arm64: Introduce prctl() options to control the tagged user addresses ABI
by Dave Hansen 02 Aug '19

02 Aug '19

On 7/23/19 10:58 AM, Andrey Konovalov wrote: > +long set_tagged_addr_ctrl(unsigned long arg) > +{ > + if (!tagged_addr_prctl_allowed) > + return -EINVAL; > + if (is_compat_task()) > + return -EINVAL; > + if (arg & ~PR_TAGGED_ADDR_ENABLE) > + return -EINVAL; > + > + update_thread_flag(TIF_TAGGED_ADDR, arg & PR_TAGGED_ADDR_ENABLE); > + > + return 0; > +} Instead of a plain enable/disable, a more flexible ABI would be to have the tag mask be passed in. That way, an implementation that has a flexible tag size can select it. It also ensures that userspace actually knows what the tag size is and isn't surprised if a hardware implementation changes the tag size or position. Also, this whole set deals with tagging/untagging, but there's an effective loss of address space when you do this. Is that dealt with anywhere? How do we ensure that allocations don't get placed at a tagged address before this gets turned on? Where's that checking?

3 3

[PATCH v19 00/15] arm64: untag user pointers passed to the kernel
by Andrey Konovalov 02 Aug '19

02 Aug '19

=== Overview arm64 has a feature called Top Byte Ignore, which allows to embed pointer tags into the top byte of each pointer. Userspace programs (such as HWASan, a memory debugging tool [1]) might use this feature and pass tagged user pointers to the kernel through syscalls or other interfaces. Right now the kernel is already able to handle user faults with tagged pointers, due to these patches: 1. 81cddd65 ("arm64: traps: fix userspace cache maintenance emulation on a tagged pointer") 2. 7dcd9dd8 ("arm64: hw_breakpoint: fix watchpoint matching for tagged pointers") 3. 276e9327 ("arm64: entry: improve data abort handling of tagged pointers") This patchset extends tagged pointer support to syscall arguments. As per the proposed ABI change [3], tagged pointers are only allowed to be passed to syscalls when they point to memory ranges obtained by anonymous mmap() or sbrk() (see the patchset [3] for more details). For non-memory syscalls this is done by untaging user pointers when the kernel performs pointer checking to find out whether the pointer comes from userspace (most notably in access_ok). The untagging is done only when the pointer is being checked, the tag is preserved as the pointer makes its way through the kernel and stays tagged when the kernel dereferences the pointer when perfoming user memory accesses. The mmap and mremap (only new_addr) syscalls do not currently accept tagged addresses. Architectures may interpret the tag as a background colour for the corresponding vma. Other memory syscalls (mprotect, etc.) don't do user memory accesses but rather deal with memory ranges, and untagged pointers are better suited to describe memory ranges internally. Thus for memory syscalls we untag pointers completely when they enter the kernel. === Other approaches One of the alternative approaches to untagging that was considered is to completely strip the pointer tag as the pointer enters the kernel with some kind of a syscall wrapper, but that won't work with the countless number of different ioctl calls. With this approach we would need a custom wrapper for each ioctl variation, which doesn't seem practical. An alternative approach to untagging pointers in memory syscalls prologues is to inspead allow tagged pointers to be passed to find_vma() (and other vma related functions) and untag them there. Unfortunately, a lot of find_vma() callers then compare or subtract the returned vma start and end fields against the pointer that was being searched. Thus this approach would still require changing all find_vma() callers. === Testing The following testing approaches has been taken to find potential issues with user pointer untagging: 1. Static testing (with sparse [2] and separately with a custom static analyzer based on Clang) to track casts of __user pointers to integer types to find places where untagging needs to be done. 2. Static testing with grep to find parts of the kernel that call find_vma() (and other similar functions) or directly compare against vm_start/vm_end fields of vma. 3. Static testing with grep to find parts of the kernel that compare user pointers with TASK_SIZE or other similar consts and macros. 4. Dynamic testing: adding BUG_ON(has_tag(addr)) to find_vma() and running a modified syzkaller version that passes tagged pointers to the kernel. Based on the results of the testing the requried patches have been added to the patchset. === Notes This patchset is meant to be merged together with "arm64 relaxed ABI" [3]. This patchset is a prerequisite for ARM's memory tagging hardware feature support [4]. This patchset has been merged into the Pixel 2 & 3 kernel trees and is now being used to enable testing of Pixel phones with HWASan. Thanks! [1] http://clang.llvm.org/docs/HardwareAssistedAddressSanitizerDesign.html [2] https://github.com/lucvoo/sparse-dev/commit/5f960cb10f56ec2017c128ef9d16060… [3] https://lkml.org/lkml/2019/6/12/745 [4] https://community.arm.com/processors/b/blog/posts/arm-a-profile-architectur… === History Changes in v19: - Rebased onto 7b5cf701 (5.3-rc1+). Changes in v18: - Reverted the selftest back to not using the LD_PRELOAD approach. - Added prctl(PR_SET_TAGGED_ADDR_CTRL) call to the selftest. - Reworded the patch descriptions to make them less oriented on arm64 only. - Catalin's patch: "I added a Kconfig option and dropped the prctl args zero check. There is some minor clean-up as well". Changes in v17: - The "uaccess: add noop untagged_addr definition" patch is dropped, as it was merged into upstream named as "uaccess: add noop untagged_addr definition". - Merged "mm, arm64: untag user pointers in do_pages_move" into "mm, arm64: untag user pointers passed to memory syscalls". - Added "arm64: Introduce prctl() options to control the tagged user addresses ABI" patch from Catalin. - Add tags_lib.so to tools/testing/selftests/arm64/.gitignore. - Added a comment clarifying untagged in mremap. - Moved untagging back into mlx4_get_umem_mr() for the IB patch. Changes in v16: - Moved untagging for memory syscalls from arm64 wrappers back to generic code. - Dropped untagging for the following memory syscalls: brk, mmap, munmap; mremap (only dropped for new_address); mmap_pgoff (not used on arm64); remap_file_pages (deprecated); shmat, shmdt (work on shared memory). - Changed kselftest to LD_PRELOAD a shared library that overrides malloc to return tagged pointers. - Rebased onto 5.2-rc3. Changes in v15: - Removed unnecessary untagging from radeon_ttm_tt_set_userptr(). - Removed unnecessary untagging from amdgpu_ttm_tt_set_userptr(). - Moved untagging to validate_range() in userfaultfd code. - Moved untagging to ib_uverbs_(re)reg_mr() from mlx4_get_umem_mr(). - Rebased onto 5.1. Changes in v14: - Moved untagging for most memory syscalls to an arm64 specific implementation, instead of doing that in the common code. - Dropped "net, arm64: untag user pointers in tcp_zerocopy_receive", since the provided user pointers don't come from an anonymous map and thus are not covered by this ABI relaxation. - Dropped "kernel, arm64: untag user pointers in prctl_set_mm*". - Moved untagging from __check_mem_type() to tee_shm_register(). - Updated untagging for the amdgpu and radeon drivers to cover the MMU notifier, as suggested by Felix. - Since this ABI relaxation doesn't actually allow tagged instruction pointers, dropped the following patches: - Dropped "tracing, arm64: untag user pointers in seq_print_user_ip". - Dropped "uprobes, arm64: untag user pointers in find_active_uprobe". - Dropped "bpf, arm64: untag user pointers in stack_map_get_build_id_offset". - Rebased onto 5.1-rc7 (37624b58). Changes in v13: - Simplified untagging in tcp_zerocopy_receive(). - Looked at find_vma() callers in drivers/, which allowed to identify a few other places where untagging is needed. - Added patch "mm, arm64: untag user pointers in get_vaddr_frames". - Added patch "drm/amdgpu, arm64: untag user pointers in amdgpu_ttm_tt_get_user_pages". - Added patch "drm/radeon, arm64: untag user pointers in radeon_ttm_tt_pin_userptr". - Added patch "IB/mlx4, arm64: untag user pointers in mlx4_get_umem_mr". - Added patch "media/v4l2-core, arm64: untag user pointers in videobuf_dma_contig_user_get". - Added patch "tee/optee, arm64: untag user pointers in check_mem_type". - Added patch "vfio/type1, arm64: untag user pointers". Changes in v12: - Changed untagging in tcp_zerocopy_receive() to also untag zc->address. - Fixed untagging in prctl_set_mm* to only untag pointers for vma lookups and validity checks, but leave them as is for actual user space accesses. - Updated the link to the v2 of the "arm64 relaxed ABI" patchset [3]. - Dropped the documentation patch, as the "arm64 relaxed ABI" patchset [3] handles that. Changes in v11: - Added "uprobes, arm64: untag user pointers in find_active_uprobe" patch. - Added "bpf, arm64: untag user pointers in stack_map_get_build_id_offset" patch. - Fixed "tracing, arm64: untag user pointers in seq_print_user_ip" to correctly perform subtration with a tagged addr. - Moved untagged_addr() from SYSCALL_DEFINE3(mprotect) and SYSCALL_DEFINE4(pkey_mprotect) to do_mprotect_pkey(). - Moved untagged_addr() definition for other arches from include/linux/memory.h to include/linux/mm.h. - Changed untagging in strn*_user() to perform userspace accesses through tagged pointers. - Updated the documentation to mention that passing tagged pointers to memory syscalls is allowed. - Updated the test to use malloc'ed memory instead of stack memory. Changes in v10: - Added "mm, arm64: untag user pointers passed to memory syscalls" back. - New patch "fs, arm64: untag user pointers in fs/userfaultfd.c". - New patch "net, arm64: untag user pointers in tcp_zerocopy_receive". - New patch "kernel, arm64: untag user pointers in prctl_set_mm*". - New patch "tracing, arm64: untag user pointers in seq_print_user_ip". Changes in v9: - Rebased onto 4.20-rc6. - Used u64 instead of __u64 in type casts in the untagged_addr macro for arm64. - Added braces around (addr) in the untagged_addr macro for other arches. Changes in v8: - Rebased onto 65102238 (4.20-rc1). - Added a note to the cover letter on why syscall wrappers/shims that untag user pointers won't work. - Added a note to the cover letter that this patchset has been merged into the Pixel 2 kernel tree. - Documentation fixes, in particular added a list of syscalls that don't support tagged user pointers. Changes in v7: - Rebased onto 17b57b18 (4.19-rc6). - Dropped the "arm64: untag user address in __do_user_fault" patch, since the existing patches already handle user faults properly. - Dropped the "usb, arm64: untag user addresses in devio" patch, since the passed pointer must come from a vma and therefore be untagged. - Dropped the "arm64: annotate user pointers casts detected by sparse" patch (see the discussion to the replies of the v6 of this patchset). - Added more context to the cover letter. - Updated Documentation/arm64/tagged-pointers.txt. Changes in v6: - Added annotations for user pointer casts found by sparse. - Rebased onto 050cdc6c (4.19-rc1+). Changes in v5: - Added 3 new patches that add untagging to places found with static analysis. - Rebased onto 44c929e1 (4.18-rc8). Changes in v4: - Added a selftest for checking that passing tagged pointers to the kernel succeeds. - Rebased onto 81e97f013 (4.18-rc1+). Changes in v3: - Rebased onto e5c51f30 (4.17-rc6+). - Added linux-arch@ to the list of recipients. Changes in v2: - Rebased onto 2d618bdf (4.17-rc3+). - Removed excessive untagging in gup.c. - Removed untagging pointers returned from __uaccess_mask_ptr. Changes in v1: - Rebased onto 4.17-rc1. Changes in RFC v2: - Added "#ifndef untagged_addr..." fallback in linux/uaccess.h instead of defining it for each arch individually. - Updated Documentation/arm64/tagged-pointers.txt. - Dropped "mm, arm64: untag user addresses in memory syscalls". - Rebased onto 3eb2ce82 (4.16-rc7). Signed-off-by: Andrey Konovalov <andreyknvl(a)google.com> Andrey Konovalov (14): arm64: untag user pointers in access_ok and __uaccess_mask_ptr lib: untag user pointers in strn*_user mm: untag user pointers passed to memory syscalls mm: untag user pointers in mm/gup.c mm: untag user pointers in get_vaddr_frames fs/namespace: untag user pointers in copy_mount_options userfaultfd: untag user pointers drm/amdgpu: untag user pointers drm/radeon: untag user pointers in radeon_gem_userptr_ioctl IB/mlx4: untag user pointers in mlx4_get_umem_mr media/v4l2-core: untag user pointers in videobuf_dma_contig_user_get tee/shm: untag user pointers in tee_shm_register vfio/type1: untag user pointers in vaddr_get_pfn selftests, arm64: add a selftest for passing tagged pointers to kernel Catalin Marinas (1): arm64: Introduce prctl() options to control the tagged user addresses ABI arch/arm64/Kconfig | 9 +++ arch/arm64/include/asm/processor.h | 8 ++ arch/arm64/include/asm/thread_info.h | 1 + arch/arm64/include/asm/uaccess.h | 12 ++- arch/arm64/kernel/process.c | 73 +++++++++++++++++++ .../gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c | 2 +- drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c | 2 + drivers/gpu/drm/radeon/radeon_gem.c | 2 + drivers/infiniband/hw/mlx4/mr.c | 7 +- drivers/media/v4l2-core/videobuf-dma-contig.c | 9 ++- drivers/tee/tee_shm.c | 1 + drivers/vfio/vfio_iommu_type1.c | 2 + fs/namespace.c | 2 +- fs/userfaultfd.c | 22 +++--- include/uapi/linux/prctl.h | 5 ++ kernel/sys.c | 12 +++ lib/strncpy_from_user.c | 3 +- lib/strnlen_user.c | 3 +- mm/frame_vector.c | 2 + mm/gup.c | 4 + mm/madvise.c | 2 + mm/mempolicy.c | 3 + mm/migrate.c | 2 +- mm/mincore.c | 2 + mm/mlock.c | 4 + mm/mprotect.c | 2 + mm/mremap.c | 7 ++ mm/msync.c | 2 + 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 ++++++++ 32 files changed, 233 insertions(+), 25 deletions(-) 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 -- 2.22.0.709.g102302147b-goog

4 8

[PATCH] drm/tilcdc: Check priv->crtc validity in cpufreq_transition()
by Peter Ujfalusi 02 Aug '19

02 Aug '19

The notifier can be called before we have crtc. With the check we can avoid NULL pointer dereference within tilcdc_crtc_update_clk(). Signed-off-by: Peter Ujfalusi <peter.ujfalusi(a)ti.com> --- drivers/gpu/drm/tilcdc/tilcdc_drv.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/tilcdc/tilcdc_drv.c b/drivers/gpu/drm/tilcdc/tilcdc_drv.c index 3046a4a4232d..85093123722d 100644 --- a/drivers/gpu/drm/tilcdc/tilcdc_drv.c +++ b/drivers/gpu/drm/tilcdc/tilcdc_drv.c @@ -169,7 +169,7 @@ static int cpufreq_transition(struct notifier_block *nb, struct tilcdc_drm_private *priv = container_of(nb, struct tilcdc_drm_private, freq_transition); - if (val == CPUFREQ_POSTCHANGE) + if (val == CPUFREQ_POSTCHANGE && priv->crtc) tilcdc_crtc_update_clk(priv->crtc); return 0; -- Peter Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki

2 2

[PATCH] drm/komeda: Adds error event print functionality
by Lowry Li (Arm Technology China) 02 Aug '19

02 Aug '19

From: "Lowry Li (Arm Technology China)" <Lowry.Li(a)arm.com> Adds to print the event message when error happens and the same event will not be printed until next vsync. Changes since v1: 1. Handling the event print by CONFIG_KOMEDA_ERROR_PRINT; 2. Changing the max string size to 256. Signed-off-by: Lowry Li (Arm Technology China) <lowry.li(a)arm.com> --- drivers/gpu/drm/arm/display/Kconfig | 6 + drivers/gpu/drm/arm/display/komeda/Makefile | 2 + drivers/gpu/drm/arm/display/komeda/komeda_dev.h | 15 +++ drivers/gpu/drm/arm/display/komeda/komeda_event.c | 141 ++++++++++++++++++++++ drivers/gpu/drm/arm/display/komeda/komeda_kms.c | 4 + 5 files changed, 168 insertions(+) create mode 100644 drivers/gpu/drm/arm/display/komeda/komeda_event.c diff --git a/drivers/gpu/drm/arm/display/Kconfig b/drivers/gpu/drm/arm/display/Kconfig index cec0639..e87ff86 100644 --- a/drivers/gpu/drm/arm/display/Kconfig +++ b/drivers/gpu/drm/arm/display/Kconfig @@ -12,3 +12,9 @@ config DRM_KOMEDA Processor driver. It supports the D71 variants of the hardware. If compiled as a module it will be called komeda. + +config DRM_KOMEDA_ERROR_PRINT + bool "Enable komeda error print" + depends on DRM_KOMEDA + help + Choose this option to enable error printing. diff --git a/drivers/gpu/drm/arm/display/komeda/Makefile b/drivers/gpu/drm/arm/display/komeda/Makefile index 5c3900c..f095a1c 100644 --- a/drivers/gpu/drm/arm/display/komeda/Makefile +++ b/drivers/gpu/drm/arm/display/komeda/Makefile @@ -22,4 +22,6 @@ komeda-y += \ d71/d71_dev.o \ d71/d71_component.o +komeda-$(CONFIG_DRM_KOMEDA_ERROR_PRINT) += komeda_event.o + obj-$(CONFIG_DRM_KOMEDA) += komeda.o diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_dev.h b/drivers/gpu/drm/arm/display/komeda/komeda_dev.h index d1c86b6..e28e7e6 100644 --- a/drivers/gpu/drm/arm/display/komeda/komeda_dev.h +++ b/drivers/gpu/drm/arm/display/komeda/komeda_dev.h @@ -40,6 +40,17 @@ #define KOMEDA_ERR_TTNG BIT_ULL(30) #define KOMEDA_ERR_TTF BIT_ULL(31) +#define KOMEDA_ERR_EVENTS \ + (KOMEDA_EVENT_URUN | KOMEDA_EVENT_IBSY | KOMEDA_EVENT_OVR |\ + KOMEDA_ERR_TETO | KOMEDA_ERR_TEMR | KOMEDA_ERR_TITR |\ + KOMEDA_ERR_CPE | KOMEDA_ERR_CFGE | KOMEDA_ERR_AXIE |\ + KOMEDA_ERR_ACE0 | KOMEDA_ERR_ACE1 | KOMEDA_ERR_ACE2 |\ + KOMEDA_ERR_ACE3 | KOMEDA_ERR_DRIFTTO | KOMEDA_ERR_FRAMETO |\ + KOMEDA_ERR_ZME | KOMEDA_ERR_MERR | KOMEDA_ERR_TCF |\ + KOMEDA_ERR_TTNG | KOMEDA_ERR_TTF) + +#define KOMEDA_WARN_EVENTS KOMEDA_ERR_CSCE + /* malidp device id */ enum { MALI_D71 = 0, @@ -207,4 +218,8 @@ struct komeda_dev { struct komeda_dev *dev_to_mdev(struct device *dev); +#ifdef CONFIG_DRM_KOMEDA_ERROR_PRINT +void komeda_print_events(struct komeda_events *evts); +#endif + #endif /*_KOMEDA_DEV_H_*/ diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_event.c b/drivers/gpu/drm/arm/display/komeda/komeda_event.c new file mode 100644 index 0000000..57b60cd --- /dev/null +++ b/drivers/gpu/drm/arm/display/komeda/komeda_event.c @@ -0,0 +1,141 @@ +// SPDX-License-Identifier: GPL-2.0 +/* + * (C) COPYRIGHT 2019 ARM Limited. All rights reserved. + * Author: James.Qian.Wang <james.qian.wang(a)arm.com> + * + */ +#include <drm/drm_print.h> + +#include "komeda_dev.h" + +struct komeda_str { + char *str; + u32 sz; + u32 len; +}; + +/* return 0 on success, < 0 on no space. + */ +static int komeda_sprintf(struct komeda_str *str, const char *fmt, ...) +{ + va_list args; + int num, free_sz; + int err; + + free_sz = str->sz - str->len; + if (free_sz <= 0) + return -ENOSPC; + + va_start(args, fmt); + + num = vsnprintf(str->str + str->len, free_sz, fmt, args); + + va_end(args); + + if (num <= free_sz) { + str->len += num; + err = 0; + } else { + str->len = str->sz; + err = -ENOSPC; + } + + return err; +} + +static void evt_sprintf(struct komeda_str *str, u64 evt, const char *msg) +{ + if (evt) + komeda_sprintf(str, msg); +} + +static void evt_str(struct komeda_str *str, u64 events) +{ + if (events == 0ULL) { + evt_sprintf(str, 1, "None"); + return; + } + + evt_sprintf(str, events & KOMEDA_EVENT_VSYNC, "VSYNC|"); + evt_sprintf(str, events & KOMEDA_EVENT_FLIP, "FLIP|"); + evt_sprintf(str, events & KOMEDA_EVENT_EOW, "EOW|"); + evt_sprintf(str, events & KOMEDA_EVENT_MODE, "OP-MODE|"); + + evt_sprintf(str, events & KOMEDA_EVENT_URUN, "UNDERRUN|"); + evt_sprintf(str, events & KOMEDA_EVENT_OVR, "OVERRUN|"); + + /* GLB error */ + evt_sprintf(str, events & KOMEDA_ERR_MERR, "MERR|"); + evt_sprintf(str, events & KOMEDA_ERR_FRAMETO, "FRAMETO|"); + + /* DOU error */ + evt_sprintf(str, events & KOMEDA_ERR_DRIFTTO, "DRIFTTO|"); + evt_sprintf(str, events & KOMEDA_ERR_FRAMETO, "FRAMETO|"); + evt_sprintf(str, events & KOMEDA_ERR_TETO, "TETO|"); + evt_sprintf(str, events & KOMEDA_ERR_CSCE, "CSCE|"); + + /* LPU errors or events */ + evt_sprintf(str, events & KOMEDA_EVENT_IBSY, "IBSY|"); + evt_sprintf(str, events & KOMEDA_ERR_AXIE, "AXIE|"); + evt_sprintf(str, events & KOMEDA_ERR_ACE0, "ACE0|"); + evt_sprintf(str, events & KOMEDA_ERR_ACE1, "ACE1|"); + evt_sprintf(str, events & KOMEDA_ERR_ACE2, "ACE2|"); + evt_sprintf(str, events & KOMEDA_ERR_ACE3, "ACE3|"); + + /* LPU TBU errors*/ + evt_sprintf(str, events & KOMEDA_ERR_TCF, "TCF|"); + evt_sprintf(str, events & KOMEDA_ERR_TTNG, "TTNG|"); + evt_sprintf(str, events & KOMEDA_ERR_TITR, "TITR|"); + evt_sprintf(str, events & KOMEDA_ERR_TEMR, "TEMR|"); + evt_sprintf(str, events & KOMEDA_ERR_TTF, "TTF|"); + + /* CU errors*/ + evt_sprintf(str, events & KOMEDA_ERR_CPE, "COPROC|"); + evt_sprintf(str, events & KOMEDA_ERR_ZME, "ZME|"); + evt_sprintf(str, events & KOMEDA_ERR_CFGE, "CFGE|"); + evt_sprintf(str, events & KOMEDA_ERR_TEMR, "TEMR|"); + + if (str->len > 0 && (str->str[str->len - 1] == '|')) { + str->str[str->len - 1] = 0; + str->len--; + } +} + +static bool is_new_frame(struct komeda_events *a) +{ + return (a->pipes[0] | a->pipes[1]) & + (KOMEDA_EVENT_FLIP | KOMEDA_EVENT_EOW); +} + +void komeda_print_events(struct komeda_events *evts) +{ + u64 print_evts = KOMEDA_ERR_EVENTS; + static bool en_print = true; + + /* reduce the same msg print, only print the first evt for one frame */ + if (evts->global || is_new_frame(evts)) + en_print = true; + if (!en_print) + return; + + if ((evts->global | evts->pipes[0] | evts->pipes[1]) & print_evts) { + #define STR_SZ 256 + char msg[STR_SZ]; + struct komeda_str str; + + str.str = msg; + str.sz = STR_SZ; + str.len = 0; + + komeda_sprintf(&str, "gcu: "); + evt_str(&str, evts->global); + komeda_sprintf(&str, ", pipes[0]: "); + evt_str(&str, evts->pipes[0]); + komeda_sprintf(&str, ", pipes[1]: "); + evt_str(&str, evts->pipes[1]); + + DRM_ERROR("err detect: %s\n", msg); + + en_print = false; + } +} diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_kms.c b/drivers/gpu/drm/arm/display/komeda/komeda_kms.c index 419a8b0..0fafc36 100644 --- a/drivers/gpu/drm/arm/display/komeda/komeda_kms.c +++ b/drivers/gpu/drm/arm/display/komeda/komeda_kms.c @@ -47,6 +47,10 @@ static irqreturn_t komeda_kms_irq_handler(int irq, void *data) memset(&evts, 0, sizeof(evts)); status = mdev->funcs->irq_handler(mdev, &evts); +#ifdef CONFIG_DRM_KOMEDA_ERROR_PRINT + komeda_print_events(&evts); +#endif + /* Notify the crtc to handle the events */ for (i = 0; i < kms->n_crtcs; i++) komeda_crtc_handle_event(&kms->crtcs[i], &evts); -- 1.9.1

3 3

[Bug 111272] [DRI_PRIME] Error on multi GPU with only one enabled
by bugzilla-daemon＠freedesktop.org 02 Aug '19

02 Aug '19

https://bugs.freedesktop.org/show_bug.cgi?id=111272 Bug ID: 111272 Summary: [DRI_PRIME] Error on multi GPU with only one enabled Product: DRI Version: XOrg git Hardware: Other OS: All Status: NEW Severity: normal Priority: medium Component: DRM/AMDgpu Assignee: dri-devel(a)lists.freedesktop.org Reporter: parker.l.reed(a)gmail.com Created attachment 144921 --> https://bugs.freedesktop.org/attachment.cgi?id=144921&action=edit DRI PRIME 0 I have a Razer Blade Stealth late 2016 with a Razer Core V1 and an RX 560. Arch Linux Linux stealth 5.2.1-arch1-1-fsync #1 SMP PREEMPT Mon Jul 22 17:40:06 PDT 2019 x86_64 GNU/Linux mesa-aco-git 19.2.0_devel.114720.5c6077221dd-1 (Also happens on normal mesa-git and mesa stable) With only the AMDGPU enabled for Xorg, DRI_PRIME=1 attempts to use Intel, falls back to AMD as expected, but has the weird behavior of completely bypassing vsync. DRI_PRIME=0 works as expected Expected behavior is to ignore the Intel card since it's not currently loaded in Xorg. I can obviously set DRI_PRIME=0 and be fine, but the DRI_PRIME=1 behavior seems to be a bug. Xorg conf Section "Device" Identifier "AMD" Driver "amdgpu" BusID "PCI:07:0:0" EndSection xrandr corroborates this in the listproviders output Providers: number : 1 Provider 0: id: 0x57 cap: 0xf, Source Output, Sink Output, Source Offload, Sink Offload crtcs: 5 outputs: 3 associated providers: 0 name:AMD Radeon (TM) RX 460 Graphics @ pci:0000:07:00.0 DRI_PRIME=1 glxinfo reports the same info aside from an error at the top of the output libGL error: Different GPU, but blitImage not implemented for this driver libGL error: failed to load driver: i965 Full glxinfo attached for DRI_PRIME=0, DRI_PRIME=1, and DRI_PRIME=1 with vblank_mode=1 glxgears for FPS example $ DRI_PRIME=0 glxgears Running synchronized to the vertical refresh. The framerate should be approximately the same as the monitor refresh rate. 333 frames in 5.0 seconds = 66.549 FPS 300 frames in 5.0 seconds = 59.999 FPS 300 frames in 5.0 seconds = 59.997 FPS 301 frames in 5.0 seconds = 60.001 FPS $ DRI_PRIME=1 glxgears libGL error: Different GPU, but blitImage not implemented for this driver libGL error: failed to load driver: i965 Running synchronized to the vertical refresh. The framerate should be approximately the same as the monitor refresh rate. 42158 frames in 5.0 seconds = 8431.391 FPS 42406 frames in 5.0 seconds = 8481.144 FPS 42266 frames in 5.0 seconds = 8453.060 FPS 42444 frames in 5.0 seconds = 8488.649 FPS $ vblank_mode=1 DRI_PRIME=1 glxgears libGL error: Different GPU, but blitImage not implemented for this driver libGL error: failed to load driver: i965 ATTENTION: default value of option vblank_mode overridden by environment. 42081 frames in 5.0 seconds = 8415.999 FPS 42527 frames in 5.0 seconds = 8505.298 FPS 42591 frames in 5.0 seconds = 8518.191 FPS 42508 frames in 5.0 seconds = 8501.433 FPS -- You are receiving this mail because: You are the assignee for the bug.

1 8

[PATCH v2 0/5] Add supply property for DSI controller
by Yannick Fertré 02 Aug '19

02 Aug '19

The DSI controller needs a new property that powers its physical layer. Binding has been updated to documented this property. Device tree of stm32mp157c soc. Move reg18 & reg11 to stm32mp157c device tree file. Remove property phy-dsi-supply property to stm32mp157c-dk2.dts file. Changes in v2: - rename patch drm/stm: dsi: add support of an optional regulator - rework dw_mipi_dsi-stm probe sequence Yannick Fertré (5): dt-bindings: display: stm32: add supply property to DSI controller drm/stm: dsi: add support of an optional regulator ARM: dts: stm32: add phy-dsi-supply property on stm32mp157c ARM: dts: stm32: move fixe regulators reg11 & reg18 ARM: dts: stm32: remove phy-dsi-supply property on stm32mp157c-dk2 board .../devicetree/bindings/display/st,stm32-ltdc.txt | 3 +++ arch/arm/boot/dts/stm32mp157c-dk2.dts | 9 --------- arch/arm/boot/dts/stm32mp157c-ed1.dts | 16 ---------------- arch/arm/boot/dts/stm32mp157c.dtsi | 17 +++++++++++++++++ drivers/gpu/drm/stm/dw_mipi_dsi-stm.c | 45 +++++++++++++++++++--- 5 files changed, 40 insertions(+), 25 deletions(-) -- 2.7.4

4 13

[PATCH 1/2] drm/etnaviv: fix etnaviv_cmdbuf_suballoc_new return value
by Lucas Stach 02 Aug '19

02 Aug '19

The call site expects to get either a valid suballoc or an error pointer, so a NULL return will not be treated as an error. Make sure to always return a proper error pointer in case something goes wrong. Signed-off-by: Lucas Stach <l.stach(a)pengutronix.de> --- drivers/gpu/drm/etnaviv/etnaviv_cmdbuf.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/etnaviv/etnaviv_cmdbuf.c b/drivers/gpu/drm/etnaviv/etnaviv_cmdbuf.c index bb4900bc1c4c..7b77992f31c4 100644 --- a/drivers/gpu/drm/etnaviv/etnaviv_cmdbuf.c +++ b/drivers/gpu/drm/etnaviv/etnaviv_cmdbuf.c @@ -48,8 +48,10 @@ etnaviv_cmdbuf_suballoc_new(struct etnaviv_gpu * gpu) suballoc->vaddr = dma_alloc_wc(gpu->dev, SUBALLOC_SIZE, &suballoc->paddr, GFP_KERNEL); - if (!suballoc->vaddr) + if (!suballoc->vaddr) { + ret = -ENOMEM; goto free_suballoc; + } ret = etnaviv_iommu_get_suballoc_va(gpu, suballoc->paddr, &suballoc->vram_node, SUBALLOC_SIZE, @@ -64,7 +66,7 @@ etnaviv_cmdbuf_suballoc_new(struct etnaviv_gpu * gpu) free_suballoc: kfree(suballoc); - return NULL; + return ERR_PTR(ret); } void etnaviv_cmdbuf_suballoc_destroy(struct etnaviv_cmdbuf_suballoc *suballoc) -- 2.20.1

3 5

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

dri-devel August 2019