- 03 Jan, 2018 11 commits
-
-
Chris Wilson authored
We should never insert the invalid seqno into the wait tree, so assert we do not. Signed-off-by:
Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by:
Michał Winiarski <michal.winiarski@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180102192500.20364-1-chris@chris-wilson.co.uk
-
Sujaritha Sundaresan authored
Instead of returning -EINVAL, GEM_BUG_ON when GuC reset is invoked for platforms not supporting as we don't expect to invoke it. v2: re-wording commit message and subject (Sagar) Signed-off-by:
Sujaritha Sundaresan <sujaritha.sundaresan@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: Sagar Arun Kamble <sagar.a.kamble@intel.com> Reviewed-by:
Sagar Arun Kamble <sagar.a.kamble@intel.com> Signed-off-by:
-
Sujaritha Sundaresan authored
The Additional Data Struct (ADS) contains objects that are required by GuC post FW load and are not necessarily submission-only. Even with submission disabled we may require something inside the ADS, so it makes more sense for them to be always created. Similarly, we need to access GuC logs and even if GuC submission is disabled, to debug issues with GuC loading or with whatever we're using GuC for. v2: re-wording commit message (Sagar) Signed-off-by:
-
Chris Wilson authored
After staring at the list_for_each_safe macros for a bit, our current invocation of list_safe_reset_next in execlists_schedule() simply reduces to list_for_each. Signed-off-by:
-
Chris Wilson authored
The dependency chain must be an acyclic graph. This is checked by the swfence, but for sanity, also do a simple check that we do not corrupt our list iteration in execlists_schedule() by a shallow dependency cycle. Signed-off-by:
-
Chris Wilson authored
Back up our comment that all signalers should have been signaled before we ourselves were retired with an assert to that effect. Signed-off-by:
-
Chris Wilson authored
To modify the global seqno may require rewriting a few registers, which requires us to hold the rpm wakeref. We must therefore take it around the call to i915_gem_set_global_seqno() in debugfs, on behalf of the user. Signed-off-by:
-
Chris Wilson authored
Move the register settings for enabling execlists into its own function for clarity. Signed-off-by:
-
Chris Wilson authored
Currently, we record the elsp register offset inside init-hw but we only need to do it once during engine setup (after we know the mmio iomapping). Signed-off-by:
-
Chris Wilson authored
Move the clearing of the CS-interrupt into the engine reset phase, before the current init-hw phase. This helps clarify that we clear the pending interrupts prior to any restarting of the execlists. Signed-off-by:
-
Chris Wilson authored
i915_gem_request_assign() is not used since commit 77f0d0e9 ("drm/i915/execlists: Pack the count into the low bits of the port.request"), so remove the defunct code References: 77f0d0e9 ("drm/i915/execlists: Pack the count into the low bits of the port.request") Signed-off-by:
Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180102151235.3949-1-chris@chris-wilson.co.uk
-
- 02 Jan, 2018 2 commits
-
-
Chris Wilson authored
In the selftests, we don't want to force an oom and would rather ENOMEM be reported. In this case, we would rather the allocation for the random array to fail. Signed-off-by:
Matthew Auld <matthew.auld@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20171223110407.21402-2-chris@chris-wilson.co.uk
-
Chris Wilson authored
Reduce the number of GGTT PTE operations to speed the test up, but we reduce the likelihood of spotting a coherency error in those operations. However, Broxton is sporadically timing on this test, presumably because its GGTT operations are all uncached. Signed-off-by:
-
- 28 Dec, 2017 2 commits
-
-
C, Ramalingam authored
Existing debugfs entry i915_drrs_status is updated with whether PSR is the cause for DRRS disabled state. [v2]: Dropped the module parameter details as ctl moved from module parameter to debugfs. [Rodrigo] [v3]: Crtc ID information is dropped as there is no immediate usecase. [Rodrigo]. Signed-off-by:C, Ramalingam <ramalingam.c@intel.com> Reviewed-by:
-
C, Ramalingam authored
Debugfs called i915_drrs_ctl is added to enable and disable the eDP DRRS. Writing 0 will disable the feature, whereas non-zero will enable the feature. Possibility of disabling the DRRS, enables the testing of the frontbuffer tracking based features (FBC, DRRS and PSR) as standalone or any combination of the set. [v2]: ctl interface is moved from module parameter to debugfs [Rodrigo] Signed-off-by:
-
- 23 Dec, 2017 1 commit
-
-
Hans de Goede authored
At least on the Chuwi Vi8 (non pro/plus) the LCD panel will show an image shifted aprox. 20% to the left (with wraparound) and sometimes also wrong colors, showing that the panel controller is starting with sampling the datastream somewhere mid-line. This happens after the first blanking and re-init of the panel. After looking at drm.debug output I noticed that initially we inherit the cdclk of 333333 KHz set by the GOP, but after the re-init we picked 266667 KHz, which turns out to be the cause of this problem, a quick hack to hard code the cdclk to 333333 KHz makes the problem go away. I've tested this on various Bay Trail devices, to make sure this not does cause regressions on other devices and the higher cdclk does not cause any problems on the following devices: -GP-electronic T701 1024x600 333333 KHz cdclk after this patch -PEAQ C1010 1920x1200 333333 KHz cdclk after this patch -PoV mobii-wintab-800w 800x1280 333333 KHz cdclk after this patch -Asus Transformer-T100TA 1368x768 320000 KHz cdclk after this patch Also interesting wrt this is the comment in vlv_calc_cdclk about the existing workaround to avoid 200 Mhz as clock because that causes issues in some cases. This commit extends the "do not use 200 Mhz" workaround with an extra check to require atleast 320000 KHz (avoiding 266667 KHz) when a DSI panel is active. Changes in v2: -Change the commit message and the code comment to not treat the GOP as a reference, the GOP should not be treated as a reference Acked-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by:
Hans de Goede <hdegoede@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20171220105017.11259-1-hdegoede@redhat.com
-
- 22 Dec, 2017 23 commits
-
-
Lucas De Marchi authored
Display WA #1183 was recently added to workaround "Failures when enabling DPLL0 with eDP link rate 2.16 or 4.32 GHz and CD clock frequency 308.57 or 617.14 MHz (CDCLK_CTL CD Frequency Select 10b or 11b) used in this enabling or in previous enabling." This workaround was designed to minimize the impact only to save the bad case with that link rates. But HW engineers indicated that it should be safe to apply broadly, although they were expecting the DPLL0 link rate to be unchanged on runtime. We need to cover 2 cases: when we are in fact enabling DPLL0 and when we are just changing the frequency with small differences. This is based on previous patch by Rodrigo Vivi with suggestions from Ville Syrjälä. Cc: Arthur J Runyan <arthur.j.runyan@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: stable@vger.kernel.org Signed-off-by:
Lucas De Marchi <lucas.demarchi@intel.com> Reviewed-by:
-
Rodrigo Vivi authored
Signed-off-by: -
Chris Wilson authored
Looking at a CI failure with an ominous line of [ 362.550715] hangcheck current seqno ffffff6b, last ffffff8c, hangcheck ffffff6b [6016 ms], inflight 118 with no apparent cause for the seqno to be negative, left me wondering if someone had scribbled over the HWSP. So include the HWSP in the engine dump to see if there are more signs of random scribbling. v2: Fix row pointer, i is now incremented by 8 so doesn't need scaling by 8, and we don't need to keep volatile here as the status_page isn't marked up as volatile itself. v3: Use hexdump, with suppression of identical lines. (Tvrtko) Which results in HWSP: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 * 00000040 00000001 00000000 00000018 00000002 00000001 00000000 00000018 00000000 00000060 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000003 00000080 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 * 000000c0 00000002 00000000 00000000 00000000 00000000 00000000 00000000 00000000 000000e0 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 * instead of 128 lines of mostly 0s. v4: Tidy up the locals Signed-off-by:Tvrtko Ursulin <tvrtko.ursulin@intel.com>
-
Chris Wilson authored
We should only attempt to remove requests from the execution queue that are on the execution queue. These are the requests that have been assigned a global_seqno, so we can assert that we only attempt to remove requests with a nonzero global_seqno. Afterwards we assert that we remove them in order, i.e. the global_seqno matches the engine's seqno, but that leaves a small loophole for an unattached request on an unused engine. We can then make the same assertion on queuing the request to the execution engine, it must have a zero global_seqno or else we are queuing the same request twice. Signed-off-by:
-
Chris Wilson authored
We already emit a GEM_TRACE for when we start preemption, but we lack one to show when the preemption is completed and we return to the regular queue. This is to continue the investigation into the mysterious <0>[ 197.854177] <idle>-0 1..s1 197837017us : execlists_submission_tasklet: rcs0 cs-irq head=0 [0], tail=0 [0] <0>[ 197.854209] drv_self-6008 2.... 197837390us : reset_common_ring: rcs0 seqno=15515 <0>[ 197.854240] drv_self-6008 2.... 197837415us : reset_common_ring: bcs0 seqno=0 <0>[ 197.854270] drv_self-6008 2.... 197837443us : reset_common_ring: vcs0 seqno=0 <0>[ 197.854300] drv_self-6008 2.... 197837463us : reset_common_ring: vcs1 seqno=0 <0>[ 197.854330] drv_self-6008 2.... 197837482us : reset_common_ring: vecs0 seqno=0 <0>[ 197.854360] ksoftirq-23 2..s. 197838341us : execlists_submission_tasklet: bcs0 in[0]: ctx=0.1, seqno=1dce7 <0>[ 197.854392] <idle>-0 1..s1 197838347us : execlists_submission_tasklet: bcs0 cs-irq head=0 [0], tail=0 [0] <0>[ 197.854423] ksoftirq-23 2..s. 197838354us : execlists_submission_tasklet: vcs0 in[0]: ctx=0.1, seqno=1d027 <0>[ 197.854456] ksoftirq-23 2.Ns. 197838361us : execlists_submission_tasklet: vcs1 in[0]: ctx=0.1, seqno=1e738 <0>[ 197.854488] ksoftirq-23 2.Ns. 197838366us : execlists_submission_tasklet: vecs0 in[0]: ctx=0.1, seqno=235aa <0>[ 197.854520] ksoftirq-23 2.Ns. 197838376us : execlists_submission_tasklet: rcs0 in[0]: ctx=0.1, seqno=15518 <0>[ 197.854552] <idle>-0 1..s1 197853285us : execlists_submission_tasklet: rcs0 cs-irq head=0 [0], tail=7 [7] <0>[ 197.854584] <idle>-0 1..s1 197853285us : execlists_submission_tasklet: rcs0 csb[1]: status=0x00000018:0x00000000 <0>[ 197.854616] <idle>-0 1..s1 197853286us : execlists_submission_tasklet: rcs0 out[0]: ctx=0.0, seqno=0 Signed-off-by:
-
https://github.com/intel/gvt-linuxRodrigo Vivi authored
gvt-next-2017-12-22: - more mmio switch optimization (Weinan) - cleanup i915_reg_t vs. offset usage (Zhenyu) - move write protect handler out of mmio handler (Zhenyu) Signed-off-by:
-
Ville Syrjälä authored
We have plenty of global registers and whatnot programmed without any further locking by the modeset code. Currently non-bocking modesets are allowed to execute in parallel which could corrupt said registers. To avoid the problem let's run all non-blocking modesets on an ordered workqueue. We still put page flips etc. to system_unbound_wq allowing page flips on one pipe to execute in parallel with page flips or a modeset on a another pipe (assuming no known state is shared between them, at which point they would have been added to the same atomic commit and serialized that way). Blocking modesets are already serialized with each other by connection_mutex, and thus are safe. To serialize them with non-blocking modesets we just flush the workqueue before executing blocking modesets. Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Fixes: 94f05024 ("drm/i915: nonblocking commit") Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by:
Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
-
Ville Syrjälä authored
Gen9+ need to disable GMBUS clock gating when doing multi part transfers. Otherwise clock gating will kick in when GMBUS is in the WAIT state and presumably that will corrupt the transfer. This is documented as Display WA #0868. Apparently older hardware doesn't allow clock gating in the WAIT state and thus are unaffected by this problem. v2: Limit the PCH w/a to gen9 and gen10 only (DK) Actually change it to check the PCH type instead since it's the PCH that actually contains the GMBUS hardware Signed-off-by: -
Ville Syrjälä authored
Give a proper name for the GMBUS clock gating disable bit on PNV, and rename intel_i2c_quirk_set() to pnv_gmbus_clock_gating() for clarity. Signed-off-by:
-
Ville Syrjälä authored
GMBUS lives in PG1, so no need to power up PG2. We do want to prevent the DMC from making a mess of things though, so add GMBUS to the DC off power well. Signed-off-by:
Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
-
Ville Syrjälä authored
Prevent the DMC from destroying GMBUS transfers on GLK. GMBUS lives in PG1 so DC off is all we need. Cc: stable@vger.kernel.org Signed-off-by:
-
Changbin Du authored
Our QA reported a problem caused by movntdqa instructions. Currently, the KVM hypervisor doesn't support VEX-prefix instructions emulation. If users passthrough a GPU to guest with vfio option 'x-no-mmap=on', then all access to the BARs will be trapped and emulated. The KVM hypervisor would raise an inertal error to qemu which cause the guest killed. (Since 'movntdqa' ins is not supported.) This patch try not to enable movntdqa optimization if the driver is running in hypervisor guest. Signed-off-by:
Changbin Du <changbin.du@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/1513924309-3113-1-git-send-email-changbin.du@intel.comReviewed-by:
-
Michal Wajdeczko authored
We are dumping device info separately for sw_only and runtime part but to simplify the code we can also do it from one place once we complete driver load. v2: use dedicated welcome function (Chris) Signed-off-by:
Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20171221185334.17396-8-michal.wajdeczko@intel.comReviewed-by:
-
Michal Wajdeczko authored
During initialization of the runtime part of the intel_device_info we are dumping that part using DRM_DEBUG_DRIVER mechanism. As we already have pretty printer for const part of the info, make similar function for the runtime part and use it separately. v2: add runtime dump to debugfs (Chris) Signed-off-by:
-
Michal Wajdeczko authored
As we try to follow object-verb pattern in our functions, update intel_device_info_runtime_init() parameter from dev_priv to info. Signed-off-by:
-
Michal Wajdeczko authored
We already keep intel_device_info functions in dedicated file. Add matching header file and move related definitions there. v2: add gen boundaries (Chris) Signed-off-by:
-
Michal Wajdeczko authored
We already have dedicated file for opregion related code, dedicated header will make our life easier. v2: reorder includes (Chris) Signed-off-by:
-
Michal Wajdeczko authored
We already have separate files for display related code, there is no reason to keep all display definitions in master header. Signed-off-by:
-
Michal Wajdeczko authored
We have dedicated header file for utility functions and macros. Signed-off-by:
-
Zhenyu Wang authored
It's a bit confusing that page write protect handler is live in mmio emulation handler. This moves it to stand alone gvt ops. Also remove unnecessary check of write protected page access in mmio read handler and cleanup handling of failsafe case. v2: rebase Reviewed-by:
Xiong Zhang <xiong.y.zhang@intel.com> Signed-off-by:
Zhenyu Wang <zhenyuw@linux.intel.com>
-
Zhenyu Wang authored
We had previous hack that tried to accept either i915_reg_t or offset value to access vGPU virtual/shadow regs which broke that purpose to be type safe in context. This one trys to explicitly separate the usage of typed mmio reg with real offset. Old vgpu_vreg(offset) helper is used only for offset now with new vgpu_vreg_t(reg) is used for i915_reg_t only. Convert left usage of that to new helper. Also fixed left KASAN warning issues caused by previous hack. v2: rebase, fixup against recent mmio switch change Reviewed-by:
Zhi Wang <zhi.a.wang@intel.com> Signed-off-by:
-
Xiaolin Zhang authored
observed igt drv_module_reload test case failure on 4.15.0 rc2 kernel with panic due to no active pipe available. the gpu will reset during unload/load and make pipe config reg lost which can cause kernel panic issue happen. this patch is to move pipe enabling to emulate_mointor_status_chagne to handle vgpu reset case as well. Fixes: 7e605902 ("drm/i915/gvt: enabled pipe A default on creating vgpu") Signed-off-by:
Xiaolin Zhang <xiaolin.zhang@intel.com> Signed-off-by:
-
Zhenyu Wang authored
Always requires properly defined i915_reg_t type for MMIO handler definition. Fix kasan warning of "drivers/gpu/drm/i915/gvt/handlers.c:2397:1: error: the frame size of 32120 bytes is larger than 8192 bytes" Reviewed-by:
-
- 21 Dec, 2017 1 commit
-
-
Chris Wilson authored
Include the pending update from the FBC worker in i915_fbc_status. Signed-off-by:
Paulo Zanoni <paulo.r.zanoni@intel.com>
-
