Re: [Intel-gfx] [GIT PULL] GVT next changes for drm-intel-next

Hi Joonas: Thanks so much. Will do. :) Thanks, Zhi. On 3/8/22 3:19 PM, Joonas Lahtinen wrote: > Quoting Wang, Zhi A (2022-03-08 12:07:04) >> Which suits better for you? For me, I am OK with both. If you are not in a >> rush of closing the window, I can submit through drm-intel-next-fixes. > >

[Intel-gfx] ✗ Fi.CI.IGT: failure for series starting with [1/2] Revert "drm/i915/edp: Ignore short pulse when panel powered off"

== Series Details == Series: series starting with [1/2] Revert "drm/i915/edp: Ignore short pulse when panel powered off" URL : https://patchwork.freedesktop.org/series/101162/ State : failure == Summary == CI Bug Log - changes from CI_DRM_11337_full -> Patchwork_22513_full ===

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/vlv_dsi_pll: use min_t() to make code cleaner

== Series Details == Series: drm/i915/vlv_dsi_pll: use min_t() to make code cleaner URL : https://patchwork.freedesktop.org/series/101151/ State : success == Summary == CI Bug Log - changes from CI_DRM_11337_full -> Patchwork_22511_full Sum

[Intel-gfx] ✗ Fi.CI.BAT: failure for Patches for selftest_lrc

== Series Details == Series: Patches for selftest_lrc URL : https://patchwork.freedesktop.org/series/101188/ State : failure == Summary == CI Bug Log - changes from CI_DRM_11338 -> Patchwork_22520 Summary --- **FAILURE** Serious u

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/guc: Refactor CT access to use iosys_map

== Series Details == Series: drm/i915/guc: Refactor CT access to use iosys_map URL : https://patchwork.freedesktop.org/series/101148/ State : success == Summary == CI Bug Log - changes from CI_DRM_11337_full -> Patchwork_22509_full Summary

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for Patches for selftest_lrc

== Series Details == Series: Patches for selftest_lrc URL : https://patchwork.freedesktop.org/series/101188/ State : warning == Summary == $ dim sparse --fast origin/drm-tip Sparse version: v0.6.2 Fast mode used, each commit won't be checked separately. - +drivers/gpu/drm/i915/gt/intel_engine_

[Intel-gfx] [PATCH 8/8] drm/i915/xehpsdv/dg1/tgl: Fix issue with LRI relative addressing

