- 05 Mar, 2014 21 commits
-
-
Ben Widawsky authored
This got lost when we shuffled around our internal branch and GEN7_FEATURES macro. There were no HW changes to support FBC, so we just need to set the flag. v2: Don't allow FBC for any pipe but A on platforms with DDI. (Paulo) Cc: Daisy Sun <daisy.sun@intel.com> Signed-off-by:
Ben Widawsky <ben@bwidawsk.net> Reviewed-by:
Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch>
-
Chris Wilson authored
We currently call intel_mark_idle() too often, as we do so as a side-effect of processing the request queue. However, we the calls to intel_mark_idle() are expected to be paired with a call to intel_mark_busy() (or else we try to idle the hardware by accessing registers that are already disabled). Make the idle/busy tracking explicit to prevent the multiple calls. v2: We can drop some of the complexity in __i915_add_request() as queue_delayed_work() already behaves as we want (not requeuing the item if it is already in the queue) and mark_busy/mark_idle imply that the idle task is inactive. v3: We do still need to cancel the pending idle task so that it is sent again after the current busy load completes (not in the middle of it). Reported-by:
Chris Wilson <chris@chris-wilson.co.uk> Cc: Paulo Zanoni <paulo.r.zanoni@intel.com> Reviewed-by:
-
Mika Kuoppala authored
Sometimes generic driver code gets forcewake explicitly by gen6_gt_force_wake_get(), which check forcewake_count before accessing hardware. However the register access with gen8_write function access low level hw accessors directly, ignoring the forcewake_count. This leads to nested forcewake get from hardware, in ring init and possibly elsewhere, causing forcewake ack clear errors and/or hangs. Fix this by checking the forcewake count also in gen8_write v2: Read side doesn't care about shadowed registers, Remove __needs_put funkiness from gen8_write. (Ville) Improved commit message. References: https://bugs.freedesktop.org/show_bug.cgi?id=74007Signed-off-by:Mika Kuoppala <mika.kuoppala@intel.com> Cc: Ben Widawsky <benjamin.widawsky@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by:
-
Imre Deak authored
Signed-off-by:
Imre Deak <imre.deak@intel.com> Reviewed-by:
Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by:
-
Imre Deak authored
This way we can reuse the check on other platforms too. Also factor out a version of the function that doesn't check if the power is on, we'll need to call this from within the power domain framework. Signed-off-by:
-
Imre Deak authored
On VLV at least the display IRQ register access and functionality depends on its power well to be on, so move the power domain HW init before we install the IRQs. Signed-off-by:
-
Imre Deak authored
The power domains framework is internal to the i915 driver, so pass drm_i915_private instead of drm_device to its functions. Also remove a dangling intel_set_power_well() declaration. No functional change. Signed-off-by:
-
Daniel Vetter authored
Both Ville and QA rather immediately complained that with the new initial_config logic from Jesse not all outputs get enabled. Since the fbdev emulation pretty much tries to always enable as many outputs as possible (it even has hotplug handling and all that) fall back if more outputs could have been enabled. v2: Fix up my confusion about what enabled means - it's passed from the fbdev helper, we need to check for a non-zero connector->encoder link. Spotted by Ville. v3: Add some debug output as requested by Jesse for debugging fallback issues. Cc: Jesse Barnes <jbarnes@virtuousgeek.org> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=75552Tested-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by:
-
Daniel Vetter authored
It started as a simple check whether anything is lit up, but now is't used to driver the general fallback logic to the default output configuration selector in the helper library. So rename it for more clarity. Cc: Jesse Barnes <jbarnes@virtuousgeek.org> Reviewed-by:
-
Chris Wilson authored
This should be impossible due to the wait for outstanding flips that the caller is meant to perform prior to updating the scanout base. Paranoia tells me to check anyway. References: https://bugs.freedesktop.org/show_bug.cgi?id=75502Signed-off-by:
-
Chris Wilson authored
This reverts commit 116f2b6d. This optimization causes widespread corruption in games, and even in glxgears, on my ivb:gt1. The corruption appears like z-fighting of overlapping polygons in the HiZ buffer. The observation ties in very closely with the description of the optimization disabled by default on IVB: "The Hierarchical Z RAW Stall Optimization allows non-overlapping polygons in the same 8x4 pixel/sample area to be processed without stalling waiting for the earlier ones to write to Hierarchical Z buffer." No reason is given for why it is disabled by default, usually for such optimizations it is that it is incomplete. However, there is no indication whether this a gt1 only issue either. Before considering reenabling this optimization, I would first suggest reproducing the corruption in piglit. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=75623Signed-off-by:
-
Jesse Barnes authored
To silence locking complaints. This was a rebase failure on my part in commit fa9fa083 Author: Jesse Barnes <jbarnes@virtuousgeek.org> Date: Tue Feb 11 15:28:56 2014 -0800 drm/i915: read out hw state earlier v2 Reported-by:
-
Jesse Barnes authored
In the move over to use BIOS connector configs, we lost the ability to force a specific set of connectors on or off. Try to remedy that by dropping back to the old behavior if we detect a hard coded connector config. v2: don't deref connector state for disabled connectors (Jesse) Reported-by:
-
Chris Wilson authored
In commit e4e0c058 Author: Eugeni Dodonov <eugeni.dodonov@intel.com> Date: Wed Feb 8 12:53:50 2012 -0800 drm/i915: gen7: Implement an L3 caching workaround. the L3 cache aging was disabled. This was part of a shotgun response to a number of GPU hang bugs, but there appears to be no documentation to suggest that disabling the L3 cache age was ever required (to prevent the GPU hangs). Restoring the L3 cache age is a minor performance win of around 2% on IVB:GT2. (Note that this value seems to be consistent across a number of tests and so appears to be above the usual noise.) Signed-off-by:
-
Sinclair Yeh authored
V2: edit the commit message to contain more info The W/A spreadsheet says this is still required, but the b-spec says it's not for BYT-T. So the documentation is not clear. However, our experience with the other SKUs of BYT-I/M on Android and Linux suggests that setting this bit actually causes GPU hang for certain OGL benchmark applications. Removing this bit completely resolves the GPU hangs. Signed-off-by:
Sinclair Yeh <sinclair.yeh@intel.com> Acked-by:
-
Ben Widawsky authored
With the original PPGTT implementation if the number of PDPs was not a power of two, the number of pages for the page tables would end up being rounded up. The code actually had a bug here afaict, but this is a theoretical bug as I don't believe this can actually occur with the current code/HW.. With the rework of the page table allocations, there is no longer a distinction between number of page table pages, and number of page directory entries. To avoid confusion, kill the redundant (and newer) struct member. Cc: Imre Deak <imre.deak@intel.com> Signed-off-by:
-
Ben Widawsky authored
Simply to match the GEN8 style of PPGTT initialization, split up the allocations and mappings. Unlike GEN8, we skip a separate dma_addr_t allocation function, as it is much simpler pre-gen8. With this code it would be easy to make a more general PPGTT initialization function with per GEN alloc/map/etc. or use a common helper, similar to the ringbuffer code. I don't see a benefit to doing this just yet, but who knows... Reviewed-by:
-
Ben Widawsky authored
This cleanup is similar to the GEN8 cleanup (though less necessary). Having everything split will make cleaning the initialization path error paths easier to understand. Reviewed-by:
-
Ben Widawsky authored
I keep meaning to do this... by now almost the entire file has been written by an Intel employee (including Daniel post-2010). Reviewed-by:
-
Ben Widawsky authored
This reverts commit 3a2ffb65. Now that the code is fixed to use smaller allocations, it should be safe to let the full GGTT be used on BDW. The testcase for this is anything which uses more than half of the GTT, thus eclipsing the old limit. Reviewed-by:
-
Ben Widawsky authored
The previous allocation mechanism would get 2 contiguous allocations, one for the page directories, and one for the page tables. As each page table is 1 page, and there are 512 of these per page directory, this goes to 2MB. An unfriendly request at best. Worse still, our HW now supports 4 page directories, and a 2MB allocation is not allowed. In order to fix this, this patch attempts to split up each page table allocation into a single, discrete allocation. There is nothing really fancy about the patch itself, it just has to manage an extra pointer indirection, and have a fancier bit of logic to free up the pages. To accommodate some of the added complexity, two new helpers are introduced to allocate, and free the page table pages. NOTE: I really wanted to split the way we do allocations, and the way in which we identify the page table/page directory being used. I found splitting this functionality up to be too unwieldy. I apologize in advance to the reviewer. I'd recommend looking at the result, rather than the diff. v2/NOTE2: This patch predated commit: 6f1cc993 Author: Chris Wilson <chris@chris-wilson.co.uk> Date: Tue Dec 31 15:50:31 2013 +0000 drm/i915: Avoid dereference past end of page arr It fixed the same issue as that patch, but because of the limbo state of PPGTT, Chris patch was merged instead. The excess churn is a result of my using my original patch, which has my preferred naming. Primarily act_* is changed to which_*, but it's mostly the same otherwise. I've kept the convention Chris used for the pte wrap (I had something slightly different, and broken - but fixable) v3: Rename which_p[..]e to drop which_ (Chris) Remove BUG_ON in inner loop (Chris) Redo the pde/pdpe wrap logic (Chris) v4: s/1MB/2MB in commit message (Imre) Plug leaking gen8_pt_pages in both the error path, as well as general free case (Imre) v5: Rename leftover "which_" variables (Imre) Add the pde = 0 wrap that was missed from v3 (Imre) Reviewed-by:
-
- 04 Mar, 2014 15 commits
-
-
Ben Widawsky authored
This patch converts insert_entries and clear_range, both functions which are specific to the VM. These functions tend to encapsulate the gen specific PTE writes. Passing absolute addresses to the insert_entries, and clear_range will help make the logic clearer within the functions as to what's going on. Currently, all callers simply do the appropriate page shift, which IMO, ends up looking weird with an upcoming change for the gen8 page table allocations. Up until now, the PPGTT was a funky 2 level page table. GEN8 changes this to look more like a 3 level page table, and to that extent we need a significant amount more memory simply for the page tables. To address this, the allocations will be split up in finer amounts. v2: Replace size_t with uint64_t (Chris, Imre) v3: Fix size in gen8_ppgtt_init (Ben) Fix Size in i915_gem_suspend_gtt_mappings/restore (Imre) Reviewed-by: Imre Deak <imre.deak@intel.com> (v2) Signed-off-by:
-
Ben Widawsky authored
Like cleanup in an earlier patch, the code becomes much more readable, and easier to extend if we extract out helper functions for the various stages of init. Note that with this patch it becomes really simple, and tempting to begin using the 'goto out' idiom with explicit free/fini semantics. I've kept the error path as similar as possible to the cleanup() function to make sure cleanup is as robust as possible v2: Remove comment "NB:From here on, ppgtt->base.cleanup() should function properly" Update commit message to reflect above v3: Rebased on top of bugfixes found in the previous patch by Imre Moved number of pd pages assertion to the proper place (Imre) v4: Allocate dma address space for num_pd_pages, not num_pd_entries (Ben) Don't use gen8_pt_dma_addr after free on error path (Imre) With new fix from v4 of the previous patch. Signed-off-by:
-
Ben Widawsky authored
Create 3 clear stages in PPGTT init. This will help with upcoming changes be more readable. The 3 stages are, allocation, dma mapping, and writing the P[DT]Es One nice benefit to the patches is that it makes 2 very clear error points, allocation, and mapping, and avoids having to do any handling after writing PTEs (something which was likely buggy before). This simplified error handling I suspect will be helpful when we move to deferred/dynamic page table allocation and mapping. The patches also attempts to break up some of the steps into more logical reviewable chunks, particularly when we free. v2: Don't call cleanup on the error path since that takes down the drm_mm and list entry, which aren't setup at this point. v3: Fixes addressing Imre's comments from: <1392821989.19792.13.camel@intelbox> Don't do dynamic allocation for the page table DMA addresses. I can't remember why I did it in the first place. This addresses one of Imre's other issues. Fix error path leak of page tables. v4: Fix the fix of the error path leak. Original fix still leaked page tables. (Imre) Reviewed-by:
-
Ben Widawsky authored
GEN8 never freed the PPGTT struct. As GEN8 doesn't use full PPGTT, the leak is small and only found on a module reload. ie. I don't think this needs to go to stable. v2: The very naive, kfree in gen8 ppgtt cleanup, is subject to a double free on PPGTT initialization failure. (Spotted by Imre). Instead this patch pulls the ppgtt struct freeing out of the cleanup and leaves it to the allocators/callers or the one doing the last kref_put as in standard convention Reported-by:
-
Ben Widawsky authored
At one time it was expected to be called in multiple places by kref_put. At the current time however, it is all contained within i915_gem_context.c. This patch makes an upcoming required addition a bit nicer since it too doesn't need to be defined in a header file. Signed-off-by:
-
Ville Syrjälä authored
Add a comment next to our WIZ hashing setup to remind people about the link between WIZ hashing disable bit and PS/WM thread counts. Suggested-by:
-
Ville Syrjälä authored
BSpec recommends using 8x4 hashing mode when MSAA is used. But in practice 16x4 seems to have a slight edge in performance (on IVB and HSW at least). So just use 16x4. Signed-off-by:
Antti Koskipää <antti.koskipaa@linux.intel.com> Signed-off-by:
-
Ville Syrjälä authored
BSpec recommends using 8x4 hashing mode when MSAA is used. But in practice 16x4 seems to have a slight edge in performance (on IVB and HSW at least). So just use 16x4. Signed-off-by:
-
Ville Syrjälä authored
BSpec recommends using 8x4 hashing mode when MSAA is used. But in practice 16x4 seems to have a slight edge in performance (on IVB and HSW at least). So just use 16x4. Signed-off-by:
-
Ville Syrjälä authored
The need to set all of the mask bits for 3D_CHICKEN3 was required only for pre-production hardware. Signed-off-by:
-
Ville Syrjälä authored
Based on the name, the workaround we implement is WaStripsFansDisableFastClipPerformanceFix. Unfortunately there's no description in the w/a database, so this is just a guess. Signed-off-by:
-
Ville Syrjälä authored
On SNB we set up WaSetupGtModeTdRowDispatch:snb early in gen6_init_clock_gating(). That sets a bit in the GEN6_GT_MODE register. However later we go and disable all the bits in the same register. And then we go on to set some other bit. So apparently we never actually implemented this workaround since the "disable all bits" part was there already before the w/a got supposedly implemented. These are the relevant commits: commit 6547fbdb Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Fri Dec 14 23:38:29 2012 +0100 drm/i915: Implement WaSetupGtModeTdRowDispatch commit f8f2ac9a Author: Ben Widawsky <ben@bwidawsk.net> Date: Wed Oct 3 19:34:24 2012 -0700 drm/i915: Fix GT_MODE default value So, let's drop the "disable all bits" part, move both writes to closer proxomity to each other, and name the WIZ hashing bits appropriately. BSpec is still a bit confused how the bits should actually be interpreted, but I took the the description for the high bit since the low bit part only lists values for a single bit. Also add a comment about our choice of WIZ hashing mode. Signed-off-by:
-
Paulo Zanoni authored
We'll need this when we merge PC8 and Runtime PM: the PC8 enable/disable functions need that lock. Also, it's good practice to not hold a lock for longer than strictly needed. Signed-off-by:
-
Paulo Zanoni authored
To modeset_update_crtc_power_domains, since this function is responsible for updating all the power domains of all CRTCs after a modeset. In the future we should also run this function on all platforms, not just Haswell. Signed-off-by:
-
Thierry Reding authored
The i915 driver sets DRIVER_GEM unconditionally, so testing for the feature will always fail. Signed-off-by:
Thierry Reding <treding@nvidia.com> [danvet: Fix up conflicts.] Signed-off-by:
-
- 02 Mar, 2014 1 commit
-
-
Daniel Vetter authored
Apparently we've missed a few more than what Fengguang's 0-day tester recently reported in i915_irq.c ... Makes sparse happy again (ignore some spurious stuff about ksyms of exported functions). Cc: kbuild test robot <fengguang.wu@intel.com> Cc: Imre Deak <imre.deak@intel.com> Signed-off-by:
-
- 14 Feb, 2014 3 commits
-
-
Daniel Vetter authored
Spotted while auditing the code for fencing issues. Cc: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by:
Damien Lespiau <damien.lespiau@intel.com> Signed-off-by:
-
Daniel Vetter authored
Looks like I've missed one of the potential NULL deref bugs in Jesse's fbdev->fb embedded struct to pointer conversions. Fix it up. This regression has been introduced in commit 8bcd4553 Author: Jesse Barnes <jbarnes@virtuousgeek.org> Date: Fri Feb 7 12:10:38 2014 -0800 drm/i915: alloc intel_fb in the intel_fbdev struct Cc: Jesse Barnes <jbarnes@virtuousgeek.org> Reviewed-by:
-
Daniel Vetter authored
One side-effect of the introduction of ppgtt was that we needed to rebind the object into the appropriate vm (and global gtt in some peculiar cases). For simplicity this was done twice for every object on every call to execbuffer. However, that adds a tremendous amount of CPU overhead (rewriting all the PTE for all objects into WC memory) per draw. The fix is to push all the decision about which vm to bind into and when down into the low-level bind routines through hints rather than performing the bind unconditionally in the execbuffer routine. Note that this is a regression introduced in the full ppgtt feature branch, before this we've only done re-bound objects when the relevant has_(aliasing_ppgtt|global_gtt)_mapping flag was clear. But since that's per-object and not per-vma that optimization broke. v2: Split out prep work and unrelated changes. v3: Bring back functional change around PIN_GLOBAL that I've accidentally split out. v4: Remove the temporary hack for the old binding logic to avoid bisection issues. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=72906 Tested-by: jianx.zhou@intel.com Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> (v1) Cc: Ben Widawsky <benjamin.widawsky@intel.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Acked-by:
-
