- 29 Aug, 2017 14 commits
-
-
Alex Deucher authored
Be more explicit and add comments explaining each case. Also s/gart/GART/ in the parameter string as per Felix' suggestion. Reviewed-by:
Felix Kuehling <Felix.Kuehling@amd.com> Reviewed-by:
Christian König <christian.koenig@amd.com> Signed-off-by:
Alex Deucher <alexander.deucher@amd.com>
-
Evan Quan authored
Signed-off-by:
Evan Quan <evan.quan@amd.com> Reviewed-by:
-
Christian König authored
When a process is killed we shouldn't submit all waiting jobs, but instead clean up as fast as possible. Signed-off-by:
Chunming Zhou <david1.zhou@amd.com> Signed-off-by:
-
Christian König authored
Set the shadow flag on the shadow and not the parent, always bind shadow BOs during allocation instead of manually, use the reservation_object wrappers to grab the lock. This fixes a couple of issues with binding the shadow BOs as well as correctly evicting them when memory becomes tight. Signed-off-by:
-
Alex Deucher authored
We need a larger gart for asics that do not support GPUVM on all engines (e.g., MM) to make sure we have enough space for all gtt buffers in physical mode. Change the default size based on the asic type. Reviewed-by:
-
Alex Deucher authored
Acked-by:
-
Evan Quan authored
Signed-off-by:
-
Emily Deng authored
For virtual display, it uses software timer to emulate the vsync interrupt, it doesn't have high precision, so doesn't support disable vblank immediately. BUG: SWDEV-129274 Signed-off-by:
Emily Deng <Emily.Deng@amd.com> Reviewed-by:
Michel Dänzer <michel.daenzer@amd.com> Signed-off-by:
-
Felix Kuehling authored
Correctly detect system memory mappings when using CPU and don't use huge pages for them. Avoid incorrectly translating a physical page table GPU address when splitting a huge page while mapping system memory. Signed-off-by:
-
git://people.freedesktop.org/~syeh/repos_linuxDave Airlie authored
vmwgfx add fence fd support. * 'drm-vmwgfx-next' of git://people.freedesktop.org/~syeh/repos_linux: drm/vmwgfx: Bump the version for fence FD support drm/vmwgfx: Add export fence to file descriptor support drm/vmwgfx: Add support for imported Fence File Descriptor drm/vmwgfx: Prepare to support fence fd drm/vmwgfx: Fix incorrect command header offset at restart drm/vmwgfx: Support the NOP_ERROR command drm/vmwgfx: Restart command buffers after errors drm/vmwgfx: Move irq bottom half processing to threads drm/vmwgfx: Don't use drm_irq_[un]install
-
Dave Airlie authored
Merge tag 'exynos-drm-next-for-v4.14' of git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos into drm-next Summary: - Provide NV12MT pixel format support of Mixer driver in generic way. - Refactor Exynos KMS drivers . Refactoring to panel detection way . Refactoring to setting up possible_crtcs . Refactoring to video and command mode support - Some cleanups * tag 'exynos-drm-next-for-v4.14' of git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos: drm/exynos: simplify set_pixfmt() in DECON and FIMD drivers drm/exynos: consistent use of cpp drm/exynos: mixer: remove src offset from mixer_graph_buffer() drm/exynos: mixer: simplify mixer_graph_buffer() drm/exynos: mixer: simplify vp_video_buffer() drm/exynos: mixer: enable NV12MT support for the video plane drm/exynos: mixer: fix chroma comment in vp_video_buffer() arm64: dts: exynos: remove i80-if-timings nodes dt-bindings: exynos5433-decon: remove i80-if-timings property drm/exynos/decon5433: use mode info stored in CRTC to detect i80 mode drm/exynos: add mode_valid callback to exynos_drm drm/exynos/decon5433: refactor irq requesting code drm/exynos/mic: use mode info stored in CRTC to detect i80 mode drm/exynos/dsi: propagate info about command mode from panel drm/exynos/dsi: refactor panel detection logic drm/exynos: use helper to set possible crtcs drm/exynos/decon5433: use readl_poll_timeout helpers
-
Dave Airlie authored
Merge tag 'drm-misc-next-fixes-2017-08-28' of git://anongit.freedesktop.org/git/drm-misc into drm-next UAPI Changes: - Rename u32 to __u32 in struct drm_format_modifier_blob (Lionel) Cc: Lionel Landwerlin <lionel.g.landwerlin@intel.com> * tag 'drm-misc-next-fixes-2017-08-28' of git://anongit.freedesktop.org/git/drm-misc: drm: rename u32 in __u32 in uapi
-
Jason Ekstrand authored
This IOCTL provides a mechanism for userspace to trigger a sync object directly. There are other ways that userspace can trigger a syncobj such as submitting a dummy batch somewhere or hanging on to a triggered sync_file and doing an import. This just provides an easy way to manually trigger the sync object without weird hacks. The motivation for this IOCTL is Vulkan fences. Vulkan lets you create a fence already in the signaled state so that you can wait on it immediatly without stalling. We could also handle this with a new create flag to ask the driver to create a syncobj that is already signaled but the IOCTL seemed a bit cleaner and more generic. v2: - Take an array of sync objects (Dave Airlie) v3: - Throw -EINVAL if pad != 0 Signed-off-by:
Jason Ekstrand <jason@jlekstrand.net> Signed-off-by:
Dave Airlie <airlied@redhat.com>
-
Jason Ekstrand authored
This just resets the dma_fence to NULL so it looks like it's never been signaled. This will be useful once we add the new wait API for allowing wait on "submit and signal" behavior. v2: - Take an array of sync objects (Dave Airlie) v3: - Throw -EINVAL if pad != 0 Signed-off-by:
-
- 28 Aug, 2017 18 commits
-
-
Jason Ekstrand authored
The wait ioctl has a bunch of code to read an syncobj handle array from userspace and turn it into an array of syncobj pointers. We're about to add two new IOCTLs which will need to work with arrays of syncobj handles so let's make some helpers. Signed-off-by:
-
Jason Ekstrand authored
Vulkan VkFence semantics require that the application be able to perform a CPU wait on work which may not yet have been submitted. This is perfectly safe because the CPU wait has a timeout which will get triggered eventually if no work is ever submitted. This behavior is advantageous for multi-threaded workloads because, so long as all of the threads agree on what fences to use up-front, you don't have the extra cross-thread synchronization cost of thread A telling thread B that it has submitted its dependent work and thread B is now free to wait. Within a single process, this can be implemented in the userspace driver by doing exactly the same kind of tracking the app would have to do using posix condition variables or similar. However, in order for this to work cross-process (as is required by VK_KHR_external_fence), we need to handle this in the kernel. This commit adds a WAIT_FOR_SUBMIT flag to DRM_IOCTL_SYNCOBJ_WAIT which instructs the IOCTL to wait for the syncobj to have a non-null fence and then wait on the fence. Combined with DRM_IOCTL_SYNCOBJ_RESET, you can easily get the Vulkan behavior. v2: - Fix a bug in the invalid syncobj error path - Unify the wait-all and wait-any cases v3: - Unify the timeout == 0 case a bit with the timeout > 0 case - Use wait_event_interruptible_timeout v4: - Use proxy fence v5: - Revert to a combination of v2 and v3 - Don't use proxy fences - Don't use wait_event_interruptible_timeout because it just adds an extra layer of callbacks Signed-off-by:
-
Jason Ekstrand authored
This requests that the driver create the sync object such that it already has a signaled dma_fence attached. Because we don't need anything in particular (just something signaled), we use a dummy null fence. This is useful for Vulkan which has a similar flag that can be passed to vkCreateFence. Signed-off-by:
-
Jason Ekstrand authored
It is useful in certain circumstances to know when the fence is replaced in a syncobj. Specifically, it may be useful to know when the fence goes from NULL to something valid. This does make syncobj_replace_fence a little more expensive because it has to take a lock but, in the common case where there is no callback list, it spends a very short amount of time inside the lock. v2: - Don't lock in drm_syncobj_fence_get. We only really need to lock around fence_replace to make the callback work. v3: - Fix the cb_list comment to make kbuild happy Signed-off-by:
-
Dave Airlie authored
This interface will allow sync object to be used to back Vulkan fences. This API is pretty much the vulkan fence waiting API, and I've ported the code from amdgpu. v2: accept relative timeout, pass remaining time back to userspace. v3: return to absolute timeouts. v4: absolute zero = poll, rewrite any/all code to have same operation for arrays return -EINVAL for 0 fences. v4.1: fixup fences allocation check, use u64_to_user_ptr v5: move to sec/nsec, and use timespec64 for calcs. v6: use -ETIME and drop the out status flag. (-ETIME is suggested by ickle, I can feel a shed painting) v7: talked to Daniel/Arnd, use ktime and ns everywhere. v8: be more careful in the timeout calculations use uint32_t for counter variables so we don't overflow graciously handle -ENOINT being returned from dma_fence_wait_timeout Signed-off-by: -
Jason Ekstrand authored
Signed-off-by:
-
Jason Ekstrand authored
The atomic exchange operation in drm_syncobj_replace_fence is sufficient for the case where it races with itself. However, if you have a race between a replace_fence and dma_fence_get(syncobj->fence), you may end up with the entire replace_fence happening between the point in time where the one thread gets the syncobj->fence pointer and when it calls dma_fence_get() on it. If this happens, then the reference may be dropped before we get a chance to get a new one. The new helper uses dma_fence_get_rcu_safe to get rid of the race. This is also needed because it allows us to do a bit more than just get a reference in drm_syncobj_fence_get should we wish to do so. v2: - RCU isn't that scary - Call rcu_read_lock/unlock - Don't rename fence to _fence - Make the helper static inline Signed-off-by:
-
Jason Ekstrand authored
The function has far more in common with drm_syncobj_find than with any in the get/put functions. Signed-off-by:
-
John Stultz authored
Currently the hikey dsi logic cannot generate accurate byte clocks values for all pixel clock values. Thus if a mode clock is selected that cannot match the calculated byte clock, the device will boot with a blank screen. This patch uses the new mode_valid callback (many thanks to Jose Abreu for upstreaming it!) to ensure we don't select modes we cannot generate. Also, since the ade crtc code will adjust the mode in mode_set, this patch also adds a mode_fixup callback which we use to make sure we are validating the mode clock that will eventually be used. Cc: Daniel Vetter <daniel.vetter@intel.com> Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Sean Paul <seanpaul@chromium.org> Cc: David Airlie <airlied@linux.ie> Cc: Rob Clark <robdclark@gmail.com> Cc: Xinliang Liu <xinliang.liu@linaro.org> Cc: Xinliang Liu <z.liuxinliang@hisilicon.com> Cc: Rongrong Zou <zourongrong@gmail.com> Cc: Xinwei Kong <kong.kongxinwei@hisilicon.com> Cc: Chen Feng <puck.chen@hisilicon.com> Cc: Jose Abreu <Jose.Abreu@synopsys.com> Cc: Archit Taneja <architt@codeaurora.org> Cc: dri-devel@lists.freedesktop.org Reviewed-by:
Sean Paul <seanpaul@chromium.org> Signed-off-by:
John Stultz <john.stultz@linaro.org> Reviewed-by:
Xinliang Liu <xinliang.liu@linaro.org> Signed-off-by:
-
Sinclair Yeh authored
Minor version bump to indicate support for fence FD Signed-off-by:
Sinclair Yeh <syeh@vmware.com> Reviewed-by:
Deepak Singh Rawat <drawat@vmware.com> Reviewed-by:
Thomas Hellstrom <thellstrom@vmware.com>
-
Sinclair Yeh authored
Added code to link a fence to a out_fence_fd file descriptor and thread out_fence_fd down to vmw_execbuf_copy_fence_user() so it can be copied into the IOCTL reply and be passed back up the the user. v2: Make sure to sync and clean up in case of failure Signed-off-by:
-
Sinclair Yeh authored
This allows vmwgfx to wait on a fence created by another device. v2: * Remove special handling for vmwgfx fence and just use dma_fence_wait() * Use interruptible waits * Added function documentation Signed-off-by:
-
Sinclair Yeh authored
Make the fields and flags available. Signed-off-by:
-
Thomas Hellstrom authored
Sometimes it appears like the device modifies the command header offset member. So explicitly clear it when restarting after an error. Signed-off-by:
-
Thomas Hellstrom authored
Can be used by user-space applications to test and verify the kernel command buffer error recovery functionality. Malicious user-space apps could potentially use this command to slow down graphics processing somewhat, but they could also accomplish the same thing using a random malformed command so this should be considered safe. At least as safe as it gets. Signed-off-by:
Brian Paul <brianp@vmware.com> Reviewed-by:
-
Thomas Hellstrom authored
Previously we skipped the command buffer and added an extra fence to avoid hangs due to skipped fence commands. Now we instead restart the command buffer after the failing command, if there are any commands left. In addition we print out some information about the failing command and its location in the command buffer. Testing Done: ran glxgears using mesa modified to send the NOP_ERROR command before each 10th clear and verified that we detected the device error properly and that there were no other device errors caused by incorrectly ordered command buffers. Also ran the piglit "quick" test suite which generates a couple of device errors and verified that they were handled as intended. Signed-off-by:
-
Thomas Hellstrom authored
This gets rid of the irq bottom half tasklets and instead performs the work needed in process context. We also convert irq-disabling spinlocks to ordinary spinlocks. This should decrease system latency for other system components, like sound for example but has the potential to increase latency for processes that wait on the GPU. Signed-off-by:
-
Thomas Hellstrom authored
We're not allowed to change the upstream version of the drm_irq_install function to be able to incorporate threaded irqs. So roll our own irq install- and uninstall functions instead of relying on the drm core ones. Signed-off-by:
-
- 25 Aug, 2017 8 commits
-
-
Lionel Landwerlin authored
All other fields use __ Cc: Ben Widawsky <ben@bwidawsk.net> Fixes: db1689aa ("drm: Create a format/modifier blob") Signed-off-by:
Lionel Landwerlin <lionel.g.landwerlin@intel.com> Signed-off-by:
Daniel Stone <daniels@collabora.com> Reviewed-by:
Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by:
Emil Velikov <emil.l.velikov@gmail.com> Reviewed-by:
Ben Widawsky <ben@bwidawsk.net> Reviewed-by:
-
Tobias Jakobi authored
DRM core already checks the validity of the pixelformat. Signed-off-by:
Tobias Jakobi <tjakobi@math.uni-bielefeld.de> Signed-off-by:
Inki Dae <inki.dae@samsung.com>
-
Tobias Jakobi authored
A recent commit (272725c7) has removed the use of 'bits_per_pixel' in DRM. However the corresponding Exynos driver code still uses the ambiguous 'bpp', even though it is now initialized from fb->cpp[0]. Consistenly use 'cpp' in FIMD, DECON7 and DECON5433 drivers. Signed-off-by:
-
Tobias Jakobi authored
We always translate the dma address such that the offsets of the source image are zero. Hence we can remove manipulation of the MXR_GRAPHIC_SXY(win) register and just zero them once in mixer_win_reset(). Signed-off-by:
-
Tobias Jakobi authored
DRM core already checks in drm_atomic_plane_check() if the pixelformat is valid. Hence we can collapse the default case of the switch statement with the XRGB8888 case. No functional change. Signed-off-by:
-
Tobias Jakobi authored
DRM core already checks in drm_atomic_plane_check() if the pixelformat is valid. Hence we can drop the default case of the switch statement and collapse most of the code. Also rename the two booleans to reflect what true/false actually means, and to avoid mixing CrCb/NV21 descriptions. No functional change. Signed-off-by:
-
Tobias Jakobi authored
The video processor supports a tiled version of the NV12 format, known as NV12MT in V4L2 terms. The support was removed in commit 083500ba due to not being a real pixel format, but rather NV12 with a special memory layout. With the introduction of FB modifiers, we can now properly support this format again. Tested with a hacked up modetest from libdrm's test suite on an ODROID-X2 (Exynos4412). Signed-off-by:
-
Tobias Jakobi authored
The current comment sounds like the division op is done to compensate for some hardware erratum. But the chroma plane having half the height of the luma plane is just the way NV12/NV21 is defined, so clarify this behaviour. Signed-off-by:
-
