summaryrefslogtreecommitdiff
path: root/drivers/gpu/drm/i915/i915_debugfs.c
AgeCommit message (Collapse)AuthorFilesLines
2019-01-10drm/i915: Skip the ERR_PTR error stateChris Wilson1-3/+9
Although commit fb6f0b64e455 ("drm/i915: Prevent machine hang from Broxton's vtd w/a and error capture") applied cleanly after a 24 month hiatus, the code had moved on with new methods for peeking and fetching the captured gpu info. Make sure we catch all uses of the stashed error state and avoid dereferencing the error pointer. v2: Move error pointer determination into i915_gpu_capture_state v3: Restore early check to avoid capturing and then throwing away subsequent GPU error states. Fixes: fb6f0b64e455 ("drm/i915: Prevent machine hang from Broxton's vtd w/a and error capture") Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181207110554.19897-1-chris@chris-wilson.co.uk (cherry picked from commit e6154e4cb8b0d3692f84ca0d66b4e1ba0389b134) Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2018-12-04drm/i915: Fuse per-context workaround handling with the common frameworkTvrtko Ursulin1-5/+7
Convert the per context workaround handling code to run against the newly introduced common workaround framework and fuse the two to use the existing smarter list add helper, the one which does the sorted insert and merges registers where possible. This completes migration of all four classes of workarounds onto the common framework. Existing macros are kept untouched for smaller code churn. v2: * Rename to list name ctx_wa_list and move from dev_priv to engine. v3: * API rename and parameters tweaking. (Chris Wilson) Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20181203133357.10341-1-tvrtko.ursulin@linux.intel.com
2018-11-28drm/i915: Move ddb/wm programming into plane update/disable hooks on skl+Ville Syrjälä1-10/+11
On SKL+ the plane WM/BUF_CFG registers are a proper part of each plane's register set. That means accessing them will cancel any pending plane update, and we would need a PLANE_SURF register write to arm the wm/ddb change as well. To avoid all the problems with that let's just move the wm/ddb programming into the plane update/disable hooks. Now all plane registers get written in one (hopefully atomic) operation. To make that feasible we'll move the plane ddb tracking into the crtc state. Watermarks were already tracked there. v2: Rebase due to input CSC v3: Split out a bunch of junk (Matt) v4: Add skl_wm_add_affected_planes() to deal with cursor special case and non-zero wm register reset value v5: Drop the unrelated for_each_intel_plane_mask() fix (Matt) Remove the redundant ddb memset() (Matt) Cc: Matt Roper <matthew.d.roper@intel.com> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> #v3 Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181127165900.31298-1-ville.syrjala@linux.intel.com
2018-11-23drm/i915: Cache the error stringChris Wilson1-14/+14
Currently, we convert the error state into a string every time we read from sysfs (and sysfs reads in page size (4KiB) chunks). We do try to window the string and only capture the portion that is being read, but that means that we must always convert up to the window to find the start. For a very large error state bordering on EXEC_OBJECT_CAPTURE abuse, this is noticeable as it degrades to O(N^2)! As we do not have a convenient hook for sysfs open(), and we would like to keep the lazy conversion into a string, do the conversion of the whole string on the first read and keep the string until the error state is freed. v2: Don't double advance simple_read_from_buffer v3: Due to extreme pain of lack of vrealloc, use a scatterlist v4: Keep the forward iterator loosely cached v5: Stylistic improvements to reduce patch size Reported-by: Jason Ekstrand <jason@jlekstrand.net> Testcase: igt/gem_exec_capture/many* Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com> Cc: Jason Ekstrand <jason@jlekstrand.net> Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181123132325.26541-1-chris@chris-wilson.co.uk
2018-11-22drm/i915: Synchronize hpd work in i915_hpd_storm_ctl_show()Lyude Paul1-0/+7
While trying to add a chamelium test for short HPD IRQs, I ran into issues where a hotplug storm would be triggered, but the point at which it would be reported by the kernel would be after igt actually finished checking i915_hpd_storm_ctl's status. So, fix this by simply synchronizing our IRQ work, dig_port_work, and hotplug_work before printing out the HPD storm status in i915_hpd_storm_ctl_show(). Signed-off-by: Lyude Paul <lyude@redhat.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20181121003718.17704-1-lyude@redhat.com
2018-11-21drm/i915: fix spelling mistake "reserverd" -> "reserved"Alexandre Belloni1-1/+1
Fix a spelling mistake in a comment. Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181120151415.32419-1-alexandre.belloni@bootlin.com
2018-11-20drm/i915/ilk: Fix warning when reading emon_status with no outputJosé Roberto de Souza1-0/+4
When there is no output no one will hold a runtime_pm reference causing a warning when trying to read emom_status in debugfs. [22.756480] ------------[ cut here ]------------ [22.756489] RPM wakelock ref not held during HW access [22.756578] WARNING: CPU: 0 PID: 1058 at drivers/gpu/drm/i915/intel_drv.h:2104 gen5_read32+0x16b/0x1a0 [i915] [22.756580] Modules linked in: snd_hda_codec_hdmi snd_hda_codec_realtek snd_hda_codec_generic i915 coretemp crct10dif_pclmul crc32_pclmul ghash_clmulni_intel snd_hda_intel snd_hda_codec snd_hwdep snd_hda_core e1000e snd_pcm mei_me prime_numbers mei lpc_ich [22.756595] CPU: 0 PID: 1058 Comm: debugfs_test Not tainted 4.20.0-rc1-CI-Trybot_3219+ #1 [22.756597] Hardware name: Hewlett-Packard HP Compaq 8100 Elite SFF PC/304Ah, BIOS 786H1 v01.13 07/14/2011 [22.756634] RIP: 0010:gen5_read32+0x16b/0x1a0 [i915] [22.756637] Code: a4 ea e0 0f 0b e9 d2 fe ff ff 80 3d a5 71 19 00 00 0f 85 d3 fe ff ff 48 c7 c7 48 d0 2d a0 c6 05 91 71 19 00 01 e8 35 a4 ea e0 <0f> 0b e9 b9 fe ff ff e8 69 c6 f2 e0 85 c0 75 92 48 c7 c2 78 d0 2d [22.756639] RSP: 0018:ffffc90000f1fd38 EFLAGS: 00010282 [22.756642] RAX: 0000000000000000 RBX: ffff8801f7ab0000 RCX: 0000000000000006 [22.756643] RDX: 0000000000000006 RSI: ffffffff8212886a RDI: ffffffff820d6d57 [22.756645] RBP: 0000000000011020 R08: 0000000043e3d1a8 R09: 0000000000000000 [22.756647] R10: ffffc90000f1fd80 R11: 0000000000000000 R12: 0000000000000001 [22.756649] R13: ffff8801f7ab0068 R14: 0000000000000001 R15: ffff88020d53d188 [22.756651] FS: 00007f2878849980(0000) GS:ffff880213a00000(0000) knlGS:0000000000000000 [22.756653] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [22.756655] CR2: 00005638deedf028 CR3: 0000000203292001 CR4: 00000000000206f0 [22.756657] Call Trace: [22.756689] i915_mch_val+0x1b/0x60 [i915] [22.756721] i915_emon_status+0x45/0xd0 [i915] [22.756730] seq_read+0xdb/0x3c0 [22.756736] ? lockdep_hardirqs_off+0x94/0xd0 [22.756740] ? __slab_free+0x24e/0x510 [22.756746] full_proxy_read+0x52/0x90 [22.756752] __vfs_read+0x31/0x170 [22.756759] ? do_sys_open+0x13b/0x240 [22.756763] ? rcu_read_lock_sched_held+0x6f/0x80 [22.756766] vfs_read+0x9e/0x140 [22.756770] ksys_read+0x50/0xc0 [22.756775] do_syscall_64+0x55/0x190 [22.756781] entry_SYSCALL_64_after_hwframe+0x49/0xbe [22.756783] RIP: 0033:0x7f28781dc34e [22.756786] Code: 00 00 00 00 48 8b 15 71 8c 20 00 f7 d8 64 89 02 48 c7 c0 ff ff ff ff c3 0f 1f 40 00 8b 05 ba d0 20 00 85 c0 75 16 31 c0 0f 05 <48> 3d 00 f0 ff ff 77 5a f3 c3 0f 1f 84 00 00 00 00 00 41 54 55 49 [22.756787] RSP: 002b:00007ffd33fa0d08 EFLAGS: 00000246 ORIG_RAX: 0000000000000000 [22.756790] RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f28781dc34e [22.756792] RDX: 0000000000000200 RSI: 00007ffd33fa0d50 RDI: 0000000000000008 [22.756794] RBP: 00007ffd33fa0f60 R08: 0000000000000000 R09: 0000000000000020 [22.756796] R10: 0000000000000000 R11: 0000000000000246 R12: 00005638de45c2c0 [22.756797] R13: 00007ffd33fa14b0 R14: 0000000000000000 R15: 0000000000000000 [22.756806] irq event stamp: 47950 [22.756811] hardirqs last enabled at (47949): [<ffffffff810fba74>] vprintk_emit+0x124/0x320 [22.756813] hardirqs last disabled at (47950): [<ffffffff810019b0>] trace_hardirqs_off_thunk+0x1a/0x1c [22.756816] softirqs last enabled at (47518): [<ffffffff81c0033a>] __do_softirq+0x33a/0x4b9 [22.756820] softirqs last disabled at (47479): [<ffffffff8108df29>] irq_exit+0xa9/0xc0 [22.756858] WARNING: CPU: 0 PID: 1058 at drivers/gpu/drm/i915/intel_drv.h:2104 gen5_read32+0x16b/0x1a0 [i915] [22.756860] ---[ end trace bf56fa7d6a3cbf7a ] Signed-off-by: José Roberto de Souza <jose.souza@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181119230101.32460-1-jose.souza@intel.com
2018-11-07drm/i915: Add short HPD IRQ storm detection for non-MST systemsLyude Paul1-0/+74
Unfortunately, it seems that the HPD IRQ storm problem from the early days of Intel GPUs was never entirely solved, only mostly. Within the last couple of days, I got a bug report from one of our customers who had been having issues with their machine suddenly booting up very slowly after having updated. The amount of time it took to boot went from around 30 seconds, to over 6 minutes consistently. After some investigation, I discovered that i915 was reporting massive amounts of short HPD IRQ spam on this system from the DisplayPort port, despite there not being anything actually connected. The symptoms would start with one "long" HPD IRQ being detected at boot: [ 1.891398] [drm:intel_get_hpd_pins [i915]] hotplug event received, stat 0x00440000, dig 0x00440000, pins 0x000000a0 [ 1.891436] [drm:intel_hpd_irq_handler [i915]] digital hpd port B - long [ 1.891472] [drm:intel_hpd_irq_handler [i915]] Received HPD interrupt on PIN 5 - cnt: 0 [ 1.891508] [drm:intel_hpd_irq_handler [i915]] digital hpd port D - long [ 1.891544] [drm:intel_hpd_irq_handler [i915]] Received HPD interrupt on PIN 7 - cnt: 0 [ 1.891592] [drm:intel_dp_hpd_pulse [i915]] got hpd irq on port B - long [ 1.891628] [drm:intel_dp_hpd_pulse [i915]] got hpd irq on port D - long … followed by constant short IRQs afterwards: [ 1.895091] [drm:intel_encoder_hotplug [i915]] [CONNECTOR:66:DP-1] status updated from unknown to disconnected [ 1.895129] [drm:i915_hotplug_work_func [i915]] Connector DP-3 (pin 7) received hotplug event. [ 1.895165] [drm:intel_dp_detect [i915]] [CONNECTOR:72:DP-3] [ 1.895275] [drm:intel_get_hpd_pins [i915]] hotplug event received, stat 0x00200000, dig 0x00200000, pins 0x00000080 [ 1.895312] [drm:intel_hpd_irq_handler [i915]] digital hpd port D - short [ 1.895762] [drm:intel_get_hpd_pins [i915]] hotplug event received, stat 0x00200000, dig 0x00200000, pins 0x00000080 [ 1.895799] [drm:intel_hpd_irq_handler [i915]] digital hpd port D - short [ 1.896239] [drm:intel_dp_aux_xfer [i915]] dp_aux_ch timeout status 0x71450085 [ 1.896293] [drm:intel_get_hpd_pins [i915]] hotplug event received, stat 0x00200000, dig 0x00200000, pins 0x00000080 [ 1.896330] [drm:intel_hpd_irq_handler [i915]] digital hpd port D - short [ 1.896781] [drm:intel_get_hpd_pins [i915]] hotplug event received, stat 0x00200000, dig 0x00200000, pins 0x00000080 [ 1.896817] [drm:intel_hpd_irq_handler [i915]] digital hpd port D - short [ 1.897275] [drm:intel_get_hpd_pins [i915]] hotplug event received, stat 0x00200000, dig 0x00200000, pins 0x00000080 The customer's system in question has a GM45 GPU, which is apparently well known for hotplugging storms. So, workaround this impressively broken hardware by changing the default HPD storm threshold from 5 to 50. Then, make long IRQs count for 10, and short IRQs count for 1. This makes it so that 5 long IRQs will trigger an HPD storm, and on systems with short HPD storm detection 50 short IRQs will trigger an HPD storm. 50 short IRQs amounts to 100ms of constant pulsing, which seems like a good middleground between being too sensitive and not being sensitive enough (which would cause visible stutters in userspace every time a storm occurs). And just to be extra safe: we don't enable this by default on systems with MST support. There's too high of a chance of MST support triggering storm detection, and systems that are new enough to support MST are a lot less likely to have issues with IRQ storms anyway. As a note: this patch was tested using a ThinkPad T450s and a Chamelium to simulate the short IRQ storms. Changes since v1: - Don't use two separate thresholds, just make long IRQs count for 10 each and short IRQs count for 1. This simplifies the code a bit - Ville Syrjälä Changes since v2: - Document @long_hpd in intel_hpd_irq_storm_detect, no functional changes Changes since v4: - Remove !! in long_hpd assignment - Ville Syrjälä - queue_hp = true - Ville Syrjälä Signed-off-by: Lyude Paul <lyude@redhat.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181106213017.14563-6-lyude@redhat.com
2018-11-05drm/i915/gen9_lp: Fix DMC DC counter debugfs outputImre Deak1-7/+7
On GEN9 LP (BXT/GLK) DC6 is not supported, so don't print the counter on those platforms. So far we did this on GLK too. While at it warn if we forgot to adjust the printout properly for a new platform. (Rodrigo) Testcase: igt/pm_dc/dc6-dpms Cc: Jyoti Yadav <jyoti.r.yadav@intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181031200220.11608-1-imre.deak@intel.com
2018-10-31drm/i915/debugfs: Do not print cached information of a disconnected sinkJosé Roberto de Souza1-10/+11
Besides of give the expected output of i915_display_info it will also avoid some aux ch transactions that would timeout by obvious reasons. Reviewed-by: Ville Syrjälä <ville.syrjala@linux.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/20181030215750.28213-1-jose.souza@intel.com
2018-10-29drm/i915: wrapping all hdcp var into intel_hdcpRamalingam C1-1/+1
Considering significant number of HDCP specific variables, it will be clean to have separate struct for HDCP. New structure called intel_hdcp is added within intel_connector. v2: struct hdcp statically allocated. [Sean Paul] enable and disable function parameters are retained.[Sean Paul] v3: No Changes. v4: Commit msg is rephrased [Uma] v5: Comment for mutex definition. v6: hdcp_ prefix from all intel_hdcp members are removed [Sean Paul] inline function intel_hdcp_to_connector is defined [Sean Paul] v7: %s/uint64_t/u64 v8: Rebased Signed-off-by: Ramalingam C <ramalingam.c@intel.com> Reviewed-by: Sean Paul <seanpaul@chromium.org> Reviewed-by: Uma Shankar <uma.shankar@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/1540806351-7137-2-git-send-email-ramalingam.c@intel.com
2018-10-24drm/i915/debugfs: hdcp capability of a sinkRamalingam C1-0/+29
Add a debugfs entry for providing the hdcp capabilities of the sink connected to the HDCP capable connectors. v2: Squashed the sink's hdcp capability into this patch. [Daniel] Signed-off-by: Ramalingam C <ramalingam.c@intel.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/1540286550-20399-4-git-send-email-ramalingam.c@intel.com
2018-10-18drm/i915: Drop rpm wakeref on error in debugfs/i915_drop_caches_setJoonas Lahtinen1-1/+2
Use single exit point to drop rpm wakeref in case of an error. Fixes: 9d3eb2c33f03 ("drm/i915: Hold rpm wakeref for debugfs/i915_drop_caches_set") Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20181018092025.24076-1-joonas.lahtinen@linux.intel.com
2018-10-17drm/i915: Remove crtc->config dereference from drrs_ctlMaarten Lankhorst1-12/+42
Wait for idle, and iterate over connectors instead of encoders. With this information we know crtc->state is the actual state, and we can enable/disable drrs safely. Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181011100457.8776-2-maarten.lankhorst@linux.intel.com Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
2018-10-15drm/i915: Hold rpm wakeref for debugfs/i915_drop_caches_setChris Wilson1-4/+4
Since we peek into HW state and poke around, it behoves us to acquire a runtime pm wakeref beforehand. References: https://bugs.freedesktop.org/show_bug.cgi?id=108343 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=108364 Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181015115856.18590-1-chris@chris-wilson.co.uk
2018-10-12drm/i915/csr Added DC5 and DC6 counter register for ICL in debugfs entry.Jyoti Yadav1-5/+4
DC5 and DC6 counter register tells about residency of DC5 and DC6. Added the same in debugfs file. v2 : Remove csr_version check. Added generic check regarding DC counters for Gen9 onwards. (Rodrigo) v3 : Simplified gen checks. (Chris) v4 : Simplified "if" ladder for multiple gens. v5 : Removed unnecessary comment. Signed-off-by: Jyoti Yadav <jyoti.r.yadav@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/1538762926-4880-1-git-send-email-jyoti.r.yadav@intel.com
2018-10-10drm/i915: Show the DPCD read error inlineChris Wilson1-7/+4
When reporting the DPCD dump through debugfs, show the errors inline where appropriate. If a read at one particular offset fails, report it. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=106371 Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181010081706.29931-1-chris@chris-wilson.co.uk
2018-10-05drm/i915: Only reset seqno if actually idleChris Wilson1-1/+1
Before we can reset the seqno, we have to be sure the engines are idle. In debugfs/i915_drop_caches_set, we do wait_for_idle but allow ourselves to be interrupted. We should only proceed to reset the seqno then if we were not interrupted, and so also avoid overwriting the error status. References: https://bugs.freedesktop.org/show_bug.cgi?id=108133 Fixes: 6b048706f407 ("drm/i915: Forcibly flush unwanted requests in drop-caches") Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181004082119.24970-1-chris@chris-wilson.co.uk
2018-10-02drm/i915: Show actual alongside requested frequency in ↵Chris Wilson1-2/+18
debugfs/i915_rps_boost_info Previously we hesitated in adding the hw probe for the actual GPU frequency for rps_boost as it is quite cumbersome, but given some surprising HW behaviour it would be useful to know both the RPS boost state and the actual HW state in one location. v2: vlv/chv needs more tlc Reported-by: Tomi Sarvela <tomi.p.sarvela@intel.com> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181002113221.29208-1-chris@chris-wilson.co.uk
2018-09-07drm/i915: Missed interrupt simulation is no more, tell the worldChris Wilson1-0/+11
Using the guc, we cannot disable the user interrupt generation as we use it for driving submission. And from Icelake, we no longer have the ability to individually mask interrupt generation from each engine, disabling our ability to fake missed interrupts. In both cases, report back to userspace that the missed interrupt generator is no longer available. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com> Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180907112856.28242-1-chris@chris-wilson.co.uk
2018-09-05drm/i915: Reduce context HW ID lifetimeChris Wilson1-1/+4
Future gen reduce the number of bits we will have available to differentiate between contexts, so reduce the lifetime of the ID assignment from that of the context to its current active cycle (i.e. only while it is pinned for use by the HW, will it have a constant ID). This means that instead of a max of 2k allocated contexts (worst case before fun with bit twiddling), we instead have a limit of 2k in flight contexts (minus a few that have been pinned by the kernel or by perf). To reduce the number of contexts id we require, we allocate a context id on first and mark it as pinned for as long as the GEM context itself is, that is we keep it pinned it while active on each engine. If we exhaust our context id space, then we try to reclaim an id from an idle context. In the extreme case where all context ids are pinned by active contexts, we force the system to idle in order to recover ids. We cannot reduce the scope of an HW-ID to an engine (allowing the same gem_context to have different ids on each engine) as in the future we will need to preassign an id before we know which engine the context is being executed on. v2: Improved commentary (Tvrtko) [I tried at least] References: https://bugs.freedesktop.org/show_bug.cgi?id=107788 Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Lionel Landwerlin <lionel.g.landwerlin@intel.com> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: Mika Kuoppala <mika.kuoppala@intel.com> Cc: Michel Thierry <michel.thierry@intel.com> Cc: Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180904153117.3907-1-chris@chris-wilson.co.uk
2018-09-03drm/i915: Forcibly flush unwanted requests in drop-cachesChris Wilson1-16/+36
Add a mode to debugfs/drop-caches to flush unwanted requests off the GPU (by wedging the device and resetting). This is very useful if a test terminated leaving a long queue of hanging batches that would ordinarily require a round trip through hangcheck for each. It reduces the inter-test operation to just a write into drop-caches to reset driver/GPU state between tests. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180903083337.13134-5-chris@chris-wilson.co.uk
2018-08-22drm/i915/psr: Add PSR mode/revision to debugfsAzhar Shaikh1-0/+2
Log the PSR mode/revision (PSR1 or PSR2) in the debugfs file i915_edp_psr_status. Suggested-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> Signed-off-by: Azhar Shaikh <azhar.shaikh@intel.com> Reviewed-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> Signed-off-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/1534958628-193724-1-git-send-email-azhar.shaikh@intel.com
2018-08-21drm/i915/psr: Add missing check for I915_PSR_DEBUG_IRQ bitDhinakaran Pandiyan1-1/+1
We print the last attempted entry and last exit timestamps only when IRQ debug is requested. This check was missed when new debug flags were added in 'commit c44301fce614 ("drm/i915: Allow control of PSR at runtime through debugfs, v6") Fixes: c44301fce614 ("drm/i915: Allow control of PSR at runtime through debugfs, v6") Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180821221156.2442-2-dhinakaran.pandiyan@intel.com
2018-08-10drm/i915: Allow control of PSR at runtime through debugfs, v6Maarten Lankhorst1-4/+19
Currently tests modify i915.enable_psr and then do a modeset cycle to change PSR. We can write a value to i915_edp_psr_debug to force a certain PSR mode without a modeset. To retain compatibility with older userspace, we also still allow the override through the module parameter, and add some tracking to check whether a debugfs mode is specified. Changes since v1: - Rename dev_priv->psr.enabled to .dp, and .hw_configured to .enabled. - Fix i915_psr_debugfs_mode to match the writes to debugfs. - Rename __i915_edp_psr_write to intel_psr_set_debugfs_mode, simplify it and move it to intel_psr.c. This keeps all internals in intel_psr.c - Perform an interruptible wait for hw completion outside of the psr lock, instead of being forced to trywait and return -EBUSY. Changes since v2: - Rebase on top of intel_psr changes. Changes since v3: - Assign psr.dp during init. (dhnkrn) - Add prepared bool, which should be used instead of relying on psr.dp. (dhnkrn) - Fix -EDEADLK handling in debugfs. (dhnkrn) - Clean up waiting for idle in intel_psr_set_debugfs_mode. - Print PSR mode when trying to enable PSR. (dhnkrn) - Move changing psr debug setting to i915_edp_psr_debug_set. (dhnkrn) Changes since v4: - Return error in _set() function. - Change flag values to make them easier to remember. (dhnkrn) - Only assign psr.dp once. (dhnkrn) - Only set crtc_state->has_psr on the crtc with psr.dp. - Fix typo. (dhnkrn) Changes since v5: - Only wait for PSR idle on the PSR connector correctly. (dhnkrn) - Reinstate WARN_ON(drrs.dp) in intel_psr_enable. (dhnkrn) - Remove stray comment. (dhnkrn) - Be silent in intel_psr_compute_config on wrong connector. (dhnkrn) Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180809142101.26155-1-maarten.lankhorst@linux.intel.com Reviewed-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
2018-08-08drm/i915: Constify power well descriptorsImre Deak1-2/+2
It makes sense to keep unchanging data const. Extract such fields from the i915_power_well struct into a new i915_power_well_desc struct that we initialize during compile time. For the rest of the dynamic fields allocate an array of i915_power_well objects in i915 dev_priv, and link to each of these objects their corresponding i915_power_well_desc object. v2: - Fix checkpatch warnings about missing param name in fn declaration and lines over 80 chars. (Paulo) - Move check for unique IDs to __set_power_wells(). Cc: Ville Syrjala <ville.syrjala@linux.intel.com> Cc: Paulo Zanoni <paulo.r.zanoni@intel.com> Cc: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> [Fixed checkpatch warn in __set_power_wells()] Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180806095843.13294-5-imre.deak@intel.com
2018-07-31drm/i915: Interactive RPS modeChris Wilson1-5/+8
RPS provides a feedback loop where we use the load during the previous evaluation interval to decide whether to up or down clock the GPU frequency. Our responsiveness is split into 3 regimes, a high and low plateau with the intent to keep the gpu clocked high to cover occasional stalls under high load, and low despite occasional glitches under steady low load, and inbetween. However, we run into situations like kodi where we want to stay at low power (video decoding is done efficiently inside the fixed function HW and doesn't need high clocks even for high bitrate streams), but just occasionally the pipeline is more complex than a video decode and we need a smidgen of extra GPU power to present on time. In the high power regime, we sample at sub frame intervals with a bias to upclocking, and conversely at low power we sample over a few frames worth to provide what we consider to be the right levels of responsiveness respectively. At low power, we more or less expect to be kicked out to high power at the start of a busy sequence by waitboosting. Prior to commit e9af4ea2b9e7 ("drm/i915: Avoid waitboosting on the active request") whenever we missed the frame or stalled, we would immediate go full throttle and upclock the GPU to max. But in commit e9af4ea2b9e7, we relaxed the waitboosting to only apply if the pipeline was deep to avoid over-committing resources for a near miss. Sadly though, a near miss is still a miss, and perceptible as jitter in the frame delivery. To try and prevent the near miss before having to resort to boosting after the fact, we use the pageflip queue as an indication that we are in an "interactive" regime and so should sample the load more frequently to provide power before the frame misses it vblank. This will make us more favorable to providing a small power increase (one or two bins) as required rather than going all the way to maximum and then having to work back down again. (We still keep the waitboosting mechanism around just in case a dramatic change in system load requires urgent uplocking, faster than we can provide in a few evaluation intervals.) v2: Reduce rps_set_interactive to a boolean parameter to avoid the confusion of what if they wanted a new power mode after pinning to a different mode (which to choose?) v3: Only reprogram RPS while the GT is awake, it will be set when we wake the GT, and while off warns about being used outside of rpm. v4: Fix deferred application of interactive mode v5: s/state/interactive/ v6: Group the mutex with its principle in a substruct Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107111 Fixes: e9af4ea2b9e7 ("drm/i915: Avoid waitboosting on the active request") Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: Radoslaw Szwichtenberg <radoslaw.szwichtenberg@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180731132629.3381-1-chris@chris-wilson.co.uk
2018-07-20drm/i915: Fix psr sink status report.Rodrigo Vivi1-2/+11
First of all don't try to read dpcd if PSR is not even supported. But also, if read failed return -EIO instead of reporting via a backchannel. v2: fix dev_priv: At this level m->private is the connector. (CI/DK) don't convert dpcd read errors to EIO. (DK) Fixes: 5b7b30864d1d ("drm/i915/psr: Split sink status into a separate debugfs node") Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> Cc: José Roberto de Souza <jose.souza@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180720003155.16290-1-rodrigo.vivi@intel.com
2018-07-18drm/i915: Kill sink_crc for goodRodrigo Vivi1-81/+0
It was originally introduced following the VESA spec in order to validate PSR. However we found so many issues around sink_crc that instead of helping PSR development it only brought another layer of trouble to the table. So, sink_crc has been a black whole for us in question of time, effort and hope. First of the problems is that HW statement is clear: "Do not attempt to use aux communication with PSR enabled". So the main reason behind sink_crc is already compromised. For a while we had hope on the aux-mutex could workaround this problem on SKL+ platforms, but that mutex was not reliable, not tested, and we shouldn't use according to HW engineers. Also, nor source, nor sink designed and implemented the sink_crc to be used like we are trying to use here. Well, the sink side of things is also apparently not prepared for this case. Each panel that we tried seemed to have a different behavior with same code and same source. So, for all the time we lost on trying to ducktape all these different issues I believe it is now time to move PSR to a more reliable validation. Maybe not a perfect one as we dreamed for this sink_crc, but at least more reliable. Cc: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180705192528.30515-1-rodrigo.vivi@intel.com
2018-07-12drm/i915/psr: Split sink status into a separate debugfs nodeDhinakaran Pandiyan1-30/+39
This allows to read i915_edp_psr_status from tests without triggering any AUX communication. Take this opportunity to move this under the eDP-1 connector directory as the status we print is of the sink. Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: José Roberto de Souza <jose.souza@intel.com> Suggested-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180705003121.2478-1-dhinakaran.pandiyan@intel.com
2018-07-09drm/i915: Provide a timeout to i915_gem_wait_for_idle()Chris Wilson1-2/+4
Usually we have no idea about the upper bound we need to wait to catch up with userspace when idling the device, but in a few situations we know the system was idle beforehand and can provide a short timeout in order to very quickly catch a failure, long before hangcheck kicks in. In the following patches, we will use the timeout to curtain two overly long waits, where we know we can expect the GPU to complete within a reasonable time or declare it broken. In particular, with a broken GPU we expect it to fail during the initial GPU setup where do a couple of context switches to record the defaults. This is a task that takes a few milliseconds even on the slowest of devices, but we may have to wait 60s for hangcheck to give in and declare the machine inoperable. In this a case where any gpu hang is unacceptable, both from a timeliness and practical standpoint. The other improvement is that in selftests, we do not need to arm an independent timer to inject a wedge, as we can just limit the timeout on the wait directly. v2: Include the timeout parameter in the trace. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180709122044.7028-1-chris@chris-wilson.co.uk
2018-07-06drm/i915: Remove support for legacy debugfs crc interfaceMaarten Lankhorst1-6/+1
This interface is deprecated, and has been replaced by the upstream drm crc interface. Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Tomi Sarvela <tomi.p.sarvela@intel.com> Cc: Petri Latvala <petri.latvala@intel.com> Cc: Jani Nikula <jani.nikula@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Acked-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Acked-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180628072303.14175-1-maarten.lankhorst@linux.intel.com
2018-07-02drm/i915/psr: Add psr1 live statusVathsala Nagaraju1-24/+48
Prints live state of psr1.Extending the existing PSR2 live state function to cover psr1. Tested on KBL with psr2 and psr1 panel. v2: rebase v3: DK Rename psr2_live_status to psr_source_status. v4: DK Move EDP_PSR_STATUS_STATE_SHIFT below EDP_PSR_STATUS_STATE_MASK. Pass seq to psr_source_status, handle source status prints in psr_source_status. v5: Fixed CI warning messages v6: Remove extra space in the title before the colon.(DK) Rebase. (Jani) v7: Use tabs for indenting the values.(Jani) v8: Addressed dk's review comments. Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> Reviewed-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> Signed-off-by: Vathsala Nagaraju <vathsala.nagaraju@intel.com> Signed-off-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/1530086910-15914-1-git-send-email-vathsala.nagaraju@intel.com
2018-06-29drm/i915: Remove delayed FBC activation.Maarten Lankhorst1-5/+0
The only time we should start FBC is when we have waited a vblank after the atomic update. We've already forced a vblank wait by doing wait_for_flip_done before intel_post_plane_update(), so we don't need to wait a second time before enabling. Removing the worker simplifies the code and removes possible race conditions, like happening in 103167. Cc: Paulo Zanoni <paulo.r.zanoni@intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=103167 Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180625163758.10871-2-maarten.lankhorst@linux.intel.com Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
2018-06-15drm/i915: Keep the ctx workarounds tightly packedChris Wilson1-20/+5
For each platform, we have a few registers that are rewritten with different values -- they are not part of a sequence, just different parts of a masked register set at different times (e.g. platform and gen workarounds). Consolidate these into a single register write to keep the table compact, important since we are running of room in the current fixed sized buffer. While adjusting the construction of the wa table, make it non fatal so that the driver still loads but keeping the warning and extra details for inspection. Inspecting the changes for a Kabylake system, Before: Address val mask read 0x07014 0x20002000 0x00002000 0x00002100 0x0E194 0x01000100 0x00000100 0x00000114 0x0E4F0 0x81008100 0x00008100 0xFFFF8120 0x0E184 0x00200020 0x00000020 0x00000022 0x0E194 0x00140014 0x00000014 0x00000114 0x07004 0x00420042 0x00000042 0x000029C2 0x0E188 0x00080000 0x00000008 0x00008030 0x07300 0x80208020 0x00008020 0x00008830 0x07300 0x00100010 0x00000010 0x00008830 0x0E184 0x00020002 0x00000002 0x00000022 0x0E180 0x20002000 0x00002000 0x00002000 0x02580 0x00010000 0x00000001 0x00000004 0x02580 0x00060004 0x00000006 0x00000004 0x07014 0x01000100 0x00000100 0x00002100 0x0E100 0x00100010 0x00000010 0x00008050 After: Address val mask read 0x02580 0x00070004 0x00000007 0x00000004 0x07004 0x00420042 0x00000042 0x000029C2 0x07014 0x21002100 0x00002100 0x00002100 0x07300 0x80308030 0x00008030 0x00008830 0x0E100 0x00100010 0x00000010 0x00008050 0x0E180 0x20002000 0x00002000 0x00002000 0x0E184 0x00220022 0x00000022 0x00000022 0x0E188 0x00080000 0x00000008 0x00008030 0x0E194 0x01140114 0x00000114 0x00000114 0x0E4F0 0x81008100 0x00008100 0xFFFF8120 Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Oscar Mateo <oscar.mateo@intel.com> Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180615120207.13952-1-chris@chris-wilson.co.uk
2018-06-14drm/i915: Declare the driver wedged if hangcheck makes no progressChris Wilson1-2/+3
Hangcheck is our back up in case the GPU or the driver gets stuck. It detects when the GPU is not making any progress and issues a GPU reset. However, if the driver is failing to make any progress, we can get ourselves into a situation where we continually try resetting the GPU to no avail. Employ a second timeout such that if we continue to see the same seqno (the stalled engine has made no progress at all) over the course of several hangchecks, declare the driver wedged and attempt to start afresh. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Mika Kuoppala <mika.kuoppala@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180602104853.17140-1-chris@chris-wilson.co.uk Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com>
2018-06-14drm/i915/psr: Kill delays when activating psr back.Rodrigo Vivi1-2/+0
The immediate enabling was actually not an issue for the HW perspective for core platforms that have HW tracking. HW will wait few identical idle frames before transitioning to actual psr active anyways. Now that we removed VLV/CHV out of the picture completely we can safely remove any delays. Note that this patch also remove the delayed activation on HSW and BDW introduced by commit 'd0ac896a477d ("drm/i915: Delay first PSR activation.")'. This was introduced to fix a blank screen on VLV/CHV and also masked some frozen screens on other core platforms. Probably the same that we are now properly hunting and fixing. v2:(DK): Remove unnecessary WARN_ONs and make some other VLV | CHV more readable. v3: Do it regardless the timer rework. v4: (DK/CI): Add VLV || CHV check on cancel work at psr_disable. v5: Kill remaining items and fully rework activation functions. v6: Rebase on top of VLV/CHV clean-up and keep the reactivation on a regular non-delayed work to avoid extra delays on exit calls and allow us to add few more safety checks before real activation. Cc: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: José Roberto de Souza <jose.souza@intel.com> Reviewed-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180613192600.3955-1-rodrigo.vivi@intel.com
2018-06-12drm/i915/guc: Don't store runtime GuC log level in modparamPiotr Piórkowski1-2/+2
Currently we are using modparam as placeholder for GuC log level. Stop doing this and keep runtime GuC level in intel_guc_log struct. v2: - rename functions intel_guc_log_level_[get|set] to intel_guc_log_[get|set]_level (Michał Wajdeczko) - remove GEM_BUG_ON from intel_guc_log_get_level() (Michał Wajdeczko) Signed-off-by: Piotr Piórkowski <piotr.piorkowski@intel.com> Cc: Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: Michał Winiarski <michal.winiarski@intel.com> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20180604141947.8299-1-piotr.piorkowski@intel.com
2018-06-05drm/i915/gtt: Rename i915_hw_ppgtt base memberChris Wilson1-2/+2
In the near future, I want to subclass gen6_hw_ppgtt as it contains a few specialised members and I wish to add more. To avoid the ugliness of using ppgtt->base.base, rename the i915_hw_ppgtt base member (i915_address_space) as vm, which is our common shorthand for an i915_address_space local. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com> Cc: Matthew Auld <matthew.william.auld@gmail.com> Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180605153758.18422-1-chris@chris-wilson.co.uk
2018-05-31drm/i915: Switch to kernel context before idling at runtimeChris Wilson1-2/+7
We can reduce our exposure to random neutrinos by resting on the kernel context having flushed out the user contexts to system memory and beyond. The corollary is that we then we require two passes through the idle handler to go to sleep, which on a truly idle system involves an extra pass through the slow and irregular retire work handler. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180531082246.9763-1-chris@chris-wilson.co.uk
2018-05-24drm/i915/psr: Nuke PSR support for VLV and CHVDhinakaran Pandiyan1-37/+5
PSR hardware and hence the driver code for VLV and CHV deviates a lot from their DDI counterparts. While the feature has been disabled for a long time now, retaining support for these platforms is a maintenance burden. There have been multiple refactoring commits to just keep the existing code for these platforms in line with the rest. There are known issues that need to be fixed to enable PSR on these platforms, and there is no PSR capable platform in CI to ensure the code does not break again if we get around to fixing the existing issues. On account of all these reasons, let's nuke this code for now and bring it back if a need arises in the future. Cc: Jani Nikula <jani.nikula@intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Acked-by: Jani Nikula <jani.nikula@intel.com> Acked-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: José Roberto de Souza <jose.souza@intel.com> Signed-off-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180511230059.19387-1-dhinakaran.pandiyan@intel.com
2018-05-22drm/i915: Use intel_fb_obj() everywhereDaniel Stone1-2/+2
We already have a macro to pull the GEM object from a FB, so use it everywhere. We'll make use of this later to move the object storage. Signed-off-by: Daniel Stone <daniels@collabora.com> Reviewed-by: Ville Syrjälä <ville.syrjala@intel.com> Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: intel-gfx@lists.freedesktop.org Link: https://patchwork.freedesktop.org/patch/msgid/20180518143008.4120-1-daniels@collabora.com
2018-05-18drm/i915: Move request->ctx asideChris Wilson1-2/+2
In the next patch, we want to store the intel_context pointer inside i915_request, as it is frequently access via a convoluted dance when submitting the request to hw. Having two context pointers inside i915_request leads to confusion so first rename the existing i915_gem_context pointer to i915_request.gem_context. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180517212633.24934-1-chris@chris-wilson.co.uk
2018-05-17drm/i915/icl: Read the correct Gen11 interrupt registersOscar Mateo1-10/+23
Stop reading some now deprecated interrupt registers in both debugfs and error state. Instead, read the new equivalents in the Gen11 interrupt repartitioning scheme. Note that the equivalent to the PM ISR & IIR cannot be read without affecting the current state of the system, so I've opted for leaving them out. See gen11_reset_one_iir() for more info. v2: else if !!! (Paulo) v3: another else if (Vinay) v4: - Rebased - Renamed patch - Improved the ordering of GENs - Improved the printing of per-GEN info v5: Avoid maybe-unitialized & add comment explaining the lack of PM ISR & IIR Suggested-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Oscar Mateo <oscar.mateo@intel.com> 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: Vinay Belgaumkar <vinay.belgaumkar@intel.com> Reviewed-by: Vinay Belgaumkar <vinay.belgaumkar@intel.com> [Paulo: fix commit message and coding style.] Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/1525989595-18220-1-git-send-email-oscar.mateo@intel.com
2018-05-07drm/i915/icl: add basic support for the ICL clocksPaulo Zanoni1-0/+22
This commit introduces the definitions for the ICL clocks and adds the basic functions to the shared DPLL framework. It adds code for the Enable and Disable sequences for some PLLs, but it does not have the code to compute the actual PLL values, which are marked as TODO comments and should be introduced as separate commits. Special thanks to James Ausmus for investigating and fixing a bug with the placement of icl_unmap_plls_to_ports() function. v2: - Rebase around dpll_lock changes. v3: - The spec now says what the timeouts should be. - Touch DPCLKA_CFGCR0_ICL at the appropriate time so we don't freeze the machine. - Checkpatch found a white space problem. - Small adjustments before upstreaming. v4: - Move the ICL checks out of the *map_plls_to_ports() functions (James) - Add extra encoder check (James) - Call icl_unmap_plls_to_ports() later (James) v5: - Rebase after the pll struct changes. v6: - Properly make the unmap function based on encoders_post_disable() with regarding to checks and iterators. - Address checkpatch comment on "min = max = x()". Cc: James Ausmus <james.ausmus@intel.com> Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Reviewed-by: James Ausmus <james.ausmus@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180427231436.9353-1-paulo.r.zanoni@intel.com
2018-04-30drm/i915: Wrap engine->context_pin() and engine->context_unpin()Chris Wilson1-8/+12
Make life easier in upcoming patches by moving the context_pin and context_unpin vfuncs into inline helpers. v2: Fixup mock_engine to mark the context as pinned on use. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180430131503.5375-2-chris@chris-wilson.co.uk
2018-04-30drm/i915: Stop tracking timeline->inflight_seqnosChris Wilson1-3/+2
In commit 9b6586ae9f6b ("drm/i915: Keep a global seqno per-engine"), we moved from a global inflight counter to per-engine counters in the hope that will be easy to run concurrently in future. However, with the advent of the desire to move requests between engines, we do need a global counter to preserve the semantics that no engine wraps in the middle of a submit. (Although this semantic is now only required for gen7 semaphore support, which only supports greater-then comparisons!) v2: Keep a global counter of all requests ever submitted and force the reset when it wraps. References: 9b6586ae9f6b ("drm/i915: Keep a global seqno per-engine") Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180430131503.5375-1-chris@chris-wilson.co.uk
2018-04-26drm/i915/debugfs: Print sink PSR statusJosé Roberto de Souza1-0/+29
IGT tests could be improved with sink status, knowing for sure that hardware have activate or exit PSR. v3: Reading i915_edp_psr_status was causing PSR to exit but now with 'drm/i915/psr: Prevent PSR exit when a non-pipe related register is written' it is fixed. Reviewed-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> Cc: 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/20180425212334.21109-3-jose.souza@intel.com
2018-04-25drm/i915: Remove obsolete min/max freq setters from debugfsChris Wilson1-115/+0
A more complete, and more importantly stable, interface for controlling the RPS frequency range is available in sysfs, obsoleting the unstable debugfs. It's presence seems to trick people into using it, forgetting it is not ABI. References: https://bugs.freedesktop.org/show_bug.cgi?id=106237 Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Sagar Arun Kamble <sagar.a.kamble@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180425142334.27113-1-chris@chris-wilson.co.uk
2018-04-20drm/i915/psr: Timestamps for PSR entry and exit interrupts.Dhinakaran Pandiyan1-0/+7
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: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180403212420.25007-4-dhinakaran.pandiyan@intel.com
generated by cgit v1.2.3 (git 2.39.1) at 2024-04-30 10:29:24 +0000