From: Akeem G Abodunrin When bit 19 of MI_LOAD_REGISTER_IMM instruction opcode is set on devices of tgl+, HW does not care about certain register address offsets, but instead check the following for valid address ranges on specific engines: RCS && CCS: BITS(0 - 10) BCS: BITS(0 - 1

[Intel-gfx] [PATCH 6/8] drm/i915/selftest: Clear the output buffers before GPU writes

From: Chris Wilson When testing whether we can get the GPU to leak information about non-privileged state, we first need to ensure that the output buffer is set to a known value as the HW may opt to skip the write into memory for a non-privileged read of a sensitive register. We chose POISON_INUS

[Intel-gfx] [PATCH 7/8] drm/i915/selftest: Always cancel semaphore on error

From: Chris Wilson Ensure that we always signal the semaphore when timing out, so that if it happens to be stuck waiting for the semaphore we will quickly recover without having to wait for a reset. Reported-by: CQ Tang Signed-off-by: Chris Wilson cc: Joonas Lahtinen Signed-off-by: Ramalingam

[Intel-gfx] [PATCH 5/8] drm/i915/selftests: Check for incomplete LRI from the context image

From: Chris Wilson In order to keep the context image parser simple, we assume that all commands follow a similar format. A few, especially not MI commands on the render engines, have fixed lengths not encoded in a length field. This caused us to incorrectly skip over 3D state commands, and start

[Intel-gfx] [PATCH 4/8] drm/i915/gt: Explicitly clear BB_OFFSET for new contexts

From: Chris Wilson Even though the initial protocontext we load onto HW has the register cleared, by the time we save it into the default image, BB_OFFSET has had the enable bit set. Reclear BB_OFFSET for each new context. Testcase: igt/i915_selftests/gt_lrc Signed-off-by: Chris Wilson Cc: Mik

[Intel-gfx] [PATCH 3/8] drm/i915/selftests: Flush the submission for lrc_isolation

From: Chris Wilson The lrc_isolation test uses two contexts in order to read from one context while poisoning from a second. The test verifies that the writes of the second context do not leak into the first context. This is done by first recording the register state from context A, forcing a pre

[Intel-gfx] [PATCH 2/8] drm/i915/selftests: Exercise cross-process context isolation

From: Chris Wilson Verify that one context running on engine A cannot manipulate another client's context concurrently running on engine B using unprivileged access. Signed-off-by: Chris Wilson Signed-off-by: Ramalingam C --- drivers/gpu/drm/i915/gt/selftest_lrc.c | 275 +-

[Intel-gfx] [PATCH 1/8] drm/i915/selftests: Exercise relative mmio paths to non-privileged registers

From: Chris Wilson Verify that context isolation is also preserved when accessing context-local registers with relative-mmio commands. Signed-off-by: Chris Wilson Signed-off-by: Ramalingam C --- drivers/gpu/drm/i915/gt/selftest_lrc.c | 88 -- 1 file changed, 67 inserti

[Intel-gfx] [PATCH 0/8] Patches for selftest_lrc

Patches that fix and enhance the selftest_lrc Akeem G Abodunrin (1): drm/i915/xehpsdv/dg1/tgl: Fix issue with LRI relative addressing Chris Wilson (7): drm/i915/selftests: Exercise relative mmio paths to non-privileged registers drm/i915/selftests: Exercise cross-process context isolati

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: Clean up some dpll stuff (rev4)

== Series Details == Series: drm/i915: Clean up some dpll stuff (rev4) URL : https://patchwork.freedesktop.org/series/100899/ State : failure == Summary == CI Bug Log - changes from CI_DRM_11338 -> Patchwork_22519 Summary --- **FAILU

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915: Clean up some dpll stuff (rev4)

== Series Details == Series: drm/i915: Clean up some dpll stuff (rev4) URL : https://patchwork.freedesktop.org/series/100899/ State : warning == Summary == $ dim sparse --fast origin/drm-tip Sparse version: v0.6.2 Fast mode used, each commit won't be checked separately.

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: SAGV block time fixes

== Series Details == Series: drm/i915: SAGV block time fixes URL : https://patchwork.freedesktop.org/series/101171/ State : success == Summary == CI Bug Log - changes from CI_DRM_11338 -> Patchwork_22517 Summary --- **SUCCESS** No

[Intel-gfx] ✗ Fi.CI.BUILD: failure for ALSA: hda/i915 - avoid hung task timeout in i915 wait (rev2)

== Series Details == Series: ALSA: hda/i915 - avoid hung task timeout in i915 wait (rev2) URL : https://patchwork.freedesktop.org/series/101156/ State : failure == Summary == Applying: ALSA: hda/i915 - avoid hung task timeout in i915 wait Using index info to reconstruct a base tree... M

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: check before removing mm notifier

== Series Details == Series: drm/i915: check before removing mm notifier URL : https://patchwork.freedesktop.org/series/101170/ State : success == Summary == CI Bug Log - changes from CI_DRM_11338 -> Patchwork_22516 Summary --- **SUC

Re: [Intel-gfx] [v2] drm/i915/gem: missing boundary check in vm_access leads to OOB read/write

On 03/03/2022 09:00, Tvrtko Ursulin wrote: > > + Matt > > On 03/03/2022 06:04, Mastan Katragadda wrote: >> Intel ID: PSIRT-PTK0002429 >> >> A missing bounds check in vm_access()can lead to an out-of-bounds >> read or write in the adjacent memory area.The len attribute is not >> validated before

Re: [Intel-gfx] [PATCH 2/2] drm/i915/guc: Convert ct buffer to iosys_map

On Tue, Mar 08, 2022 at 03:08:05PM +0530, Mullati Siva wrote: From: Siva Mullati Convert CT commands and descriptors to use iosys_map rather than plain pointer and save it in the intel_guc_ct_buffer struct. This will help with ct_write and ct_read for cmd send and receive after the initializati

Re: [Intel-gfx] [PATCH 1/2] iosys-map: Add a helper for pointer difference

On Tue, Mar 08, 2022 at 03:08:04PM +0530, Mullati Siva wrote: From: Siva Mullati iosys_map_ptrdiff to get the difference in address of same memory type. Signed-off-by: Siva Mullati --- include/linux/iosys-map.h | 21 + 1 file changed, 21 insertions(+) diff --git a/include/

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/guc: Use iosys_map interface to update lrc_desc

== Series Details == Series: drm/i915/guc: Use iosys_map interface to update lrc_desc URL : https://patchwork.freedesktop.org/series/101166/ State : success == Summary == CI Bug Log - changes from CI_DRM_11337 -> Patchwork_22515 Summary ---

[Intel-gfx] ✗ Fi.CI.BAT: failure for Add driver for GSC controller (rev10)

== Series Details == Series: Add driver for GSC controller (rev10) URL : https://patchwork.freedesktop.org/series/98066/ State : failure == Summary == CI Bug Log - changes from CI_DRM_11337 -> Patchwork_22514 Summary --- **FAILURE**

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915/guc: Use iosys_map interface to update lrc_desc

== Series Details == Series: drm/i915/guc: Use iosys_map interface to update lrc_desc URL : https://patchwork.freedesktop.org/series/101166/ State : warning == Summary == $ dim sparse --fast origin/drm-tip Sparse version: v0.6.2 Fast mode used, each commit won't be checked separately.

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for Add driver for GSC controller (rev10)

== Series Details == Series: Add driver for GSC controller (rev10) URL : https://patchwork.freedesktop.org/series/98066/ State : warning == Summary == $ dim sparse --fast origin/drm-tip Sparse version: v0.6.2 Fast mode used, each commit won't be checked separately.

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for Add driver for GSC controller (rev10)

== Series Details == Series: Add driver for GSC controller (rev10) URL : https://patchwork.freedesktop.org/series/98066/ State : warning == Summary == $ dim checkpatch origin/drm-tip 44fdb8f68777 drm/i915/gsc: add gsc as a mei auxiliary device -:63: WARNING:FILE_PATH_CHANGES: added, moved or d

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/2] Revert "drm/i915/edp: Ignore short pulse when panel powered off"

