- 06 Dec, 2017 2 commits
-
-
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: 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: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20171206135316.32556-1-michal.wajdeczko@intel.com
-
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: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20171205032629.vylemph57toipeax@zhen-hp.sh.intel.com
-
- 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: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20171205190118.7088-2-lucas.demarchi@intel.com
-
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: Lucas De Marchi <lucas.demarchi@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20171205190118.7088-1-lucas.demarchi@intel.com
-
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: Chris Wilson <chris@chris-wilson.co.uk> Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Michał Winiarski <michal.winiarski@intel.com> Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Acked-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: Chris Wilson <chris@chris-wilson.co.uk> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: stable@vger.kernel.org Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20171204132513.7303-1-chris@chris-wilson.co.uk
-
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: Imre Deak <imre.deak@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/1510276712-29590-2-git-send-email-anusha.srivatsa@intel.com
-
- 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: Paulo Zanoni <paulo.r.zanoni@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20171113233455.12085-5-lionel.g.landwerlin@intel.com
-
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: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/1b214f53-47f5-bef3-f58e-8136de5678ed@infradead.org
-
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: Zhenyu Wang <zhenyuw@linux.intel.com>
-
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: Zhenyu Wang <zhenyuw@linux.intel.com>
-
Changbin Du authored
Convert the macro to a function which should always be preferred. Signed-off-by: Changbin Du <changbin.du@intel.com> Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
-
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: Zhenyu Wang <zhenyuw@linux.intel.com>
-
Tina Zhang authored
This patch introduces KBL platform to dma-buf on Gvt-g. Signed-off-by: Tina Zhang <tina.zhang@intel.com> Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
-
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 <tina.zhang@intel.com> Cc: Zhenyu Wang <zhenyuw@linux.intel.com> Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
-
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 <tina.zhang@intel.com> Cc: Alex Williamson <alex.williamson@redhat.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Gerd Hoffmann <kraxel@redhat.com> Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
-
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: Tina Zhang <tina.zhang@intel.com> Reviewed-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: Zhenyu Wang <zhenyuw@linux.intel.com>
-
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 <tina.zhang@intel.com> Cc: Zhenyu Wang <zhenyuw@linux.intel.com> Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
-
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: Tina Zhang <tina.zhang@intel.com> Tested-by: Xiong Zhang <xiong.y.zhang@intel.com> Cc: Zhenyu Wang <zhenyuw@linux.intel.com> Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
-
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: Xiong Zhang <xiong.y.zhang@intel.com> Tested-by: Tina Zhang <tina.zhang@intel.com> Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
-
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: Chris Wilson <chris@chris-wilson.co.uk> Cc: Xiong Zhang <xiong.y.zhang@intel.com> Cc: Zhenyu Wang <zhenyuw@linux.intel.com> Cc: Zhi Wang <zhi.a.wang@intel.com> Cc: intel-gvt-dev@lists.freedesktop.org Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
-
- 02 Dec, 2017 1 commit
-
-
Rodrigo Vivi authored
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
-
- 01 Dec, 2017 13 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: Rodrigo Vivi <rodrigo.vivi@intel.com> Tested-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20171201021700.13504-1-james.ausmus@intel.com
-
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 <chris@chris-wilson.co.uk> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Jani Nikula <jani.nikula@intel.com> Cc: Imre Deak <imre.deak@intel.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20171201113030.18360-1-chris@chris-wilson.co.uk
-
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: Chris Wilson <chris@chris-wilson.co.uk> Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20171201122011.16841-1-chris@chris-wilson.co.ukReviewed-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: Rodrigo Vivi <rodrigo.vivi@intel.com>
-
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ä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20171129153732.3612-3-ville.syrjala@linux.intel.comReviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
-
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: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20171129153732.3612-2-ville.syrjala@linux.intel.com
-
Ville Syrjälä authored
Previously I was under the impression that the scanline counter reads 0 when the pipe is off. Turns out that's not correct, and instead the scanline counter simply stops when the pipe stops, and it retains it's last value until the pipe starts up again, at which point the scanline counter jumps to vblank start. These jumps can cause the timestamp to jump backwards by one frame. Since we use the timestamps to guesstimage also the frame counter value on gen2, that would cause the frame counter to also jump backwards, which leads to a massice difference from the previous value. The end result is that flips/vblank events don't appear to complete as they're stuck waiting for the frame counter to catch up to that massive difference. Fix the problem properly by actually making sure the scanline counter has started to move before we assume that it's safe to enable vblank processing. v2: Less pointless duplication in the code (Chris) Cc: stable@vger.kernel.org Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Fixes: b7792d8b ("drm/i915: Wait for pipe to start before sampling vblank timestamps on gen2") Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20171129153732.3612-1-ville.syrjala@linux.intel.com
-
Ville Syrjälä authored
i830_disable_pipe() gets called from the power well code, and thus we're already holding the power domain mutex. That means we can't call plane->get_hw_state() as it will also try to grab the same mutex and will thus deadlock. Replace the assert_plane() calls (which calls ->get_hw_state()) with just raw register reads in i830_disable_pipe(). As a bonus we can now get a warning if plane C is enabled even though we don't even expose it as a drm plane. v2: Do a separate WARN_ON() for each plane (Chris) Cc: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Fixes: 51f5a096 ("drm/i915: Add .get_hw_state() method for planes") Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20171129125411.29055-1-ville.syrjala@linux.intel.com
-
Ville Syrjälä authored
Transcoder EDP does not support audio. Let's not try to read the state of the audio enable bit HSW_AUD_PIN_ELD_CP_VLD based on the pipe when using transcoder EDP. While at it make the function static and flatten it. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20171129164303.18793-3-ville.syrjala@linux.intel.comReviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
-
Ville Syrjälä authored
No point in adding the "force audio" property to DP connectors that don't support audio (g4x or port A). Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20171129164303.18793-2-ville.syrjala@linux.intel.comReviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
-
Ville Syrjälä authored
Apparently g4x doesn't support audio over DP. Bspec lists the bit as "Reserved for Audio Output Enable", and empirical evidence tells us that the bit won't stick. So stop trying to enable DP audio on g4x. Link: https://patchwork.freedesktop.org/patch/msgid/20171129164303.18793-1-ville.syrjala@linux.intel.comReviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=103989Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
-
Chris Wilson authored
To execute a requests requires us to have first woken the device, using the rpm wakeref (as the request needs to write to hardware to setup the context/ppGTT and execute on the GPU). So call intel_runtime_pm_get() around queuing the request; the request itself will then carry a wakeref until completion. References: https://bugs.freedesktop.org/show_bug.cgi?id=103994Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: Matthew Auld <matthew.auld@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20171130094231.10405-1-chris@chris-wilson.co.ukReviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
-
Chris Wilson authored
When capturing the bo, we allocate an error object with an array of min(vma->size, vma->node.size) pages, plus a bit for compression overhead. However, when creating the fake vma to describe the bo, only one of the sizes was filled in, resulting in a too small array. Through my and CI testing, this was sufficient for the mostly empty NULL context as it compressed well (or the out-of-bounds access simply didn't cause an issue). However, in real workloads on Cannonlake, we were overflowing that array and causing havoc with the random memory corruption. Reported-by: Rafael Antognolli <rafael.antognolli@intel.com> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=103964 Fixes: 4e90a6e2 ("drm/i915: Record default HW state in the GPU error state") Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Tested-by: Rodrigo Vivi <rodrigo.vivi@gmail.com> Link: https://patchwork.freedesktop.org/patch/msgid/20171201001536.13941-1-chris@chris-wilson.co.ukReviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
-
- 30 Nov, 2017 4 commits
-
-
Chris Wilson authored
drivers/gpu/drm/i915/i915_irq.c|3096 col 29| error: comparison between signed and unsigned integer expressions [-Werror=sign-compare] Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20171130125253.21405-1-chris@chris-wilson.co.ukReviewed-by: Michal Wajdeczko <michal.wajdeczko@intel.com>
-
Maarten Lankhorst authored
This comment predates atomic, and I think with the way we currently track IPS, it's safe to enable this for the case we switch too. Changes since v1: - Keep IPS enabled when switching planes. Changes since v2: - Enable IPS when at least one plane is enabled. (Ville) Changes since v3: - Actually do what was advertised in v3, sigh! (Ville, CI) Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20171122183906.47767-1-maarten.lankhorst@linux.intel.comReviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
-
Maarten Lankhorst authored
ips_enabled was used as a variable of whether IPS can be enabled or not, but should be used to test whether IPS is actually enabled. Changes since v1: - Call needs_modeset on new crtc state. (Ville) - IPS can be enabled with sprite plane enabled too. (Ville) - Fix CDCLK vs IPS workaround. (Ville) Changes since v2: - Only re-enable fastset when inheriting mode. (Ville) - Put the conditions for enabling and disabling IPS in a helper. Changes since v3: - Keep the max_cdclk workaround working. (Ville) - Also check logical cdclk out of paranoia. - Remove planes check from IPS disable function for initial disable. - Remove assert_plane_enabled/disabled checks and use crtc_state->active_planes for hsw_enable_ips only, always allow calling hsw_disable_ips to disable it initially in hw. Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20171122183901.47720-1-maarten.lankhorst@linux.intel.com [mlankhorst: pipe_config -> crtc_state (Ville)] Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
-
Imre Deak authored
We store a SW state of the t11_t12 timing in 100usec units but have to program it in 100msec as required by HW. The rounding used during programming means there will be a mismatch between the SW and HW states of this value triggering a "PPS state mismatch" error. Avoid this by storing the already rounded-up value in the SW state. Note that we still calculate panel_power_cycle_delay with the finer 100usec granularity to avoid any needless waits using that version of the delay. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=103903 Cc: joks <joks@linux.pl> Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20171129175137.2889-1-imre.deak@intel.com
-