- 28 Dec, 2016 1 commit
-
-
Chris Wilson authored
Add an assertion to the plain i915_ggtt_offset() to double check that any offset we hand to the GuC is outside of its unmappable ranges. Signed-off-by:
Chris Wilson <chris@chris-wilson.co.uk> Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20161224193146.4402-1-chris@chris-wilson.co.ukReviewed-by:
Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
-
- 26 Dec, 2016 1 commit
-
-
Daniel Vetter authored
Signed-off-by:Daniel Vetter <daniel.vetter@ffwll.ch>
-
- 24 Dec, 2016 2 commits
-
-
Daniele Ceraolo Spurio authored
The context has to obey the same offset requirements as the ring, so we can re-use the same bias value we computed for the ring instead of unconditionally using GUC_WOPCM_TOP. Suggested-by:
-
Daniele Ceraolo Spurio authored
GuC will validate the ring offset and fail if it is in the [0, GUC_WOPCM_TOP) range. The bias is conditionally applied only if GuC loading is enabled (we can't check for guc submission enabled as in other cases because HuC loading requires this fix). Note that the default context is processed before enable_guc_loading is sanitized, so we might still apply the bias to its ring even if it is not needed. v2: compute the value during ctx init and pass it to intel_ring_pin (Chris), updated commit message Signed-off-by:
-
- 23 Dec, 2016 9 commits
-
-
Chris Wilson authored
As the fence may be signaled concurrently from an interrupt on another device, it is possible for the list of requests on the timeline to be modified as we walk it. Take both (the context's timeline and the global timeline) locks to prevent such modifications. Fixes: 80b204bc ("drm/i915: Enable multiple timelines") Signed-off-by:
Mika Kuoppala <mika.kuoppala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20161223145804.6605-10-chris@chris-wilson.co.uk
-
Chris Wilson authored
When creating a partial VMA assert that it first fits with the parent object, and that if it covers the whole of the parent a normal view was created instead. Signed-off-by:
Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20161223145804.6605-5-chris@chris-wilson.co.uk
-
Chris Wilson authored
As trimming the sg table is merely an optimisation that gracefully fails if we cannot allocate a new table, we do not need to report the failure either. Fixes: 0c40ce13 ("drm/i915: Trim the object sg table") Signed-off-by:
-
Chris Wilson authored
When we teardown the backing storage for the phys object, we copy from the coherent contiguous block back to the shmemfs object, clflushing as we go. Trying to clflush the invalid sg beforehand just oops and would be redundant (due to it already being coherent, and clflushed afterwards). Reported-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by:
-
Chris Wilson authored
The idle work handler is self-arming - if it detects that it needs to run again it will queue itself from its work handler. Take greater care when trying to drain the idle work, and double check that it is flushed. The free worker has a similar issue where it is armed by an RCU task which may be running concurrently with us. This should hopefully help with the sporadic WARN_ON(dev_priv->gt.awake) from i915_gem_suspend. v2: Reuse drain_freed_objects. v3: Don't try to flush the freed objects from the shrinker, as it may be underneath the struct_mutex already. v4: do while and comment upon the excess rcu_barrier in drain_freed_objects Signed-off-by:
-
Chris Wilson authored
Since commit db6c2b41 ("drm/i915: Store the vma in an rbtree under the object") the vma are once again sorted into GGTT first, then ppGTT so that the typical case of walking the GGTT vma can stop as soon as we find a non-ppGTT. Apply that optimisation. Signed-off-by:
-
Ville Syrjälä authored
Now that we're disabling L2 clock gating MI_OVERLAY_OFF actually works on 830, so let's use it. v2: Nuke the unused dev_priv variable Signed-off-by:
-
Hans de Goede authored
On enable intel_dsi_enable() directly calls intel_enable_dsi_pll(), make intel_dsi_disable() also directly call intel_disable_dsi_pll(), rather then hiding the call in intel_dsi_clear_device_ready(), no functional changes. Signed-off-by:
Hans de Goede <hdegoede@redhat.com> Reviewed-by:
Jani Nikula <jani.nikula@intel.com> Signed-off-by:
-
Vincente Tsou authored
The upper bits of the vsync width, vsync offset and hsync width were not parsed from the VBT. Parse these fields in this patch. V2: Renamed lvds dvo timing structure members and code identation fix (Jani's review comments) V3: Corrected commit message, used "from the VBT" Signed-off-by:
Vincente Tsou <vincente.tsou@intel.com> Signed-off-by:
Madhav Chauhan <madhav.chauhan@intel.com> Reviewed-by:
-
- 22 Dec, 2016 14 commits
-
-
Ville Syrjälä authored
BSpec says: "Overlay Clock Gating Must be Disabled: Overlay & L2 Cache clock gating must be disabled in order to prevent device hangs when turning off overlay.SW must turn off Ovrunit clock gating (6200h) and L2 Cache clock gating (C8h)." We only turned off the overlay clock gating (due to lack of docs I presume). After a bit of experimentation it looks like the the magic C8h register lives in the PCI config space of device 0, and the magic bit appears to be bit 2. Or at the very least this eliminates the GPU death after MI_OVERLAY_OFF. L2 clock gating seems to save ~80mW, so let's keep it on unless we need to actually use the overlay. Also let's move the OVRUNIT clock gating to the same place since we can, and 845 supposedly doesn't need it. Signed-off-by:
-
Ville Syrjälä authored
Extract the primary plane pixel format via plane state when setting up the overlay colorkey. Signed-off-by:
-
Ville Syrjälä authored
Use two-dimensional arrays and named initializers to make the overlay filter coefficient tables easier to parse for humans. Signed-off-by:
-
Ville Syrjälä authored
The formula in Bspec for computing the overlay SWIDTHSW is overly obfuscated. Simplify the formula to something that's easily parsed by humans. Signed-off-by:
-
Ville Syrjälä authored
Check pipe config gmch_pfit.control instead of using intel_panel_fitter_pipe() to figure out if the pipe for the overlay is using the panel fitter. Signed-off-by:
-
Ville Syrjälä authored
Replace the use of crtc->mode.h/vdisplay with the more appropriate config->pipe_src_w/h. Signed-off-by:
-
Ville Syrjälä authored
Do the overlay frontbuffer tracking properly so that it matches the state of the overlay on/off/continue requests. One slight problem is that intel_frontbuffer_flip_complete() may get delayed by an arbitrarily liong time due to the fact that the overlay code likes to bail out when a signal occurs. So the flip may not get completed until the ioctl is restarted. But fixing that would require bigger surgery, so I decided to ignore it for now. Signed-off-by:
-
Ville Syrjälä authored
The vma will be NULL if the overlay was previously off, so dereferencing it will oops. Check for NULL before doing that. Cc: stable@vger.kernel.org Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Fixes: 9b3b7841 ("drm/i915/overlay: Use VMA as the primary tracker for images") Signed-off-by:
-
Ville Syrjälä authored
The i915_gem_active stuff doesn't like a NULL ->retire hook, but the overlay code can set it to NULL. That obviously ends up oopsing. Fix it by introducing a new helper to assign the retirement callback that will switch out the NULL function pointer with i915_gem_retire_noop. Cc: stable@vger.kernel.org Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Fixes: 0d9bdd88 ("drm/i915: Convert intel_overlay to request tracking") Signed-off-by:
-
Ville Syrjälä authored
Initialize overlay->last_flip properly instead of leaving it zeroed. Cc: stable@vger.kernel.org Cc: Chris Wilson <chris@chris-wilson.co.uk> Fixes: 0d9bdd88 ("drm/i915: Convert intel_overlay to request tracking") Reviewed-by:
-
Ville Syrjälä authored
Trying to determine the pixel rate of the pipe can't be done until we know the clock, which means it can't be done until the encoder .get_config() hooks have been called. So let's move the min_pixclk[] stuff to the end of intel_modeset_readout_hw_state() when we actually have gathered all the required infromation. Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Mika Kahola <mika.kahola@intel.com> Cc: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com> Fixes: 565602d7 ("drm/i915: Do not acquire crtc state to check clock during modeset, v4.") Signed-off-by:
Ander Conselvan de Oliveira <conselvan2@gmail.com> Reviewed-by:
Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
-
Ville Syrjälä authored
Apparently some VLV BIOSen like to leave the VDD force bit enabled even for power seqeuncers that aren't properly hooked up to any port. That will result in a imbalance in the AUX power domain refcount when we stat to use said power sequencer as edp_panel_vdd_on() will not grab the power domain reference if it sees that the VDD is already on. To fix this let's make sure we turn off the VDD force bit when we initialize the power sequencer registers. That is, unless it's being done from the init path since there we are actually initializing the registers for the current power sequencer and we don't want to turn VDD off needlessly as that would require waiting for the power cycle delay before we turn it back on. This fixes the following kind of warnings: WARNING: CPU: 0 PID: 123 at ../drivers/gpu/drm/i915/intel_runtime_pm.c:1455 intel_display_power_put+0x13a/0x170 [i915]() WARN_ON(!power_domains->domain_use_count[domain]) ... v2: Fix typos in comment (David) Cc: stable@vger.kernel.org Cc: Matwey V. Kornilov <matwey.kornilov@gmail.com> Tested-by:
Matwey V. Kornilov <matwey.kornilov@gmail.com> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=98695Signed-off-by:
David Weinehall <david.weinehall@linux.intel.com>
-
Imre Deak authored
There is at least one APL based system using port A in DP mode (connecting to an on-board DP->VGA adaptor). Atm we'll configure port A unconditionally as eDP which is incorrect in this case. Fix this by relying on the VBT DDI port 'internal port' flag instead on all ports on DDI platforms. For now chicken out from using VBT for port A before GEN9. v2: - Move the DDI port info lookup to intel_bios_is_port_edp() (David, Jani) - Use the DDI port info on all DDI platforms starting from port B. Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Jani Nikula <jani.nikula@intel.com> Cc: David Weinehall <david.weinehall@linux.intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> (v1) Reviewed-by:
Imre Deak <imre.deak@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1482315444-24750-1-git-send-email-imre.deak@intel.com
-
Elaine Wang authored
when num_pipes is zero, it indicates there is no display and HDMI audio doesn't exist. v2: Move the check from caller to callee for consistency. Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Jani Nikula <jani.nikula@linux.intel.com> Signed-off-by:
Elaine Wang <elaine.wang@intel.com> Reviewed-by:
-
- 21 Dec, 2016 1 commit
-
-
Deepak M authored
v2: Addressed Jani's Review comments (renamed bit field macros) Signed-off-by:
Deepak M <m.deepak@intel.com> Signed-off-by:
-
- 20 Dec, 2016 7 commits
-
-
Rodrigo Vivi authored
This macro got useless after commit 8d9c20e1 "drm/i915: Remove .is_mobile field from platform struct" that removed is_mobile split from VLV definition. Also this was never reused on any following platform. So let's clean up a bit here. Cc: Carlos Santa <carlos.santa@intel.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by:
Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by:
-
Paulo Zanoni authored
Don't even tell the mm allocator to handle the first page of stolen on the affected platforms. This means that we won't inherit the FB in case the BIOS decides to put it at the start of stolen. But the BIOS should not be putting it at the start of stolen since it's going to get corrupted. I suppose the bug here is that some pixels at the very top of the screen will be corrupted, so it's not exactly easy to notice. We have confirmation that the first page of stolen does actually get corrupted, so I really think we should do this in order to avoid any possible future headaches, even if that means losing BIOS framebuffer inheritance. Let's not use the HW in a way it's not supposed to be used. Notice that now ggtt->stolen_usable_size won't reflect the ending address of the stolen usable range anymore, so we have to fix the places that rely on this. To simplify, we'll just use U64_MAX. v2: don't even put the first page on the mm (Chris) v3: drm_mm_init() takes size instead of end as argument (Ville) v4: add a comment explaining the reserved ranges (Chris) use 0 for start and U64_MAX for end when possible (Chris) Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=94605 Cc: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by:Paulo Zanoni <paulo.r.zanoni@intel.com> Reviewed-by:
-
Paulo Zanoni authored
BSpec got updated and this workaround is now listed as standard required programming for all subsequent projects. This is confirmed to fix Skylake screen flickering issues (probably caused by the fact that we initialized a ring in the first page of stolen, but I didn't 100% confirm this theory). v2: this is the patch that fixes the screen flickering, document it. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=94605 Cc: stable@vger.kernel.org Tested-by:
Dominik Klementowski <dominik232@gmail.com> Signed-off-by:
-
Chris Wilson authored
In commit 0c40ce13 ("drm/i915: Trim the object sg table"), we expect to copy exactly orig_st->nents across and allocate the table thusly. The copy loop should therefore end with the new_sg being NULL. Signed-off-by:
Tvrtko Ursulin <tvrtko.ursulin@intel.com>
-
Chris Wilson authored
If we at first do not succeed with attempting to remap our physical pages using a coalesced scattergather list, try again with one scattergather entry per page. This should help with swiotlb as it uses a limited buffer size and only searches for contiguous chunks within its buffer aligned up to the next boundary - i.e. we may prematurely cause a failure as we are unable to utilize the unused space between large chunks and trigger an error such as: i915 0000:00:02.0: swiotlb buffer is full (sz: 1630208 bytes) Reported-by:
Juergen Gross <jgross@suse.com> Tested-by:
-
Chris Wilson authored
In keeping with commit f802cf7e ("drm/i915/debugfs: use rb_entry()"), convert the primary user of the rbtrees over to using rb_entry rather than the equivalent container_of. Signed-off-by:
-
Geliang Tang authored
To make the code clearer, use rb_entry() instead of container_of() to deal with rbtree. Signed-off-by:
Geliang Tang <geliangtang@gmail.com> Signed-off-by:
-
- 19 Dec, 2016 5 commits
-
-
Rodrigo Vivi authored
Let's take usage of IS_LP to simplify the gem stolen initialization as suggest by Tvrtko. Also assume that all new LP platforms follows the chv+ and others bdw+. v2: Remove the wrong commit message about bxt and glk. (Ander) Cc: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com> Cc: Imre Deak <imre.deak@intel.com> Cc: Mika Kuoppala <mika.kuoppala@intel.com> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Signed-off-by:
-
Rodrigo Vivi authored
gen8 is used for both Broadwell and Cherryview but this function here is only Cherryview and all next atom LP platforms. So let's rename it to avoid confusion as suggested by Ville. Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by:
-
Rodrigo Vivi authored
Valleyview/Baytrail (gen7_lp) and Cherryview/Braswell (gen8_lp) are both Atom platforms like Broxton/Apollolake and Geminilake. So let's expand this is_lp back to these platforms and create the IS_LP(dev_priv) so we can start simplifying a bit our if/else for platform lists. Signed-off-by:
-
Ville Syrjälä authored
VLV apparently gets upset if the PPS for a pipe currently driving an external DP port gets used for VDD stuff on another eDP port. The DP port falls over and fails to retrain when this happens, leaving the user staring at a black screen. Let's fix it by also tracking which pipe is driving which DP/eDP port. We'll track this under intel_dp so that we'll share the protection of the pps_mutex alongside the pps_pipe tracking, since the two things are intimately related. I had plans to reduce the protection of pps_mutex to cover only eDP ports, but with this we can't do that. Well, for for VLV/CHV at least. For other platforms it should still be possible, which would allow AUX communication to occur in parallel for multiple DP ports. v2: Drop stray crap from a comment (Imre) Grab pps_mutex when clearing active_pipe Fix a typo in the commit message v3: Make vlv_active_pipe() static Cc: stable@vger.kernel.org Signed-off-by: -
Chris Wilson authored
The kref_put_mutex() returns with the mutex held after freeing the object - so we must remember to drop it... Fixes: 69df05e1 ("drm/i915: Simplify releasing context reference") Signed-off-by:
-
