- 08 Dec, 2017 2 commits
-
-
Tvrtko Ursulin authored
It seems that the DMC likes to transition between the DC states a lot when there are no connected displays (no active power domains) during command submission. This activity on DC states has a negative impact on the performance of the chip with huge latencies observed in the interrupt handlers and elsewhere. Simple tests like igt/gem_latency -n 0 are slowed down by a factor of eight. Work around it by introducing a new power domain named, POWER_DOMAIN_GT_IRQ, associtated with the "DC off" power well, which is held for the duration of command submission activity. CNL has the same problem which will be addressed as a follow-up. Doing that requires a fix for a DC6 context corruption problem in the CNL DMC firmware which is yet to be released. v2: * Add commit text as comment in i915_gem_mark_busy. (Chris Wilson) * Protect macro body with braces. (Jani Nikula) v3: * Add dedicated power domain for clarity. (Chris, Imre) * Commit message and comment text updates. * Apply to all big-core GEN9 parts apart for Skylake which is pending DMC firmware release. v4: * Power domain should be inner to device runtime pm. (Chris) * Simplify NEEDS_CSR_GT_PERF_WA macro. (Chris) * Handle async DMC loading by moving the GT_IRQ power domain logic into intel_runtime_pm. (Daniel, Chris) * Include small core GEN9 as well. (Imre) v5 * Special handling for async DMC load is not needed since on failure the power domain reference is kept permanently taken. (Imre) v6: * Drop the NEEDS_CSR_GT_PERF_WA macro since all firmwares have now been deployed. (Imre, Chris) Signed-off-by:
Tvrtko Ursulin <tvrtko.ursulin@intel.com> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=100572 Testcase: igt/gem_exec_nop/headless Cc: Imre Deak <imre.deak@intel.com> Acked-by: Chris Wilson <chris@chris-wilson.co.uk> (v2) Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Dmitry Rogozhkin <dmitry.v.rogozhkin@intel.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> (v5) Reviewed-by:
Chris Wilson <chris@chris-wilson.co.uk> [Imre: Add note about applying the WA on CNL as a follow-up] Signed-off-by:
Imre Deak <imre.deak@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20171205132854.26380-1-tvrtko.ursulin@linux.intel.com
-
Chris Wilson authored
Currently on every submission, we recalculate the ELSP register offset for the engine, after chasing the pointers to find the iomem base. Since this is fixed for the lifetime of the driver, record the offset in the execlists struct. In practice the difference is negligible, it just happens to remove 27 bytes of eyesore pointer dancing from next to the hottest instruction (which is itself due to stalling for a cache miss) in perf profiles of the execlists_submission_tasklet(). v2: Trim off one more elsp local. Signed-off-by:
Michel Thierry <michel.thierry@intel.com> Reviewed-by:
Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20171207222434.17686-1-chris@chris-wilson.co.uk
-
- 07 Dec, 2017 3 commits
-
-
Chris Wilson authored
In quite a few places, we have a list iteration over the vma on an object that only want to inspect GGTT vma. By construction, these are placed at the start of the list, so we have copied that knowledge into many callsites. Pull that knowledge back to i915_vma.h and provide a for_each_ggtt_vma() to tidy up the code. v2: Add a backreference from vma_create() to remind ourselves why we put ggtt vma at the head of the obj->vma_list (and ppgtt vma at the tail). v3: Fixup s/vma/V/ Suggested-by:
Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20171207211407.31549-1-chris@chris-wilson.co.uk
-
Chris Wilson authored
As writes through the GTT and GGTT PTE updates do not share the same path, they are not strictly ordered and so we must explicitly flush the indirect writes prior to modifying the PTE. We do track outstanding GGTT writes on the object itself, but since the object may have multiple GGTT vma, that is overly coarse as we can track and flush individual vma as required. Whilst here, update the GGTT flushing behaviour for Cannonlake. v2: Hard-code ring offset to allow use during unload (after RCS may have been freed, or never existed!) References: https://bugs.freedesktop.org/show_bug.cgi?id=104002Signed-off-by:
-
Chris Wilson authored
Originally we translated from the object to the vma by walking obj->vma_list to find the matching vm (for user lookups). Now we process user lookups using the rbtree, and we only use obj->vma_list itself for maintaining state (e.g. ensuring that all vma are flushed or rebound). As such maintenance needs to go on beyond the user's awareness of the vma, defer removal of the vma from the obj->vma_list from i915_vma_close() to i915_vma_destroy() Fixes: 5888fc9e ("drm/i915: Flush pending GTT writes before unbinding") Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=104155Signed-off-by:
-
- 06 Dec, 2017 8 commits
-
-
Michal Wajdeczko authored
Our new "enable_guc" modparam allows to control whenever HuC should be loaded. However existing code will try load and authenticate HuC always when we use the GuC. This patch is trying to enforce modparam selection. v2: no need to cast PTR_ERR (Chris) fetch/fini only if required (Michal) fix wrong break (Sagar) v3: add new goto label (Sagar) Signed-off-by:Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Sagar Arun Kamble <sagar.a.kamble@intel.com> Reviewed-by:
Sagar Arun Kamble <sagar.a.kamble@intel.com> Signed-off-by:
-
Michal Wajdeczko authored
We currently have two module parameters that control GuC: "enable_guc_loading" and "enable_guc_submission". Whenever we need submission=1, we also need loading=1. We also need loading=1 when we want to want to load and verify the HuC. Lets combine above module parameters into one "enable_guc" modparam. New supported bit values are: 0=disable GuC (no GuC submission, no HuC) 1=enable GuC submission 2=enable HuC load Special value "-1" can be used to let driver decide what option should be enabled for given platform based on hardware/firmware availability or preference. Explicit enabling any of the GuC features makes GuC load a required step, fallback to non-GuC mode will not be supported. v2: Don't use -EIO v3: define modparam bits (Chris) v4: rely on implicit cast (Chris) Signed-off-by:
-
Michal Wajdeczko authored
-EIO has special meaning and is used when we want to allow engine initialization to fail and mark GPU as wedged. However here at this function we should return error code that corresponds to upload status only, as any decision how to handle missing firmware should be done higher level function (silent fallback to non-GuC mode, fail into wedged mode, or abort driver load with fatal error). v2: commit message update (Michal) Signed-off-by:
-
Michal Wajdeczko authored
If we don't plan to use GuC then we should not try to fetch GuC and HuC firmwares. We can save memory and avoid possible dmesg noise. Signed-off-by:
-
Michal Wajdeczko authored
In the upcoming patch we will change the way how to recognize when GuC is in use. Using helper macros will minimize scope of that changes. While here, update dev_info message. Signed-off-by:
-
Michal Wajdeczko authored
Doing GuC firmware path selection from sanitize_options function is not perfect, while there is no problem with doing so during early init stage as we already have all needed data. Signed-off-by:
-
Michal Wajdeczko authored
Doing HuC firmware path selection from sanitize_options function is not perfect, while there is no problem with doing so during early init stage as we already have all needed data. Signed-off-by:
-
https://github.com/intel/gvt-linuxRodrigo Vivi authored
gvt-next-2017-12-05 - VFIO mdev display dmabuf interface and gvt support (Tina) - VFIO mdev opregion support/fixes (Tina/Xiong/Chris) - workload scheduling optimization (Changbin) - preemption fix and temporal workaround (Zhenyu) - and misc fixes after refactor (Chris) Signed-off-by:
-
- 05 Dec, 2017 5 commits
-
-
Lucas De Marchi authored
v2: add more missing platform tags v3: change tag to cnp rather than using gen9,gen10 Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by:
Lucas De Marchi <lucas.demarchi@intel.com> Reviewed-by:
-
Lucas De Marchi authored
v2: Allow to have or omit space before platform Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by:
-
Chris Wilson authored
History tells us that if we cannot reset the GPU now, we never will. This then impacts everything that is run subsequently. On failing the reset, we mark the driver as wedged, trying to prevent further execution on the GPU, forcing userspace to fallback to using the CPU to update its framebuffers and let the user know what happened. We also want to go one step further and add a taint to the kernel so that any subsequent faults can be traced back to this failure. This is useful for CI, where if the GPU/driver fails we want to reboot and restart testing rather than continue on into oblivion. For everyone else, the warning taint is a testament to the system unreliability. TAINT_WARN is used anytime a WARN() is emitted, which is suitable for our purposes here as well; the driver/system may behave unexpectedly after the failure. v2: Also taint if the recovery fails (again history shows us that is typically fatal). v3: Use TAINT_WARN References: https://bugs.freedesktop.org/show_bug.cgi?id=103514Signed-off-by:
Tomi Sarvela <tomi.p.sarvela@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20171205172757.32609-1-chris@chris-wilson.co.uk
-
Chris Wilson authored
From the shrinker paths, we want to relinquish the GPU and GGTT access to the object, releasing the backing storage back to the system for swapout. As a part of that process we would unpin the pages, marking them for access by the CPU (for the swapout/swapin). However, if that process was interrupted after unbind the vma, we missed a flush of the inflight GGTT writes before we made that GTT space available again for reuse, with the prospect that we would redirect them to another page. The bug dates back to the introduction of multiple GGTT vma, but the code itself dates to commit 02bef8f9 ("drm/i915: Unbind closed vma for i915_gem_object_unbind()"). Fixes: 02bef8f9 ("drm/i915: Unbind closed vma for i915_gem_object_unbind()") Fixes: c5ad54cf ("drm/i915: Use partial view in mmap fault handler") Signed-off-by:
-
Anusha Srivatsa authored
There is a new version of dmc available for skylake. Following additions from ver1.27 1. Fix for the issue where DC_STATE was getting enabled even when disabled by driver causing data corruption. Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by:
Anusha Srivatsa <anusha.srivatsa@intel.com> Reviewed-by:
-
- 04 Dec, 2017 15 commits
-
-
Lionel Landwerlin authored
We apply this logic to Gen9 as well. We didn't notice this issue as most part we've encountered so far only use the crystal as source for their timestamp registers. Fixes: dab91783 ("drm/i915: expose command stream timestamp frequency to userspace") Reviewed-by:
Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by:
Lionel Landwerlin <lionel.g.landwerlin@intel.com> Signed-off-by:
-
Randy Dunlap authored
Fix documentation build errors after intel_guc_loader.c was renamed to intel_guc_fw.c. Error: Cannot open file ../drivers/gpu/drm/i915/intel_guc_loader.c WARNING: kernel-doc '../scripts/kernel-doc -rst -enable-lineno -function GuC-specific firmware loader ../drivers/gpu/drm/i915/intel_guc_loader.c' failed with return code 1 Error: Cannot open file ../drivers/gpu/drm/i915/intel_guc_loader.c Error: Cannot open file ../drivers/gpu/drm/i915/intel_guc_loader.c WARNING: kernel-doc '../scripts/kernel-doc -rst -enable-lineno -internal ../drivers/gpu/drm/i915/intel_guc_loader.c' failed with return code 2 Fixes: e8668bbc ("drm/i915/guc: Rename intel_guc_loader.c to intel_guc_fw.c") Signed-off-by:
Randy Dunlap <rdunlap@infradead.org> Cc: Michal Wajdeczko <michal.wajdeczko@intel.com> Signed-off-by:
-
Zhenyu Wang authored
This is to workaround guest driver hang regression after preemption enable that gvt hasn't enabled handling of that for guest workload. So in effect this disables preemption for gvt context now. Signed-off-by:Zhenyu Wang <zhenyuw@linux.intel.com>
-
Zhenyu Wang authored
We shouldn't mark inactive for vGPU context if preempted, which would still be re-scheduled later. So keep active state. Fixes: d6c05113 ("drm/i915/execlists: Distinguish the incomplete context notifies") Signed-off-by:
-
Changbin Du authored
The current schedule policy rely on a 1ms timer to execute workload. This can introduce maximum 1ms unnecessary latency. This is especially bad for small media workloads. And I don't think we need this timer for QoS, but the change is not simply remove the code. So I made a new API intel_gvt_kick_schedule() for future change. Signed-off-by:
Changbin Du <changbin.du@intel.com> Signed-off-by:
-
Changbin Du authored
Convert the macro to a function which should always be preferred. Signed-off-by:
-
Tina Zhang authored
The per vGPU dmabuf_obj list should be released in intel_vgpu_dmabuf_ cleanup, which is invoked either in the process of closing a VM or in the process of removing a vGPU. Fixes: e3a0d7976c53 ("drm/i915/gvt: Handle orphan dmabuf_objs") Signed-off-by:Tina Zhang <tina.zhang@intel.com> Signed-off-by:
-
Tina Zhang authored
This patch introduces KBL platform to dma-buf on Gvt-g. Signed-off-by:
-
Tina Zhang authored
dmabuf_obj's destruction relys on GEM release operation, which is managed in i915 driver. And there is a time window between vgpu's destruction and its dmabuf_objs' destruction. This patch is to free the orphan dmabuf_objs correctly after the vgpu passes away. Signed-off-by:
-
Tina Zhang authored
This patch introduces a guest's framebuffer sharing mechanism based on dma-buf subsystem. With this sharing mechanism, guest's framebuffer can be shared between guest VM and host. v17: - modify VFIO_DEVICE_GET_GFX_DMABUF interface. (Alex) v16: - add x_hot and y_hot. (Gerd) - add flag validation for VFIO_DEVICE_GET_GFX_DMABUF. (Alex) - rebase 4.14.0-rc6. v15: - add VFIO_DEVICE_GET_GFX_DMABUF ABI. (Gerd) - add intel_vgpu_dmabuf_cleanup() to clean up the vGPU's dmabuf. (Gerd) v14: - add PROBE, DMABUF and REGION flags. (Alex) v12: - refine the lifecycle of dmabuf. v9: - remove dma-buf management. (Alex) - track the dma-buf create and release in kernel mode. (Gerd) (Daniel) v8: - refine the dma-buf ioctl definition.(Alex) - add a lock to protect the dmabuf list. (Alex) v7: - release dma-buf related allocations in dma-buf's associated release function. (Alex) - refine ioctl interface for querying plane info or create dma-buf. (Alex) v6: - align the dma-buf life cycle with the vfio device. (Alex) - add the dma-buf related operations in a separate patch. (Gerd) - i915 related changes. (Chris) v5: - fix bug while checking whether the gem obj is gvt's dma-buf when user change caching mode or domains. Add a helper function to do it. (Xiaoguang) - add definition for the query plane and create dma-buf. (Xiaoguang) v4: - fix bug while checking whether the gem obj is gvt's dma-buf when set caching mode or doamins. (Xiaoguang) v3: - declare a new flag I915_GEM_OBJECT_IS_GVT_DMABUF in drm_i915_gem_object to represent the gem obj for gvt's dma-buf. The tiling mode, caching mode and domains can not be changed for this kind of gem object. (Alex) - change dma-buf related information to be more generic. So other vendor can use the same interface. (Alex) v2: - create a management fd for dma-buf operations. (Alex) - alloc gem object's backing storage in gem obj's get_pages() callback. (Chris) Signed-off-by:
-
Tina Zhang authored
Add VFIO_DEVICE_QUERY_GFX_PLANE ioctl command to let user query and get a plane and its information. So far, two types of buffers are supported: buffers based on dma-buf and buffers based on region. This ioctl can be invoked with: 1) Either DMABUF or REGION flag. Vendor driver returns a plane_info successfully only when the specific kind of buffer is supported. 2) Flag PROBE. And at the same time either DMABUF or REGION must be set, so that vendor driver returns success only when the specific kind of buffer is supported. Add VFIO_DEVICE_GET_GFX_DMABUF ioctl command to let user get a specific dma-buf fd of an exposed MDEV buffer provided by dmabuf_id which was returned in VFIO_DEVICE_QUERY_GFX_PLANE ioctl command. The life cycle of an exposed MDEV buffer is handled by userspace and tracked by kernel space. The returned dmabuf_id in struct vfio_device_ query_gfx_plane can be a new id of a new exposed buffer or an old id of a re-exported buffer. Host user can check the value of dmabuf_id to see if it needs to create new resources according to the new exposed buffer or just re-use the existing resource related to the old buffer. v18: - update comments for VFIO_DEVICE_GET_GFX_DMABUF. (Alex) v17: - modify VFIO_DEVICE_GET_GFX_DMABUF interface. (Alex) v16: - add x_hot and y_hot fields. (Gerd) - add comments for VFIO_DEVICE_GET_GFX_DMABUF. (Alex) - rebase to 4.14.0-rc6. v15: - add a ioctl to get a dmabuf for a given dmabuf id. (Gerd) v14: - add PROBE, DMABUF and REGION flags. (Alex) v12: - add drm_format_mod back. (Gerd and Zhenyu) - add region_index. (Gerd) v11: - rename plane_type to drm_plane_type. (Gerd) - move fields of vfio_device_query_gfx_plane to vfio_device_gfx_plane_info. (Gerd) - remove drm_format_mod, start fields. (Daniel) - remove plane_id. v10: - refine the ABI API VFIO_DEVICE_QUERY_GFX_PLANE. (Alex) (Gerd) v3: - add a field gvt_plane_info in the drm_i915_gem_obj structure to save the decoded plane information to avoid look up while need the plane info. (Gerd) Signed-off-by:
Gerd Hoffmann <kraxel@redhat.com> Reviewed-by:
Kirti Wankhede <kwankhede@nvidia.com> Acked-by:
Alex Williamson <alex.williamson@redhat.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by:
-
Tina Zhang authored
This patch is to introduce the framebuffer decoder which can decode guest OS's framebuffer information, including primary, cursor and sprite plane. v16: - rebase to 4.14.0-rc6. v14: - refine pixel format table. (Zhenyu) v9: - move drm format change to a separate patch. (Xiaoguang) v8: - fix a bug in decoding primary plane. (Tina) v7: - refine framebuffer decoder code. (Zhenyu) Signed-off-by:
-
Tina Zhang authored
Windows guest driver needs vbt in opregion, to configure the setting for display. Without opregion support, the display registers won't be set and this blocks display model to get the correct information of the guest display plane. This patch is to provide a virtual opregion for guest. The original author of this patch is Xiaoguang Chen. This patch is split from the "Dma-buf support for GVT-g" patch set, with being rebased to the latest gvt-staging branch. v3: - add checking region index during intel_vgpu_rw. (Xiong) v2: - refine intel_vgpu_reg_release_opregion. (Xiong) Here are the previous version comments: v18: - unmap vgpu's opregion when destroying vgpu. v16: - rebase to 4.14.0-rc6. Signed-off-by:
Bing Niu <bing.niu@intel.com> Signed-off-by:
Xiong Zhang <xiong.y.zhang@intel.com> Cc: Zhenyu Wang <zhenyuw@linux.intel.com> Signed-off-by:
-
Xiong Zhang authored
Currently guest opregion is allocated and initialised when guest write opregion base register. This is too late for kvmgt, so move it to vgpu_create time. Signed-off-by:
-
Chris Wilson authored
sparse spots drivers/gpu/drm/i915/gvt/opregion.c:234 alloc_and_init_virt_opregion() error: memcpy() 'header->signature' too small (16 vs 17) as gvt is indeed trying to memcpy a string longer than the signature[]. Fixes: b2d6ef70 ("drm/i915/gvt: Let each vgpu has separate opregion memory") Signed-off-by:
-
- 02 Dec, 2017 1 commit
-
-
Rodrigo Vivi authored
Signed-off-by:
-
- 01 Dec, 2017 6 commits
-
-
James Ausmus authored
Without masking out the old value, we can end up pointing the DDI to a disabled PLL, which makes the system fall over. Mask out the previous value before setting the PLL to DDI mapping. This can be observed by running igt/testdisplay with both an eDP and HDMI/DP output active. v2: Add the Bugzilla link Fixes: 555e38d2 ("drm/i915/cnl: DDI - PLL mapping") Testcase: igt/testdisplay Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=103997 Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Matt Atwood <matthew.s.atwood@intel.com> Signed-off-by:
James Ausmus <james.ausmus@intel.com> Reviewed-by:
-
Chris Wilson authored
It has been many years since the last confirmed sighting (and fix) of an RC6 related bug (usually a system hang). Remove the parameter to stop users from setting dangerous values, as they often set it during triage and end up disabling the entire runtime pm instead (the option is not a fine scalpel!). Furthermore, it allows users to set known dangerous values which were intended for testing and not for production use. For testing, we can always patch in the required setting without having to expose ourselves to random abuse. v2: Fixup NEEDS_WaRsDisableCoarsePowerGating fumble, and document the lack of ilk support better. v3: Clear intel_info->rc6p if we don't support rc6 itself. Signed-off-by:
-
Chris Wilson authored
As we declare the GPU wedged if the reset fails, such a failure is quite terminal. Before taking that drastic action, let's sleep first and try active, in the hope that the hardware has quietened down and is then able to reset. After a few such attempts, it is fair to say that the HW is truly wedged. v2: Always print the failure message now, we precheck whether resets are disabled. References: https://bugs.freedesktop.org/show_bug.cgi?id=104007Signed-off-by:
Mika Kuoppala <mika.kuoppala@linux.intel.com>
-
Ville Syrjälä authored
Reject interlaced modes on VLV/CHV DP outputs. This simply does not work correctly in the hardware. We do get some output, but it's quite corrupted. The available documentation fails to mention this fact. I contacted some hardware people who eventually managed to locate the relevant HSD for VLV, which was resolved by declaring interlaced DP output as not supported. The HSD was never cloned for CHV even though it inherited most of the hardware and thus has the same problems with interlaced DP output. Cc: Dennis Vshivkov <awesome.walrus+bugzilla@gmail.com> Reported-by:
Dennis Vshivkov <awesome.walrus+bugzilla@gmail.com> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=103922Signed-off-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20171129180847.30613-1-ville.syrjala@linux.intel.comAcked-by:
-
Ville Syrjälä authored
Get rid of the crtc->config usages from within intel_pipe_{enable,disable}() by passing in the appropriate crtc state. Signed-off-by: -
Ville Syrjälä authored
We should make sure the pipe has fully started when we enable it from the i830 "power well". Otherwise theoretically i830 could also hit problems with vblank timestamps jumping around (since we skip the wait during modeset on i830). Additionally moving planes between the pipes etc. might not work correctly until both pipes are actually up and running. v2: Less pointless duplication in the code (Chris) Cc: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by:
-
