[Intel-gfx] ✓ Fi.CI.BAT: success for Enable GuC submission by default on DG1

== Series Details == Series: Enable GuC submission by default on DG1 URL : https://patchwork.freedesktop.org/series/93325/ State : success == Summary == CI Bug Log - changes from CI_DRM_10440 -> Patchwork_20763 Summary ---

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for Enable GuC submission by default on DG1

== Series Details == Series: Enable GuC submission by default on DG1 URL : https://patchwork.freedesktop.org/series/93325/ 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 Enable GuC submission by default on DG1

== Series Details == Series: Enable GuC submission by default on DG1 URL : https://patchwork.freedesktop.org/series/93325/ State : warning == Summary == $ dim checkpatch origin/drm-tip 9d575da473a3 drm/i915: Do not define vma on stack -:12: WARNING:BAD_SIGN_OFF: Non-standard signature:

[Intel-gfx] [PATCH 3/4] drm/i915/guc: Add DG1 GuC / HuC firmware defs

Signed-off-by: Matthew Brost --- drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c b/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c index f8cb00ffb506..a685d563df72 100644 ---

[Intel-gfx] [PATCH 2/4] drm/i915/guc: put all guc objects in lmem when available

From: Daniele Ceraolo Spurio The firmware binary has to be loaded from lmem and the recommendation is to put all other objects in there as well. Note that we don't fall back to system memory if the allocation in lmem fails because all objects are allocated during driver load and if we have

[Intel-gfx] [PATCH 4/4] drm/i915/guc: Enable GuC submission by default on DG1

Signed-off-by: Matthew Brost --- drivers/gpu/drm/i915/gt/uc/intel_uc.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/gt/uc/intel_uc.c b/drivers/gpu/drm/i915/gt/uc/intel_uc.c index da57d18d9f6b..fc2fc8d111d8 100644 ---

[Intel-gfx] [PATCH 0/4] Enable GuC submission by default on DG1

Minimum set of patches to enable GuC submission on DG1 and enable it by default. A little difficult to test as IGTs do not work with DG1 due to a bunch of uAPI features being disabled (e.g. relocations, caching memory options, etc...). Tested with the loading the driver and 'live' selftests.

[Intel-gfx] [PATCH 1/4] drm/i915: Do not define vma on stack

From: Venkata Sandeep Dhanalakota Defining vma on stack can cause stack overflow, if vma gets populated with new fields. Cc: Daniele Ceraolo Spurio Cc: Tvrtko Ursulin Signed-off-by: Venkata Sandeep Dhanalakota Signef-off-by: Matthew Brost --- drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c | 18

[Intel-gfx] ✗ Fi.CI.IGT: failure for fbdev/efifb: Release PCI device's runtime PM ref during FB destroy

== Series Details == Series: fbdev/efifb: Release PCI device's runtime PM ref during FB destroy URL : https://patchwork.freedesktop.org/series/93307/ State : failure == Summary == CI Bug Log - changes from CI_DRM_10437_full -> Patchwork_20760_full

Re: [Intel-gfx] [PATCH 6/9] drm/i915: Drop __rcu from gem_context->vm

, kindly drop us a note. And when submitting patch, we suggest to use '--base' as documented in https://git-scm.com/docs/git-format-patch] url: https://github.com/0day-ci/linux/commits/Daniel-Vetter/remove-rcu-support-from-i915_address_space/20210802-234929 base: git://anongit.freedesktop.org/drm

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/display: Fix the 12 BPC bits for PIPE_MISC reg

== Series Details == Series: drm/i915/display: Fix the 12 BPC bits for PIPE_MISC reg URL : https://patchwork.freedesktop.org/series/93306/ State : success == Summary == CI Bug Log - changes from CI_DRM_10437_full -> Patchwork_20759_full

[Intel-gfx] ✓ Fi.CI.IGT: success for locking/lockdep, drm: apply new lockdep assert in drm_auth.c

== Series Details == Series: locking/lockdep, drm: apply new lockdep assert in drm_auth.c URL : https://patchwork.freedesktop.org/series/93304/ State : success == Summary == CI Bug Log - changes from CI_DRM_10437_full -> Patchwork_20757_full

