- 19 Dec, 2016 4 commits
-
-
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 <rodrigo.vivi@intel.com> Reviewed-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by:
Ander Conselvan de Oliveira <conselvan2@gmail.com> Link: http://patchwork.freedesktop.org/patch/msgid/1482096988-400-2-git-send-email-rodrigo.vivi@intel.com
-
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:Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by:
Imre Deak <imre.deak@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1481738423-29738-1-git-send-email-ville.syrjala@linux.intel.com
-
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:
Chris Wilson <chris@chris-wilson.co.uk> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20161219101357.28140-1-chris@chris-wilson.co.ukReviewed-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:
Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20161218153724.8439-7-chris@chris-wilson.co.uk
-
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 8 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:
-
Matthew Auld authored
In a similar spirit to GEM_BUG_ON we now also have GEM_WARN_ON, with the simple goal of expressing warnings which are truly insane, and so are only really useful for CI where we have some abusive tests. v2: - use BUILD_BUG_ON_INVALID for !DEBUG_GEM - clarify commit message Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Suggested-by:
-
Tvrtko Ursulin authored
Commit 3b3f1650 ("drm/i915: Allocate intel_engine_cs structure only for the enabled engines") introduced the dynanically allocated engine instances and created an potential use after free scenario in logical_render_ring_init where lrc_destroy_wa_ctx_obj could be called after the engine instance has been freed. This can only happen during engine setup/init error handling which luckily does not happen ever in practice. Fix is to not call lrc_destroy_wa_ctx_obj since it would have already been executed from the preceding engine cleanup. Signed-off-by:
Dan Carpenter <dan.carpenter@oracle.com> Fixes: 3b3f1650 ("drm/i915: Allocate intel_engine_cs structure only for the enabled engines") Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: Daniel Vetter <daniel.vetter@intel.com> Cc: Jani Nikula <jani.nikula@linux.intel.com> Reviewed-by:
-
Nicholas Mc Guire authored
udelay_range(1, 2) is inefficient and as discussions with Jani Nikula <jani.nikula@linux.intel.com> unnecessary here. This replaces this tight setting with a relaxed delay of min=20 and max=50 which helps the hrtimer subsystem optimize timer handling. Fixes: commit be4fc046 ("drm/i915: add VLV DSI PLL Calculations") Link: http://lkml.org/lkml/2016/12/15/147Signed-off-by:
Nicholas Mc Guire <hofrat@osadl.org> Reviewed-by:
Jani Nikula <jani.nikula@intel.com> Signed-off-by:
-
Nicholas Mc Guire authored
udelay_range(2, 3) is inefficient and as discussions with Jani Nikula <jani.nikula@linux.intel.com> unnecessary here. This replaces this tight setting with a relaxed delay of min=20 and max=50. which helps the hrtimer subsystem optimize timer handling. Link: http://lkml.org/lkml/2016/12/15/127 Fixes: commit 37ab0810 ("drm/i915/bxt: DSI enable for BXT") Signed-off-by:
-
Michal Wajdeczko authored
We usually use 'client' as identifier for the i915_guc_client. For unknown reason, few functions were using 'gc' name. Signed-off-by:
Michal Wajdeczko <michal.wajdeczko@intel.com> Reviewed-by:
-
- 15 Dec, 2016 1 commit
-
-
Tvrtko Ursulin authored
Cast VM pointers before substraction to save the compiler doing a smart one which includes multiplication. v2: Only keep the first optimisation and prettify it. (Chris Wilson) Signed-off-by:
-
- 14 Dec, 2016 3 commits
-
-
Paulo Zanoni authored
We've been ignoring the poor bugzilla reporters that say PSR causes system lockups and all other sorts of problems. The earliest bug report is from April, so I think we can use the "revert the offending commit if no fixes are presented within 8 months" rule here. Fixes: 9b58e352 ("drm/i915: Enable PSR by default on Haswell and Broadwell.") Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=97602 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=97515 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=96736 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=96704 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=96569 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=95176 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=94985 Cc: <stable@vger.kernel.org> # v4.6+ Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Jim Bride <jim.bride@linux.intel.com> Signed-off-by:
Paulo Zanoni <paulo.r.zanoni@intel.com> Acked-by:
-
Mika Kuoppala authored
For limiting the max frequency of gpu, the max freq tunable is not enough to hard limit the max gap. We now have also per client boost max freq. When this tunable was introduced, it was mistakenly made read only. Allow user to gain control by setting it writable. Fixes: 29ecd78d ("drm/i915: Define a separate variable and control for RPS waitboost frequency") Cc: <stable@vger.kernel.org> # v4.9+ Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Mika Kuoppala <mika.kuoppala@intel.com> Cc: Daniel Vetter <daniel.vetter@intel.com> Cc: Jani Nikula <jani.nikula@linux.intel.com> Reviewed-by:
Mika Kuoppala <mika.kuoppala@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1481718380-9170-1-git-send-email-mika.kuoppala@intel.com
-
Jani Nikula authored
Commit c9c4b6f6 ("drm/i915: fix swizzle detection for gen3") added a complicated check for I915G/I945G. Pineview and other gen3 devices match IS_MOBILE() anyway. Simplify. Cc: Daniel Vetter <daniel@ffwll.ch> Reviewed-by:
-
- 13 Dec, 2016 9 commits
-
-
Daniel Vetter authored
It's been unfixed since a while and no one is immediately working on this. And we have the FIXME already. And now also a task in the DP team's backlog. Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: stable@vger.kernel.org Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> References: https://lists.freedesktop.org/archives/intel-gfx/2016-July/101951.htmlAcked-by:
Daniel Vetter <daniel.vetter@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20161213195414.28923-1-daniel.vetter@ffwll.ch
-
Mika Kahola authored
Unify function structure as any other *_hz_to_pwm() functions are structured. Signed-off-by:
Mika Kahola <mika.kahola@intel.com> Reviewed-by:
-
Mika Kahola authored
Let's switch to use dev_priv instead of dev when calling intel_find_panel_downclock() function. Signed-off-by:
-
Mika Kahola authored
Let's switch to use private dev_priv instead of dev when detecting intel panels. Signed-off-by:
-
Manasi Navare authored
This patch does not change anything functionally, just cleans up the DP compliance related variables and stores them all together in a separate struct intel_dp_compliance. There is another struct intel_dp_compliance_data to store all the test data. This makes it easy to reset the compliance variables through a memset instead of individual resetting. v2: * Removed functional changes for EDID (Jani Nikula) Reviewed-by:
Jani Nikula <jani.nikula@linux.intel.com> Signed-off-by:
Manasi Navare <manasi.d.navare@intel.com> Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Daniel Vetter <daniel.vetter@ffwl.ch> Signed-off-by:
-
Manasi Navare authored
If link training fails, then we need to fallback to lower link rate first and if link training fails at RBR, then fallback to lower lane count. This function finds the next lower link rate/lane count value after link training failure and limits the max link_rate and lane_count values to these fallback values. v7: * Remove unnecessary intializations and remove redundant call to intel_dp_common_rates (Jani Nikula) v6: * Cap the max link rate and lane count to the max values obtained during fallback link training (Daniel Vetter) v5: * Start the fallback at the lane count value passed not the max lane count (Jani Nikula) v4: * Remove the redundant variable link_train_failed v3: * Remove fallback_link_rate_index variable, just obtain that using the helper intel_dp_link_rate_index (Jani Nikula) v2: Squash the patch that returns the link rate index (Jani Nikula) Acked-by:
Tony Cheng <tony.cheng@amd.com> Acked-by:
Harry Wentland <harry.wentland@amd.com> Cc: Ville Syrjala <ville.syrjala@linux.intel.com> Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Daniel Vetter <daniel.vetter@intel.com> Signed-off-by:
-
Manasi Navare authored
Sink's capabilities are advertised through DPCD registers and get updated only on hotplug. So they should be computed only once in the long pulse handler and saved off in intel_dp structure for the use later. For this reason two new fields max_sink_lane_count and max_sink_link_bw are added to intel_dp structure. This also simplifies the fallback link rate/lane count logic to handle link training failure. In that case, the max_sink_link_bw and max_sink_lane_count can be reccomputed to match the fallback values lowering the sink capabilities due to link train failure. Cc: Ville Syrjala <ville.syrjala@linux.intel.com> Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Daniel Vetter <daniel.vetter@intel.com> Signed-off-by:
-
Jani Nikula authored
Request the GPIO by index through the consumer API. For now, use a quick hack to store the already requested ones, simply because I have no idea whether this actually works or not, and I have no way to test it. v2 by Mika: switch *NULL* to *"panel"* when requesting gpio for MIPI/DSI panel. Signed-off-by:
-
Tomeu Vizoso authored
In preparation to using a generic API in the DRM core for continuous CRC generation, move the related code out of i915_debugfs.c into a new file. Eventually, only the Intel-specific code will remain in this new file. v2: Rebased. v6: Rebased. v7: Fix whitespace issue. v9: Have intel_display_crc_init accept a drm_i915_private instead. v12: Rebased. Signed-off-by:
Tomeu Vizoso <tomeu.vizoso@collabora.com> Reviewed-by:
Emil Velikov <emil.velikov@collabora.com> Signed-off-by:
-
- 12 Dec, 2016 3 commits
-
-
Vidya Srinivas authored
Currently the backlight controller is taken as 0. It needs to derive value from the VBT. Adding the necessary changes. v2 by Jani: - drop obsolete comments, drop redundant initialization (Bob) - merge debug logging into one Signed-off-by:
Uma Shankar <uma.shankar@intel.com> Signed-off-by:
Vidya Srinivas <vidya.srinivas@intel.com> Reviewed-by:
Bob Paauwe <bob.j.paauwe@intel.com> Tested-by:
-
Chris Wilson authored
Some object retain an extra pin whilst they are active (e.g. contexts). This excludes them from being considered for eviction unless we idle the GPU. If before we look at the active list, we retire beforehand we can hopefully remove a few excess pins and reduce the amount of searching required. v2: Similar principle applies to evict_for_vma Signed-off-by:
-
Chris Wilson authored
In commit a4f5ea64 ("drm/i915: Refactor object page API"), I reordered the object->pages teardown to be more friendly wrt to a separate obj->mm.lock. However, I overlooked the phys object and left it with a dangling use-after-free of its phys_handle. Move the allocation of the phys handle to get_pages and it release to put_pages to prevent the invalid access and to improve symmetry. v2: Add commentary about always aligning to page size. Testcase: igt/drv_selftest/objects Reported-by:
-
- 10 Dec, 2016 1 commit
-
-
Nagaraju, Vathsala authored
For PSR2 , as per spec, PSR2_CTL bit 31 to be set. for psr1, bit 31 in SRD_CTL to be set. Reporting "HW Enabled & Active bit" status for psr2 from SRD_CTL gives wrong status. Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Jim Bride <jim.bride@linux.intel.com> Signed-off-by:
vathsala nagaraju <vathsala.nagaraju@intel.com> Reviewed-by:
-
- 09 Dec, 2016 1 commit
-
-
Robert Bragg authored
This adds a 'Perf' section to i915.rst with the following sub sections: - Overview - Comparison with Core Perf - i915 Driver Entry Points - i915 Perf Stream - i915 Perf Observation Architecture Stream - All i915 Perf Internals v2: section headers in i915.rst (Daniel Vetter) missing symbol docs + other fixups (Matthew Auld) Signed-off-by:Robert Bragg <robert@sixbynine.org> Reviewed-by:
-
- 08 Dec, 2016 3 commits
-
-
Imre Deak authored
According to the previous patch, it's possible atm that we call intel_do_sagv_disable() only once during the 1ms period and time out if that call fails. As opposed to this the spec says that we need to keep retrying this request for a 1ms duration, so let's do this similarly to the CDCLK change notification request. v4-5: - Rebased on the reply_mask, reply change. v6: - Remove w/s change. (Lyude) - Rebased on the timeout_base argument change. Cc: Lyude <cpaul@redhat.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Fixes: 656d1b89 ("drm/i915/skl: Add support for the SAGV, fix underrun hangs") Signed-off-by:
-
Imre Deak authored
commit 848496e5 Author: Ville Syrjälä <ville.syrjala@linux.intel.com> Date: Wed Jul 13 16:32:03 2016 +0300 drm/i915: Wait up to 3ms for the pcu to ack the cdclk change request on SKL increased the timeout to match the spec, but we still see a timeout on at least one SKL. A CDCLK change request following the failed one will succeed nevertheless. I could reproduce this problem easily by running kms_pipe_crc_basic in a loop. In all failure cases _wait_for() was pre-empted for >3ms and so in the worst case - when the pre-emption happened right after calculating timeout__ in _wait_for() - we called skl_cdclk_wait_for_pcu_ready() only once which failed and so _wait_for() timed out. As opposed to this the spec says to keep retrying the request for at most a 3ms period. To fix this send the first request explicitly to guarantee that there is 3ms between the first and last request. Though this matches the spec, I noticed that in rare cases this can still time out if we sent only a few requests (in the worst case 2) _and_ PCODE is busy for some reason even after a previous request and a 3ms delay. To work around this retry the polling with pre-emption disabled to maximize the number of requests. Also increase the timeout to 10ms to account for interrupts that could reduce the number of requests. With this change I couldn't trigger the problem. v2: - Use 1ms poll period instead of 10us. (Chris) v3: - Poll with pre-emption disabled to increase the number of request attempts. (Ville, Chris) - Factor out a helper to poll, it's also needed by the next patch. v4: - Pass reply_mask, reply to skl_pcode_request(), instead of assuming the reply is generic. (Ville) v5: - List the request specific timeout values as code comment. (Ville) v6: - Try the poll first with preemption enabled. - Add code comment about first request being queued by PCODE. (Art) - Add timeout_base_ms argument. (Ville) v7: - Clarify code comment about first queued request. (Chris) Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Art Runyan <arthur.j.runyan@intel.com> Cc: <stable@vger.kernel.org> # v4.2- : 3b2c1710 : drm/i915: Wait up to 3ms Cc: <stable@vger.kernel.org> # v4.2- Fixes: 5d96d8af ("drm/i915/skl: Deinit/init the display at suspend/resume") Reference: https://bugs.freedesktop.org/show_bug.cgi?id=97929 Testcase: igt/kms_pipe_crc_basic/suspend-read-crc-pipe-B Signed-off-by:
-
Tvrtko Ursulin authored
Now that it is available we don't have to open code a similar error message ourselves. Signed-off-by:
-
