- 05 Oct, 2022 5 commits
-
-
Matthew Auld authored
For these types of display buffers, we need to able to CPU access some part of the backing memory in prepare_plane_clear_colors(). As a result we need to ensure we always place in the mappable part of lmem, which becomes necessary on small-bar systems. v2(Nirmoy & Ville): - Add some commentary for why we need to CPU access the buffer. - Split out the other changes, so we just consider the display change here. v3: - Handle this in the dpt path. v4(Ville): - Drop the intel_fb_rc_ccs_cc_plane() sanity check in pin_and_fence_fb_obj(), since we can also trigger this on DG1 it seems. Fixes: eb1c535f ("drm/i915: turn on small BAR support") Reported-by:
Jianshui Yu <jianshui.yu@intel.com> Signed-off-by:
Matthew Auld <matthew.auld@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Nirmoy Das <nirmoy.das@intel.com> Reviewed-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Acked-by:
Nirmoy Das <nirmoy.das@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20221004131916.233474-4-matthew.auld@intel.com
-
Matthew Auld authored
In the next patch we want to move the object (if the current resource is not compatible), to the mappable part of lmem for some display buffers. Currently that requires being able to unset the I915_BO_ALLOC_GPU_ONLY hint. Signed-off-by:
-
Matthew Auld authored
On platforms like DG2, it looks like the dpt path here is missing the migrate-to-lmem step on discrete platforms. v2: - Move the vma_pin() under the for_i915_gem_ww(), otherwise the object can be moved after dropping the lock and then doing the pin. Fixes: 33e7a975 ("drm/i915/xelpd: First stab at DPT support") Signed-off-by: -
Matthew Auld authored
The copy is async (if there even is one), but when later updating the GGTT we always sync against the binding, which will in turn sync against any moves. Signed-off-by:
-
Tvrtko Ursulin authored
Patch which added graceful exit for non-persistent contexts missed the fact it is not enough to set the exiting flag on a context and let the backend handle it from there. GuC backend cannot handle it because it runs independently in the firmware and driver might not see the requests ever again. Patch also missed the fact some usages of intel_context_is_banned in the GuC backend needed replacing with newly introduced intel_context_is_schedulable. Fix the first issue by calling into backend revoke when we know this is the last chance to do it. Fix the second issue by replacing intel_context_is_banned with intel_context_is_schedulable, which should always be safe since latter is a superset of the former. v2: * Just call ce->ops->revoke unconditionally. (Andrzej) Signed-off-by:
Tvrtko Ursulin <tvrtko.ursulin@intel.com> Fixes: 45c64ecf ("drm/i915: Improve user experience and driver robustness under SIGINT or similar") Cc: Andrzej Hajda <andrzej.hajda@intel.com> Cc: John Harrison <John.C.Harrison@Intel.com> Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: <stable@vger.kernel.org> # v6.0+ Reviewed-by:
Andrzej Hajda <andrzej.hajda@intel.com> Acked-by:
Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20221003121630.694249-1-tvrtko.ursulin@linux.intel.com
-
- 04 Oct, 2022 3 commits
-
-
Matt Roper authored
Intel hardware allows some preemption settings to be controlled either by the kernel-mode driver exclusively, or placed under control of the user-mode drivers; on Linux we always select the userspace control option. The various registers involved in this are not documented very clearly; let's add some clarifying comments to help explain how this all works and provide some history on why our Linux drivers take the approach they do (which I believe differs from the path taken by certain other operating systems' drivers). While we're at it, let's also remove the graphics version 12 upper bound on this programming. As described, we don't have any plans to move away from UMD control of preemption settings on future platforms, and there's currently no reason to believe that the hardware will fundamentally change how these registers and settings work after version 12. Bspec: 45921, 45858, 45863 Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Lionel Landwerlin <lionel.g.landwerlin@intel.com> Suggested-by:
Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Signed-off-by:
Matt Roper <matthew.d.roper@intel.com> Reviewed-by:
Wayne Boyer <wayne.boyer@intel.com> Acked-by:
Tapani Pälli <tapani.palli@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220907212410.22623-1-matthew.d.roper@intel.com
-
Matthew Auld authored
It looks like we need this for local-memory, if we want to use ptrace. Something more is still needed if we want to handle non-mappable memory, which looks quite annoying. v2: - ttm_bo_kmap doesn't seem to work well here, and seems to expect contiguous resource. v3(Andi): - s/PAGE_SIZE/bytes/ when passing in the size of the mapping. References: https://gitlab.freedesktop.org/drm/intel/-/issues/6989Signed-off-by:Andi Shyti <andi.shyti@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20221003172819.99245-1-matthew.auld@intel.com
-
Gwan-gyeong Mun authored
Remove unused function prototype; intel_gt_create_kobj() Cc: Andi Shyti <andi.shyti@linux.intel.com> Signed-off-by:
Gwan-gyeong Mun <gwan-gyeong.mun@intel.com> Reviewed-by:
-
- 03 Oct, 2022 19 commits
-
-
Daniele Ceraolo Spurio authored
The fw name is different and we need to record the fact that the blob is gsc-loaded, so add a new macro to help. Note: A-step DG2 G10 does not support HuC loading via GSC and would require a separate firmware to be loaded the legacy way, but that's not a production stepping so we're not going to bother. v2: rebase on new fw fetch logic Signed-off-by:
Tony Ye <tony.ye@intel.com> Reviewed-by:
Alan Previn <alan.previn.teres.alexis@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220928004145.745803-15-daniele.ceraolospurio@intel.com
-
Daniele Ceraolo Spurio authored
The current HuC status getparam return values are a bit confusing in regards to what happens in some scenarios. In particular, most of the error cases cause the ioctl to return an error, but a couple of them, INIT_FAIL and LOAD_FAIL, are not explicitly handled and neither is their expected return value documented; these 2 error cases therefore end up into the catch-all umbrella of the "HuC not loaded" case, with this case therefore including both some error scenarios and the load in progress one. The updates included in this patch change the handling so that all error cases behave the same way, i.e. return an errno code, and so that the HuC load in progress case is unambiguous. The patch also includes a small change to the FW init path to make sure we always transition to an error state if something goes wrong. Signed-off-by:
-
Daniele Ceraolo Spurio authored
Wait on the fence to be signalled to avoid the submissions finding HuC not yet loaded. v2: use dedicaded wait_queue_entry for waiting in HuC load, as submitq can't be re-used for it. Signed-off-by:
-
Daniele Ceraolo Spurio authored
Given that HuC load is delayed on DG2, this patch adds support for a fence that can be used to wait for load completion. No waiters are added in this patch (they're coming up in the next one), to keep the focus of the patch on the tracking logic. The full HuC loading flow on boot DG2 is as follows: 1) i915 exports the GSC as an aux device; 2) the mei-gsc driver is loaded on the aux device; 3) the mei-pxp component is loaded; 4) mei-pxp calls back into i915 and we load the HuC. Between steps 1 and 2 there can be several seconds of gap, mainly due to the kernel doing other work during the boot. The resume flow is slightly different, because we don't need to re-expose or re-probe the aux device, so we go directly to step 3 once i915 and mei-gsc have completed their resume flow. Here's an example of the boot timing, captured with some logs added to i915: [ 17.908307] [drm] adding GSC device [ 17.915717] [drm] i915 probe done [ 22.282917] [drm] mei-gsc bound [ 22.938153] [drm] HuC authenticated Also to note is that if something goes wrong during GSC HW init the mei-gsc driver will still bind, but steps 3 and 4 will not happen. The status tracking is done by registering a bus_notifier to receive a callback when the mei-gsc driver binds, with a large enough timeout to account for delays. Once mei-gsc is bound, we switch to a smaller timeout to wait for the mei-pxp component to load. The fence is signalled on HuC load complete or if anything goes wrong in any of the tracking steps. Timeout are enforced via hrtimer callbacks. v2: fix includes (Jani) v5: gsc_notifier() remove unneeded () Signed-off-by:
-
Daniele Ceraolo Spurio authored
The GSC will perform both the load and the authentication, so we just need to check the auth bit after the GSC has replied. Since we require the PXP module to load the HuC, the earliest we can trigger the load is during the pxp_bind operation. Note that GSC-loaded HuC survives GT reset, so we need to just mark it as ready when we re-init the GT HW. V2: move setting of HuC fw error state to the failure path of the HuC auth function, so it covers both the legacy and new auth flows V4: 1. Fix typo in the commit message 2. style fix in intel_huc_wait_for_auth_complete() Signed-off-by:
Vitaly Lubart <vitaly.lubart@intel.com> Signed-off-by:
Tomas Winkler <tomas.winkler@intel.com> Reviewed-by:
-
Tomas Winkler authored
Add support for loading HuC via a pxp stream command. V4: 1. Remove unnecessary include in intel_pxp_huc.h (Jani) 2. Adjust copyright year to 2022 Signed-off-by:
-
Vitaly Lubart authored
Command to be sent via the stream interface are written to a local memory page, whose address is then provided to the GSC. The interface supports providing a full sg with multiple pages for both input and output messages, but since for now we only aim to support short and synchronous messages we can use a single page for both input and output. Note that the mei interface expects an sg of 4k pages, while our lmem pages are 64k. If we ever need to support more than 4k we'll need to convert. Added a TODO comment to the code to record this. Signed-off-by:
-
Daniele Ceraolo Spurio authored
The mei_pxp module is required to send the command to load authenticate the HuC to the GSC even if pxp is not in use for protected content management. Signed-off-by:
-
Tomas Winkler authored
With on-boards graphics card, both i915 and MEI are in the same device hierarchy with the same parent, while for discrete gfx card the MEI is its child device. Adjust the match function for that scenario by matching MEI parent device with i915. Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> Link: https://patchwork.freedesktop.org/patch/msgid/20220928004145.745803-7-daniele.ceraolospurio@intel.com
-
Vitaly Lubart authored
The discrete graphics card with GSC firmware using command streamer API hence it requires to enhance pxp module with the new gsc_command() handler. The handler is implemented via mei_pxp_gsc_command() which is just a thin wrapper around mei_cldev_send_gsc_command() Signed-off-by:
-
Vitaly Lubart authored
Add mei bus API for sending gsc commands: mei_cldev_send_gsc_command() The GSC commands are originated in the graphics stack and are in form of SGL DMA buffers. The GSC commands are synchronous, the response is received in the same call on the out sg list buffers. The function setups pointers for in and out sg lists in the mei sgl extended header and sends it to the firmware. Signed-off-by:
-
Tomas Winkler authored
Fix kdoc for struct mei_ext_hdr and mei_ext_begin(). Signed-off-by:
-
Tomas Winkler authored
GSC command is and extended header containing a scatter gather list and without a data buffer. Using MEI_CL_IO_SGL flag, the caller send the GSC command as a data and the function internally moves it to the extended header. Signed-off-by:
-
Tomas Winkler authored
GSC extend header is of variable size and data is provided in a sgl list inside the header and not in the data buffers, need to enable the path. Signed-off-by:
-
Tvrtko Ursulin authored
Daniele needs 84d4333c ("misc/mei: Add NULL check to component match callback functions") in order to merge the DG2 HuC patches. Signed-off-by:
-
Tejas Upadhyay authored
Add these extra EHL entries back since we have drm-tip commit 13d29c82 ("drm/i915/ehl: unconditionally flush the pages on acquire") introduces proper flushing to make it work as expected. Cc: Chris Wilson <chris.p.wilson@intel.com> Cc: Matthew Auld <matthew.auld@intel.com> Fixes: 04609175 ("Revert "drm/i915/ehl: Update MOCS table for EHL"") Signed-off-by:
Tejas Upadhyay <tejas.upadhyay@intel.com> Acked-by:
-
Lucas De Marchi authored
Different handling for XeHP and later platforms should be using the xehp prefix, not gen125. Rename them. Signed-off-by:
Lucas De Marchi <lucas.demarchi@intel.com> Reviewed-by:
-
Lucas De Marchi authored
It's not obvious how the encode/decode of the per platform tables is done. Document it so while adding tables for new platforms people can be confident they right things is being done. Signed-off-by:
-
Lucas De Marchi authored
ce->wa_bb_page is allocated only for graphics version 12. However __gen125_emit_bb_start() is used for any graphics version >= 12.50. For the currently supported platforms this is not an issue, but for future ones there's a mismatch causing the jump to `wa_offset + DG2_PREDICATE_RESULT_BB` to be invalid since wa_offset is not correct. As in other places in the driver, check for graphics version "greater or equal" to future-proof the support for new platforms. Cc: Matt Roper <matthew.d.roper@intel.com> Cc: Matthew Auld <matthew.auld@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by:
-
- 30 Sep, 2022 3 commits
-
-
Aravind Iddamsetty authored
As an integrated GPU, MTL does not have local memory and HAS_LMEM() returns false. However the platform's stolen memory is presented via BAR2 (i.e., the BAR we traditionally consider to be the GMADR on IGFX) and should be managed by the driver the same way that local memory is on dgpu platforms (which includes setting the "lmem" bit on page table entries). We use the term "local stolen memory" to refer to this model. The major difference from the traditional BAR2 (GMADR) is that the stolen area is mapped via the BAR2 while in the former BAR2 is an aperture into the GTT VA through which access are made into stolen area. BSPEC: 53098, 63830 v2: 1. dropped is_dsm_invalid, updated valid_stolen_size check from Lucas (Jani, Lucas) 2. drop lmembar_is_igpu_stolen 3. revert to referring GFXMEM_BAR as GEN12_LMEM_BAR (Lucas) v3:(Jani) 1. rename get_mtl_gms_size to mtl_get_gms_size 2. define register for MMIO address v4:(Matt) 1. Use REG_FIELD_GET to read GMS value 2. replace the calculations with SZ_256M/SZ_8M v5: Include more details to commit message on how it is different from earlier platforms (Anshuman) Cc: Matt Roper <matthew.d.roper@intel.com> Cc: Lucas De Marchi <lucas.demarchi@intel.com> Cc: Jani Nikula <jani.nikula@linux.intel.com> Signed-off-by:
CQ Tang <cq.tang@intel.com> Signed-off-by:
Aravind Iddamsetty <aravind.iddamsetty@intel.com> Original-author: CQ Tang Reviewed-by:
-
Matt Roper authored
The part of the media and blitter engine contexts that we care about for setting up an initial state on MTL are nearly similar to DG2 (and PVC). The difference being PRT_BB_STATE being replaced with NOP. For render/compute engines, the part of the context images are nearly the same, although the layout had a very slight change --- one POSH register was removed and the placement of some LRI/noops adjusted slightly to compensate. v2: - Dg2, mtl xcs offsets slightly vary. Use a separate offsets array(Bala) - Add missing nop in xcs offsets(Bala) v3: - Fix the spacing for nop in xcs offset(MattR) v4: - Fix rcs register offset(MattR) v4.1: - Fix commit message(Lucas) Bspec: 46261, 46260, 45585 Cc: Balasubramani Vivekanandan <balasubramani.vivekanandan@intel.com> Cc: Licas De Marchi <lucas.demarchi@intel.com> Signed-off-by:
Radhakrishna Sripada <radhakrishna.sripada@intel.com> Reviewed-by:
-
Rob Clark authored
9178e3dcb121 ("mm: discard __GFP_ATOMIC") removed __GFP_ATOMIC, replacing it with a check for not __GFP_DIRECT_RECLAIM. Reported-by:Randy Dunlap <rdunlap@infradead.org> Reported-by:
Stephen Rothwell <sfr@canb.auug.org.au> Signed-off-by:
Rob Clark <robdclark@chromium.org> Acked-by: Randy Dunlap <rdunlap@infradead.org> # build-tested Signed-off-by:
Dave Airlie <airlied@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220929161404.2769414-1-robdclark@gmail.com
-
- 29 Sep, 2022 7 commits
-
-
Dave Airlie authored
Merge tag 'drm-intel-next-fixes-2022-09-29' of git://anongit.freedesktop.org/drm/drm-intel into drm-next - Fix release build bug in 'remove GuC log size module parameters' (John Harrison) - Remove ipc_enabled from struct drm_i915_private (Jani Nikula) - Do not cleanup obj with NULL bo->resource (Nirmoy Das) - Fix device info for devices without display (Jani Nikula) - Force DPLL calculation for TC ports after readout (Ville Syrjälä) - Use i915_vm_put on ppgtt_create error paths (Chris Wilson) Signed-off-by:
-
Prathap Kumar Valsan authored
Add flag to pipecontrol instruction to ensure in-flight writes are flushed to global observation point. Also split the pipecontrol instruction like we have in gen8. References: https://gitlab.freedesktop.org/drm/intel/-/issues/5886Signed-off-by:
Prathap Kumar Valsan <prathap.kumar.valsan@intel.com> Signed-off-by:
-
Nirmoy Das authored
i915_gem_drain_workqueue() call i915_gem_drain_freed_objects() so no need to call that again. Reviewed-by:
-
Nirmoy Das authored
i915_gem_drain_freed_objects() might not be enough to free all the objects and RCU delayed work might get scheduled after the i915 device struct gets freed. Call i915_gem_drain_workqueue() to catch all RCU delayed work. Suggested-by:
Chris Wilson <chris.p.wilson@intel.com> Acked-by:
-
Riana Tauro authored
A fundamental assumption is that at lower frequencies, not only do we run slower, but we save power compared to higher frequencies. live_slpc_power checks if running at low frequency saves power v2: re-use code to measure power fixed cosmetic review comments (Vinay) Signed-off-by:Riana Tauro <riana.tauro@intel.com> Reviewed-by:
Vinay Belgaumkar <vinay.belgaumkar@intel.com> Signed-off-by:
Anshuman Gupta <anshuman.gupta@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220923110043.789178-4-riana.tauro@intel.com
-
Riana Tauro authored
move the power measurement and the triangle filter to a different function. No functional changes. Signed-off-by:
-
Riana Tauro authored
Run slpc selftests on all tiles Signed-off-by:
-
- 28 Sep, 2022 3 commits
-
-
Niranjana Vishwanathapura authored
In await_fence_array(), unpacking syncobj pointer is not needed. Remove it. Reviewed-by:
Niranjana Vishwanathapura <niranjana.vishwanathapura@intel.com> Signed-off-by:
-
https://gitlab.freedesktop.org/agd5f/linuxDave Airlie authored
amd-drm-next-6.1-2022-09-23: amdgpu: - SDMA fix - Add new firmware types to debugfs/IOCTL version queries - Misc spelling and grammar fixes - Misc code cleanups - DCN 3.2.x fixes - DCN 3.1.x fixes - CS cleanup - Gang submit support - Clang fixes - Non-DC audio fix - GPUVM locking fixes - Vega10 PWN fan speed fix amdkgd: - MQD manager cleanup - Misc spelling and grammar fixes UAPI: - Add new firmware types to the FW version query IOCTL Signed-off-by:
-
git://anongit.freedesktop.org/drm/drm-miscDave Airlie authored
drm-misc-next for 6.1: UAPI Changes: Cross-subsystem Changes: - dma-buf: Improve signaling when debugging Core Changes: - Backlight handling improvements - format-helper: Add drm_fb_build_fourcc_list() - fourcc: Kunit tests improvements - modes: Add DRM_MODE_INIT() macro - plane: Remove drm_plane_init(), Allocate planes with drm_universal_plane_alloc() - plane-helper: Add drm_plane_helper_atomic_check() - probe-helper: Add drm_connector_helper_get_modes_fixed() and drm_crtc_helper_mode_valid_fixed() - tests: Conversion to parametrized tests, test name consistency Driver Changes: - amdgpu: Fix for a VRAM eviction issue - ast: Resolution handling improvements - mediatek: small code improvements for DP - omap: Refcounting fix, small improvements - rockchip: RK3568 support, Gamma support for RK3399 - sun4i: Build failure fix when !OF - udl: Multiple fixes here and there - vc4: HDMI hotplug handling improvements - vkms: Warning fix Signed-off-by:
-
