Re: [Intel-gfx] [PATCH 03/46] drm/i915/guc: Don't return -EAGAIN to user when guc_ids exhausted

On Tue, Aug 03, 2021 at 03:29:00PM -0700, Matthew Brost wrote: > Rather than returning -EAGAIN to the user when no guc_ids are available, > implement a fair sharing algorithm in the kernel which blocks submissons > until guc_ids become available. Submissions are released one at a time, > based on p

Re: [Intel-gfx] [PATCH 04/46] drm/i915/guc: Don't allow requests not ready to consume all guc_ids

On Tue, Aug 03, 2021 at 03:29:01PM -0700, Matthew Brost wrote: > Add a heuristic which checks if over half of the available guc_ids are > currently consumed by requests not ready to be submitted. If this > heuristic is true at request creation time (normal guc_id allocation > location) force all su

Re: [Intel-gfx] [PATCH v5 07/12] drm/i915/gt: Pipelined page migration

On Thu, Jun 17, 2021 at 8:30 AM Thomas Hellström wrote: > From: Chris Wilson > > If we pipeline the PTE updates and then do the copy of those pages > within a single unpreemptible command packet, we can submit the copies > and leave them to be scheduled without having to synchronously wait > unde

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

On Mon, Aug 02, 2021 at 06:59:57PM +0800, Desmond Cheong Zhi Xi wrote: > 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 ("

Re: [Intel-gfx] [PATCH] drm/i915/userptr: Probe existence of backing struct pages upon creation

Op 03-08-2021 om 17:57 schreef Maarten Lankhorst: > Op 2021-08-03 om 17:45 schreef Jason Ekstrand: >> On Tue, Aug 3, 2021 at 10:09 AM Daniel Vetter wrote: >>> On Wed, Jul 28, 2021 at 4:22 PM Matthew Auld >>> wrote: On Mon, 26 Jul 2021 at 17:10, Tvrtko Ursulin wrote: > On 26/07/2021

[Intel-gfx] [PATCH] drm/i915: Update small joiner ram size

Xelpd supports larger small joiner ram. Signed-off-by: Vandita Kulkarni --- drivers/gpu/drm/i915/display/intel_dp.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/display/intel_dp.c b/drivers/gpu/drm/i915/display/intel_dp.c index 75d4ebc66941..d174f0

[Intel-gfx] [PULL] drm-misc-next

drm-misc-next-2021-08-05: drm-misc-next for v5.15: UAPI Changes: Cross-subsystem Changes: Core Changes: - Assorted docbook updates. - Unbreak damage selftests. - Define DRM_FORMAT_MAX_PLANES, maximum planes for a planar format. - Add gem fb vmap/vunmap helpers, use them in gud and vkms drivers.

[Intel-gfx] [PATCH v3 5/8] 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 help

[Intel-gfx] [PATCH v3 2/8] 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 ppg

[Intel-gfx] [PATCH v3 1/8] 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 pla

[Intel-gfx] [PATCH v3 7/8] 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 Dat

[Intel-gfx] [PATCH v3 4/8] 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 gt->vm,

[Intel-gfx] [PATCH v3 8/8] 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 do

[Intel-gfx] [PATCH v3 3/8] 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 C

[Intel-gfx] [PATCH v3 6/8] 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 v3 0/8] remove rcu support from i915_address_space

Hi all, My seemingly trivial but totally not cleanup patch at the end now leaks, so clearly the fixup in v2 did improve things but I still don't understand that. Anyway that was fairly orthogonal, so I dropped it for later. v1: https://lore.kernel.org/dri-devel/20210802154806.3710472-1-daniel.ve

[Intel-gfx] [PATCH v5 00/20] drm/sched dependency handling and implicit sync fixes

Hi all, Two big changes: - bikeshed repainted in new paint, pls don't touch, it's all fresh! The functions are now called _add_dependency and _add_implicit_dependencies. - msm conversion, which includes a bugfix for the msm drm/sched conversion. I think it would be really good if the first tw

[Intel-gfx] [PATCH v5 02/20] drm/msm: Fix drm/sched point of no return rules

Originally drm_sched_job_init was the point of no return, after which drivers must submit a job. I've split that up, which allows us to fix this issue pretty easily. Only thing we have to take care of is to not skip to error paths after that. Other drivers do this the same for out-fence and simila

[Intel-gfx] [PATCH v5 01/20] drm/sched: Split drm_sched_job_init

