- 29 Mar, 2018 2 commits
-
-
Chris Wilson authored
When we include a request's global_seqno in a GEM_TRACE it often helps to know how that relates to the current breadcrumb as seen by the hardware. Signed-off-by:
Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20180327210157.16896-3-chris@chris-wilson.co.ukReviewed-by:
Tvrtko Ursulin <tvrtko.ursulin@intel.com>
-
Michel Thierry authored
Probably lost while rebasing commit eacd8391 ("drm/i915/guc: Keep GuC interrupts enabled when using GuC"). Not really needed since i915_gem_init_hw is called before uc_resume, but it brings symmetry to uc_suspend. Signed-off-by:
Michel Thierry <michel.thierry@intel.com> Cc: Michał Winiarski <michal.winiarski@intel.com> Reviewed-by:
Michał Winiarski <michal.winiarski@intel.com> Signed-off-by:
-
- 28 Mar, 2018 14 commits
-
-
Michal Wajdeczko authored
During debug we may want to investigate all communication from the Guc. Add proper tracing macros in debug config. v2: convert remaining DRM_DEBUG into new CT_DEBUG (Michal) v3: use dedicated Kconfig (Daniele) v4: checkpatch Signed-off-by:
Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Acked-by:
Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Signed-off-by:
-
Michal Wajdeczko authored
When running on platform with CTB based GuC communication enabled, GuC to Host event data will be delivered as CT request message. However, content of the data[1] of this CT message follows format of the scratch register used in MMIO based communication, so some code reuse is still possible. v2: filter disabled messages (Daniele) Signed-off-by:
-
Michal Wajdeczko authored
Requests are read from CT in the irq handler, but actual processing will be done in the work thread. Processing of specific actions will be added in the upcoming patches. v2: don't use GEM_BUG_ON (Chris) don't kmalloc too large buffer (Michal) v3: rebased v4: don't name it 'dispatch' (Michel) and fix checkpatch add some documentation (Michal) Signed-off-by: -
Michal Wajdeczko authored
Instead of returning small data in response status dword, GuC may append longer data as response message payload. If caller provides response buffer, we will copy received data and use number of received data dwords as new success return value. We will WARN if response from GuC does not match caller expectation. v2: fix timeout and checkpatch warnings (Michal) v3: fix checkpatch again (Michel) update wait function name (Michal) no need for spinlock_irqsave (MichalWi) no magic numbers (MichalWi) must check before use (Jani) add some more documentation (Michal) v4: update documentation (Michal) Signed-off-by: -
Michal Wajdeczko authored
In next patch we will introduce another way of waiting for the response that will use RECV buffer. To avoid misleading names, rename old wait function to reflect the fact that it is based on descriptor update. v2: fix comment style (Michal) v3: use more specific name (Michel) Signed-off-by:
-
Michal Wajdeczko authored
GuC can respond to our commands not only by updating SEND buffer descriptor, but can also send a response message over RECV buffer. Guc can also send unsolicited request messages over RECV buffer. Let's start reading those messages and make placeholders for actual response/request handlers. v2: misc improvements (Michal) v3: change response detection (Michal) invalid status is protocol error (Michal) v4: rebase v5: fix checkpatch (Michel) don't use fields before check (Jani) add some documentation (Michal) Signed-off-by: -
Michal Wajdeczko authored
On platforms with CTB based GuC communications, we will handle GuC events in a different way. Let's make event handler a virtual function to allow easy switch between those variants. Credits-to: Oscar Mateo <oscar.mateo@intel.com> Signed-off-by:
-
Michal Wajdeczko authored
We're using data encoded in the status MMIO as return value from send function, but GuC may also write more data in remaining MMIO regs. Let's copy content of these registers to the buffer provided by caller. v2: new line (Michel) v3: updated commit message Signed-off-by:
-
Michal Wajdeczko authored
This is a preparation step for the upcoming patches. We already can return some small data decoded from the command status, but we will need more in the future. v2: add explicit response buf size v3: squash with helper patch Signed-off-by:
-
Michal Wajdeczko authored
GuC may return additional data in the response message. Format and meaning of this data is action specific. We will use this non-negative data as a new success return value. Currently used actions don't return data that way yet. v2: fix prohibited space after '~' (Michel) update commit message (Daniele) v3: rebase Signed-off-by: -
Michal Wajdeczko authored
As we are going to extend our use of MMIO based communication, try to explain its mechanics and update corresponding definitions. v2: fix checkpatch MACRO_ARG_REUSE Signed-off-by:
-
Chris Wilson authored
Tvrtko uncovered a fun issue with recovering from a wedge device. In his tests, he wedged the driver by injecting an unrecoverable hang whilst a batch was spinning. As we reset the gpu in the middle of the spinner, when resumed it would continue on from the next instruction in the ring and write it's breadcrumb. However, on wedging we updated our bookkeeping to indicate that the GPU had completed executing and would restart from after the breadcrumb; so the emission of the stale breadcrumb from before the reset came as a bit of a surprise. A simple fix is to when rebinding the context into the GPU, we update the ring register state in the context image to match our bookkeeping. We already have to update the RING_START and RING_TAIL, so updating RING_HEAD as well is trivial. This works because whenever we unbind the context, we keep the bookkeeping in check; and on wedging we unbind all contexts. Testcase: igt/gem_eio Signed-off-by:
Mika Kuoppala <mika.kuoppala@linux.intel.com> Reviewed-by:
-
Paulo Zanoni authored
The only thing that differs here is that the crystal clock freq now has four possible values. This patch gets rid of the "Unknown gen, unable to compute..." message at boot for gen11. Reviewed-by:
Lionel Landwerlin <lionel.g.landwerlin@intel.com> Signed-off-by:
Paulo Zanoni <paulo.r.zanoni@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180109232835.11478-18-paulo.r.zanoni@intel.com
-
Yaodong Li authored
GuC Address Space and WOPCM Layout diagrams won't be generated correctly by sphinx build if not using proper reST syntax. This patch uses reST literal blocks to make sure GuC Address Space and WOPCM Layout diagrams to be generated correctly, and it also corrects some errors in the diagram description. v2: - Fixed errors in diagram description v3: - Updated GuC Address Space kernel-doc based on Michal's suggestion v4: - Added WOPCM layout and GuC address space docs into i915.rst (Joonas) Signed-off-by:
Jackie Li <yaodong.li@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> Reviewed-by:
Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Signed-off-by:
-
- 27 Mar, 2018 11 commits
-
-
Lucas De Marchi authored
Remove 4-bytes hole in this struct an reorder tables accordingly. This also changes the last element of the tables to be more future-proof. Signed-off-by:
Lucas De Marchi <lucas.demarchi@intel.com> Reviewed-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by:
Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180320220637.21480-8-lucas.demarchi@intel.com
-
Lucas De Marchi authored
Replace all users of pll->flags to use pll->info.flags. Signed-off-by:
-
Lucas De Marchi authored
Replace all users of pll->id to use pll->info->id. In functions using this more than once it was preferred to add an id variable to make the code easier to read. Signed-off-by:
-
Lucas De Marchi authored
Replace all users of pll->name to use pll->info->name. Signed-off-by:
-
Lucas De Marchi authored
Replace all users of pll->funcs.* to use pll->info->funcs->*. The extra indirection here is not on any critical path and we can leave all const data together. Signed-off-by:
-
Lucas De Marchi authored
This way we can stop copying fields from dpll_info to intel_shared_dpll one by one. The migration of each field will come on separate patches. Signed-off-by:
-
Lucas De Marchi authored
This will allow the struct to be embedded in intel_shared_dpll. Signed-off-by:
-
Lucas De Marchi authored
In some places we end up converting switch statements to a series of if/else, particularly when introducing helper functions to handle a group of cases. It's tempting to either leave a wrong warning (since now we don't have a switch case anymore) or to convert to WARN(1, ...), but we can just provide a better message and avoid the doubt when such conversions arrise. Introducing a warning inside i915_driver_load() just for tests we get: [ 4535.233717] Missing case (ret == 0) [ 4535.233868] WARNING: CPU: 1 PID: 795 at drivers/gpu/drm/i915/i915_drv.c:1341 i915_driver_load+0x42/0x10e0 [i915] which is clear enough. v2: remove __func__ since this is already on the warning. Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by:
-
Chris Wilson authored
If the request is still waiting on external fences, it has not yet been submitted to the HW queue and so we can forgo kicking the submission tasklet when re-evaluating its priority. This should have no impact other than reducing the number of tasklet wakeups under signal heavy workloads (e.g. switching between engines). v2: Use prebaked container_of() References: f6322edd ("drm/i915/preemption: Allow preemption between submission ports") Signed-off-by:
-
Chris Wilson authored
For the off-chance we have an interrupt posted and haven't processed the CSB. v2: Include tasklet enable/disable state for good measure. Signed-off-by:
-
Chris Wilson authored
When cancelling the requests and clearing out the ports following a successful preemption completion, also clear the active flag. I had assumed that all preemptions would be followed by an immediate dequeue (preserving the active user flag), but under rare circumstances we may be triggering a preemption for the second port only for it to have completed before the preemotion kicks in; leaving execlists->active set even though the system is now idle. We can clear the flag inside the common execlists_cancel_port_requests() as the other users also expect the semantics of active being cleared. Fixes: f6322edd ("drm/i915/preemption: Allow preemption between submission ports") Signed-off-by:
-
- 23 Mar, 2018 13 commits
-
-
Paulo Zanoni authored
Protect the macro parameters with parens in order to avoid priority issues on macro evaluation when the macro argument is not a single operand. This is not a problem today, but it could be in the future. I found this while reviewing a patch that introduces new callers for the macros. v2: Rebase. Reference: commit 04416108 ("drm/i915/cnl: Add registers related to voltage swing sequences.") Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by:
-
Nabendu Maiti authored
Gen11 supports upto 5k source scaling v2: Re-factoring of code as per review v3: Corrected max Vertical size and indentation v4: Added max Vertical dst size in same patch Reviewed-by:
Nabendu Maiti <nabendu.bikash.maiti@intel.com> Signed-off-by:
-
Dhinakaran Pandiyan authored
Extend enum hpd_pin to port F so that we can start using this for ICL. v2: Rebase. Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Paulo Zanoni <paulo.r.zanoni@intel.com> Reviewed-by:
Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> Signed-off-by:
-
Manasi Navare authored
This table is used for voltage swing programming sequence during DDI Buffer initialization for MG PHY DDI Buffers on Icelake. v2 (from Paulo): * Fix white space issues. Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Jani Nikula <jani.nikula@linux.intel.com> Reviewed-by:
Manasi Navare <manasi.d.navare@intel.com> Signed-off-by:
-
Manasi Navare authored
On Icelake platform, MG PHY is used when operating in DP alternate mode or the legacy HDMI or DP modes. DDI Ports C, D, E, F are MG PHY DDI ports on ICL. This patch adds the necessary voltage swing programming related register definitions and macros for MG PHY DDI ports. v4 (from Paulo): * Use _PORT instead of _PICK * Change some mask names to our current coding standards * Stay under 80 columns v3: * Rebase on new revision of patches v2: * Remove whitespaces in the #defines (Paulo) Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Jani Nikula <jani.nikula@linux.intel.com> Reviewed-by:
-
Manasi Navare authored
These tables are used on voltage vswing sequence initialization on Icelake. The swing_sel on the spec's table is defined in a 4 bits binary like 1010. However the register bits are split in upper 1 bit swing_sel and lower 3 bits swing sel. In this table here we store this value as a single value in hex like it is mentioned in the Bspec and split it to the upper and lower bit values only while programming the registers. For instance: b1010 is written as 0xA and then while writing to the register, the upper 1 bit is obtained by (0xA & 0x8) and shifting by appropriate bits while lower 3 bits are obtained by (0xA & 0x7) and shifting by appropriate bits. Some of the columns need to be updated after the spec is updated. v5 (from Paulo): * Checkpatch fixes. v4 (from Paulo): * Fix minor typo * Coding style conformance v3: * Get rid of HDMI/DVI tables, same as DP (Paulo) * Use combo_phy in ddi buf trans table defs (Paulo) v2: * Added DW4_scaling_hex column to the translation tables (Rodrigo) Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by:
-
Manasi Navare authored
This patch defines register definitions required for ICL voltage vswing programming for Combo PHY DDI Ports. It uses the same bit definitions and macros as the CNL voltage swing sequences. v8 (from Paulo): * Rebase. v7: * Kill _MMIIO_PORT2_LN (Paulo) v6: * Replace some spaces with TAB (Paulo) v5: * Use _PORT instead of _PICK (Paulo) * Remove DW7 defs for ICL, not used (Paulo) v4: * Rebase after _PICK was used instead of _PORT3 * Use _PICK for _MMIO_PORT2 since address of B is less than address of A so cant use the math (Paulo) v3: * Make changes to the existing macro in a diff patch (Paulo) v2: * Add new defs fro ICL regs (Paulo) Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by:
-
Imre Deak authored
After commit dd9f31c7 Author: Imre Deak <imre.deak@intel.com> Date: Wed Aug 16 17:46:07 2017 +0300 drm/i915/gen9+: Set same power state before hibernation image save/restore during hibernation/suspend the power domain functionality got disabled, after which resume could leave it incorrectly disabled if the ACPI target state was S0 during suspend and i915 was not loaded by the loader kernel. This was caused by not considering if we resumed from hibernation as the condition for power domains reiniting. Fix this by simply tracking if we suspended power domains during system suspend and reinit power domains accordingly during resume. This will result in reiniting power domains always when resuming from hibernation, regardless of the platform and whether or not i915 is loaded by the loader kernel. The reason we didn't catch this earlier is that the enabled/disabled state of power domains during PMSG_FREEZE/PMSG_QUIESCE is platform and kernel config dependent: on my SKL the target state is S4 during PMSG_FREEZE and (with the driver loaded in the loader kernel) S0 during PMSG_QUIESCE. On the reporter's machine it's S0 during PMSG_FREEZE but (contrary to this) power domains are not initialized during PMSG_QUIESCE since i915 is not loaded in the loader kernel, or it's loaded but without the DMC firmware being available. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=105196 Reported-and-tested-by: amn-bas@hotmail.com Fixes: dd9f31c7 ("drm/i915/gen9+: Set same power state before hibernation image save/restore") Cc: amn-bas@hotmail.com Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: <stable@vger.kernel.org> Signed-off-by:
Imre Deak <imre.deak@intel.com> Reviewed-by:
-
Chris Wilson authored
Commit 0f36a85c ("drm/i915: Flush pending interrupt following a GPU reset") got confused and only applied the flush to the set-wedge path (which itself is proving troublesome), but we also need the serialisation on the regular reset path. Oops. Move the interrupt into reset_irq() and make it common to the reset and final set-wedge. v2: reset_irq() after port cancellation, as we assert that execlists->active is sane for cancellation (and is being reset by reset_irq). References: 0f36a85c ("drm/i915: Flush pending interrupt following a GPU reset") Signed-off-by:
-
Michal Wajdeczko authored
We were fetching uC firmwares in separate uc_init_fw step, while there is no reason why we can't fetch them during init_early. This will also simplify upcoming patches, as size of the firmware may be used for register initialization. Signed-off-by:
-
Michal Wajdeczko authored
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:
-
Piotr Piórkowski authored
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: 6b0478fb ("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:
-
Ville Syrjälä authored
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=105655Signed-off-by:Shashank Sharma <shashank.sharma@intel.com>
-
