summaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2018-02-06drm/i915/cnp: Ignore VBT request for know invalid DDC pin.Rodrigo Vivi1-3/+8
Let's ignore VBT request if the pin is clearly wrong. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=104139 Cc: Kai Heng Feng <kai.heng.feng@canonical.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180123174050.4261-1-rodrigo.vivi@intel.com Reviewed-by: Radhakrishna Sripada <radhakrishna.sripada@intel.com> (cherry picked from commit a8e6f3888b05c1e7b685800a3371ce050720368f) Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2018-02-06drm/i915/cmdparser: Do not check past the cmd length.Michal Srb1-0/+6
The command MEDIA_VFE_STATE checks bits at offset +2 dwords. However, it is possible to have MEDIA_VFE_STATE command with length = 0 + LENGTH_BIAS = 2. In that case check_cmd will read bits from the following command, or even past the end of the buffer. If the offset ends up outside of the command length, reject the command. Fixes: 351e3db2b363 ("drm/i915: Implement command buffer parsing logic") Signed-off-by: Michal Srb <msrb@suse.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180205151745.29292-1-msrb@suse.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/20180205160438.3267-2-chris@chris-wilson.co.uk (cherry picked from commit 3aec7f871c65eb5f76b4125fda432593c834a6f2) Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2018-02-06drm/i915/cmdparser: Check reg_table_count before derefencing.Michal Srb1-2/+2
The find_reg function was assuming that there is always at least one table in reg_tables. It is not always true. In case of VCS or VECS, the reg_tables is NULL and reg_table_count is 0, implying that no register-accessing commands are allowed. However, the command tables include commands such as MI_STORE_REGISTER_MEM. When trying to check such command, the find_reg would dereference NULL pointer. Now it will just return NULL meaning that the register was not found and the command will be rejected. Fixes: 76ff480ec963 ("drm/i915/cmdparser: Use binary search for faster register lookup") Signed-off-by: Michal Srb <msrb@suse.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180205142916.27092-2-msrb@suse.com Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Matthew Auld <matthew.auld@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/20180205160438.3267-1-chris@chris-wilson.co.uk register lookup") (cherry picked from commit 2f265fad9756a40c09e3f4dcc62d5d7fa73a9fb2) Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2018-02-06drm/i915/bxt, glk: Increase PCODE timeouts during CDCLK freq changingImre Deak3-9/+25
Currently we see sporadic timeouts during CDCLK changing both on BXT and GLK as reported by the Bugzilla: ticket. It's easy to reproduce this by changing the frequency in a tight loop after blanking the display. The upper bound for the completion time is 800us based on my tests, so increase it from the current 500us to 2ms; with that I couldn't trigger the problem either on BXT or GLK. Note that timeouts happened during both the change notification and the voltage level setting PCODE request. (For the latter one BSpec doesn't require us to wait for completion before further HW programming.) This issue is similar to commit 2c7d0602c815 ("drm/i915/gen9: Fix PCODE polling during CDCLK change notification") but there the PCODE request does complete (as shown by the mbox busy flag), only the reply we get from PCODE indicates a failure. So there we keep resending the request until a success reply, here we just have to increase the timeout for the one PCODE request we send. v2: - s/snb_pcode_request/sandybridge_pcode_write_timeout/ (Ville) Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: <stable@vger.kernel.org> # v4.4+ Acked-by: Chris Wilson <chris@chris-wilson.co.uk> (v1) Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=103326 Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180130142939.17983-1-imre.deak@intel.com (cherry picked from commit e76019a81921e87a4d9e7b3d86102bc708a6c227) Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2018-02-06drm/i915/gvt: Use KVM r/w to access guest opregionTina Zhang2-29/+70
For KVMGT, the guest opregion, which is handled by VFIO, is actually a piece of guest memory which won't be accessed by devices. So, its mfn shouldn't be obtained through VFIO interface. This patch uses KVM r/w interface to access the data in guest opregion. Fix the guest opregion accessing issue when host "intel_iommu=on". v3: - Remove mapped flag for KVM/VFIO usage, as it's useless for KVM. v2: - Set the gpa correctly when invoking KVM r/w operations. (Zhenyu) Signed-off-by: Tina Zhang <tina.zhang@intel.com> Cc: Yan Zhao <yan.y.zhao@intel.com> Cc: Xiong Zhang <xiong.y.zhang@intel.com> Signed-off-by: Zhi Wang <zhi.a.wang@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2018-02-06drm/i915/gvt: Fix aperture read/write emulation when enable x-no-mmap=onChangbin Du4-59/+35
When add 'x-no-mmap=on' for vfio-pci option, aperture access in guest is emulated. But the vgpu_aperture_rw() function take wrong offset when do memcpy, since vgpu->gm.aperture_va is not the base of entire aperture. This mistake cause GPU command in guest get lost and so the seqno is not updated in engine HWSP. This patch fix this, and it also move the emulation code to kvmgt. Because only vfio need to emulate it. Put aperture rw to MMIO emulation path breaks assumptions in xengt. v2: Remove PAGE_ALIGN for size (zhenyu) Fixes: f090a00df9ec ("drm/i915/gvt: Add emulation for BAR2 (aperture) with normal file RW approach") Signed-off-by: Changbin Du <changbin.du@intel.com> Signed-off-by: Zhi Wang <zhi.a.wang@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2018-02-06drm/i915/gvt: only reset execlist state of one engine during VM engine resetWeinan Li3-14/+20
Only reset vgpu execlist state of the exact engine which gets reset request from VM. After read context status from HWSP enabled, KMD will use the saved CSB read pointer but not always read from MMIO. When one engine reset happen, only the read pointer of this engine will be reset, in GVT-g host side also need to align with this policy, otherwise VM may get wrong CSB status after one engine reset compeleted. v2: Split refine and fix patch, code refine(Zhenyu) v3: Move active flag of vgpu scheduler into sched_data(Zhenyu) Cc: Fred Gao <fred.gao@intel.com> Cc: Zhi Wang <zhi.a.wang@intel.com> Cc: Zhenyu Wang <zhenyuw@linux.intel.com> Signed-off-by: Weinan Li <weinan.z.li@intel.com> Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com> Signed-off-by: Zhi Wang <zhi.a.wang@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2018-02-06drm/i915/gvt: refine intel_vgpu_submission_ops as per engine opsWeinan Li6-18/+20
Using per engine ops will be more flexible, here refine sub-ops(init, clean) as per engine operation align with reset operation. This change also will be used in next fix patch for VM engine reset. Cc: Fred Gao <fred.gao@intel.com> Cc: Zhi Wang <zhi.a.wang@intel.com> Signed-off-by: Weinan Li <weinan.z.li@intel.com> Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com> Signed-off-by: Zhi Wang <zhi.a.wang@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2018-02-06Merge branch 'linux-4.16' of git://github.com/skeggsb/linux into drm-nextDave Airlie44-1491/+2723
- initial kepler clock gating support - atomic gamma handling fixes - support for gp108 "secure boot" (enables acceleration, finally) * 'linux-4.16' of git://github.com/skeggsb/linux: drm/nouveau/clk: fix gcc-7 -Wint-in-bool-context warning drm/nouveau/mmu: Fix trailing semicolon drm/nouveau: Introduce NvPmEnableGating option drm/nouveau: Add support for SLCG for Kepler2 drm/nouveau: Add support for BLCG on Kepler2 drm/nouveau: Add support for BLCG on Kepler1 drm/nouveau: Add support for basic clockgating on Kepler1 drm/nouveau/kms/nv50: fix handling of gamma since atomic conversion drm/nouveau/kms/nv50: use INTERPOLATE_257_UNITY_RANGE LUT on newer chipsets drm/nouveau/kms/nv50: use "low res" lut for indexed mode drm/nouveau/kms/nv50: prepare for double-buffered LUTs drm/nouveau/bo: add helper functions for handling pinned+mapped buffers drm/nouveau/fbcon: add module parameter to select bits-per-pixel drm/nouveau/secboot/gp108: implement on top of acr_r370 drm/nouveau/secboot/r370: implement support for booting LS SEC2 ucode drm/nouveau/secboot/r370: move a bunch of r375 stuff to a new implementation drm/nouveau: nouveau: use correct string length drm/nouveau/drm/nouveau/mmu: fix odd_ptr_err.cocci warnings drm/nouveau/pmu/fuc: don't use movw directly anymore
2018-02-06Merge tag 'drm-intel-next-fixes-2018-02-01' of ↵Dave Airlie26-133/+226
git://anongit.freedesktop.org/drm/drm-intel into drm-next Fixes for GPU hangs and other bugs around hangcheck and result; Fix for regression on suspend case with vgaswitcheroo; Fixes for eDP and HDMI blank screens Fix for protecting WC allocation to avoid overflow on page vec; Cleanup around unpublished GLK firmware blobs, and other small fixes. This also contains GVT pull request mostly with regression fixes on vGPU display dmabuf, mmio switch and other misc changes. * tag 'drm-intel-next-fixes-2018-02-01' of git://anongit.freedesktop.org/drm/drm-intel: (21 commits) drm/i915/ppgtt: Pin page directories before allocation drm/i915: Always run hangcheck while the GPU is busy Revert "drm/i915: mark all device info struct with __initconst" drm/i915/edp: Do not do link training fallback or prune modes on EDP drm/i915: Check for fused or unused pipes drm/i915: Protect WC stash allocation against direct reclaim drm/i915: Only attempt to scan the requested number of shrinker slabs drm/i915: Always call to intel_display_set_init_power() in resume_early. drm/i915/gvt: cancel scheduler timer when no vGPU exists drm/i915/gvt: cancel virtual vblank timer when no vGPU exists drm/i915/gvt: Keep obj->dma_buf link NULL during exporting drm/i915/pmu: Reconstruct active state on starting busy-stats drm/i915: Stop getting the fault address from RING_FAULT_REG drm/i915/guc: Add uc_fini_wq in gem_init unwind path drm/i915: Fix using BIT_ULL() vs. BIT() for power domain masks drm/i915: Try EDID bitbanging on HDMI after failed read drm/i915/glk: Disable Guc and HuC on GLK drm/i915/gvt: Do not use I915_NUM_ENGINES to iterate over the mocs regs array drm/i915/gvt: validate gfn before set shadow page entry drm/i915/gvt: add PLANE_KEYMAX regs to mmio track list ...
2018-02-02drm/nouveau/clk: fix gcc-7 -Wint-in-bool-context warningArnd Bergmann1-3/+6
gcc thinks that interpreting a multiplication result as a bool is confusing: drivers/gpu/drm/nouveau/nvkm/subdev/clk/gt215.c: In function 'read_pll': drivers/gpu/drm/nouveau/nvkm/subdev/clk/gt215.c:133:8: error: '*' in boolean context, suggest '&&' instead [-Werror=int-in-bool-context] Adding a temporary variable to contain the divisor helps make it clear what is going on and avoids that warning. Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2018-02-02drm/nouveau/mmu: Fix trailing semicolonLuis de Bethencourt1-1/+1
The trailing semicolon is an empty statement that does no operation. Removing it since it doesn't do anything. Signed-off-by: Luis de Bethencourt <luisbg@kernel.org> Reviewed-by: Karol Herbst <kherbst@redhat.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2018-02-02drm/nouveau: Introduce NvPmEnableGating optionLyude Paul1-1/+3
This adds the NvPmEnableGating config option to nouveau, which can be used to enable or disable clockgating for supported chipsets. Enabling can be done by passing config=NvPmEnableGating=1 To nouveau. If your chipset supports it, you'll see a message in your kernel log indicating that clockgating is enabled. Since clockgating has only had limited testing thus far, we leave this option disabled by default for now. Signed-off-by: Lyude Paul <lyude@redhat.com> Reviewed-by: Martin Peres <martin.peres@free.fr> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2018-02-02drm/nouveau: Add support for SLCG for Kepler2Lyude Paul1-0/+93
That's right, there's still more power saving to go! Starting with kepler 2, nvidia hardware has an additional level of clockgating known as second level clockgating. The details of this are not exact, but it seems to work by waiting for a collection of dependent hardware blocks to be gated before taking affect. As with the previous series, this results in another noticeable drop in power consumption and is programmed in the same manner. Signed-off-by: Lyude Paul <lyude@redhat.com> Reviewed-by: Martin Peres <martin.peres@free.fr> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2018-02-02drm/nouveau: Add support for BLCG on Kepler2Lyude Paul5-4/+139
Same as the previous patch, but for Kepler2 now Signed-off-by: Lyude Paul <lyude@redhat.com> Reviewed-by: Martin Peres <martin.peres@free.fr> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2018-02-02drm/nouveau: Add support for BLCG on Kepler1Lyude Paul14-1/+442
This enables BLCG optimization for kepler1. When using clockgating, nvidia's firmware has a set of registers which are initially programmed by the vbios with various engine delays and other mysterious settings that are safe enough to bring up the GPU. However, the values used by the vbios are more power hungry then they need to be, so the nvidia driver writes it's own more optimized set of BLCG settings before enabling CG_CTRL. This adds support for programming the optimized BLCG values during engine/subdev init, which enables rather significant power savings. This introduces the nvkm_therm_clkgate_init() helper, which we use to program the optimized BLCG settings before enabling clockgating with nvkm_therm_clkgate_enable. As well, this commit shares a lot more code with Fermi since BLCG is mostly the same there as far as we can tell. In the future, it's likely we'll reformat the clkgate_packs for kepler1 so that they share a list of mmio packs with Fermi. Signed-off-by: Lyude Paul <lyude@redhat.com> Reviewed-by: Martin Peres <martin.peres@free.fr> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2018-02-02drm/nouveau: Add support for basic clockgating on Kepler1Lyude Paul9-21/+301
This adds support for enabling automatic clockgating on nvidia GPUs for Kepler1. While this is not technically a clockgating level, it does enable clockgating using the clockgating values initially set by the vbios (which should be safe to use). This introduces two therm helpers for controlling basic clockgating: nvkm_therm_clkgate_enable() - enables clockgating through CG_CTRL, done after initializing the GPU fully nvkm_therm_clkgate_fini() - prepares clockgating for suspend or driver unload A lot of this code was originally going to be based off of fermi; however it turns out that while Fermi's the first line of GPUs that introduced this kind of power saving, Fermi requires more fine tuned control of the CG_CTRL registers from the driver while reclocking that we don't entirely understand yet. For the simple parts we will be sharing with Fermi for certain however, we at least add those into a new subdev/therm/gf100.h header. Signed-off-by: Lyude Paul <lyude@redhat.com> Reviewed-by: Martin Peres <martin.peres@free.fr> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2018-02-02drm/nouveau/kms/nv50: fix handling of gamma since atomic conversionBen Skeggs1-53/+109
We've still been directly using the legacy crtc gamma_set() hook even after conversion to atomic modesetting. For userspace clients this was fine, however, fbcon will use the atomic property when it's running on an atomic driver, which means we miss its colormap updates - which is particularly bad for 8bpp framebuffers! This commit converts the driver to use the atomic property + the helper function implementing the legacy hook on top of atomic. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=80675 Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2018-02-02drm/nouveau/kms/nv50: use INTERPOLATE_257_UNITY_RANGE LUT on newer chipsetsBen Skeggs1-4/+4
For some reason forgotten by history, we've been using a 1025-entry LUT mode, and sparsely filling it with the 256-entry LUT we're handed. Until we land support for the full atomic colour management properties, this commit switches to using the 257-entry mode to fix colour mapping with depth 30 framebuffers. Reported-by: Ilia Mirkin <imirkin@alum.mit.edu> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2018-02-02drm/nouveau/kms/nv50: use "low res" lut for indexed modeIlia Mirkin1-2/+4
This is what was done prior to the big refactor in kernel 3.8, and what was done by xf86-video-nv. Experimentally, it seems like there's some sort of issue with the high-res lut to be used there. Tested on G92. This ends up mattering because fbcon/fbdev chooses the C8 fb format for low-vram systems, which can occur with some IGP-based configurations with little "stolen" vram. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=80675 Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2018-02-02drm/nouveau/kms/nv50: prepare for double-buffered LUTsBen Skeggs2-23/+15
We need to double-buffer LUTs to handle their update atomically. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2018-02-02drm/nouveau/bo: add helper functions for handling pinned+mapped buffersBen Skeggs1-0/+28
This is a common, awkward sequence. Let's wrap it up! Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2018-02-02drm/nouveau/fbcon: add module parameter to select bits-per-pixelBen Skeggs1-8/+14
Useful for debugging. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2018-02-02drm/nouveau/secboot/gp108: implement on top of acr_r370Ben Skeggs7-1/+78
Signed-off-by: Ben Skeggs <bskeggs@redhat.com> Reviewed-by: Gourav Samaiya <gsamaiya@nvidia.com>
2018-02-02drm/nouveau/secboot/r370: implement support for booting LS SEC2 ucodeBen Skeggs1-0/+39
Signed-off-by: Ben Skeggs <bskeggs@redhat.com> Reviewed-by: Gourav Samaiya <gsamaiya@nvidia.com>
2018-02-02drm/nouveau/secboot/r370: move a bunch of r375 stuff to a new implementationBen Skeggs5-86/+163
It's entirely possibly that the other r375 code is relevant to r370 too, but I've not confirmed this, so I'll leave it where it is for now. NVIDIA's copyright headers maintained, as it's still all their code. Signed-off-by: Ben Skeggs <bskeggs@redhat.com> Reviewed-by: Gourav Samaiya <gsamaiya@nvidia.com>
2018-02-02drm/nouveau: nouveau: use correct string lengthArnd Bergmann1-3/+3
gcc-8 reports drivers/gpu/drm/nouveau/nvkm/engine/pm/base.c: In function 'nvkm_perfmon_mthd': include/linux/string.h:265:9: error: '__builtin_strncpy' specified bound 64 equals destination size [-Werror=stringop-truncation] We need one less byte or call strlcpy() to make it a nul-terminated string. Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2018-02-02drm/nouveau/drm/nouveau/mmu: fix odd_ptr_err.cocci warningsChristoph Böhmwalder1-1/+2
The kbuild test bot complained about a new coccinelle warning nearby, which sparked a discussion about the assignment to 'memory' inside of the conditional expression. See Link below for the original post. Fix the assignment to silence the coccinelle warning and also make the code look a little nicer. Link: https://lists.freedesktop.org/archives/nouveau/2017-November/029242.html Signed-off-by: Christoph Böhmwalder <christoph@boehmwalder.at> Signed-off-by: Ben Skeggs <bskeggs@redhat.com> Reviewed-by: Karol Herbst <kherbst@redhat.com>
2018-02-02drm/nouveau/pmu/fuc: don't use movw directly anymoreKarol Herbst4-1292/+1292
Fixes failure to compile with recent envyas as a result of the 'movw' alias being removed for v5. A bit of history: v3 only has a 16-bit sign-extended immediate mov op. In order to set the high bits, there's a separate 'sethi' op. envyas validates that the value passed to mov(imm) is between -0x8000 and 0x7fff. In order to simplify macros that load both the low and high word, a 'movw' alias was added which takes an unsigned 16-bit immediate. However the actual hardware op still sign extends. v5 has a full 32-bit immediate mov op. The v3 16-bit immediate mov op is gone (loads 0 into the dst reg). However due to a bug in envyas, the movw alias still existed, and selected the no-longer-present v3 16-bit immediate mov op. As a result usage of movw on v5 is the same as mov with a 0x0 argument. The proper fix throughout is to only ever use the 'movw' alias in combination with 'sethi'. Anything else should get the sign-extended validation to ensure that the intended value ends up in the destination register. Changes in fuc3 binaries is the result of a different encoding being selected for a mov with an 8-bit value. v2: added commit message written by Ilia, thanks for that! v3: messed up rebasing, now it should apply Signed-off-by: Karol Herbst <kherbst@redhat.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2018-02-01drm/i915/ppgtt: Pin page directories before allocationChris Wilson1-4/+10
Commit e2b763caa6eb ("drm/i915: Remove bitmap tracking for used-pdpes") believed that because it did not insert its freshly allocated page directory into the pd tree, it was safe from the shrinker. I failed to heed the lesson learnt from commit dd19674bacba ("drm/i915: Remove bitmap tracking for used-ptes") that we need to pin all the levels in the tree before hitting the shrinker or else the shrinker may free an upper layer as we proceed to allocate the tree. Thus leaving dangling pointers everywhere and a GPF should we hit direct reclaim at just the wrong moment. CPU: 0 PID: 7374 Comm: chromium Tainted: P O 4.14.13-1-ARCH #1 Hardware name: Apple Inc. MacBookPro12,1/Mac-E43C1C25D4880AD6, BIOS MBP121.88Z.0167.B33.1706181928 06/18/2017 task: ffff994f696c2c40 task.stack: ffffb1a789d4c000 RIP: 0010:gen8_ppgtt_set_pde.isra.40+0x48/0x70 [i915] RSP: 0018:ffffb1a789d4f940 EFLAGS: 00010206 RAX: 81c1788cc4f68138 RBX: ffff994f54db8000 RCX: ffff994f696c2c40 RDX: 000000023bc73003 RSI: ffff994d598b6b80 RDI: ffff994f54db8000 RBP: ffff994d598b6b80 R08: 0000000000000000 R09: 0000000000000000 R10: ffffb1a789d4f550 R11: ffff994eaf3c3208 R12: 0000000000000027 R13: 0000000000005000 R14: 0000000004e8f000 R15: ffff994f54dba000 FS: 00007f585886aa00(0000) GS:ffff994faec00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00000000004ac8e8 CR3: 00000002552c8004 CR4: 00000000003606f0 Call Trace: gen8_ppgtt_alloc_pdp+0x178/0x320 [i915] gen8_ppgtt_alloc_4lvl+0x5f/0x150 [i915] ppgtt_bind_vma+0x30/0x70 [i915] i915_vma_bind+0x68/0xd0 [i915] __i915_vma_do_pin+0x2d6/0x3a0 [i915] eb_lookup_vmas+0x7a2/0xb50 [i915] i915_gem_do_execbuffer+0x4d7/0x10e0 [i915] ? sock_wfree+0x34/0x60 ? unix_stream_read_generic+0x1f9/0x7e0 ? import_iovec+0x37/0xd0 ? i915_gem_execbuffer2+0x5d/0x390 [i915] i915_gem_execbuffer2+0x1b7/0x390 [i915] ? i915_gem_execbuffer+0x2d0/0x2d0 [i915] drm_ioctl_kernel+0x59/0xb0 [drm] drm_ioctl+0x2d5/0x370 [drm] ? i915_gem_execbuffer+0x2d0/0x2d0 [i915] ? __seccomp_filter+0x3b/0x260 do_vfs_ioctl+0xa1/0x610 ? syscall_trace_enter+0xdb/0x2b0 SyS_ioctl+0x74/0x80 do_syscall_64+0x55/0x110 entry_SYSCALL64_slow_path+0x25/0x25 RIP: 0033:0x7f584fa82d27 RSP: 002b:00007ffee14a7828 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 RAX: ffffffffffffffda RBX: 000003b0126a1030 RCX: 00007f584fa82d27 RDX: 00007ffee14a7870 RSI: 0000000040406469 RDI: 0000000000000080 RBP: 00007ffee14a7870 R08: 0000000000000002 R09: 0000000000000077 R10: 00007f5839f2b780 R11: 0000000000000246 R12: 0000000040406469 R13: 0000000000000080 R14: 00007f5842b00040 R15: 0000000000000000 Code: 01 00 83 81 58 0a 00 00 01 48 2b 05 13 9d fd c9 48 c1 f8 06 48 c1 e0 0c 48 8d 04 d0 48 8b 56 08 48 03 05 0c 9d fd c9 48 83 ca 03 <48> 89 10 83 a9 58 0a 00 00 01 65 ff 0d 37 03 fb 3e 74 02 f3 c3 RIP: gen8_ppgtt_set_pde.isra.40+0x48/0x70 [i915] RSP: ffffb1a789d4f940 Reported-by: Eric Blau <eblau@eblau.com> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=104773 Fixes: e2b763caa6eb ("drm/i915: Remove bitmap tracking for used-pdpes") References: dd19674bacba ("drm/i915: Remove bitmap tracking for used-ptes") Testcase: igt/drv_selftest/live_gtt (igt_ppgtt_shrink_boom) Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Matthew Auld <matthew.auld@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180131214440.7141-1-chris@chris-wilson.co.uk Reviewed-by: Matthew Auld <matthew.auld@intel.com> (cherry picked from commit b715a2f0c7714a399e7f8e951cc8dea9cd4eeb4b) Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2018-02-01drm/i915: Always run hangcheck while the GPU is busyChris Wilson4-21/+6
Previously, we relied on only running the hangcheck while somebody was waiting on the GPU, in order to minimise the amount of time hangcheck had to run. (If nobody was watching the GPU, nobody would notice if the GPU wasn't responding -- eventually somebody would care and so kick hangcheck into action.) However, this falls apart from around commit 4680816be336 ("drm/i915: Wait first for submission, before waiting for request completion"), as not all waiters declare themselves to hangcheck and so we could switch off hangcheck and miss GPU hangs even when waiting under the struct_mutex. If we enable hangcheck from the first request submission, and let it run until the GPU is idle again, we forgo all the complexity involved with only enabling around waiters. We just have to remember to be careful that we do not declare a GPU hang when idly waiting for the next request to be come ready, as we will run hangcheck continuously even when the engines are stalled waiting for external events. This should be true already as we should only be tracking requests submitted to hardware for execution as an indicator that the engine is busy. Fixes: 4680816be336 ("drm/i915: Wait first for submission, before waiting for request completion" Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=104840 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> Link: https://patchwork.freedesktop.org/patch/msgid/20180129144104.3921-1-chris@chris-wilson.co.uk Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com> (cherry picked from commit 889230489b6b138ba97ba2f13fc9644a3d16d0d2) Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2018-02-01Revert "drm/i915: mark all device info struct with __initconst"Lionel Landwerlin1-47/+47
This reverts commit 5b54eddd3920e9f6f1a6d972454baf350cbae77e. Conflicts: drivers/gpu/drm/i915/i915_pci.c Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=104805 Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Fixes: 5b54eddd3920 ("drm/i915: mark all device info struct with __initconst") Link: https://patchwork.freedesktop.org/patch/msgid/20180129083346.29173-1-lionel.g.landwerlin@intel.com (cherry picked from commit 5db47e37b38755c5e26e6b8fbc1a32ce73495940) Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2018-02-01drm/i915/edp: Do not do link training fallback or prune modes on EDPManasi Navare1-9/+17
In case of eDP because the panel has a fixed mode, the link rate and lane count at which it is trained corresponds to the link BW required to support the native resolution of the panel. In case of panles with lower resolutions where fewer lanes are hooked up internally, that number is reflected in the MAX_LANE_COUNT DPCD register of the panel. So it is pointless to fallback to lower link rate/lane count in case of link training failure on eDP connector since the lower link BW will not support the native resolution of the panel and we cannot prune the preferred mode on the eDP connector. In case of Link training failure on the eDP panel, something is wrong in the HW internally and hence driver errors out with a loud and clear DRM_ERROR message. v2: * Fix the DEBUG_ERROR and add {} in else (Ville Syrjala) Cc: Clinton Taylor <clinton.a.taylor@intel.com> Cc: Jim Bride <jim.bride@linux.intel.com> Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Ville Syrjala <ville.syrjala@linux.intel.com> Cc: Dave Airlie <airlied@redhat.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Manasi Navare <manasi.d.navare@intel.com> Reviewed-by: Ville Syrjala <ville.syrjala@linux.intel.com> Reference: https://bugs.freedesktop.org/show_bug.cgi?id=103369 Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/1507835618-23051-1-git-send-email-manasi.d.navare@intel.com (cherry picked from commit c0cfb10d9e1de490e36d3b9d4228c0ea0ca30677) Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2018-02-01drm/i915: Check for fused or unused pipesMika Kahola1-1/+1
We may have fused or unused pipes in our system. Let's check that the pipe in question is within limits of accessible pipes. In case, that we are not able to access the pipe, we return early with a warning. v2: Rephrasing of the commit message (Jani) Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=103206 Reported-by: Thomas Gleixner <tglx@linutronix.de> Tested-by: Jaswinder Singh Rajput <jaswinder@perfectintelligent.com> Suggested-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Mika Kahola <mika.kahola@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/1513584243-12607-1-git-send-email-mika.kahola@intel.com (cherry picked from commit 0b7029b7e43fda1304c181a3ade0b429b9edcd9d) Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: <stable@vger.kernel.org> # v4.10+
2018-02-01drm/i915: Protect WC stash allocation against direct reclaimChris Wilson1-7/+25
As we attempt to allocate pages for use in a new WC stash, direct reclaim may run underneath us and fill up the WC stash. We have to be careful then not to overflow the pvec. Fixes: 66df1014efba ("drm/i915: Keep a small stash of preallocated WC pages") Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=103109 Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Matthew Auld <matthew.auld@intel.com> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Reviewed-by: Matthew Auld <matthew.auld@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180121173143.17090-1-chris@chris-wilson.co.uk (cherry picked from commit 073cd7816685ac77c6d8b4d321a5586c9177b76a) Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2018-02-01drm/i915: Only attempt to scan the requested number of shrinker slabsChris Wilson1-2/+2
Since commit 4e773c3a8a69 ("drm/i915: Wire up shrinkctl->nr_scanned"), we track the number of objects we scan and do not wish to exceed that as it will overly penalise our own slabs under mempressure. Given that we now know the target number of objects to scan, use that as our guide for deciding to shrink as opposed to the number of objects we manage to shrink (which doesn't correspond to the numbers we report to shrinkctl). Fixes: 4e773c3a8a69 ("drm/i915: Wire up shrinkctl->nr_scanned") Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180115212455.24046-2-chris@chris-wilson.co.uk Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> (cherry picked from commit 29d384e34c55d696cf37bd4159e05f4b14d45da0) Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2018-02-01drm/i915: Always call to intel_display_set_init_power() in resume_early.Maarten Lankhorst1-0/+2
intel_power_domains_init_hw() calls set_init_power, but when using runtime power management this call is skipped. This prevents hw readout from taking place. Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=104172 Link: https://patchwork.freedesktop.org/patch/msgid/20180116155324.75120-1-maarten.lankhorst@linux.intel.com Fixes: bc87229f323e ("drm/i915/skl: enable PC9/10 power states during suspend-to-idle") Cc: Nivedita Swaminathan <nivedita.swaminathan@intel.com> Cc: Imre Deak <imre.deak@intel.com> Cc: Patrik Jakobsson <patrik.jakobsson@linux.intel.com> Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: <stable@vger.kernel.org> # v4.5+ Reviewed-by: Imre Deak <imre.deak@intel.com> (cherry picked from commit ac25dfed15d470d7f23dd817e965b54aa3f94a1e) Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2018-02-01drm/i915/gvt: cancel scheduler timer when no vGPU existsZhenyu Wang1-0/+7
Stop gvt scheduler timer if no vGPU exists, otherwise it keeps gvt service thread busy to handle request schedule event but no actual schedule activity required. Reviewed-by: Zhi Wang <zhi.a.wang@intel.com> Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2018-02-01drm/i915/gvt: cancel virtual vblank timer when no vGPU existsZhenyu Wang1-0/+2
Stop irq timer for virtual vblank timer emulation if no vGPU exists, otherwise it will keep gvt service thread busy to handle virtual vblank but no use. Reviewed-by: Zhi Wang <zhi.a.wang@intel.com> Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2018-02-01drm/i915/gvt: Keep obj->dma_buf link NULL during exportingTina Zhang1-1/+0
According to commit (319c933c71f3dbdb2b3274d1634d3494c70efa06) Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Thu Aug 15 00:02:46 2013 +0200 drm/prime: proper locking+refcounting for obj->dma_buf link obj->dma_buf link should be reinstated at import time. Gvt-g dma-buf buffer exposeing might be simpler, as there won't be much racing during Gvt-g dma-buf exposing. In other words, Gvt-g dma-buf exposing can guarantee exposing happens before gem close ioctl, and Gvt-g is the only exporter of the guest framebuffer. But following the drm prime scheme can give Gvt-g a chance to increase a dma-buf reference count during importing. Otherwise, we have to increase the reference during exposing, which will break the case that the only reference userspace has held was through the dma-buf fd and the reference count is one. Signed-off-by: Tina Zhang <tina.zhang@intel.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Zhenyu Wang <zhenyuw@linux.intel.com> Cc: Zhi Wang <zhi.a.wang@intel.com> Cc: Hang Yuan <hang.yuan@intel.com> Cc: Gerd Hoffmann <kraxel@redhat.com> Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2018-02-01drm/i915/pmu: Reconstruct active state on starting busy-statsChris Wilson1-1/+15
We have a hole in our busy-stat accounting if the pmu is enabled during a long running batch, the pmu will not start accumulating busy-time until the next context switch. This then fails tests that are only sampling a single batch. v2: Count each active port just once (context in/out events are only on the first and last assignment to a port). v3: Avoid hardcoding knowledge of 2 submission ports Fixes: 30e17b7847f5 ("drm/i915: Engine busy time tracking") Testcase: igt/perf_pmu/busy-start Testcase: igt/perf_pmu/busy-double-start 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/20180111073031.14614-1-chris@chris-wilson.co.uk (cherry picked from commit 4900727d35bb20028f9bd83146ec4bf78afffe30) Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2018-02-01drm/i915: Stop getting the fault address from RING_FAULT_REGOscar Mateo2-2/+15
This register does not contain it. Instead, we have to look into FAULT_TLB_DATA0 & 1 (where, by the way, we can also get the address space). v2: Right formatting v3: - Use 12 (as per the register format) instead of PAGE_SIZE (Chris) - s/BITS_44_TO_47/HIGHBITS (Chris) - Right formatting, this time for real Fixes: b03ec3d67ab8 ("drm/i915: There is only one fault register from GEN8 onwards") Signed-off-by: Oscar Mateo <oscar.mateo@intel.com> Cc: Michel Thierry <michel.thierry@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/1513982329-32191-1-git-send-email-oscar.mateo@intel.com Reviewed-by: Michel Thierry <michel.thierry@intel.com> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> (cherry picked from commit 5a3f58dfd1420347be838546e00a4a9e847bda30) Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2018-02-01drm/i915/guc: Add uc_fini_wq in gem_init unwind pathSagar Arun Kamble2-2/+2
While moving code around for solving lockdep issue for GuC log relay, spotted that uc_fini_wq is not being called in failure path in gem_init. Missed in the below commit. Add it. v2: Removed GEM_BUG_ON(!HAS_GUC()) from intel_uc_fini_wq as init happens only based on enable_guc module parameter and does not consider has_guc capability. (Michal) Signed-off-by: Sagar Arun Kamble <sagar.a.kamble@intel.com> Fixes: 3176ff49bc3e ("drm/i915/guc: Move GuC workqueue allocations outside of the mutex") Cc: Michał Winiarski <michal.winiarski@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Michał Winiarski <michal.winiarski@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/1515588857-10283-1-git-send-email-sagar.a.kamble@intel.com Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> (cherry picked from commit da943b5ab071584fcb9cfa896dc8c643d376f362) Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2018-02-01drm/i915: Fix using BIT_ULL() vs. BIT() for power domain masksImre Deak1-3/+3
The power domain masks are 64 bit wide, so we need BIT_ULL() when setting bits in them, these ones were missed during converting from 32 to 64 bit masks. All 3 enums are <32 atm, so this didn't cause a real problem. Fixes: d8fc70b7367b ("drm/i915: Make power domain masks 64 bit long") Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Reported-by: Fengguang Wu <fengguang.wu@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180109122040.19425-1-imre.deak@intel.com (cherry picked from commit 17bd6e66d8f677b1b250d098097fbed6e70175ef) Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2018-02-01drm/i915: Try EDID bitbanging on HDMI after failed readStefan Brüns1-3/+11
The ACK/NACK implementation as found in e.g. the G965 has the falling clock edge and the release of the data line after the ACK for the received byte happen at the same time. This is conformant with the I2C specification, which allows a zero hold time, see footnote [3]: "A device must internally provide a hold time of at least 300 ns for the SDA signal (with respect to the V IH(min) of the SCL signal) to bridge the undefined region of the falling edge of SCL." Some HDMI-to-VGA converters apparently fail to adhere to this requirement and latch SDA at the falling clock edge, so instead of an ACK sometimes a NACK is read and the slave (i.e. the EDID ROM) ends the transfer. The bitbanging releases the data line for the ACK only 1/4 bit time after the falling clock edge, so a slave will see the correct value no matter if it samples at the rising or the falling clock edge or in the center. Fallback to bitbanging is already done for the CRT connector. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=92685 Signed-off-by: Stefan Brüns <stefan.bruens@rwth-aachen.de> Cc: stable@vger.kernel.org Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/a39f080b-81a5-4c93-b3f7-7cb0a58daca3@rwthex-w2-a.rwth-ad.de (cherry picked from commit cfb926e148e99acc02351d72e8b85e32b5f786ef) Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2018-02-01drm/i915/glk: Disable Guc and HuC on GLKAnusha Srivatsa2-20/+0
Since the firmwares are not yet released to public repo, disable them on Geminilake. v2: Remove the firmware versions (Michal) v3: Remove unwanted defines (Rodrigo) Correct commit message (Michal) Cc: Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: <stable@vger.kernel.org> Signed-off-by: Anusha Srivatsa <anusha.srivatsa@intel.com> Fixes: 90f192c8241e ("drm/i915/GuC/GLK: Load GuC on GLK") Fixes: db5ba0d8931e ("drm/i915/GLK/HuC: Load HuC on GLK") Reviewed-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/1515006225-13003-1-git-send-email-anusha.srivatsa@intel.com (cherry picked from commit a76050a4837860fcadb6ca11d69d41e08f4090d8) Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2018-02-01drm/i915/gvt: Do not use I915_NUM_ENGINES to iterate over the mocs regs arrayMichel Thierry1-1/+1
The mocs reg array is defined locally but then we iterate over its elements using I915_NUM_ENGINES. There is no 'hard' connection between I915_NUM_ENGINES and the regs array and there will be problems if either of them increases. Use the size of the mocs reg array instead to safely iterate over it. Signed-off-by: Michel Thierry <michel.thierry@intel.com> Cc: Weinan Li <weinan.z.li@intel.com> Cc: Zhenyu Wang <zhenyuw@linux.intel.com> Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2018-02-01drm/i915/gvt: validate gfn before set shadow page entryHang Yuan4-5/+53
GVT may receive partial write on one guest PTE update. Validate gfn not to translate incomplete gfn. This avoids some unnecessary error messages incurred by the incomplete gfn translating. Also fix the bug that the whole PPGTT shadow page update is aborted on any invalid gfn entry. gfn validation relys on hypervisor's help. Add one MPT module function to provide the function. Signed-off-by: Hang Yuan <hang.yuan@intel.com> Reviewed-by: Zhi Wang <zhi.a.wang@intel.com> Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2018-02-01drm/i915/gvt: add PLANE_KEYMAX regs to mmio track listPei Zhang1-0/+3
Running 4.15 Linux kernel in VM will cause host GVT reports 'untrack mmio 0x701a0' errror, which identifies the PLANE_KEYMAX registers. Add them to track list. v2: rebase to latest staging code. Signed-off-by: Pei Zhang <pei.zhang@intel.com> Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2018-02-01drm/i915/gvt: Fix gen8/9_render_mmio_list[0] don't take effectXiong Zhang1-4/+4
while(mmio++) increase mmio to next, mmio[0] never take effect in while loop. This patch change while to for and fix the above issue. v2: Correct Fixes format.(Zhenyu) v3: Rebase to latest staging.(Zhenyu) Fixes: 83164886e455("drm/i915/gvt: Select appropriate mmio list at initialization time") Signed-off-by: Xiong Zhang <xiong.y.zhang@intel.com> Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
generated by cgit v1.2.3 (git 2.39.1) at 2024-06-22 14:16:04 +0000