This is a very confusingly named function, because not just does it init an object, it arms it and provides a point of no return for pushing a job into the scheduler. It would be nice if that's a bit clearer in the interface. But the real reason is that I want to push the dependency tracking helpe

[Intel-gfx] [PATCH v5 04/20] drm/sched: Add dependency tracking

Instead of just a callback we can just glue in the gem helpers that panfrost, v3d and lima currently use. There's really not that many ways to skin this cat. v2/3: Rebased. v4: Repaint this shed. The functions are now called _add_dependency() and _add_implicit_dependency() Reviewed-by: Boris Bre

[Intel-gfx] [PATCH v5 03/20] drm/sched: Barriers are needed for entity->last_scheduled

It might be good enough on x86 with just READ_ONCE, but the write side should then at least be WRITE_ONCE because x86 has total store order. It's definitely not enough on arm. Fix this proplery, which means - explain the need for the barrier in both places - point at the other side in each commen

[Intel-gfx] [PATCH v5 05/20] drm/sched: drop entity parameter from drm_sched_push_job

Originally a job was only bound to the queue when we pushed this, but now that's done in drm_sched_job_init, making that parameter entirely redundant. Remove it. The same applies to the context parameter in lima_sched_context_queue_task, simplify that too. v2: Rebase on top of msm adopting drm/s

[Intel-gfx] [PATCH v5 06/20] drm/sched: improve docs around drm_sched_entity

I found a few too many things that are tricky and not documented, so I started typing. I found a few more things that looked broken while typing, see the varios FIXME in drm_sched_entity. Also some of the usual logics: - actually include sched_entity.c declarations, that was lost in the move he

[Intel-gfx] [PATCH v5 07/20] drm/panfrost: use scheduler dependency tracking

Just deletes some code that's now more shared. Note that thanks to the split into drm_sched_job_init/arm we can now easily pull the _init() part from under the submission lock way ahead where we're adding the sync file in-fences as dependencies. v2: Correctly clean up the partially set up job, no

[Intel-gfx] [PATCH v5 09/20] drm/v3d: Move drm_sched_job_init to v3d_job_init

Prep work for using the scheduler dependency handling. We need to call drm_sched_job_init earlier so we can use the new drm_sched_job_await* functions for dependency handling here. v2: Slightly better commit message and rebase to include the drm_sched_job_arm() call (Emma). v3: Cleanup jobs under

[Intel-gfx] [PATCH v5 08/20] drm/lima: use scheduler dependency tracking

Nothing special going on here. Aside reviewing the code, it seems like drm_sched_job_arm() should be moved into lima_sched_context_queue_task and put under some mutex together with drm_sched_push_job(). See the kerneldoc for drm_sched_push_job(). v2: Rebase over renamed functions to add dependenc

[Intel-gfx] [PATCH v5 10/20] drm/v3d: Use scheduler dependency handling

With the prep work out of the way this isn't tricky anymore. Aside: The chaining of the various jobs is a bit awkward, with the possibility of failure in bad places. I think with the drm_sched_job_init/arm split and maybe preloading the job->dependencies xarray this should be fixable. v2: Rebase

[Intel-gfx] [PATCH v5 11/20] drm/etnaviv: Use scheduler dependency handling

We need to pull the drm_sched_job_init much earlier, but that's very minor surgery. v2: Actually fix up cleanup paths by calling drm_sched_job_init, which I wanted to to in the previous round (and did, for all other drivers). Spotted by Lucas. v3: Rebase over renamed functions to add dependencies

[Intel-gfx] [PATCH v5 14/20] drm/sched: Don't store self-dependencies

This is essentially part of drm_sched_dependency_optimized(), which only amdgpu seems to make use of. Use it a bit more. This would mean that as-is amdgpu can't use the dependency helpers, at least not with the current approach amdgpu has for deciding whether a vm_flush is needed. Since amdgpu als

[Intel-gfx] [PATCH v5 17/20] drm/etnaviv: Don't break exclusive fence ordering

There's only one exclusive slot, and we must not break the ordering. Adding a new exclusive fence drops all previous fences from the dma_resv. To avoid violating the signalling order we err on the side of over-synchronizing by waiting for the existing fences, even if userspace asked us to ignore th

[Intel-gfx] [PATCH v5 15/20] drm/sched: Check locking in drm_sched_job_await_implicit