== Series Details == Series: series starting with [1/2] Revert "drm/i915/edp: Ignore short pulse when panel powered off" URL : https://patchwork.freedesktop.org/series/101162/ State : success == Summary == CI Bug Log - changes from CI_DRM_11337 -> Patchwork_22513 =

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/vlv_dsi_pll: use min_t() to make code cleaner

== Series Details == Series: drm/i915/vlv_dsi_pll: use min_t() to make code cleaner URL : https://patchwork.freedesktop.org/series/101151/ State : success == Summary == CI Bug Log - changes from CI_DRM_11337 -> Patchwork_22511 Summary -

[Intel-gfx] ✗ Fi.CI.BUILD: failure for drm/i915/dpll: make read-only array div1_vals static const

== Series Details == Series: drm/i915/dpll: make read-only array div1_vals static const URL : https://patchwork.freedesktop.org/series/101152/ State : failure == Summary == Applying: drm/i915/dpll: make read-only array div1_vals static const Using index info to reconstruct a base tree... M

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/guc: Refactor CT access to use iosys_map

== Series Details == Series: drm/i915/guc: Refactor CT access to use iosys_map URL : https://patchwork.freedesktop.org/series/101148/ State : success == Summary == CI Bug Log - changes from CI_DRM_11337 -> Patchwork_22509 Summary ---

[Intel-gfx] ✗ Fi.CI.BUILD: failure for Improve anti-pre-emption w/a for compute workloads (rev6)

== Series Details == Series: Improve anti-pre-emption w/a for compute workloads (rev6) URL : https://patchwork.freedesktop.org/series/100428/ State : failure == Summary == Applying: drm/i915/guc: Limit scheduling properties to avoid overflow error: patch failed: drivers/gpu/drm/i915/gt/uc/inte

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915/guc: Refactor CT access to use iosys_map

== Series Details == Series: drm/i915/guc: Refactor CT access to use iosys_map URL : https://patchwork.freedesktop.org/series/101148/ State : warning == Summary == $ dim sparse --fast origin/drm-tip Sparse version: v0.6.2 Fast mode used, each commit won't be checked separately.

Re: [Intel-gfx] [PATCH v2 1/1] drm/i915/reset: Fix error_state_read ptr + offset use

On 3/1/2022 1:37 PM, John Harrison wrote: On 2/25/2022 22:27, Alan Previn wrote: ... This fixes a kernel page fault can happen when multiple tests are running concurrently in a loop and one is producing engine resets and consuming the i915 error_state dump while the other is forcing full GT re

Re: [Intel-gfx] [PATCH 5/6] drm/rcar_du: changes to rcar-du driver resulting from drm_writeback_connector structure changes

Hi Suraj On 3/8/2022 6:30 AM, Kandpal, Suraj wrote: Hi Abhinav, Hi, Hi, Hi Abhinav, Hi Laurent Ok sure, I can take this up but I need to understand the proposal a little bit more before proceeding on this. So we will discuss this in another email where we specifically talk about the connec