Re: [Intel-gfx] [PATCH] drm/i915: Apply CMTG clock disabling WA while DPLL0 is enabled

On Tue, Aug 03, 2021 at 12:16:30AM +0300, Souza, Jose wrote: > On Tue, 2021-08-03 at 00:07 +0300, Imre Deak wrote: > > On Mon, Aug 02, 2021 at 11:52:41PM +0300, Souza, Jose wrote: > > > On Mon, 2021-08-02 at 22:01 +0300, Imre Deak wrote: > > > > CI test results/further experiments show that the

Re: [Intel-gfx] [PATCH] drm/i915: Apply CMTG clock disabling WA while DPLL0 is enabled

On Tue, 2021-08-03 at 00:07 +0300, Imre Deak wrote: > On Mon, Aug 02, 2021 at 11:52:41PM +0300, Souza, Jose wrote: > > On Mon, 2021-08-02 at 22:01 +0300, Imre Deak wrote: > > > CI test results/further experiments show that the workaround added in > > > > > > commit 573d7ce4f69a ("drm/i915/adlp:

Re: [Intel-gfx] [PATCH] drm/i915: Apply CMTG clock disabling WA while DPLL0 is enabled

On Mon, Aug 02, 2021 at 11:52:41PM +0300, Souza, Jose wrote: > On Mon, 2021-08-02 at 22:01 +0300, Imre Deak wrote: > > CI test results/further experiments show that the workaround added in > > > > commit 573d7ce4f69a ("drm/i915/adlp: Add workaround to disable CMTG clock > > gating") > > > > can

Re: [Intel-gfx] [PATCH] drm/i915: Apply CMTG clock disabling WA while DPLL0 is enabled

On Mon, 2021-08-02 at 22:01 +0300, Imre Deak wrote: > CI test results/further experiments show that the workaround added in > > commit 573d7ce4f69a ("drm/i915/adlp: Add workaround to disable CMTG clock > gating") > > can be applied only while DPLL0 is enabled. If it's disabled the >

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Apply CMTG clock disabling WA while DPLL0 is enabled

== Series Details == Series: drm/i915: Apply CMTG clock disabling WA while DPLL0 is enabled URL : https://patchwork.freedesktop.org/series/93318/ State : success == Summary == CI Bug Log - changes from CI_DRM_10440 -> Patchwork_20762

Re: [Intel-gfx] [PATCH i-g-t 1/1] i915/gem_scheduler: Ensure submission order in manycontexts

On Mon, Aug 02, 2021 at 09:59:01AM +0100, Tvrtko Ursulin wrote: > > > On 30/07/2021 19:06, Matthew Brost wrote: > > On Fri, Jul 30, 2021 at 10:58:38AM +0100, Tvrtko Ursulin wrote: > > > > > > On 27/07/2021 19:20, Matthew Brost wrote: > > > > With GuC submission contexts can get reordered

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915: Apply CMTG clock disabling WA while DPLL0 is enabled

== Series Details == Series: drm/i915: Apply CMTG clock disabling WA while DPLL0 is enabled URL : https://patchwork.freedesktop.org/series/93318/ State : warning == Summary == $ dim checkpatch origin/drm-tip 31185812783d drm/i915: Apply CMTG clock disabling WA while DPLL0 is enabled -:12:

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/adl_s: Update ADL-S PCI IDs

== Series Details == Series: drm/i915/adl_s: Update ADL-S PCI IDs URL : https://patchwork.freedesktop.org/series/93302/ State : success == Summary == CI Bug Log - changes from CI_DRM_10437_full -> Patchwork_20756_full Summary ---

[Intel-gfx] [PATCH] drm/i915: Apply CMTG clock disabling WA while DPLL0 is enabled

CI test results/further experiments show that the workaround added in commit 573d7ce4f69a ("drm/i915/adlp: Add workaround to disable CMTG clock gating") can be applied only while DPLL0 is enabled. If it's disabled the TRANS_CMTG_CHICKEN register is not accessible. Accordingly move the WA to

Re: [Intel-gfx] [PATCH v4 3/7] dyndbg: add dyndbg-bitmap definer and callbacks

On Mon, Aug 2, 2021 at 10:24 AM Emil Velikov wrote: > > Hi Jim, > > On Sat, 31 Jul 2021 at 22:42, Jim Cromie wrote: > > > +struct dyndbg_bitdesc { > > + /* bitpos is inferred from index in containing array */ > > + char *prefix; > > + char *help; > AFAICT these two should also

Re: [Intel-gfx] [PATCH v4 2/7] moduleparam: add data member to struct kernel_param

On Mon, Aug 2, 2021 at 10:18 AM Emil Velikov wrote: > > Hi Jim, > > On Sat, 31 Jul 2021 at 22:42, Jim Cromie wrote: > > > Use of this new data member will be rare, it might be worth redoing > > this as a separate/sub-type to keep the base case. > > > > Signed-off-by: Jim Cromie > > --- > >

[Intel-gfx] ✗ Fi.CI.BAT: failure for remove rcu support from i915_address_space

== Series Details == Series: remove rcu support from i915_address_space URL : https://patchwork.freedesktop.org/series/93314/ State : failure == Summary == CI Bug Log - changes from CI_DRM_10439 -> Patchwork_20761 Summary ---

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for remove rcu support from i915_address_space

== Series Details == Series: remove rcu support from i915_address_space URL : https://patchwork.freedesktop.org/series/93314/ 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 remove rcu support from i915_address_space

== Series Details == Series: remove rcu support from i915_address_space URL : https://patchwork.freedesktop.org/series/93314/ State : warning == Summary == $ dim checkpatch origin/drm-tip a853815d3335 drm/i915: Drop code to handle set-vm races from execbuf -:17: WARNING:COMMIT_LOG_LONG_LINE:

Re: [Intel-gfx] [PATCH v4 5/7] i915/gvt: control pr_debug("gvt:")s with bits in parameters/debug_gvt

Hi Jim, On Sat, 31 Jul 2021 at 22:42, Jim Cromie wrote: > DYNDBG_BITMAP_DESC(__gvt_debug, "dyndbg bitmap desc", > { "gvt: cmd: ", "command processing" }, > { "gvt: core: ", "core help" }, > { "gvt: dpy: ", "display help" }, > { "gvt: el: ", "help" }, >

Re: [Intel-gfx] [PATCH v4 3/7] dyndbg: add dyndbg-bitmap definer and callbacks

Hi Jim, On Sat, 31 Jul 2021 at 22:42, Jim Cromie wrote: > +struct dyndbg_bitdesc { > + /* bitpos is inferred from index in containing array */ > + char *prefix; > + char *help; AFAICT these two should also be constant, right? > +int param_set_dyndbg(const char *instr, const

Re: [Intel-gfx] [PATCH v4 2/7] moduleparam: add data member to struct kernel_param

Hi Jim, On Sat, 31 Jul 2021 at 22:42, Jim Cromie wrote: > Use of this new data member will be rare, it might be worth redoing > this as a separate/sub-type to keep the base case. > > Signed-off-by: Jim Cromie > --- > include/linux/moduleparam.h | 11 +-- > 1 file changed, 9

Re: [Intel-gfx] ✗ Fi.CI.IGT: failure for lpsp with hdmi/dp outputs

Re-reported. -Original Message- From: Deak, Imre Sent: Monday, August 2, 2021 4:23 AM To: intel-gfx@lists.freedesktop.org; Gupta, Anshuman ; Vudum, Lakshminarayana Subject: Re: [Intel-gfx] ✗ Fi.CI.IGT: failure for lpsp with hdmi/dp outputs On Thu, Jul 29, 2021 at 10:27:29PM +,

[Intel-gfx] [PATCH 9/9] drm/i915: Split out intel_context_create_user

There's quite a fundamental difference between userspace contexts, and kernel contexts. Latter all share intel_gt->vm, former get their vm from gem_ctx->vm (on full ppgtt at least). By splitting context creation for userspace from kernel-internal ones we can make this all a bit more strict and

[Intel-gfx] [PATCH 8/9] drm/i915: Stop rcu support for i915_address_space

The full audit is quite a bit of work: - i915_dpt has very simple lifetime (somehow we create a display pagetable vm per object, so its _very_ simple, there's only ever a single vma in there), and uses i915_vm_close(), which internally does a i915_vm_put(). No rcu. Aside: wtf is i915_dpt

[Intel-gfx] [PATCH 7/9] drm/i915: use xa_lock/unlock for fpriv->vm_xa lookups

We don't need the absolute speed of rcu for this. And i915_address_space in general dont need rcu protection anywhere else, after we've made gem contexts and engines a lot more immutable. Note that this semantically reverts commit aabbe344dc3ca5f7d8263a02608ba6179e8a4499 Author: Chris Wilson

[Intel-gfx] [PATCH 6/9] drm/i915: Drop __rcu from gem_context->vm

It's been invariant since commit ccbc1b97948ab671335e950271e39766729736c3 Author: Jason Ekstrand Date: Thu Jul 8 10:48:30 2021 -0500 drm/i915/gem: Don't allow changing the VM on running contexts (v4) this just completes the deed. I've tried to split out prep work for more

[Intel-gfx] [PATCH 5/9] drm/i915: Use i915_gem_context_get_eb_vm in intel_context_set_gem

Since commit ccbc1b97948ab671335e950271e39766729736c3 Author: Jason Ekstrand Date: Thu Jul 8 10:48:30 2021 -0500 drm/i915/gem: Don't allow changing the VM on running contexts (v4) the gem_ctx->vm can't change anymore. Plus we always set the intel_context->vm, so might as well use the

[Intel-gfx] [PATCH 4/9] drm/i915: Add i915_gem_context_is_full_ppgtt

And use it anywhere we have open-coded checks for ctx->vm that really only check for full ppgtt. Plus for paranoia add a GEM_BUG_ON that checks it's really only set when we have full ppgtt, just in case. gem_context->vm is different since it's NULL in ggtt mode, unlike intel_context->vm or

[Intel-gfx] [PATCH 3/9] drm/i915: Use i915_gem_context_get_eb_vm in ctx_getparam

Consolidates the "which is the vm my execbuf runs in" code a bit. We do some get/put which isn't really required, but all the other users want the refcounting, and I figured doing a function just for this getparam to avoid 2 atomis is a bit much. Signed-off-by: Daniel Vetter Cc: Jon Bloomfield

[Intel-gfx] [PATCH 2/9] drm/i915: Rename i915_gem_context_get_vm_rcu to i915_gem_context_get_eb_vm

The important part isn't so much that this does an rcu lookup - that's more an implementation detail, which will also be removed. The thing that makes this different from other functions is that it's gettting you the vm that batchbuffers will run in for that gem context, which is either a full

[Intel-gfx] [PATCH 1/9] drm/i915: Drop code to handle set-vm races from execbuf

Changing the vm from a finalized gem ctx is no longer possible, which means we don't have to check for that anymore. I was pondering whether to keep the check as a WARN_ON, but things go boom real bad real fast if the vm of a vma is wrong. Plus we'd need to also get the ggtt vm for !full-ppgtt

[Intel-gfx] [PATCH 0/9] remove rcu support from i915_address_space

Hi all, Jason wanted to do that as part of the scheduler series, but I object since rcu is very, very hard to review when adding, and much, much harder even to review when removing. This is because simply looking for __rcu pointer annotations and rcu functions isn't enough, rcu is also relied

[Intel-gfx] linux-next: manual merge of the drm-intel tree with Linus' tree

Hi all, Today's linux-next merge of the drm-intel tree got a conflict in: drivers/gpu/drm/i915/display/intel_display.c between commit: b4bde5554f70 ("drm/i915/display: split DISPLAY_VER 9 and 10 in intel_setup_outputs()") from Linus' tree and commits: cad83b405fe4 ("drm/i915/display:

[Intel-gfx] ✓ Fi.CI.IGT: success for lpsp with hdmi/dp outputs

== Series Details == Series: lpsp with hdmi/dp outputs URL : https://patchwork.freedesktop.org/series/93179/ State : success == Summary == CI Bug Log - changes from CI_DRM_10418_full -> Patchwork_20740_full Summary --- **SUCCESS**

[Intel-gfx] linux-next: manual merge of the drm-intel tree with the drm-intel-fixes tree

Hi all, Today's linux-next merge of the drm-intel tree got a conflict in: drivers/gpu/drm/i915/intel_device_info.c between commit: 0f9ed3b2c9ec ("drm/i915/display/cnl+: Handle fused off DSC") from the drm-intel-fixes tree and commit: a4d082fc194a ("drm/i915: rename/remove CNL

[Intel-gfx] ✓ Fi.CI.BAT: success for fbdev/efifb: Release PCI device's runtime PM ref during FB destroy

== Series Details == Series: fbdev/efifb: Release PCI device's runtime PM ref during FB destroy URL : https://patchwork.freedesktop.org/series/93307/ State : success == Summary == CI Bug Log - changes from CI_DRM_10437 -> Patchwork_20760

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/display: Fix the 12 BPC bits for PIPE_MISC reg

== Series Details == Series: drm/i915/display: Fix the 12 BPC bits for PIPE_MISC reg URL : https://patchwork.freedesktop.org/series/93306/ State : success == Summary == CI Bug Log - changes from CI_DRM_10437 -> Patchwork_20759 Summary

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915/display: Fix the 12 BPC bits for PIPE_MISC reg

== Series Details == Series: drm/i915/display: Fix the 12 BPC bits for PIPE_MISC reg URL : https://patchwork.freedesktop.org/series/93306/ State : warning == Summary == $ dim checkpatch origin/drm-tip fee101cc5424 drm/i915/display: Fix the 12 BPC bits for PIPE_MISC reg -:10:

[Intel-gfx] ✓ Fi.CI.BAT: success for locking/lockdep, drm: apply new lockdep assert in drm_auth.c

== Series Details == Series: locking/lockdep, drm: apply new lockdep assert in drm_auth.c URL : https://patchwork.freedesktop.org/series/93304/ State : success == Summary == CI Bug Log - changes from CI_DRM_10437 -> Patchwork_20757 Summary

[Intel-gfx] ✗ Fi.CI.BUILD: failure for gpu/drm/i915: Remove duplicated include of intel_region_lmem.h

== Series Details == Series: gpu/drm/i915: Remove duplicated include of intel_region_lmem.h URL : https://patchwork.freedesktop.org/series/93305/ State : failure == Summary == Applying: gpu/drm/i915: Remove duplicated include of intel_region_lmem.h Using index info to reconstruct a base

[Intel-gfx] [PATCH] fbdev/efifb: Release PCI device's runtime PM ref during FB destroy

Atm the EFI FB driver gets a runtime PM reference for the associated GFX PCI device during driver probing and releases it only when removing the driver. When fbcon switches to the FB provided by the PCI device's driver (for instance i915/drmfb), the EFI FB will get only unregistered without the

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for locking/lockdep, drm: apply new lockdep assert in drm_auth.c

== Series Details == Series: locking/lockdep, drm: apply new lockdep assert in drm_auth.c URL : https://patchwork.freedesktop.org/series/93304/ 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 locking/lockdep, drm: apply new lockdep assert in drm_auth.c

== Series Details == Series: locking/lockdep, drm: apply new lockdep assert in drm_auth.c URL : https://patchwork.freedesktop.org/series/93304/ State : warning == Summary == $ dim checkpatch origin/drm-tip 60bc4f495a48 locking/lockdep: Provide lockdep_assert{, _once}() helpers -:30:

[Intel-gfx] [PATCH v2] drm/i915/display: Fix the 12 BPC bits for PIPE_MISC reg

From: Ankit Nautiyal Till DISPLAY12 the PIPE_MISC bits 5-7 are used to set the Dithering BPC, with valid values of 6, 8, 10 BPC, with Dithering bit enabled. Also, these bits are used in case of HW readout for pipe_bpp in case of DSI. For ADLP+ these bits are used to set the PORT OUTPUT BPC, with

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/adl_s: Update ADL-S PCI IDs

== Series Details == Series: drm/i915/adl_s: Update ADL-S PCI IDs URL : https://patchwork.freedesktop.org/series/93302/ State : success == Summary == CI Bug Log - changes from CI_DRM_10437 -> Patchwork_20756 Summary --- **SUCCESS**

[Intel-gfx] [PATCH] gpu/drm/i915: Remove duplicated include of intel_region_lmem.h

Duplicate include header file "intel_region_lmem.h" line 8: #include "intel_region_lmem.h" line 12: #include "intel_region_lmem.h" Signed-off-by: zhouchuangao --- drivers/gpu/drm/i915/gt/intel_region_lmem.c | 1 - 1 file changed, 1 deletion(-) diff --git

Re: [Intel-gfx] [PATCH] drm/i915: Fix typo in comments and Kconfig.debug

Hello Thanks for your reply. Exactly , the tools is base on codespell But it seems not working well > iff -Original Message- From: Lucas De Marchi Sent: 2021年7月31日 1:31 To: Cai,Huoqing Cc: jani.nik...@linux.intel.com; joonas.lahti...@linux.intel.com; rodrigo.v...@intel.com;

[Intel-gfx] [RESEND PATCH v2 2/2] drm: add lockdep assert to drm_is_current_master_locked

In drm_is_current_master_locked, accessing drm_file.master should be protected by either drm_file.master_lookup_lock or drm_device.master_mutex. This was previously awkward to assert with lockdep. Following patch ("locking/lockdep: Provide lockdep_assert{,_once}() helpers"), this assertion is now

[Intel-gfx] [RESEND PATCH v2 1/2] locking/lockdep: Provide lockdep_assert{, _once}() helpers

From: Peter Zijlstra Extract lockdep_assert{,_once}() helpers to more easily write composite assertions like, for example: lockdep_assert(lockdep_is_held(_device.master_mutex) || lockdep_is_held(_file.master_lookup_lock)); Signed-off-by: Peter Zijlstra (Intel)

[Intel-gfx] [RESEND PATCH v2 0/2] locking/lockdep, drm: apply new lockdep assert in drm_auth.c

Hi all, My bad for the resend. Adding cc: intel-gfx, and the maintainers and mailing lists for include/drm/drm_file.h. Following a discussion on the patch ("drm: use the lookup lock in drm_is_current_master") [1], Peter Zijlstra proposed new lockdep_assert helpers to make it convenient to

Re: [Intel-gfx] ✗ Fi.CI.IGT: failure for lpsp with hdmi/dp outputs

On Thu, Jul 29, 2021 at 10:27:29PM +, Patchwork wrote: > == Series Details == > > Series: lpsp with hdmi/dp outputs > URL : https://patchwork.freedesktop.org/series/93179/ > State : failure Thanks for the patch pushed it to -din, fixing some typos in the commit message and the playback

[Intel-gfx] [PATCH] drm/i915/adl_s: Update ADL-S PCI IDs

Sync PCI IDs with Bspec. Bspec:53655 Signed-off-by: Tejas Upadhyay --- include/drm/i915_pciids.h | 4 1 file changed, 4 deletions(-) diff --git a/include/drm/i915_pciids.h b/include/drm/i915_pciids.h index eee18fa53b54..8adb058dfc5a 100644 --- a/include/drm/i915_pciids.h +++

Re: [Intel-gfx] [PATCH] drm/i915: Correct SFC_DONE register offset

Matt Roper writes: > On Wed, Jul 28, 2021 at 06:05:57PM -0700, Matt Roper wrote: >> On Wed, Jul 28, 2021 at 04:34:11PM -0700, Matt Roper wrote: >> > The register offset for SFC_DONE was missing a '0' at the end, causing >> > us to read from a non-existent register address. We only use this >> >

Re: [Intel-gfx] [PATCH 1/1] drm/i915: Check if engine has heartbeat when closing a context

On 30/07/2021 19:13, John Harrison wrote: On 7/30/2021 02:49, Tvrtko Ursulin wrote: On 30/07/2021 01:13, John Harrison wrote: On 7/28/2021 17:34, Matthew Brost wrote: If an engine associated with a context does not have a heartbeat, ban it immediately. This is needed for GuC submission as

Re: [Intel-gfx] [PATCH v2 1/2] drm/i915: document caching related bits

Matthew Auld writes: > Try to document the object caching related bits, like cache_coherent and > cache_dirty. > > v2(Ville): > - As pointed out by Ville, fix the completely incorrect assumptions >about the "partial" coherency on shared LLC platforms. > > Suggested-by: Daniel Vetter >

Re: [Intel-gfx] [PATCH] drm: Fix oops in damage self-tests by mocking damage property

Op 30-07-2021 om 11:52 schreef Daniel Vetter: > I've added a new check to make sure that drivers which insepct the > damage property have it set up correctly, but somehow missed that this > borke the damage selftest in the CI result noise. > > Fix it up by mocking enough of drm_device and

Re: [Intel-gfx] [PATCH i-g-t 1/1] i915/gem_scheduler: Ensure submission order in manycontexts

On 30/07/2021 19:06, Matthew Brost wrote: On Fri, Jul 30, 2021 at 10:58:38AM +0100, Tvrtko Ursulin wrote: On 27/07/2021 19:20, Matthew Brost wrote: With GuC submission contexts can get reordered (compared to submission order), if contexts get reordered the sequential nature of the batches

[Intel-gfx] [CI v2] drm/i915: Tweaked Wa_14010685332 for all PCHs

dispcnlunit1_cp_xosc_clkreq clock observed to be active on TGL-H platform despite Wa_14010685332 original sequence, thus blocks entry to deeper s0ix state. The Tweaked Wa_14010685332 sequence fixes this issue, therefore use tweaked Wa_14010685332 sequence for every PCH since PCH_CNP. v2: -

Re: [Intel-gfx] [PATCH v2 7/7] drm/connector: add ref to drm_connector_get in iter docs

Pushed this one doc patch with Daniel's R-b on IRC.

Re: [Intel-gfx] [PATCH v3 1/1] drm/i915/dg1: Adjust the AUDIO power domain

> -Original Message- > From: Gupta, Anshuman > Sent: Thursday, July 29, 2021 5:49 PM > To: intel-gfx@lists.freedesktop.org > Cc: Deak, Imre ; Gupta, Anshuman > ; Ville Syrjälä ; Kai > Vehmanen ; Shankar, Uma > > Subject: [PATCH v3 1/1] drm/i915/dg1: Adjust the AUDIO power domain > >

Re: [Intel-gfx] [PATCH i-g-t v3 03/11] lib/i915/gem_mman: add fixed mode to gem_mmap_offset__cpu

On Fri, 30 Jul 2021 01:53:40 -0700, Matthew Auld wrote: > > On discrete we only support the new fixed mode. > > Signed-off-by: Matthew Auld > Cc: Maarten Lankhorst > Cc: Ashutosh Dixit > Cc: Daniel Vetter > Cc: Ramalingam C > --- > lib/i915/gem_mman.c | 8 +++- > 1 file changed, 7

Re: [Intel-gfx] [PATCH i-g-t v2 04/11] lib/i915/gem_mman: add fixed mode to gem_mmap__cpu

On Thu, 29 Jul 2021 01:50:45 -0700, Matthew Auld wrote: > Hi Matt, > On 29/07/2021 00:07, Dixit, Ashutosh wrote: > > On Wed, 28 Jul 2021 03:30:34 -0700, Matthew Auld wrote: > >> > >> diff --git a/lib/i915/gem_mman.c b/lib/i915/gem_mman.c > >> index 337d28fb..6f5e6d72 100644 > >> ---

Re: [Intel-gfx] [PATCH i-g-t v3 09/11] tests/i915/module_load: update for discrete

On Fri, 30 Jul 2021 01:53:46 -0700, Matthew Auld wrote: > > The set_caching ioctl is gone for discrete, and now just returns > -ENODEV. Update the gem_sanitycheck to account for that. After this we > should be back to just having the breakage caused by missing reloc > support for the reload

Re: [Intel-gfx] [PATCH i-g-t v3 08/11] lib/ioctl_wrappers: update set_domain for discrete

On Fri, 30 Jul 2021 01:53:45 -0700, Matthew Auld wrote: > > On discrete set_domain is now gone, instead we just need to add the > wait. Reviewed-by: Ashutosh Dixit > Signed-off-by: Matthew Auld > Cc: Maarten Lankhorst > Cc: Ashutosh Dixit > Cc: Daniel Vetter > Cc: Ramalingam C > --- >