You really need to hold the reservation here or all kinds of funny things can happen between grabbing the dependencies and inserting the new fences. Acked-by: Melissa Wen Signed-off-by: Daniel Vetter Cc: "Christian König" Cc: Daniel Vetter Cc: Luben Tuikov Cc: Andrey Grodzovsky Cc: Alex Deuc

[Intel-gfx] [PATCH v5 13/20] drm/gem: Delete gem array fencing helpers

Integrated into the scheduler now and all users converted over. Signed-off-by: Daniel Vetter Cc: Maarten Lankhorst Cc: Maxime Ripard Cc: Thomas Zimmermann Cc: David Airlie Cc: Daniel Vetter Cc: Sumit Semwal Cc: "Christian König" Cc: linux-me...@vger.kernel.org Cc: linaro-mm-...@lists.linar

[Intel-gfx] [PATCH v5 16/20] drm/msm: Don't break exclusive fence ordering

There's only one exclusive slot, and we must not break the ordering. Adding a new exclusive fence drops all previous fences from the dma_resv. To avoid violating the signalling order we err on the side of over-synchronizing by waiting for the existing fences, even if userspace asked us to ignore t

[Intel-gfx] [PATCH v5 18/20] drm/i915: delete exclude argument from i915_sw_fence_await_reservation

No longer used, the last user disappeared with commit d07f0e59b2c762584478920cd2d11fba2980a94a Author: Chris Wilson Date: Fri Oct 28 13:58:44 2016 +0100 drm/i915: Move GEM activity tracking into a common struct reservation_object Signed-off-by: Daniel Vetter Cc: Maarten Lankhorst Cc: "T

[Intel-gfx] [PATCH v5 12/20] drm/msm: Use scheduler dependency handling

drm_sched_job_init is already at the right place, so this boils down to deleting code. Signed-off-by: Daniel Vetter Cc: Rob Clark Cc: Sean Paul Cc: Sumit Semwal Cc: "Christian König" Cc: linux-arm-...@vger.kernel.org Cc: freedr...@lists.freedesktop.org Cc: linux-me...@vger.kernel.org Cc: lina

[Intel-gfx] [PATCH v5 20/20] dma-resv: Give the docs a do-over

Specifically document the new/clarified rules around how the shared fences do not have any ordering requirements against the exclusive fence. But also document all the things a bit better, given how central struct dma_resv to dynamic buffer management the docs have been very inadequat. - Lots mor

[Intel-gfx] [PATCH v5 19/20] drm/i915: Don't break exclusive fence ordering

There's only one exclusive slot, and we must not break the ordering. Adding a new exclusive fence drops all previous fences from the dma_resv. To avoid violating the signalling order we err on the side of over-synchronizing by waiting for the existing fences, even if userspace asked us to ignore th

Re: [Intel-gfx] [PATCH 24/33] drm/i915/guc: Implement banned contexts for GuC submission

On 27/07/2021 01:23, Matthew Brost wrote: When using GuC submission, if a context gets banned disable scheduling and mark all inflight requests as complete. Cc: John Harrison Signed-off-by: Matthew Brost Reviewed-by: John Harrison --- drivers/gpu/drm/i915/gem/i915_gem_context.c | 2 +-

[Intel-gfx] [PATCH] drm/i915: Be more gentle when exiting non-persistent contexts

From: Tvrtko Ursulin When a non-persistent context exits we currently mark it as banned in order to trigger fast termination of any outstanding GPU jobs it may have left running. In doing so we apply a very strict 1ms limit in which the left over job has to preempt before we issues an engine res

