- 23 Dec, 2016 3 commits
-
-
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:
Ville Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20161222195222.9618-1-ville.syrjala@linux.intel.comReviewed-by:
Chris Wilson <chris@chris-wilson.co.uk>
-
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:
Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/1482184508-18346-1-git-send-email-rodrigo.vivi@intel.com
-
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:
Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
-
- 18 Dec, 2016 7 commits
-
-
Chris Wilson authored
A fairly trivial move of a matching pair of routines (for preparing a request for construction) onto an engine vfunc. The ulterior motive is to be able to create a mock request implementation. Signed-off-by:
-
Chris Wilson authored
PIN_HIGH is an expensive operation (in comparison to allocating from the hole stack) unsuitable for frequent use (such as switching between contexts). However, the kernel context should be pinned just once for the lifetime of the driver, and here it is appropriate to keep it out of the mappable range (in order to maximise mappable space for users). Signed-off-by:
-
Chris Wilson authored
As the shadow gvt is not user accessible and does not have an associated vm, we can mark it as closed during its construction. This saves leaking the internal knowledge of i915_gem_context into gvt/. Signed-off-by:
-
Chris Wilson authored
A few users only take the struct_mutex in order to release a reference to a context. We can expose a kref_put_mutex() wrapper in order to simplify these users, and optimise taking of the mutex to the final unref. Signed-off-by:
-
Chris Wilson authored
The requests conversion introduced a nasty bug where we could generate a new request in the middle of constructing a request if we needed to idle the system in order to evict space for a context. The request to idle would be executed (and waited upon) before the current one, creating a minor havoc in the seqno accounting, as we will consider the current request to already be completed (prior to deferred seqno assignment) but ring->last_retired_head would have been updated and still could allow us to overwrite the current request before execution. We also employed two different mechanisms to track the active context until it was switched out. The legacy method allowed for waiting upon an active context (it could forcibly evict any vma, including context's), but the execlists method took a step backwards by pinning the vma for the entire active lifespan of the context (the only way to evict was to idle the entire GPU, not individual contexts). However, to circumvent the tricky issue of locking (i.e. we cannot take struct_mutex at the time of i915_gem_request_submit(), where we would want to move the previous context onto the active tracker and unpin it), we take the execlists approach and keep the contexts pinned until retirement. The benefit of the execlists approach, more important for execlists than legacy, was the reduction in work in pinning the context for each request - as the context was kept pinned until idle, it could short circuit the pinning for all active contexts. We introduce new engine vfuncs to pin and unpin the context respectively. The context is pinned at the start of the request, and only unpinned when the following request is retired (this ensures that the context is idle and coherent in main memory before we unpin it). We move the engine->last_context tracking into the retirement itself (rather than during request submission) in order to allow the submission to be reordered or unwound without undue difficultly. And finally an ulterior motive for unifying context handling was to prepare for mock requests. v2: Rename to last_retired_context, split out legacy_context tracking for MI_SET_CONTEXT. Signed-off-by:
-
Chris Wilson authored
Just a simple move to avoid a forward declaration, though the diff likes to present itself as a move of intel_logical_ring_alloc_request_extras() in the opposite direction. Signed-off-by:
-
Chris Wilson authored
i915_vma_move_to_active() requires the struct_mutex for serialisation with retirement, so mark it up with lockdep_assert_held(). Signed-off-by:
-
- 16 Dec, 2016 3 commits
-
-
Matthew Auld authored
Convert some of the obvious hand-rolled ranged overflow sanity checks to our shiny new range_overflows macro. Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Suggested-by:
Matthew Auld <matthew.auld@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20161213203222.32564-4-matthew.auld@intel.comReviewed-by:
-
Matthew Auld authored
In a number places we hand-roll the overflow sanity check for ranges, so roll that into single macro, conceived by Chris, along with its typed variant. Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Suggested-by:
-
Matthew Auld authored
If we move the sanity checking from gen8_alloc_va_range_3lvl and gen6_alloc_va_range into i915_vma_bind, we will increase our coverage to now both callbacks. We also convert each WARN_ON over to a GEM_WARN_ON. Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Suggested-by:
-
