- 16 Nov, 2017 20 commits
-
-
Zhi Wang authored
Now the function has been moved into scheduler.c. The extra declaration is not necessary. Signed-off-by: Zhi Wang <zhi.a.wang@intel.com>
-
Zhi Wang authored
Move common vGPU workload creation functions into scheduler.c since they are not specific to execlist emulation. Signed-off-by: Zhi Wang <zhi.a.wang@intel.com>
-
Zhi Wang authored
Move common workload preparation into prepare_workload() in scheduler.c, as they are not specific to execlist emulation. Signed-off-by: Zhi Wang <zhi.a.wang@intel.com>
-
Zhi Wang authored
Factor out prepare_workload() for the following re-factor. Signed-off-by: Zhi Wang <zhi.a.wang@intel.com>
-
Zhi Wang authored
Factor out vGPU workload creation/destroy functions since they are not specific to execlist emulation. Signed-off-by: Zhi Wang <zhi.a.wang@intel.com>
-
Shuo Liu authored
It's better enable/disable and classify gvt debug info dynamically. This patch change it to dyndbg so can be dynamically enable/disable each item. All gvt log can be enabled by, $ echo 'file *gvt* +p' > /sys/kernel/debug/dynamic_debug/control Signed-off-by: Shuo Liu <shuo.a.liu@intel.com> Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
-
Colin Ian King authored
An earlier fix changed the return type from find_bb_size however the integer return is being assigned to a unsigned int so the -ve error check will never be detected. Make bb_size an int to fix this. Detected by CoverityScan CID#1456886 ("Unsigned compared against 0") Fixes: 1e3197d6 ("drm/i915/gvt: Refine error handling for perform_bb_shadow") Signed-off-by: Colin Ian King <colin.king@canonical.com> Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
-
fred gao authored
When a scan error occurs in submit_context, this patch is to decrease the mm ref count and free the workload struct before the workload is abandoned. v2: - submit_context related code should be combined together. (Zhenyu) v3: - free all the unsubmitted workloads. (Zhenyu) v4: - refine the clean path. (Zhenyu) v5: - polish the title. (Zhenyu) Signed-off-by: fred gao <fred.gao@intel.com> Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
-
fred gao authored
When a scan error occurs in dispatch_workload, this patch is to check the healthy state and free all the queued workloads before the failsafe mode is entered. Signed-off-by: fred gao <fred.gao@intel.com> Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
-
fred gao authored
Generally, there are 3 types of errors during command scan: a) some commands might be unknown with EBADRQC; b) some cmd access invalid address with EFAULT; c) some unexpected force nonpriv cmd with EPERM. later the healthy state can be judged through the return error. v2: - remove some internal i915 errors rating. (Zhenyu) v3: - the healthy state is judged through the internal defined return error. (Zhenyu) - force non priv cmd error can be ignored. (Kevin) v4: - reuse standard defined errno instead of recreate, e.g EBADRQC for unknown cmd, EFAULT for invalid address, EPERM for nonpriv. (Zhenyu) v5: - remove some irrelevant code for the patch. - fix typo of vgpu_is_vm_unhealthy. (Zhenyu) v6: - move the healthy check and failsafe code into another patch. (Zhenyu) v7: - polish title and commit message. (Zhenyu) Signed-off-by: fred gao <fred.gao@intel.com> Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
-
Zhi Wang authored
Theoretically, the largest bulk of commands in the ring buffer of an engine might be the first submission, which usually contains a lot of commands to initialize the HW. After removing the initial allocation of the ring scan buffer and let krealloc() do everything we need, we still have a big chance to get the buffer of suitable size in the first submission. Tested on my SKL NUC. Signed-off-by: Zhi Wang <zhi.a.wang@intel.com>
-
Zhi Wang authored
Move ring scan buffers into intel_vgpu_submission since they belongs to a part of vGPU submission stuffs. Signed-off-by: Zhi Wang <zhi.a.wang@intel.com>
-
Zhi Wang authored
"reserved" means reserve something from somewhere. Actually they are buffers used by command scanner. Rename it to ring_scan_buffer. v2: - Remove the usage of an extra variable. (Zhenyu) Fixes: 0a53bc07 ("drm/i915/gvt: Separate cmd scan from request allocation") Signed-off-by: Zhi Wang <zhi.a.wang@intel.com>
-
Zhi Wang authored
The pointer points to the original memory can never take the return value of krealloc(). Signed-off-by: Zhi Wang <zhi.a.wang@intel.com>
-
Zhi Wang authored
Move tlb_handle_pending into intel_vgpu_submssion since it belongs to a part of vGPU submission stuffs Signed-off-by: Zhi Wang <zhi.a.wang@intel.com>
-
Zhi Wang authored
Introduce intel_vgpu_submission to hold all members related to submission in struct intel_vgpu before. Signed-off-by: Zhi Wang <zhi.a.wang@intel.com>
-
Zhi Wang authored
Move vGPU workload cache initialization/de-initialization into intel_vgpu_{setup, clean}_submission() since they are not specific to execlist stuffs. Signed-off-by: Zhi Wang <zhi.a.wang@intel.com>
-
Zhi Wang authored
To move workload related functions into scheduler.c, an expected way is to collect all the init/clean functions related to vGPU workload submission into fewer functions. Rename intel_vgpu_{init, clean}_gvt_context() for above usage in future. Signed-off-by: Zhi Wang <zhi.a.wang@intel.com>
-
Zhi Wang authored
The context descriptors in elsp_dwords are stored in a reversed order and the definition of context descriptor is also reversed. The revesred stuff is hard to be used and might cause misunderstanding. Make them in the right oder for following code re-factoring. Tested on my SKL NUC. Signed-off-by: Zhi Wang <zhi.a.wang@intel.com>
-
Xiaolin Zhang authored
opregion emulated with a copy from host which leads to some display bugs such as guest resolution adjustment failure due to host opregion fail to claim port D support. with a fake opregion table provided to fully emulate opregion to meet guest port requirement. v1 - initial patch v2 - reforamt opregion arrary with 0x02x output v3 - opregion array removed with opregion generation on host initizaiton v4 - rebased v3 patch from stable branch to staging branch which also has different struct child_device_config and addressed v3 review comments. Signed-off-by: Xiaolin Zhang <xiaolin.zhang@intel.com> Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
-
- 15 Nov, 2017 12 commits
-
-
Chris Wilson authored
WaEnablePooledEuFor2x6 only applies to preproduction models, unsupported since commit 0102ba1f ("drm/i915: Add early BXT sdv to the list of preproduction machines"). Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20171114135116.30036-1-chris@chris-wilson.co.ukReviewed-by: David Weinehall <david.weinehall@linux.intel.com>
-
Chris Wilson authored
At the start of building a request, we would wait for roughly enough space to fit the average request (to reduce the likelihood of having to wait and abort partway through request construction). To achieve we would try to begin a 0-length command packet, this just adds extra confusion so make the wait-for-space explicit, as in the next patch we want to move it from the backend to the i915_gem_request_alloc() so it can ensure that the wait-for-space is the first operation in building a new request. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20171115151204.8105-2-chris@chris-wilson.co.uk
-
Chris Wilson authored
We don't actually emit any commands into the ringbuffer, so we set it very small. However, an upcoming change centralises the wait-for-space into i915_gem_request_alloc() and that imposes a minimum size upon all ringbuffers (mock or real) of MIN_SPACE_FOR_ADD_REQUEST. Grow the mock ringbuffer such that we allocate a single page for the struct+buffer, satisfying the new condition without wasting too much space. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20171115151204.8105-1-chris@chris-wilson.co.uk
-
Chris Wilson authored
gcc-4.7.3 is confused by the guards inside intel_ppat_get() and reports: drivers/gpu/drm/i915/i915_gem_gtt.c: In function ‘intel_ppat_get’: drivers/gpu/drm/i915/i915_gem_gtt.c:3044:27: warning: ‘entry’ may be used uninitialized in this function [-Wmaybe-uninitialized] Forgive the compiler this once, and rearrange the code so that entry is always initialised. v2: Flavour with a bit of NULL (instead of ERR_PTR(-ENOSPC)) Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Zhi Wang <zhi.a.wang@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20171115131705.16341-1-chris@chris-wilson.co.ukReviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
-
Chris Wilson authored
Silence sparse warnings by using __iomem markup and io accessors. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20171114191842.19063-1-chris@chris-wilson.co.uk
-
Ville Syrjälä authored
While I have no solid proof that ILK follows the ELK path when it comes to the stolen memory reserved area, there are some hints that it might be the case. Unfortunately my ILK doesn't have this enabled, and no way to enable it via the BIOS it seems. So let's have ILK use the ELK code path, and let's toss in a WARN into the code to see if we catch anyone with an ILK that has this enabled to further analyze the situation. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20171102151737.23336-3-ville.syrjala@linux.intel.comAcked-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
-
Ville Syrjälä authored
Now that we should be properly filtering out the cases when the stolen reserved area is disabled, let's convert the debug message about a misplaced reserved area into an error. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20171102151737.23336-2-ville.syrjala@linux.intel.comReviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
-
Ville Syrjälä authored
Apparently there are some machines that put semi-sensible looking values into the stolen "reserved" base and size, except those values are actually outside the stolen memory. There is a bit in the register which supposedly could tell us whether the reserved area is even enabled or not. Let's check for that before we go trusting the base and size. Cc: Tomi Sarvela <tomi.p.sarvela@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20171102151737.23336-1-ville.syrjala@linux.intel.comReviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
-
Ville Syrjälä authored
Fix copy/paste fail in kerneldocs for intel_audio_codec_disable(). Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Suggested-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20171114191127.16188-1-ville.syrjala@linux.intel.comReviewed-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
-
Hans de Goede authored
Quoting Ville: "the forcewake timer might still be active until the uncore suspend, and having active forcewakes while we've already told the GT wake stuff to stop acting normally doesn't seem quite right to me." Reported-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Suggested-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20171114135518.15981-3-hdegoede@redhat.com
-
Hans de Goede authored
intel_uncore_suspend() unregisters the uncore code's PMIC bus access notifier and gets called on both normal and runtime suspend. intel_uncore_resume_early() re-registers the notifier, but only on normal resume. Add a new intel_uncore_runtime_resume() function which only re-registers the notifier and call that on runtime resume. Cc: stable@vger.kernel.org Reported-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20171114135518.15981-2-hdegoede@redhat.com
-
Hans de Goede authored
assert_rpm_wakelock_held is triggered from i915_pmic_bus_access_notifier even though it gets unregistered on (runtime) suspend, this is caused by a race happening under the following circumstances: intel_runtime_pm_put does: atomic_dec(&dev_priv->pm.wakeref_count); pm_runtime_mark_last_busy(kdev); pm_runtime_put_autosuspend(kdev); And pm_runtime_put_autosuspend calls intel_runtime_suspend from a workqueue, so there is ample of time between the atomic_dec() and intel_runtime_suspend() unregistering the notifier. If the notifier gets called in this windowd assert_rpm_wakelock_held falsely triggers (at this point we're not runtime-suspended yet). This commit adds disable_rpm_wakeref_asserts and enable_rpm_wakeref_asserts calls around the intel_uncore_forcewake_get(FORCEWAKE_ALL) call in i915_pmic_bus_access_notifier fixing the false-positive WARN_ON. Changes in v2: -Reword comment explaining why disabling the wakeref asserts is ok and necessary Cc: stable@vger.kernel.org Reported-by: FKr <bugs-freedesktop@ubermail.me> Reviewed-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20171110150301.9601-2-hdegoede@redhat.com
-
- 14 Nov, 2017 8 commits
-
-
Chris Wilson authored
smatch does not track initialised values as well as gcc, and this triggers many warnings by smatch not presented by gcc. Silence smatch by initialising the error values to -ENODEV, which we use to denote internal errors. (If we see a selftest fail with a silent -ENODEV, we know smatch was right!) v2: smatch was right about igt_create_vma(), it may unlikely fail on the first object allocation which we want to be loud about. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20171114223346.25958-1-chris@chris-wilson.co.ukReviewed-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
-
Chris Wilson authored
Resuming GEM presumes it can talk to hw, in particular to ensure the kernel context is loaded upon resume for powersaving. If the GuC is still asleep at this point, we upset the HW. Rearrange the resume such that we restore the original order of init-hw, resume-guc, use-gem. Fixes: 37cd3300 ("drm/i915: Remove redundant intel_autoenable_gt_powersave()") References: a1c41994 ("drm/i915/guc: Add host2guc notification for suspend and resume") Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Alex Dai <yu.dai@intel.com> Cc: Sagar Arun Kamble <sagar.a.kamble@intel.com> Cc: Michal Wajdeczko <michal.wajdeczko@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20171114130300.25677-2-chris@chris-wilson.co.ukReviewed-by: Sagar Arun Kamble <sagar.a.kamble@intel.com>
-
Rodrigo Vivi authored
Display is not sending a PMRsp when a PMReq is received at the same time that all planes are turned off. State machine in the dcprunit is stuck in the WAIT4DONE state which means that there is no fill_done. WA: disable arbiter clock gating, set bit [27] of 0x46530 v2: As Ville pointed out, based on the description the issue can happen when disabling the planes, similar to WaRsPkgCStateDisplayPMReq:hsw Also description of the issue was updated on commit message to make it more clear that we need this earlier. v3: Restore comment about possibility to system hang to where we are sure about it, without speculation. (Ville). v4: Remove doubled sob. Actually do v3 changes :/ Cc: Radhakrishna Sripada <radhakrishna.sripada@intel.com> Cc: Imre Deak <imre.deak@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20171111000319.5040-1-rodrigo.vivi@intel.com
-
Rodrigo Vivi authored
Catchup with upstream. Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
-
Chris Wilson authored
Having removed the preproduction Broxton support (see commit 0102ba1f ("drm/i915: Add early BXT sdv to the list of preproduction machines")), we know we then always need the production Broxton workaround set and do not need a predicate upon revision. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20171114134340.5439-2-chris@chris-wilson.co.uk
-
Chris Wilson authored
We've begun excluding pre-production Broxton machines since commit 0102ba1f ("drm/i915: Add early BXT sdv to the list of preproduction machines"), now remove the list of workaround register values for those early machines. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20170927093325.24206-1-chris@chris-wilson.co.ukReviewed-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20171114134340.5439-1-chris@chris-wilson.co.uk
-
Chris Wilson authored
gem_workarounds reports that the SLICE_UNIT_LEVEL_CLKGATE write isn't sticking. Commit 0a60797a ("drm/i915: Implement ReadHitWriteOnlyDisable.") presumes that SLICE_UNIT_LEVEL_CLKGATE is a masked register in the context image, but commit 90007bca ("drm/i915/cnl: Introduce initial Cannonlake Workarounds.") lists it as an ordering unmasked register. The masked write will be losing the default settings if we trust the original commit. That gem_workarounds reports the value is lost entirely is more worrying though -- but it clearly suggests that it is not a masked register in the context image, so unify both w/a to use the original rmw. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=103705 Fixes: 0a60797a ("drm/i915: Implement ReadHitWriteOnlyDisable.") References: 90007bca ("drm/i915/cnl: Introduce initial Cannonlake Workarounds.") Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Rafael Antognolli <rafael.antognolli@intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Oscar Mateo <oscar.mateo@intel.com> Cc: Mika Kuoppala <mika.kuoppala@intel.com> Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20171111100336.11020-1-chris@chris-wilson.co.ukReviewed-by: Rafael Antognolli <rafael.antognolli@intel.com>
-
Lionel Landwerlin authored
ERROR: "__udivdi3" [drivers/gpu/drm/i915/i915.ko] undefined! ERROR: "__divdi3" [drivers/gpu/drm/i915/i915.ko] undefined! Store the frequency in kHz and drop 64bit divisions. v2: Use div64_u64 (Matthew) v3: store frequency in kHz to avoid 64bit divs (Chris/Ville) Fixes: dab91783 ("drm/i915: expose command stream timestamp frequency to userspace") Reported-by: Matthew Auld <matthew.auld@intel.com> Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20171113233455.12085-3-lionel.g.landwerlin@intel.comReviewed-by: Ewelina Musial <ewelina.musial@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
-