summaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2018-03-23drm/i915: Reorder early initializationMichal Wajdeczko3-14/+12
In upcoming patch, we want to perform more actions in early initialization of the uC. This reordering will help resolve new dependencies that will be introduced by future patch. v2: s/i915_gem_load_init/i915_gem_init_early (Chris) v3: s/i915_gem_load_cleanup/i915_gem_cleanup_early (Michal) Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> 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/20180323123451.59244-1-michal.wajdeczko@intel.com
2018-03-23drm/i915/guc: Fix null pointer dereference when GuC FW is not availablePiotr Piórkowski1-3/+3
If GuC firmware is not available on the system and we load i915 with enable GuC, then we hit this null pointer dereference issue: [ 71.098873] BUG: unable to handle kernel NULL pointer dereference at 0000000000000008 [ 71.098938] IP: intel_uc_fw_upload+0x1f/0x360 [i915] [ 71.098947] PGD 0 P4D 0 [ 71.098956] Oops: 0000 [#1] PREEMPT SMP PTI [ 71.098965] Modules linked in: i915(O+) netconsole x86_pkg_temp_thermal intel_powerclamp coretemp crct10dif_pclmul crc32_pclmul ghash_clmulni_intel mei_me i2c_i801 prime_numbers mei [last unloaded: i915] [ 71.099005] CPU: 2 PID: 1167 Comm: insmod Tainted: G U W O 4.16.0-rc1+ #337 [ 71.099018] Hardware name: /NUC6i5SYB, BIOS SYSKLi35.86A.0065.2018.0103.1000 01/03/2018 [ 71.099077] RIP: 0010:intel_uc_fw_upload+0x1f/0x360 [i915] [ 71.099087] RSP: 0018:ffffc90000417aa0 EFLAGS: 00010282 [ 71.099097] RAX: 0000000000000000 RBX: ffff88084cad12f8 RCX: ffffffffa03e9357 [ 71.099108] RDX: 0000000000000002 RSI: ffffffffa034dba0 RDI: ffff88084cad12f8 [ 71.099118] RBP: 0000000000000002 R08: ffff88085344ca90 R09: 0000000000000001 [ 71.099128] R10: 0000000000000000 R11: 0000000000000000 R12: ffff88084cad0000 [ 71.099139] R13: ffffffffa034dba0 R14: 00000000fffffff5 R15: ffff88084cad12b0 [ 71.099151] FS: 00007f7f24ae2740(0000) GS:ffff88085e200000(0000) knlGS:0000000000000000 [ 71.099162] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 71.099171] CR2: 0000000000000008 CR3: 0000000855f48001 CR4: 00000000003606e0 [ 71.099182] Call Trace: [ 71.099246] intel_uc_init_hw+0xc8/0x520 [i915] [ 71.099303] i915_gem_init_hw+0x11f/0x2d0 [i915] [ 71.099364] i915_gem_init+0x2b9/0x640 [i915] [ 71.099413] i915_driver_load+0xb74/0x1110 [i915] [ 71.099462] i915_pci_probe+0x2e/0x90 [i915] [ 71.099476] pci_device_probe+0xa1/0x130 [ 71.099488] driver_probe_device+0x302/0x470 [ 71.099502] __driver_attach+0xb9/0xe0 [ 71.099513] ? driver_probe_device+0x470/0x470 [ 71.099525] ? driver_probe_device+0x470/0x470 [ 71.099538] bus_for_each_dev+0x64/0x90 [ 71.099550] bus_add_driver+0x164/0x260 [ 71.099561] ? 0xffffffffa04d6000 [ 71.099572] driver_register+0x57/0xc0 [ 71.099582] ? 0xffffffffa04d6000 [ 71.099593] do_one_initcall+0x3b/0x160 [ 71.099606] ? kmem_cache_alloc_trace+0x1c3/0x2a0 [ 71.099621] do_init_module+0x5b/0x1f9 [ 71.099635] load_module+0x2467/0x2a70 [ 71.099654] ? SyS_finit_module+0xbd/0xe0 [ 71.099668] SyS_finit_module+0xbd/0xe0 [ 71.099682] do_syscall_64+0x73/0x1c0 [ 71.099694] entry_SYSCALL_64_after_hwframe+0x26/0x9b [ 71.099706] RIP: 0033:0x7f7f23fb40d9 [ 71.099717] RSP: 002b:00007ffda7d67ed8 EFLAGS: 00000246 ORIG_RAX: 0000000000000139 [ 71.099734] RAX: ffffffffffffffda RBX: 000055f96e2a8870 RCX: 00007f7f23fb40d9 [ 71.099748] RDX: 0000000000000000 RSI: 000055f96e2a8260 RDI: 0000000000000003 [ 71.099763] RBP: 000055f96e2a8260 R08: 0000000000000000 R09: 00007ffda7d68088 [ 71.099777] R10: 0000000000000003 R11: 0000000000000246 R12: 0000000000000000 [ 71.099791] R13: 000055f96e2a8830 R14: 0000000000000000 R15: 000055f96e2a8260 [ 71.099810] Code: 00 00 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 41 55 41 54 49 89 f5 55 53 48 c7 c1 57 93 3e a0 48 8b 47 10 48 89 fb 4c 8b 07 <48> 8b 68 08 8b 47 28 85 c0 74 15 83 f8 01 48 c7 c1 5b 93 3e a0 [ 71.100004] RIP: intel_uc_fw_upload+0x1f/0x360 [i915] RSP: ffffc90000417aa0 [ 71.100020] CR2: 0000000000000008 [ 71.100031] ---[ end trace d8ac93c30ceff5b2 ]-- Fixes: 6b0478fb722a ("drm/i915: Implement dynamic GuC WOPCM offset and size calculation") v2: don't assume it is always GuC FW (Michal) v3: added a new variable to avoid exceeding the number of characters in the line (Michal) Signed-off-by: Piotr Piórkowski <piotr.piorkowski@intel.com> Reported-by: Radoslaw Szwichtenberg <radoslaw.szwichtenberg@intel.com> Cc: Michał Winiarski <michal.winiarski@intel.com> Cc: Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: Sagar Arun Kamble <sagar.a.kamble@intel.com> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Jackie Li <yaodong.li@intel.com> Cc: Radoslaw Szwichtenberg <radoslaw.szwichtenberg@intel.com> Reviewed-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Reviewed-by: Jackie Li <yaodong.li@intel.com> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20180323112319.16293-1-piotr.piorkowski@intel.com
2018-03-23drm/i915: Don't spew errors when resetting HDMI scrambling/bit clock ratio failsVille Syrjälä3-32/+29
When we're disabling the HDMI link we try to reset the scrambling and TMDS bit clock ratio back to the default values. This will fail if the sink has already been disconnected. Thus we should not print an error message when resetting the scrambling/TMDS bit clock ratio fail during disable. During enable we do want the error, and during disable we may still want to know what happended for debug purposes so let's use DRM_DEBUG_KMS() there. v2: Remember them consts v3: Go back to just one function and print the errors/debugs from callers (Shashank) Cc: Shashank Sharma <shashank.sharma@intel.com> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=105644 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=105655 Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180322154707.22103-1-ville.syrjala@linux.intel.com Reviewed-by: Shashank Sharma <shashank.sharma@intel.com>
2018-03-23drm/i915: Skip logging impossible slicesTvrtko Ursulin1-4/+4
Log up to sseu->max_slices instead basing on ARRAY_SIZE since to avoid printing impossible and empty slices for a platform. Also compact slice total and slice mask into one log line. Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: Lionel Landwerlin <lionel.g.landwerlin@intel.com> Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180321103228.32205-1-tvrtko.ursulin@linux.intel.com
2018-03-23drm/i915: Avoid setting ring freq on invalid rps freqsMika Kuoppala1-3/+6
Looping through rps frequencies when both min and max are zero ends up into an endless loop. This can happen during hardware enablement. Bail out early if rps frequencies are not correctly set yet. Cc: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Mika Kuoppala <mika.kuoppala@linux.intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20180320151734.11761-1-mika.kuoppala@linux.intel.com
2018-03-22drm/i915: Flush pending interrupt following a GPU resetChris Wilson2-4/+7
After resetting the GPU (or subset of engines), call synchronize_irq() to flush any pending irq before proceeding with the cleanup. For a device level reset, we disable the interupts around the reset, but when resetting just one engine, we have to avoid such global disabling. This leaves us open to an interrupt arriving for the engine as we try to reset it. We already do try to flush the IIR following the reset, but we have to ensure that the in-flight interrupt does not land after we start cleaning up after the reset; enter synchronize_irq(). As it current stands, we very rarely, but fatally, see sequences such as: 2.... 57964564us : execlists_reset_prepare: rcs0 2.... 57964613us : execlists_reset: rcs0 seqno=424 0d.h1 57964615us : gen8_cs_irq_handler: rcs0 CS active=1 2d..1 57964617us : __i915_request_unsubmit: rcs0 fence 29:1056 <- global_seqno 1060 2.... 57964703us : execlists_reset_finish: rcs0 0..s. 57964705us : execlists_submission_tasklet: rcs0 awake?=1, active=0, irq-posted?=1 v2: Move the sync into the execlists reset handler so that we coordinate the flush with disabling the interrupt handling and canceling the pending interrupt. v3: Just use synchronize_hardirq() to avoid the might_sleep(), we do not yet have threaded-irq to worry about. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com> Cc: Michel Thierry <michel.thierry@intel.com> Cc: Michał Winiarski <michal.winiarski@intel.com> Cc: Jeff McGee <jeff.mcgee@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180322073533.5313-4-chris@chris-wilson.co.uk Reviewed-by: Jeff McGee <jeff.mcgee@intel.com>
2018-03-22drm/i915: Use full serialisation around engine->irq_postedChris Wilson1-4/+3
Using engine->irq_posted for execlists, we are not always serialised by the tasklet as we supposed. On the reset paths, the tasklet is disabled and ignored. Instead, we manipulate the engine->irq_posted directly to account for the reset, but if an interrupt fired before the reset and so wrote to engine->irq_posted, that write may not be flushed from the local CPU's cacheline until much later as the tasklet is already active and so does not generate a mb(). To correctly serialise the interrupt with reset, we need serialisation on the set_bit() itself. And at last Mika can be happy. 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: Mika Kuoppala <mika.kuoppala@linux.intel.com> Reviewed-by: Jeff McGee <jeff.mcgee@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180322073533.5313-3-chris@chris-wilson.co.uk
2018-03-22drm/i915/selftests: Stress resets-vs-request-priorityChris Wilson1-63/+126
Watch what happens if we try to reset with a queue of requests with varying priorities -- that may need reordering or preemption across the reset. v2: Tweak priorities to avoid starving the hanging thread. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20180322073533.5313-2-chris@chris-wilson.co.uk Reviewed-by: Jeff McGee <jeff.mcgee@intel.com>
2018-03-22drm/i915/selftests: Include the trace as a debug aideChris Wilson1-3/+20
If we fail to reset the GPU in a timely fashion, dump the GEM trace so that we can see what operations were in flight when the GPU got stuck. v2: There's more than one timeout that deserves tracing! v3: Silence checkpatch by not even using a product at all! Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com> Reviewed-by: Jeff McGee <jeff.mcgee@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180322074908.10838-1-chris@chris-wilson.co.uk
2018-03-22drm/i915: Remove local timeline var from submit/unsubmitChris Wilson1-15/+15
Both request_submit and request_unsubmit deal with transferring the request from the client's timeline onto the execution timeline and back again. As both functions deal with a pair of timeline's, using a shorthand for just one of them is slightly confusing, especially as the different functions use the shorthand for the alternate timeline. Instead, use the full version of each timeline so it should be easier to keep track of the transfer between the request/client and the engine. v2: Refactor the common lock+list_move v3: Be clear we require the other timeline list to be locked as well. 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/20180322131034.6036-1-chris@chris-wilson.co.uk
2018-03-22drm/i915: Fix tracing of submit seqnoChris Wilson1-1/+1
We pre-increment the timeline->seqno when handing it to the request, make sure the GEM_TRACE takes this into account. Otherwise, it appears that we go backwards over a preemption point: 1d..1 157681077us : __i915_request_unsubmit: vcs0 fence 75e:3 <- global_seqno 17 0d.s1 157681113us : __i915_request_submit: vcs0 fence 75e:3 -> global_seqno 16 Fixes: d9b13c4dde6c ("drm/i915: Trace GEM steps between submit and wedging") Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> 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/20180322110059.4467-1-chris@chris-wilson.co.uk
2018-03-21drm/i915/psr: Remove open-coded PSR AUX transactions for SKL+Dhinakaran Pandiyan2-33/+28
HSW and BDW have SRD_AUX_{CTL, STATUS} registers that the driver needs to setup for the HW to use whenever exiting PSR. SKL+ hardware use hardcoded values for the same and do not need any registers to be setup. So, use drm_dp_dpcd_writeb() for a one-time write during PSR enable and setup the PSR aux registers on HSW and BDW for later use by HW. We also end up writing to reserved bits in SRD_AUX_CTL by reusing intel_dp->get_aux_send_ctl() for HSW and BDW, fix this. Since the AUX register setup is source side programming, move the call to enable_source() from enable_sink(). Cc: José Roberto de Souza <jose.souza@intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> 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/20180313034646.3721-2-dhinakaran.pandiyan@intel.com
2018-03-21drm/i915/psr: Move PSR aux setup to it's own function.Dhinakaran Pandiyan1-11/+20
Non-functional change useful for the following patch. Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: José Roberto de Souza <jose.souza@intel.com> Signed-off-by: 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/20180313034646.3721-1-dhinakaran.pandiyan@intel.com
2018-03-21drm/i915/execlists: Use a locked clear_bit() for synchronisation with interruptChris Wilson1-13/+8
We were relying on the uncached reads when processing the CSB to provide ourselves with the serialisation with the interrupt handler (so we could detect new interrupts in the middle of processing the old one). However, in commit 767a983ab255 ("drm/i915/execlists: Read the context-status HEAD from the HWSP") those uncached reads were eliminated (on one path at least) and along with them our serialisation. The result is that we would very rarely miss notification of a new interrupt and leave a context-switch unprocessed, hanging the GPU. Fixes: 767a983ab255 ("drm/i915/execlists: Read the context-status HEAD from the HWSP") Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Michel Thierry <michel.thierry@intel.com> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: Mika Kuoppala <mika.kuoppala@intel.com> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com> Reviewed-by: Michel Thierry <michel.thierry@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180321091027.21034-1-chris@chris-wilson.co.uk
2018-03-21drm/i915/guc: Unify parameters of public CT functionsMichal Wajdeczko3-20/+31
There is no need to mix parameter types in public CT functions as we can always accept intel_guc_ct. v2: fix 'Return' doc, s/dev_priv/i915 (Sagar) Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: Sagar Arun Kamble <sagar.a.kamble@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Sagar Arun Kamble <sagar.a.kamble@intel.com> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20180320162020.38672-1-michal.wajdeczko@intel.com
2018-03-21drm/i915/guc: Handle GuC log flush event in dedicated functionMichal Wajdeczko3-2/+8
We already try to keep all GuC log related code in separate file, handling flush event should be placed there too. This will also allow future code reuse. v2: rebased Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: Michal Winiarski <michal.winiarski@intel.com> Cc: Sagar Arun Kamble <sagar.a.kamble@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Oscar Mateo <oscar.mateo@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/20180319125049.48932-1-michal.wajdeczko@intel.com
2018-03-21drm/i915/guc: Move enable/disable msg functions to GuC headerMichal Wajdeczko2-14/+26
While today we are modifying GuC enabled msg mask only in GuC log, this code should be defined as generic GuC to allow future code reuse. Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: Michal Winiarski <michal.winiarski@intel.com> Cc: Sagar Arun Kamble <sagar.a.kamble@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> 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/20180320181419.35576-3-michal.wajdeczko@intel.com
2018-03-21drm/i915/guc: Drop union guc_log_controlMichal Wajdeczko2-19/+10
Usually we use shift/mask macros for bit field definitions. Union guc_log_control was not following that pattern. Additional bonus: add/remove: 0/0 grow/shrink: 0/1 up/down: 0/-25 (-25) Function old new delta intel_guc_log_level_set 388 363 -25 v2: prevent out-of-range verbosity (MichalWi) Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: Michal Winiarski <michal.winiarski@intel.com> Cc: Sagar Arun Kamble <sagar.a.kamble@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/20180320181419.35576-2-michal.wajdeczko@intel.com
2018-03-21drm/i915/guc: Unify naming of private GuC action functionsMichal Wajdeczko1-9/+9
We should avoid using guc_log prefix for functions that don't operate on GuC log, but rather request action from the GuC. Better to use guc_action prefix. v2: rebase + naming compromise v3: rebase Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: Michal Winiarski <michal.winiarski@intel.com> Cc: Sagar Arun Kamble <sagar.a.kamble@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/20180320181419.35576-1-michal.wajdeczko@intel.com
2018-03-21drm/i915/huc: Check HuC status in dedicated functionMichal Wajdeczko3-3/+29
We try to keep all HuC related code in dedicated file. There is no need to peek HuC register directly during handling getparam ioctl. Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: Michel Thierry <michel.thierry@intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Anusha Srivatsa <anusha.srivatsa@intel.com> Reviewed-by: Michel Thierry <michel.thierry@intel.com> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20180314200429.40132-1-michal.wajdeczko@intel.com
2018-03-21drm/i915/icl: Added ICL 11 slice, subslice and EU fuse detectionKelvin Gardiner3-2/+51
This patch adds support to detect ICL, slice, subslice and EU fuse settings. Add addresses for ICL 11 slice, subslice and EU fuses registers. These register addresses are the same as previous platforms but the format and / or the meaning of the information is different. Therefore Gen11 defines for these registers are added. Bspec: 9731 Bspec: 20643 Bspec: 20673 v2: Update fusing information storage after introducing the new query uAPI (Lionel) v3 (Oscar): - The maximum number of slices in ICL 11 is 1 - The subslice disable fuse can potentially store information in all bits - GEN_MAX_SUBSLICES has to be increased to 8 - Don't trust the slice enabled fuse outside the max number of expected slices - Indentation fix and some reordering and renaming of local variables v4: Use single space after Cc tag Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com> Signed-off-by: Kelvin Gardiner <kelvin.gardiner@intel.com> Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com> Signed-off-by: Oscar Mateo <oscar.mateo@intel.com> Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com> Signed-off-by: Mika Kuoppala <mika.kuoppala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/1521575121-9577-1-git-send-email-oscar.mateo@intel.com
2018-03-20drm/i915: Add control flags to i915_handle_error()Chris Wilson8-55/+62
Not all callers want the GPU error to handled in the same way, so expose a control parameter. In the first instance, some callers do not want the heavyweight error capture so add a bit to request the state to be captured and saved. v2: Pass msg down to i915_reset/i915_reset_engine so that we include the reason for the reset in the dev_notice(), superseding the earlier option to not print that notice. v3: Stash the reason inside the i915->gpu_error to handover to the direct reset from the blocking waiter. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Jeff McGee <jeff.mcgee@intel.com> Cc: Mika Kuoppala <mika.kuoppala@intel.com> Cc: Michel Thierry <michel.thierry@intel.com> Reviewed-by: Michel Thierry <michel.thierry@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180320100449.1360-2-chris@chris-wilson.co.uk
2018-03-20drm/i915: Specify which engines to reset following semaphore/event lockupsChris Wilson1-2/+2
If the GPU is stuck waiting for an event or for a semaphore, we need to reset the GPU in order to recover. We have to tell the reset routine which engines we want reset, but we were still using the old interface and declaring it as "not-fatal". Fixes: 14b730fcb8d9 ("drm/i915/tdr: Prepare error handler to accept mask of hung engines") Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Mika Kuoppala <mika.kuoppala@intel.com> Cc: Michel Thierry <michel.thierry@intel.com> Reviewed-by: Michel Thierry <michel.thierry@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180320100449.1360-1-chris@chris-wilson.co.uk
2018-03-20drm/i915/guc: Don't try to enable GuC logging when we're not using GuCMichał Winiarski4-23/+23
When changing the default values for guc_log_level, we accidentally left the log enabled on non-guc platforms. Let's fix that. v2: Define the levels used and remove (now obsolete) comments (Chris) v3: Use "IS" rather than "TO" for booleans (Chris) Fixes: 9605d1ce7c6b ("drm/i915/guc: Default to non-verbose GuC logging") Reported-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Michał Winiarski <michal.winiarski@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Sagar Arun Kamble <sagar.a.kamble@intel.com> Cc: Michal Wajdeczko <michal.wajdeczko@intel.com> 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/20180320115517.20423-1-michal.winiarski@intel.com
2018-03-20drm/i915/icl: Update subslice define for ICL 11Kelvin Gardiner3-5/+23
ICL 11 has a greater number of maximum subslices. This patch reflects this. v2: GEN11 updates to MCR_SELECTOR (Oscar) v3: Copypasta error in the new defines (Lionel) Bspec: 21139 BSpec: 21108 Signed-off-by: Kelvin Gardiner <kelvin.gardiner@intel.com> Reviewed-by: Oscar Mateo <oscar.mateo@intel.com> (v1) Reviewed-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> (v1) Signed-off-by: Oscar Mateo <oscar.mateo@intel.com> Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180316121456.11577-3-mika.kuoppala@linux.intel.com Signed-off-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
2018-03-20drm/i915/icl: Enable the extra video decode and enhancement boxes for Icelake 11Oscar Mateo1-0/+1
Icelake 11 has one vebox and two vdboxes (0 and 2). Bspec: 21140 v2: Split out in two (Daniele) Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Signed-off-by: Oscar Mateo <oscar.mateo@intel.com> Reviewed-by: Michel Thierry <michel.thierry@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180316121456.11577-2-mika.kuoppala@linux.intel.com Signed-off-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
2018-03-20drm/i915/icl: Check for fused-off VDBOX and VEBOX instancesOscar Mateo6-0/+115
In Gen11, the Video Decode engines (aka VDBOX, aka VCS, aka BSD) and the Video Enhancement engines (aka VEBOX, aka VECS) could be fused off. Also, each VDBOX and VEBOX has its own power well, which only exist if the related engine exists in the HW. Unfortunately, we have a Catch-22 situation going on: we need the blitter forcewake to read the register with the fuse info, but we cannot initialize the forcewake domains without knowin about the engines present in the HW. We workaround this problem by allowing the initialization of all forcewake domains and then pruning the fused off ones, as per the fuse information. Bspec: 20680 v2: We were shifting incorrectly for vebox disable (Vinay) v3: Assert mmio is ready and warn if we have attempted to initialize forcewake for fused-off engines (Paulo) v4: - Use INTEL_GEN in new code (Tvrtko) - Shorter local variable (Tvrtko, Michal) - Keep "if (!...) continue" style (Tvrtko) - No unnecessary BUG_ON (Tvrtko) - WARN_ON and cleanup if wrong mask (Tvrtko, Michal) - Use I915_READ_FW (Michal) - Use I915_MAX_VCS/VECS macros (Michal) v5: Rebased by Rodrigo fixing conflicts on top of: "drm/i915: Simplify intel_engines_init" v6: Fix v5. Remove info->num_rings. (by Oscar) v7: Rebase (Rodrigo). v8: - s/intel_device_info_fused_off_engines/ intel_device_info_init_mmio (Chris) - Make vdbox_disable & vebox_disable local variables (Chris) v9: - Move function declaration to intel_device_info.h (Michal) - Missing indent in bit fields definitions (Michal) - When RC6 is enabled by BIOS, the fuse register cannot be read until the blitter powerwell is awake. Shuffle where the fuse is read, prune the forcewake domains after the fact and change the commit message accordingly (Vinay, Sagar, Chris). v10: - Improved commit message (Sagar) - New line in header file (Sagar) - Specify the message in fw_domain_reset applies to ICL+ (Sagar) Cc: Paulo Zanoni <paulo.r.zanoni@intel.com> Cc: Vinay Belgaumkar <vinay.belgaumkar@intel.com> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Sagar Arun Kamble <sagar.a.kamble@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Oscar Mateo <oscar.mateo@intel.com> Reviewed-by: Sagar Arun Kamble <sagar.a.kamble@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180316121456.11577-1-mika.kuoppala@linux.intel.com [Mika: soothe checkpatch on commit msg] Signed-off-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
2018-03-20drm/i915: Select STACKDEPOT for DRM_I915_DEBUGDaniel Vetter1-0/+1
select in Kconfig isn't recursive, we need to select the stuff our selects select, too. Fix that. Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20180320125009.2305-1-daniel.vetter@ffwll.ch
2018-03-19drm/i915: Trim error mask to known enginesChris Wilson1-0/+1
For the convenience of userspace passing in an arbitrary reset mask, remove unknown engines from the set of engines that are to be reset. This means that we always follow a per-engine reset with a full-device reset when userspace writes -1 into debugfs/i915_wedged. Reported-by: Michał Winiarski <michal.winiarski@intel.com> 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> Link: https://patchwork.freedesktop.org/patch/msgid/20180316215001.12391-1-chris@chris-wilson.co.uk Reviewed-by: Michel Thierry <michel.thierry@intel.com>
2018-03-19drm/i915: Prefer memset64() when filling the iomapChris Wilson1-3/+4
As the ringbuffer may exist inside stolen memory, our access to it may be via the GTT iomap. This implies we may only have WC access for which the conventional memset() substitution of rep stos performs very badly, so switch to the rep mov[dq] variants when available. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Mika Kuoppala <mika.kuoppala@intel.com> Cc: Matthew Auld <matthew.auld@intel.com> Reviewed-by: Matthew Auld <matthew.auld@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180319123528.28249-1-chris@chris-wilson.co.uk
2018-03-19drm/i915/guc: Demote GuC error messagesMichał Winiarski2-5/+6
We're using those functions in selftests, and the callers are expected to do the error handling anyways. Let's demote all GuC actions and doorbell creation to DEBUG_DRIVER. Signed-off-by: Michał Winiarski <michal.winiarski@intel.com> Cc: Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: Michel Thierry <michel.thierry@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> 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/20180319095348.9716-12-michal.winiarski@intel.com
2018-03-19drm/i915/guc: Default to non-verbose GuC loggingMichał Winiarski2-2/+2
Now that we've decoupled logging from relay, GuC log level is only controlling the GuC behavior - there shouldn't be any impact on i915 behaviour. We're only going to see a single extra interrupt when log will get half full. That, and the fact that we're seeing igt/gem_exec_nop/basic-series failing with non-verbose logging being disabled. v2: Bring back the "auto" guc_log_level, now that we fixed the log Signed-off-by: Michał Winiarski <michal.winiarski@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Sagar Arun Kamble <sagar.a.kamble@intel.com> Cc: Michal Wajdeczko <michal.wajdeczko@intel.com> Reviewed-by: Sagar Arun Kamble <sagar.a.kamble@intel.com> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20180319095348.9716-11-michal.winiarski@intel.com
2018-03-19drm/i915/guc: Allow user to control default GuC loggingMichał Winiarski5-27/+49
While both naming and actual log enable logic in GuC interface are confusing, we can simply expose the default log as yet another log level. GuC logic aside, from i915 point of view we now have the following GuC log levels: 0 Log disabled 1 Non-verbose log 2-5 Verbose log v2: Adjust naming after rebase. v3: Fixed the log_level logic error introduced on rebase. Signed-off-by: Michał Winiarski <michal.winiarski@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Sagar Arun Kamble <sagar.a.kamble@intel.com> Cc: Michal Wajdeczko <michal.wajdeczko@intel.com> Reviewed-by: Sagar Arun Kamble <sagar.a.kamble@intel.com> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20180319095348.9716-10-michal.winiarski@intel.com
2018-03-19drm/i915/guc: Don't print out relay statistics when relay is disabledMichał Winiarski4-38/+52
If nobody has enabled the relay, we're not comunicating with GuC, which means that the stats don't have any meaning. Let's also remove interrupt counter and tidy the debugfs formatting. v2: Correct stats accounting (Sagar) v3: Corrected one more error in stats accounting, move relay_enabled (Sagar) Signed-off-by: Michał Winiarski <michal.winiarski@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Sagar Arun Kamble <sagar.a.kamble@intel.com> Cc: Michal Wajdeczko <michal.wajdeczko@intel.com> Reviewed-by: Sagar Arun Kamble <sagar.a.kamble@intel.com> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20180319095348.9716-9-michal.winiarski@intel.com
2018-03-19drm/i915/guc: Always print log stats in i915_guc_info when using GuCMichał Winiarski1-6/+9
While some of the content in this file is related to GuC submission only, that's not the case with log related statistics. Signed-off-by: Michał Winiarski <michal.winiarski@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Sagar Arun Kamble <sagar.a.kamble@intel.com> Cc: Michal Wajdeczko <michal.wajdeczko@intel.com> Reviewed-by: Sagar Arun Kamble <sagar.a.kamble@intel.com> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20180319095348.9716-8-michal.winiarski@intel.com
2018-03-19drm/i915/guc: Get rid of GuC log runtimeMichał Winiarski4-45/+45
Runtime is not a very good name. Let's also move counting relay overflows inside relay struct. v2: Rename things rather than remove the struct (Chris) Signed-off-by: Michał Winiarski <michal.winiarski@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Sagar Arun Kamble <sagar.a.kamble@intel.com> Cc: Michal Wajdeczko <michal.wajdeczko@intel.com> Reviewed-by: Sagar Arun Kamble <sagar.a.kamble@intel.com> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20180319095348.9716-7-michal.winiarski@intel.com
2018-03-19drm/i915/guc: Move check for fast memcpy_wc to relay creationMichał Winiarski1-10/+10
We only need those fast memcpy_wc when we're using relay to read continuous GuC log. Let's prevent the user from creating a relay if we know we won't be able to keep up with GuC. v2: Adjust the return value (Michał) Signed-off-by: Michał Winiarski <michal.winiarski@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Sagar Arun Kamble <sagar.a.kamble@intel.com> Cc: Michal Wajdeczko <michal.wajdeczko@intel.com> Reviewed-by: Sagar Arun Kamble <sagar.a.kamble@intel.com> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20180319095348.9716-6-michal.winiarski@intel.com
2018-03-19drm/i915/guc: Split relay control and GuC log levelMichał Winiarski6-84/+84
Those two concepts are really separate. Since GuC is writing data into its own buffer and we even provide a way for userspace to read directly from it using i915_guc_log_dump debugfs, there's no real reason to tie log level with relay creation. Let's create a separate debugfs, giving userspace a way to create a relay on demand, when it wants to read a continuous log rather than a snapshot. v2: Don't touch guc_log_level on relay creation error, adjust locking after rebase, s/dev_priv/i915, pass guc to file->private_data (Sagar) Use struct_mutex rather than runtime.lock for set_log_level v3: Tidy ordering of definitions (Sagar) Signed-off-by: Michał Winiarski <michal.winiarski@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Sagar Arun Kamble <sagar.a.kamble@intel.com> Cc: Michal Wajdeczko <michal.wajdeczko@intel.com> Reviewed-by: Sagar Arun Kamble <sagar.a.kamble@intel.com> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20180319095348.9716-5-michal.winiarski@intel.com
2018-03-19drm/i915/guc: Flush directly in log unregisterMichał Winiarski1-22/+16
Having both guc_flush_logs and guc_log_flush functions is confusing. While we could just rename things, guc_flush_logs implementation is quite simple. Let's get rid of it and move its content to unregister. v2: s/dev_priv/i915 (Sagar) Signed-off-by: Michał Winiarski <michal.winiarski@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Sagar Arun Kamble <sagar.a.kamble@intel.com> Cc: Michal Wajdeczko <michal.wajdeczko@intel.com> Reviewed-by: Sagar Arun Kamble <sagar.a.kamble@intel.com> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20180319095348.9716-4-michal.winiarski@intel.com
2018-03-19drm/i915/guc: Merge log relay file and channel creationMichał Winiarski1-60/+5
We have all the information we need at relay_open call time. Since there's no reason to split the process into relay_open and relay_late_setup_files, let's remove the extra code. v2: Remove obsoleted comments (Sagar) v3: There was one obsolete comment left (Sagar) Signed-off-by: Michał Winiarski <michal.winiarski@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Sagar Arun Kamble <sagar.a.kamble@intel.com> Cc: Michal Wajdeczko <michal.wajdeczko@intel.com> Reviewed-by: Sagar Arun Kamble <sagar.a.kamble@intel.com> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20180319095348.9716-3-michal.winiarski@intel.com
2018-03-19drm/i915/guc: Log runtime should consist of both mapping and relayMichał Winiarski2-90/+38
Currently, we're treating relay and mapping of GuC log as a separate concepts. We're also using inconsistent locking, sometimes using relay_lock, sometimes using struct mutex. Let's correct that. Anything touching the runtime is now serialized using runtime.lock, while we're still using struct mutex as inner lock for mapping. We're still racy in setting the log level - but we'll take care of that in the following patches. v2: Tidy locking (Sagar) v3: Remove obsoleted comment (Sagar) Signed-off-by: Michał Winiarski <michal.winiarski@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Sagar Arun Kamble <sagar.a.kamble@intel.com> Cc: Michal Wajdeczko <michal.wajdeczko@intel.com> Reviewed-by: Sagar Arun Kamble <sagar.a.kamble@intel.com> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20180319095348.9716-2-michal.winiarski@intel.com
2018-03-19drm/i915/guc: Keep GuC interrupts enabled when using GuCMichał Winiarski4-36/+36
The GuC log contains a separate space used for crash dump. We even get a separate notification for it. While we're not handling crash differently yet, it makes sense to decouple the two right now to simplify the following patches. v2: Move guc_log_flush_irq_disable up to avoid movement in following patches (Sagar). v3: s/guc_log_flush_irq_*/guc_flush_log_msg_*, rebase after mass rename Signed-off-by: Michał Winiarski <michal.winiarski@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Sagar Arun Kamble <sagar.a.kamble@intel.com> Cc: Michal Wajdeczko <michal.wajdeczko@intel.com> Reviewed-by: Sagar Arun Kamble <sagar.a.kamble@intel.com> (v2) Reviewed-by: Sagar Arun Kamble <sagar.a.kamble@intel.com> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20180319095348.9716-1-michal.winiarski@intel.com
2018-03-19drm/i915/dp: Write to SET_POWER dpcd to enable MST hub.Dhinakaran Pandiyan1-5/+2
If bios sets up an MST output and hardware state readout code sees this is an SST configuration, when disabling the encoder we end up calling ->post_disable_dp() hook instead of the MST version. Consequently, we write to the DP_SET_POWER dpcd to set it D3 state. Further along when we try enable the encoder in MST mode, POWER_UP_PHY transaction fails to power up the MST hub. This results in continuous link training failures which keep the system busy delaying boot. We could identify bios MST boot discrepancy and handle it accordingly but a simple way to solve this is to write to the DP_SET_POWER dpcd for MST too. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=105470 Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reported-by: Laura Abbott <labbott@redhat.com> Cc: stable@vger.kernel.org Fixes: 5ea2355a100a ("drm/i915/mst: Use MST sideband message transactions for dpms control") Tested-by: Laura Abbott <labbott@redhat.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/20180314054825.1718-1-dhinakaran.pandiyan@intel.com
2018-03-16drm/i915: Kill the remaining CHV HBR2 leftoversVille Syrjälä2-18/+4
AFAIK CHV was supposed to have HBR2 originally, but in the end the feature was dropped. We still have some code leftovers from those early days. Eliminate them. The extra bit for the training pattern seems to be dead in the hardware. I can set it (in fact I can set almost any reserved bit in the registers) but it doesn't seem to interfere with the operation of the hardware. Either that or I'm very lucky that my displays complete link training with the incorrect pattern being sent out. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180302095656.19662-1-ville.syrjala@linux.intel.com Reviewed-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
2018-03-16i915: Re-use DEFINE_SHOW_ATTRIBUTE() macroAndy Shevchenko2-77/+12
...instead of open coding file operations followed by custom ->open() callbacks per each attribute. Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20180316141213.38774-1-andriy.shevchenko@linux.intel.com
2018-03-16drm/i915: Don't initialize plane_to_crtc_mapping[] on SKL+Ville Syrjälä1-4/+11
We don't use the enum i9xx_plane_id namespace on SKL+ anymore, so do not initialize the related plane_to_crtc_mapping[] table either. Actually the only remaining user of that table is the pre-g4x watermark code, but no harm in initializing the table on all pre-SKL platforms. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180305174122.17273-1-ville.syrjala@linux.intel.com Reviewed-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
2018-03-16drm/i915/stolen: Deduce base of reserved portion as top-size on vlvChris Wilson1-47/+56
On Valleyview, the HW deduces the base of the reserved portion of stolen memory as being (top - size) and the address field within GEN6_STOLEN_RESERVED is set to 0. Add yet another GEN6_STOLEN_RESERVED reader to cope with the subtly different path required for vlv. v2: Avoid using reserved_base = reserved_size = 0 as the invalid condition as that typically falls outside of the stolen region, provoking a consistency error. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Imre Deak <imre.deak@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180312165206.31772-3-chris@chris-wilson.co.uk
2018-03-16drm/i915/stolen: Checkpatch cleansingChris Wilson1-12/+28
In the next patch, we will introduce a new vlv_get_stolen_reserved, so before we do, make sure checkpatch is happy with the surrounding code. Sneak in some debug output while we are here. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180312165206.31772-2-chris@chris-wilson.co.uk Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
2018-03-16drm/i915/stolen: Switch from DEBUG_KMS to DEBUG_DRIVERChris Wilson1-10/+10
i915_gem_stolen is an allocator for the reserved portion of memory ("stolen" from the system by the BIOS). It is not tied to KMS but central to the driver, so prefer DRM_DEBUG_DRIVER. 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/20180312165206.31772-1-chris@chris-wilson.co.uk
2018-03-16drm/i915: Stop engines when declaring the machine wedgedChris Wilson2-1/+3
If we fail to reset the GPU, we declare the machine wedged. However, the GPU may well still be running in the background with an in-flight request. So despite our efforts in cleaning up the request queue and faking the breadcrumb in the HWSP, the GPU may eventually write the in-flght seqno there breaking all of our assumptions and throwing the driver into a deep turmoil, wedging beyond wedged. To avoid this we ideally want to reset the GPU. Since that has already failed, make sure the rings have the stop bit set instead. This is part of the normal GPU reset sequence, but that is actually disabled by igt/gem_eio to force the wedged state. If we assume the worst, we must poke at the bit again before we give up. v2: Move the intel_gpu_reset() from set-wedged in the reset error path into i915_gem_set_wedged() itself. Even if the reset fails (e.g. if it is disabled by gem_eio), it still tries to make sure the engines are stopped. For i915_gem_set_wedged() callers from outside of i915_reset(), this should make sure the GPU is disabled while the driver is marked as being wedged. Testcase: igt/gem_eio 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: Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: Michel Thierry <michel.thierry@intel.com> Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180315151015.22741-1-chris@chris-wilson.co.uk
generated by cgit v1.2.3 (git 2.39.0) at 2025-09-27 15:09:49 +0300