summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2018-04-09drm/i915/skl+: add NV12 in skl_format_to_fourccMahesh Kumar
Add support of recognizing DRM_FORMAT_NV12 from plane_format register value. v2: Added reviewed by tag from Mika Kahola v3: Added reviewed by from Juha-Pekka Heikkila v4: Rebased the series Reviewed-by: Juha-Pekka Heikkila <juhapekka.heikkila@gmail.com> Reviewed-by: Mika Kahola <mika.kahola@intel.com> Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by: Mahesh Kumar <mahesh1.kumar@intel.com> Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/1523245273-30264-4-git-send-email-vidya.srinivas@intel.com
2018-04-09drm/i915/skl+: refactor WM calculation for NV12Mahesh Kumar
Current code calculates DDB for planar formats in such a way that we store DDB of plane-0 in plane 1 & vice-versa. In order to make this clean this patch refactors WM/DDB calculation for NV12 planar formats. v2: Addressed review comments by Maarten v3: Rebased and addressed review comments by Maarten v4: Fixed a compilation issue of string replacement is_nv12 to is_planar v5: Added reviewed by from Juha-Pekka Heikkila v6: Rebased the series Reviewed-by: Juha-Pekka Heikkila <juhapekka.heikkila@gmail.com> Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by: Mahesh Kumar <mahesh1.kumar@intel.com> Signed-off-by: Vidya Srinivas <vidya.srinivas@intel.com> Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/1523245273-30264-3-git-send-email-vidya.srinivas@intel.com
2018-04-09drm/i915/skl+: rename skl_wm_values struct to skl_ddb_valuesMahesh Kumar
skl_wm_values struct contains values of pipe/plane DDB only. so rename it for better readability of code. Similarly skl_copy_wm_for_pipe copies DDB values. s/skl_wm_values/skl_ddb_values s/skl_copy_wm_for_pipe/skl_copy_ddb_for_pipe Changes since V1: - also change name of skl_copy_wm_for_pipe v2: Added reviewed by from Juha-Pekka Heikkila v3: Rebased the series Reviewed-by: Juha-Pekka Heikkila <juhapekka.heikkila@gmail.com> Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by: Mahesh Kumar <mahesh1.kumar@intel.com> Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/1523245273-30264-2-git-send-email-vidya.srinivas@intel.com
2018-04-07drm/i915/dp: Send DPCD ON for MST before phy_upLyude Paul
When doing a modeset where the sink is transitioning from D3 to D0 , it would sometimes be possible for the initial power_up_phy() to start timing out. This would only be observed in the last action before the sink went into D3 mode was intel_dp_sink_dpms(DRM_MODE_DPMS_OFF). We originally thought this might be an issue with us accidentally shutting off the aux block when putting the sink into D3, but since the DP spec mandates that sinks must wake up within 1ms while we have 100ms to respond to an ESI irq, this didn't really add up. Turns out that the problem is more subtle then that: It turns out that the timeout is from us not enabling DPMS on the MST hub before actually trying to initiate sideband communications. This would cause the first sideband communication (power_up_phy()), to start timing out because the sink wasn't ready to respond. Afterwards, we would call intel_dp_sink_dpms(DRM_MODE_DPMS_ON) in intel_ddi_pre_enable_dp(), which would actually result in waking up the sink so that sideband requests would work again. Since DPMS is what lets us actually bring the hub up into a state where sideband communications become functional again, we just need to make sure to enable DPMS on the display before attempting to perform sideband communications. Changes since v1: - Remove comment above if (!intel_dp->is_mst) - vsryjala - Move intel_dp_sink_dpms() for MST into intel_dp_post_disable_mst() to keep enable/disable paths symmetrical - Improve commit message - dhnkrn Changes since v2: - Only send DPMS off when we're disabling the last sink, and only send DPMS on when we're enabling the first sink - dhnkrn Changes since v3: - Check against is_mst, not intel_dp->is_mst - dhnkrn/vsyrjala Signed-off-by: Lyude Paul <lyude@redhat.com> Reviewed-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Tested-by: Laura Abbott <labbott@redhat.com> Cc: stable@vger.kernel.org Fixes: ad260ab32a4d9 ("drm/i915/dp: Write to SET_POWER dpcd to enable MST hub.") Link: https://patchwork.freedesktop.org/patch/msgid/20180407011053.22437-1-lyude@redhat.com
2018-04-06drm/i915: Pass the set of guilty engines to i915_reset()Chris Wilson
Currently, we rely on inspecting the hangcheck state from within the i915_reset() routines to determine which engines were guilty of the hang. This is problematic for cases where we want to run i915_handle_error() and call i915_reset() independently of hangcheck. Instead of relying on the indirect parameter passing, turn it into an explicit parameter providing the set of stalled engines which then are treated as guilty until proven innocent. While we are removing the implicit stalled parameter, also make the reason into an explicit parameter to i915_reset(). We still need a back-channel for i915_handle_error() to hand over the task to the locked waiter, but let's keep that its own channel rather than incriminate another. This leaves stalled/seqno as being private to hangcheck, with no more nefarious snooping by reset, be it whole-device or per-engine. \o/ The only real issue now is that this makes it crystal clear that we don't actually do any testing of hangcheck per se in drv_selftest/live_hangcheck, merely of resets! Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Michel Thierry <michel.thierry@intel.com> Cc: Jeff McGee <jeff.mcgee@intel.com> Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com> Reviewed-by: Michel Thierry <michel.thierry@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180406220354.18911-2-chris@chris-wilson.co.uk
2018-04-06drm/i915: Treat i915_reset_engine() as guilty until proven innocentChris Wilson
If we are resetting just one engine, we know it has stalled. So we can pass the stalled parameter directly to i915_gem_reset_engine(), which alleviates the necessity to poke at the generic engine->hangcheck.stalled magic variable, leaving that under control of hangcheck as its name implies. Other than simplifying by removing the indirect parameter along this path, this allows us to introduce new reset mechanisms that run independently of hangcheck. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Michel Thierry <michel.thierry@intel.com> Cc: Jeff McGee <jeff.mcgee@intel.com> Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com> Reviewed-by: Michel Thierry <michel.thierry@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180406220354.18911-1-chris@chris-wilson.co.uk
2018-04-06drm/i915: Split out parking from the idle worker for reuseChris Wilson
We will want to park GEM before disengaging the drive^W^W^W unwedging. Since we already do the work for idling, expose the guts as a new function that we can then reuse. v2: Just skip if already parked; makes it more forgiving to use by future callers. v3: Extract mark_busy, rename it to i915_gem_unpark and place it next to i915_gem_park so that we can evaluate it for symmetry more easily. Calling GEM from inside i915_request looks to be a bit of a layering violation, for the moment I am imaging them as being notify_cb. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: Sagar Arun Kamble <sagar.a.kamble@intel.com> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com> Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com> #v1 Reviewed-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180406155144.27791-1-chris@chris-wilson.co.uk
2018-04-06drm/i915/selftests: Rename wait_for_hang() to wait_until_running()Chris Wilson
Tvrtko mentioned that wait_for_hang() was confusing as it does not actually wait for the aforementioned hang, just until the request is running and we are *ready* to inject a hang. A quick s/wait_for_hang/wait_until_running/ removes that confusion without having to rethink the naming scheme, immediately at least. Suggested-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com> Cc: Michel Thierry <michel.thierry@intel.com> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180406100950.19033-1-chris@chris-wilson.co.uk
2018-04-06drm/i915/icl: Enable RC6 and RPS in Gen11Oscar Mateo
AFAICT, once the new interrupt is in place, the rest should behave the same as Gen10. v2: Update ring frequencies (Sagar) v3: Rebase. Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Sagar Arun Kamble <sagar.a.kamble@intel.com> Cc: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Oscar Mateo <oscar.mateo@intel.com> Reviewed-by: Michel Thierry <michel.thierry@intel.com> Signed-off-by: Mika Kuoppala <mika.kuoppala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180405140052.10682-5-mika.kuoppala@linux.intel.com
2018-04-06drm/i915/icl: Deal with GT INT DW correctlyOscar Mateo
BSpec says: "Second level interrupt events are stored in the GT INT DW. GT INT DW is a double buffered structure. A snapshot of events is taken when SW reads GT INT DW. From the time of read to the time of SW completely clearing GT INT DW (to indicate end of service), all incoming interrupts are logged in a secondary storage structure. this guarantees that the record of interrupts SW is servicing will not change while under service". We read GT INT DW in several places now: - The IRQ handler (banks 0 and 1) where, hopefully, it is completely cleared (operation now covered with the irq lock). - The 'reset' interrupts functions for RPS and GuC logs, where we clear the bit we are interested in and leave the others for the normal interrupt handler. - The 'enable' interrupts functions for RPS and GuC logs, as a measure of precaution. Here we could relax a bit and don't check GT INT DW at all or, if we do, at least we should clear the offending bit (which is what this patch does). Note that, if every bit is cleared on reading GT INT DW, the register won't be locked. Also note that, according to the BSpec, GT INT DW cannot be cleared without first servicing the Selector & Shared IIR registers. v2: - Remove some code duplication (Tvrtko) - Make sure GT_INTR_DW are protected by the irq spinlock, since it's a global resource (Tvrtko) v3: Optimize the spinlock (Tvrtko) v4: Rebase. v5: - take spinlock on outer scope to please sparse (Mika) - use raw_reg accessors (Mika) v6: omit the continue in looping banks (Michel) Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Sagar Arun Kamble <sagar.a.kamble@intel.com> Signed-off-by: Oscar Mateo <oscar.mateo@intel.com> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> (v4) Signed-off-by: Mika Kuoppala <mika.kuoppala@linux.intel.com> Reviewed-by: Michel Thierry <michel.thierry@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180406093237.14548-1-mika.kuoppala@linux.intel.com
2018-04-06drm/i915/icl: Handle RPS interrupts correctly for Gen11Oscar Mateo
Using the new hierarchical interrupt infrastructure. v2: Rebase v3: Rebase v4: use class/instance handler (Mika) Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Sagar Arun Kamble <sagar.a.kamble@intel.com> Cc: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Oscar Mateo <oscar.mateo@intel.com> Signed-off-by: Mika Kuoppala <mika.kuoppala@linux.intel.com> Reviewed-by: Michel Thierry <michel.thierry@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180405140052.10682-3-mika.kuoppala@linux.intel.com
2018-04-06drm/i915/icl: Use hw engine class, instance to find irq handlerMika Kuoppala
Interrupt identity register we already read from hardware contains engine class and instance fields. Leverage these fields to find correct engine to handle the interrupt. v3: rebase on top of rps intr use correct class / instance limits (Michel) v4: split engine/other handling v5: empty iir is not err (Daniele, Michel) Suggested-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: Michel Thierry <michel.thierry@intel.com> Signed-off-by: Mika Kuoppala <mika.kuoppala@linux.intel.com> Reviewed-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Reviewed-by: Michel Thierry <michel.thierry@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180406093145.14389-1-mika.kuoppala@linux.intel.com
2018-04-06drm/i915/icl: Add reset control register changesMichel Thierry
The bits used to reset the different engines/domains have changed in GEN11, this patch maps the reset engine mask bits with the new bits in the reset control register. v2: Use shift-left instead of BIT macro to match the file style (Paulo). v3: Reuse gen8_reset_engines (Daniele). v4: Do not call intel_uncore_forcewake_reset after reset, we may be using the forcewake to read protected registers elsewhere and those results may be clobbered by the concurrent dropping of forcewake. bspec: 19212 Cc: Oscar Mateo <oscar.mateo@intel.com> Cc: Antonio Argenziano <antonio.argenziano@intel.com> Cc: Paulo Zanoni <paulo.r.zanoni@intel.com> Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Acked-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Signed-off-by: Michel Thierry <michel.thierry@intel.com> Reviewed-by: Oscar Mateo <oscar.mateo@intel.com> Signed-off-by: Mika Kuoppala <mika.kuoppala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180405140052.10682-1-mika.kuoppala@linux.intel.com
2018-04-06drm/i915: Describe the bottom of stack in processing a batchbufferKevin Rogovin
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: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/1523001957-6427-4-git-send-email-kevin.rogovin@intel.com
2018-04-06drm/i915: Add link to documentation in i915_gem_execbuffer.cKevin Rogovin
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 <kevin.rogovin@intel.com> Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> [Joonas: correcting the patch title] Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/1523001957-6427-3-git-send-email-kevin.rogovin@intel.com
2018-04-06drm/i915: Narration overview on GEMKevin Rogovin
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: Kevin Rogovin <kevin.rogovin@intel.com> Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com> [Joonas: correcting the patch title] Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/1523001957-6427-2-git-send-email-kevin.rogovin@intel.com
2018-04-06drm/i915/selftests: Avoid repeatedly harming the same innocent contextChris Wilson
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
2018-04-06drm/i915/audio: Fix audio enumeration issue on BXTGaurav K Singh
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
2018-04-06drm/i915: Fix memory leak in intel_hdcp authRadhakrishna Sripada
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: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180404225957.7457-1-radhakrishna.sripada@intel.com
2018-04-05drm/i915: Only call finish_reset after a prepare_resetChris Wilson
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: Chris Wilson <chris@chris-wilson.co.uk> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180405123714.3638-1-chris@chris-wilson.co.uk
2018-04-04drm/i915/selftests: Add basic sanitychecks for execlistsChris Wilson
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: Chris Wilson <chris@chris-wilson.co.uk> Cc: Michał Winiarski <michal.winiarski@intel.com> CC: Michel Thierry <michel.thierry@intel.com> Cc: Jeff McGee <jeff.mcgee@intel.com> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com> Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180404093329.5383-1-chris@chris-wilson.co.uk
2018-04-04drm/i915: Do no use kfree() to free a kmem_cache_alloc() return valueXidong Wang
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: d1b48c1e7184 ("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: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20180404093824.9313-1-chris@chris-wilson.co.uk
2018-04-04drm/i915: Check hdcp key loadabilityRamalingam C
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
2018-04-04drm/i915: Read Vprime thrice incase of mismatchRamalingam C
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 <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-3-git-send-email-ramalingam.c@intel.com
2018-04-04drm/i915: Read HDCP R0 thrice in case of mismatchRamalingam C
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: 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/1522669822-2508-1-git-send-email-ramalingam.c@intel.com
2018-04-04drm/i915: Store preemption capability in engine->flagsChris Wilson
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: Chris Wilson <chris@chris-wilson.co.uk> Cc: Tomasz Lis <tomasz.lis@intel.com> Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Michał Winiarski <michal.winiarski@intel.com> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Reviewed-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180403183537.5522-1-chris@chris-wilson.co.uk
2018-04-03drm/i915/execlists: Track begin/end of execlists submission sequencesChris Wilson
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: Chris Wilson <chris@chris-wilson.co.uk> Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com> Cc: Francisco Jerez <currojerez@riseup.net> Reviewed-by: Francisco Jerez <currojerez@riseup.net> Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180331130626.10712-1-chris@chris-wilson.co.uk
2018-03-30Merge airlied/drm-next into drm-intel-next-queuedRodrigo Vivi
Commit 'aee3bac0a3a8 ("drm/i915/psr: Tie PSR2 support to Y coordinate requirement")' got merged to drm-intel-next-queued but the variable was defined commit 'c5fe47327b06 ("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: Rodrigo Vivi <rodrigo.vivi@intel.com>
2018-03-30drm/i915/psr: Set DPCD PSR2 enable bit when neededJosé Roberto de Souza
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: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180328223046.16125-9-jose.souza@intel.com
2018-03-30drm/i915/psr: Cache sink synchronization latencyJosé Roberto de Souza
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: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: José Roberto de Souza <jose.souza@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180328223046.16125-8-jose.souza@intel.com
2018-03-30drm/i915/psr: Use PSR2 macro for PSR2José Roberto de Souza
Cosmetic change. Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: José Roberto de Souza <jose.souza@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180328223046.16125-7-jose.souza@intel.com
2018-03-30drm/i915/psr: Do not override PSR2 sink supportJosé Roberto de Souza
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: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: José Roberto de Souza <jose.souza@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180328223046.16125-6-jose.souza@intel.com
2018-03-30drm/i915/psr/cnl: Enable Y-coordinate support in sourceJosé Roberto de Souza
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: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: José Roberto de Souza <jose.souza@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180328223046.16125-5-jose.souza@intel.com
2018-03-30drm/i915/psr: Tie PSR2 support to Y coordinate requirementJosé Roberto de Souza
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: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> Signed-off-by: José Roberto de Souza <jose.souza@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180328223046.16125-4-jose.souza@intel.com
2018-03-30drm/i915/psr: Nuke aux frame syncJosé Roberto de Souza
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: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> Signed-off-by: José Roberto de Souza <jose.souza@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180328223046.16125-3-jose.souza@intel.com
2018-03-30drm: Add DP last received PSR SDP VSC register and bitsJosé Roberto de Souza
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 <jose.souza@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180328223046.16125-2-jose.souza@intel.com
2018-03-30drm: Add DP PSR2 sink enable bitJosé Roberto de Souza
To comply with eDP1.4a this bit should be set when enabling PSR2. Signed-off-by: José Roberto de Souza <jose.souza@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180328223046.16125-1-jose.souza@intel.com
2018-03-30drm/i915: Only warn for might_sleep() before a slow wait_for_registerChris Wilson
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 <chris@chris-wilson.co.uk> Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180329224519.13598-2-chris@chris-wilson.co.uk
2018-03-30drm/i915: Avoid sleeping inside per-engine resetChris Wilson
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: 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> Cc: Jeff McGee <jeff.mcgee@intel.com> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Reviewed-by: Michel Thierry <michel.thierry@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180329224519.13598-1-chris@chris-wilson.co.uk
2018-03-29drm/i915/perf: add more debug message on perf open & configsLionel Landwerlin
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
2018-03-29drm/i915: rename PPGTT/GGTT fields OA registersLionel Landwerlin
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 <lionel.g.landwerlin@intel.com> Reviewed-by: Matthew Auld <matthew.auld@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180326090831.22686-7-lionel.g.landwerlin@intel.com
2018-03-29drm/i915/perf: remove empty lineLionel Landwerlin
This was added by mistake in commit 28964cf25ee67 ("drm/i915/perf: disable NOA logic when not used"). 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-6-lionel.g.landwerlin@intel.com
2018-03-29drm/i915/perf: simplify OA unit enabling on gen7Lionel Landwerlin
In commit d79651522e89c ("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 <lionel.g.landwerlin@intel.com> Reviewed-by: Matthew Auld <matthew.auld@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180326090831.22686-4-lionel.g.landwerlin@intel.com
2018-03-29drm/i915/perf: check the value of PROP_SAMPLE_OA uapi parameterLionel Landwerlin
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 <lionel.g.landwerlin@intel.com> Reviewed-by: Matthew Auld <matthew.auld@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180326090831.22686-3-lionel.g.landwerlin@intel.com
2018-03-29drm/i915/perf: enable perf support on ICLLionel Landwerlin
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: Lionel Landwerlin <lionel.g.landwerlin@intel.com> Reviewed-by: Matthew Auld <matthew.auld@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180326133949.12469-3-lionel.g.landwerlin@intel.com
2018-03-29drm/i915: Include the HW breadcrumb whenever we trace the global_seqnoChris Wilson
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: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20180327210157.16896-3-chris@chris-wilson.co.uk Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
2018-03-29drm/i915/guc: enable guc interrupts unconditionally in uc_resumeMichel Thierry
Probably lost while rebasing commit eacd8391f977 ("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: Michel Thierry <michel.thierry@intel.com> Cc: Michał Winiarski <michal.winiarski@intel.com> Reviewed-by: Michał Winiarski <michal.winiarski@intel.com> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20180328205851.16188-1-michel.thierry@intel.com
2018-03-29Merge branch 'drm-misc-next-fixes' of ↵Dave Airlie
git://anongit.freedesktop.org/drm/drm-misc into drm-next - 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
2018-03-28drm/i915/guc: Trace messages from CT while in debugMichal Wajdeczko
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: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20180326194829.58836-12-michal.wajdeczko@intel.com
2018-03-28drm/i915/guc: Handle default action received over CTMichal Wajdeczko
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 <michal.wajdeczko@intel.com> Cc: Oscar Mateo <oscar.mateo@intel.com> Reviewed-by: Michel Thierry <michel.thierry@intel.com> #1 Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Acked-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20180327214124.70680-1-michal.wajdeczko@intel.com
generated by cgit v1.2.3 (git 2.39.1) at 2025-08-01 17:15:30 +0000