summaryrefslogtreecommitdiffstats
path: root/drivers/gpu/drm
Commit message (Collapse)AuthorAgeFilesLines
* drm/i915: One hopeful eviction on PPGTT allocBen Widawsky2013-12-181-2/+12
| | | | | | | | | | | | | | | | | | The patch before this changed the way in which we allocate space for the PPGTT PDEs. It began carving out the PPGTT PDEs (which live in the Global GTT) from the GGTT's drm_mm. Prior to that patch, the PDEs were hidden from the drm_mm, and therefore could never fail to be allocated. In unfortunate cases, the drm_mm may be full when we want to allocate the space. This can technically occur whenever we try to allocate, which happens in two places currently. Practically, it can only really ever happen at GPU reset. Later, when we allocate more PDEs for multiple PPGTTs this will potentially even more useful. Signed-off-by: Ben Widawsky <ben@bwidawsk.net> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: Use drm_mm for PPGTT PDEsBen Widawsky2013-12-182-25/+32
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When PPGTT support was originally enabled, it was only designed to support 1 PPGTT. It therefore made sense to simply hide the GGTT space required to enable this from the drm_mm allocator. Since we intend to support full PPGTT, which means more than 1, and they can be created and destroyed ad hoc it will be required to use the proper allocation techniques we already have. The first step here is to make the existing single PPGTT use the allocator. The astute observer will notice that we are reserving space in the GGTT for the PDEs for the lifetime of the address space, and would be right to question whether or not this is a good idea. It does not make a difference with this current patch only the aliasing PPGTT (indeed the PDEs should still be hidden from the shrinker). For the future, we are allocating from top to bottom to avoid using the precious "gtt space" The GGTT space at that point should only be used for scanout, HW contexts, ringbuffers, HWSP, PDEs, and a couple of other small buffers (potentially) used by the kernel. Everything else should be mapped into a PPGTT. To put the consumption in more tangible terms, it takes approximately 4 sets of PDEs to equal one 19x10 framebuffer (with no fancy stride or alignment constraints). 3/4 of the total [average] GGTT can be used for PDEs, and hopefully never touch the 1/4 that the framebuffer needs. The astute, and persistent observer might ask about the page tables which are also pinned for the address space. This waste is unfortunate. We use 2MB of memory per address space. We leave wrapping the PDEs as a real GEM object as a TODO. v2: Align PDEs to 64b in GTT Allocate the node dynamically so we can use drm_mm_put_block Now tested on IGT Allocate node at the top to avoid fragmentation (Chris) v3: Use Chris' top down allocator v4: Embed drm_mm_node into ppgtt struct (Jesse) Remove hunks which didn't belong (Jesse) v5: Don't subtract guard page since we now killed the guard page prior to this patch. (Ben) v6: Rebased and removed guard page stuff. Added a chunk to the commit message Allow adding a context to mappable region v7: Undo v3, so we can make the drm patch last in the series Cc: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> (v4) Signed-off-by: Ben Widawsky <ben@bwidawsk.net> squash: drm/i915: allow PPGTT to use mappable Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: PPGTT vfuncs should take a ppgtt argumentBen Widawsky2013-12-183-6/+9
| | | | | Signed-off-by: Ben Widawsky <ben@bwidawsk.net> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: Generalize default context setupBen Widawsky2013-12-181-13/+12Star
| | | | | | | | | The plan to to make every file descriptor have a default context. To accommodate this, generalize out default context setup function so it can be used at file open time. Signed-off-by: Ben Widawsky <ben@bwidawsk.net> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: Split context enabling from initBen Widawsky2013-12-183-16/+44
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We **need** to do this for exactly 1 reason, because we want to embed a PPGTT into the context, but we don't want to special case the default context. To achieve that, we must be able to initialize contexts after the GTT is setup (so we can allocate and pin the default context's BO), but before the PPGTT and rings are initialized. This is because, currently, context initialization requires ring usage. We don't have rings until after the GTT is setup. If we split the enabling part of context initialization, the part requiring the ringbuffer, we can untangle this, and then later embed the PPGTT Incidentally this allows us to also adhere to the original design of context init/fini in future patches: they were only ever meant to be called at driver load and unload. v2: Move hw_contexts_disabled test in i915_gem_context_enable() (Chris) v3: BUG_ON after checking for disabled contexts. Or else it blows up pre gen6 (Ben) v4: Forward port Modified enable for each ring, since that patch is earlier in the series Dropped ring arg from create_default_context so it can be used by others Signed-off-by: Ben Widawsky <ben@bwidawsk.net> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: Better reset handling for contextsBen Widawsky2013-12-183-0/+46
| | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch adds to changes for contexts on reset: Sets last context to default - this will prevent the context switch happening after a reset. That switch is not possible because the rings are hung during reset and context switch requires reset. This behavior will need to be reworked in the future, but this is what we want for now. In the future, we'll also want to reset the guilty context to uninitialized. We should wait for ARB_Robustness related code to land for that. This is somewhat for paranoia. Because we really don't know what the GPU was doing when it hung, or the state it was in (mid context write, for example), later restoring the context is a bad idea. By setting the flag to not initialized, the next load of that context will not restore the state, and thus on the subsequent switch away from the context will overwrite the old data. NOTE: This code needs a fixup when we actually have multiple VMs. The issue that can occur is inactive objects in a VM will need to be destroyed before the last context unref. This can now happen via the fake switch introduced in this patch (and it other ways in the future) Signed-off-by: Ben Widawsky <ben@bwidawsk.net> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: Track which ring a context ran onBen Widawsky2013-12-182-8/+6Star
| | | | | | | | | | | | | | | | | | | | | | | | | | Previously we dropped the association of a context to a ring. It is however very important to know which ring a context ran on (we could have reused the other member, but I was nitpicky). This is very important when we switch address spaces, which unlike context objects, do change per ring. As an example, if we have: RCS BCS ctx A ctx A ctx B ctx B Without tracking the last ring B ran on, we wouldn't know to switch the address space on BCS in the last row. As a result, we no longer need to track which ring a context "belongs" to, as it never really made much sense anyway. Signed-off-by: Ben Widawsky <ben@bwidawsk.net> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: Permit contexts on all ringsBen Widawsky2013-12-182-15/+42
| | | | | | | | | | | | | | | | | | | | | If we want to use contexts in more abstract terms (specifically with PPGTT in mind), we need to allow them to be specified for any ring. Since the upcoming patches will bring about the use of multiple address spaces, and each ring needs to have an address space programmed (which we intend to do at context switch time), we can no longer only use RCS. With multiple rings having a last context, we must now unreference these contexts. NOTE: This commit requires an update to intel-gpu-tools to make it not fail. v2: Rebased with some logical conflicts. Squashed in the context fini refcount patch Signed-off-by: Ben Widawsky <ben@bwidawsk.net> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: Simplify ring handling in execbufBen Widawsky2013-12-181-31/+10Star
| | | | | Signed-off-by: Ben Widawsky <ben@bwidawsk.net> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: relax context alignmentBen Widawsky2013-12-181-7/+19
| | | | | | | | | | | | | | | With the introduction of contexts per fd in the future, one can easily envision more contexts being used. We do not have an easy remedy to reduce the space requirements of the contexts, we can make things slightly better by using less stringent alignments on later hardware. Ville: Since I can almost predict you'll point this out. I can no longer find the docs which specify the 64k requirement on certain gen6 SKUs. If you'd like to change that too, be my guest. CC: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Ben Widawsky <ben@bwidawsk.net> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: Add a context open functionBen Widawsky2013-12-183-2/+21
| | | | | | | | | | | We'll be doing a bit more stuff with each file, so having our own open function should make things clean. This also allows us to easily add conditionals for stuff we don't want to do when we don't have HW contexts. Signed-off-by: Ben Widawsky <ben@bwidawsk.net> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: Remove vm arg from relocate entryBen Widawsky2013-12-181-7/+6Star
| | | | | | | | | | The only place we were using it was for GEN6, which won't have PPGTT support anyway (ie. the VM is always the same). To clear things up, (it only added confusion for me since it doesn't allow us to assert vma->vm is what we always want, when just looking at the code). Signed-off-by: Ben Widawsky <ben@bwidawsk.net> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: Create bind/unbind abstraction for VMAsBen Widawsky2013-12-185-162/+245
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | To sum up what goes on here, we abstract the vma binding, similarly to the previous object binding. This helps for distinguishing legacy binding, versus modern binding. To keep the code churn as minimal as possible, I am leaving in insert_entries(). It serves as the per platform pte writing basically. bind_vma and insert_entries do share a lot of similarities, and I did have designs to combine the two, but as mentioned already... too much churn in an already massive patchset. What follows are the 3 commits which existed discretely in the original submissions. Upon rebasing on Broadwell support, it became clear that separation was not good, and only made for more error prone code. Below are the 3 commit messages with all their history. drm/i915: Add bind/unbind object functions to VMA drm/i915: Use the new vm [un]bind functions drm/i915: reduce vm->insert_entries() usage drm/i915: Add bind/unbind object functions to VMA As we plumb the code with more VM information, it has become more obvious that the easiest way to deal with bind and unbind is to simply put the function pointers in the vm, and let those choose the correct way to handle the page table updates. This change allows many places in the code to simply be vm->bind, and not have to worry about distinguishing PPGTT vs GGTT. Notice that this patch has no impact on functionality. I've decided to save the actual change until the next patch because I think it's easier to review that way. I'm happy to squash the two, or let Daniel do it on merge. v2: Make ggtt handle the quirky aliasing ppgtt Add flags to bind object to support above Don't ever call bind/unbind directly for PPGTT until we have real, full PPGTT (use NULLs to assert this) Make sure we rebind the ggtt if there already is a ggtt binding. This happens on set cache levels. Use VMA for bind/unbind (Daniel, Ben) v3: Reorganize ggtt_vma_bind to be more concise and easier to read (Ville). Change logic in unbind to only unbind ggtt when there is a global mapping, and to remove a redundant check if the aliasing ppgtt exists. v4: Make the bind function a bit smarter about the cache levels to avoid unnecessary multiple remaps. "I accept it is a wart, I think unifying the pin_vma / bind_vma could be unified later" (Chris) Removed the git notes, and put version info here. (Daniel) v5: Update the comment to not suck (Chris) v6: Move bind/unbind to the VMA. It makes more sense in the VMA structure (always has, but I was previously lazy). With this change, it will allow us to keep a distinct insert_entries. Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Ben Widawsky <ben@bwidawsk.net> drm/i915: Use the new vm [un]bind functions Building on the last patch which created the new function pointers in the VM for bind/unbind, here we actually put those new function pointers to use. Split out as a separate patch to aid in review. I'm fine with squashing into the previous patch if people request it. v2: Updated to address the smart ggtt which can do aliasing as needed Make sure we bind to global gtt when mappable and fenceable. I thought we could get away without this initialy, but we cannot. v3: Make the global GTT binding explicitly use the ggtt VM for bind_vma(). While at it, use the new ggtt_vma helper (Chris) At this point the original mailing list thread diverges. ie. v4^: use target_obj instead of obj for gen6 relocate_entry vma->bind_vma() can be called safely during pin. So simply do that instead of the complicated conditionals. Don't restore PPGTT bound objects on resume path Bug fix in resume path for globally bound Bos Properly handle secure dispatch Rebased on vma bind/unbind conversion Signed-off-by: Ben Widawsky <ben@bwidawsk.net> drm/i915: reduce vm->insert_entries() usage FKA: drm/i915: eliminate vm->insert_entries() With bind/unbind function pointers in place, we no longer need insert_entries. We could, and want, to remove clear_range, however it's not totally easy at this point. Since it's used in a couple of place still that don't only deal in objects: setup, ppgtt init, and restore gtt mappings. v2: Don't actually remove insert_entries, just limit its usage. It will be useful when we introduce gen8. It will always be called from the vma bind/unbind. Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> (v1) Signed-off-by: Ben Widawsky <ben@bwidawsk.net> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: Make pin count per VMABen Widawsky2013-12-1812-70/+90
| | | | | Signed-off-by: Ben Widawsky <ben@bwidawsk.net> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: Identify active VM for batchbuffer captureBen Widawsky2013-12-181-0/+33
| | | | | | | | | | | | | | Using the current state of the page directory registers, we can determine which of our address spaces was active when the hang occurred. This allows us to scan through all the address spaces to identify the "active" one during error capture. v2: Rebased for BDW error detection. BDW error detection is similar except instead of PP_DIR_BASE, we can use the PDP registers. Signed-off-by: Ben Widawsky <ben@bwidawsk.net> [danvet: Add FIXME about global gtt misuse.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: Don't use gtt mapping for !gtt error objectsBen Widawsky2013-12-181-1/+2
| | | | | | | | | | | | | | | | | | | | The existing check was insufficient to determine whether we can use the GTT mapping to read out the object during error capture. The previous condition was, if the object has a GGTT mapping, and the reloc is in the GTT range... the can happen with opjects mapped into multiple vms (one of which being the GTT). There are two solutions to this problem: 1. This patch, which avoid reading the io mapping 2. Use the GGTT offset with the io mapping. Since error capture is about recording the most accurate possible error state, and the error was caused by the object not in the GGTT - I opted for the former. Signed-off-by: Ben Widawsky <ben@bwidawsk.net> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: Add vm to error BO captureBen Widawsky2013-12-181-7/+14
| | | | | | | formerly: drm/i915: Create VMAs (part 6) - finish error plumbing Signed-off-by: Ben Widawsky <ben@bwidawsk.net> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: Handle inactivating objects for all VMAsBen Widawsky2013-12-181-3/+7
| | | | | | | | | | | | | | This came from a patch called, "drm/i915: Move active to vma" When moving an object to the inactive list, we do it for all VMs for which the object is bound. The primary difference from that patch is this time around we don't not track 'active' per vma, but rather by object. Therefore, we only need one unref. Signed-off-by: Ben Widawsky <ben@bwidawsk.net> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: Takedown drm_mm on failed gtt setupBen Widawsky2013-12-181-0/+1
| | | | | | | | | | This was found by code inspection. If the GTT setup fails then we are left without properly tearing down the drm_mm. Hopefully this never happens. Signed-off-by: Ben Widawsky <ben@bwidawsk.net> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: Allow ggtt lookups to not WARNBen Widawsky2013-12-181-1/+1
| | | | | | | | | | | | | | | | | | | To be able to effectively use the GGTT object lookup function, we don't want to warn when there is no GGTT mapping. Let the caller deal with it instead. Originally, I had intended to have this behavior, and has not introduced the WARN. It was introduced during review with the addition of the follow commit commit 5c2abbeab798154166d42fce4f71790caa6dd9bc Author: Ben Widawsky <benjamin.widawsky@intel.com> Date: Tue Sep 24 09:57:57 2013 -0700 drm/i915: Provide a cheap ggtt vma lookup Signed-off-by: Ben Widawsky <ben@bwidawsk.net> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: Don't unconditionally try to deref aliasing ppgttBen Widawsky2013-12-181-2/+4
| | | | | | | | | | | | | | | | Since the beginning, the functions which try to properly reference the aliasing PPGTT have deferences a potentially null aliasing_ppgtt member. Since the accessors are meant to be global, this will not do. Introduced originally in: commit a70a3148b0c61cb7c588ea650db785b261b378a3 Author: Ben Widawsky <ben@bwidawsk.net> Date: Wed Jul 31 16:59:56 2013 -0700 drm/i915: Make proper functions for VMs Signed-off-by: Ben Widawsky <ben@bwidawsk.net> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: Provide PDP updates via MMIOBen Widawsky2013-12-181-2/+10
| | | | | | | | | | | | | | | The initial implementation of this function used MMIO to write the PDPs. Upon review it was determined (correctly) that the docs say to use LRI. The issue is there are times where we want to do a synchronous write (GPU reset). I've tested this, and it works. I've verified with as many people as possible that it should work. This should fix the failing reset problems. Signed-off-by: Ben Widawsky <ben@bwidawsk.net> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* Merge tag 'v3.13-rc3' into drm-intel-next-queuedDaniel Vetter2013-12-0987-467/+1141
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Linux 3.13-rc3 I need a backmerge for two reasons: - For merging the ppgtt patches from Ben I need to pull in the bdw support. - We now have duplicated calls to intel_uncore_forcewake_reset in the setup code to due 2 different patches merged into -next and 3.13. The conflict is silen so I need the merge to be able to apply Deepak's fixup patch. Conflicts: drivers/gpu/drm/i915/intel_display.c Trivial conflict, it doesn't even show up in the merge diff. Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * drm/qxl: fix memory leak in release list handlingDave Airlie2013-11-281-0/+1
| | | | | | | | | | | | | | | | | | | | wow no idea how I got this far without seeing this, leaking the entries in the list makes kmalloc-64 slab grow. References: https://bugzilla.kernel.org/show_bug.cgi?id=65121 Cc: stable@vger.kernel.org Reported-by: Matthew Stapleton <matthew4196@gmail.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
| * drm/nouveau/hwmon: fix compilation without CONFIG_HWMONIlia Mirkin2013-11-281-1/+0Star
| | | | | | | | | | | | | | Reported-by: Jim Davis <jim.epost@gmail.com> Tested-by: Jim Davis <jim.epost@gmail.com> Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu> Signed-off-by: Dave Airlie <airlied@redhat.com>
| * drm/sysfs: fix OOM verificationDavid Herrmann2013-11-281-1/+1
| | | | | | | | | | | | | | | | Copy/Paste typo.. we need to test for ->kdev instead of ->dev. Reported-by: Juha Leppänen <juha_efku@dnainternet.net> Signed-off-by: David Herrmann <dh.herrmann@gmail.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
| * drm/sysfs: fix hotplug regression since lifetime changesDavid Herrmann2013-11-211-7/+33
| | | | | | | | | | | | | | | | | | | | | | | | airlied: The lifetime changes introduced in 5bdebb183c9702a8c57a01dff09337be3de337a6 tried to use device_create, however that led to the regression where dev->type wasn't getting set correctly. First attempt at fixing it would have led to a race, so this undoes the device_createa work and does it all manually making sure the dev->type is setup before we register the device. Signed-off-by: David Herrmann <dh.herrmann@gmail.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
| * drm/exynos: g2d: fix memory leak to userptrInki Dae2013-11-211-0/+2
| | | | | | | | | | | | | | | | | | | | | | This patch releases a vma object when cleaning up userptr resources. A new vma object was allocated and copied when getting userptr pages so the new vma object should be freed properly if the userptr pages aren't used anymore. Signed-off-by: Inki Dae <inki.dae@samsung.com> Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
| * Merge branch 'ttm-fixes-3.13' of git://people.freedesktop.org/~thomash/linux ↵Dave Airlie2013-11-213-9/+59
| |\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | into drm-fixes The set_need_resched() removal fix and yet another fix in ttm_bo_move_memcpy(). * 'ttm-fixes-3.13' of git://people.freedesktop.org/~thomash/linux: drm/ttm: Remove set_need_resched from the ttm fault handler drm/ttm: Don't move non-existing data
| | * drm/ttm: Remove set_need_resched from the ttm fault handlerThomas Hellstrom2013-11-202-7/+54
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Addresses "[BUG] completely bonkers use of set_need_resched + VM_FAULT_NOPAGE". In the first occurence it was used to try to be nice while releasing the mmap_sem and retrying the fault to work around a locking inversion. The second occurence was never used. There has been some discussion whether we should change the locking order to mmap_sem -> bo_reserve. This patch doesn't address that issue, and leaves that locking order undefined. The solution that we release the mmap_sem if tryreserve fails and wait for the buffer to become unreserved is something we want in any case, and follows how the core vm system waits for pages to be come unlocked while releasing the mmap_sem. The code also outlines what needs to be changed if we want to establish the locking order as mmap_sem -> bo::reserve. One slight issue that remains with this code is that the fault handler might be prone to starvation if another thread countinously reserves the buffer. IMO that usage pattern is highly unlikely. Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
| | * drm/ttm: Don't move non-existing dataThomas Hellstrom2013-11-201-2/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | If ttm_bo_move_memcpy was instructed to move a non-populated ttm to io memory, it would first populate the ttm, then move the data and then destroy the ttm. That's stupid. However, some drivers might have relied on this to clear io memory from old stuff. So instead of a NOP, which would be the most efficient, just clear the destination. Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com> Reviewed-by: Jakob Bornecrantz <jakob@vmware.com>
| * | Merge branch 'vmwgfx-fixes-3.13' of ↵Dave Airlie2013-11-218-67/+472
| |\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://people.freedesktop.org/~thomash/linux into drm-fixes Below is a fix for a false lockep warning, and the vmwgfx prime implementation. * 'vmwgfx-fixes-3.13' of git://people.freedesktop.org/~thomash/linux: drm/vmwgfx: Make vmwgfx dma buffers prime aware drm/vmwgfx: Make surfaces prime-aware drm/vmwgfx: Hook up the prime ioctls drm/ttm: Add a minimal prime implementation for ttm base objects drm/vmwgfx: Fix false lockdep warning drm/ttm: Allow execbuf util reserves without ticket
| | * | drm/vmwgfx: Make vmwgfx dma buffers prime awareThomas Hellstrom2013-11-181-20/+25
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Should we need to share dma buffers using prime, let's make them prime aware. Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com> Reviewed-by: Jakob Bornecrantz <jakob@vmware.com>
| | * | drm/vmwgfx: Make surfaces prime-awareThomas Hellstrom2013-11-182-15/+17
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Add prime exporting and imporing operations to surfaces Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com> Reviewed-by: Jakob Bornecrantz <jakob@vmware.com>
| | * | drm/vmwgfx: Hook up the prime ioctlsThomas Hellstrom2013-11-184-3/+157
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Also provide a completely dumb dma-buf ops implementation. Once we have other virtual dma-buf aware devices, we need to provide something better. Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com> Reviewed-by: Jakob Bornecrantz <jakob@vmware.com>
| | * | drm/ttm: Add a minimal prime implementation for ttm base objectsThomas Hellstrom2013-11-181-6/+248
| | | | | | | | | | | | | | | | | | | | Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com> Reviewed-by: Jakob Bornecrantz <jakob@vmware.com>
| | * | drm/vmwgfx: Fix false lockdep warningThomas Hellstrom2013-11-181-10/+6Star
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | A lockdep warning is hit when evicting surfaces and reserving the backup buffer. Since this buffer can only be reserved by the process holding the surface reservation or by the buffer eviction processes that use tryreserve, there is no real deadlock here, but there's no other way to silence lockdep than to use a tryreserve. This means the reservation might fail if the buffer is about to be evicted or swapped out, but we now have code in place to handle that reasonably well. Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com> Reviewed-by: Jakob Bornecrantz <jakob@vmware.com>
| | * | drm/ttm: Allow execbuf util reserves without ticketThomas Hellstrom2013-11-181-13/+19
| | |/ | | | | | | | | | | | | | | | | | | | | | | | | | | | If no reservation ticket is given to the execbuf reservation utilities, try reservation with non-blocking semantics. This is intended for eviction paths that use the execbuf reservation utilities for convenience rather than for deadlock avoidance. Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com> Reviewed-by: Jakob Bornecrantz <jakob@vmware.com>
| * | Merge tag 'drm-intel-fixes-2013-11-20' of ↵Dave Airlie2013-11-218-22/+79
| |\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://people.freedesktop.org/~danvet/drm-intel into drm-fixes Just a small pile of fixes for bugs and a few regressions. I'm still trying to track down a driver load hang on my g33 (which infuriatingly doesn't happen when loading the module manually after boot), somehow bisecting loves to go astray on this one :( And there's a (harmless) locking WARN in the suspend code due to one of Jesse's vlv backlight rework patches. Otherwise nothing outstanding afaik. * tag 'drm-intel-fixes-2013-11-20' of git://people.freedesktop.org/~danvet/drm-intel: drm/i915: Fix gen3 self-refresh watermarks drm/i915: Replicate BIOS eDP bpp clamping hack for hsw drm/i915: Do not enable package C8 on unsupported hardware drm/i915: Hold pc8 lock around toggling pc8.gpu_idle drm/i915: encoder->get_config is no longer optional drm/i915/tv: add ->get_config callback drm/i915: restore the early forcewake cleanup Partially revert "drm/i915: tune the RC6 threshold for stability" drm/i915: flush cursors harder i915: Use 120MHz LVDS SSC clock for gen5/gen6/gen7 x86/early quirk: use gen6 stolen detection for VLV drm/i915/dp: set sink to power down mode on dp disable
| | * | drm/i915: Fix gen3 self-refresh watermarksDaniel Vetter2013-11-201-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This regression has been introduced in commit 4fe8590a921d0b2e36e542dbfa89a8c5993f5a3f Author: Ville Syrjälä <ville.syrjala@linux.intel.com> Date: Wed Sep 4 18:25:22 2013 +0300 drm/i915: Use adjusted_mode appropriately when computing watermarks I guess we should renable the enabled local variable into something a notch more descriptive, but that's something for -next. The effect on my i945gme netbook is pretty severe amounts of underruns - usually the very first pixel gets used for the entire screeen. Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Damien Lespiau <damien.lespiau@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| | * | drm/i915: Replicate BIOS eDP bpp clamping hack for hswDaniel Vetter2013-11-191-0/+20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Haswell's DDI encoders have their own ->get_config callback and in commit c6cd2ee2d59111a07cd9199564c9bdcb2d11e5cf Author: Jani Nikula <jani.nikula@intel.com> Date: Mon Oct 21 10:52:07 2013 +0300 drm/i915/dp: workaround BIOS eDP bpp clamping issue we've forgotten to replicate this hack. So let's do it that. Note for backporters: The above commit and all it's depencies need to be backported first. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=71049 Cc: stable@vger.kernel.org Tested-by: Gökçen Eraslan <gokcen.eraslan@gmail.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| | * | drm/i915: Do not enable package C8 on unsupported hardwareChris Wilson2013-11-192-0/+16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | If the hardware does not support package C8, then do not even schedule work to enable it. Thereby we can eliminate a bunch of dangerous work. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Paulo Zanoni <paulo.r.zanoni@intel.com> Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@gmail.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| | * | drm/i915: Hold pc8 lock around toggling pc8.gpu_idleChris Wilson2013-11-191-2/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We need to hold the pc8 lock around toggling the value of gpu_idle. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Paulo Zanoni <paulo.r.zanoni@intel.com> Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@gmail.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| | * | drm/i915: encoder->get_config is no longer optionalDaniel Vetter2013-11-181-4/+2Star
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We must have one to fill out the adjusted_mode.crtc_clock. And with the tv encoder fixed up every encoder we have has a ->get_config callback. So we can drop the checks. Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| | * | drm/i915/tv: add ->get_config callbackDaniel Vetter2013-11-181-0/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We need this to properly fill in adjusted_mode.crtc_clock, otherwise the state checker gets unhappy. This seems to have been forgotten in the big clock rework in commit 18442d08786472c63a0a80c27f92b033dffc26de Author: Ville Syrjälä <ville.syrjala@linux.intel.com> Date: Fri Sep 13 16:00:08 2013 +0300 drm/i915: Fix port_clock and adjusted_mode.clock readout all over Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| | * | drm/i915: restore the early forcewake cleanupDaniel Vetter2013-11-171-12/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Some BIOS just leak the forcewak bits, which we clean up. Unfortunately this has been broken in commit 521198a2e7095c8c7daa8d7d3a76a110c346be6f Author: Mika Kuoppala <mika.kuoppala@linux.intel.com> Date: Fri Aug 23 16:52:30 2013 +0300 drm/i915: sanitize forcewake registers on reset To make this work both for resets and for BIOS takeover just add the forcewake clearing call back to intel_uncore_early_sanitize. We need to clear the forcewake in early sanitize so that the forcewak dance in intel_uncore_init (to figure out whether we have mt or legacy forcewake on ivb) works. That cleanup fits in nicely with the general topic of early_sanitize to prepare for the very first mmio ops. Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Reported-by: Jörg Otte <jrg.otte@gmail.com> Cc: Jörg Otte <jrg.otte@gmail.com> References: https://lkml.org/lkml/2013/11/16/40 Cc: stable@vger.kernel.org (for 3.12 only) Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| | * | Partially revert "drm/i915: tune the RC6 threshold for stability"Daniel Vetter2013-11-161-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This reverts commit 351aa5666d02062b52329bcfe4bcf9d1f882fba9. It breaks rc6 on at least one snb machine. Since we don't yet have a report for ivb let's keep it there for now. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=71656 Cc: Stéphane Marchesin <marcheu@chromium.org> Cc: erik@vontaene.de Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| | * | drm/i915: flush cursors harderDaniel Vetter2013-11-151-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Apparently they need the same treatment as primary planes. This fixes modesetting failures because of stuck cursors (!) on Thomas' i830M machine. I've figured while at it I'll also roll it out for the ivb 3 pipe version of this function. I didn't do this for i845/i865 since Bspec says the update mechanism works differently, and there's some additional rules about what can be updated in which order. Tested-by: Thomas Richter <thor@math.tu-berlin.de> Cc: stable@vger.kernel.org Cc: Thomas Richter <thor@math.tu-berlin.de> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| | * | i915: Use 120MHz LVDS SSC clock for gen5/gen6/gen7Duncan Laurie2013-11-151-1/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We had been using a DMI table workaround to select the right frequency for devices, but this is fragile and must be updated with every new platform. Instead the default case when VBT is missing is changed to use 120MHz clock for LVDS SSC for these generations. The docs for 2010-Core, SandyBridge, and IvyBridge all indicate that the reference frequency for LVDS is 120MHz: "2010 Core" http://intellinuxgraphics.org/IHD_OS_Vol3_Part3r2.pdf page 38 Reference Frequency: 120MHz for CRT and LVDS. 100MHz for the FDI. "2011 SandyBridge" http://intellinuxgraphics.org/documentation/SNB/IHD_OS_Vol3_Part3.pdf page 33 Reference Frequency: 120MHz for CRT, HDMI, LVDS. 100MHz for the FDI. "2012 IvyBridge" http://intellinuxgraphics.org/documentation/IVB/IHD_OS_Vol3_Part4.pdf page 27 Reference Frequency: 120 MHz for CRT, HDMI, LVDS, 100MHz for the FDI. Signed-off-by: Duncan Laurie <dlaurie@chromium.org> [olof: Fixup for recent base, switched from if/else to single call] Signed-off-by: Olof Johansson <olof@lixom.net> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| | * | drm/i915/dp: set sink to power down mode on dp disableJani Nikula2013-11-141-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We used to put the local sink and any downstream sinks to power down mode at disable or dpms off using the DPCD SET_POWER register, until this was broken by commit e8cb455876fa8f67c6aba394d0a14b697bf04cc3 Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Sun Jul 1 13:05:48 2012 +0200 drm/i915/dp: convert to encoder disable/enable Fix it. Signed-off-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Todd Previte <tprevite@gmail.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
generated by cgit v1.2.3-55-g7522 (git 2.39.0) at 2024-07-19 17:11:40 +0200