- 28 Aug, 2017 9 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 <jason@jlekstrand.net> Signed-off-by: Dave Airlie <airlied@redhat.com>
-
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 <jason@jlekstrand.net> Cc: Dave Airlie <airlied@redhat.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Christian König <christian.koenig@amd.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
-
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 <jason@jlekstrand.net> Signed-off-by: Dave Airlie <airlied@redhat.com>
-
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: Jason Ekstrand <jason@jlekstrand.net> Signed-off-by: Dave Airlie <airlied@redhat.com>
-
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: Dave Airlie <airlied@redhat.com> Reviewed-by: Jason Ekstrand <jason@jlekstrand.net> Acked-by: Christian König <christian.koenig@amd.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
-
Jason Ekstrand authored
Signed-off-by: Jason Ekstrand <jason@jlekstrand.net> Signed-off-by: Dave Airlie <airlied@redhat.com>
-
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 <jason@jlekstrand.net> Acked-by: Christian König <christian.koenig@amd.com> (v1) Signed-off-by: Dave Airlie <airlied@redhat.com>
-
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: Jason Ekstrand <jason@jlekstrand.net> Acked-by: Christian König <christian.koenig@amd.com> (v1) Signed-off-by: Dave Airlie <airlied@redhat.com>
-
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: Dave Airlie <airlied@redhat.com>
-
- 24 Aug, 2017 4 commits
-
-
Dave Airlie authored
Merge tag 'sunxi-drm-for-4.14-2' of https://git.kernel.org/pub/scm/linux/kernel/git/mripard/linux into drm-next sun4i DRM changes for 4.14, take 2 A single patch switching to a new OF helper. * tag 'sunxi-drm-for-4.14-2' of https://git.kernel.org/pub/scm/linux/kernel/git/mripard/linux: drm/sun4i: use of_graph_get_remote_endpoint()
-
Dave Airlie authored
Merge tag 'omapdrm-4.14-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/tomba/linux into drm-next omapdrm fixes for 4.14 * fix compilation when compiling omapfb driver * WA for OMAP3 endless sync lost issue * WA for OMAP5 DSI PLL issue * fix analog TV out modecheck * tag 'omapdrm-4.14-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/tomba/linux: ARM: OMAP2+: fix missing variable declaration drm/omap: work-around for omap3 display enable drm/omap: fix i886 work-around drm/omap: fix analog tv-out modecheck
-
git://people.freedesktop.org/~robclark/linuxDave Airlie authored
Updates for 4.14.. I have some further patches from Jordan to add multiple priority levels and pre-emption, but those will probably be for 4.15 to give me time for the mesa parts. * tag 'drm-msm-next-2017-08-22' of git://people.freedesktop.org/~robclark/linux: drm/msm/mdp5: mark runtime_pm functions as __maybe_unused drm/msm: remove unused variable drm/msm/mdp5: make helper function static drm/msm: make msm_framebuffer_init() static drm/msm: add helper to allocate stolen fb drm/msm: don't track fbdev's gem object separately drm/msm: add modeset module param drm/msm/mdp5: add tracking for clk enable-count drm/msm: remove unused define drm/msm: Add a helper function for in-kernel buffer allocations drm/msm: Attach the GPU MMU when it is created drm/msm: Add A5XX hardware fault detection drm/msm: Remove uneeded platform dev members drm/msm/mdp5: Set up runtime PM for MDSS drm/msm/mdp5: Write to SMP registers even if allocations don't change drm/msm/mdp5: Don't use mode_set helper funcs for encoders and CRTCs drm/msm/dsi: Implement RPM suspend/resume callbacks drm/msm/dsi: Set up runtime PM for DSI drm/msm/hdmi: Set up runtime PM for HDMI drm/msm/mdp5: Use runtime PM get/put API instead of toggling clocks
-
Arnd Bergmann authored
The function that was added doesn't actually build: arch/arm/mach-omap2/display.c: In function 'omapdss_init_fbdev': arch/arm/mach-omap2/display.c:184:2: error: 'r' undeclared (first use in this function) This adds a declaration for 'r' to fix it. Fixes: 5ce78302 ("ARM: OMAP2+: Don't register omapdss device for omapdrm") Signed-off-by: Arnd Bergmann <arnd@arndb.de> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Acked-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
-
- 23 Aug, 2017 4 commits
-
-
Kuninori Morimoto authored
Now, we can use of_graph_get_remote_endpoint(). Let's use it. Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
-
Tomi Valkeinen authored
Seems that on omap3 enabling a crtc without any planes causes a sync lost flood. This only happens on the first enable, and after that it works. This looks like an HW issue and it's unclear why this is happening or how to fix it. This started happening after 897145d0 ("drm/omapdrm: Move commit_modeset_enables() before commit_planes()") which, as a work-around, changed omapdrm first to do the modeset enable, and plane set only after that. This WA should be fine on all DSS versions, but apparently OMAP3 DSS is an exception. This patch reverts that work-around for OMAP3 DSS. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
-
Tomi Valkeinen authored
7d267f06 ("drm/omap: work-around for errata i886") changed how the PLL dividers and multipliers are calculated. While the new way should work fine for all the PLLs, it breaks omap5 PLLs. The issues seen are rather odd: seemed that the output clock rate is half of what we asked. It is unclear what's causing there issues. As a work-around this patch adds a "errata_i886" flag, which is set only for DRA7's PLLs, and the PLL setup is done according to that flag. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com> Tested-by: H. Nikolaus Schaller <hns@goldelico.com>
-
Tomi Valkeinen authored
omapdrm rejects all venc (analog tv-out) videomodes, due to somewhat strict checking of the values, making tv-out unusable. We only support two videomodes, one for PAL and one for NTSC, so instead of trying to check every field in the videomode struct, this patch makes the driver check only the pixel clock and the size of the display. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
-
- 22 Aug, 2017 23 commits
-
-
git://github.com/skeggsb/linuxDave Airlie authored
Not a lot that's ready to be included this round for Nouveau. GP108 modesetting support, and misc other fixes. * 'linux-4.14' of git://github.com/skeggsb/linux: drm/nouveau/kms/nv50: perform null check on msto[i] rathern than msto drm/nouveau/pci/msi: disable MSI on big-endian platforms by default drm/nouveau: silence suspend/resume debugging messages drm/nouveau/kms/nv04-nv4x: fix exposed format list drm/nouveau/kms/nv10-nv40: add NV21 support to overlay drm/nouveau/kms/nv04-nv40: improve overlay error detection, fix pitch setting drm/nouveau/kms/nv04-nv40: prevent undisplayable framebuffers from creation drm/nouveau/mpeg: print more debug info when rejecting dma objects drm/nouveau/fb/gf100-: zero mmu debug buffers drm/nouveau/bar/gf100: add config option to limit BAR2 to 16MiB initial support (display-only) for GP108 drm/nouveau/falcon: use a more reasonable msgqueue timeout value drm/nouveau/disp: Silence DCB warnings. drm/nouveau/bios: Demote missing fp table message to NV_DEBUG. drm/nouveau/pmu/gt215-: abstract detection of whether reset is needed drm/nouveau/pmu/gt215: fix reset drm/nouveau/mc/gf100: add pmu to reset mask drm/nouveau/disp/gf119-: avoid creating non-existent heads drm/nouveau/therm/gm200: Added drm/nouveau/therm: fix spelling mistake on array thresolds
-
Arnd Bergmann authored
When CONFIG_PM is disabled, we get harmless warnings about unused functions: drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c:1025:12: error: 'mdp5_runtime_resume' defined but not used [-Werror=unused-function] static int mdp5_runtime_resume(struct device *dev) ^~~~~~~~~~~~~~~~~~~ drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c:1015:12: error: 'mdp5_runtime_suspend' defined but not used [-Werror=unused-function] static int mdp5_runtime_suspend(struct device *dev) ^~~~~~~~~~~~~~~~~~~~ This marks both functions as __maybe_unused so the compiler can drop them silently. Fixes: d68fe15b ("drm/msm/mdp5: Use runtime PM get/put API instead of toggling clocks") Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Rob Clark <robdclark@gmail.com>
-
Arnd Bergmann authored
A cleanup left behind an unused variable that we have to remove in order to avoid this harmless warning: drivers/gpu/drm/msm/adreno/a5xx_gpu.c: In function 'a5xx_zap_shader_init': drivers/gpu/drm/msm/adreno/a5xx_gpu.c:493:19: error: unused variable 'a5xx_gpu' [-Werror=unused-variable] Fixes: 8d6f0827 ("drm/msm: Remove uneeded platform dev members") Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Rob Clark <robdclark@gmail.com>
-
Rob Clark authored
Not needed outside of mdp5_crtc.c. Signed-off-by: Rob Clark <robdclark@gmail.com>
-
Rob Clark authored
Only needed in msm_fb.c so don't export it. Signed-off-by: Rob Clark <robdclark@gmail.com>
-
Rob Clark authored
We'll later want to re-use this for state-readback when bootloader enables display, so that we can create an fb for the initial plane->state->fb. Signed-off-by: Rob Clark <robdclark@gmail.com>
-
Rob Clark authored
The drm_framebuffer is refcnt'd these days and will unref the underlying bo as needed. So we can simplify a little. Signed-off-by: Rob Clark <robdclark@gmail.com>
-
Rob Clark authored
At least for debugging it is nice to have an easy way to force the driver not to load. Signed-off-by: Rob Clark <robdclark@gmail.com>
-
Rob Clark authored
Accessing registers for an unclocked block is an insta-reboot on snapdragon devices. So add a bit of logic to track the enable_count so we can WARN_ON() unclocked register writes. This makes it much easier to track down mistakes. Signed-off-by: Rob Clark <robdclark@gmail.com>
-
Rob Clark authored
Signed-off-by: Rob Clark <robdclark@gmail.com>
-
Jordan Crouse authored
Nearly all of the buffer allocations for kernel allocate an buffer object, virtual address and GPU iova at the same time. Make a helper function to handle the details. Signed-off-by: Jordan Crouse <jcrouse@codeaurora.org> [dropped msm_fbdev conversion to new helper, since it interferes with display-handover work, where we want to separate allocation and mapping] Signed-off-by: Rob Clark <robdclark@gmail.com>
-
Jordan Crouse authored
Currently the GPU MMU is attached in the adreno_gpu code but as more and more of the GPU initialization moves to the generic GPU path we have a need to map and use GPU memory earlier and earlier. There isn't any reason to defer attaching the MMU until later so attach it right after the address space is created so it can be used immediately. Signed-off-by: Jordan Crouse <jcrouse@codeaurora.org> Signed-off-by: Rob Clark <robdclark@gmail.com>
-
Colin Ian King authored
The null check on the array msto is incorrect since msto is never null. The null check should be instead on msto[i] since this is being dereferenced in the call to drm_mode_connector_attach_encoder. Thanks to Emil Velikov for pointing out the mistake in my original fix and for suggesting the correct fix. Detected by CoverityScan, CID#1375915 ("Array compared against 0") Fixes: f479c0ba ("drm/nouveau/kms/nv50: initial support for DP 1.2 multi-stream") Signed-off-by: Colin Ian King <colin.king@canonical.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
-
Ilia Mirkin authored
It appears that MSI does not work on either G5 PPC nor on a E5500-based platform, where other hardware is reported to work fine with MSI. Both tests were conducted with NV4x hardware, so perhaps other (or even this) hardware can be made to work. It's still possible to force-enable with config=NvMSI=1 on load. Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu> Cc: stable@vger.kernel.org Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
-
Ben Skeggs authored
These are particularly annoying on Optimus systems where these paths can be called regularly. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
-
Ilia Mirkin authored
drm_crtc_init exposes the XRGB8888 and ARGB8888 formats. In actuality, ARGB8888's 32-bit depth messes up some formulas that weren't meant for it, and the alpha is fairly meaningless for the primary plane. The modesetting logic appears to be fully prepared for RGB565 as well as XRGB1555 however, as tested with modetest. Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
-
Ilia Mirkin authored
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
-
Ilia Mirkin authored
We were previously setting the pitch based on a perfectly packed buffer. This does not necessarily happen. Either modetest started generating such buffers recently, or earlier testing only happened with well-picked overlay sizes. While we're at it, beef up and refactor the error state detection. Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
-
Ilia Mirkin authored
Pre-nv50 YUV overlays have stringent requirements for working with the internal machinery. Instead of rejecting these at update_plane time, we should instead prevent the framebuffers from being created in the first place. Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
-
Ilia Mirkin authored
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu> Reviewed-by: Tobias Klausmann <tobias.johannes.klausmann@mni.thm.de> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
-
Ben Skeggs authored
These are used for accesses to sparse mappings, and we want reads of such mappings to return 0. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
-
Ben Skeggs authored
Useful for testing, and for the userspace build where we can't kick a framebuffer driver off the device. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
-
Ilia Mirkin authored
Forked from GP107 implementation. Secboot/gr left out as we don't have signed blobs from NVIDIA in linux-firmware. (Ben): Was unable to mmiotrace the binary driver for unknown reasons, so not able to 100% confirm that no other changes from GP107 are needed. Quick testing shows it seems to work well enough for display. Due to NVIDIA dragging their heels on getting signed firmware to us, this is the best we can do for now. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=101601Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
-