Re: [Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/xehp: Drop aux table invalidation on FlatCCS platforms

On Tue, Mar 01, 2022 at 02:01:44PM +, Patchwork wrote: > == Series Details == > > Series: drm/i915/xehp: Drop aux table invalidation on FlatCCS platforms > URL : https://patchwork.freedesktop.org/series/100867/ > State : success > > == Summary == > > CI Bug Log - changes from CI_DRM_11300_

Re: [Intel-gfx] [PATCH] drm/i915/xehp: Drop aux table invalidation on FlatCCS platforms

On Mon, Feb 28, 2022 at 09:29:52PM -0800, Matt Roper wrote: Platforms with FlatCCS do not use auxiliary planes for compression control data and thus do not need traditional aux table invalidation (and the registers no longer even exist). Original-author: CQ Tang Signed-off-by: Matt Roper --- dr

Re: [Intel-gfx] [PATCH v3 2/3] drm/i915/gem: Remove logic for wbinvd_on_all_cpus

On Tue, Feb 22, 2022 at 08:24:31PM +0100, Thomas Hellström (Intel) wrote: Hi, Michael, On 2/22/22 18:26, Michael Cheng wrote: This patch removes logic for wbinvd_on_all_cpus and brings in drm_cache.h. This header has the logic that outputs a warning when wbinvd_on_all_cpus when its being used o

[Intel-gfx] [PATCH v2] ALSA: hda/i915 - avoid hung task timeout in i915 wait

If kernel is built with hung task detection enabled and CONFIG_DEFAULT_HUNG_TASK_TIMEOUT set to less than 60 seconds, snd_hdac_i915_init() will trigger the hung task timeout in case i915 is not available and taint the kernel. Split the 60sec wait into a loop of smaller waits to avoid this. Review

[Intel-gfx] [PATCH 1/6] drm/i915: Remove leftover cnl SAGV block time

From: Ville Syrjälä GLK doesn't support SAGV, so with CNL gone there is no use for having a DISPLAY_VER==10 SAGV block time in the code. Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/i915/intel_pm.c | 3 --- 1 file changed, 3 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_pm.c b/driv

[Intel-gfx] [PATCH 2/6] drm/i915: Rework SAGV block time probing

From: Ville Syrjälä I'd like to see the SAGV block time we got from the mailbox in the logs regardless of whether other factors prevent the use of SAGV. So let's adjust the code to always query the SAGV block time, log it, and then reset it if SAGV is not actually supported. Signed-off-by: Vill

[Intel-gfx] [PATCH 6/6] drm/i915: Rename pre-icl SAGV enable/disable functions

From: Ville Syrjälä Give the pre-icl SAGV control functions a skl_ prefix instead of the intel_ prefix to make it a bit more clear that they are not some kind of universal things that can be called on any platform. Also make the functions void since we never use the return value anyway. Signed-o

[Intel-gfx] [PATCH 3/6] drm/i915: Treat SAGV block time 0 as SAGV disabled

From: Ville Syrjälä For modern platforms the spec explicitly states that a SAGV block time of zero means that SAGV is not supported. Let's extend that to all platforms. Supposedly there should be no systems where this isn't true, and it'll allow us to: - use the same code regardless of older vs.

[Intel-gfx] [PATCH 4/6] drm/i915: Probe whether SAGV works on pre-icl

From: Ville Syrjälä Instead of leaving the SAGV enable/disable to the first commit let's try to disable it first thing to see if we can do it or not (disabling SAGV is a safe thing to at any time). This avoids running the code in this funny intermediate state where we don't know if SAGV is availa

[Intel-gfx] [PATCH 0/6] drm/i915: SAGV block time fixes

From: Ville Syrjälä Try to fix SAGV block time handling: - zero means no SAGV - avoid integer overflows - slightly better debug logs - assorted cleanups Ville Syrjälä (6): drm/i915: Remove leftover cnl SAGV block time drm/i915: Rework SAGV block time probing drm/i915: Treat SAGV block time

[Intel-gfx] [PATCH 5/6] drm/i915: Reject excessive SAGV block time

From: Ville Syrjälä If the mailbox returns an exceesively large SAGV block time let's just reject it. This avoids having to worry about overflows when we add the SAGV block time to the wm0 latency. We shall put the limit arbitrarily at U16_MAX. >65msec latency doesn't really make sense to me in

[Intel-gfx] [PATCH] drm/i915: check before removing mm notifier

mmu_notifier_register() can get interrupted which will leave a NULL notifier.mm pointer. Catch that and return early. Signed-off-by: Das, Nirmoy --- drivers/gpu/drm/i915/gem/i915_gem_userptr.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/gpu/drm/i915/gem/i915_gem_userptr.c b/d

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/gtt: reduce overzealous alignment constraints for GGTT (rev3)

== Series Details == Series: drm/i915/gtt: reduce overzealous alignment constraints for GGTT (rev3) URL : https://patchwork.freedesktop.org/series/100991/ State : success == Summary == CI Bug Log - changes from CI_DRM_11332_full -> Patchwork_22497_full =

Re: [Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915: opportunistically apply ALLOC_CONTIGIOUS (rev2)

Filed a new issue and re-reported. https://gitlab.freedesktop.org/drm/intel/-/issues/5267 igt@kms_plane@plane-position-hole@pipe-b-planes - incomplete - No warnings/errors Thanks, Lakshmi. -Original Message- From: Auld, Matthew Sent: Tuesday, March 8, 2022 4:26 AM To: intel-gfx@lists

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: opportunistically apply ALLOC_CONTIGIOUS (rev2)

== Series Details == Series: drm/i915: opportunistically apply ALLOC_CONTIGIOUS (rev2) URL : https://patchwork.freedesktop.org/series/99631/ State : success == Summary == CI Bug Log - changes from CI_DRM_11332_full -> Patchwork_22498_full S

Re: [Intel-gfx] [PATCH] drm: remove min_order BUG_ON check

On 08/03/2022 13:59, Arunpravin wrote: On 07/03/22 10:11 pm, Matthew Auld wrote: On 07/03/2022 14:37, Arunpravin wrote: place BUG_ON(order < min_order) outside do..while loop as it fails Unigine Heaven benchmark. Unigine Heaven has buffer allocation requests for example required pages are 16

[Intel-gfx] [PATCH] drm/i915/guc: Use iosys_map interface to update lrc_desc

This patch is continuation of the effort to move all pointers in i915, which at any point may be pointing to device memory or system memory, to iosys_map interface. More details about the need of this change is explained in the patch series which initiated this task https://patchwork.freedesktop.or

[Intel-gfx] [PATCH v10 3/5] mei: gsc: setup char driver alive in spite of firmware handshake failure

Setup char device in spite of firmware handshake failure. In order to provide host access to the firmware status registers and other information required for the manufacturing process. Signed-off-by: Alexander Usyskin Signed-off-by: Tomas Winkler --- drivers/misc/mei/gsc-me.c | 11 ++-

[Intel-gfx] [PATCH v10 4/5] mei: gsc: add runtime pm handlers

From: Tomas Winkler Implement runtime handlers for mei-gsc, to track idle state of the device properly. CC: Rodrigo Vivi Signed-off-by: Tomas Winkler Signed-off-by: Alexander Usyskin --- drivers/misc/mei/gsc-me.c | 67 ++- 1 file changed, 66 insertions(+),

[Intel-gfx] [PATCH v10 5/5] mei: gsc: retrieve the firmware version

Add a hook to retrieve the firmware version of the GSC devices to bus-fixup. GSC has a different MKHI clients GUIDs but the same message structure to retrieve the firmware version as MEI so mei_fwver() can be reused. CC: Ashutosh Dixit Signed-off-by: Alexander Usyskin Signed-off-by: Tomas Winkle

[Intel-gfx] [PATCH v10 2/5] mei: add support for graphics system controller (gsc) devices

From: Tomas Winkler GSC is a graphics system controller, based on CSE, it provides a chassis controller for graphics discrete cards, as well as it supports media protection on selected devices. mei_gsc binds to a auxiliary devices exposed by Intel discrete driver i915. Signed-off-by: Alexander

[Intel-gfx] [PATCH v10 1/5] drm/i915/gsc: add gsc as a mei auxiliary device

From: Tomas Winkler GSC is a graphics system controller, it provides a chassis controller for graphics discrete cards. There are two MEI interfaces in GSC: HECI1 and HECI2. Both interfaces are on the BAR0 at offsets 0x00258000 and 0x00259000. GSC is a GT Engine (class 4: instance 6). HECI1 inte

[Intel-gfx] [PATCH v10 0/5] Add driver for GSC controller

GSC is a graphics system controller, it provides a chassis controller for graphics discrete cards. There are two MEI interfaces in GSC: HECI1 and HECI2. This series includes instantiation of the auxiliary devices for HECI2 and mei-gsc auxiliary device driver that binds to the auxiliary device. T

Re: [Intel-gfx] [PATCH] ALSA: hda/i915 - avoid hung task timeout in i915 wait

On Tue, 08 Mar 2022 17:29:21 +0100, Amadeusz SX2awiX4ski wrote: > > On 3/8/2022 3:11 PM, Kai Vehmanen wrote: > > If kernel is built with hung task detection enabled and > > CONFIG_DEFAULT_HUNG_TASK_TIMEOUT set to less than 60 seconds, > > snd_hdac_i915_init() will trigger the hung task timeout in

Re: [Intel-gfx] [PATCH] ALSA: hda/i915 - avoid hung task timeout in i915 wait

On 3/8/2022 3:11 PM, Kai Vehmanen wrote: If kernel is built with hung task detection enabled and CONFIG_DEFAULT_HUNG_TASK_TIMEOUT set to less than 60 seconds, snd_hdac_i915_init() will trigger the hung task timeout in case i915 is not available and taint the kernel. Split the 60sec wait into a l

Re: [Intel-gfx] [PATCH] ALSA: hda/i915 - avoid hung task timeout in i915 wait

On Tue, Mar 08, 2022 at 04:11:12PM +0200, Kai Vehmanen wrote: If kernel is built with hung task detection enabled and CONFIG_DEFAULT_HUNG_TASK_TIMEOUT set to less than 60 seconds, snd_hdac_i915_init() will trigger the hung task timeout in case i915 is not available and taint the kernel. Split th

[Intel-gfx] [PATCH 2/2] drm/i915/display: Do not re-enable PSR after it was marked as not reliable

If a error happens and sink_not_reliable is set, PSR should be disabled for good but that is not happening. It would be disabled by the function handling the PSR error but then on the next fastset it would be enabled again in _intel_psr_post_plane_update(). It would only be disabled for good in the

[Intel-gfx] [PATCH 1/2] Revert "drm/i915/edp: Ignore short pulse when panel powered off"

This reverts commit 13ea6db2cf24a797ac8c9922e3079fcb897fd32c. This patch complete broke eDP short pulse handling as VDD is only enabled when doing aux transactions or when port is disabled. Checked on several older kernel versions and that is the behavior that i915 always had on VDD. So all legit

Re: [Intel-gfx] [GIT PULL] GVT next changes for drm-intel-next

Quoting Wang, Zhi A (2022-03-08 12:07:04) > Which suits better for you? For me, I am OK with both. If you are not in a > rush of closing the window, I can submit through drm-intel-next-fixes. I pulled this into drm-intel-next-fixes now. For future reference, let's have fixes only PRs as gvt-fixe

Re: [Intel-gfx] [PATCH 5/6] drm/rcar_du: changes to rcar-du driver resulting from drm_writeback_connector structure changes

Hi Abhinav, > > Hi, > >>> Hi, > > Hi Abhinav, > >> Hi Laurent > >> > >> Ok sure, I can take this up but I need to understand the proposal > >> a little bit more before proceeding on this. So we will discuss > >> this in another email where we specifically talk about the > >>

Re: [Intel-gfx] [PATCH] drm: remove min_order BUG_ON check

On 07/03/22 8:15 pm, Jani Nikula wrote: > On Mon, 07 Mar 2022, Arunpravin wrote: >> place BUG_ON(order < min_order) outside do..while >> loop as it fails Unigine Heaven benchmark. >> >> Unigine Heaven has buffer allocation requests for >> example required pages are 161 and alignment request >>

[Intel-gfx] [PATCH] ALSA: hda/i915 - avoid hung task timeout in i915 wait

If kernel is built with hung task detection enabled and CONFIG_DEFAULT_HUNG_TASK_TIMEOUT set to less than 60 seconds, snd_hdac_i915_init() will trigger the hung task timeout in case i915 is not available and taint the kernel. Split the 60sec wait into a loop of smaller waits to avoid this. Cc: Lu

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: Clean up some dpll stuff (rev3)

== Series Details == Series: drm/i915: Clean up some dpll stuff (rev3) URL : https://patchwork.freedesktop.org/series/100899/ State : failure == Summary == CI Bug Log - changes from CI_DRM_11334 -> Patchwork_22508 Summary --- **FAILU

[Intel-gfx] ✓ Fi.CI.BAT: success for Revert "drm/i915/edp: Ignore short pulse when panel powered off"

== Series Details == Series: Revert "drm/i915/edp: Ignore short pulse when panel powered off" URL : https://patchwork.freedesktop.org/series/101129/ State : success == Summary == CI Bug Log - changes from CI_DRM_11334 -> Patchwork_22507 Sum

Re: [Intel-gfx] [PATCH] drm/i915/gtt: reduce overzealous alignment constraints for GGTT

|Acked-by: Nirmoy Das | On 03/03/2022 11:02, Matthew Auld wrote: Currently this will enforce both 2M alignment and padding for any LMEM pages inserted into the GGTT. However, this was only meant to be applied to the compact-pt layout with the ppGTT. For the GGTT we can reduce the alignment and p

Re: [Intel-gfx] [PATCH] drm/doc: pull in drm_buddy.c

On 09/02/2022 07:32, Christian König wrote: Am 08.02.22 um 16:12 schrieb Matthew Auld: Make sure we pull in the kernel-doc for this. Reported-by: Daniel Vetter Signed-off-by: Matthew Auld Cc: Arunpravin Cc: Christian König Reviewed-by: Christian König Thanks. Could you also push this?

Re: [Intel-gfx] [PATCH RFC 0/3] MAP_POPULATE for device memory

On Sun, Mar 06, 2022 at 11:48:26PM -0800, Christoph Hellwig wrote: > On Sun, Mar 06, 2022 at 11:33:02AM +, Matthew Wilcox wrote: > > On Sun, Mar 06, 2022 at 07:32:04AM +0200, Jarkko Sakkinen wrote: > > > For device memory (aka VM_IO | VM_PFNMAP) MAP_POPULATE does nothing. Allow > > > to use tha

Re: [Intel-gfx] [PATCH RFC 0/3] MAP_POPULATE for device memory

On Mon, Mar 07, 2022 at 03:33:52PM +0100, David Hildenbrand wrote: > On 07.03.22 15:22, Jarkko Sakkinen wrote: > > On Mon, Mar 07, 2022 at 11:12:44AM +0100, David Hildenbrand wrote: > >> On 06.03.22 06:32, Jarkko Sakkinen wrote: > >>> For device memory (aka VM_IO | VM_PFNMAP) MAP_POPULATE does noth

Re: [Intel-gfx] [PATCH RFC v2] mm: Add f_ops->populate()

On Mon, Mar 07, 2022 at 02:37:48PM +, Matthew Wilcox wrote: > On Sun, Mar 06, 2022 at 03:41:54PM -0800, Dave Hansen wrote: > > In short: page faults stink. The core kernel has lots of ways of > > avoiding page faults like madvise(MADV_WILLNEED) or mmap(MAP_POPULATE). > > But, those only work

Re: [Intel-gfx] [PATCH RFC 0/3] MAP_POPULATE for device memory

On Mon, Mar 07, 2022 at 07:56:53AM -0800, Christoph Hellwig wrote: > On Mon, Mar 07, 2022 at 03:29:35PM +0200, Jarkko Sakkinen wrote: > > So what would you suggest to sort out the issue? I'm happy to go with > > ioctl if nothing else is acceptable. > > PLenty of drivers treat all mmaps as if MAP_P

[Intel-gfx] [PATCH] drm/i915/dpll: make read-only array div1_vals static const

Don't populate the read-only array div1_vals on the stack but instead make it static const. Also makes the object code a little smaller. Signed-off-by: Colin Ian King --- drivers/gpu/drm/i915/display/intel_dpll_mgr.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu

Re: [Intel-gfx] [PATCH RFC 0/3] MAP_POPULATE for device memory

On Mon, Mar 07, 2022 at 10:11:19PM +, David Laight wrote: > From: Christoph Hellwig > > Sent: 07 March 2022 15:57 > > > > On Mon, Mar 07, 2022 at 03:29:35PM +0200, Jarkko Sakkinen wrote: > > > So what would you suggest to sort out the issue? I'm happy to go with > > > ioctl if nothing else is

Re: [Intel-gfx] [PATCH RFC 1/3] mm: Add f_ops->populate()

On Sun, Mar 06, 2022 at 10:43:31PM +, Matthew Wilcox wrote: > On Sun, Mar 06, 2022 at 07:02:57PM +0200, Jarkko Sakkinen wrote: > > So can I conclude from this that in general having populate available for > > device memory is something horrid, or just the implementation path? > > You haven't e

Re: [Intel-gfx] [PATCH RFC 1/3] mm: Add f_ops->populate()

On Mon, Mar 07, 2022 at 03:16:57PM +0200, Jarkko Sakkinen wrote: > On Sun, Mar 06, 2022 at 10:43:31PM +, Matthew Wilcox wrote: > > On Sun, Mar 06, 2022 at 07:02:57PM +0200, Jarkko Sakkinen wrote: > > > So can I conclude from this that in general having populate available for > > > device memory

Re: [Intel-gfx] [PATCH RFC v2] mm: Add f_ops->populate()

On Mon, Mar 07, 2022 at 07:29:22AM -0800, Dave Hansen wrote: > On 3/7/22 03:27, Jarkko Sakkinen wrote: > > But e.g. in __mm_populate() anything with (VM_IO | VM_PFNMAP) gets > > filtered out and never reach that function. > > > > I don't know unorthodox that'd be but could we perhaps have a VM > >

Re: [Intel-gfx] [PATCH RFC v2] mm: Add f_ops->populate()

On Sun, Mar 06, 2022 at 03:24:56PM -0800, Andrew Morton wrote: > On Sun, 6 Mar 2022 05:26:55 +0200 Jarkko Sakkinen wrote: > > > Sometimes you might want to use MAP_POPULATE to ask a device driver to > > initialize the device memory in some specific manner. SGX driver can use > > this to request

Re: [Intel-gfx] [PATCH RFC v2] mm: Add f_ops->populate()

On Sun, Mar 06, 2022 at 03:41:54PM -0800, Dave Hansen wrote: > On 3/6/22 15:24, Andrew Morton wrote: > > On Sun, 6 Mar 2022 05:26:55 +0200 Jarkko Sakkinen > > wrote: > > > >> Sometimes you might want to use MAP_POPULATE to ask a device driver to > >> initialize the device memory in some specifi

[Intel-gfx] [PATCH] drm/i915/vlv_dsi_pll: use min_t() to make code cleaner

From: Changcheng Deng Use min_t() in order to make code cleaner. Reported-by: Zeal Robot Signed-off-by: Changcheng Deng --- drivers/gpu/drm/i915/display/vlv_dsi_pll.c | 5 + 1 file changed, 1 insertion(+), 4 deletions(-) diff --git a/drivers/gpu/drm/i915/display/vlv_dsi_pll.c b/drivers/

Re: [Intel-gfx] [PATCH RFC 0/3] MAP_POPULATE for device memory

On Mon, Mar 07, 2022 at 11:12:44AM +0100, David Hildenbrand wrote: > On 06.03.22 06:32, Jarkko Sakkinen wrote: > > For device memory (aka VM_IO | VM_PFNMAP) MAP_POPULATE does nothing. Allow > > to use that for initializing the device memory by providing a new callback > > f_ops->populate() for the

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/mm: Add an iterator to optimally walk over holes suitable for an allocation

== Series Details == Series: drm/mm: Add an iterator to optimally walk over holes suitable for an allocation URL : https://patchwork.freedesktop.org/series/101123/ State : success == Summary == CI Bug Log - changes from CI_DRM_11334 -> Patchwork_22506 =

Re: [Intel-gfx] [PATCH] drm/i915: opportunistically apply ALLOC_CONTIGIOUS

LGTM  Reviewed-by: Nirmoy Das On 02/02/2022 18:31, Matthew Auld wrote: It looks like this code was accidentally dropped at some point(in a slightly different form), so add it back. The gist is that if we know the allocation will be one single chunk, then we can just annotate the BO with I915_BO

Re: [Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/gtt: reduce overzealous alignment constraints for GGTT (rev3)

On 07/03/2022 16:56, Patchwork wrote: *Patch Details* *Series:* drm/i915/gtt: reduce overzealous alignment constraints for GGTT (rev3) *URL:* https://patchwork.freedesktop.org/series/100991/ *State:*failure *Details:* https://intel-gf

Re: [Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915: opportunistically apply ALLOC_CONTIGIOUS (rev2)

On 07/03/2022 17:52, Patchwork wrote: *Patch Details* *Series:* drm/i915: opportunistically apply ALLOC_CONTIGIOUS (rev2) *URL:* https://patchwork.freedesktop.org/series/99631/ *State:*failure *Details:* https://intel-gfx-ci.01.or

Re: [Intel-gfx] [PATCH] drm/i915/mst: re-enable link training failure fallback for DP MST

On Mon, 07 Mar 2022, Ville Syrjälä wrote: > On Mon, Mar 07, 2022 at 09:36:57PM +0200, Jani Nikula wrote: >> Commit 80a8cecf62a5 ("drm/i915/dp_mst: Disable link training fallback on >> MST links") disabled link training failure fallback for DP MST due to >> the MST manager using the DPCD directly,

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/doc/rfc: i915 VM_BIND feature design + uapi (rev2)

== Series Details == Series: drm/doc/rfc: i915 VM_BIND feature design + uapi (rev2) URL : https://patchwork.freedesktop.org/series/93447/ State : success == Summary == CI Bug Log - changes from CI_DRM_11334 -> Patchwork_22505 Summary --

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/mst: re-enable link training failure fallback for DP MST

== Series Details == Series: drm/i915/mst: re-enable link training failure fallback for DP MST URL : https://patchwork.freedesktop.org/series/101119/ State : success == Summary == CI Bug Log - changes from CI_DRM_11334 -> Patchwork_22504 Su

[Intel-gfx] ✗ Fi.CI.BAT: failure for Add CDCLK checks to atomic check phase (rev2)

== Series Details == Series: Add CDCLK checks to atomic check phase (rev2) URL : https://patchwork.freedesktop.org/series/101068/ State : failure == Summary == CI Bug Log - changes from CI_DRM_11334 -> Patchwork_22503 Summary --- **F

Re: [Intel-gfx] [PATCH v2 1/8] drm/i915/guc: Do not conflate lrc_desc with GuC id for registration

On Fri, 04 Mar 2022, John Harrison wrote: > On 3/4/2022 03:59, Jani Nikula wrote: >> On Thu, 24 Feb 2022, john.c.harri...@intel.com wrote: >> There are a plethora of static inlines in the guc .c files, and this >> adds more. How about just letting the compiler decide what's the best >> course of a

Re: [Intel-gfx] [PATCH] drm/i915/dg2: Add preemption changes for Wa_14015141709

On Fri, 04 Mar 2022, Matt Roper wrote: > On Fri, Mar 04, 2022 at 12:13:12PM +0200, Jani Nikula wrote: >> On Thu, 03 Mar 2022, Matt Roper wrote: >> > From: Akeem G Abodunrin >> > >> > Starting with DG2, preemption can no longer be controlled using userspace >> > on a per-context basis. Instead, t

Re: [Intel-gfx] Intel-GFX-CI is halted due to power issue

The incident is over: power has been restored, but CI is still quiet. I'll check up the affected hosts and start re-testing the missed Patchwork series. Best Regards, Tomi Sarvela From: Sarvela, Tomi P Sent: Tuesday, March 8, 2022 11:26 AM To: intel-gfx@lists.freedesktop.org Intel-GFX-CI has o

Re: [Intel-gfx] [GIT PULL] GVT next changes for drm-intel-next

Which suits better for you? For me, I am OK with both. If you are not in a rush of closing the window, I can submit through drm-intel-next-fixes. Thanks, Zhi. On 3/8/22 9:56 AM, Nikula, Jani wrote: > On Tue, 08 Mar 2022, "Wang, Zhi A" wrote: >> Hi folks: >> >> Here is a new pull request of gvt-

Re: [Intel-gfx] [GIT PULL] GVT next changes for drm-intel-next

On Tue, 08 Mar 2022, "Wang, Zhi A" wrote: > Hi folks: > > Here is a new pull request of gvt-next. It contains a small patch to add the > missing > mdev attribute name, which will be used by the middleware, like kubevirt. I'm wondering if I should pull this to drm-intel-next, which is already tar

Re: [Intel-gfx] [PATCH v3 1/4] drm/i915/guc: Limit scheduling properties to avoid overflow

On 03/03/2022 22:37, john.c.harri...@intel.com wrote: From: John Harrison GuC converts the pre-emption timeout and timeslice quantum values into clock ticks internally. That significantly reduces the point of 32bit overflow. On current platforms, worst case scenario is approximately 110 seco

Re: [Intel-gfx] [PATCH v3 4/4] drm/i915: Improve long running OCL w/a for GuC submission

On 03/03/2022 22:37, john.c.harri...@intel.com wrote: From: John Harrison A workaround was added to the driver to allow OpenCL workloads to run 'forever' by disabling pre-emption on the RCS engine for Gen12. It is not totally unbound as the heartbeat will kick in eventually and cause a reset

  1   2   >