- 15 Mar, 2018 7 commits
-
-
Michal Wajdeczko authored
In commit 56b9a8b0 ("drm/i915/guc: Update syntax of GuC log functions") we accidentally removed debugfs.h header where needed stub functions were defined. Reported-by:
Mike Lothian <mike@fireburn.co.uk> Signed-off-by:
Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: Mike Lothian <mike@fireburn.co.uk> Cc: Chris Wilson <chris@chris-wilson.co.uk> Acked-by:
Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by:
-
Michal Wajdeczko authored
We moved GuC log related data and code to separate files and definition but we didn't change functions syntax to follow object-verb pattern. Let's fix that before we continue with next round of code refactoring. v2: rebased Signed-off-by:
Michał Winiarski <michal.winiarski@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180314144539.11152-1-michal.wajdeczko@intel.com [ickle: checkpatch booleans] Signed-off-by:
Chris Wilson <chris@chris-wilson.co.uk>
-
Michal Wajdeczko authored
We should not mix MMIO with MI_INSTR definitions. v2: sanitize comment, change include order (Chris) Suggested-by:
-
Daniele Ceraolo Spurio authored
The only usage outside the intel_lrc.c file is in the ringbuffer init, but the irq mask calculated there is then overwritten for all engines that have a non-zero shift, so we can drop it. This change is not aimed at code saving but at removing from intel_engines information that does not apply to all gens that have the engine. When checking without the temporary WARN_ON, code size is basically unchanged. v2: make the irq_shifts array static const v3: rebase, move irq_shifts array to logical_ring_default_irqs v4: move array inside the if and use u8 for it (Chris) Suggested-by:
Michel Thierry <michel.thierry@intel.com> Signed-off-by:
Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by:
-
Daniele Ceraolo Spurio authored
The "reset" value and the "keep" value are the same. While we are here, add a TODO for gen11 interrupt reset Suggested-by:
-
Daniele Ceraolo Spurio authored
Check that the entries are in reverse gen order and that all entries with gen > 0 have an mmio base set. v2: loop forward, simplify logic, use i915_subtests (Chris) Suggested-by:
-
Daniele Ceraolo Spurio authored
The mmio bases we're currently storing in the intel_engines array are only valid for a subset of gens, so we need to ignore them and use different values in some cases. Instead of doing that, we can have a table of [starting gen, mmio base] pairs for each engine in intel_engines and select the correct one based on the gen we're running on in a consistent way. v2: document that the list goes in reverse order, update starting gen for render (Chris) v3: starting gen for render back to 1 to make our life easier with selftests (Chris) Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Signed-off-by:
-
- 14 Mar, 2018 9 commits
-
-
Mahesh Kumar authored
This patch replaces use of remaining _MMIO_PORT6 macro and removes the macro. Changes Since V1: - Rebase Signed-off-by:
Mahesh Kumar <mahesh1.kumar@intel.com> Reviewed-by:
-
Mahesh Kumar authored
This patch creates a new macro to get PORT_TX register for any given DW. This removes the need of defining register address for each port & DW. Changes since V1: - Use underscope prefix, as macro isn't returning an mmio reg(Lucas) - Merge patch 1 & 2 of the series Changes since V2: - remove _MMIO_PORT6_LN macro (Rodrigo) Signed-off-by:
-
Tvrtko Ursulin authored
Arnd Bergman reports: """ The conditional spinlock confuses gcc into thinking the 'flags' value might contain uninitialized data: drivers/gpu/drm/i915/i915_pmu.c: In function '__i915_pmu_event_read': arch/x86/include/asm/paravirt_types.h:573:3: error: 'flags' may be used uninitialized in this function [-Werror=maybe-uninitialized] The code is correct, but it's easy to see how the compiler gets confused here. This avoids the problem by pulling the lock outside of the function into its only caller. """ On deeper look it seems this is caused by paravirt spinlocks implementation when CONFIG_PARAVIRT_DEBUG is set, which by being complicated, manages to convince gcc locked parameter can be changed externally (impossible). Work around it by removing the conditional locking parameters altogether. (It was never the most elegant code anyway.) Slight penalty we now pay is an additional irqsave spin lock/unlock cycle on the event enable path. But since enable is not a fast path, that is preferrable to the alternative solution which was doing MMIO under irqsave spinlock. Signed-off-by:
Tvrtko Ursulin <tvrtko.ursulin@intel.com> Reported-by:
Arnd Bergmann <arnd@arndb.de> Fixes: 1fe699e3 ("drm/i915/pmu: Fix sleep under atomic in RC6 readout") Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Imre Deak <imre.deak@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: David Airlie <airlied@linux.ie> Cc: intel-gfx@lists.freedesktop.org Cc: dri-devel@lists.freedesktop.org Reviewed-by:
-
Chris Wilson authored
Not only is the context suspect to disappearing, but so is it's timeline. Under a lockless inspection of the requests for debugging from intel_engine_dump(), the context may already have been freed and we have to check before chasing the dangling pointer. [28033.681755] Modules linked in: vgem snd_hda_codec_hdmi snd_hda_codec_realtek snd_hda_codec_generic x86_pkg_temp_thermal intel_powerclamp coretemp snd_hda_intel crct10dif_pclmul crc32_pclmul snd_hda_codec snd_hwdep snd_hda_core ghash_clmulni_intel snd_pcm mei_me mei i915 r8169 mii prime_numbers i2c_hid [28033.681796] CPU: 3 PID: 3058 Comm: gem_exec_schedu Tainted: G U 4.16.0-rc5+ #9 [28033.681804] Hardware name: Acer Aspire E5-575G/Ironman_SK , BIOS V1.12 08/02/2016 [28033.681834] RIP: 0010:print_request+0x2b/0xb0 [i915] [28033.681840] RSP: 0018:ffffc90004afbc18 EFLAGS: 00010202 [28033.681847] RAX: 6b6b6b6b6b6b6b6b RBX: ffff8801921b5a40 RCX: 0000000000000006 [28033.681854] RDX: ffffc90004afbc60 RSI: ffff8801921b5a40 RDI: 0000000000000004 [28033.681861] RBP: ffffc90004afbd80 R08: 0000000000000000 R09: 0000000000000001 [28033.681868] R10: ffffc90004afbbd0 R11: ffffc90004afbc73 R12: ffffc90004afbc60 [28033.681875] R13: ffffc90004afbd80 R14: ffff8801d40ec670 R15: ffff8801921b5a40 [28033.681883] FS: 00007fbba5f6c8c0(0000) GS:ffff8801e8400000(0000) knlGS:0000000000000000 [28033.681891] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [28033.681897] CR2: 00007fbba5f8f000 CR3: 00000001b2efa002 CR4: 00000000003606e0 [28033.681904] Call Trace: [28033.681932] intel_engine_print_registers+0x6a7/0x930 [i915] [28033.681962] intel_engine_dump+0x30d/0x740 [i915] [28033.681971] ? seq_printf+0x3a/0x50 [28033.681995] i915_engine_info+0xb8/0xe0 [i915] [28033.682003] ? drm_get_color_range_name+0x20/0x20 [28033.682010] seq_read+0xe1/0x440 [28033.682018] full_proxy_read+0x51/0x80 [28033.682025] __vfs_read+0x21/0x130 [28033.682031] ? do_sys_open+0x134/0x220 [28033.682037] ? kmem_cache_free+0x177/0x2b0 [28033.682043] vfs_read+0xa1/0x150 [28033.682049] SyS_read+0x40/0xa0 [28033.682055] do_syscall_64+0x6b/0x1b0 [28033.682063] entry_SYSCALL_64_after_hwframe+0x42/0xb7 [28033.682069] RIP: 0033:0x7fbba4655d11 [28033.682074] RSP: 002b:00007ffd8c49da58 EFLAGS: 00000246 ORIG_RAX: 0000000000000000 [28033.682082] RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007fbba4655d11 [28033.682089] RDX: 000000000000003f RSI: 00005647bfbfc260 RDI: 0000000000000006 [28033.682096] RBP: 000000000000003f R08: 00000000ffffffff R09: 0000000000000000 [28033.682104] R10: 0000000000000000 R11: 0000000000000246 R12: 00005647bfbfc260 [28033.682111] R13: 0000000000000006 R14: 0000000000000000 R15: 00005647bfbfc260 [28033.682119] Code: 41 55 41 54 49 89 d4 55 53 48 89 fd 48 8b 86 c8 00 00 00 48 8b 3d d6 1e 14 e2 48 89 f3 48 2b be a8 02 00 00 48 8b 80 b0 00 00 00 <4c> 8b 68 18 e8 bc 80 02 e1 8b 8b 70 02 00 00 8b b3 28 02 00 00 [28033.682206] RIP: print_request+0x2b/0xb0 [i915] RSP: ffffc90004afbc18 Reported-by:
Mika Kuoppala <mika.kuoppala@linux.intel.com> Signed-off-by:
-
Jackie Li authored
GuC WOPCM registers are write-once registers. Current driver code accesses these registers without checking the accessibility to these registers which will lead to unpredictable driver behaviors if these registers were touch by other components (such as faulty BIOS code). This patch moves the GuC WOPCM registers updating code into intel_wopcm.c and adds check before and after the update to GuC WOPCM registers so that we can make sure the driver is in a known state after writing to these write-once registers. v6: - Made sure module reloading won't bug the kernel while doing locking status checking v7: - Fixed patch format issues v8: - Fixed coding style issue on register lock bit macro definition (Sagar) v9: - Avoided to use redundant !! to cast uint to bool (Chris) - Return error code instead of GEM_BUG_ON for locked with invalid register values case (Sagar) - Updated guc_wopcm_hw_init to use guc_wopcm as first parameter (Michal) - Added code to set and validate the HuC_LOADING_AGENT_GUC bit in GuC WOPCM offset register based on the presence of HuC firmware (Michal) - Use bit fields instead of macros for GuC WOPCM flags (Michal) v10: - Refined variable names, removed redundant comments (Joonas) - Introduced lockable_reg to handle the write once register write and propagate the write error to caller (Joonas) - Used lockable_reg abstraction to avoid locking bit check on generic i915_reg_t (Michal) - Added log message for error paths (Michal) - Removed hw_updated flag and only relies on real hardware status v11: - Replaced lockable_reg with simplified function (Michal) - Used new macros for locking bits of WOPCM size/offset registers instead of using BIT(0) directly (Michal) - use intel_wopcm_init_hw() called from intel_gem_init_hw() to do GuC WOPCM register setup instead of calling from intel_uc_init_hw() (Michal) v12: - Updated function kernel-doc to align with code changes (Michal) - Updated code to use wopcm pointer directly (Michal) v13: - Updated the ordering of s-o-b/cc/r-b tags (Sagar) BSpec: 10875, 10833 Signed-off-by:
Jackie Li <yaodong.li@intel.com> Cc: Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Reviewed-by: Michal Wajdeczko <michal.wajdeczko@intel.com> (v11) Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> (v12) Reviewed-by:
Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Signed-off-by:
-
Jackie Li authored
On CNL A0 and Gen9, there's a hardware restriction that requires the available GuC WOPCM size to be larger than or equal to HuC firmware size. This patch adds new verification code to ensure the available GuC WOPCM size to be larger than or equal to HuC firmware size on both Gen9 and CNL A0. v6: - Extended HuC FW size check against GuC WOPCM size to all Gen9 and CNL A0 platforms v7: - Fixed patch format issues v8: - Renamed variables and functions to avoid ambiguity (Joonas) - Updated commit message and comments to be more comprehensive (Sagar) v9: - Moved code that is not related to restriction check into a separate patch and updated the commit message accordingly (Sagar/Michal) - Avoided to call uc_get_fw_size for better layer isolation (Michal) v10: - Shorten function names and reorganized size_check code to have clear isolation (Joonas) - Removed unnecessary comments (Joonas) v11: - Fixed logic error in size check (Michal) v12: - Add space between "HuC FW" and "(%uKiB)" in error message (Michal) v13: - Updated the ordering of s-o-b/cc/r-b tags (Sagar) BSpec: 10875 Signed-off-by:
-
Jackie Li authored
CNL has its specific reserved GuC WOPCM size for RC6 and other hardware contexts. This patch updates the code to return CNL specific reserved GuC WOPCM size for RC6 and other hardware contexts so that the GuC WOPCM size can be calculated correctly for CNL. v9: - Created a new patch for these changes originally made in v8 4/6 patch of this series (Sagar/Michal) v10: - Used if-else ladder to the returning of context sizes (Joonas) v11: - Removed GUC_ prefix from context size macro (Michal) v13: - Updated the ordering of s-o-b/cc/r-b tags (Sagar) Bspec: 12690 Signed-off-by:
-
Jackie Li authored
Hardware may have specific restrictions on GuC WOPCM offset and size. On Gen9, the value of the GuC WOPCM size register needs to be larger than the value of GuC WOPCM offset register + a Gen9 specific offset (144KB) for reserved GuC WOPCM. Fail to enforce such a restriction on GuC WOPCM size will lead to GuC firmware execution failures. On the other hand, with current static GuC WOPCM offset and size values (512KB for both offset and size), the GuC WOPCM size verification will fail on Gen9 even if it can be fixed by lowering the GuC WOPCM offset by calculating its value based on HuC firmware size (which is likely less than 200KB on Gen9), so that we can have a GuC WOPCM size value which is large enough to pass the GuC WOPCM size check. This patch updates the reserved GuC WOPCM size for RC6 context on Gen9 to 24KB to strictly align with the Gen9 GuC WOPCM layout. It also adds support to verify the GuC WOPCM size aganist the Gen9 hardware restrictions. To meet all above requirements, let's provide dynamic partitioning of the WOPCM that will be based on platform specific HuC/GuC firmware sizes. v2: - Removed intel_wopcm_init (Ville/Sagar/Joonas) - Renamed and Moved the intel_wopcm_partition into intel_guc (Sagar) - Removed unnecessary function calls (Joonas) - Init GuC WOPCM partition as soon as firmware fetching is completed v3: - Fixed indentation issues (Chris) - Removed layering violation code (Chris/Michal) - Created separat files for GuC wopcm code (Michal) - Used inline function to avoid code duplication (Michal) v4: - Preset the GuC WOPCM top during early GuC init (Chris) - Fail intel_uc_init_hw() as soon as GuC WOPCM partitioning failed v5: - Moved GuC DMA WOPCM register updating code into intel_wopcm.c - Took care of the locking status before writing to GuC DMA Write-Once registers. (Joonas) v6: - Made sure the GuC WOPCM size to be multiple of 4K (4K aligned) v8: - Updated comments and fixed naming issues (Sagar/Joonas) - Updated commit message to include more description about the hardware restriction on GuC WOPCM size (Sagar) v9: - Minor changes variable names and code comments (Sagar) - Added detailed GuC WOPCM layout drawing (Sagar/Michal) - Refined macro definitions to be reader friendly (Michal) - Removed redundent check to valid flag (Michal) - Unified first parameter for exported GuC WOPCM functions (Michal) - Refined the name and parameter list of hardware restriction checking functions (Michal) v10: - Used shorter function name for internal functions (Joonas) - Moved init-ealry function into c file (Joonas) - Consolidated and removed redundant size checks (Joonas/Michal) - Removed unnecessary unlikely() from code which is only called once during boot (Joonas) - More fixes to kernel-doc format and content (Michal) - Avoided the use of PAGE_MASK for 4K pages (Michal) - Added error log messages to error paths (Michal) v11: - Replaced intel_guc_wopcm with more generic intel_wopcm and attached intel_wopcm to drm_i915_private instead intel_guc (Michal) - dynamic calculation of GuC non-wopcm memory start (a.k.a WOPCM Top offset from GuC WOPCM base) (Michal) - Moved WOPCM marco definitions into .c source file (Michal) - Exported WOPCM layout diagram as kernel-doc (Michal) v12: - Updated naming, function kernel-doc to align with new changes (Michal) v13: - Updated the ordering of s-o-b/cc/r-b tags (Sagar) - Corrected one tense error in comment (Sagar) - Corrected typos and removed spurious comments (Joonas) Bspec: 12690 Signed-off-by:
-
Jackie Li authored
GuC related exported functions should start with "intel_guc_" prefix and pass intel_guc as the first parameter since its GuC related. Current guc_ggtt_offset() failed to follow this code convention and this is a problem for future patches that needs to access intel_guc data to verify the GGTT offset against the GuC WOPCM top. This patch renames the guc_ggtt_offset to intel_guc_ggtt_offset and updates the related code to pass intel_guc pointer to this function call, so that we can have a unified coding style for GuC code and also enable the future patches to get GuC related data from intel_guc to do the offset verification. Meanwhile, this patch also moves the GUC_GGTT_TOP from intel_guc_regs.h to intel_guc.h since it is not GuC register related definition. v8: - Fixed coding style issues and moved GUC_GGTT_TOP to intel_guc.h (Sagar) - Updated commit message to explain to reason and motivation to add intel_guc as the first parameter of intel_guc_ggtt_offset (Chris) v9: - Fixed code alignment issue due to line break (Chris) v10: - Removed unnecessary comments, redundant code and avoided reuse variable to avoid potential issues (Joonas) v13: - Updated the ordering of s-o-b/cc/r-b tags (Sagar) Signed-off-by:
-
- 13 Mar, 2018 10 commits
-
-
Dhinakaran Pandiyan authored
What was called SRD_DEBUG(0x6F860) on HSW and BDW was renamed to PSR_MASK SKL onwards, add a note next to the macro definition. There is also a different PSR_DEBUG on SKL+ to add to the confusion. Signed-off-by:
Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> Acked-by:
-
Chris Wilson authored
If we timeout waiting for the GPU to idle, something went seriously wrong. We currently dump the engine state, but we can also dump the ftrace buffer showing our last operations (when available). In passing, note that since commit 559e040f ("drm/i915: Show the GPU state when declaring wedged", we now show the engine state twice, once in detecting the failed idle and then again on declaring wedged. v2: ftrace_dump() takes a parameter specifying whether to dump all cpu buffers or the local cpu's. Signed-off-by:
-
Rodrigo Vivi authored
No functional change. But let's keep definitions clean and cursor related register definitions together. v2: Fix caps x no caps on same reg. Change name to match original reg name. (by Ville). Also fix name on code s/surlive/surflive and on subject s/cur_surlife/cur surflive/. Suggested-by:Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by:
-
Dhinakaran Pandiyan authored
The flag becomes misleading with flips and cursor moves not modifying it's state as HW takes care of exiting PSR (when HW tracking is enabled) Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by:
-
Rodrigo Vivi authored
So far we are using frontbuffer tracking for everything and ignoring that PSR has a HW capable HW tracking for many modern usages of GPU on Core platforms and newer Atom ones. One reason for that is that we were trying to keep same infrastructure in place for VLV/CHV than the rest of platforms. But also because when this infrastructure was created the front-buffer-tracking origin wasn't that good and stable how it is today after Paulo reworked it to attend FBC cases. However this PSR implementation without HW tracking died on gen8LP. And newer platforms are starting to demand more HW tracking specially with PSR2 cases in mind. By disabling and re-enabling PSR totally every time we believe someone is going to change the front buffer content we don't allow PSR HW tracking to do this job and specially compromising the whole idea of PSR2 case where the HW tracking detect only the damaged area and do a partial screen update. So, from now on, on the platforms that has hw_tracking let's rely more on HW tracking. This also is the case in used by other drivers and more validated by SV teams. So I hope that this will lead us to less misterious bugs. v2: Only do this for platform that actually has hw tracking. v3 from DK Do this only for flips, small gradual changes are better. Cc: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> Cc: Jim Bride <jim.bride@linux.intel.com> Cc: Vathsala Nagaraju <vathsala.nagaraju@intel.com> Signed-off-by:
Jose Roberto de Souza <jose.souza@intel.com> Signed-off-by:
-
Dhinakaran Pandiyan authored
DRM_IOCTL_MODE_CURSOR results in frontbuffer flush before the cursor plane MMIOs are written to. But this flush should not be necessary for PSR as hardware tracking triggers PSR exit when MMIOs are written. As for FBC, the spec says "Flips or changes to plane size and panning" cause FBC to be nuked. Use origin == ORIGIN_FLIP so that features can ignore cursor updates in their frontbuffer_flush implementations. /sys/kernel/debug/dri/0/i915_fbc_status shows "Compressing: yes" when I move the cursor around. v3: Use ORIGIN_FLIP now that pin_to_display does not flush frontbuffer. v2: Update comment in i915_gem_object_pin_to_display_plane. (Chris) Cc: Paulo Zanoni <paulo.r.zanoni@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by:
-
Dhinakaran Pandiyan authored
i915_gem_obj_pin_to_display() calls frontbuffer_flush with origin set to DIRTYFB. The callers however are at a vantage point to decide if hardware frontbuffer tracking can do the flush for us. For example, legacy cursor updates, like flips, write to MMIO registers, which then triggers PSR flush by the hardware. Moving frontbuffer_flush out will enable us to skip a software initiated flush by setting origin to FLIP. Thanks to Chris for the idea. v2: Rebased due to Ville adding intel_plane_pin_fb(). Minor code reordering as fb_obj_flush doesn't need struct_mutex (Chris) Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by:
-
Chris Wilson authored
eu_regs[] is written 2*max_slices times (like s_reg[]) but oddly read 2*max_slices + max_subslices/2 times. Allocate the array large enough for the writes to avoid overwriting our stack and worry about the logic later. Fixes: 7aa0b14e ("drm/i915: Remove variable length arrays from sseu debugfs printers") Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=105479Signed-off-by:
Lionel Landwerlin <lionel.g.landwerlin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180313113149.1094-1-chris@chris-wilson.co.uk
-
Chris Wilson authored
VLA are strongly discouraged in the kernel due to ambiguity they impose on the limited stack space and security concerns over manipulating the stack frame. Add -Wvla to our compiler flags so that CI rejects them. Signed-off-by:
Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180313004055.25411-2-chris@chris-wilson.co.uk
-
Chris Wilson authored
In order to enable -Wvla to prevent new variable length arrays being used in i915.ko, we first must remove the existing VLA. Inside i915_print_sseu_info(), VLA are used as the actual size of the sseu depends on platform. Replace the VLA with the maximum required. Signed-off-by:
-
- 12 Mar, 2018 4 commits
-
-
Michal Wajdeczko authored
Instead of dancing around uC on reset/suspend/resume scenarios, explicitly sanitize uC when we sanitize GEM to force uC reload and start from known beginning. v2: don't forget about reset path (Daniele) sanitize uc before gem initiated full reset (Daniele) v3: drop redundant disable_communication in init_hw (Daniele) Signed-off-by: -
Michal Wajdeczko authored
We are sanitizing uC related modparams together with other driver modparams in intel_sanitize_options called from i915_driver_init_hw, but this is too late for us as we will want to use USES_GUC/USES_HUC macros at earlier stage. Since our sanitizing does not require any MMIO access, we can do it in intel_uc_init_early right after we resolve firmware names. Signed-off-by:
-
Chris Wilson authored
There is some redundancy between dma_fence->ops->enable_signaling (via i915_fence_enable_signaling) and our backend, intel_engine_enable_signaling() in that both levels recheck the fence status multiple times. If we convert intel_engine_enable_signaling() to return the information desired by dma_fence->ops->enable_signaling, we can reduce i915_fence_enable_signaling to a simple stub and avoid trying to reinterpret the same information. Signed-off-by:
-
Rodrigo Vivi authored
WA 0884:bxt:all,cnl:*:A - "When FBC is enabled with eDP PSR, the CPU host modify writes may not get updated on the Display as expected. WA: Write 0x00000000 to CUR_SURFLIVE_A with every CPU host modify write to trigger PSR exit." We can also find on spec other cases where they describe bogus writes to cursor registers to force PSR exit with HW tracking. And it was confirmed by HW engineers that this Wa can be safely applied for any frontbuffer activity. So let's use this more and more here instead of forcibly disable and re-enable PSR everytime that we have a simple reliable flush case. Other commits improve the fbcon/fbdev use a lot, but this approach is the only when where we can get a fully reliable console with no slowness or missed frames and PSR still enabled and active. v2: - Rebase on drm-tip - (DK) Add a comment to explain that WA tells about writing 0 to CUR_SURFLIVE_A but we write to CUR_SURFLIVE(pipe). v3: Wa doesn't work on PSR2. Cc: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> Signed-off-by:
-
- 09 Mar, 2018 10 commits
-
-
Michal Wajdeczko authored
Error state management code was moved into separate .c unit but we didn't move related definitions into own header. v2: move also intel_display_error_state forward decl fix ("Prefer 'unsigned int' to bare use of 'unsigned'") warnings detected by checkpatch in moved code (Michal) Signed-off-by: -
Michal Wajdeczko authored
Definitions in i915_pmu.h header depend on other types and declarations that were not explicitly included. Fix that by adding related headers and forward declarations. While here, change license text to SPDX format. v2: don't drop "intel_ringbuffer.h" (Tvrtko) Signed-off-by:
-
Michal Wajdeczko authored
Function i915_gem_batch_pool_init() failed to follow obj-verb naming schema. Fix that by swapping function parameters. While here, change license text to SPDX format. v2: use intel_engine_init_batch_pool (Chris) as proxy (Michal) Signed-off-by:
-
Michal Wajdeczko authored
Header intel_ringbuffer.h is using definitions from i915_reg.h but forget to include it. Remove this hidden dependency by explicitly include missing header. v2: add reminder (Chris) Signed-off-by:
-
Michal Wajdeczko authored
To allow future code reuse. While here, fix comment style. v2: Notifications are a separate thing - rename the handler (Sagar) Suggested-by:
Oscar Mateo <oscar.mateo@intel.com> Signed-off-by:
Sagar Arun Kamble <sagar.a.kamble@intel.com> Signed-off-by:
-
Michał Winiarski authored
We have many functions responsible for allocating different parts of GuC log runtime called from multiple places. Let's stick with keeping everything in guc_log_register instead. v2: Use more generic intel_uc_register name, keep using "misc" suffix (Michał) s/dev_priv/i915 (Sagar) Make guc_log_relay_* static (sparse) Signed-off-by: -
Michał Winiarski authored
We plan to decouple log runtime (mapping + relay) from verbosity control. Let's tidy the code now to reduce the churn in the following patches. v2: Tidy macros, keep debug messages, use helper var for enable, correct typo (Michał) Fix incorrect input validaction (Sagar) Signed-off-by: -
Lyude Paul authored
Signed-off-by:
Lyude Paul <lyude@redhat.com> Cc: Manasi Navare <manasi.d.navare@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by:
Manasi Navare <manasi.d.navare@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180308232421.14049-2-lyude@redhat.com
-
Chris Wilson authored
tasklet_kill() will spin waiting for the current tasklet to be executed. However, if tasklet_disable() has been called, then the tasklet is never executed but permanently put back onto the runlist until tasklet_enable() is called. Ergo, we cannot use tasklet_kill() inside a disable/enable pair. This is the case when we call set-wedge from inside i915_reset(), and another request was submitted to us concurrent to the reset. Fixes: 963ddd63 ("drm/i915: Suspend submission tasklets around wedging") Signed-off-by:
-
Chris Wilson authored
Similar to the staging around handling of engine->submit_request, we need to stop adding to the execlists->queue prior to calling engine->cancel_requests. cancel_requests will move requests from the queue onto the timeline, so if we add a request onto the queue after that point, it will be lost. Fixes: af7a8ffa ("drm/i915: Use rcu instead of stop_machine in set_wedged") Signed-off-by:
-