[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: - remov

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Update small joiner ram size

== Series Details == Series: drm/i915: Update small joiner ram size URL : https://patchwork.freedesktop.org/series/93410/ State : success == Summary == CI Bug Log - changes from CI_DRM_10449 -> Patchwork_20771 Summary --- **SUCCESS**

Re: [Intel-gfx] [PATCH v3 07/14] vfio/platform: Use open_device() instead of open coding a refcnt scheme

Hi Jason, On 7/29/21 2:49 AM, Jason Gunthorpe wrote: > Platform simply wants to run some code when the device is first > opened/last closed. Use the core framework and locking for this. Aside > from removing a bit of code this narrows the locking scope from a global > lock. > > Signed-off-by: Jas

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for remove rcu support from i915_address_space (rev4)

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

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

== Series Details == Series: remove rcu support from i915_address_space (rev4) 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. -drivers/gpu/drm

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

== Series Details == Series: remove rcu support from i915_address_space (rev4) URL : https://patchwork.freedesktop.org/series/93314/ State : failure == Summary == CI Bug Log - changes from CI_DRM_10449 -> Patchwork_20772 Summary ---

Re: [Intel-gfx] [PATCH v5 14/20] drm/sched: Don't store self-dependencies

On Thu, Aug 5, 2021 at 3:18 PM Christian König wrote: > > > > Am 05.08.21 um 12:46 schrieb Daniel Vetter: > > This is essentially part of drm_sched_dependency_optimized(), which > > only amdgpu seems to make use of. Use it a bit more. > > > > This would mean that as-is amdgpu can't use the depende

Re: [Intel-gfx] [PATCH v5 15/20] drm/sched: Check locking in drm_sched_job_await_implicit

On Thu, Aug 5, 2021 at 3:19 PM Christian König wrote: > > Am 05.08.21 um 12:47 schrieb Daniel Vetter: > > You really need to hold the reservation here or all kinds of funny > > things can happen between grabbing the dependencies and inserting the > > new fences. > > > > Acked-by: Melissa Wen > >

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/sched dependency handling and implicit sync fixes

== Series Details == Series: drm/sched dependency handling and implicit sync fixes URL : https://patchwork.freedesktop.org/series/93415/ State : warning == Summary == $ dim checkpatch origin/drm-tip fbee9b54db37 drm/sched: Split drm_sched_job_init -:237: WARNING:UNSPECIFIED_INT: Prefer 'unsign

Re: [Intel-gfx] [PATCH v5 01/20] drm/sched: Split drm_sched_job_init

On Thu, Aug 5, 2021 at 3:44 PM Christian König wrote: > Am 05.08.21 um 12:46 schrieb Daniel Vetter: > > This is a very confusingly named function, because not just does it > > init an object, it arms it and provides a point of no return for > > pushing a job into the scheduler. It would be nice if

[Intel-gfx] ✗ Fi.CI.BUILD: failure for Provide core infrastructure for managing open/release (rev8)

== Series Details == Series: Provide core infrastructure for managing open/release (rev8) URL : https://patchwork.freedesktop.org/series/92556/ State : failure == Summary == Applying: vfio/samples: Remove module get/put Applying: vfio/mbochs: Fix missing error unwind of mbochs_used_mbytes Appl

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/sched dependency handling and implicit sync fixes

== Series Details == Series: drm/sched dependency handling and implicit sync fixes URL : https://patchwork.freedesktop.org/series/93415/ State : failure == Summary == CI Bug Log - changes from CI_DRM_10450 -> Patchwork_20773 Summary ---

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: Be more gentle when exiting non-persistent contexts

== Series Details == Series: drm/i915: Be more gentle when exiting non-persistent contexts URL : https://patchwork.freedesktop.org/series/93420/ State : failure == Summary == CI Bug Log - changes from CI_DRM_10450 -> Patchwork_20775 Summary

Re: [Intel-gfx] [PATCH v5 14/20] drm/sched: Don't store self-dependencies

On Thu, Aug 5, 2021 at 3:57 PM Christian König wrote: > Am 05.08.21 um 15:25 schrieb Daniel Vetter: > > On Thu, Aug 5, 2021 at 3:18 PM Christian König > > wrote: > >> > >> > >> Am 05.08.21 um 12:46 schrieb Daniel Vetter: > >>> This is essentially part of drm_sched_dependency_optimized(), which >

Re: [Intel-gfx] [PATCH v5 01/20] drm/sched: Split drm_sched_job_init

On Thu, Aug 5, 2021 at 4:47 PM Christian König wrote: > > Am 05.08.21 um 16:07 schrieb Daniel Vetter: > > On Thu, Aug 5, 2021 at 3:44 PM Christian König > > wrote: > >> Am 05.08.21 um 12:46 schrieb Daniel Vetter: > >>> This is a very confusingly named function, because not just does it > >>> ini

Re: [Intel-gfx] [PATCH v4 05/18] drm/i915/dg2: Add SQIDI steering

On Wed, Aug 04, 2021 at 01:22:17PM -0700, Lucas De Marchi wrote: > On Thu, Jul 29, 2021 at 09:59:55AM -0700, Matt Roper wrote: > > Although DG2_G10 platforms will always have all SQIDI's present and > > don't need steering for registers in a SQIDI MMIO range, this isn't true > > for DG2_G11 platfor

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/dp: Use max params for older panels

== Series Details == Series: drm/i915/dp: Use max params for older panels URL : https://patchwork.freedesktop.org/series/93390/ State : success == Summary == CI Bug Log - changes from CI_DRM_10445_full -> Patchwork_20769_full Summary --

Re: [Intel-gfx] [PATCH v3 09/14] vfio/pci: Change vfio_pci_try_bus_reset() to use the dev_set

On Tue, Aug 03, 2021 at 10:52:25AM -0600, Alex Williamson wrote: > On Tue, 3 Aug 2021 13:41:52 -0300 > Jason Gunthorpe wrote: > > On Tue, Aug 03, 2021 at 10:34:06AM -0600, Alex Williamson wrote: > > > I think the vfio_pci_find_reset_target() function needs to be re-worked > > > to just tell us tru

Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: Be more gentle when exiting non-persistent contexts

On 05/08/2021 16:04, Patchwork wrote: *Patch Details* *Series:* drm/i915: Be more gentle when exiting non-persistent contexts *URL:* https://patchwork.freedesktop.org/series/93420/ *State:*failure *Details:* https://intel-gfx-ci

Re: [Intel-gfx] [PATCH] drm/i915: Be more gentle when exiting non-persistent contexts

On Thu, Aug 05, 2021 at 01:05:09PM +0100, Tvrtko Ursulin wrote: > From: Tvrtko Ursulin > > When a non-persistent context exits we currently mark it as banned in > order to trigger fast termination of any outstanding GPU jobs it may have > left running. > > In doing so we apply a very strict 1ms

[Intel-gfx] [PATCH v5 3/9] drm/i915/dg2: Report INSTDONE_GEOM values in error state

Xe_HPG adds some additional INSTDONE_GEOM debug registers; the Mesa team has indicated that having these reported in the error state would be useful for debugging GPU hangs. These registers are replicated per-DSS with gslice steering. Cc: Lionel Landwerlin Signed-off-by: Matt Roper Acked-by: Li

[Intel-gfx] [PATCH v5 4/9] drm/i915/xehpsdv: Add compute DSS type

From: Stuart Summers Starting in XeHP, the concept of slice has been removed in favor of DSS (Dual-Subslice) masks for various workload types. These workloads have been divided into those enabled for geometry and those enabled for compute. i915 currently maintains a single set of S/SS/EU masks f

[Intel-gfx] [PATCH v5 2/9] drm/i915/xehp: Loop over all gslices for INSTDONE processing

We no longer have traditional slices on Xe_HP platforms, but the INSTDONE registers are replicated according to gslice representation which is similar. We can mostly re-use the existing instdone code with just a few modifications: * Create an alternate instdone loop macro that will iterate over

[Intel-gfx] [PATCH v5 8/9] drm/i915/dg2: Maintain backward-compatible nested batch behavior

For tgl+, the per-context setting of MI_MODE[12] determines whether the bits of a nested MI_BATCH_BUFFER_START instruction should be interpreted in the traditional manner or whether they should instead use a new tgl+ meaning that breaks backward compatibility, but allows nesting into 3rd-level batc

[Intel-gfx] [PATCH v5 6/9] drm/i915/xehpsdv: Read correct RP_STATE_CAP register

The RP_STATE_CAP register is no longer part of the MCHBAR on XEHPSDV; this register is now a per-tile register at GTTMMADDR offset 0x250014. Cc: Rodrigo Vivi Signed-off-by: Matt Roper Signed-off-by: Lucas De Marchi Reviewed-by: Rodrigo Vivi --- drivers/gpu/drm/i915/gt/intel_rps.c | 4 +++- dr

[Intel-gfx] [PATCH v5 1/9] drm/i915/dg2: Add support for new DG2-G11 revid 0x5

The bspec has been updated with a new revision 0x5 that translates to B1 GT stepping and C0 display stepping. Bspec: 44477 Signed-off-by: Matt Roper --- drivers/gpu/drm/i915/intel_step.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpu/drm/i915/intel_step.c b/drivers/gpu/drm/i915

[Intel-gfx] [PATCH v5 5/9] drm/i915/xehpsdv: factor out function to read RP_STATE_CAP

From: Lucas De Marchi Instead of maintaining the same if ladder in 3 different places, add a function to read RP_STATE_CAP. Signed-off-by: Lucas De Marchi Signed-off-by: Matt Roper --- drivers/gpu/drm/i915/gt/debugfs_gt_pm.c | 8 +++- drivers/gpu/drm/i915/gt/intel_rps.c | 17

[Intel-gfx] [PATCH v5 0/9] Begin enabling Xe_HP SDV and DG2 platforms

This series provides some of the initial enablement patches for two upcoming discrete GPUs: * XeHP SDV: Xe_HP (version 12.50) graphics IP, no display IP * DG2: Xe_HPG (version 12.55) graphics IP, Xe_LPD (version 13) display IP Both platforms will need additional enablement patches beyond what'

[Intel-gfx] [PATCH v5 7/9] drm/i915/dg2: Add new LRI reg offsets

From: Akeem G Abodunrin New LRI register offsets were introduced for DG2, this patch adds those extra registers, and create new register table for setting offsets to compare with HW generated context image - especially for gt_lrc test. Also updates general purpose register with scratch offset for

[Intel-gfx] [PATCH v5 9/9] drm/i915/dg2: Configure PCON in DP pre-enable path

From: Ankit Nautiyal Add the functions to configure HDMI2.1 pcon for DG2, before DP link training. Signed-off-by: Ankit Nautiyal Signed-off-by: Matt Roper --- drivers/gpu/drm/i915/display/intel_ddi.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/gpu/drm/i915/display/intel_ddi

Re: [Intel-gfx] [PATCH v5 1/9] drm/i915/dg2: Add support for new DG2-G11 revid 0x5

On Thu, Aug 05, 2021 at 09:36:39AM -0700, Matt Roper wrote: The bspec has been updated with a new revision 0x5 that translates to B1 GT stepping and C0 display stepping. Bspec: 44477 Signed-off-by: Matt Roper Reviewed-by: Lucas De Marchi Lucas De Marchi --- drivers/gpu/drm/i915/intel_ste

Re: [Intel-gfx] [PATCH v5 14/20] drm/sched: Don't store self-dependencies

Am 05.08.21 um 12:46 schrieb Daniel Vetter: This is essentially part of drm_sched_dependency_optimized(), which only amdgpu seems to make use of. Use it a bit more. This would mean that as-is amdgpu can't use the dependency helpers, at least not with the current approach amdgpu has for decidi

Re: [Intel-gfx] [PATCH v5 15/20] drm/sched: Check locking in drm_sched_job_await_implicit

Am 05.08.21 um 12:47 schrieb Daniel Vetter: You really need to hold the reservation here or all kinds of funny things can happen between grabbing the dependencies and inserting the new fences. Acked-by: Melissa Wen Signed-off-by: Daniel Vetter Cc: "Christian König" Cc: Daniel Vetter Cc: Lube

Re: [Intel-gfx] [PATCH v5 4/9] drm/i915/xehpsdv: Add compute DSS type

On Thu, Aug 05, 2021 at 09:36:42AM -0700, Matt Roper wrote: From: Stuart Summers Starting in XeHP, the concept of slice has been removed in favor of DSS (Dual-Subslice) masks for various workload types. These workloads have been divided into those enabled for geometry and those enabled for comp

[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915: fix i915_globals_exit() section mismatch error

== Series Details == Series: drm/i915: fix i915_globals_exit() section mismatch error URL : https://patchwork.freedesktop.org/series/93398/ State : failure == Summary == CI Bug Log - changes from CI_DRM_10445_full -> Patchwork_20770_full Su

Re: [Intel-gfx] [PATCH v3 09/14] vfio/pci: Change vfio_pci_try_bus_reset() to use the dev_set

On Thu, 5 Aug 2021 08:47:01 -0300 Jason Gunthorpe wrote: > On Tue, Aug 03, 2021 at 10:52:25AM -0600, Alex Williamson wrote: > > On Tue, 3 Aug 2021 13:41:52 -0300 > > Jason Gunthorpe wrote: > > > On Tue, Aug 03, 2021 at 10:34:06AM -0600, Alex Williamson wrote: > > > > I think the vfio_pci_fin

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for Begin enabling Xe_HP SDV and DG2 platforms (rev9)

== Series Details == Series: Begin enabling Xe_HP SDV and DG2 platforms (rev9) URL : https://patchwork.freedesktop.org/series/92135/ State : warning == Summary == $ dim checkpatch origin/drm-tip 515352629f0e drm/i915/dg2: Add support for new DG2-G11 revid 0x5 b8058f4b6221 drm/i915/xehp: Loop o

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for Begin enabling Xe_HP SDV and DG2 platforms (rev9)

== Series Details == Series: Begin enabling Xe_HP SDV and DG2 platforms (rev9) URL : https://patchwork.freedesktop.org/series/92135/ 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/d

Re: [Intel-gfx] [PATCH v5 01/20] drm/sched: Split drm_sched_job_init

Am 05.08.21 um 12:46 schrieb Daniel Vetter: This is a very confusingly named function, because not just does it init an object, it arms it and provides a point of no return for pushing a job into the scheduler. It would be nice if that's a bit clearer in the interface. But the real reason is tha

Re: [Intel-gfx] [PATCH v5 03/20] drm/sched: Barriers are needed for entity->last_scheduled

Am 05.08.21 um 12:46 schrieb Daniel Vetter: It might be good enough on x86 with just READ_ONCE, but the write side should then at least be WRITE_ONCE because x86 has total store order. It's definitely not enough on arm. Fix this proplery, which means - explain the need for the barrier in bot

Re: [Intel-gfx] [PATCH v5 04/20] drm/sched: Add dependency tracking

Am 05.08.21 um 12:46 schrieb Daniel Vetter: Instead of just a callback we can just glue in the gem helpers that panfrost, v3d and lima currently use. There's really not that many ways to skin this cat. v2/3: Rebased. v4: Repaint this shed. The functions are now called _add_dependency() and _add

Re: [Intel-gfx] [PATCH v5 05/20] drm/sched: drop entity parameter from drm_sched_push_job

Am 05.08.21 um 12:46 schrieb Daniel Vetter: Originally a job was only bound to the queue when we pushed this, but now that's done in drm_sched_job_init, making that parameter entirely redundant. Remove it. The same applies to the context parameter in lima_sched_context_queue_task, simplify that

Re: [Intel-gfx] [PATCH v5 14/20] drm/sched: Don't store self-dependencies

Am 05.08.21 um 15:25 schrieb Daniel Vetter: On Thu, Aug 5, 2021 at 3:18 PM Christian König wrote: Am 05.08.21 um 12:46 schrieb Daniel Vetter: This is essentially part of drm_sched_dependency_optimized(), which only amdgpu seems to make use of. Use it a bit more. This would mean that as-is a

[Intel-gfx] ✓ Fi.CI.BAT: success for Begin enabling Xe_HP SDV and DG2 platforms (rev9)

== Series Details == Series: Begin enabling Xe_HP SDV and DG2 platforms (rev9) URL : https://patchwork.freedesktop.org/series/92135/ State : success == Summary == CI Bug Log - changes from CI_DRM_10451 -> Patchwork_20776 Summary ---

Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: Be more gentle when exiting non-persistent contexts

On Thu, Aug 05, 2021 at 05:10:29PM +0100, Tvrtko Ursulin wrote: > > On 05/08/2021 16:04, Patchwork wrote: > > *Patch Details* > > *Series:* drm/i915: Be more gentle when exiting non-persistent contexts > > *URL:* https://patchwork.freedesktop.org/series/93420/ > >

Re: [Intel-gfx] [PATCH 4/4] DO_NOT_MERGE: drm/i915/display: Enable PSR2 selective fetch by default

On 8/3/21 8:18 PM, Souza, Jose wrote: On Tue, 2021-08-03 at 14:17 +0300, Gwan-gyeong Mun wrote: On 7/31/21 3:10 AM, José Roberto de Souza wrote: Only to execute tests with PSR2 selective fetch enabled and check what is broken. IGT tests know to fail with this: - kms_cursor_legacy: all test

Re: [Intel-gfx] [PATCH] drm/i915: Update small joiner ram size

On Thu, Aug 05, 2021 at 03:49:37PM +0530, Vandita Kulkarni wrote: > Xelpd supports larger small joiner ram. > > Signed-off-by: Vandita Kulkarni > --- > drivers/gpu/drm/i915/display/intel_dp.c | 4 +++- > 1 file changed, 3 insertions(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/i915/displa

Re: [Intel-gfx] [PATCH v4 3/4] drm/shmem-helpers: Allocate wc pages on x86

Hi Am 23.07.21 um 09:36 schrieb Daniel Vetter: The real fix is to get at the architecture-specific wc allocator, which is currently not something that's exposed, but hidden within the dma api. I think having this stick out like this is better than hiding it behind fake generic code (like we do

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for remove rcu support from i915_address_space (rev5)

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

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

== Series Details == Series: remove rcu support from i915_address_space (rev5) 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. -drivers/gpu/drm

Re: [Intel-gfx] [PATCH v5 01/20] drm/sched: Split drm_sched_job_init

Am 05.08.21 um 16:07 schrieb Daniel Vetter: On Thu, Aug 5, 2021 at 3:44 PM Christian König wrote: Am 05.08.21 um 12:46 schrieb Daniel Vetter: This is a very confusingly named function, because not just does it init an object, it arms it and provides a point of no return for pushing a job into

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

== Series Details == Series: remove rcu support from i915_address_space (rev5) URL : https://patchwork.freedesktop.org/series/93314/ State : failure == Summary == CI Bug Log - changes from CI_DRM_10451 -> Patchwork_20777 Summary ---

Re: [Intel-gfx] [PATCH] drm/aperture: Pass DRM driver structure instead of driver name

On 29/06/2021 16:58, Thomas Zimmermann wrote: Print the name of the DRM driver when taking over fbdev devices. Makes the output to dmesg more consistent. Note that the driver name is only used for printing a string to the kernel log. No UAPI is affected by this change. Signed-off-by: Thomas Zimm

Re: [Intel-gfx] [PATCH v5 07/20] drm/panfrost: use scheduler dependency tracking

Acked-by: Alyssa Rosenzweig On Thu, Aug 05, 2021 at 12:46:52PM +0200, Daniel Vetter wrote: > Just deletes some code that's now more shared. > > Note that thanks to the split into drm_sched_job_init/arm we can now > easily pull the _init() part from under the submission lock way ahead > where we'

Re: [Intel-gfx] [PATCH 4/4] DO_NOT_MERGE: drm/i915/display: Enable PSR2 selective fetch by default

On Thu, 2021-08-05 at 21:26 +0300, Gwan-gyeong Mun wrote: > > On 8/3/21 8:18 PM, Souza, Jose wrote: > > On Tue, 2021-08-03 at 14:17 +0300, Gwan-gyeong Mun wrote: > > > > > > On 7/31/21 3:10 AM, José Roberto de Souza wrote: > > > > Only to execute tests with PSR2 selective fetch enabled and check

Re: [Intel-gfx] [PATCH v5 02/20] drm/msm: Fix drm/sched point of no return rules

On Thu, Aug 5, 2021 at 3:47 AM Daniel Vetter wrote: > > Originally drm_sched_job_init was the point of no return, after which > drivers must submit a job. I've split that up, which allows us to fix > this issue pretty easily. > > Only thing we have to take care of is to not skip to error paths aft

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for Provide core infrastructure for managing open/release (rev9)

== Series Details == Series: Provide core infrastructure for managing open/release (rev9) URL : https://patchwork.freedesktop.org/series/92556/ State : warning == Summary == $ dim checkpatch origin/drm-tip 5d99eb3c1b1c vfio/samples: Remove module get/put -:57: WARNING:FROM_SIGN_OFF_MISMATCH: F

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Update small joiner ram size

== Series Details == Series: drm/i915: Update small joiner ram size URL : https://patchwork.freedesktop.org/series/93410/ State : success == Summary == CI Bug Log - changes from CI_DRM_10449_full -> Patchwork_20771_full Summary --- *

[Intel-gfx] ✗ Fi.CI.BAT: failure for Provide core infrastructure for managing open/release (rev9)

== Series Details == Series: Provide core infrastructure for managing open/release (rev9) URL : https://patchwork.freedesktop.org/series/92556/ State : failure == Summary == CI Bug Log - changes from CI_DRM_10453 -> Patchwork_20778 Summary

Re: [Intel-gfx] [PATCH v3 09/14] vfio/pci: Change vfio_pci_try_bus_reset() to use the dev_set

On Thu, Aug 05, 2021 at 11:33:11AM -0600, Alex Williamson wrote: > > +static int vfio_pci_is_device_in_set(struct pci_dev *pdev, void *data) > > +{ > > + struct vfio_device_set *dev_set = data; > > + struct vfio_device *cur; > > + > > + lockdep_assert_held(&dev_set->lock); > > + > > + list_

[Intel-gfx] [PATCH v2] drm/i915/gvt: Fix cached atomics setting for Windows VM

We've seen recent regression with host and windows VM running simultaneously that cause gpu hang or even crash. Finally bisect to commit 58586680ffad ("drm/i915: Disable atomics in L3 for gen9"), which seems cached atomics behavior difference caused regression issue. This tries to add new scratch

  1   2   >