[Intel-gfx] ✓ Fi.CI.IGT: success for Another small batch of reviewed Xe_LPD patches

== Series Details == Series: Another small batch of reviewed Xe_LPD patches URL : https://patchwork.freedesktop.org/series/90560/ State : success == Summary == CI Bug Log - changes from CI_DRM_10133_full -> Patchwork_20194_full Summary

[Intel-gfx] [PATCH V2 0/1] drm/i915/gt: Introduce timeslicing for userspace

Test-with: 20210524124806.241439-1-tejaskumarx.surendrakumar.upadh...@intel.com Tejas Upadhyay (1): drm/i915/gt: Declare when we enabled timeslicing drivers/gpu/drm/i915/gt/intel_engine_user.c | 1 + include/uapi/drm/i915_drm.h | 1 + 2 files changed, 2 insertions(+) --

[Intel-gfx] [PATCH V2 1/1] drm/i915/gt: Declare when we enabled timeslicing

Let userspace know if they can trust timeslicing by including it as part of the I915_PARAM_HAS_SCHEDULER::I915_SCHEDULER_CAP_TIMESLICING V3: %s/TIMESLICE_BIT/HAS_TIMESLICES v2: Only declare timeslicing if we can safely preempt userspace. Fixes: 8ee36e048c98 ("drm/i915/execlists: Minimalistic

[Intel-gfx] ✗ Fi.CI.IGT: failure for dma-buf: Add an API for exporting sync files (v11)

== Series Details == Series: dma-buf: Add an API for exporting sync files (v11) URL : https://patchwork.freedesktop.org/series/90555/ State : failure == Summary == CI Bug Log - changes from CI_DRM_10133_full -> Patchwork_20193_full Summary

[Intel-gfx] ✗ Fi.CI.IGT: failure for Non-interface changing GuC CTBs updates

== Series Details == Series: Non-interface changing GuC CTBs updates URL : https://patchwork.freedesktop.org/series/90552/ State : failure == Summary == CI Bug Log - changes from CI_DRM_10133_full -> Patchwork_20192_full Summary ---

[Intel-gfx] ✓ Fi.CI.BAT: success for Another small batch of reviewed Xe_LPD patches

== Series Details == Series: Another small batch of reviewed Xe_LPD patches URL : https://patchwork.freedesktop.org/series/90560/ State : success == Summary == CI Bug Log - changes from CI_DRM_10133 -> Patchwork_20194 Summary ---

Re: [Intel-gfx] [PATCH] drm/i915: Add relocation exceptions for two other platforms

On Wed, 12 May 2021 at 03:05, Daniel Vetter wrote: > > On Tue, May 11, 2021 at 10:31:39AM +0200, Zbigniew Kempczyński wrote: > > We have established previously we stop using relocations starting > > from gen12 platforms with Tigerlake as an exception. Unfortunately > > we need extend transition

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for Another small batch of reviewed Xe_LPD patches

== Series Details == Series: Another small batch of reviewed Xe_LPD patches URL : https://patchwork.freedesktop.org/series/90560/ 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 Another small batch of reviewed Xe_LPD patches

== Series Details == Series: Another small batch of reviewed Xe_LPD patches URL : https://patchwork.freedesktop.org/series/90560/ State : warning == Summary == $ dim checkpatch origin/drm-tip 6973fd1b00ee drm/i915/xelpd: Enhanced pipe underrun reporting 1a22f3f8ec72 drm/i915/xelpd: Add VRR

[Intel-gfx] [CI 1/3] drm/i915/xelpd: Enhanced pipe underrun reporting

XE_LPD brings enhanced underrun recovery: the hardware can somewhat mitigate underruns by using an interpolated replacement pixel (soft underrun) or the previous pixel (hard underrun). Furthermore, underruns can now be caused downstream by the port, even if the pipe itself is operating properly.

[Intel-gfx] [CI 2/3] drm/i915/xelpd: Add VRR guardband for VRR CTL

From: Manasi Navare On XE_LPD, VRR CTL register adds a new VRR Guardband bitfield replacing the pipeline full and deprecating the pipeline override bit. This patch adds this corresponding bitfield in the register defs, crtc state vrr structure and populates this in vrr compute config and vrr

[Intel-gfx] [CI 3/3] drm/i915/display: Remove a redundant function argument from intel_psr_enable_source()

From: Gwan-gyeong Mun It removes intel_crtc_state from function argument of intel_psr_enable_source() in order to use intel_psr_enable_source() without intel_crtc_state on other psr internal functions. And we can get cpu_trancoder from intel_psr, therefore we don't need to pass intel_crtc_state

[Intel-gfx] [CI 0/3] Another small batch of reviewed Xe_LPD patches

Another small collection of Xe_LPD patches that have r-b's now and just need another CI pass to merge. Gwan-gyeong Mun (1): drm/i915/display: Remove a redundant function argument from intel_psr_enable_source() Manasi Navare (1): drm/i915/xelpd: Add VRR guardband for VRR CTL Matt Roper

[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915: Check HDMI sink deep color capabilities during .mode_valid() (rev3)

== Series Details == Series: drm/i915: Check HDMI sink deep color capabilities during .mode_valid() (rev3) URL : https://patchwork.freedesktop.org/series/90036/ State : failure == Summary == CI Bug Log - changes from CI_DRM_10132_full -> Patchwork_20191_full

[Intel-gfx] ✓ Fi.CI.BAT: success for dma-buf: Add an API for exporting sync files (v11)

== Series Details == Series: dma-buf: Add an API for exporting sync files (v11) URL : https://patchwork.freedesktop.org/series/90555/ State : success == Summary == CI Bug Log - changes from CI_DRM_10133 -> Patchwork_20193 Summary ---

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: g4x/vlv/chv CxSR/wm fixes/cleanups (rev2)

== Series Details == Series: drm/i915: g4x/vlv/chv CxSR/wm fixes/cleanups (rev2) URL : https://patchwork.freedesktop.org/series/90164/ State : success == Summary == CI Bug Log - changes from CI_DRM_10132_full -> Patchwork_20190_full

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for dma-buf: Add an API for exporting sync files (v11)

== Series Details == Series: dma-buf: Add an API for exporting sync files (v11) URL : https://patchwork.freedesktop.org/series/90555/ 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 dma-buf: Add an API for exporting sync files (v11)

== Series Details == Series: dma-buf: Add an API for exporting sync files (v11) URL : https://patchwork.freedesktop.org/series/90555/ State : warning == Summary == $ dim checkpatch origin/drm-tip 225a57e84149 dma-buf: Add dma_fence_array_for_each (v2) -:75: CHECK:MACRO_ARG_REUSE: Macro

[Intel-gfx] ✓ Fi.CI.BAT: success for Non-interface changing GuC CTBs updates

== Series Details == Series: Non-interface changing GuC CTBs updates URL : https://patchwork.freedesktop.org/series/90552/ State : success == Summary == CI Bug Log - changes from CI_DRM_10133 -> Patchwork_20192 Summary ---

[Intel-gfx] [PATCH 5/7] dma-buf: Add an API for exporting sync files (v11)

Modern userspace APIs like Vulkan are built on an explicit synchronization model. This doesn't always play nicely with the implicit synchronization used in the kernel and assumed by X11 and Wayland. The client -> compositor half of the synchronization isn't too bad, at least on intel, because we

[Intel-gfx] [PATCH 7/7] RFC: dma-buf: Add an API for importing sync files (v7)

This patch is analogous to the previous sync file export patch in that it allows you to import a sync_file into a dma-buf. Unlike the previous patch, however, this does add genuinely new functionality to dma-buf. Without this, the only way to attach a sync_file to a dma-buf is to submit a batch

[Intel-gfx] [PATCH 4/7] dma-buf: Document DMA_BUF_IOCTL_SYNC

This adds a new "DMA Buffer ioctls" section to the dma-buf docs and adds documentation for DMA_BUF_IOCTL_SYNC. Signed-off-by: Jason Ekstrand Cc: Daniel Vetter Cc: Christian König Cc: Sumit Semwal --- Documentation/driver-api/dma-buf.rst | 8 +++ include/uapi/linux/dma-buf.h | 32

[Intel-gfx] [PATCH 6/7] RFC: dma-buf: Add an extra fence to dma_resv_get_singleton_unlocked

For dma-buf sync_file import, we want to get all the fences on a dma_resv plus one more. We could wrap the fence we get back in an array fence or we could make dma_resv_get_singleton_unlocked take "one more" to make this case easier. Signed-off-by: Jason Ekstrand Reviewed-by: Daniel Vetter Cc:

[Intel-gfx] [PATCH 3/7] dma-buf: Add dma_resv_get_singleton_unlocked (v5)

Add a helper function to get a single fence representing all fences in a dma_resv object. This fence is either the only one in the object or all not signaled fences of the object in a flatted out dma_fence_array. v2 (Jason Ekstrand): - Take reference of fences both for creating the

[Intel-gfx] [PATCH 2/7] dma-buf: Rename dma_resv helpers from _rcu to _unlocked (v2)

None of these helpers actually leak any RCU details to the caller. They all assume you have a genuine reference, take the RCU read lock, and retry if needed. Naming them with an _rcu is likely to cause callers more panic than needed. v2 (Jason Ekstrand): - Fix function argument indentation

[Intel-gfx] [PATCH 1/7] dma-buf: Add dma_fence_array_for_each (v2)

From: Christian König Add a helper to iterate over all fences in a dma_fence_array object. v2 (Jason Ekstrand) - Return NULL from dma_fence_array_first if head == NULL. This matches the iterator behavior of dma_fence_chain_for_each in that it iterates zero times if head == NULL. -

[Intel-gfx] [PATCH 0/7] dma-buf: Add an API for exporting sync files (v11)

Modern userspace APIs like Vulkan are built on an explicit synchronization model. This doesn't always play nicely with the implicit synchronization used in the kernel and assumed by X11 and Wayland. The client -> compositor half of the synchronization isn't too bad, at least on intel, because we

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for Non-interface changing GuC CTBs updates

== Series Details == Series: Non-interface changing GuC CTBs updates URL : https://patchwork.freedesktop.org/series/90552/ 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 Non-interface changing GuC CTBs updates

== Series Details == Series: Non-interface changing GuC CTBs updates URL : https://patchwork.freedesktop.org/series/90552/ State : warning == Summary == $ dim checkpatch origin/drm-tip 232417d031b9 drm/i915/guc: skip disabling CTBs before sanitizing the GuC 341c70656750 drm/i915/guc: use

[Intel-gfx] [PATCH 14/17] drm/i915/guc: Ensure H2G buffer updates visible before tail update

Ensure H2G buffer updates are visible before descriptor tail updates by inserting a barrier between the H2G buffer update and the tail. The barrier is simple wmb() for SMEM and is register write for LMEM. This is needed if more than 1 H2G can be inflight at once. Signed-off-by: Matthew Brost Cc:

[Intel-gfx] [PATCH 15/17] drm/i915/guc: Stop using mutex while sending CTB messages

From: Michal Wajdeczko We are no longer using descriptor to hold G2H replies and we are protecting access to the descriptor and command buffer by the separate spinlock, so we can stop using mutex. Signed-off-by: Michal Wajdeczko Signed-off-by: Matthew Brost Reviewed-by: Matthew Brost ---

[Intel-gfx] [PATCH 16/17] drm/i915/guc: Don't receive all G2H messages in irq handler

From: Michal Wajdeczko In irq handler try to receive just single G2H message, let other messages to be received from tasklet. Signed-off-by: Michal Wajdeczko Signed-off-by: Matthew Brost Reviewed-by: Matthew Brost --- drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c | 67 ---

[Intel-gfx] [PATCH 17/17] drm/i915/guc: Always copy CT message to new allocation

From: Michal Wajdeczko Since most of future CT traffic will be based on G2H requests, instead of copying incoming CT message to static buffer and then create new allocation for such request, always copy incoming CT message to new allocation. Also by doing it while reading CT header, we can

[Intel-gfx] [PATCH 12/17] drm/i915/guc: Relax CTB response timeout

From: Michal Wajdeczko In upcoming patch we will allow more CTB requests to be sent in parallel to the GuC for procesing, so we shouldn't assume any more that GuC will always reply without 10ms. Use bigger value from CONFIG_DRM_I915_GUC_CTB_TIMEOUT instead. v2: Add

[Intel-gfx] [PATCH 08/17] drm/i915/guc: Only rely on own CTB size

From: Michal Wajdeczko In upcoming GuC firmware, CTB size will be removed from the CTB descriptor so we must keep it locally for any calculations. While around, improve some debug messages and helpers. Signed-off-by: Michal Wajdeczko Signed-off-by: Matthew Brost Reviewed-by: Matthew Brost

[Intel-gfx] [PATCH 13/17] drm/i915/guc: Start protecting access to CTB descriptors

From: Michal Wajdeczko We want to stop using guc.send_mutex while sending CTB messages so we have to start protecting access to CTB send descriptor. For completeness protect also CTB receive descriptor. Add spinlock to struct intel_guc_ct_buffer and start using it. Signed-off-by: Michal

[Intel-gfx] [PATCH 11/17] drm/i915/guc: Update sizes of CTB buffers

From: Michal Wajdeczko Future GuC will require CTB buffers sizes to be multiple of 4K. Make these changes now as this shouldn't impact us too much. Signed-off-by: Michal Wajdeczko Signed-off-by: Matthew Brost Reviewed-by: Matthew Brost Cc: John Harrison ---

[Intel-gfx] [PATCH 10/17] drm/i915/guc: Replace CTB array with explicit members

From: Michal Wajdeczko Upcoming GuC firmware will always require just two CTBs and we also plan to configure them with different sizes, so definining them as array is no longer suitable. Signed-off-by: Michal Wajdeczko Signed-off-by: Matthew Brost Reviewed-by: Matthew Brost ---

[Intel-gfx] [PATCH 06/17] drm/i915/guc: Stop using fence/status from CTB descriptor

From: Michal Wajdeczko Stop using fence/status from CTB descriptor as future GuC ABI will no longer support replies over CTB descriptor. Signed-off-by: Michal Wajdeczko Signed-off-by: Matthew Brost Reviewed-by: Matthew Brost --- .../gt/uc/abi/guc_communication_ctb_abi.h | 4 +-

[Intel-gfx] [PATCH 09/17] drm/i915/guc: Don't repeat CTB layout calculations

From: Michal Wajdeczko We can retrieve offsets to cmds buffers and descriptor from actual pointers that we already keep locally. Signed-off-by: Michal Wajdeczko Signed-off-by: Matthew Brost Reviewed-by: Matthew Brost --- drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c | 16 ++-- 1

[Intel-gfx] [PATCH 07/17] drm/i915: Promote ptrdiff() to i915_utils.h

From: Michal Wajdeczko Generic helpers should be placed in i915_utils.h. Signed-off-by: Michal Wajdeczko Signed-off-by: Matthew Brost Reviewed-by: Matthew Brost --- drivers/gpu/drm/i915/i915_utils.h | 5 + drivers/gpu/drm/i915/i915_vma.h | 5 - 2 files changed, 5 insertions(+), 5

[Intel-gfx] [PATCH 03/17] drm/i915/guc: enable only the user interrupt when using GuC submission

From: Daniele Ceraolo Spurio In GuC submission mode the CS is owned by the GuC FW, so all CS status interrupts are handled by it. We only need the user interrupt as that signals request completion. Since we're now starting the engines directly in GuC submission mode when selected, we can stop

[Intel-gfx] [PATCH 05/17] drm/i915/guc: Keep strict GuC ABI definitions

From: Michal Wajdeczko Our fwif.h file is now mix of strict firmware ABI definitions and set of our helpers. In anticipation of upcoming changes to the GuC interface try to keep them separate in smaller maintainable files. Signed-off-by: Michal Wajdeczko Signed-off-by: Matthew Brost

[Intel-gfx] [PATCH 01/17] drm/i915/guc: skip disabling CTBs before sanitizing the GuC

From: Daniele Ceraolo Spurio If we're about to sanitize the GuC, something might have going wrong beforehand, so we should avoid trying to talk to it. Even if GuC is still running fine, the sanitize will reset its internal state and clear the CTB registration, so there is still no need to

[Intel-gfx] [PATCH 00/17] Non-interface changing GuC CTBs updates

As discussed in [1] we are breaking that large series into a several smaller ones. This series is the non-interface changing part of step #2 - it makes all the changes needed before updating the GuC firwmare to a new version without breaking any old interfaces. A follow on series will be squashed

[Intel-gfx] [PATCH 04/17] drm/i915/guc: Remove sample_forcewake h2g action

From: Rodrigo Vivi This action is no-op in the GuC side for a few versions already and it is getting entirely removed soon, in an upcoming version. Time to remove before we face communication issues. Cc: Vinay Belgaumkar Signed-off-by: Rodrigo Vivi Signed-off-by: Matthew Brost Acked-by:

[Intel-gfx] [PATCH 02/17] drm/i915/guc: use probe_error log for CT enablement failure

From: Daniele Ceraolo Spurio We have a couple of failure injection points in the CT enablement path, so we need to use i915_probe_error() to select the appropriate log level. A new macro (CT_PROBE_ERROR) has been added to the set of CT logging macros to be used in this scenario and upcoming

Re: [Intel-gfx] [PATCH v4 09/17] drm/i915/pxp: Implement arb session teardown

Hi Daniele, Thank you for the patch! Yet something to improve: [auto build test ERROR on drm-tip/drm-tip] [cannot apply to drm-intel/for-linux-next char-misc/char-misc-testing v5.13-rc3 next-20210525] [If your patch is applied to the wrong git tree, kindly drop us a note. And when submitting

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Remove the repeated declaration

== Series Details == Series: drm/i915: Remove the repeated declaration URL : https://patchwork.freedesktop.org/series/90524/ State : success == Summary == CI Bug Log - changes from CI_DRM_10131_full -> Patchwork_20187_full Summary ---

Re: [Intel-gfx] [RFC PATCH 18/97] drm/i915/guc: Don't receive all G2H messages in irq handler

On 25.05.2021 20:15, Matthew Brost wrote: > On Thu, May 06, 2021 at 12:13:32PM -0700, Matthew Brost wrote: >> From: Michal Wajdeczko >> >> In irq handler try to receive just single G2H message, let other >> messages to be received from tasklet. >> >> Signed-off-by: Michal Wajdeczko >>

Re: [Intel-gfx] [RFC PATCH 15/97] drm/i915/guc: Relax CTB response timeout

On 25.05.2021 20:08, Matthew Brost wrote: > On Thu, May 06, 2021 at 12:13:29PM -0700, Matthew Brost wrote: >> From: Michal Wajdeczko >> >> In upcoming patch we will allow more CTB requests to be sent in >> parallel to the GuC for procesing, so we shouldn't assume any more >> that GuC will

Re: [Intel-gfx] [PATCH 6/6] RFC: dma-buf: Add an API for importing sync files (v6)

On Tue, May 25, 2021 at 9:19 PM Jason Ekstrand wrote: > > On Tue, May 25, 2021 at 10:37 AM Daniel Vetter wrote: > > > > On Mon, May 24, 2021 at 03:59:54PM -0500, Jason Ekstrand wrote: > > > This patch is analogous to the previous sync file export patch in that > > > it allows you to import a

Re: [Intel-gfx] [PATCH 6/6] RFC: dma-buf: Add an API for importing sync files (v6)

On Tue, May 25, 2021 at 10:37 AM Daniel Vetter wrote: > > On Mon, May 24, 2021 at 03:59:54PM -0500, Jason Ekstrand wrote: > > This patch is analogous to the previous sync file export patch in that > > it allows you to import a sync_file into a dma-buf. Unlike the previous > > patch, however,

Re: [Intel-gfx] [PATCH v4 14/17] drm/i915/pxp: User interface for Protected buffer

> -Original Message- > From: Intel-gfx On Behalf Of > Daniele Ceraolo Spurio > Sent: Monday, May 24, 2021 10:48 PM > To: intel-gfx@lists.freedesktop.org > Cc: Vetter, Daniel ; Huang Sean Z > ; dri-de...@lists.freedesktop.org; Chris Wilson > ; Kondapally Kalyan > ; Bommu, Krishnaiah >

Re: [Intel-gfx] [RFC PATCH 19/97] drm/i915/guc: Always copy CT message to new allocation

On Thu, May 06, 2021 at 12:13:33PM -0700, Matthew Brost wrote: > From: Michal Wajdeczko > > Since most of future CT traffic will be based on G2H requests, > instead of copying incoming CT message to static buffer and then > create new allocation for such request, always copy incoming CT >

Re: [Intel-gfx] [PATCH 10/11] drm/simple-helper: drm_gem_simple_display_pipe_prepare_fb as default

> It's tedious to review this all the time, and my audit showed that > arcpgu actually forgot to set this. > > Make this the default and stop worrying. > > Again I sprinkled WARN_ON_ONCE on top to make sure we don't have > strange combinations of hooks: cleanup_fb without prepare_fb doesn't > make

Re: [Intel-gfx] [RFC PATCH 18/97] drm/i915/guc: Don't receive all G2H messages in irq handler

On Thu, May 06, 2021 at 12:13:32PM -0700, Matthew Brost wrote: > From: Michal Wajdeczko > > In irq handler try to receive just single G2H message, let other > messages to be received from tasklet. > > Signed-off-by: Michal Wajdeczko > Signed-off-by: Matthew Brost > --- >

Re: [Intel-gfx] [RFC PATCH 15/97] drm/i915/guc: Relax CTB response timeout

On Thu, May 06, 2021 at 12:13:29PM -0700, Matthew Brost wrote: > From: Michal Wajdeczko > > In upcoming patch we will allow more CTB requests to be sent in > parallel to the GuC for procesing, so we shouldn't assume any more > that GuC will always reply without 10ms. > > Use bigger value from

Re: [Intel-gfx] [RFC PATCH 60/97] drm/i915: Track 'serial' counts for virtual engines

On Tue, May 25, 2021 at 11:16:12AM +0100, Tvrtko Ursulin wrote: > > On 06/05/2021 20:14, Matthew Brost wrote: > > From: John Harrison > > > > The serial number tracking of engines happens at the backend of > > request submission and was expecting to only be given physical > > engines. However,

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Check HDMI sink deep color capabilities during .mode_valid() (rev3)

== Series Details == Series: drm/i915: Check HDMI sink deep color capabilities during .mode_valid() (rev3) URL : https://patchwork.freedesktop.org/series/90036/ State : success == Summary == CI Bug Log - changes from CI_DRM_10132 -> Patchwork_20191

Re: [Intel-gfx] [PATCH 10/11] drm/simple-helper: drm_gem_simple_display_pipe_prepare_fb as default

On Tue, May 25, 2021 at 07:48:12PM +0200, Noralf Trønnes wrote: > > It's tedious to review this all the time, and my audit showed that > > arcpgu actually forgot to set this. > > > > Make this the default and stop worrying. > > > > Again I sprinkled WARN_ON_ONCE on top to make sure we don't have >

Re: [Intel-gfx] [RFC PATCH 38/97] drm/i915/guc: Optimize CTB writes and reads

On Mon, May 24, 2021 at 03:31:25PM +0200, Michal Wajdeczko wrote: > > > On 06.05.2021 21:13, Matthew Brost wrote: > > CTB writes are now in the path of command submission and should be > > optimized for performance. Rather than reading CTB descriptor values > > (e.g. head, tail, size) which

Re: [Intel-gfx] [RFC PATCH 35/97] drm/i915/guc: Improve error message for unsolicited CT response

On Mon, May 24, 2021 at 01:59:54PM +0200, Michal Wajdeczko wrote: > > > On 06.05.2021 21:13, Matthew Brost wrote: > > Improve the error message when a unsolicited CT response is received by > > printing fence that couldn't be found, the last fence, and all requests > > with a response

Re: [Intel-gfx] [RFC PATCH 36/97] drm/i915/guc: Add non blocking CTB send function

On Mon, May 24, 2021 at 02:21:42PM +0200, Michal Wajdeczko wrote: > > > On 06.05.2021 21:13, Matthew Brost wrote: > > Add non blocking CTB send function, intel_guc_send_nb. In order to > > support a non blocking CTB send function a spin lock is needed to > > spin lock was added in 16/97 > > >

Re: [Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [1/5] drm/i915/display/adl_p: Drop earlier return in tc_has_modular_fia()

On Tue, 2021-05-25 at 06:30 +, Patchwork wrote: Patch Details Series: series starting with [1/5] drm/i915/display/adl_p: Drop earlier return in tc_has_modular_fia() URL:https://patchwork.freedesktop.org/series/90495/ State: success Details:

Re: [Intel-gfx] [PATCH 5/5] drm/i915/display/adl_p: Disable PSR2

On Tue, 2021-05-25 at 13:55 +0300, Jani Nikula wrote: > On Mon, 24 May 2021, José Roberto de Souza wrote: > > We are missing the implementation of some workarounds to enabled PSR2 > > in Alderlake P, so to avoid any CI report of issues around PSR2 > > disabling it until all PSR2 workarounds are

Re: [Intel-gfx] [RFC PATCH 36/97] drm/i915/guc: Add non blocking CTB send function

On Tue, May 25, 2021 at 10:21:00AM +0100, Tvrtko Ursulin wrote: > > On 06/05/2021 20:13, Matthew Brost wrote: > > Add non blocking CTB send function, intel_guc_send_nb. In order to > > support a non blocking CTB send function a spin lock is needed to > > protect the CTB descriptors fields. Also

Re: [Intel-gfx] [CI 3/3] drm/i915/dmc: Move struct intel_dmc to intel_dmc.h

On Mon, May 24, 2021 at 12:21:03PM -0700, Anusha Srivatsa wrote: Move struct intel_dmc from i915_drv.h to intel_dmc.h. v2: Add includes along with moving the struct. Signed-off-by: Anusha Srivatsa Reviewed-by: Lucas De Marchi Lucas De Marchi --- drivers/gpu/drm/i915/display/intel_dmc.h

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: g4x/vlv/chv CxSR/wm fixes/cleanups (rev2)

== Series Details == Series: drm/i915: g4x/vlv/chv CxSR/wm fixes/cleanups (rev2) URL : https://patchwork.freedesktop.org/series/90164/ State : success == Summary == CI Bug Log - changes from CI_DRM_10132 -> Patchwork_20190 Summary ---

Re: [Intel-gfx] [RFC PATCH 39/97] drm/i915/guc: Increase size of CTB buffers

On Tue, May 25, 2021 at 10:24:09AM +0100, Tvrtko Ursulin wrote: > > On 06/05/2021 20:13, Matthew Brost wrote: > > With the introduction of non-blocking CTBs more than one CTB can be in > > flight at a time. Increasing the size of the CTBs should reduce how > > often software hits the case where

Re: [Intel-gfx] [RFC PATCH 44/97] drm/i915/guc: Implement GuC submission tasklet

On Tue, May 25, 2021 at 10:43:32AM +0100, Tvrtko Ursulin wrote: > > On 06/05/2021 20:13, Matthew Brost wrote: > > Implement GuC submission tasklet for new interface. The new GuC > > interface uses H2G to submit contexts to the GuC. Since H2G use a single > > channel, a single tasklet submits is

Re: [Intel-gfx] [RFC PATCH 55/97] drm/i915/guc: Update intel_gt_wait_for_idle to work with GuC

On Tue, May 25, 2021 at 11:06:00AM +0100, Tvrtko Ursulin wrote: > > On 06/05/2021 20:14, Matthew Brost wrote: > > When running the GuC the GPU can't be considered idle if the GuC still > > has contexts pinned. As such, a call has been added in > > intel_gt_wait_for_idle to idle the UC and in turn

Re: [Intel-gfx] [PATCH 1/1] drm/i915/gt: Declare when we enabled timeslicing

Hi Tejas, Thank you for the patch! Yet something to improve: [auto build test ERROR on drm-intel/for-linux-next] [also build test ERROR on drm-tip/drm-tip linus/master v5.13-rc3 next-20210525] [If your patch is applied to the wrong git tree, kindly drop us a note. And when submitting patch, we

Re: [Intel-gfx] [RFC PATCH 53/97] drm/i915/guc: Disable semaphores when using GuC scheduling

On Tue, May 25, 2021 at 10:52:01AM +0100, Tvrtko Ursulin wrote: > > On 06/05/2021 20:14, Matthew Brost wrote: > > Disable semaphores when using GuC scheduling as semaphores are broken in > > the current GuC firmware. > > What is "current"? Given that the patch itself is like year and a half old.

Re: [Intel-gfx] [RFC PATCH 12/97] drm/i915/guc: Don't repeat CTB layout calculations

On Tue, May 25, 2021 at 03:07:06PM +0200, Michal Wajdeczko wrote: > > > On 25.05.2021 04:53, Matthew Brost wrote: > > On Thu, May 06, 2021 at 12:13:26PM -0700, Matthew Brost wrote: > >> From: Michal Wajdeczko > >> > >> We can retrieve offsets to cmds buffers and descriptor from > >> actual

Re: [Intel-gfx] [RFC PATCH 37/97] drm/i915/guc: Add stall timer to non blocking CTB send function

On Tue, May 25, 2021 at 04:15:15PM +0200, Michal Wajdeczko wrote: > > > On 24.05.2021 20:35, Matthew Brost wrote: > > On Mon, May 24, 2021 at 02:58:12PM +0200, Michal Wajdeczko wrote: > >> > >> > >> On 06.05.2021 21:13, Matthew Brost wrote: > >>> Implement a stall timer which fails H2G CTBs once

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915: g4x/vlv/chv CxSR/wm fixes/cleanups (rev2)

== Series Details == Series: drm/i915: g4x/vlv/chv CxSR/wm fixes/cleanups (rev2) URL : https://patchwork.freedesktop.org/series/90164/ 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] [RFC PATCH 00/97] Basic GuC submission support in the i915

On Tue, May 25, 2021 at 11:32:26AM +0100, Tvrtko Ursulin wrote: > > On 06/05/2021 20:13, Matthew Brost wrote: > > Basic GuC submission support. This is the first bullet point in the > > upstreaming plan covered in the following RFC [1]. > > > > At a very high level the GuC is a piece of firmware

Re: [Intel-gfx] [RFC PATCH 17/97] drm/i915/guc: Stop using mutex while sending CTB messages

On Thu, May 06, 2021 at 12:13:31PM -0700, Matthew Brost wrote: > From: Michal Wajdeczko > > We are no longer using descriptor to hold G2H replies and we are > protecting access to the descriptor and command buffer by the > separate spinlock, so we can stop using mutex. > > Signed-off-by: Michal

Re: [Intel-gfx] [PATCH 11/11] drm/tiny: drm_gem_simple_display_pipe_prepare_fb is the default

On Fri, May 21, 2021 at 04:09:13PM +0200, Noralf Trønnes wrote: > > > Den 21.05.2021 11.09, skrev Daniel Vetter: > > Goes through all the drivers and deletes the default hook since it's > > the default now. > > > > Signed-off-by: Daniel Vetter > > Acked-by: Noralf Trønnes Can you perhaps

Re: [Intel-gfx] [PATCH 0/3] Clean a few backend interfaces in the i915

On Tue, May 25, 2021 at 04:27:49PM +0100, Tvrtko Ursulin wrote: > > On 25/05/2021 14:56, Daniel Vetter wrote: > > On Fri, May 21, 2021 at 11:32:12AM -0700, Matthew Brost wrote: > > > As discussed in [1] start merging some support patches as a precursor to > > > GuC submission the i915. This is

Re: [Intel-gfx] [PATCH 0/3] Clean a few backend interfaces in the i915

On Tue, May 25, 2021 at 03:56:56PM +0200, Daniel Vetter wrote: > On Fri, May 21, 2021 at 11:32:12AM -0700, Matthew Brost wrote: > > As discussed in [1] start merging some support patches as a precursor to > > GuC submission the i915. This is step #1 mentioned in [1]. > > > > [1]

[Intel-gfx] ✗ Fi.CI.BUILD: failure for drm/i915/gt: Introduce timeslicing for userspace

== Series Details == Series: drm/i915/gt: Introduce timeslicing for userspace URL : https://patchwork.freedesktop.org/series/90539/ State : failure == Summary == CALLscripts/checksyscalls.sh CALLscripts/atomic/check-atomics.sh DESCEND objtool CHK include/generated/compile.h

Re: [Intel-gfx] [PATCH v3 06/12] drm/ttm: Add a generic TTM memcpy move for page-based iomem

Am 25.05.21 um 12:07 schrieb Thomas Hellström: On Tue, 2021-05-25 at 10:58 +0100, Matthew Auld wrote: On Tue, 25 May 2021 at 10:32, Thomas Hellström wrote: On 5/25/21 11:18 AM, Matthew Auld wrote: On Fri, 21 May 2021 at 16:33, Thomas Hellström wrote: The internal ttm_bo_util memcpy uses

[Intel-gfx] ✗ Fi.CI.BUILD: failure for drm/i915/gt: Introduce timeslicing for userspace

== Series Details == Series: drm/i915/gt: Introduce timeslicing for userspace URL : https://patchwork.freedesktop.org/series/90538/ State : failure == Summary == CALLscripts/checksyscalls.sh CALLscripts/atomic/check-atomics.sh DESCEND objtool CHK include/generated/compile.h

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Remove the repeated declaration

== Series Details == Series: drm/i915: Remove the repeated declaration URL : https://patchwork.freedesktop.org/series/90524/ State : success == Summary == CI Bug Log - changes from CI_DRM_10131 -> Patchwork_20187 Summary ---

Re: [Intel-gfx] [RFC PATCH 00/97] Basic GuC submission support in the i915

On Fri, May 14, 2021 at 12:31 PM Jason Ekstrand wrote: > > Pulling a few threads together... > > On Mon, May 10, 2021 at 1:39 PM Francisco Jerez wrote: > > > > I agree with Martin on this. Given that using GuC currently involves > > making your open-source graphics stack rely on a closed-source

Re: [Intel-gfx] [PATCH 6/6] RFC: dma-buf: Add an API for importing sync files (v6)

On Mon, May 24, 2021 at 03:59:54PM -0500, Jason Ekstrand wrote: > This patch is analogous to the previous sync file export patch in that > it allows you to import a sync_file into a dma-buf. Unlike the previous > patch, however, this does add genuinely new functionality to dma-buf. > Without

Re: [Intel-gfx] [PATCH 0/3] Clean a few backend interfaces in the i915

On 25/05/2021 14:56, Daniel Vetter wrote: On Fri, May 21, 2021 at 11:32:12AM -0700, Matthew Brost wrote: As discussed in [1] start merging some support patches as a precursor to GuC submission the i915. This is step #1 mentioned in [1]. [1] https://patchwork.freedesktop.org/series/89844/

Re: [Intel-gfx] [PATCH 5/6] RFC: dma-buf: Add an extra fence to dma_resv_get_singleton_unlocked

On Mon, May 24, 2021 at 03:59:53PM -0500, Jason Ekstrand wrote: > For dma-buf sync_file import, we want to get all the fences on a > dma_resv plus one more. We could wrap the fence we get back in an array > fence or we could make dma_resv_get_singleton_unlocked take "one more" > to make this case

Re: [Intel-gfx] [Mesa-dev] [PATCH 01/11] drm/amdgpu: Comply with implicit fencing rules

On Tue, May 25, 2021 at 5:05 PM Christian König wrote: > > Hi Daniel, > > Am 25.05.21 um 15:05 schrieb Daniel Vetter: > > Hi Christian, > > > > On Sat, May 22, 2021 at 10:30:19AM +0200, Christian König wrote: > >> Am 21.05.21 um 20:31 schrieb Daniel Vetter: > >> This works by adding the fence of

Re: [Intel-gfx] [PATCH] drm/i915/display: relax 2big checking around initial fb

On Tue, May 25, 2021 at 02:25:15PM +0100, Matthew Auld wrote: > On Fri, 7 May 2021 at 10:12, Matthew Auld wrote: > > > > From: Chris Wilson > > > > The kernel prefers enabling fbc over the initial fb, since this leads to > > actual runtime power savings, so if the initial fb is deemed too big >

Re: [Intel-gfx] [PATCH 4/6] dma-buf: Add an API for exporting sync files (v9)

On Mon, May 24, 2021 at 03:59:52PM -0500, Jason Ekstrand wrote: > Modern userspace APIs like Vulkan are built on an explicit > synchronization model. This doesn't always play nicely with the > implicit synchronization used in the kernel and assumed by X11 and > Wayland. The client -> compositor

Re: [Intel-gfx] [PATCH 2/6] dma-buf: Rename dma_resv helpers from _rcu to _unlocked

On Mon, May 24, 2021 at 03:59:50PM -0500, Jason Ekstrand wrote: > None of these helpers actually leak any RCU details to the caller. They > all assume you have a genuine reference, take the RCU read lock, and > retry if needed. Naming them with an _rcu is likely to cause callers > more panic

Re: [Intel-gfx] [PATCH 1/1] Let userspace know if they can trust timeslicing by including it as part of the I915_PARAM_HAS_SCHEDULER::I915_SCHEDULER_CAP_TIMESLICING

On Tue, May 25, 2021 at 03:19:47PM +0100, Tvrtko Ursulin wrote: > > + dri-devel as per process > > On 25/05/2021 14:55, Tejas Upadhyay wrote: > > v2: Only declare timeslicing if we can safely preempt userspace. > > Commit message got butchered up somehow so you'll need to fix that at some >

[Intel-gfx] drm-misc-next

Hi Dave and Daniel, here's this week's PR for drm-misc-next. Besides the usual round of fixes, amdgpu now supports hot unplug and GEM CMA supports cached page mappings. No standard email this week, sorry. Dim pushed the tag into the repo, but then failed to create the rsp email from it.

Re: [Intel-gfx] [PATCH 1/1] Let userspace know if they can trust timeslicing by including it as part of the I915_PARAM_HAS_SCHEDULER::I915_SCHEDULER_CAP_TIMESLICING

+ dri-devel as per process On 25/05/2021 14:55, Tejas Upadhyay wrote: v2: Only declare timeslicing if we can safely preempt userspace. Commit message got butchered up somehow so you'll need to fix that at some point. Regards, Tvrtko Fixes: 8ee36e048c98 ("drm/i915/execlists:

Re: [Intel-gfx] [RFC PATCH 37/97] drm/i915/guc: Add stall timer to non blocking CTB send function

On 24.05.2021 20:35, Matthew Brost wrote: > On Mon, May 24, 2021 at 02:58:12PM +0200, Michal Wajdeczko wrote: >> >> >> On 06.05.2021 21:13, Matthew Brost wrote: >>> Implement a stall timer which fails H2G CTBs once a period of time >>> with no forward progress is reached to prevent deadlock.

[Intel-gfx] [PATCH 0/1] drm/i915/gt: Introduce timeslicing for userspace

Test-with: 20210524124806.241439-1-tejaskumarx.surendrakumar.upadh...@intel.com Tejas Upadhyay (1): drm/i915/gt: Declare when we enabled timeslicing drivers/gpu/drm/i915/gt/intel_engine_user.c | 1 + include/uapi/drm/i915_drm.h | 1 + 2 files changed, 2 insertions(+) --

[Intel-gfx] [PATCH 1/1] drm/i915/gt: Declare when we enabled timeslicing

Let userspace know if they can trust timeslicing by including it as part of the I915_PARAM_HAS_SCHEDULER::I915_SCHEDULER_CAP_TIMESLICING v2: Only declare timeslicing if we can safely preempt userspace. Fixes: 8ee36e048c98 ("drm/i915/execlists: Minimalistic timeslicing") Signed-off-by: Chris

  1   2   >