- 03 May, 2023 1 commit
-
-
Tejas Upadhyay authored
It will be more informative regarding GT if we use gt_err instead. Cc: Andi Shyti <andi.shyti@intel.com> Signed-off-by:
Tejas Upadhyay <tejas.upadhyay@intel.com> Reviewed-by:
Andi Shyti <andi.shyti@linux.intel.com> Signed-off-by:
-
- 02 May, 2023 3 commits
-
-
Umesh Nerlige Ramappa authored
Enable fdinfo for GuC based platforms with the exception that long running contexts will not provide reliable busyness data unless they switch out at some reasonable point in time. Link: https://gitlab.freedesktop.org/drm/intel/issues/8303Signed-off-by:
Umesh Nerlige Ramappa <umesh.nerlige.ramappa@intel.com> Reviewed-by:
Ashutosh Dixit <ashutosh.dixit@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230427224705.2785566-3-umesh.nerlige.ramappa@intel.com
-
Umesh Nerlige Ramappa authored
GPU accumulates the context runtime in a 32 bit counter - CTX_TIMESTAMP in the context image. This value is saved/restored on context switches. KMD accumulates these values into a 64 bit counter taking care of any overflows as needed. This count provides the basis for client specific busyness in the fdinfo interface. KMD accumulation happens just before the context is unpinned and when context switches out. This works for execlist back-end since execlist scheduling has visibility into context switches. With GuC mode, KMD does not have visibility into context switches and this counter is accumulated only when context is unpinned. Context is unpinned once the context scheduling is successfully disabled. Disabling context scheduling is an asynchronous operation. Also if a context is servicing frequent requests, scheduling may never be disabled on it. For GuC mode, since updates to the context runtime may be delayed, add hooks to update the context runtime in a worker thread as well as when a user queries for it. Limitation: - If a context is never switched out or runs for a long period of time, the runtime value of CTX_TIMESTAMP may never be updated, so the counter value may be unreliable. This patch does not support such cases. Such support must be available from the GuC FW and it is WIP. This patch is an extract from previous work authored by John/Umesh here - https://patchwork.freedesktop.org/patch/496441/?series=105085&rev=4 v2: (Ashutosh) - Drop COPS_RUNTIME_ACTIVE_TOTAL - s/guc_context_update_clks/__guc_context_update_stats - Pin context before accessing in guc_timestamp_ping - In guc_context_unpin, use spinlock to serialize access to runtime stats Signed-off-by:
John Harrison <John.C.Harrison@Intel.com> Signed-off-by:
-
Jani Nikula authored
Remove useless indirection that's just misdirection for the readers. Signed-off-by:
Jani Nikula <jani.nikula@intel.com> Reviewed-by:
Matt Roper <matthew.d.roper@intel.com> Reviewed-by:
Andrzej Hajda <andrzej.hajda@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230421135948.2029121-1-jani.nikula@intel.com
-
- 28 Apr, 2023 4 commits
-
-
Vinay Belgaumkar authored
Use the new efficient frequency toggling interface. Also create a helper function to restore the frequencies after the test is done. v2: Restore max freq first and then min. Signed-off-by:
Vinay Belgaumkar <vinay.belgaumkar@intel.com> Reviewed-by:
-
Vinay Belgaumkar authored
SLPC enables use of efficient freq at init by default. It is possible for GuC to request frequencies that are higher than the 'software' max if user has set it lower than the efficient level. Scenarios/tests that require strict fixing of freq below the efficient level will need to disable it through this interface. v2: Keep just one interface to toggle sysfs. With this, user will be completely responsible for toggling efficient frequency if need be. There will be no implicit disabling when user sets min < RP1 (Ashutosh) v3: Remove unused label, review comments (Ashutosh) v4: Toggle efficient freq usage in SLPC selftest and checkpatch fixes v5: Review comments (Andi) and add a separate patch for selftest updates Fixes: 95ccf312 ("drm/i915/guc/slpc: Allow SLPC to use efficient frequency") Signed-off-by:
Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by:
-
Jonathan Cavitt authored
MTL currently uses gen8_ppgtt_insert_huge when managing huge pages. This is because MTL reports as not supporting 64K pages, or more accurately, the system that reports whether a platform has 64K pages reports false for MTL. This is only half correct, as the 64K page support reporting system only cares about 64K page support for LMEM, which MTL doesn't have. MTL should be using xehpsdv_ppgtt_insert_huge. However, simply changing over to using that manager doesn't resolve the issue because MTL is expecting the virtual address space for the page table to be flushed after initialization, so we must also add a flush statement there. Signed-off-by:
Jonathan Cavitt <jonathan.cavitt@intel.com> Reviewed-by:
Matthew Auld <matthew.auld@intel.com> Signed-off-by:
-
Jonathan Cavitt authored
Convert the igt_mock_ppgtt_huge_fill and igt_mock_ppgtt_64K mock selftests into live selftests as their requirements have recently become platform-dependent. Additionally, apply necessary platform dependency checks to these tests. v8: - handle properly 64K and 2M pages v9: - do not expect 64K pages if 2M are present - fix hex printing - obey commit message line limit Signed-off-by:
-
- 26 Apr, 2023 5 commits
-
-
Radhakrishna Sripada authored
Enable strict RAR to prevent spurious GPU hangs. v1.1: Rebase Bspec: 51762 Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by:
Radhakrishna Sripada <radhakrishna.sripada@intel.com> Reviewed-by:
Haridhar Kalvala <haridhar.kalvala@intel.com> Reviewed-by:
-
Ashutosh Dixit authored
Instead of erroring out when GuC reset is in progress, block waiting for GuC reset to complete which is a more reasonable uapi behavior. v2: Avoid race between wake_up_all and waiting for wakeup (Rodrigo) v3: Remove timeout when blocked (Tvrtko) Signed-off-by:
-
Ashutosh Dixit authored
On dGfx, the PL1 power limit being enabled and set to a low value results in a low GPU operating freq. It also negates the freq raise operation which is done before GuC firmware load. As a result GuC firmware load can time out. Such timeouts were seen in the GL #8062 bug below (where the PL1 power limit was enabled and set to a low value). Therefore disable the PL1 power limit when allowed by HW when loading GuC firmware. v2: - Take mutex (to disallow writes to power1_max) across GuC reset/fw load - Add hwm_power_max_restore to error return code path v3 (Jani N): - Add/remove explanatory comments - Function renames - Type corrections - Locking annotation v4: - Don't hold the lock across GuC reset (Rodrigo) - New locking scheme (suggested by Rodrigo) - Eliminate rpm_get in power_max_disable/restore, not needed (Tvrtko) v5: - Fix uninitialized pl1en variable compile warning reported by kernel build robot by creating new err_rps label Link: https://gitlab.freedesktop.org/drm/intel/-/issues/8062Signed-off-by:
-
Ashutosh Dixit authored
In preparation for follow-on patches, refactor hwm_power_max_write to take hwmon_lock and runtime pm wakeref at start of the function and release them at the end, therefore acquiring these just once each. Signed-off-by:
-
John Harrison authored
Dan Carpenter pointed out that 'err' was not being set in the case where the GuC firmware version range check fails. Fix that. Note that while this is a bug fix for a previous patch (see Fixes tag below). It is an exceedingly low risk bug. The range check is asserting that the GuC firmware version is within spec. So it should not be possible to ever have a firmware file that fails this check. If larger version numbers are required in the future, that would be a backwards breaking spec change and thus require a major version bump, in which case an old i915 driver would not load that new version anyway. Fixes: 9bbba066 ("drm/i915/guc: Use GuC submission API version number") Reported-by:
Dan Carpenter <error27@gmail.com> Signed-off-by:
-
- 25 Apr, 2023 4 commits
-
-
Tejas Upadhyay authored
WA 18018781329 is applicable now across all MTL steppings. V2: - Remove IS_MTL check, code already running for MTL - Matt Cc: Matt Roper <matthew.d.roper@intel.com> Signed-off-by:
-
Tejas Upadhyay authored
igt_live_test has pr_err dumped in case of some GT failures. It will be more informative regarding GT if we use gt_err instead. Cc: Andi Shyti <andi.shyti@intel.com> Signed-off-by:
-
Fei Yang authored
This patch implements Wa_22016122933. In MTL, memory writes initiated by the Media tile update the whole cache line, even for partial writes. This creates a coherency problem for cacheable memory if both CPU and GPU are writing data to different locations within a single cache line. This patch circumvents the issue by making CPU/GPU shared memory uncacheable (WC on CPU side, and PAT index 2 for GPU). Additionally, it ensures that CPU writes are visible to the GPU with an intel_guc_write_barrier(). While fixing the CTB issue, we noticed some random GSC firmware loading failure because the share buffers are cacheable (WB) on CPU side but uncached on GPU side. To fix these issues we need to map such shared buffers as WC on CPU side. Since such allocations are not all done through GuC allocator, to avoid too many code changes, the i915_coherent_map_type() is now hard coded to return WC for MTL. v2: Simplify the commit message(Matt). BSpec: 45101 Signed-off-by:
Fei Yang <fei.yang@intel.com> Reviewed-by:
Nirmoy Das <nirmoy.das@intel.com> Reviewed-by:
-
Fei Yang authored
PTE encode functions are platform dependent. This patch implements PTE functions for MTL, and ensures the correct PTE encode function is used by calling pte_encode function pointer instead of the hardcoded gen8 version of PTE encode. Fixes: b76c0dee ("drm/i915/mtl: Define MOCS and PAT tables for MTL") Signed-off-by:
-
- 23 Apr, 2023 4 commits
-
-
Andi Shyti authored
In the process of renaming all instances of 'dev_priv' to 'i915', start using 'i915' within the i915_drv.h file. Signed-off-by:
-
Andi Shyti authored
for_each_engine() loops through engines in the GT, not in dev_priv. Because it's misleading, call it "gt__" instead of "dev_priv__". Signed-off-by:
-
Fei Yang authored
Media GT has a different base for MOCS register, need to apply gsi_offset to the mmio address if not using the intel_uncore_r/w functions for register access. Cc: Matt Roper <matthew.d.roper@intel.com> Signed-off-by:
-
Madhumitha Tolakanahalli Pradeep authored
On MTL, GT can no longer allocate on LLC - only the CPU can. This, along with programming new register bits that MTL requires calls for a MOCS/PAT table update. Also the PAT index registers are multicasted for primary GT, and there is an address jump from index 7 to 8. This patch makes sure that these registers are programmed in the proper way. BSpec: 44509, 45101, 44235 Cc: Matt Roper <matthew.d.roper@intel.com> Cc: Lucas De Marchi <lucas.demarchi@intel.com> Signed-off-by:
Madhumitha Tolakanahalli Pradeep <madhumitha.tolakanahalli.pradeep@intel.com> Signed-off-by:
Aravind Iddamsetty <aravind.iddamsetty@intel.com> Signed-off-by:
-
- 21 Apr, 2023 1 commit
-
-
Fei Yang authored
On MTL, LLC is not shared between GT and CPU, set has_llc=0. Signed-off-by:
-
- 20 Apr, 2023 1 commit
-
-
Haridhar Kalvala authored
Workaround implementation to clear RDOP clock gating. Bspec: 66622 Signed-off-by:
Matt Atwood <matthew.s.atwood@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230418220446.2205509-5-radhakrishna.sripada@intel.com
-
- 19 Apr, 2023 4 commits
-
-
Madhumitha Tolakanahalli Pradeep authored
Wa_22011802037 was being applied to all graphics_ver 11 & 12. This patch updates the if statement to apply the W/A to right platforms and extends it to MTL-M:A step. v1.1: Fix checkpatch warning. v2: Change the check to reflect the wa at other places(Lucas) Bspec: 66622 Cc: Lucas De Marchi <lucas.demarchi@intel.com> Cc: Umesh Nerlige Ramappa <umesh.nerlige.ramappa@intel.com> Signed-off-by:
-
Tejas Upadhyay authored
In order to enable complete multi-GT, loop through all the GTs, rather than relying on the to_gt(), which only provides a reference to the primary GT. Problem appear when it runs on platform like MTL where different set of engines are possible on different GTs. Signed-off-by:
-
Tejas Upadhyay authored
In order to enable complete multi-GT, use the GT reference obtained directly from the engine, rather than relying on the to_gt(), which only provides a reference to the primary GT. Problem appear when it runs on platform like MTL where different set of engines are possible on different GTs. Signed-off-by:
-
Tejas Upadhyay authored
In order to enable complete multi-GT, use the GT reference obtained directly from the engine, rather than relying on the to_gt(), which only provides a reference to the primary GT. Problem appear when it runs on platform like MTL where different set of engines are possible on different GTs. Cc: Andi Shyti <andi.shyti@linux.intel.com> Signed-off-by:
-
- 18 Apr, 2023 1 commit
-
-
Andi Shyti authored
In multi-gt systems IRQs need to be reset and enabled per GT. This might add some redundancy when handling interrupts for engines that might not exist in every tile, but helps to keep the code cleaner and more understandable. Signed-off-by:
-
- 15 Apr, 2023 1 commit
-
-
Cong Liu authored
This patch fixes memory leaks on error escapes in function fake_get_pages Fixes: c3bfba9a ("drm/i915: Check for integer truncation on scatterlist creation") Signed-off-by:
Cong Liu <liucong2@kylinos.cn> Reviewed-by:
-
- 14 Apr, 2023 1 commit
-
-
Lucas De Marchi authored
When HuC is loaded by GSC, there is no header definition for the kernel to look at and firmware is just handed to GSC. However when reading the version, it should still check the size of the blob to guarantee it's not incurring into out-of-bounds array access. If firmware is smaller than expected, the following message is now printed: # echo boom > /lib/firmware/i915/dg2_huc_gsc.bin # dmesg | grep -i huc [drm] GT0: HuC firmware i915/dg2_huc_gsc.bin: invalid size: 5 < 184 [drm] *ERROR* GT0: HuC firmware i915/dg2_huc_gsc.bin: fetch failed -ENODATA ... Even without this change the size, header and signature are still checked by GSC when loading, so this only avoids the out-of-bounds array access. Fixes: a7b516bd ("drm/i915/huc: Add fetch support for gsc-loaded HuC binary") Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Alan Previn <alan.previn.teres.alexis@intel.com> Signed-off-by:
Lucas De Marchi <lucas.demarchi@intel.com> Reviewed-by:
Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230413200349.3492571-1-lucas.demarchi@intel.com
-
- 11 Apr, 2023 5 commits
-
-
Nirmoy Das authored
Stolen memory is not usable for MTL A0 stepping beyond certain access size and we have no control over userspace access size of /dev/fb which can be backed by stolen memory. So disable stolen memory backed fb by setting i915->dsm.usable_size to zero. v2: remove hsdes reference and fix commit message(Andi) v3: use revid as we want to target SOC stepping(Radhakrishna) Cc: Matthew Auld <matthew.auld@intel.com> Cc: Andi Shyti <andi.shyti@linux.intel.com> Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Lucas De Marchi <lucas.demarchi@intel.com> Cc: Radhakrishna Sripada <radhakrishna.sripada@intel.com> Signed-off-by:
-
Joonas Lahtinen authored
Need to pull in commit from drm-next (earlier in drm-intel-next): 1eca0778 ("drm/i915: add struct i915_dsm to wrap dsm members together") In order to merge following patch to drm-intel-gt-next: https://patchwork.freedesktop.org/patch/530942/?series=114925&rev=6Signed-off-by:
Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
-
Daniel Vetter authored
Merge tag 'mediatek-drm-next-6.4' of https://git.kernel.org/pub/scm/linux/kernel/git/chunkuang.hu/linux into drm-next Mediatek DRM Next for Linux 6.4 1. Add support for 10-bit overlays 2. Add MediaTek SoC DRM (vdosys1) support for mt8195 3. Change mmsys compatible for mt8195 mediatek-drm 4. Only trigger DRM HPD events if bridge is attached 5. Change the aux retries times when receiving AUX_DEFER Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch> From: Chun-Kuang Hu <chunkuang.hu@kernel.org> Link: https://patchwork.freedesktop.org/patch/msgid/20230410233005.2572-1-chunkuang.hu@kernel.org
-
https://gitlab.freedesktop.org/drm/msmDaniel Vetter authored
main pull request for v6.4 Core Display: ============ * Bugfixes for error handling during probe * rework UBWC decoder programming * prepare_commit cleanup * bindings for SM8550 (MDSS, DPU), SM8450 (DP) * timeout calculation fixup * atomic: use drm_crtc_next_vblank_start() instead of our own custom thing to calculate the start of next vblank DP: == * interrupts cleanup DPU: === * DSPP sub-block flush on sc7280 * support AR30 in addition to XR30 format * Allow using REC_0 and REC_1 to handle wide (4k) RGB planes * Split the HW catalog into individual per-SoC files DSI: === * rework DSI instance ID detection on obscure platforms GPU: === * uapi C++ compatibility fix * a6xx: More robust gdsc reset * a3xx and a4xx devfreq support * update generated headers * various cleanups and fixes * GPU and GEM updates to avoid allocations which could trigger reclaim (shrinker) in fence signaling path * dma-fence deadline hint support and wait-boost * a640 speedbin support * a650 speedbin support Conflicts in drivers/gpu/drm/msm/adreno/adreno_gpu.c: Conflict between the 7fa5047a ("drm: Use of_property_present() for testing DT property presence") and 9f251f93 ("drm/msm/adreno: Use OPP for every GPU generation"). The latter removed the of_ function call outright, so I went with what's in the PR unchanged. From: Rob Clark <robdclark@gmail.com> Link: https://patchwork.freedesktop.org/patch/msgid/CAF6AEGvwuj5tabyW910+N-B=5kFNAC7QNYoQ=0xi3roBjQvFFQ@mail.gmail.comSigned-off-by:
Daniel Vetter <daniel.vetter@intel.com>
-
Daniel Vetter authored
Merge tag 'drm-habanalabs-next-2023-04-10' of https://git.kernel.org/pub/scm/linux/kernel/git/ogabbay/linux into drm-next This tag contains additional habanalabs driver changes for v6.4: - uAPI changes: - Add a definition of a new Gaudi2 server type. This is used by userspace to know what is the connectivity between the accelerators inside the server - New features and improvements: - speedup h/w queues test in Gaudi2 to reduce device initialization times. - Firmware related fixes: - Fixes to the handshake protocol during f/w initialization. - Sync f/w events interrupt in hard reset to avoid warning message. - Improvements to extraction of the firmware version. - Misc bug fixes and code cleanups. Notable fixes are: - Multiple fixes for interrupt handling in Gaudi2. - Unmap mapped memory in case TLB invalidation fails. Signed-off-by:
-
- 08 Apr, 2023 5 commits
-
-
Tomer Tayar authored
hl_sysfs_fini() is called only if hl_sysfs_init() completes successfully. Therefore if hl_sysfs_init() fails, need to remove any sysfs group that was added until that point. Signed-off-by:
Tomer Tayar <ttayar@habana.ai> Reviewed-by:
Oded Gabbay <ogabbay@kernel.org> Signed-off-by:
-
Moti Haimovski authored
HW queues testing at driver load and after reset takes a substantial amount of time. This commit reduces the queues test time in Gaudi2 devices by running all the tests in parallel instead of one after the other. Time measurements on tests duration shows that the new method is almost x100 faster than the serial approach. Signed-off-by:
Moti Haimovski <mhaimovski@habana.ai> Reviewed-by:
-
Dani Liberman authored
There is only single eq entry for arc farm sei event which aggregates events from the four arc farms. Fix the code to handle this event according to this behavior. Signed-off-by:
Dani Liberman <dliberman@habana.ai> Reviewed-by:
-
Ofir Bitton authored
Multi MSI interrupts aren't working in Gaudi1 and because of that, we are only using a single MSI interrupt. Therefore, let's remove this dead code in order to avoid confusion. Signed-off-by:
Ofir Bitton <obitton@habana.ai> Reviewed-by:
-
Oded Gabbay authored
Add definition of a new Gaudi2 server type. This represents the connectivity between the cards in that server type. Signed-off-by:
Stanislaw Gruszka <stanislaw.gruszka@linux.intel.com>
-
