- 24 Apr, 2018 1 commit
-
-
Mika Kuoppala authored
We use jiffies to determine when wait expires. However Imre did find out that jiffies can and will do a >1 increments on certain situations [1]. When this happens in a wait_for loop, we return timeout errorneously much earlier than what the real wallclock would say. We can't afford our waits to timeout prematurely. Discard jiffies and change to ktime to detect timeouts. v2: added bugzilla entry (Imre), added stable (Chris) Reported-by:
Imre Deak <imre.deak@intel.com> References: https://lkml.org/lkml/2018/4/18/798 [1] Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=105771 Cc: Imre Deak <imre.deak@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: <stable@vger.kernel.org> Signed-off-by:
Mika Kuoppala <mika.kuoppala@linux.intel.com> Reviewed-by:
Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20180423113754.28424-1-mika.kuoppala@linux.intel.com
-
- 23 Apr, 2018 7 commits
-
-
Matt Atwood authored
Adding a missing GT2 sku discovered off hardware. Signed-off-by:
Matt Atwood <matthew.s.atwood@intel.com> Reviewed-by:
Clint Taylor <clinton.a.taylor@intel.com> Signed-off-by:
Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/1524522483-19987-1-git-send-email-matthew.s.atwood@intel.com
-
https://github.com/intel/gvt-linuxJani Nikula authored
- Minor condition check improvment (Gustavo A. R. Silva) - Non-priviliged batch buffer scan (Yan Zhao) - Scheduling optimizations (Zhipeng Gong) Signed-off-by:
Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/5dafba29-b2bd-6b94-630e-db5c009da7e3@intel.com
-
Gustavo A. R. Silva authored
In preparation to enabling -Wimplicit-fallthrough, mark switch cases where we are expecting to fall through. Addresses-Coverity-ID: 1466154 ("Missing break in switch") Signed-off-by:Gustavo A. R. Silva <gustavo@embeddedor.com> Signed-off-by:
Zhi Wang <zhi.a.wang@intel.com>
-
Gustavo A. R. Silva authored
The checks are misleading and not required [1]. [1] https://lkml.org/lkml/2018/3/19/1792 Addresses-Coverity-ID: 1466017 Cc: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by:
-
Zhao Yan authored
For perfomance purpose, scanning of non-privileged batch buffer is turned off by default. But for debugging purpose, it can be turned on via debugfs. After scanning, we submit the original non-privileged batch buffer into hardware, so that the scanning is only a peeking window of guest submitted commands and will not affect the execution results. v4: - refine debugfs print format&content (zhenyu wang) - print engine id instread of engine name to prevent potential memory leak in debugfs warning message. (zhenyu wang) v3: - change vgpu->scan_nonprivbb from type bool to u32, so it is able to selectively turn on/off scanning of non-privileged batch buffer on engine level. e.g. if vgpu->scan_nonprivbb=3, then it will scan non-privileged batch buffer on engine 0 and 1. - in debugfs interface to set vgpu->scan_nonprivbb, print warning message to warn user and explicitly tell state change in kernel log (zhenyu wang) v2: - rebase - update comments for start_gma_offset (henry) Signed-off-by:
Zhao Yan <yan.y.zhao@intel.com> Reviewed-by:
Zhenyu Wang <zhenyuw@linux.intel.com> Signed-off-by:
-
Zhipeng Gong authored
When there is only one vGPU in GVT-g and it submits workloads continuously, it will not be scheduled out, vgpu_update_timeslice is not called and its sched_in_time is not updated in a long time, which can be several seconds or longer. Once GVT-g pauses to submit workload for this vGPU due to heavy host CPU workload, this vGPU get scheduled out and vgpu_update_timeslice is called, its left_ts will be subtract by a big value from sched_out_time - sched_in_time. When GVT-g is going to submit workload for this vGPU again, it will not be scheduled in until gvt_balance_timeslice reaches stage 0 and reset its left_ts, which introduces several hunderand milliseconds latency. This patch updates time slice in every ms to update sched_in_time timely. v2: revise commit message v3: use more concise expr. (Zhenyu) Signed-off-by:
Zhipeng Gong <zhipeng.gong@intel.com> Cc: Zhenyu Wang <zhenyuw@linux.intel.com> Cc: Min He <min.he@intel.com> Signed-off-by:
-
Zhipeng Gong authored
intel_gvt_schedule check timer through a counter and is supposed to wake up to increase the counter every ms. In a system with heavy workload, gvt_service_thread can not get a chance to run right after wake up and will be delayed several milliseconds. As a result, one hundred counter interval means several hundred milliseconds in real time. This patch use real time instead of counter to do timer check. v2: remove static variable. (Zhenyu) v3: correct expire_time update. (Zhenyu) Signed-off-by:
-
- 21 Apr, 2018 1 commit
-
-
Hans de Goede authored
Before this commit the WaSkipStolenMemoryFirstPage workaround code was skipping the first 4k by passing 4096 as start of the address range passed to drm_mm_init(). This means that calling drm_mm_reserve_node() to try and reserve the firmware framebuffer so that we can inherit it would always fail, as the firmware framebuffer starts at address 0. Commit d4353761 ("drm/i915: skip the first 4k of stolen memory on everything >= gen8") says in its commit message: "This is confirmed to fix Skylake screen flickering issues (probably caused by the fact that we initialized a ring in the first page of stolen, but I didn't 100% confirm this theory)." Which suggests that it is safe to use the first page for a linear framebuffer as the firmware is doing (see note below). This commit always passes 0 as start to drm_mm_init() and works around WaSkipStolenMemoryFirstPage in i915_gem_stolen_insert_node_in_range() by insuring the start address passed by to drm_mm_insert_node_in_range() is always 4k or more. All entry points to i915_gem_stolen.c go through i915_gem_stolen_insert_node_in_range(), so that any newly allocated objects such as ring-buffers will not be allocated in the first 4k. The one exception is i915_gem_object_create_stolen_for_preallocated() which directly calls drm_mm_reserve_node() which now will be able to use the first 4k. This fixes the i915 driver no longer being able to inherit the firmware framebuffer on gen8+, which fixes the video output changing from the vendor logo to a black screen as soon as the i915 driver is loaded (on systems without fbcon). Some notes about the mapping of the BIOS framebuffer: v1 led to some discussion if the assumption of the intel_display.c code that the firmware framebuffer is a linear mapping of the stolen memory starting at offset 0 is still correct, because that would mean that the GOP does not implement the WaSkipStolenMemoryFirstPage workaround. To verify this the following code was added at the end of i915_gem_object_create_stolen_for_preallocated() : pr_err("first ggtt entry before bind: 0x%016llx\n", readq(dev_priv->ggtt.gsm)); ret = i915_vma_bind(vma, HAS_LLC(dev_priv) ? I915_CACHE_LLC : I915_CACHE_NONE, PIN_UPDATE); pr_err("i915_vma_bind ret %d\n", ret); pr_err("first ggtt entry after bind: 0x%016llx\n", readq(dev_priv->ggtt.gsm)); Which prints the mapping of the first page, then does a vma_bind() to force update the mapping with our linear view of the framebuffer and then prints the mapping of the first page again. On an Asrock B150M Pro4S/D3 mainboard with i5-6500 CPU this prints: [ 1.651141] first ggtt entry before bind: 0x0000000078c00001 [ 1.651151] i915_vma_bind ret 0 [ 1.651152] first ggtt entry after bind: 0x0000000078c00083 And "sudo cat /proc/iomem | grep Stolen" gives: 78c00000-88bfffff : Graphics Stolen Memory There are no visual changes with this patch (BIOS vendor logo still stays in place when we inherit the BIOS framebuffer), so the vma_bind() does not impact which memory is being scanned out. The address of the first ggtt entry matches with the start of stolen and the i915_vma_bind call only changes the first gtt entry's flags, or-ing in _PAGE_RW (BIT(1)) and PPAT_CACHED (BIT(7)), which perfectly matches what we would expect based on gen8_pte_encode()'s behavior. So it seems that the GOP indeed does NOT implement the wa and the i915's code assuming a linear mapping at the start of stolen for the BIOS fb still holds true for gen8+. I've also tested this on a Cherry Trail based device (a GPD Win) with identical results (the flags are 0x1b after the vma_bind on CHT, which matches with I915_CACHE_NONE). Changed in v2: No code changes, extended the commit message with the verification that the intel_display.c BIOS framebuffer mapping is still correct. Reviewed-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by:
Hans de Goede <hdegoede@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180420095933.16442-1-hdegoede@redhat.com
-
- 20 Apr, 2018 6 commits
-
-
Dhinakaran Pandiyan authored
Timestamps are useful for IGT tests that trigger PSR exit and/or wait for PSR entry. v2: Removed seqlock (Ville) Removed erroneous warning in irq loop (Chris) Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by:Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> Reviewed-by:
Jose Roberto de Souza <jose.souza@intel.com> Signed-off-by:
-
Dhinakaran Pandiyan authored
Interrupts other than the one for AUX errors are required only for debug, so unmask them via debugfs when the user requests debug. User can make such a request with echo 1 > <DEBUG_FS>/dri/0/i915_edp_psr_debug There are no locks to serialize PSR debug enabling from irq_postinstall() and debugfs for simplicity. As irq_postinstall() is called only during module initialization/resume and IGT subtests aren't expected to modify PSR debug at those times, we should be safe. v2: Unroll loops (Ville) Avoid resetting error mask bits. v3: Unmask interrupts in postinstall() if debug was still enabled. Avoid RMW (Ville) v4: Avoid extra IMR write introduced in the previous version.(Jose) Style changes, renames (Jose). Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: -
Ville Syrjälä authored
Plug in the bdw+ irq handling for PSR interrupts. bdw+ supports psr on any transcoder in theory, though the we don't currenty enable PSR except on the EDP transcoder. v2: From DK * Rebased on drm-tip v3: Switched author to Ville based on IRC discussion. Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by:
-
Daniel Vetter authored
The definitions for the error register should be valid on bdw/skl too, but there we haven't even enabled DE_MISC handling yet. Somewhat confusing the the moved register offset on bdw is only for the _CTL/_AUX register, and that _IIR/IMR stayed where they have been on bdw. v2: Fixes from Ville. v3: From DK * Rebased on drm-tip * Removed BDW IIR bit definition, looks like an unintentional change that should be in the following patch. v4: From DK * Don't mask REG_WRITE. References: bspec/11974 [SRD Interrupt Bit Definition DevHSW] Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Daniel Vetter <daniel.vetter@intel.com> Signed-off-by:
Daniel Vetter <daniel.vetter@intel.com> Signed-off-by:
-
Daniel Vetter authored
One is outright unused, other can be made static. Drive-by cleanup while accidentally reading dc code. Cc: Imre Deak <imre.deak@intel.com> Acked-by:
-
Imre Deak authored
The DMC FW specific part of display WA#1183 is supposed to be enabled whenever enabling DC5 or DC6, so move it to the DC6 enable function from the DC6 disable function. I noticed this after Daniel's patch to remove the unused skl_disable_dc6() function. Fixes: 53421c2f ("drm/i915: Apply Display WA #1183 on skl, kbl, and cfl") Cc: Lucas De Marchi <lucas.demarchi@intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: <stable@vger.kernel.org> Signed-off-by:
-
- 19 Apr, 2018 3 commits
-
-
Ville Syrjälä authored
Make the PIPE_CONF_CHECK macros a bit more robust by wrapping them in do {} while(0). Avoids funky sirprises when you try put an 'else' after a PIPE_CONF_CHECK invocation... Signed-off-by: -
Jani Nikula authored
Move the limit checks near the calculations for each field, and actually log the values that exceed limits. Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by:
-
Abhay Kumar authored
In GLK when the device boots with only 1366x768 panel without audio, HDA codec doesn't come up. In this case, the CDCLK is less than twice the BCLK. Even though audio isn't being enabled, having a too low CDCLK leads to audio probe failing altogether. Require CDCLK to be at least twice the BLCK regardless of audio. This is a minimal fix to improve things. Unfortunately, this a) leads to too high CDCLK being used when audio is not used, and b) is still not enough to fix audio probe when no outputs are connected at probe time. The proper fix would be to increase CDCLK dynamically from the audio component hooks. v2: - Address comment (Jani) - New design approach v3: - Typo fix on top of v1 v4 by Jani: rewrite commit message, add comment in code Cc: stable@vger.kernel.org Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Dhinakaran Pandiyan <dhinakaran.pandiyan@gmail.com> Cc: Wenkai Du <wenkai.du@intel.com> Reviewed-by:Wenkai Du <wenkai.du@intel.com> Tested-by:
Abhay Kumar <abhay.kumar@intel.com> Signed-off-by:
-
- 18 Apr, 2018 4 commits
-
-
Chris Wilson authored
Today we only want to pass along the priority to engine->schedule(), but in the future we want to have much more control over the various aspects of the GPU during a context's execution, for example controlling the frequency allowed. As we need an ever growing number of parameters for scheduling, move those into a struct for convenience. v2: Move the anonymous struct into its own function for legibility and ye olde gcc. Signed-off-by:
Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180418184052.7129-3-chris@chris-wilson.co.uk
-
Chris Wilson authored
Having moved the priotree struct into i915_scheduler.h, identify it as the scheduling element and rebrand into i915_sched. This becomes more useful as we start attaching more information we require to propagate through the scheduler. v2: Use i915_sched_node for future distinctiveness Signed-off-by:
-
Chris Wilson authored
Over time the priotree has grown from a sorted list to a more complicated structure for propagating constraints along the dependency chain to try and resolve priority inversion. Start to segregate this information from the rest of the request/fence tracking. Signed-off-by:
-
Gaurav K Singh authored
On Geminilake, sometimes audio card is not getting detected after reboot. This is a spurious issue happening on Geminilake. HW codec and HD audio controller link was going out of sync for which there was a fix in i915 driver but was not getting invoked for GLK. Extending this fix to GLK as well. Tested by Du,Wenkai on GLK board. Bspec: 21829 v2: Instead of checking GEN9_BC, BXT and GLK macros, use IS_GEN9 macro (Jani N) Cc: <stable@vger.kernel.org> # b651bd2a ("drm/i915/audio: Fix audio enumeration issue on BXT") Cc: <stable@vger.kernel.org> Signed-off-by:
Gaurav K Singh <gaurav.k.singh@intel.com> Reviewed-by:
-
- 17 Apr, 2018 1 commit
-
-
Oscar Mateo authored
Silence smatch over: drivers/gpu/drm/i915/selftests/intel_workarounds.c:58 read_nonprivs() error: 'cs' dereferencing possible ERR_PTR() by handling a potential (but unlikely) failure of intel_ring_begin. Fixes: f4ecfbfc ("drm/i915: Check whitelist registers across resets") Signed-off-by:
Oscar Mateo <oscar.mateo@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by:
-
- 14 Apr, 2018 2 commits
-
-
Chris Wilson authored
We have to cleanup after i915_perf_init(), even on the error path, as it passes a pointer into the module to the sysfs core. If we fail to unregister the sysctl table, we leave a dangling pointer which then may explode anytime later. Fixes: 9f9b2792 ("drm/i915/perf: reuse timestamp frequency from device info") Signed-off-by:
Lionel Landwerlin <lionel.g.landwerlin@intel.com> Reviewed-by:
Michal Wajdeczko <michal.wajdeczko@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180414091233.32224-1-chris@chris-wilson.co.uk
-
Chris Wilson authored
Add a selftest to ensure that we restore the whitelisted registers after rewrite the registers everytime they might be scrubbed, e.g. module load, reset and resume. For the other volatile workaround registers, we export their presence via debugfs and check in igt/gem_workarounds. However, we don't export the whitelist and rather than do so, let's test them directly in the kernel. The test we use is to read the registers back from the CS (this helps us be sure that the registers will be valid for MI_LRI etc). In order to generate the expected list, we split intel_whitelist_workarounds_emit into two phases, the first to build the list and the second to apply. Inside the test, we only build the list and then check that list against the hw. v2: Filter out pre-gen8 as they do not have RING_NONPRIV. v3: Drop unused engine parameter, no plans to use it now or future. Signed-off-by:
-
- 13 Apr, 2018 3 commits
-
-
Piorkowski, Piotr authored
It looks that GuC does not actively use GUC_CTL_DEVICE_INFO parameter where we are passing GT type and Core family values. Let's stop/remove setup of this parameter and remove related definitions. v2: (this time without squashed HAX) - New title and description - Remove also GUC_CORE_FAMILY_* definitions (Michel) v3: - The removed define GUC_CTL_DEVICE_INFO has been restored (Michel) - Updated description (Sagar) v4: rebase Signed-off-by:
Piotr Piórkowski <piotr.piorkowski@intel.com> Cc: Sagar Arun Kamble <sagar.a.kamble@intel.com> Cc: Michał Winiarski <michal.winiarski@intel.com> Cc: John A Spotswood <john.a.spotswood@intel.com> Cc: Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Michel Thierry <michel.thierry@intel.com> Acked-by:
Michel Thierry <michel.thierry@intel.com> Reviewed-by:
Sagar Arun Kamble <sagar.a.kamble@intel.com> Signed-off-by:
-
Jani Nikula authored
Signed-off-by: -
Mika Kuoppala authored
Evidence indicates that Cannonlake HWSP is not coherent as it should. Revert to using mmio access for now. Testcase: igt/gem_ctx_switch References: https://bugs.freedesktop.org/show_bug.cgi?id=105888 Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Rafael Antognolli <rafael.antognolli@intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by:
-
- 12 Apr, 2018 2 commits
-
-
Jani Nikula authored
No functional changes. Cc: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by:
-
Jani Nikula authored
The VBT contains the DDC pin to use for specific ports. Alas, sometimes the field appears to contain bogus data, and while we check for it later on in intel_gmbus_get_adapter() we fail to check the returned NULL on errors. Oops results. The simplest approach seems to be to catch and ignore the bogus DDC pins already at the VBT parsing phase, reverting to fixed per port default pins. This doesn't guarantee display working, but at least it prevents the oops. And we continue to be fuzzed by VBT. One affected machine is Dell Latitude 5590 where a BIOS upgrade added invalid DDC pins. Typical backtrace: [ 35.461411] WARN_ON(!intel_gmbus_is_valid_pin(dev_priv, pin)) [ 35.461432] WARNING: CPU: 6 PID: 411 at drivers/gpu/drm/i915/intel_i2c.c:844 intel_gmbus_get_adapter+0x32/0x37 [i915] [ 35.461437] Modules linked in: i915 ahci libahci dm_snapshot dm_bufio dm_raid raid456 async_raid6_recov async_pq raid6_pq async_xor xor async_memcpy async_tx [ 35.461445] CPU: 6 PID: 411 Comm: kworker/u16:2 Not tainted 4.16.0-rc7.x64-g1cda370ffded #1 [ 35.461447] Hardware name: Dell Inc. Latitude 5590/0MM81M, BIOS 1.1.9 03/13/2018 [ 35.461450] Workqueue: events_unbound async_run_entry_fn [ 35.461465] RIP: 0010:intel_gmbus_get_adapter+0x32/0x37 [i915] [ 35.461467] RSP: 0018:ffff9b4e43d47c40 EFLAGS: 00010286 [ 35.461469] RAX: 0000000000000000 RBX: ffff98f90639f800 RCX: ffffffffae051960 [ 35.461471] RDX: 0000000000000001 RSI: 0000000000000092 RDI: 0000000000000246 [ 35.461472] RBP: ffff98f905410000 R08: 0000004d062a83f6 R09: 00000000000003bd [ 35.461474] R10: 0000000000000031 R11: ffffffffad4eda58 R12: ffff98f905410000 [ 35.461475] R13: ffff98f9064c1000 R14: ffff9b4e43d47cf0 R15: ffff98f905410000 [ 35.461477] FS: 0000000000000000(0000) GS:ffff98f92e580000(0000) knlGS:0000000000000000 [ 35.461479] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 35.461481] CR2: 00007f5682359008 CR3: 00000001b700c005 CR4: 00000000003606e0 [ 35.461483] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 35.461484] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 35.461486] Call Trace: [ 35.461501] intel_hdmi_set_edid+0x37/0x27f [i915] [ 35.461515] intel_hdmi_detect+0x7c/0x97 [i915] [ 35.461518] drm_helper_probe_single_connector_modes+0xe1/0x6c0 [ 35.461521] drm_setup_crtcs+0x129/0xa6a [ 35.461523] ? __switch_to_asm+0x34/0x70 [ 35.461525] ? __switch_to_asm+0x34/0x70 [ 35.461527] ? __switch_to_asm+0x40/0x70 [ 35.461528] ? __switch_to_asm+0x34/0x70 [ 35.461529] ? __switch_to_asm+0x40/0x70 [ 35.461531] ? __switch_to_asm+0x34/0x70 [ 35.461532] ? __switch_to_asm+0x40/0x70 [ 35.461534] ? __switch_to_asm+0x34/0x70 [ 35.461536] __drm_fb_helper_initial_config_and_unlock+0x34/0x46f [ 35.461538] ? __switch_to_asm+0x40/0x70 [ 35.461541] ? _cond_resched+0x10/0x33 [ 35.461557] intel_fbdev_initial_config+0xf/0x1c [i915] [ 35.461560] async_run_entry_fn+0x2e/0xf5 [ 35.461563] process_one_work+0x15b/0x364 [ 35.461565] worker_thread+0x2c/0x3a0 [ 35.461567] ? process_one_work+0x364/0x364 [ 35.461568] kthread+0x10c/0x122 [ 35.461570] ? _kthread_create_on_node+0x5d/0x5d [ 35.461572] ret_from_fork+0x35/0x40 [ 35.461574] Code: 74 16 89 f6 48 8d 04 b6 48 c1 e0 05 48 29 f0 48 8d 84 c7 e8 11 00 00 c3 48 c7 c6 b0 19 1e c0 48 c7 c7 64 8a 1c c0 e8 47 88 ed ec <0f> 0b 31 c0 c3 8b 87 a4 04 00 00 80 e4 fc 09 c6 89 b7 a4 04 00 [ 35.461604] WARNING: CPU: 6 PID: 411 at drivers/gpu/drm/i915/intel_i2c.c:844 intel_gmbus_get_adapter+0x32/0x37 [i915] [ 35.461606] ---[ end trace 4fe1e63e2dd93373 ]--- [ 35.461609] BUG: unable to handle kernel NULL pointer dereference at 0000000000000010 [ 35.461613] IP: i2c_transfer+0x4/0x86 [ 35.461614] PGD 0 P4D 0 [ 35.461616] Oops: 0000 [#1] SMP PTI [ 35.461618] Modules linked in: i915 ahci libahci dm_snapshot dm_bufio dm_raid raid456 async_raid6_recov async_pq raid6_pq async_xor xor async_memcpy async_tx [ 35.461624] CPU: 6 PID: 411 Comm: kworker/u16:2 Tainted: G W 4.16.0-rc7.x64-g1cda370ffded #1 [ 35.461625] Hardware name: Dell Inc. Latitude 5590/0MM81M, BIOS 1.1.9 03/13/2018 [ 35.461628] Workqueue: events_unbound async_run_entry_fn [ 35.461630] RIP: 0010:i2c_transfer+0x4/0x86 [ 35.461631] RSP: 0018:ffff9b4e43d47b30 EFLAGS: 00010246 [ 35.461633] RAX: ffff9b4e43d47b6e RBX: 0000000000000005 RCX: 0000000000000001 [ 35.461635] RDX: 0000000000000002 RSI: ffff9b4e43d47b80 RDI: 0000000000000000 [ 35.461636] RBP: ffff9b4e43d47bd8 R08: 0000004d062a83f6 R09: 00000000000003bd [ 35.461638] R10: 0000000000000031 R11: ffffffffad4eda58 R12: 0000000000000002 [ 35.461639] R13: 0000000000000001 R14: ffff9b4e43d47b6f R15: ffff9b4e43d47c07 [ 35.461641] FS: 0000000000000000(0000) GS:ffff98f92e580000(0000) knlGS:0000000000000000 [ 35.461643] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 35.461645] CR2: 0000000000000010 CR3: 00000001b700c005 CR4: 00000000003606e0 [ 35.461646] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 35.461647] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 35.461649] Call Trace: [ 35.461652] drm_do_probe_ddc_edid+0xb3/0x128 [ 35.461654] drm_get_edid+0xe5/0x38d [ 35.461669] intel_hdmi_set_edid+0x45/0x27f [i915] [ 35.461684] intel_hdmi_detect+0x7c/0x97 [i915] [ 35.461687] drm_helper_probe_single_connector_modes+0xe1/0x6c0 [ 35.461689] drm_setup_crtcs+0x129/0xa6a [ 35.461691] ? __switch_to_asm+0x34/0x70 [ 35.461693] ? __switch_to_asm+0x34/0x70 [ 35.461694] ? __switch_to_asm+0x40/0x70 [ 35.461696] ? __switch_to_asm+0x34/0x70 [ 35.461697] ? __switch_to_asm+0x40/0x70 [ 35.461698] ? __switch_to_asm+0x34/0x70 [ 35.461700] ? __switch_to_asm+0x40/0x70 [ 35.461701] ? __switch_to_asm+0x34/0x70 [ 35.461703] __drm_fb_helper_initial_config_and_unlock+0x34/0x46f [ 35.461705] ? __switch_to_asm+0x40/0x70 [ 35.461707] ? _cond_resched+0x10/0x33 [ 35.461724] intel_fbdev_initial_config+0xf/0x1c [i915] [ 35.461727] async_run_entry_fn+0x2e/0xf5 [ 35.461729] process_one_work+0x15b/0x364 [ 35.461731] worker_thread+0x2c/0x3a0 [ 35.461733] ? process_one_work+0x364/0x364 [ 35.461734] kthread+0x10c/0x122 [ 35.461736] ? _kthread_create_on_node+0x5d/0x5d [ 35.461738] ret_from_fork+0x35/0x40 [ 35.461739] Code: 5c fa e1 ad 48 89 df e8 ea fb ff ff e9 2a ff ff ff 0f 1f 44 00 00 31 c0 e9 43 fd ff ff 31 c0 45 31 e4 e9 c5 fd ff ff 41 54 55 53 <48> 8b 47 10 48 83 78 10 00 74 70 41 89 d4 48 89 f5 48 89 fb 65 [ 35.461756] RIP: i2c_transfer+0x4/0x86 RSP: ffff9b4e43d47b30 [ 35.461757] CR2: 0000000000000010 [ 35.461759] ---[ end trace 4fe1e63e2dd93374 ]--- Based on a patch by Fei Li. v2: s/reverting/sticking/ (Chris) Cc: stable@vger.kernel.org Cc: Fei Li <fei.li@intel.com> Co-developed-by:
Fei Li <fei.li@intel.com> Reported-by:
Pavel Nakonechnyi <zorg1331@gmail.com> Reported-and-tested-by:
Seweryn Kokot <sewkokot@gmail.com> Reported-and-tested-by:
Laszlo Valko <valko@linux.karinthy.hu> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=105549 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=105961Reviewed-by:
-
- 11 Apr, 2018 5 commits
-
-
Oscar Mateo authored
There are different kind of workarounds (those that modify registers that live in the context image, those that modify global registers, those that whitelist registers, etc...) and they have different requirements in terms of where they are applied and how. Also, by splitting them apart, it should be easier to decide where a new workaround should go. v2: - Add multiple MISSING_CASE - Rebased v3: - Rename mmio_workarounds to gt_workarounds (Chris, Mika) - Create empty placeholders for BDW and CHV GT WAs - Rebased v4: Rebased v5: - Rebased - FORCE_TO_NONPRIV register exists since BDW, so make a path for it to achieve universality, even if empty (Chris) Signed-off-by:
-
Oscar Mateo authored
This has grown to be a sizable amount of code, so move it to its own file before we try to refactor anything. For the moment, we are leaving behind the WA BB code and the WAs that get applied (incorrectly) in init_clock_gating, but we will deal with it later. v2: Use intel_ prefix for code that deals with the hardware (Chris) v3: Rebased v4: - Rebased - New license header v5: - Rebased - Added some organisational notes to the file (Chris) v6: Include DOC section in the documentation build (Jani) Signed-off-by:
-
Chris Wilson authored
We can refine our current execlists->queue_priority if we inspect ELSP[1] rather than the head of the unsubmitted queue. Currently, we use the unsubmitted queue and say that if a subsequent request is more important than the current queue, we will rerun the submission tasklet to evaluate the need for preemption. However, we only want to preempt if we need to jump ahead of a currently executing request in ELSP. The second reason for running the submission tasklet is amalgamate requests into the active context on ELSP[0] to avoid a stall when ELSP[0] drains. (Though repeatedly amalgamating requests into the active context and triggering many lite-restore is off question gain, the goal really is to put a context into ELSP[1] to cover the interrupt.) So if instead of looking at the head of the queue, we look at the context in ELSP[1] we can answer both of the questions more accurately -- we don't need to rerun the submission tasklet unless our new request is important enough to feed into, at least, ELSP[1]. v2: Add some comments from the discussion with Tvrtko. v3: More commentary to cross-reference queue_request() References: f6322edd ("drm/i915/preemption: Allow preemption between submission ports") Signed-off-by:
Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180411103929.27374-1-chris@chris-wilson.co.uk
-
Jani Nikula authored
Apparently caused by a merge fail at some point. Due to the nature of the duplicated block, the second one will have no effect, and there's no need to backport. Reviewed-by:
Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by:
-
Tvrtko Ursulin authored
While thinking about sporadic failures of perf_pmu/rc6-runtime-pm* tests on some CI machines I have concluded that: a) the PMU readout of RC6 can race against runtime PM transitions, and b) there are other reasons than being runtime suspended which can cause intel_runtime_pm_get_if_in_use to fail. Therefore when estimating RC6 the code needs to assert we are indeed in suspended state, and if not, the best we can do is return the last known RC6 value. Without this check we can calculate the estimated value based on un- initialized or inappropriate internal state, which can result in over- estimation, or in any case incorrect value being returned. v2: * Re-arrange the code a bit to avoid second unlock and return branch. (Chris Wilson) v3: * Insert some strategic blank lines and improve commit msg. (Chris Wilson) Signed-off-by:
-
- 10 Apr, 2018 5 commits
-
-
Chris Wilson authored
%phn is not a valid specifier, and the trailing 'n' is being eaten by the format-specifier and defaulting to the ' ' separator. Avoid angering smatch by using the unknown specifier, and use the default we expect. drivers/gpu/drm/i915/intel_guc_ct.c:616 ctb_read() warn: '%ph' cannot be followed by 'n' drivers/gpu/drm/i915/intel_guc_ct.c:616 ctb_read() warn: '%ph' cannot be followed by 'n' drivers/gpu/drm/i915/intel_guc_ct.c:616 ctb_read() warn: '%ph' cannot be followed by 'n' drivers/gpu/drm/i915/intel_guc_ct.c:669 ct_handle_response() warn: '%ph' cannot be followed by 'n' drivers/gpu/drm/i915/intel_guc_ct.c:679 ct_handle_response() warn: '%ph' cannot be followed by 'n' drivers/gpu/drm/i915/intel_guc_ct.c:693 ct_handle_response() warn: '%ph' cannot be followed by 'n' drivers/gpu/drm/i915/intel_guc_ct.c:707 ct_handle_response() warn: '%ph' cannot be followed by 'n' drivers/gpu/drm/i915/intel_guc_ct.c:727 ct_process_request() warn: '%ph' cannot be followed by 'n' drivers/gpu/drm/i915/intel_guc_ct.c:803 ct_handle_request() warn: '%ph' cannot be followed by 'n' Signed-off-by:
-
Chris Wilson authored
Resetting the GPU doesn't affect the RPS/RC6 state, so we can stop forcibly reloading the registers. Ville suggested this many moons ago, I said at that time that sanitizing was no harm and meant that our bookkeeping was kept consistent with the HW. However, in a forthcoming series, we want to split rps/rc6 GT powermanagement and one of the key simplifications is the control of when we enable it. Performing a crude sanitize in the middle of i915_gem_reset() is then a huge wart. Suggested-by:
-
Maarten Lankhorst authored
Adding a i915_fifo_underrun_reset debugfs file will make it possible for IGT tests to clear FIFO underrun fallout at the start of each subtest, and make re-enable FBC so tests always have maximum exposure to features used by IGT. FIFO underruns and FBC bugs will no longer hide when an earlier subtests disables both. Signed-off-by:
Maarten Lankhorst <maarten.lankhorst@linux.intel.com> References: https://bugs.freedesktop.org/show_bug.cgi?id=105685 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=105681 Link: https://patchwork.freedesktop.org/patch/msgid/20180328100526.36467-1-maarten.lankhorst@linux.intel.comAcked-by:
Jani Nikula <jani.nikula@linux.intel.com> [mlankhorst: Reset FBC reason if underrun had occurred. (vivijim)] Reviewed-by:
-
Chris Wilson authored
Inside the psr work function, we want to wait for PSR to idle first and wish to do so without blocking the normal modeset path, so we do so without holding the PSR lock. However, we first have to find which pipe PSR was enabled on, which requires chasing into the PSR struct and requires locking to prevent intel_psr_disable() from concurrently setting our pointer to NULL. Fixes: 995d3047 ("drm/i915: VLV/CHV PSR Software timer mode") Signed-off-by:
-
Imre Deak authored
On GLK sporadic timeouts occur during PHY0 enabling. Based on logs it looks like they happen sometime after a system suspend/resume cycle, with the same power well enabling succeeding both before and after the failed one and no other problems observed. The current timeout in the code is not actually specified by BSpec, so let's try to increase that until a BSpec update. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=105771Signed-off-by:
-
