aboutsummaryrefslogtreecommitdiffstats
path: root/drivers/gpu
Commit message (Collapse)AuthorAge
...
| * | | | | | | drm/i915: page table generalizationsMichel Thierry2015-03-20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
| * | | | | | | drm/i915: Send out the full AUX addressVille Syrjälä2015-03-20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
| * | | | | | | drm/i915: kerneldoc for i915_gem_shrinker.cDaniel Vetter2015-03-20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
| * | | | | | | drm/i915: Extract i915_gem_shrinker.cDaniel Vetter2015-03-20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
| * | | | | | | drm/i915: Use down ei for manual Baytrail RPS calculationsChris Wilson2015-03-20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
| * | | | | | | drm/i915: Improved w/a for rps on BaytrailChris Wilson2015-03-20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
| * | | | | | | drm/i915: Relax RPS contraints to allows setting minfreq on idleChris Wilson2015-03-20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
| * | | | | | | drm/i915: Fallback to using CPU relocations for large batch buffersChris Wilson2015-03-20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
| * | | | | | | drm/i915: Turn on PIN_GLOBAL in i915_gem_object_ggtt_pinTvrtko Ursulin2015-03-20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
| * | | | | | | drm/i915: memory leak in __i915_gem_vma_create()Dan Carpenter2015-03-20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
| * | | | | | | drm/i915/dp: return number of bytes written for short aux/i2c writesJani Nikula2015-03-20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
| * | | | | | | drm/i915: Unconfuse DP link rate array namesVille Syrjälä2015-03-20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
| * | | | | | | drm/i915: Include the sink/source/supported rates in debug outputVille Syrjälä2015-03-20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
| * | | | | | | drm/i915: Add eDP intermediate frequencies for CHVVille Syrjälä2015-03-20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | "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>
| * | | | | | | drm/i915: Avoid overflowing the DP link rate arraysVille Syrjälä2015-03-20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
| * | | | | | | drm/i915: Fix MST link rate handlingVille Syrjälä2015-03-20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
| * | | | | | | drm/i915: Use DP_LINK_RATE_SET whenever possibleVille Syrjälä2015-03-20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
| * | | | | | | drm/i915: Fix max link rate in intel_dp_mode_valid()Ville Syrjälä2015-03-20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
| * | | | | | | drm/i915: Hide the source vs. sink rate handling from intel_dp_compute_config()Ville Syrjälä2015-03-20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
| * | | | | | | drm/i915: Fully separate source vs. sink ratesVille Syrjälä2015-03-20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
| * | | | | | | drm/i915: Remove special case from intel_supported_rates()Ville Syrjälä2015-03-20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
| * | | | | | | drm/i915: Don't copy sink rates eitherVille Syrjälä2015-03-20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
| * | | | | | | drm/i915: Don't copy the DP source rates arraysVille Syrjälä2015-03-20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
| * | | | | | | drm/i915: Store the converted link rates in intel_dp->supported_rates[]Ville Syrjälä2015-03-20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
| * | | | | | | drm/i915: Make the DP rates int instead of uint32_tVille Syrjälä2015-03-20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
| * | | | | | | drm/i915: Do not use ggtt_view with (aliasing) PPGTTJoonas Lahtinen2015-03-20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
| * | | | | | | drm/i915: Fix sink crc connector iterationRodrigo Vivi2015-03-20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* | | | | | | | Merge branch 'drm-atmel-hlcdc-4.1-fixes' of ↵Dave Airlie2015-03-30
|\ \ \ \ \ \ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://github.com/bbrezillon/linux-at91 into drm-next add PM fix. * 'drm-atmel-hlcdc-4.1-fixes' of git://github.com/bbrezillon/linux-at91: drm: atmel-hlcdc: use appropriate enabled flag in suspend/resume
| * | | | | | | | drm: atmel-hlcdc: use appropriate enabled flag in suspend/resumeSylvain Rochet2015-03-16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Unfortunately we used the enabled flag in struct drm_crtc instead of the enabled flag in struct atmel_hlcdc_crtc. This obviously leads to discrepancies on crtc enable state. This patch fixes the issue by using the struct atmel_hlcdc_crtc enabled flag in PM support. Signed-off-by: Sylvain Rochet <sylvain.rochet@finsecur.com> Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>
* | | | | | | | | Merge tag 'drm-amdkfd-next-2015-03-25' of ↵Dave Airlie2015-03-30
|\ \ \ \ \ \ \ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://people.freedesktop.org/~gabbayo/linux into drm-next - Allow amdkfd to work with multiple kgd instances. This is in preparation for AMD's new open source kernel graphic driver (amdgpu), and for the new AMD APU, Carrizo. - Convert timestamping to use 64bit time accessors - Three other minor changes. * tag 'drm-amdkfd-next-2015-03-25' of git://people.freedesktop.org/~gabbayo/linux: drm/amdkfd: Add multiple kgd support drm/amdkfd: Convert timestamping to use 64bit time accessors drm/amdkfd: add debug prints for process teardown drm/amdkfd: Remove unused field from struct qcm_process_device drm/amdkfd: rename fence_wait_timeout
| * | | | | | | | | drm/amdkfd: Add multiple kgd supportXihan Zhang2015-03-25
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The current code can only support one kgd instance. We have to support multiple kgd instances in one system. i.e two amdgpu or two radeon or one amdgpu + one radeon or more than two kgd instances. Signed-off-by: Xihan Zhang <xihan.zhang@amd.com> Signed-off-by: Oded Gabbay <oded.gabbay@amd.com>
| * | | | | | | | | drm/amdkfd: Convert timestamping to use 64bit time accessorsJohn Stultz2015-03-25
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Convert the timestamping in the amdkfd driver to use a timespec64 and 64bit time accessors. Although the existing code is completely safe beyond y2038 because it deals with monotonic time, this patch is still needed in order to kill off all uses of struct timespec. Signed-off-by: John Stultz <john.stultz@linaro.org> Signed-off-by: Oded Gabbay <oded.gabbay@amd.com>
| * | | | | | | | | drm/amdkfd: add debug prints for process teardownOded Gabbay2015-03-25
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Signed-off-by: Oded Gabbay <oded.gabbay@amd.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
| * | | | | | | | | drm/amdkfd: Remove unused field from struct qcm_process_deviceOded Gabbay2015-03-25
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Signed-off-by: Oded Gabbay <oded.gabbay@amd.com> Reviewed-by: Ben Goz <ben.goz@amd.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
| * | | | | | | | | drm/amdkfd: rename fence_wait_timeoutOded Gabbay2015-03-25
| | |_|_|_|/ / / / | |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | fence_wait_timeout() is an exported kernel symbol, so we should rename our local function to something different. Signed-off-by: Oded Gabbay <oded.gabbay@amd.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
* | | | | | | | | Merge branch 'drm-st-next-2015-03-19' of ↵Dave Airlie2015-03-26
|\ \ \ \ \ \ \ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.linaro.org/people/benjamin.gaignard/kernel into drm-next This patch makes STI driver use the atomic helpers. I have fix the comments done by Daniel on the first version and get his ack with this second version. * 'drm-st-next-2015-03-19' of git://git.linaro.org/people/benjamin.gaignard/kernel: drm: sti: convert driver to atomic modeset
| * | | | | | | | | drm: sti: convert driver to atomic modesetBenjamin Gaignard2015-03-19
| | |/ / / / / / / | |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | v1: This patch does the minimum to make sti driver use atomic helpers. No big bang, only adapt some functions to new call order. v2: Use dpms and page flip atomic helpers Signed-off-by: Benjamin Gaignard <benjamin.gaignard@linaro.org>
* | | | | | | | | Merge tag 'drm-intel-next-2015-03-13-merge' of ↵Dave Airlie2015-03-23
|\ \ \ \ \ \ \ \ \ | |_|/ / / / / / / |/| | / / / / / / | | |/ / / / / / | |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://anongit.freedesktop.org/drm-intel into drm-next drm-intel-next-2015-03-13-rebased: - EU count report param for gen9+ (Jeff McGee) - piles of pll/wm/... fixes for chv, finally out of preliminary hw support (Ville, Vijay) - gen9 rps support from Akash - more work to move towards atomic from Matt, Ander and others - runtime pm support for skl (Damien) - edp1.4 intermediate link clock support (Sonika) - use frontbuffer tracking for fbc (Paulo) - remove ilk rc6 (John Harrison) - a bunch of smaller things and fixes all over Includes backmerge because git rerere couldn't keep up any more. * tag 'drm-intel-next-2015-03-13-merge' of git://anongit.freedesktop.org/drm-intel: (366 commits) drm/i915: Make sure the primary plane is enabled before reading out the fb state drm/i915: Update DRIVER_DATE to 20150313 drm/i915: Fix vmap_batch page iterator overrun drm/i915: Export total subslice and EU counts drm/i915: redefine WARN_ON_ONCE to include the condition drm/i915/skl: Implement WaDisableHBR2 drm/i915: Remove the preliminary_hw_support shackles from CHV drm/i915: Read CHV_PLL_DW8 from the correct offset drm/i915: Rewrite IVB FDI bifurcation conflict checks drm/i915: Rewrite some some of the FDI lane checks drm/i915/skl: Enable the RPS interrupts programming drm/i915/skl: Enabling processing of Turbo interrupts drm/i915/skl: Updated the i915_frequency_info debugfs function drm/i915: Simplify the way BC bifurcation state consistency is kept drm/i915/skl: Updated the act_freq_mhz_show sysfs function drm/i915/skl: Updated the gen9_enable_rps function drm/i915/skl: Updated the gen6_rps_limits function drm/i915/skl: Restructured the gen6_set_rps_thresholds function drm/i915/skl: Updated the gen6_set_rps function drm/i915/skl: Updated the gen6_init_rps_frequencies function ...
| * | | | | | | Merge tag 'drm-intel-fixes-2015-03-19' into drm-intel-nextDaniel Vetter2015-03-20
| |\ \ \ \ \ \ \ | | | |_|/ / / / | | |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
| | * | | | | | drm/i915: Make sure the primary plane is enabled before reading out the fb stateDamien Lespiau2015-03-18
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
| | * | | | | | drm/i915: Ensure plane->state->fb stays in sync with plane->fbXi Ruoyao2015-03-16
| | | |/ / / / | | |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | plane->state->fb and plane->fb should always reference the same FB so that atomic and legacy codepaths have the same view of display state. However, there are some places in kernel code that directly set plane->fb and neglect to update plane->state->fb. If we never do a successful update through the atomic pipeline, the RmFB cleanup code will look at the plane->state->fb pointer, which has never actually been set to a legitimate value, and try to clean it up, leading to BUG's. Add a quick helper function to synchronize plane->state->fb with plane->fb and call it everywhere the driver tries to manually set plane->fb outside of the atomic pipeline. In this function, use drm_atomic_set_fb_for_plane instead of writing plane->state->fb directly to keep the reference count right. This is modified from Matt Roper's patch to drm-intel-nightly with commit id commit afd65eb4cc0578a9c07d621acdb8a570e2782bf7 Author: Matt Roper <matthew.d.roper@intel.com> Date: Tue Feb 3 13:10:04 2015 -0800 drm/i915: Ensure plane->state->fb stays in sync with plane->fb However this bug exists in mainline kernel too, so I created this to fix it in mainline kernel. A minor change is to use drm_atomic_set_fb_for_plane instead of update reference count manually. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=88909 Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=93711 Signed-off-by: Xi Ruoyao <xry111@outlook.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> [Jani: included the patch notes in the commit message] Signed-off-by: Jani Nikula <jani.nikula@intel.com>
| | * | | | | [PATCH] drm/mm: Fix support 4 GiB and larger rangesKrzysztof Kolasa2015-03-15
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | bad argument if(tmp)... in check_free_hole fix oops: kernel BUG at drivers/gpu/drm/drm_mm.c:305! [airlied: excellent, this was my task for today]. Signed-off-by: Krzysztof Kolasa <kkolasa@winsoft.pl> Reviewed-by: Chris wilson <chris@chris-wilson.co.uk> Signed-off-by: Dave Airlie <airlied@redhat.com>
| | * | | | | Merge branch 'drm-fixes-4.0' of git://people.freedesktop.org/~agd5f/linux ↵Dave Airlie2015-03-12
| | |\ \ \ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | into drm-fixes Some additional radeon fixes for 4.0 * 'drm-fixes-4.0' of git://people.freedesktop.org/~agd5f/linux: drm/radeon: drop setting UPLL to sleep mode drm/radeon: fix wait to actually occur after the signaling callback
| | | * | | | | drm/radeon: drop setting UPLL to sleep modeChristian König2015-03-11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Just keep it working, seems to fix some PLL problems. Bug: https://bugs.freedesktop.org/show_bug.cgi?id=73378 Signed-off-by: Christian König <christian.koenig@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org
| | | * | | | | drm/radeon: fix wait to actually occur after the signaling callbackMaarten Lankhorst2015-03-11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | A normal wait adds to the front of the tail. By doing something similar to fence_default_wait the fence code can run without racing. This is a complete fix for "panic on suspend from KDE with radeon", and a partial fix for "Radeon: System pauses on TAHITI". On tahiti si_irq_set needs to be fixed too, to completely flush the writes before radeon_fence_activity is called in radeon_fence_enable_signaling. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=90741 Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=90861 Signed-off-by: Maarten Lankhorst <maarten.lankhorst@ubuntu.com> Reported-by: Jon Arne Jørgensen <jonjon.arnearne@gmail.com> Reported-and-tested-by: Gustaw Smolarczyk <wielkiegie@gmail.com> Cc: stable@vger.kernel.org (v3.18+) Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
| | * | | | | | Merge branch 'vmwgfx-fixes-4.0' of ↵Dave Airlie2015-03-12
| | |\ \ \ \ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://people.freedesktop.org/~thomash/linux into drm-fixes A couple of fixes for vmwgfx. * 'vmwgfx-fixes-4.0' of git://people.freedesktop.org/~thomash/linux: drm/vmwgfx: Fix an issue with the device losing its irq line on module unload drm/vmwgfx: Correctly NULLify dma buffer pointer on failure drm/vmwgfx: Reorder device takedown somewhat drm/vmwgfx: Fix a couple of lock dependency violations
| | | * | | | | | drm/vmwgfx: Fix an issue with the device losing its irq line on module unloadThomas Hellstrom2015-03-11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Starting with commit b4b55cda5874 ("x86/PCI: Refine the way to release PCI IRQ resources") the device lost its irq resource on module unload. While that's ok and apparently intentional, the driver never got the resource back on module load The code apparently wants drivers to disable the pci device at pci device driver removal, so lets do that. That fixes the issue. Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com> Reviewed-by: Brian Paul <brianp@vmware.com>
| | | * | | | | | drm/vmwgfx: Correctly NULLify dma buffer pointer on failureColin Ian King2015-03-11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | cppcheck on lines 917 and 977 show an ineffective assignment to the dma buffer pointer: [drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c:917]: [drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c:977]: (warning) Assignment of function parameter has no effect outside the function. Did you forget dereferencing it? On a successful DMA buffer lookup, the dma buffer pointer is assigned, however, on failure it currently is left in an undefined state. The original intention in the error exit path was to nullify the pointer on an error (which the original code failed to do properly). This patch fixes this also ensures all failure paths nullify the buffer pointer on the error return. Fortunately the callers to vmw_translate_mob_ptr and vmw_translate_guest_ptr are checking on a return status and not on the dma buffer pointer, so the original code worked. Reviewed-by: Thomas Hellstrom <thellstrom@vmware.com> Signed-off-by: Colin Ian King <colin.king@canonical.com>
| | | * | | | | | drm/vmwgfx: Reorder device takedown somewhatThomas Hellstrom2015-03-11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | To take down the MOB and GMR memory types, the driver may have to issue fence objects and thus make sure that the fence manager is taken down after those memory types. Reorder device init accordingly. Cc: <stable@vger.kernel.org> Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com> Reviewed-by: Sinclair Yeh <syeh@vmware.com>
| | | * | | | | | drm/vmwgfx: Fix a couple of lock dependency violationsThomas Hellstrom2015-03-11
| | | |/ / / / / | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Experimental lockdep annotation added to the TTM lock has unveiled a couple of lock dependency violations in the vmwgfx driver. In both cases it turns out that the device_private::reservation_sem is not needed so the offending code is moved out of that lock. Cc: <stable@vger.kernel.org> Acked-by: Sinclair Yeh <syeh@vmware.com> Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
generated by cgit v1.2.2 (git 2.25.0) at 2025-04-20 03:51:50 -0400