- 20 Jun, 2017 6 commits
-
-
git://anongit.freedesktop.org/git/drm-intelDave Airlie authored
Final pile of features for 4.13 New uabi: - batch bo in first slot, for faster execbuf assembly in userspace (Chris Wilson) - (sub)slice getparam, needed for mesa perf support (Robert Bragg) First pile of patches for cnl/cfl support, maintained by Rodrigo but with lots of contributions from others. Still incomplete since public review still ongoing. Features/refactoring: - Make execbuf faster (Chris Wilson), a pile of series to make execbuf buffer handling have fewer passes, use less list walking, postpone more work to async workers and shuffle buffers less, all to make the common case much faster (in some cases at least). - cold boot support for glk dsi (Madhav Chauhan) - Clean up pipe A quirk and related old platform hacks (Ville) - perf sampling support for kbl/glk (Lionel) - perf cleanups (Robert Bragg) - wire atomic state to backlight code, to avoid pipe lookup hacks (Maarten) - reduce request waiting latency/overhead to remove the spinning and associated cpu cycle wasting (Chris) - fix 90/270 rotation wm computation (Ville) - new ddb allocation algo for skl (Kumar Mahesh) - fix regression due to system suspend optimiazatino (Imre) - the usual pile of small cleanups and refactors all over GVT updates contained in this tag: - optimization for per-VM mmio save/restore (Changbin) - optimization for mmio hash table (Changbin) - scheduler optimization with event (Ping) - vGPU reset refinement (Fred) - other misc refactor and cleanups, etc. * tag 'drm-intel-next-2017-06-19' of git://anongit.freedesktop.org/git/drm-intel: (170 commits) drm/i915: Update DRIVER_DATE to 20170619 drm/i915/cfl: Introduce Coffee Lake workarounds. drm/i915: Store 9 bits of PCI Device ID for platforms with a LP PCH drm/i915: Stash a pointer to the obj's resv in the vma drm/i915: Async GPU relocation processing drm/i915: Allow execbuffer to use the first object as the batch drm/i915: Wait upon userptr get-user-pages within execbuffer drm/i915: First try the previous execbuffer location drm/i915: Store a persistent reference for an object in the execbuffer cache drm/i915: Eliminate lots of iterations over the execobjects array drm/i915: Disable EXEC_OBJECT_ASYNC when doing relocations drm/i915: Pass vma to relocate entry drm/i915: Store a direct lookup from object handle to vma drm/i915: Fix retrieval of hangcheck stats drm/i915: Store i915_gem_object_is_coherent() as a bit next to cache-dirty drm/i915: Mark CPU cache as dirty on every transition for CPU writes drm/i915: Make i915_vma_destroy() static drm/i915: Actually attach the tv_format property to the SDVO connector Revert "drm/i915/skl: New ddb allocation algorithm" drm/i915/glk: Add cold boot sequence for GLK DSI ...
-
git://people.freedesktop.org/~robclark/linuxDave Airlie authored
This time around, the biggest thing is a bunch of GEM rework for more fine grained locking and prep work to handle multiple address spaces (ie. per-process pagetables). Also some HDMI fixes for 8x96 (snapdragon 820). One unrelated bus patch, for something that seems to get merged through whatever random tree (and has all the right ack's). * tag 'drm-msm-next-2017-06-20' of git://people.freedesktop.org/~robclark/linux: drm/msm: Fix potential buffer overflow issue bus: SIMPLE_PM_BUS does not depend on ARCH_RENESAS drm/msm: Separate locking of buffer resources from struct_mutex drm/msm/hdmi: Fix HDMI pink strip issue seen on 8x96 drm/msm/hdmi: 8996 PLL: Populate unprepare drm/msm/hdmi: Use bitwise operators when building register values drm/msm: update generated headers drm/msm: remove address-space id drm/msm: support for an arbitrary number of address spaces drm/msm: refactor how we handle vram carveout buffers drm/msm: pass address-space to _get_iova() and friends drm/msm/mdp4+5: move aspace/id to base class drm/msm/mdp5: kill pipe_lock drm/msm: fix locking inconsistency for gpu->hw_init() drm/msm: Remove memptrs->wptr drm/msm: Add a struct to pass configuration to msm_gpu_init() drm/msm: Add hint to DRM_IOCTL_MSM_GEM_INFO to return an object IOVA drm/msm: Remove idle function hook drm/msm: Remove DRM_MSM_NUM_IOCTLS drm/msm: gpu: Enable zap shader for A5XX
-
git://people.freedesktop.org/~agd5f/linuxDave Airlie authored
A few more things for 4.13: - Semaphore support using sync objects - Drop fb location programming - Optimize bo list ioctl * 'drm-next-4.13' of git://people.freedesktop.org/~agd5f/linux: drm/amdgpu: Optimize mutex usage (v4) drm/amdgpu: Optimization of AMDGPU_BO_LIST_OP_CREATE (v2) amdgpu: use drm sync objects for shared semaphores (v6) amdgpu/cs: split out fence dependency checking (v2) drm/amdgpu: don't check the default value for vm size
-
git://linux-arm.org/linux-ldDave Airlie authored
Here are the Mali DP driver changes. They include the mali-dp specific changes from Jose Abreu on crtc->mode_valid() as well as a couple of patches for fixing the sharing of IRQ lines and use of DRM CMA helper for framebuffer physical address calculation. Please pull! * 'for-upstream/mali-dp' of git://linux-arm.org/linux-ld: drm/arm: mali-dp: Use CMA helper for plane buffer address calculation drm/mali-dp: Check PM status when sharing interrupt lines drm/arm: malidp: Use crtc->mode_valid() callback
-
git://github.com/skeggsb/linuxDave Airlie authored
- HDMI stereoscopic support - Rework of display code to properly support SOR pad macro routing on >=GM20x GPUs - Various other fixes/improvements. * 'linux-4.13' of git://github.com/skeggsb/linux: (73 commits) drm/nouveau/disp/nv50-: avoid creating ORs that aren't present on HW drm/nouveau: use proper prototype in nouveau_pmops_runtime() definition drm/nouveau: Skip vga_fini on non-PCI device drm/nouveau/tegra: Don't leave GPU in reset drm/nouveau/tegra: Skip manual unpowergating when not necessary drm/nouveau/hwmon: Change permissions to numeric drm/nouveau/hwmon: expose the auto_point and pwm_min/max attrs drm/nouveau/hwmon: Remove old code, add .write/.read operations drm/nouveau/hwmon: Add nouveau_hwmon_ops structure with .is_visible/.read_string drm/nouveau/hwmon: Add config for all sensors and their settings drm/nouveau/disp/gm200-: allow non-identity mapping of SOR <-> macro links drm/nouveau/disp/nv50-: implement a common supervisor 3.0 drm/nouveau/disp/nv50-: implement a common supervisor 2.2 drm/nouveau/disp/nv50-: implement a common supervisor 2.1 drm/nouveau/disp/nv50-: implement a common supervisor 2.0 drm/nouveau/disp/nv50-: implement a common supervisor 1.0 drm/nouveau/disp/nv50-gt21x: remove workaround for dp->tmds hotplug issues drm/nouveau/disp/dp: use new devinit script interpreter entry-point drm/nouveau/disp/dp: determine link bandwidth requirements from head state drm/nouveau/disp: introduce acquire/release display path methods ...
-
git://anongit.freedesktop.org/tegra/linuxDave Airlie authored
drm/tegra: Changes for v4.13-rc1 This starts off with the addition of more documentation for the host1x and DRM drivers and finishes with a slew of fixes and enhancements for the staging IOCTLs as a result of the awesome work done by Dmitry and Erik on the grate reverse-engineering effort. * tag 'drm/tegra/for-4.13-rc1' of git://anongit.freedesktop.org/tegra/linux: gpu: host1x: At first try a non-blocking allocation for the gather copy gpu: host1x: Refactor channel allocation code gpu: host1x: Remove unused host1x_cdma_stop() definition gpu: host1x: Remove unused 'struct host1x_cmdbuf' gpu: host1x: Check waits in the firewall gpu: host1x: Correct swapped arguments in the is_addr_reg() definition gpu: host1x: Forbid unrelated SETCLASS opcode in the firewall gpu: host1x: Forbid RESTART opcode in the firewall gpu: host1x: Forbid relocation address shifting in the firewall gpu: host1x: Do not leak BO's phys address to userspace gpu: host1x: Correct host1x_job_pin() error handling gpu: host1x: Initialize firewall class to the job's one drm/tegra: dc: Disable plane if it is invisible drm/tegra: dc: Apply clipping to the plane drm/tegra: dc: Avoid reset asserts on Tegra20 drm/tegra: Check syncpoint ID in the 'submit' IOCTL drm/tegra: Correct copying of waitchecks and disable them in the 'submit' IOCTL drm/tegra: Check for malformed offsets and sizes in the 'submit' IOCTL drm/tegra: Add driver documentation gpu: host1x: Flesh out kerneldoc
-
- 19 Jun, 2017 4 commits
-
-
Kasin Li authored
In function submit_create, if nr_cmds or nr_bos is assigned with negative value, the allocated buffer may be small than intended. Using this buffer will lead to buffer overflow issue. Signed-off-by:
Kasin Li <donglil@codeaurora.org> Signed-off-by:
Jordan Crouse <jcrouse@codeaurora.org> Signed-off-by:
Rob Clark <robdclark@gmail.com>
-
Alex Xie authored
In original function amdgpu_bo_list_get, the waiting for result->lock can be quite long while mutex bo_list_lock was holding. It can make other tasks waiting for bo_list_lock for long period. Secondly, this patch allows several tasks(readers of idr) to proceed at the same time. v2: use rcu and kref (Dave Airlie and Christian König) v3: update v1 commit message (Michel Dänzer) v4: rebase on upstream (Alex Deucher) Signed-off-by:
Alex Xie <AlexBin.Xie@amd.com> Reviewed-by:
Christian König <christian.koenig@amd.com>
-
Alex Xie authored
v2: Remove duplication of zeroing of bo list (Christian König) Move idr_alloc function to end of ioctl (Christian König) Call kfree bo_list when amdgpu_bo_list_set return error. Combine the previous two patches into this patch. Add amdgpu_bo_list_set function prototype. Signed-off-by: -
Daniel Vetter authored
Signed-off-by:Daniel Vetter <daniel.vetter@ffwll.ch>
-
- 17 Jun, 2017 3 commits
-
-
Rob Clark authored
In fact, it is needed for PCI to work on msm8996 (and probably other things). No idea why it was depending on renesas but that doesn't make any sense. So drop the dependency. Signed-off-by:
Bjorn Andersson <bjorn.andersson@linaro.org> Acked-by:
Geert Uytterhoeven <geert+renesas@glider.be> Reviewed-by:
Simon Horman <horms+renesas@verge.net.au> Acked-by:
Arnd Bergmann <arnd@arndb.de>
-
Sushmita Susheelendra authored
Buffer object specific resources like pages, domains, sg list need not be protected with struct_mutex. They can be protected with a buffer object level lock. This simplifies locking and makes it easier to avoid potential recursive locking scenarios for SVM involving mmap_sem and struct_mutex. This also removes unnecessary serialization when creating buffer objects, and also between buffer object creation and GPU command submission. Signed-off-by:
Sushmita Susheelendra <ssusheel@codeaurora.org> [robclark: squash in handling new locking for shrinker] Signed-off-by:
-
Ben Skeggs authored
Signed-off-by:Ben Skeggs <bskeggs@redhat.com>
-
- 16 Jun, 2017 27 commits
-
-
Rodrigo Vivi authored
Coffee Lake inherit most of Kabylake production workarounds. v2: Fix typo on commit message and remove WaDisableKillLogic and GEN9_DISABLE_OCL_OOB_SUPPRESS_LOGIC, since as Mika pointed out they shouldn't be here for cfl according to BSpec. Cc: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> Signed-off-by:Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by:
Mika Kuoppala <mika.kuoppala@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1497653398-15722-1-git-send-email-rodrigo.vivi@intel.com
-
Dave Airlie authored
This creates a new command submission chunk for amdgpu to add in and out sync objects around the submission. Sync objects are managed via the drm syncobj ioctls. The command submission interface is enhanced with two new chunks, one for syncobj pre submission dependencies, and one for post submission sync obj signalling, and just takes a list of handles for each. This is based on work originally done by David Zhou at AMD, with input from Christian Konig on what things should look like. In theory VkFences could be backed with sync objects and just get passed into the cs as syncobj handles as well. NOTE: this interface addition needs a version bump to expose it to userspace. TODO: update to dep_sync when rebasing onto amdgpu master. (with this - r-b from Christian) v1.1: keep file reference on import. v2: move to using syncobjs v2.1: change some APIs to just use p pointer. v3: make more robust against CS failures, we now add the wait sems but only remove them once the CS job has been submitted. v4: rewrite names of API and base on new syncobj code. v5: move post deps earlier, rename some apis v6: lookup post deps earlier, and just replace fences in post deps stage (Christian) Reviewed-by:
Dave Airlie <airlied@redhat.com> Signed-off-by:
Alex Deucher <alexander.deucher@amd.com>
-
Dave Airlie authored
This just splits out the fence depenency checking into it's own function to make it easier to add semaphore dependencies. v2: rebase onto other changes. v1-Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by:
-
Alex Deucher authored
Avoids printing spurious messages like this: [ 3.102059] amdgpu 0000:01:00.0: VM size (-1) must be a power of 2 Reviewed-by:
Michel Dänzer <michel.daenzer@amd.com> Signed-off-by:
-
Dhinakaran Pandiyan authored
Although we use 9 bits of Device ID for identifying PCH, only 8 bits are stored in dev_priv->pch_id. This makes HAS_PCH_CNP_LP() and HAS_PCH_SPT_LP() incorrect. Fix this by storing all the 9 bits for the platforms with LP PCH. v2: Drop PCH_LPT_LP change (Imre) Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Jani Nikula <jani.nikula@intel.com> Cc: Imre Deak <imre.deak@intel.com> Fixes: commit ec7e0bb3 ("drm/i915/cnp: Add PCI ID for Cannonpoint LP PCH") Reported-by:
Imre Deak <imre.deak@intel.com> Reviewed-by:
Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> Signed-off-by:
-
Chris Wilson authored
During execbuf, a mandatory step is that we add this request (this fence) to each object's reservation_object. Inside execbuf, we track the vma, and to add the fence to the reservation_object then means having to first chase the obj, incurring another cache miss. We can reduce the number of cache misses by stashing a pointer to the reservation_object in the vma itself. Signed-off-by:
Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by:
Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20170616140525.6394-1-chris@chris-wilson.co.uk
-
Chris Wilson authored
If the user requires patching of their batch or auxiliary buffers, we currently make the alterations on the cpu. If they are active on the GPU at the time, we wait under the struct_mutex for them to finish executing before we rewrite the contents. This happens if shared relocation trees are used between different contexts with separate address space (and the buffers then have different addresses in each), the 3D state will need to be adjusted between execution on each context. However, we don't need to use the CPU to do the relocation patching, as we could queue commands to the GPU to perform it and use fences to serialise the operation with the current activity and future - so the operation on the GPU appears just as atomic as performing it immediately. Performing the relocation rewrites on the GPU is not free, in terms of pure throughput, the number of relocations/s is about halved - but more importantly so is the time under the struct_mutex. v2: Break out the request/batch allocation for clearer error flow. v3: A few asserts to ensure rq ordering is maintained Signed-off-by:
-
Chris Wilson authored
Currently, the last object in the execlist is the always the batch. However, when building the batch buffer we often know the batch object first and if we can use the first slot in the execlist we can emit relocation instructions relative to it immediately and avoid a separate pass to adjust the relocations to point to the last execlist slot. Signed-off-by:
-
Chris Wilson authored
This simply hides the EAGAIN caused by userptr when userspace causes resource contention. However, it is quite beneficial with highly contended userptr users as we avoid repeating the setup costs and kernel-user context switches. Signed-off-by:
Michał Winiarski <michal.winiarski@intel.com>
-
Chris Wilson authored
When choosing a slot for an execbuffer, we ideally want to use the same address as last time (so that we don't have to rebind it) and the same address as expected by the user (so that we don't have to fixup any relocations pointing to it). If we first try to bind the incoming execbuffer->offset from the user, or the currently bound offset that should hopefully achieve the goal of avoiding the rebind cost and the relocation penalty. However, if the object is not currently bound there we don't want to arbitrarily unbind an object in our chosen position and so choose to rebind/relocate the incoming object instead. After we report the new position back to the user, on the next pass the relocations should have settled down. Signed-off-by:
Joonas Lahtinen <joonas.lahtien@linux.intel.com>
-
Chris Wilson authored
If we take a reference to the object/vma when it is first used in an execbuf, we can keep that reference until the object's file-local handle is closed. Thereby saving a frequent ref/unref pair. Signed-off-by:
-
Chris Wilson authored
The major scaling bottleneck in execbuffer is the processing of the execobjects. Creating an auxiliary list is inefficient when compared to using the execobject array we already have allocated. Reservation is then split into phases. As we lookup up the VMA, we try and bind it back into active location. Only if that fails, do we add it to the unbound list for phase 2. In phase 2, we try and add all those objects that could not fit into their previous location, with fallback to retrying all objects and evicting the VM in case of severe fragmentation. (This is the same as before, except that phase 1 is now done inline with looking up the VMA to avoid an iteration over the execobject array. In the ideal case, we eliminate the separate reservation phase). During the reservation phase, we only evict from the VM between passes (rather than currently as we try to fit every new VMA). In testing with Unreal Engine's Atlantis demo which stresses the eviction logic on gen7 class hardware, this speed up the framerate by a factor of 2. The second loop amalgamation is between move_to_gpu and move_to_active. As we always submit the request, even if incomplete, we can use the current request to track active VMA as we perform the flushes and synchronisation required. The next big advancement is to avoid copying back to the user any execobjects and relocations that are not changed. v2: Add a Theory of Operation spiel. v3: Fall back to slow relocations in preparation for flushing userptrs. v4: Document struct members, factor out eb_validate_vma(), add a few more comments to explain some magic and hide other magic behind macros. Signed-off-by:
-
Chris Wilson authored
If we write a relocation into the buffer, we require our own implicit synchronisation added after the start of the execbuf, outside of the user's control. As we may end up clflushing, or doing the patch itself on the GPU, asynchronously we need to look at the implicit serialisation on obj->resv and hence need to disable EXEC_OBJECT_ASYNC for this object. If the user does trigger a stall for relocations, we make sure the stall is complete enough so that the batch is not submitted before we complete those relocations. Fixes: 77ae9957 ("drm/i915: Enable userspace to opt-out of implicit fencing") Signed-off-by:
-
Chris Wilson authored
We can simplify our tracking of pending writes in an execbuf to the single bit in the vma->exec_entry->flags, but that requires the relocation function knowing the object's vma. Pass it along. Note we have only been using a single bit to track flushing since commit cc889e0f Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Wed Jun 13 20:45:19 2012 +0200 drm/i915: disable flushing_list/gpu_write_list unconditionally flushed all render caches before the breadcrumb and commit 6ac42f41 Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Sat Jul 21 12:25:01 2012 +0200 drm/i915: Replace the complex flushing logic with simple invalidate/flush all did away with the explicit GPU domain tracking. This was then codified into the ABI with NO_RELOC in commit ed5982e6 Author: Daniel Vetter <daniel.vetter@ffwll.ch> # Oi! Patch stealer! Date: Thu Jan 17 22:23:36 2013 +0100 drm/i915: Allow userspace to hint that the relocations were known Signed-off-by:
-
Chris Wilson authored
The advent of full-ppgtt lead to an extra indirection between the object and its binding. That extra indirection has a noticeable impact on how fast we can convert from the user handles to our internal vma for execbuffer. In order to bypass the extra indirection, we use a resizable hashtable to jump from the object to the per-ctx vma. rhashtable was considered but we don't need the online resizing feature and the extra complexity proved to undermine its usefulness. Instead, we simply reallocate the hastable on demand in a background task and serialize it before iterating. In non-full-ppgtt modes, multiple files and multiple contexts can share the same vma. This leads to having multiple possible handle->vma links, so we only use the first to establish the fast path. The majority of buffers are not shared and so we should still be able to realise speedups with multiple clients. v2: Prettier names, more magic. v3: Many style tweaks, most notably hiding the misuse of execobj[].rsvd2 Signed-off-by:
-
Chris Wilson authored
The default context is always supported (as it contains the global hangcheck stats) and the contexts for hangcheck are not limited to any ring. This was dropped in 2013 because it was supposed to have been included with Ben's full-ppgtt patch set. It never landed and the bug remains. References: https://bugs.freedesktop.org/show_bug.cgi?id=65845 Link: http://patchwork.freedesktop.org/patch/msgid/1372175222-27622-1-git-send-email-mika.kuoppala@intel.comSigned-off-by:
-
Archit Taneja authored
A 2 pixel wide pink strip was observed on the left end of some HDMI monitors configured in a HDMI mode. It turned out that we were missing out on configuring AVI infoframes, and unlike APQ8064, the 8x96 HDMI H/W seems to be sensitive to that. Add configuration of AVI infoframes. While at it, make sure that hdmi_audio_update is only called when we've detected that the monitor supports HDMI. Signed-off-by:
Archit Taneja <architt@codeaurora.org> Signed-off-by:
-
Archit Taneja authored
Without doing anything in unprepare, the HDMI driver isn't able to switch modes successfully. Calling set_rate with a new rate results in an un-locked PLL. If we reset the PLL in unprepare, the PLL is able to lock with the new rate. Signed-off-by:
-
Liviu Dudau authored
Commit c0c0d9ee ("drm/msm: hdmi audio support") uses logical OR operators to build up a value to be written in the REG_HDMI_AUDIO_INFO0 and REG_HDMI_AUDIO_INFO1 registers when it should have used bitwise operators. Signed-off-by:
Liviu Dudau <liviu.dudau@arm.com> Fixes: c0c0d9ee ("drm/msm: hdmi audio support") Signed-off-by:
-
Rob Clark authored
Signed-off-by: -
Rob Clark authored
Now that the msm_gem supports an arbitrary number of vma's, we no longer need to assign an id (index) to each address space. So rip out the associated code. Signed-off-by: -
Rob Clark authored
It means we have to do a list traversal where we once had an index into a table. But the list will normally have one or two entries. Signed-off-by: -
Rob Clark authored
Pull some of the logic out into msm_gem_new() (since we don't need to care about the imported-bo case), and don't defer allocating pages. The latter is generally a good idea, since if we are using VRAM carveout to allocate contiguous buffers (ie. no IOMMU), the allocation is more likely to fail. So failing at allocation time is a more sane option. Plus this simplifies things in the next patch. Signed-off-by: -
Rob Clark authored
No functional change, that will come later. But this will make it easier to deal with dynamically created address spaces (ie. per- process pagetables for gpu). Signed-off-by: -
Rob Clark authored
Before we can shift to passing the address-space object to _get_iova(), we need to fix a few places (dsi+fbdev) that were hard-coding the adress space id. That gets somewhat easier if we just move these to the kms base class. Prep work for next patch. Signed-off-by: -
Rob Clark authored
It serves no purpose, things should be sufficiently synchronized already by atomic framework. And it is somewhat awkward to be holding a spinlock when msm_gem_iova() is going to start needing to grab a mutex. Signed-off-by: -
Rob Clark authored
Most, but not all, paths where calling the with struct_mutex held. The fast-path in msm_gem_get_iova() (plus some sub-code-paths that only run the first time) was masking this issue. So lets just always hold struct_mutex for hw_init(). And sprinkle some WARN_ON()'s and might_lock() to avoid this sort of problem in the future. Signed-off-by:
-
