summaryrefslogtreecommitdiff
path: root/drivers/gpu/drm/i915
AgeCommit message (Collapse)Author
2015-03-20drm/i915: check for div-by-zero in vlv_PLL_is_optimalImre Deak
Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-03-20drm/i915: factor out vlv_PLL_is_optimalImre Deak
Factor out the logic to decide whether the newly calculated dividers are better than the best found so far. Do this for clarity and to prepare for the upcoming BXT helper needing the same. No functional change. Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-03-20drm/i915: Kill intel_plane->objVille Syrjälä
intel_plane->obj is not used anymore so kill it. Also don't pass both the fb and obj to the sprite .update_plane() hook, as just passing the fb is enough. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-03-20drm/i915: Initialize all contextsBen Widawsky
The problem is we're going to switch to a new context, which could be the default context. The plan was to use restore inhibit, which would be fine, except if we are using dynamic page tables (which we will). If we use dynamic page tables and we don't load new page tables, the previous page tables might go away, and future operations will fault. CTXA runs. switch to default, restore inhibit CTXA dies and has its address space taken away. Run CTXB, tries to save using the context A's address space - this fails. The general solution is to make sure every context has it's own state, and its own address space. For cases when we must restore inhibit, first thing we do is load a valid address space. I thought this would be enough, but apparently there are references within the context itself which will refer to the old address space - therefore, we also must reinitialize. v2: to->ppgtt is only valid in full ppgtt. v3: Rebased. v4: Make post PDP update clearer. Signed-off-by: Ben Widawsky <ben@bwidawsk.net> Signed-off-by: Michel Thierry <michel.thierry@intel.com> (v2+) Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-03-20drm/i915: Track page table reload needBen Widawsky
This patch was formerly known as, "Force pd restore when PDEs change, gen6-7." I had to change the name because it is needed for GEN8 too. The real issue this is trying to solve is when a new object is mapped into the current address space. The GPU does not snoop the new mapping so we must do the gen specific action to reload the page tables. GEN8 and GEN7 do differ in the way they load page tables for the RCS. GEN8 does so with the context restore, while GEN7 requires the proper load commands in the command streamer. Non-render is similar for both. Caveat for GEN7 The docs say you cannot change the PDEs of a currently running context. We never map new PDEs of a running context, and expect them to be present - so I think this is okay. (We can unmap, but this should also be okay since we only unmap unreferenced objects that the GPU shouldn't be tryingto va->pa xlate.) The MI_SET_CONTEXT command does have a flag to signal that even if the context is the same, force a reload. It's unclear exactly what this does, but I have a hunch it's the right thing to do. The logic assumes that we always emit a context switch after mapping new PDEs, and before we submit a batch. This is the case today, and has been the case since the inception of hardware contexts. A note in the comment let's the user know. It's not just for gen8. If the current context has mappings change, we need a context reload to switch v2: Rebased after ppgtt clean up patches. Split the warning for aliasing and true ppgtt options. And do not break aliasing ppgtt, where to->ppgtt is always null. v3: Invalidate PPGTT TLBs inside alloc_va_range. v4: Rename ppgtt_invalidate_tlbs to mark_tlbs_dirty and move pd_dirty_rings from i915_address_space to i915_hw_ppgtt. Fixes when neither ctx->ppgtt and aliasing_ppgtt exist. v5: Removed references to teardown_va_range. v6: Updated needs_pd_load_pre/post. v7: Fix pd_dirty_rings check in needs_pd_load_post, and update/move comment about updated PDEs to object_pin/bind (Mika). Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com> Signed-off-by: Ben Widawsky <ben@bwidawsk.net> Signed-off-by: Michel Thierry <michel.thierry@intel.com> (v2+) Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-03-20drm/i915: Track GEN6 page table usageBen Widawsky
Instead of implementing the full tracking + dynamic allocation, this patch does a bit less than half of the work, by tracking and warning on unexpected conditions. The tracking itself follows which PTEs within a page table are currently being used for objects. The next patch will modify this to actually allocate the page tables only when necessary. With the current patch there isn't much in the way of making a gen agnostic range allocation function. However, in the next patch we'll add more specificity which makes having separate functions a bit easier to manage. One important change introduced here is that DMA mappings are created/destroyed at the same page directories/tables are allocated/deallocated. Notice that aliasing PPGTT is not managed here. The patch which actually begins dynamic allocation/teardown explains the reasoning for this. v2: s/pdp.page_directory/pdp.page_directories Make a scratch page allocation helper v3: Rebase and expand commit message. v4: Allocate required pagetables only when it is needed, _bind_to_vm instead of bind_vma (Daniel). v5: Rebased to remove the unnecessary noise in the diff, also: - PDE mask is GEN agnostic, renamed GEN6_PDE_MASK to I915_PDE_MASK. - Removed unnecessary checks in gen6_alloc_va_range. - Changed map/unmap_px_single macros to use dma functions directly and be part of a static inline function instead. - Moved drm_device plumbing through page tables operation to its own patch. - Moved allocate/teardown_va_range calls until they are fully implemented (in subsequent patch). - Merged pt and scratch_pt unmap_and_free path. - Moved scratch page allocator helper to the patch that will use it. v6: Reduce complexity by not tearing down pagetables dynamically, the same can be achieved while freeing empty vms. (Daniel) v7: s/i915_dma_map_px_single/i915_dma_map_single s/gen6_write_pdes/gen6_write_pde Prevent a NULL case when only GGTT is available. (Mika) v8: Rebased after s/page_tables/page_table/. v9: Reworked i915_pte_index and i915_pte_count. Also exercise bitmap allocation here (gen6_alloc_va_range) and fix incorrect write_page_range in i915_gem_restore_gtt_mappings (Mika). Cc: Daniel Vetter <daniel@ffwll.ch> Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com> Signed-off-by: Ben Widawsky <ben@bwidawsk.net> Signed-off-by: Michel Thierry <michel.thierry@intel.com> (v3+) Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-03-20drm/i915: Extract context switch skip and add pd load logicBen Widawsky
In Gen8, PDPs are saved and restored with legacy contexts (legacy contexts only exist on the render ring). So change the ordering of LRI vs MI_SET_CONTEXT for the initialization of the context. Also the only cases in which we need to manually update the PDPs are when MI_RESTORE_INHIBIT has been set in MI_SET_CONTEXT (i.e. when the context is not yet initialized or it is the default context). Legacy submission is not available post GEN8, so it isn't necessary to add extra checks for newer generations. v2: Use new functions to replace the logic right away (Daniel) v3: Add missing pd load logic. v4: Add warning in case pd_load_pre & pd_load_post are true, and add missing trace_switch_mm. Cleaned up pd_load conditions. Add more information about when is pd_load_post needed. (Mika) Signed-off-by: Ben Widawsky <ben@bwidawsk.net> Signed-off-by: Michel Thierry <michel.thierry@intel.com> (v2+) Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-03-20drm/i915: page table generalizationsMichel Thierry
No functional changes, but will improve code clarity and removed some duplicated defines. Signed-off-by: Michel Thierry <michel.thierry@intel.com> Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-03-20drm/i915: Send out the full AUX addressVille Syrjälä
AUX addresses are 20 bits long. Send out the entire address instead of just the low 16 bits. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-03-20drm/i915: kerneldoc for i915_gem_shrinker.cDaniel Vetter
And remove one bogus * from i915_gem_gtt.c since that's not a kerneldoc there. v2: Review from Chris: - Clarify memory space to better distinguish from address space. - Add note that shrink doesn't guarantee the freed memory and that users must fall back to shrink_all. - Explain how pinning ties in with eviction/shrinker. Cc: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-03-20drm/i915: Extract i915_gem_shrinker.cDaniel Vetter
Two code changes: - Extract i915_gem_shrinker_init. - Inline i915_gem_object_is_purgeable since we open-code it everywhere else too. This already has the benefit of pulling all the shrinker code together, next patch adds a bit of kerneldoc. Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-03-20drm/i915: Use down ei for manual Baytrail RPS calculationsChris Wilson
Use both up/down manual ei calcuations for symmetry and greater flexibility for reclocking, instead of faking the down interrupt based on a fixed integer number of up interrupts. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Deepak S<deepak.s@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-03-20drm/i915: Improved w/a for rps on BaytrailChris Wilson
Rewrite commit 31685c258e0b0ad6aa486c5ec001382cf8a64212 Author: Deepak S <deepak.s@linux.intel.com> Date: Thu Jul 3 17:33:01 2014 -0400 drm/i915/vlv: WA for Turbo and RC6 to work together. Other than code clarity, the major improvement is to disable the extra interrupts generated when idle. However, the reclocking remains rather slow under the new manual regime, in particular it fails to downclock as quickly as desired. The second major improvement is that for certain workloads, like games, we need to combine render+media activity counters as the work of displaying the frame is split across the engines and both need to be taken into account when deciding the global GPU frequency as memory cycles are shared. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Deepak S <deepak.s@linux.intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by: Deepak S<deepak.s@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-03-20drm/i915: Relax RPS contraints to allows setting minfreq on idleChris Wilson
When we idle, we set the GPU frequency to the hardware minimum (not user minimum). We introduce a new variable to distinguish between the different roles, and to allow easy tuning of the idle frequency without impacting over aspects of RPS. Setting the minimum frequency should be a safety blanket as the pcu on the GPU should be power gating itself anyway. However, in order for us to do set the absolute minimum frequency, we need to relax a few of our assertions that we do not exceed the user limits. v2: Add idle_freq v3: Init idle_freq for vlv and add a bunch of WARNs Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Deepak S <deepak.s@linux.intel.com> Reviewed-by: Deepak S<deepak.s@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-03-20drm/i915: Fallback to using CPU relocations for large batch buffersChris Wilson
If the batch buffer is too large to fit into the aperture and we need a GTT mapping for relocations, we currently fail. This only applies to a subset of machines for a subset of environments, quite undesirable. We can simply check after failing to insert the batch into the GTT as to whether we only need a mappable binding for relocation and, if so, we can revert to using a non-mappable binding and an alternate relocation method. However, using relocate_entry_cpu() is excruciatingly slow for large buffers on non-LLC as the entire buffer requires clflushing before and after the relocation handling. Alternatively, we can implement a third relocation method that only clflushes around the relocation entry. This is still slower than updating through the GTT, so we prefer using the GTT where possible, but is orders of magnitude faster as we typically do not have to then clflush the entire buffer. An alternative idea of using a temporary WC mapping of the backing store is promising (it should be faster than using the GTT itself), but requires fairly extensive arch/x86 support - along the lines of kmap_atomic_prof_pfn() (which is not universally implemented even for x86). Testcase: igt/gem_exec_big #pnv,byt Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=88392 Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> [danvet: Add a WARN_ONCE for the impossible reloc case and explain in a short comment why we want to avoid ping-pong.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-03-20drm/i915: Turn on PIN_GLOBAL in i915_gem_object_ggtt_pinTvrtko Ursulin
This makes the interface consistent to old i915_gem_obj_ggtt_pin. Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-03-20drm/i915: memory leak in __i915_gem_vma_create()Dan Carpenter
In the original code then if WARN_ON(i915_is_ggtt(vm) != !!ggtt_view) was true then we leak "vma". Presumably that doesn't happen often but static checkers complain and this bug is easy to fix. Fixes: c3bbb6f2825d ('drm/i915: Do not use ggtt_view with (aliasing) PPGTT') Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-03-20drm/i915/dp: return number of bytes written for short aux/i2c writesJani Nikula
Allow for a larger receive data size, and check if the receiver returned the number of bytes written. Without this, we've basically skipped all the unwritten bytes for short writes. Signed-off-by: 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>
2015-03-20drm/i915: Unconfuse DP link rate array namesVille Syrjälä
To keep things clear rename the intel_dp->supported_rates[] to intel_dp->sink_rates[], and rename the supported_rates[] name we used elsewhere for the intersection of source and sink rates to common_rates[]. Cc: Sonika Jindal <sonika.jindal@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Sonika Jindal <sonika.jindal@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-03-20drm/i915: Include the sink/source/supported rates in debug outputVille Syrjälä
TODO: Is there an actually nice way to print an array of ints? Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Sonika Jindal <sonika.jindal@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-03-20drm/i915: Add eDP intermediate frequencies for CHVVille Syrjälä
"P1273_DPLL_Programming Spreadsheet.xlsm" lists a boatload of frequencies for eDP. Try to use them all. For now I've decided not to add hardcoded DPLL dividers for these cases since chv_find_best_dpll() works just fine. I've not actually tested any of these since I don't have an eDP 1.4 panel. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Sonika Jindal <sonika.jindal@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-03-20drm/i915: Avoid overflowing the DP link rate arraysVille Syrjälä
Complain loudly if we ever attempt to overflow the the supported_rates[] array. This should never happen since the sink_rates[] array will always be smaller or of equal size. But should someone change that we want to catch it without scribblign over the stack. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Sonika Jindal <sonika.jindal@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-03-20drm/i915: Fix MST link rate handlingVille Syrjälä
Now that intel_dp_max_link_bw() no longer considers the source restrictions we may try to enable MST with 5.4GHz even when the source doesn't support it. To fix that switch the code over to handle the link rate in the same way as the SST code handles it. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Sonika Jindal <sonika.jindal@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-03-20drm/i915: Use DP_LINK_RATE_SET whenever possibleVille Syrjälä
Drop the gen9 checks from the code and issue DP_LINK_RATE_SET whenever the sink reports to support it. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Sonika Jindal <sonika.jindal@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-03-20drm/i915: Fix max link rate in intel_dp_mode_valid()Ville Syrjälä
Consider the link rates reported by the sink via DP_SUPPORTED_LINK_RATES when checking modes against the max link rate. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Sonika Jindal <sonika.jindal@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-03-20drm/i915: Hide the source vs. sink rate handling from intel_dp_compute_config()Ville Syrjälä
intel_dp_compute_config() only really needs to know the rates supported by both source and sink, so hide the raw source and sink arrays from it. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Sonika Jindal <sonika.jindal@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-03-20drm/i915: Fully separate source vs. sink ratesVille Syrjälä
Remove the sink vs. source limit mess from intel_dp_max_link_bw() and just move the source restriction checks to intel_dp_source_rates(). Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Sonika Jindal <sonika.jindal@intel.com> [danvet: Resolve conflict with WaDisableHBR2:skl patch.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-03-20drm/i915: Remove special case from intel_supported_rates()Ville Syrjälä
Now that both source and sink rates are always filled in there's no need for any special cases in intel_supported_rates(). Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Sonika Jindal <sonika.jindal@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-03-20drm/i915: Don't copy sink rates eitherVille Syrjälä
Once we've read the rates from the sink we don't have to mess with them, so the caller can just look at the stored rates without doing extra copies. If the sink doesn't support the new link rate stuff, we just point the caller at the default_rates[] array. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Sonika Jindal <sonika.jindal@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-03-20drm/i915: Don't copy the DP source rates arraysVille Syrjälä
The source rates don't change, so we can just point the caller at the const arrays. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Sonika Jindal <sonika.jindal@intel.com> Reviewed-by: Todd Previte <tprevite@gmail.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-03-20drm/i915: Store the converted link rates in intel_dp->supported_rates[]Ville Syrjälä
No point in converting from hardware format every single time, just store the rates in the final format under intel_dp. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Sonika Jindal <sonika.jindal@intel.com> Reviewed-by: Todd Previte <tprevite@gmail.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-03-20drm/i915: Make the DP rates int instead of uint32_tVille Syrjälä
No point in using uint32_t here, just plain old int will do. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Sonika Jindal <sonika.jindal@intel.com> Reviewed-by: Todd Previte <tprevite@gmail.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-03-20drm/i915: Do not use ggtt_view with (aliasing) PPGTTJoonas Lahtinen
GGTT views are only applicable when dealing with GGTT. Change the code to reject ggtt_view where it should not be used and require it when it should be. v2: - Dropped _ppgtt_ infixes, allow both types to be passed - Disregard other but normal views when no view is specified - More checks that valid parameters are passed - More readable error checking v3: - Prefer WARN_ONCE over BUG_ON when there is code path for failure Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> [danvet: Drop unecessary forward decl from earlier patch iterations.] [danvet: Remove unused variable spotted by Tvrtko.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-03-20drm/i915: Fix sink crc connector iterationRodrigo Vivi
Regressed by this commit: commit 3455454e18ca3f92c565700539e744c620d8276b Author: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com> Date: Tue Mar 3 15:21:56 2015 +0200 drm/i915: Add a for_each_intel_connector macro Cc: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: Ander Conselvan de Oliveira <conselvan2@gmail.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-03-20Merge tag 'drm-intel-fixes-2015-03-19' into drm-intel-nextDaniel Vetter
Backmerge because of numerous and interleaving conflicts and git rerere getting confused a bit too often. Conflicts: drivers/gpu/drm/i915/intel_display.c All conflicts are because of -next patches backported to -fixes, so just go with the code in -next. Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
2015-03-18drm/i915: Make sure the primary plane is enabled before reading out the fb stateDamien Lespiau
We don't want to end up in a state where we track that the pipe has its primary plane enabled when primary plane registers are programmed with values that look possible but the plane actually disabled. Refuse to read out the fb state when the primary plane isn't enabled. Suggested-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Suggested-by: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: Damien Lespiau <damien.lespiau@intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Reported-by: Andrey Skvortsov <andrej.skvortzov@gmail.com> Reported-by: Steven Rostedt <rostedt@goodmis.org> Reference: http://mid.gmane.org/20150203191507.GA2374@crion86 Tested-by: Steven Rostedt <rostedt@goodmis.org> Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2015-03-17drm/i915: Update DRIVER_DATE to 20150313Daniel Vetter
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-03-17drm/i915: Fix vmap_batch page iterator overrunMika Kuoppala
vmap_batch() calculates amount of needed pages for the mapping we are going to create. And it uses this page count as an argument for the for_each_sg_pages() macro. The macro takes the number of sg list entities as an argument, not the page count. So we ended up iterating through all the pages on the mapped object, corrupting memory past the smaller pages[] array. Fix this by bailing out when we have enough pages. This regression has been introduced in commit 17cabf571e50677d980e9ab2a43c5f11213003ae Author: Chris Wilson <chris@chris-wilson.co.uk> Date: Wed Jan 14 11:20:57 2015 +0000 drm/i915: Trim the command parser allocations Cc: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-03-17drm/i915: Export total subslice and EU countsJeff McGee
Setup new I915_GETPARAM ioctl entries for subslice total and EU total. Userspace drivers need these values when constructing GPGPU commands. This kernel query method is intended to replace the PCI ID-based tables that userspace drivers currently maintain. The kernel driver can employ fuse register reads as needed to ensure the most accurate determination of GT config attributes. This first became important with Cherryview in which the config could differ between devices with the same PCI ID. The kernel detection of these values is device-specific and not included in this patch. Because zero is not a valid value for any of these parameters, a value of zero is interpreted as unknown for the device. Userspace drivers should continue to maintain ID-based tables for older devices not supported by the new query method. v2: Increment our I915_GETPARAM indices to fit after REVISION which was merged ahead of us. For: VIZ-4636 Signed-off-by: Jeff McGee <jeff.mcgee@intel.com> Tested-by: Zhigang Gong <zhigang.gong@linux.intel.com> Acked-by: Zhigang Gong <zhigang.gong@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-03-17drm/i915: redefine WARN_ON_ONCE to include the conditionJani Nikula
Same as commit c883ef1b1c998d2d66866772fd0fc34afa45641e Author: Mika Kuoppala <miku@iki.fi> Date: Tue Oct 28 17:32:30 2014 +0200 drm/i915: Redefine WARN_ON to include the condition but for WARN_ON_ONCE. Since the kernel WARN_ON_ONCE actually picks up *our* version of WARN_ON, we end up with messages like [ 838.285319] WARN_ON(!__warned) which are not that helpful. Signed-off-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-03-17drm/i915/skl: Implement WaDisableHBR2Damien Lespiau
v2: Use the recently introduced INTEL_REVID() and SKL_REVID defines (Nick Hoath) Signed-off-by: Damien Lespiau <damien.lespiau@intel.com> Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Tested-by: Jesse Barnes <jbarnes@virtuousgeek.org> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=89554 Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-03-17drm/i915: Remove the preliminary_hw_support shackles from CHVVille Syrjälä
CHV should be in a good enough shape now, so let's drop the .is_preliminary flag. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-03-17drm/i915: Read CHV_PLL_DW8 from the correct offsetVille Syrjälä
We accidentally pass 'pipe' instead of 'port' to CHV_PLL_DW8() and with PIPE_C we end up at register offset 0x8320 which isn't the 0x8020 we wanted. Fix it. The problem was fortunately caught by the sanity check in vlv_dpio_read(): WARNING: CPU: 1 PID: 238 at ../drivers/gpu/drm/i915/intel_sideband.c:200 vlv_dpio_read+0x77/0x80 [i915]() DPIO read pipe C reg 0x8320 == 0xffffffff The problem got introduced with this commit: commit 71af07f91f12bbab96335e202c82525d31680960 Author: Vijay Purushothaman <vijay.a.purushothaman@linux.intel.com> Date: Thu Mar 5 19:33:08 2015 +0530 drm/i915: Update prop, int co-eff and gain threshold for CHV Cc: Vijay Purushothaman <vijay.a.purushothaman@linux.intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Todd Previte <tprevite@gmail.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-03-17drm/i915: Rewrite IVB FDI bifurcation conflict checksVille Syrjälä
Ignore the current state of the pipe and just check crtc_state->enable and the number of FDI lanes required. This means we don't accidentally mistake the FDI lanes as being available of one of the pipes just happens to be disabled at the time of the check. Also we no longer consider pipe C to require FDI lanes when it's driving the eDP transcoder. We also take the opportunity to make the code a bit nicer looking by hiding the ugly bits in the new pipe_required_fdi_lanes() function. Cc: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com> Cc: Daniel Vetter <daniel@ffwll.ch> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Ander Conselvan de Oliveira <conselvan2@gmail.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-03-17drm/i915: Rewrite some some of the FDI lane checksVille Syrjälä
The logic in the FDI lane checks is very hard for my poor brain to grasp. Rewrite it in a more straightforward way. Cc: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com> Cc: Daniel Vetter <daniel@ffwll.ch> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Ander Conselvan de Oliveira <conselvan2@gmail.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-03-17drm/i915/skl: Enable the RPS interrupts programmingAkash Goel
Enable the RPS interrupts programming(enable/disable/reset) for GEN9, as missing changes to enable the RPS support on GEN9 have been added. Signed-off-by: Akash Goel <akash.goel@intel.com> Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-03-17drm/i915/skl: Enabling processing of Turbo interruptsAkash Goel
Earlier Turbo interrupts were not being processed for SKL, as something was amiss in turbo programming for SKL. Now missing changes have been added, so enabling the Turbo interrupt processing for SKL. Signed-off-by: Akash Goel <akash.goel@intel.com> Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-03-17drm/i915/skl: Updated the i915_frequency_info debugfs functionAkash Goel
Added support for SKL in the i915_frequency_info debugfs function v2: - corrected the handling of reqf (Damien) - Reorderd the platform check for cagf (Ville) Signed-off-by: Akash Goel <akash.goel@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-03-17drm/i915: Simplify the way BC bifurcation state consistency is keptAnder Conselvan de Oliveira
Remove the global modeset resource function that would disable the bifurcation bit, and instead enable/disable it when enabling the pch transcoder. The mode set consistency check should prevent us from disabling the bit if pipe C is enabled so the change should be safe. Note that this doens't affect the logic that prevents the bit being set while a pipe is active, since the patch retains the behavior of only chaging the bit if necessary. Because of the checks during mode set, the first change would necessarily happen with both pipes B and C disabled, and any subsequent write would be skipped. v2: Only change the bit during pch trancoder enable. (Ville) Signed-off-by: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-03-17drm/i915/skl: Updated the act_freq_mhz_show sysfs functionAkash Goel
Added support for SKL in the act_freq_mhz_show sysfs function Signed-off-by: Akash Goel <akash.goel@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>