- 06 Apr, 2018 6 commits
-
-
Kevin Rogovin authored
Now that "DOC: User command execution" of i915_gem_execbuffer.c is included in the i915.rst, it is benecifial (for new developers) to read what happens at the bottom of the driver stack (in terms of bytes written to be read by the GPU) when processing a user-space batchbuffer. v5: Typo correction of lacking double tick. Signed-off-by:
Kevin Rogovin <kevin.rogovin@intel.com> Reviewed-by:
Joonas Lahtinen <joonas.lahtinen@linux.intel.com> [Joonas: correcting the patch title] Signed-off-by:
-
Kevin Rogovin authored
Add the documentation of "DOC: User command execution" of i915_gem_execbuffer.c into a new section in i915.rst. Signed-off-by:
-
Kevin Rogovin authored
Add a narration to i915.rst about Intel GEN GPU's: engines, driver context and relocation. Also do minor reorder to improve narration. v5: More type fixes. Flow bullet list so lines are not too long. Signed-off-by:
Mika Kuoppala <mika.kuoppala@linux.intel.com> [Joonas: correcting the patch title] Signed-off-by:
-
Chris Wilson authored
We don't handle resetting the kernel context very well, or presumably any context executing its breadcrumb commands in the ring as opposed to the batchbuffer and flush. If we trigger a device reset twice in quick succession while the kernel context is executing, we may end up skipping the breadcrumb. This is really only a problem for the selftest as normally there is a large interlude between resets (hangcheck), or we focus on resetting just one engine and so avoid repeatedly resetting innocents. Something to try would be a preempt-to-idle to quiesce the engine before reset, so that innocent contexts would be spared the reset. Signed-off-by:
Chris Wilson <chris@chris-wilson.co.uk> Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com> Cc: Michał Winiarski <michal.winiarski@intel.com> CC: Michel Thierry <michel.thierry@intel.com> Reviewed-by:
Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180330131801.18327-1-chris@chris-wilson.co.uk
-
Gaurav K Singh authored
On Apollolake, with stress test warm reboot, audio card was not getting enumerated after reboot. This was a spurious issue happening on Apollolake. 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 BXT. Extending this fix to BXT as well. Tested on apollolake chromebook by stress test warm reboot with 2500 iterations. Bspec: 21829 Signed-off-by:
Gaurav K Singh <gaurav.k.singh@intel.com> Reviewed-by:
Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> Signed-off-by:
Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/1522946544-11524-1-git-send-email-gaurav.k.singh@intel.com
-
Radhakrishna Sripada authored
Static code analysis tool reported memory leak in intel_hdcp_auth_downstream. Fixing the memory leak. v2: Rebase, move free to a cleanup label(Jani) Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Anusha Srivatsa <anusha.srivatsa@intel.com> Signed-off-by:
Radhakrishna Sripada <radhakrishna.sripada@intel.com> Reviewed-by:
Anusha Srivatsa <anusha.srivatsa@intel.com> Signed-off-by:
-
- 05 Apr, 2018 1 commit
-
-
Chris Wilson authored
If we skip the intel_prepare_reset(), we should also skip the intel_display_reset(). If we we use a flag set by intel_prepare_reset() then we do not have to second guess based on external user controlled state whether or not the prepare was called before deciding to finish it after the reset. igt/gem_eio is one such example that may tweak i915.reset faster than the code is expecting, leading to [ 190.233528] ===================================== [ 190.233534] WARNING: bad unlock balance detected! [ 190.233540] 4.16.0-rc7-g335ef9849310-drmtip_10+ #1 Tainted: G U [ 190.233547] ------------------------------------- [ 190.233553] gem_eio/1348 is trying to release lock (crtc_ww_class_acquire) at: [ 190.233569] [<ffffffff895c7810>] drm_modeset_acquire_fini+0x0/0x60 [ 190.233575] but there are no more locks to release! [ 190.233580] other info that might help us debug this: [ 190.233588] 3 locks held by gem_eio/1348: [ 190.233592] #0: (&f->f_pos_lock){+.+.}, at: [<00000000ab90c784>] __fdget_pos+0x3a/0x50 [ 190.233607] #1: (sb_writers#11){.+.+}, at: [<00000000e1529265>] vfs_write+0x188/0x1a0 [ 190.233622] #2: (&attr->mutex){+.+.}, at: [<0000000011f40afe>] simple_attr_write+0x36/0xd0 [ 190.233635] stack backtrace: [ 190.233644] CPU: 0 PID: 1348 Comm: gem_eio Tainted: G U 4.16.0-rc7-g335ef9849310-drmtip_10+ #1 [ 190.233655] Hardware name: Dell Inc. OptiPlex GX280 /0G8310, BIOS A04 02/09/2005 [ 190.233664] Call Trace: [ 190.233674] dump_stack+0x67/0x95 [ 190.233682] ? drm_modeset_backoff+0x1b0/0x1b0 [ 190.233690] print_unlock_imbalance_bug+0xd2/0xe0 [ 190.233698] ? drm_modeset_backoff+0x1b0/0x1b0 [ 190.233704] lock_release+0x23e/0x300 [ 190.233712] drm_modeset_acquire_fini+0x16/0x60 [ 190.233835] intel_finish_reset+0x72/0x160 [i915] [ 190.233894] i915_reset_device+0x1e9/0x240 [i915] [ 190.233953] ? __intel_get_crtc_scanline+0x1c0/0x1c0 [i915] [ 190.233962] ? work_on_cpu_safe+0x50/0x50 [ 190.234020] i915_handle_error+0x1f2/0x470 [i915] [ 190.234031] ? __might_fault+0x39/0x90 [ 190.234037] ? __might_fault+0x39/0x90 [ 190.234099] i915_wedged_set+0x7f/0xc0 [i915] [ 190.234107] simple_attr_write+0xb0/0xd0 [ 190.234117] full_proxy_write+0x51/0x80 [ 190.234125] __vfs_write+0x21/0x140 [ 190.234133] ? rcu_read_lock_sched_held+0x6f/0x80 [ 190.234140] ? rcu_sync_lockdep_assert+0x29/0x50 [ 190.234147] ? __sb_start_write+0x152/0x1f0 [ 190.234152] ? __sb_start_write+0x168/0x1f0 [ 190.234159] vfs_write+0xbd/0x1a0 [ 190.234166] SyS_write+0x40/0xa0 [ 190.234173] ? do_syscall_64+0x19/0x1b0 [ 190.234180] do_syscall_64+0x6b/0x1b0 [ 190.234188] entry_SYSCALL_64_after_hwframe+0x42/0xb7 [ 190.234196] RIP: 0033:0x7f84c1b392b7 [ 190.234201] RSP: 002b:00007f84b6755b00 EFLAGS: 00000293 ORIG_RAX: 0000000000000001 [ 190.234211] RAX: ffffffffffffffda RBX: 0000000000000046 RCX: 00007f84c1b392b7 [ 190.234218] RDX: 0000000000000002 RSI: 000055ec20abc8d6 RDI: 0000000000000046 [ 190.234225] RBP: 000055ec20abc8d6 R08: 0000000000000000 R09: 0000000000000000 [ 190.234231] R10: 0000000000000000 R11: 0000000000000293 R12: 0000000000000002 [ 190.234238] R13: 0000000000000000 R14: 00007f84b0000b20 R15: 000055ec20ce4eb8 Testcase: igt/gem_eio Signed-off-by:Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180405123714.3638-1-chris@chris-wilson.co.uk
-
- 04 Apr, 2018 6 commits
-
-
Chris Wilson authored
Before adding a new feature to execlists submission, we should endeavour to cover the baseline behaviour with selftests. So start the ball rolling. Signed-off-by:
-
Xidong Wang authored
Along the eb_lookup_vmas() error path, the return value from kmem_cache_alloc() was freed using kfree(). Fix it to use the proper kmem_cache_free() instead. Fixes: d1b48c1e ("drm/i915: Replace execbuf vma ht with an idr") Signed-off-by:
Xidong Wang <wangxidong_97@163.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: <stable@vger.kernel.org> # v4.14+ Reviewed-by:
-
Ramalingam C authored
HDCP1.4 key can be loaded, only when Power well #1 is enabled and cdclk is enabled. Using the I915 power well infrastruture, above requirement is verified. This patch enables the hdcp initialization for HSW, BDW, and BXT. v2: Choose the PW# based on the platform. v3: No Changes. Signed-off-by:
Ramalingam C <ramalingam.c@intel.com> Reviewed-by:
Sean Paul <seanpaul@chromium.org> Signed-off-by:
Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/1522663834-24482-4-git-send-email-ramalingam.c@intel.com
-
Ramalingam C authored
In case of V prime mismatch, DP HDCP spec mandates the re-read of Vprime atleast twice. This patch needed for DP HDCP1.4 CTS Test: 1B-05. v2: Moved the V' validation into a function for retry. [Sean Paul] v3: Removed Inline keyword and DRM_DEBUG_KMS are used [Sean Paul] Signed-off-by:
-
Ramalingam C authored
As per DP spec when R0 mismatch is detected, HDCP source supported re-read the R0 atleast twice. And For HDMI and DP minimum wait required for the R0 availability is 100mSec. So this patch changes the wait time to 100mSec but retries twice with the time interval of 100mSec for each attempt. This patch is needed for DP HDCP1.4 CTS Test: 1A-06. v2: No Change v3: Comment on R0 retry is moved closer to the code[Seanpaul] v4: Removing unwanted noise introduced in v3. Signed-off-by:
-
Chris Wilson authored
Let's avoid having to delve down the pointer chain to see if the i915 device has support for preemption and store that on the engine, which made the decision in the first place! v2: Refactor common preemption policy between execlists/guc. Signed-off-by:
Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180403183537.5522-1-chris@chris-wilson.co.uk
-
- 03 Apr, 2018 1 commit
-
-
Chris Wilson authored
We would like to start doing some bookkeeping at the beginning, between contexts and at the end of execlists submission. We already mark the beginning and end using EXECLISTS_ACTIVE_USER, to provide an indication when the HW is idle. This give us a pair of sequence points we can then expand on for further bookkeeping. v2: Refactor guc submission to share the same begin/end. Signed-off-by:
Francisco Jerez <currojerez@riseup.net> Reviewed-by:
-
- 30 Mar, 2018 12 commits
-
-
Rodrigo Vivi authored
Commit 'aee3bac0 ("drm/i915/psr: Tie PSR2 support to Y coordinate requirement")' got merged to drm-intel-next-queued but the variable was defined commit 'c5fe4732 ("drm: Add PSR version 3 macro") who was merged through drm-misc. So backmerging to get drm-intel-next-queued compiling back again. Signed-off-by:
-
José Roberto de Souza authored
In the 2 eDP1.4a pannels tested set or not set bit have no effect but is better set it and comply with specification. Signed-off-by:
José Roberto de Souza <jose.souza@intel.com> Cc: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> Reviewed-by:
-
José Roberto de Souza authored
This value do not change overtime so better cache it than fetch it every PSR enable. Cc: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> Reviewed-by:
-
José Roberto de Souza authored
Cosmetic change. Reviewed-by:
-
José Roberto de Souza authored
Sink can support our PSR2 requirements but userspace can request a resolution that PSR2 hardware do not support, in this case it was overwritten the PSR2 sink support. Adding another flag here, this way if requested resolution changed to a value that PSR2 hardware can handle, PSR2 can be enabled. Cc: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> Reviewed-by:
-
José Roberto de Souza authored
For Geminilake and Cannonlake+ the Y-coordinate support must be enabled in PSR2_CTL too. Spec: 7713 and 7720 Cc: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> Reviewed-by:
-
José Roberto de Souza authored
Although i915 don't implement aux sync frame through tests was findout that pannels can do selective update when the y-coordinate is also included in SDP, that is why it is required to run PSR2 in i915. So moving to only one place the sink requirements that the actual driver needs to enable PSR2. Also intel_psr2_config_valid() is called every time the crtc config is computed, wasting some time every time it was checking for Y coordinate requirement. This allow us to nuke y_cord_support and some of VSC setup code that was handling a scenario that would never happen(PSR2 without Y coordinate). Also here renaming intel_dp_get_y_cord_status() to intel_dp_get_y_coord_required() as it more accurate to the name and function of bit according to eDP spec. Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by:
-
José Roberto de Souza authored
eDP spec states that aux frame is required to do PSR2 selective update but i915 don't fully implement it. It sends the aux frame sync messages but the value is always zero as the GTC is not enabled in driver. Through tests was findout that pannels can do selective update when the y-coordinate is also included in SDP, that is why it is required to run PSR2 in i915. A dummy value is not useful at all to sink, so removing everything related to aux frame sync, if GTC is enabled we can bring this back. Cc: Vathsala Nagaraju <vathsala.nagaraju@intel.com> Acked-by:
-
José Roberto de Souza authored
This is a register to help debug what is in the last SDP VSC packet revived by sink. Signed-off-by:
-
José Roberto de Souza authored
To comply with eDP1.4a this bit should be set when enabling PSR2. Signed-off-by:
-
Chris Wilson authored
As intel_wait_for_register_fw() may use, and if successful only use, a busy-wait loop, the might_sleep() warning is a little over-zealous. Restrict it to a might_sleep_if() a slow timeout is specified (and so the caller authorises use of a usleep). Signed-off-by:
-
Chris Wilson authored
Only sleep and repeat when asked for a full device reset (ALL_ENGINES) and avoid using sleeping waits when asked for a per-engine reset. The goal is to be able to use a per-engine reset from hardirq/softirq/timer context. A consequence is that our individual wait timeouts are a thousand times shorter, on the order of a hundred microseconds rather than hundreds of millisecond. This may make hitting the timeouts more common, but hopefully the fallover to the full-device reset will be sufficient to pick up the pieces. Note, that the sleeps inside older gen (pre-gen8) have been left as they are only used in full device reset mode. Signed-off-by:
Michel Thierry <michel.thierry@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180329224519.13598-1-chris@chris-wilson.co.uk
-
- 29 Mar, 2018 8 commits
-
-
Lionel Landwerlin authored
This will make it easier to spot issues related to config creation/usage. Signed-off-by:
Lionel Landwerlin <lionel.g.landwerlin@intel.com> Reviewed-by:
Matthew Auld <matthew.auld@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180326090831.22686-9-lionel.g.landwerlin@intel.com
-
Lionel Landwerlin authored
We had a generic field name used across 2 registers but it feels like it's clearer we make it obvious what register this field belongs to. Signed-off-by:
-
Lionel Landwerlin authored
This was added by mistake in commit 28964cf2 ("drm/i915/perf: disable NOA logic when not used"). Signed-off-by:
-
Lionel Landwerlin authored
In commit d7965152 ("drm/i915: Enable i915 perf stream for Haswell OA unit") the enable/disable vfunc hadn't appear yet and the same function would deal with enabling/disabling the OA unit. This was split later on for gen8 but the gen7 retained some code that isn't actually useful anymore. Signed-off-by:
-
Lionel Landwerlin authored
We've been a bit loose about this opening parameter. We should only add the flag for writing OA reports when the value of this parameter is != 0. Signed-off-by:
-
Lionel Landwerlin authored
No significant changes from either context offsets, nor report formats, nor register whitelist. v2: Also drop slice/unslice clock ratio changes (Matt) Signed-off-by:
-
Chris Wilson authored
When we include a request's global_seqno in a GEM_TRACE it often helps to know how that relates to the current breadcrumb as seen by the hardware. Signed-off-by:
-
Michel Thierry authored
Probably lost while rebasing commit eacd8391 ("drm/i915/guc: Keep GuC interrupts enabled when using GuC"). Not really needed since i915_gem_init_hw is called before uc_resume, but it brings symmetry to uc_suspend. Signed-off-by:
Michał Winiarski <michal.winiarski@intel.com> Signed-off-by:
-
- 28 Mar, 2018 6 commits
-
-
git://anongit.freedesktop.org/drm/drm-miscDave Airlie authored
- Mask mode type garbage from userspace (Ville) Something went wrong on the misc tree side, but I'll pull the patch directly. * 'drm-misc-next-fixes' of git://anongit.freedesktop.org/drm/drm-misc: drm: Fix uabi regression by allowing garbage mode->type from userspace
-
Michal Wajdeczko authored
During debug we may want to investigate all communication from the Guc. Add proper tracing macros in debug config. v2: convert remaining DRM_DEBUG into new CT_DEBUG (Michal) v3: use dedicated Kconfig (Daniele) v4: checkpatch Signed-off-by:
Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Acked-by:
-
Michal Wajdeczko authored
When running on platform with CTB based GuC communication enabled, GuC to Host event data will be delivered as CT request message. However, content of the data[1] of this CT message follows format of the scratch register used in MMIO based communication, so some code reuse is still possible. v2: filter disabled messages (Daniele) Signed-off-by:
-
Michal Wajdeczko authored
Requests are read from CT in the irq handler, but actual processing will be done in the work thread. Processing of specific actions will be added in the upcoming patches. v2: don't use GEM_BUG_ON (Chris) don't kmalloc too large buffer (Michal) v3: rebased v4: don't name it 'dispatch' (Michel) and fix checkpatch add some documentation (Michal) Signed-off-by: -
Michal Wajdeczko authored
Instead of returning small data in response status dword, GuC may append longer data as response message payload. If caller provides response buffer, we will copy received data and use number of received data dwords as new success return value. We will WARN if response from GuC does not match caller expectation. v2: fix timeout and checkpatch warnings (Michal) v3: fix checkpatch again (Michel) update wait function name (Michal) no need for spinlock_irqsave (MichalWi) no magic numbers (MichalWi) must check before use (Jani) add some more documentation (Michal) v4: update documentation (Michal) Signed-off-by: -
Michal Wajdeczko authored
In next patch we will introduce another way of waiting for the response that will use RECV buffer. To avoid misleading names, rename old wait function to reflect the fact that it is based on descriptor update. v2: fix comment style (Michal) v3: use more specific name (Michel) Signed-off-by:
-
