- 18 May, 2018 7 commits
-
-
Ville Syrjälä authored
All DDI platforms support the full set of preemph settings for each supported vswing, so let's use the same code for them. We'll also move the code into intel_ddi.c so that it sits closer to the actual buf trans tables. Signed-off-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180517170309.28630-2-ville.syrjala@linux.intel.comReviewed-by:
Jani Nikula <jani.nikula@intel.com>
-
Ville Syrjälä authored
Use intel_ddi_dp_voltage_max() for HSW/BDW too instead of letting these fall through the if ladder in a weird way. This function will look at the actual buf trans tables we have for HSW/BDW to determine the max vswing level. It looks to me like the current code leads HSW port A down the IVB port A path, HSW port B+ and BDW fall through to the very end. Both cases do result in the correct max vswing level 2, but it's very hard to see that from the code. Signed-off-by:
-
Ondrej Zary authored
Radiant P845 does not have LVDS, only VGA. Cc: stable@vger.kernel.org Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=105468Signed-off-by:
Ondrej Zary <linux@rainbow-software.org> Signed-off-by:
-
Chris Wilson authored
As all backends implement the same pin_count mechanism and do a dec-and-test as their first step, pull that into the common intel_context_unpin(). This also pulls into the caller, eliminating the indirect call in the usual steady state case. The intel_context_pin() side is a little more complicated as it combines the lookup/alloc as well as pinning the state, and so is left for a later date. Signed-off-by:
Chris Wilson <chris@chris-wilson.co.uk> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Reviewed-by:
Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180517212633.24934-4-chris@chris-wilson.co.uk
-
Chris Wilson authored
To ease the frequent and ugly pointer dance of &request->gem_context->engine[request->engine->id] during request submission, store that pointer as request->hw_context. One major advantage that we will exploit later is that this decouples the logical context state from the engine itself. v2: Set mock_context->ops so we don't crash and burn in selftests. Cleanups from Tvrtko. Signed-off-by:Zhenyu Wang <zhenyuw@linux.intel.com> Reviewed-by:
-
Chris Wilson authored
Move the knowledge about resetting the current context tracking on the engine from inside i915_gem_context.c into intel_engine_cs.c Signed-off-by:
-
Chris Wilson authored
In the next patch, we want to store the intel_context pointer inside i915_request, as it is frequently access via a convoluted dance when submitting the request to hw. Having two context pointers inside i915_request leads to confusion so first rename the existing i915_gem_context pointer to i915_request.gem_context. Signed-off-by:
-
- 17 May, 2018 10 commits
-
-
Paulo Zanoni authored
For all platforms that run haswell_crtc_enable, our spec tells us to configure the transcoder clocks and do link training before it tells us to set pipeconf and the other pipe/transcoder/plane registers. Starting from Icelake, we get machine hangs if we try to touch the pipe/transcoder registers without having the clocks configured and not having some chicken bits set. So this patch changes haswell_crtc_enable() to issue the calls at the appropriate order mandated by the spec. While setting the appropriate chicken bits would also work here, it's better if we actually program the hardware the way it is intended to be programmed. And the chicken bit also has some theoretical downsides that may or may not affect us. Also, correctly programming the hardware does not prevent us from setting the chicken bits in a later patch in case we decide to. v2: Don't forget link training (Ville). Cc: Arthur J Runyan <arthur.j.runyan@intel.com> Cc: James Ausmus <james.ausmus@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by:
Paulo Zanoni <paulo.r.zanoni@intel.com> Reviewed-by:
Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by:
Manasi Navare <manasi.d.navare@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180502215851.30736-1-paulo.r.zanoni@intel.com
-
Oscar Mateo authored
Stop reading some now deprecated interrupt registers in both debugfs and error state. Instead, read the new equivalents in the Gen11 interrupt repartitioning scheme. Note that the equivalent to the PM ISR & IIR cannot be read without affecting the current state of the system, so I've opted for leaving them out. See gen11_reset_one_iir() for more info. v2: else if !!! (Paulo) v3: another else if (Vinay) v4: - Rebased - Renamed patch - Improved the ordering of GENs - Improved the printing of per-GEN info v5: Avoid maybe-unitialized & add comment explaining the lack of PM ISR & IIR Suggested-by:Oscar Mateo <oscar.mateo@intel.com> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Sagar Arun Kamble <sagar.a.kamble@intel.com> Cc: Vinay Belgaumkar <vinay.belgaumkar@intel.com> Reviewed-by:
Vinay Belgaumkar <vinay.belgaumkar@intel.com> [Paulo: fix commit message and coding style.] Signed-off-by:
-
Chris Wilson authored
The command parser is feature complete, stable and required by userspace. In commit 41736a8e ("drm/i915: Use the precomputed value for whether to enable command parsing") I accidentally removed control from the modparam, and as no one has complained, remove the left over modparam completely! References: 41736a8e ("drm/i915: Use the precomputed value for whether to enable command parsing") Signed-off-by:
-
Chris Wilson authored
Make sure that when we don't have any scheduler attributes for the request, the string is terminated. Fixes: 247870ac ("drm/i915: Build request info on stack before printk") Signed-off-by:
-
Chris Wilson authored
The HWACK bit more generically solves the problem of resubmitting ESLP while the hardware is still processing the current ELSP write. We no longer need to check port[0].count itself. References: ba74cb10 ("drm/i915/execlists: Delay writing to ELSP until HW has processed the previous write") Signed-off-by:
-
Ville Syrjälä authored
Parametrize the DVO pipe select bits. For consistency with the new way of doing things, let's read out the pipe select bits even when the port is disable, even though we don't need that behaviour for asserts in this case. v2: Order the defines shift,mask,value (Jani) Reviewed-by:
-
Ville Syrjälä authored
Parametrize the TV pipe select bits. For consistency with the new way of doing things, let's read out the pipe select bits even when the port is disable, even though we don't need that behaviour for asserts in this case. v2: Order the defines shift,mask,value (Jani) Clear the stale pipe select bit in load detection (Jani) Reviewed-by: -
Ville Syrjälä authored
Clean up the SDVO pipe select bits. To make the whole situation a bit less ugly we'll start to share the same code between .get_hw_state() and the port state asserts. v2: Order the defines shift,mask,value (Jani) Reviewed-by:
-
Ville Syrjälä authored
Clean up the LVDS pipe select bits. To make the whole situation a bit less ugly we'll start to share the same code between .get_hw_state() and the port state asserts. v2: Order the defines shift,mask,value (Jani) Drop ruperfluous braces and whitesapce changes (Jani) Combine masks in compute_is_dual_link_lvds() (Jani) v3: Fix LVDS_PIPE_SEL_MASK_CPT Reviewed-by: -
Ville Syrjälä authored
Clean up the ADPA pipe select bits. To make the whole situation a bit less ugly we'll start to share the same code between .get_hw_state() and the port state asserts. v2: Order the defines shift,mask,value (Jani) Reviewed-by:
-
- 16 May, 2018 10 commits
-
-
Chris Wilson authored
We cannot call kthread_park() from softirq context, so let's avoid it entirely during the reset. We wanted to suspend the signaler so that it would not mark a request as complete at the same time as we marked it as being in error. Instead of parking the signaling, stop the engine from advancing so that the GPU doesn't emit the breadcrumb for our chosen "guilty" request. v2: Refactor setting STOP_RING so that we don't have the same code thrice Signed-off-by:
-
Chris Wilson authored
Catch up with the inflight CSB events, after disabling the tasklet before deciding which request was truly guilty of hanging the GPU. Signed-off-by:
-
Chris Wilson authored
Pull the CSB event processing into its own routine so that we can reuse it during reset to flush any missed interrupts/events. Signed-off-by:
-
Chris Wilson authored
In the next patch, we will make the execlists reset prepare callback take into account preemption by flushing the context-switch handler. This is not applicable to the GuC submission backend, so split the two into their own backend callbacks. Signed-off-by:
Jeff McGee <jeff.mcgee@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180516183355.10553-5-chris@chris-wilson.co.uk
-
Chris Wilson authored
In preparation to more carefully handling incomplete preemption during reset by execlists, we move the existing code wholesale to the backends under a couple of new reset vfuncs. Signed-off-by:
-
Chris Wilson authored
As a complement to inject_preempt_context(), follow up with the function to handle its completion. This will be useful should we wish to extend the duties of the preempt-context for execlists. v2: And do the same for the guc. Signed-off-by:
-
Chris Wilson authored
When setting up reset, we may need to recursively prepare an engine. In which case we should only synchronously flush the tasklets on the outer most call, the inner calls will then be inside an atomic section where the tasklet will never be run (and so the sync will never complete). Signed-off-by:
Mika Kuoppala <mika.kuoppala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180516183355.10553-2-chris@chris-wilson.co.uk
-
Chris Wilson authored
The idea was to try and let the existing tasklet run to completion before we began the reset, but it involves a racy check against anything else that tries to run the tasklet. Rather than acknowledge and ignore the race, let it be and don't try and be too clever. The tasklet will resume execution after reset (after spinning a bit during reset), but before we allow it to resume we will have cleared all the pending state. Signed-off-by:
-
Colin Ian King authored
Trivial fix to spelling mistakes in WARN warning message text and in comments: "seqeuncer", "seqeuencer" -> "sequencer" Signed-off-by:
Colin Ian King <colin.king@canonical.com> Signed-off-by:
-
Chris Wilson authored
When switching to the kernel context, we force the switch to occur after all currently active requests (so that we know the GPU won't switch immediately away and the kernel context remains current as we work). To do so we have to inspect all the timelines and add a fence from the active work to queue our switch afterwards. We can use the tracked set of active rings to shrink our search for active timelines. v2: Use a local to shrink the list_for_each_entry() Signed-off-by:
-
- 14 May, 2018 4 commits
-
-
Jani Nikula authored
Signed-off-by: -
Chris Wilson authored
When we process the outstanding requests upon banning a context, we need to acquire both the engine and the client's timeline, nesting the locks. This requires explicit markup as the two timelines are now of the same class, since commit a89d1f92 ("drm/i915: Split i915_gem_timeline into individual timelines"). Testcase: igt/gem_eio/banned Fixes: a89d1f92 ("drm/i915: Split i915_gem_timeline into individual timelines") Signed-off-by:
-
Chris Wilson authored
The original switch to use CSB from the HWSP was plagued by the effect of read ordering on VT-d; we would read the WRITE pointer from the HWSP before it had completed writing the CSB contents. The mystery comes down to the lack of rmb() for correct ordering with respect to the writes from HW, and with that resolved we can remove the VT-d special casing. Signed-off-by:
-
https://github.com/intel/gvt-linuxJani Nikula authored
- Improve the emulation of virtual non-priv register. (Yan) - Reverse the hack of host of preeption of GVT-g. (Weinan) - Improve untracked warning message.(Changbin) Signed-off-by:
-
- 13 May, 2018 8 commits
-
-
Weinan Li authored
This reverts commit 11474e90. There are issues which will block the host preemption before, instead of disabling it use one workaround "setting max priority for gvt context" to avoid the gvt context be preempted by the host. Now the issues have been cleared, so revert this patch to enable host preemption. v2: - refine description(Zhenyu) Signed-off-by:
Weinan Li <weinan.z.li@intel.com> Signed-off-by:
Zhi Wang <zhi.a.wang@intel.com>
-
Zhi Wang authored
Signed-off-by: -
Zhao Yan authored
the cmd_reg_handler() is called by cmds LRM, PIPE_CTRL, SRM... for LRM, SRM, we cannot get write data in a simple way. On other side, the force_to_nonpriv reigsters will only be written in LRI in current drivers. so we don't want to bother the handler to handle those memory access cmds, just leave a print message here. Signed-off-by:
Zhao Yan <yan.y.zhao@intel.com> Signed-off-by:
-
Zhao Yan authored
Return error will cause vm hang and enter failsafe mode. However, we don't want that happen on detecting an wrong force_to_nonpriv register write. Therefore, we just omit the wrong write or patch it to default value. v2: only return 0 on detecting lri write of registers outside whitelist, but still return error on other error conditions. (zhenyu wang) Signed-off-by:
Zhang Yulei <yulei.zhang@intel.com> Signed-off-by:
-
Zhao Yan authored
Each ring has a NOPID register and currently they are regarded as default value of force_to_nonpriv registers in guest drivers Signed-off-by:
-
Changbin Du authored
The disable_warn_untrack never prevent gvt from printing untracked mmio errors. We were disturbed by this error storm and the fix is just adding them to the list with no essential new change. This message is only useful for enabling new platform during developing process. So lower the message level to debug and then remove disable_warn_untrack. Signed-off-by:
Changbin Du <changbin.du@intel.com> Signed-off-by:
-
Michel Thierry authored
Factor in clear values wherever required while updating destination min/max. References: HSDES#1604444184 Signed-off-by:
Michel Thierry <michel.thierry@intel.com> Cc: mesa-dev@lists.freedesktop.org Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com> Cc: Oscar Mateo <oscar.mateo@intel.com> Reviewed-by:
-
Matthew Auld authored
We write all 4K page entries, even when using 64K pages. In order to verify that the HW isn't cheating by using the 4K PTE instead of the 64K PTE, we want to remove all the surplus entries. If the HW skipped the 64K PTE, it will read/write into the scratch page instead - which we detect as missing results during selftests. v2: much improved commentary (Chris) Signed-off-by:
Matthew Auld <matthew.auld@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Changbin Du <changbin.du@intel.com> Reviewed-by:
-
- 11 May, 2018 1 commit
-
-
Chris Wilson authored
Before we unpin the buffer used for OA reports and return it to the system, we need to be sure that the HW has finished writing into it. For lack of a better idea, poll OACONTROL to check it is switched off. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=106379Signed-off-by:
Lionel Landwerlin <lionel.g.landwerlin@intel.com> Tested-by:
-
