[Intel-gfx] ✓ Fi.CI.BAT: success for GuC CTBs changes + a few misc patches

2021-06-02 Thread Patchwork
== Series Details == Series: GuC CTBs changes + a few misc patches URL : https://patchwork.freedesktop.org/series/90923/ State : success == Summary == CI Bug Log - changes from CI_DRM_10161 -> Patchwork_20268 Summary --- **SUCCESS**

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for GuC CTBs changes + a few misc patches

2021-06-02 Thread Patchwork
== Series Details == Series: GuC CTBs changes + a few misc patches URL : https://patchwork.freedesktop.org/series/90923/ 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 GuC CTBs changes + a few misc patches

2021-06-02 Thread Patchwork
== Series Details == Series: GuC CTBs changes + a few misc patches URL : https://patchwork.freedesktop.org/series/90923/ State : warning == Summary == $ dim checkpatch origin/drm-tip b995ee93341d drm/i915/guc: skip disabling CTBs before sanitizing the GuC 615b2e145353 drm/i915/guc: use

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

2021-06-02 Thread Matthew Brost
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 17/20] drm/i915/guc: Don't receive all G2H messages in irq handler

2021-06-02 Thread Matthew Brost
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 16/20] drm/i915/guc: Stop using mutex while sending CTB messages

2021-06-02 Thread Matthew Brost
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 19/20] drm/i915/guc: Early initialization of GuC send registers

2021-06-02 Thread Matthew Brost
From: Michal Wajdeczko Base offset and count of the GuC scratch registers, used for sending MMIO messages to GuC, can be initialized earlier with other GuC members that also depends on platform. Signed-off-by: Michal Wajdeczko Signed-off-by: Matthew Brost Reviewed-by: Matthew Brost Cc:

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

2021-06-02 Thread Matthew Brost
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 14/20] drm/i915/guc: Start protecting access to CTB descriptors

2021-06-02 Thread Matthew Brost
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 20/20] drm/i915/guc: Use guc_class instead of engine_class in fw interface

2021-06-02 Thread Matthew Brost
From: Daniele Ceraolo Spurio GuC has its own defines for the engine classes. They're currently mapping 1:1 to the defines used by the driver, but there is no guarantee this will continue in the future. Given that we've been caught off-guard in the past by similar divergences, we can prepare for

[Intel-gfx] [PATCH 13/20] drm/i915/guc: Relax CTB response timeout

2021-06-02 Thread Matthew Brost
From: Michal Wajdeczko In upcoming patch we will allow more CTB requests to be sent in parallel to the GuC for processing, 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 11/20] drm/i915/guc: Replace CTB array with explicit members

2021-06-02 Thread Matthew Brost
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 04/20] drm/i915/guc: Remove sample_forcewake h2g action

2021-06-02 Thread Matthew Brost
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 09/20] drm/i915/guc: Only rely on own CTB size

2021-06-02 Thread Matthew Brost
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 03/20] drm/i915/guc: enable only the user interrupt when using GuC submission

2021-06-02 Thread Matthew Brost
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 18/20] drm/i915/guc: Always copy CT message to new allocation

2021-06-02 Thread Matthew Brost
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 10/20] drm/i915/guc: Don't repeat CTB layout calculations

2021-06-02 Thread Matthew Brost
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 15/20] drm/i915/guc: Ensure H2G buffer updates visible before tail update

2021-06-02 Thread Matthew Brost
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. If this barrier is not inserted

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

2021-06-02 Thread Matthew Brost
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 05/20] drm/i915/guc: Keep strict GuC ABI definitions

2021-06-02 Thread Matthew Brost
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/20] drm/i915/guc: skip disabling CTBs before sanitizing the GuC

2021-06-02 Thread Matthew Brost
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/20] GuC CTBs changes + a few misc patches

2021-06-02 Thread Matthew Brost
Single series to merge the following series that have been reviewed / passed CI: https://patchwork.freedesktop.org/series/90633/ https://patchwork.freedesktop.org/series/90552/ Signed-off-by: Matthew Brost Daniele Ceraolo Spurio (4): drm/i915/guc: skip disabling CTBs before sanitizing the GuC

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

2021-06-02 Thread Matthew Brost
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

[Intel-gfx] [PATCH 06/20] drm/i915/guc: Drop guc->interrupts.enabled

2021-06-02 Thread Matthew Brost
Drop the variable guc->interrupts.enabled as this variable is just leading to bugs creeping into the code. e.g. A full GPU reset disables the GuC interrupts but forgot to clear guc->interrupts.enabled, guc->interrupts.enabled being true suppresses interrupts from getting re-enabled and now we are

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

2021-06-02 Thread Daniel Vetter
On Thu, Jun 3, 2021 at 5:48 AM Matthew Brost wrote: > > On Wed, Jun 02, 2021 at 08:57:02PM +0200, Daniel Vetter wrote: > > On Wed, Jun 2, 2021 at 5:27 PM Tvrtko Ursulin > > wrote: > > > On 25/05/2021 17:45, Matthew Brost wrote: > > > > On Tue, May 25, 2021 at 11:32:26AM +0100, Tvrtko Ursulin

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

2021-06-02 Thread Matthew Brost
On Wed, Jun 02, 2021 at 04:27:18PM +0100, Tvrtko Ursulin wrote: > > On 25/05/2021 17:45, Matthew Brost wrote: > > 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

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

2021-06-02 Thread Matthew Brost
On Wed, Jun 02, 2021 at 08:57:02PM +0200, Daniel Vetter wrote: > On Wed, Jun 2, 2021 at 5:27 PM Tvrtko Ursulin > wrote: > > On 25/05/2021 17:45, Matthew Brost wrote: > > > On Tue, May 25, 2021 at 11:32:26AM +0100, Tvrtko Ursulin wrote: > > >> * Context pinning code with it's magical two adds,

Re: [Intel-gfx] [PATCH 00/21] Add Support for Plane Color Lut and CSC features

2021-06-02 Thread Harry Wentland
On 2021-06-02 4:22 p.m., Shankar, Uma wrote: > > >> -Original Message- >> From: Pekka Paalanen >> Sent: Wednesday, June 2, 2021 2:59 PM >> To: Shankar, Uma >> Cc: intel-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org; Modem, >> Bhanuprakash ; Harry Wentland >> >>

Re: [Intel-gfx] [PATCH 1/1] drm/i915: Introduce i915_sched_engine object

2021-06-02 Thread Matthew Brost
On Mon, May 31, 2021 at 10:31:53AM +0200, Daniel Vetter wrote: > On Thu, May 27, 2021 at 4:19 PM Matthew Brost wrote: > > > > On Thu, May 27, 2021 at 10:41:10AM +0100, Tvrtko Ursulin wrote: > > > > > > On 26/05/2021 21:03, Matthew Brost wrote: > > > > Introduce i915_sched_engine object which is

Re: [Intel-gfx] linux-next: manual merge of the amdgpu tree with the drm-misc tree

2021-06-02 Thread Stephen Rothwell
Hi all, On Thu, 3 Jun 2021 12:48:47 +1000 Stephen Rothwell wrote: > > diff --cc drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c > index bcfd4a8d0288,1923f035713a.. > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c > @@@ -657,11 -657,10 +658,11 @@@

[Intel-gfx] linux-next: manual merge of the amdgpu tree with the drm-misc tree

2021-06-02 Thread Stephen Rothwell
Hi all, Today's linux-next merge of the amdgpu tree got conflicts in: drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c between commit: d3116756a710 ("drm/ttm: rename bo->mem and make it a pointer") from the drm-misc tree and commits: b453e42a6e8b

Re: [Intel-gfx] [PATCH v4 06/17] drm/i915/pxp: Implement funcs to create the TEE channel

2021-06-02 Thread Teres Alexis, Alan Previn
On Mon, 2021-05-24 at 22:47 -0700, Daniele Ceraolo Spurio wrote: > From: "Huang, Sean Z" > > Implement the funcs to create the TEE channel, so kernel can > send the TEE commands directly to TEE for creating the arbitrary > (default) session. > > v2: fix locking, don't pollute dev_priv (Chris) >

Re: [Intel-gfx] [PATCH 24/29] drm/i915/gem: Delay context creation

2021-06-02 Thread Jason Ekstrand
On Mon, May 31, 2021 at 4:50 AM Daniel Vetter wrote: > > On Thu, May 27, 2021 at 11:26:45AM -0500, Jason Ekstrand wrote: > > The current context uAPI allows for two methods of setting context > > parameters: SET_CONTEXT_PARAM and CONTEXT_CREATE_EXT_SETPARAM. The > > former is allowed to be

Re: [Intel-gfx] [PATCH 21/29] drm/i915/gem: Use the proto-context to handle create parameters (v2)

2021-06-02 Thread Jason Ekstrand
On Mon, May 31, 2021 at 4:12 AM Daniel Vetter wrote: > > On Thu, May 27, 2021 at 11:26:42AM -0500, Jason Ekstrand wrote: > > This means that the proto-context needs to grow support for engine > > configuration information as well as setparam logic. Fortunately, we'll > > be deleting a lot of

[Intel-gfx] ✓ Fi.CI.IGT: success for Finish conversion to GRAPHICS_VER (rev2)

2021-06-02 Thread Patchwork
== Series Details == Series: Finish conversion to GRAPHICS_VER (rev2) URL : https://patchwork.freedesktop.org/series/90693/ State : success == Summary == CI Bug Log - changes from CI_DRM_10161_full -> Patchwork_20267_full Summary ---

Re: [Intel-gfx] [PATCH 18/29] drm/i915/gem: Optionally set SSEU in intel_context_set_gem

2021-06-02 Thread Jason Ekstrand
On Mon, May 31, 2021 at 3:48 AM Daniel Vetter wrote: > > On Thu, May 27, 2021 at 11:26:39AM -0500, Jason Ekstrand wrote: > > For now this is a no-op because everyone passes in a null SSEU but it > > lets us get some of the error handling and selftest refactoring plumbed > > through. > > > >

Re: [Intel-gfx] [PATCH 16/27] drm/i915/gem: Add an intermediate proto_context struct

2021-06-02 Thread Jason Ekstrand
On Tue, May 4, 2021 at 11:13 AM Daniel Vetter wrote: > > On Mon, May 03, 2021 at 10:57:37AM -0500, Jason Ekstrand wrote: > > The current context uAPI allows for two methods of setting context > > parameters: SET_CONTEXT_PARAM and CONTEXT_CREATE_EXT_SETPARAM. The > > former is allowed to be

[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915: Get rid of fence error propagation

2021-06-02 Thread Patchwork
== Series Details == Series: drm/i915: Get rid of fence error propagation URL : https://patchwork.freedesktop.org/series/90891/ State : failure == Summary == CI Bug Log - changes from CI_DRM_10161_full -> Patchwork_20265_full Summary

Re: [Intel-gfx] [PATCH 16/29] drm/i915/gem: Add an intermediate proto_context struct

2021-06-02 Thread Jason Ekstrand
On Mon, May 31, 2021 at 3:47 AM Daniel Vetter wrote: > > On Thu, May 27, 2021 at 11:26:37AM -0500, Jason Ekstrand wrote: > > The current context uAPI allows for two methods of setting context > > parameters: SET_CONTEXT_PARAM and CONTEXT_CREATE_EXT_SETPARAM. The > > former is allowed to be

Re: [Intel-gfx] [PATCH 01/21] drm: Add Enhanced Gamma and color lut range attributes

2021-06-02 Thread Shankar, Uma
> -Original Message- > From: Pekka Paalanen > Sent: Wednesday, June 2, 2021 3:04 PM > To: Shankar, Uma > Cc: intel-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org; Modem, > Bhanuprakash > Subject: Re: [PATCH 01/21] drm: Add Enhanced Gamma and color lut range > attributes >

Re: [Intel-gfx] [PATCH 00/21] Add Support for Plane Color Lut and CSC features

2021-06-02 Thread Shankar, Uma
> -Original Message- > From: Pekka Paalanen > Sent: Wednesday, June 2, 2021 2:59 PM > To: Shankar, Uma > Cc: intel-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org; Modem, > Bhanuprakash ; Harry Wentland > > Subject: Re: [PATCH 00/21] Add Support for Plane Color Lut and CSC

Re: [Intel-gfx] [PATCH 1/9] drm: Add gamma mode property

2021-06-02 Thread Shankar, Uma
> -Original Message- > From: Pekka Paalanen > Sent: Wednesday, June 2, 2021 2:40 PM > To: Shankar, Uma > Cc: intel-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org; Modem, > Bhanuprakash > Subject: Re: [PATCH 1/9] drm: Add gamma mode property > > On Tue, 1 Jun 2021

Re: [Intel-gfx] [PATCH 5/9] drm: Add Client Cap for advance gamma mode

2021-06-02 Thread Shankar, Uma
> -Original Message- > From: Pekka Paalanen > Sent: Wednesday, June 2, 2021 2:33 PM > To: Shankar, Uma > Cc: intel-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org; Modem, > Bhanuprakash > Subject: Re: [PATCH 5/9] drm: Add Client Cap for advance gamma mode > > On Tue, 1

[Intel-gfx] ✓ Fi.CI.BAT: success for Finish conversion to GRAPHICS_VER (rev2)

2021-06-02 Thread Patchwork
== Series Details == Series: Finish conversion to GRAPHICS_VER (rev2) URL : https://patchwork.freedesktop.org/series/90693/ State : success == Summary == CI Bug Log - changes from CI_DRM_10161 -> Patchwork_20267 Summary ---

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for Finish conversion to GRAPHICS_VER (rev2)

2021-06-02 Thread Patchwork
== Series Details == Series: Finish conversion to GRAPHICS_VER (rev2) URL : https://patchwork.freedesktop.org/series/90693/ 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 Finish conversion to GRAPHICS_VER (rev2)

2021-06-02 Thread Patchwork
== Series Details == Series: Finish conversion to GRAPHICS_VER (rev2) URL : https://patchwork.freedesktop.org/series/90693/ State : warning == Summary == $ dim checkpatch origin/drm-tip 6ec9c3d188bc drm/i915/gt: replace IS_GEN and friends with GRAPHICS_VER -:2330: WARNING:LONG_LINE: line

[Intel-gfx] [PATCH v2 5/7] drm/i915: replace IS_GEN and friends with GRAPHICS_VER

2021-06-02 Thread Lucas De Marchi
This was done by the following semantic patch: @@ expression i915; @@ - INTEL_GEN(i915) + GRAPHICS_VER(i915) @@ expression i915; expression E; @@ - INTEL_GEN(i915) >= E + GRAPHICS_VER(i915) >= E @@ expression dev_priv; expression E; @@

[Intel-gfx] [PATCH v2 3/7] drm/i915/gem: replace IS_GEN and friends with GRAPHICS_VER

2021-06-02 Thread Lucas De Marchi
This was done by the following semantic patch: @@ expression i915; @@ - INTEL_GEN(i915) + GRAPHICS_VER(i915) @@ expression i915; expression E; @@ - INTEL_GEN(i915) >= E + GRAPHICS_VER(i915) >= E @@ expression dev_priv; expression E; @@

[Intel-gfx] [PATCH v2 7/7] drm/i915/display: replace IS_GEN() in commented code

2021-06-02 Thread Lucas De Marchi
Since we are replacing IS_GEN() with GRAPHICS_VER(), make sure we take care of the comments as well. Signed-off-by: Lucas De Marchi Reviewed-by: Matt Roper --- drivers/gpu/drm/i915/display/intel_tv.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git

[Intel-gfx] [PATCH v2 4/7] drm/i915/gvt: replace IS_GEN and friends with GRAPHICS_VER

2021-06-02 Thread Lucas De Marchi
This was done by the following semantic patch: @@ expression i915; @@ - INTEL_GEN(i915) + GRAPHICS_VER(i915) @@ expression i915; expression E; @@ - INTEL_GEN(i915) >= E + GRAPHICS_VER(i915) >= E @@ expression dev_priv; expression E; @@

[Intel-gfx] [PATCH v2 0/7] Finish conversion to GRAPHICS_VER

2021-06-02 Thread Lucas De Marchi
Latest version of previous series "drm/i915: Extend GEN renames to the rest of the driver" (https://patchwork.freedesktop.org/series/88825/) dropped one patch converting all the instances of IS_GEN() and INTEL_GEN() to GRAPHICS_VER() due to the patches changing the meaning of the macros

[Intel-gfx] [PATCH v2 6/7] drm/i915: Add remaining conversions to GRAPHICS_VER

2021-06-02 Thread Lucas De Marchi
For some reason coccinelle misses a few cases in header files with calls to INTEL_GEN()/IS_GEN(). Do a manual conversion for those. Signed-off-by: Lucas De Marchi Reviewed-by: Matt Roper --- drivers/gpu/drm/i915/i915_drv.h | 35 - drivers/gpu/drm/i915/i915_reg.h

[Intel-gfx] [PATCH v2 2/7] drm/i915/gt: Add remaining conversions to GRAPHICS_VER

2021-06-02 Thread Lucas De Marchi
For some reason coccinelle misses a few cases in gt with calls to INTEL_GEN()/IS_GEN(). Do a manual conversion for those. Signed-off-by: Lucas De Marchi Reviewed-by: Matt Roper --- drivers/gpu/drm/i915/gt/debugfs_gt_pm.c | 2 +- drivers/gpu/drm/i915/gt/intel_engine_types.h | 4 ++--

[Intel-gfx] [PATCH v2 1/7] drm/i915/gt: replace IS_GEN and friends with GRAPHICS_VER

2021-06-02 Thread Lucas De Marchi
This was done by the following semantic patch: @@ expression i915; @@ - INTEL_GEN(i915) + GRAPHICS_VER(i915) @@ expression i915; expression E; @@ - INTEL_GEN(i915) >= E + GRAPHICS_VER(i915) >= E @@ expression dev_priv; expression E; @@

Re: [Intel-gfx] [PATCH v4 02/17] mei: pxp: export pavp client to me client bus

2021-06-02 Thread Rodrigo Vivi
On Mon, May 24, 2021 at 10:47:48PM -0700, Daniele Ceraolo Spurio wrote: > From: Vitaly Lubart > > Export PAVP client to work with i915 driver, > for binding it uses kernel component framework. > > Signed-off-by: Vitaly Lubart > Signed-off-by: Tomas Winkler > Signed-off-by: Daniele Ceraolo

Re: [Intel-gfx] [PATCH v4 16/17] drm/i915/pxp: black pixels on pxp disabled

2021-06-02 Thread Rodrigo Vivi
On Mon, May 24, 2021 at 10:48:02PM -0700, Daniele Ceraolo Spurio wrote: > From: Anshuman Gupta > > When protected sufaces has flipped and pxp session is disabled, > display black pixels by using plane color CTM correction. > > v2: > - Display black pixels in async flip too. > > v3: > - Removed

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

2021-06-02 Thread Daniel Vetter
On Wed, Jun 2, 2021 at 5:27 PM Tvrtko Ursulin wrote: > On 25/05/2021 17:45, Matthew Brost wrote: > > On Tue, May 25, 2021 at 11:32:26AM +0100, Tvrtko Ursulin wrote: > >> * Context pinning code with it's magical two adds, subtract and cmpxchg > >> is > >> dodgy as well. > > > > Daniele tried to

Re: [Intel-gfx] [PATCH 03/11] drm/panfrost: Use xarray and helpers for depedency tracking

2021-06-02 Thread Daniel Vetter
On Wed, Jun 02, 2021 at 03:06:50PM +0100, Steven Price wrote: > On 21/05/2021 10:09, Daniel Vetter wrote: > > More consistency and prep work for the next patch. > > > > Aside: I wonder whether we shouldn't just move this entire xarray > > business into the scheduler so that not everyone has to

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/gem/mman: only allow WC for lmem

2021-06-02 Thread Patchwork
== Series Details == Series: drm/i915/gem/mman: only allow WC for lmem URL : https://patchwork.freedesktop.org/series/90875/ State : success == Summary == CI Bug Log - changes from CI_DRM_10159_full -> Patchwork_20263_full Summary ---

Re: [Intel-gfx] Merging TTM branches through the Intel tree?

2021-06-02 Thread Daniel Vetter
On Wed, Jun 02, 2021 at 11:48:41AM +0200, Christian König wrote: > Am 02.06.21 um 11:16 schrieb Thomas Hellström (Intel): > > > > On 6/2/21 10:32 AM, Christian König wrote: > > > Uff I'm just waiting for feedback from Philip to merge a large patch > > > set for TTM through drm-misc-next. > > > >

Re: [Intel-gfx] [PATCH v4 15/17] drm/i915/pxp: Add plane decryption support

2021-06-02 Thread Rodrigo Vivi
On Mon, May 24, 2021 at 10:48:01PM -0700, Daniele Ceraolo Spurio wrote: > From: Anshuman Gupta > > Add support to enable/disable PLANE_SURF Decryption Request bit. > It requires only to enable plane decryption support when following > condition met. > 1. PXP session is enabled. > 2. Buffer

Re: [Intel-gfx] [PATCH v4 04/17] drm/i915/gt: Export the pinned context constructor and destructor

2021-06-02 Thread Rodrigo Vivi
On Tue, Jun 01, 2021 at 02:23:00PM -0700, Daniele Ceraolo Spurio wrote: > > > On 6/1/2021 1:20 PM, Rodrigo Vivi wrote: > > On Mon, May 24, 2021 at 10:47:50PM -0700, Daniele Ceraolo Spurio wrote: > > > From: Chris Wilson > > > > > > Allow internal clients to create a pinned context. > > > > >

Re: [Intel-gfx] [PATCH v4 12/17] drm/i915/pxp: start the arb session on demand

2021-06-02 Thread Rodrigo Vivi
On Mon, May 24, 2021 at 10:47:58PM -0700, Daniele Ceraolo Spurio wrote: > Now that we can handle destruction and re-creation of the arb session, > we can postpone the start of the session to the first submission that > requires it, to avoid keeping it running with no user. > > Signed-off-by:

[Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [v2,1/2] drm/i915/display: Introduce new intel_psr_pause/resume function (rev2)

2021-06-02 Thread Patchwork
== Series Details == Series: series starting with [v2,1/2] drm/i915/display: Introduce new intel_psr_pause/resume function (rev2) URL : https://patchwork.freedesktop.org/series/90830/ State : success == Summary == CI Bug Log - changes from CI_DRM_10159_full -> Patchwork_20262_full

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Get rid of fence error propagation

2021-06-02 Thread Patchwork
== Series Details == Series: drm/i915: Get rid of fence error propagation URL : https://patchwork.freedesktop.org/series/90891/ State : success == Summary == CI Bug Log - changes from CI_DRM_10161 -> Patchwork_20265 Summary ---

[Intel-gfx] ✗ Fi.CI.BUILD: failure for drm/i915: Move system memory to TTM for discrete

2021-06-02 Thread Patchwork
== Series Details == Series: drm/i915: Move system memory to TTM for discrete URL : https://patchwork.freedesktop.org/series/90898/ State : failure == Summary == Applying: drm/i915: Update object placement flags to be mutable Using index info to reconstruct a base tree... M

Re: [Intel-gfx] [PATCH v9 07/15] drm: Add a prefetching memcpy_from_wc

2021-06-02 Thread Thomas Hellström
On 6/1/21 2:27 PM, Jani Nikula wrote: On Tue, 01 Jun 2021, Thomas Hellström wrote: Reading out of write-combining mapped memory is typically very slow since the CPU doesn't prefetch. However some archs have special instructions to do this. So add a best-effort memcpy_from_wc taking

[Intel-gfx] [PATCH 5/5] drm/i915/ttm: Implement object migration

2021-06-02 Thread Thomas Hellström
Implement object migration, needed primarily for dma-buf exports of objects currently residing in LMEM, until we land p2pdma. There are no users yet of this code. Signed-off-by: Thomas Hellström --- drivers/gpu/drm/i915/gem/i915_gem_object.c| 100 ++

[Intel-gfx] [PATCH 2/5] drm/i915/ttm: Adjust gem flags and caching settings after a move

2021-06-02 Thread Thomas Hellström
After a TTM move we need to update the i915 gem flags and caching settings to reflect the new placement. Also introduce gpu_binds_iomem() and cpu_maps_iomem() to clean up the various ways we previously used to detect this. Finally, initialize the TTM object reserved to be able to update flags and

[Intel-gfx] [PATCH 4/5] drm/i915/ttm: Use TTM for system memory

2021-06-02 Thread Thomas Hellström
For discrete, use TTM for both cached and WC system memory. That means we currently rely on the TTM memory accounting / shrinker. For cached system memory we should consider remaining shmem-backed, which can be implemented from our ttm_tt_populate calback. We can then also reuse our own very

[Intel-gfx] [PATCH 0/5] drm/i915: Move system memory to TTM for discrete

2021-06-02 Thread Thomas Hellström
Early implementation of moving system memory for discrete cards over to TTM. We first add the notion of objects being migratable under the object lock to i915 gem, and add some asserts to verify that objects are either locked or pinned when the placement is checked by the gem code. Patch 2 and 3

[Intel-gfx] [PATCH 3/5] drm/i915/ttm: Calculate the object placement at get_pages time

2021-06-02 Thread Thomas Hellström
Instead of relying on a static placement, calculate at get_pages() time. This should work for LMEM regions and system for now. For stolen we need to take preallocated range into account. That well be added later. Signed-off-by: Thomas Hellström --- drivers/gpu/drm/i915/gem/i915_gem_ttm.c | 92

[Intel-gfx] [PATCH 1/5] drm/i915: Update object placement flags to be mutable

2021-06-02 Thread Thomas Hellström
The object ops i915_GEM_OBJECT_HAS_IOMEM and the object I915_BO_ALLOC_STRUCT_PAGE flags are considered immutable by much of our code. Introduce a new mem_flags member to hold these and make sure checks for these flags being set are either done under the object lock or with pages properly pinned.

[Intel-gfx] ✗ Fi.CI.DOCS: warning for drm/i915: Get rid of fence error propagation

2021-06-02 Thread Patchwork
== Series Details == Series: drm/i915: Get rid of fence error propagation URL : https://patchwork.freedesktop.org/series/90891/ State : warning == Summary == $ make htmldocs 2>&1 > /dev/null | grep i915 ./drivers/gpu/drm/i915/i915_cmd_parser.c:1436: warning: Excess function parameter

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915: Get rid of fence error propagation

2021-06-02 Thread Patchwork
== Series Details == Series: drm/i915: Get rid of fence error propagation URL : https://patchwork.freedesktop.org/series/90891/ 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.IGT: success for Move LMEM (VRAM) management over to TTM (rev6)

2021-06-02 Thread Patchwork
== Series Details == Series: Move LMEM (VRAM) management over to TTM (rev6) URL : https://patchwork.freedesktop.org/series/90681/ State : success == Summary == CI Bug Log - changes from CI_DRM_10159_full -> Patchwork_20261_full Summary

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915: Get rid of fence error propagation

2021-06-02 Thread Patchwork
== Series Details == Series: drm/i915: Get rid of fence error propagation URL : https://patchwork.freedesktop.org/series/90891/ State : warning == Summary == $ dim checkpatch origin/drm-tip 18e3ff57e304 drm/i915: Revert "drm/i915/gem: Asynchronous cmdparser" -:6: ERROR:GIT_COMMIT_ID: Please

[Intel-gfx] [PATCH 5/5] Revert "drm/i915: Skip over MI_NOOP when parsing"

2021-06-02 Thread Jason Ekstrand
This reverts a6c5e2aea704 ("drm/i915: Skip over MI_NOOP when parsing"). It complicates the batch parsing code a bit and increases indentation for no reason other than fast-skipping a command that userspace uses only rarely. Sure, there may be IGT tests that fill batches with NOOPs but that's not

[Intel-gfx] [PATCH 4/5] Revert "drm/i915: Propagate errors on awaiting already signaled fences"

2021-06-02 Thread Jason Ekstrand
This reverts commit 9e31c1fe45d555a948ff66f1f0e3fe1f83ca63f7. Ever since that commit, we've been having issues where a hang in one client can propagate to another. In particular, a hang in an app can propagate to the X server which causes the whole desktop to lock up. Signed-off-by: Jason

[Intel-gfx] [PATCH 3/5] drm/i915: Drop error handling from dma_fence_work

2021-06-02 Thread Jason Ekstrand
Signed-off-by: Jason Ekstrand Reviewed-by: Jon Bloomfield --- drivers/gpu/drm/i915/gem/i915_gem_clflush.c | 4 +--- drivers/gpu/drm/i915/i915_sw_fence_work.c | 5 + drivers/gpu/drm/i915/i915_sw_fence_work.h | 2 +- drivers/gpu/drm/i915/i915_vma.c | 3 +-- 4 files changed, 4

[Intel-gfx] [PATCH 2/5] drm/i915: Remove allow_alloc from i915_gem_object_get_sg*

2021-06-02 Thread Jason Ekstrand
This reverts the rest of 0edbb9ba1bfe ("drm/i915: Move cmd parser pinning to execbuffer"). Now that the only user of i915_gem_object_get_sg without allow_alloc has been removed, we can drop the parameter. This portion of the revert was broken into its own patch to aid review. Signed-off-by:

[Intel-gfx] [PATCH 1/5] drm/i915: Revert "drm/i915/gem: Asynchronous cmdparser"

2021-06-02 Thread Jason Ekstrand
This reverts 686c7c35abc2 ("drm/i915/gem: Asynchronous cmdparser"). The justification for this commit in the git history was a vague comment about getting it out from under the struct_mutex. While this may improve perf for some workloads on Gen7 platforms where we rely on the command parser for

[Intel-gfx] [PATCH 0/5] drm/i915: Get rid of fence error propagation

2021-06-02 Thread Jason Ekstrand
Fence error propagation is sketchy at best. Instead of explicitly handling fences which might have errors set in the code which is aware of errors, we just kick them down the line and hope that userspace knows what to do when a wait eventually fails. This is sketchy at best because most

Re: [Intel-gfx] [PATCH v4 1/1] drm/i915/dg1: Add HWMON power sensor support

2021-06-02 Thread Sundaresan, Sujaritha
On 6/1/2021 5:42 PM, Dale B Stimson wrote: On 2021-06-01 14:39:11, Sundaresan, Sujaritha wrote: Date: Tue, 1 Jun 2021 14:39:11 -0700 From: "Sundaresan, Sujaritha" To: Dale B Stimson , intel-gfx@lists.freedesktop.org, dri-de...@lists.freedesktop.org CC: Jon Ewins , Jani Nikula Subject:

Re: [Intel-gfx] [PATCH] Revert "i915: use io_mapping_map_user"

2021-06-02 Thread Daniel Vetter
Adding Jani and Rodrigo since drm-intel-fixes is on them. -Daniel On Wed, Jun 2, 2021 at 12:10 PM Matthew Auld wrote: > > On Wed, 2 Jun 2021 at 09:01, Daniel Vetter wrote: > > > > On Wed, Jun 2, 2021 at 9:28 AM Matthew Auld > > wrote: > > > > > > On Thu, 27 May 2021 at 19:52, Matthew Auld

Re: [Intel-gfx] [PATCH v4 13/17] drm/i915/pxp: Enable PXP power management

2021-06-02 Thread Rodrigo Vivi
On Mon, May 24, 2021 at 10:47:59PM -0700, Daniele Ceraolo Spurio wrote: > From: "Huang, Sean Z" > > During the power event S3+ sleep/resume, hardware will lose all the > encryption keys for every hardware session, even though the > session state might still be marked as alive after resume.

Re: [Intel-gfx] [PATCH v4 10/17] drm/i915/pxp: Implement PXP irq handler

2021-06-02 Thread Rodrigo Vivi
On Mon, May 24, 2021 at 10:47:56PM -0700, Daniele Ceraolo Spurio wrote: > From: "Huang, Sean Z" > > The HW will generate a teardown interrupt when session termination is > required, which requires i915 to submit a terminating batch. Once the HW > is done with the termination it will generate

Re: [Intel-gfx] [PATCH v4 10/17] drm/i915/pxp: Implement PXP irq handler

2021-06-02 Thread Rodrigo Vivi
On Mon, May 24, 2021 at 10:47:56PM -0700, Daniele Ceraolo Spurio wrote: > From: "Huang, Sean Z" > > The HW will generate a teardown interrupt when session termination is > required, which requires i915 to submit a terminating batch. Once the HW > is done with the termination it will generate

Re: [Intel-gfx] [PATCH 1/7] drm/i915/gt: replace IS_GEN and friends with IS_GRAPHICS_VER

2021-06-02 Thread Matt Roper
On Tue, Jun 01, 2021 at 11:34:39PM -0700, Lucas De Marchi wrote: > On Tue, Jun 01, 2021 at 01:39:25PM -0700, Matt Roper wrote: > > On Tue, Jun 01, 2021 at 12:13:17PM -0700, Lucas De Marchi wrote: > > > On Tue, Jun 01, 2021 at 10:30:55AM -0700, Matt Roper wrote: > > > > On Tue, Jun 01, 2021 at

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

2021-06-02 Thread Tvrtko Ursulin
On 25/05/2021 17:45, Matthew Brost wrote: 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

Re: [Intel-gfx] [RFC PATCH 65/97] drm/i915: Reset GPU immediately if submission is disabled

2021-06-02 Thread Tvrtko Ursulin
On 06/05/2021 20:14, Matthew Brost wrote: If submission is disabled by the backend for any reason, reset the GPU immediately in the heartbeat code. Okay that's what, but why is also often good to have in commit messages. Regards, Tvrtko Signed-off-by: Matthew Brost ---

Re: [Intel-gfx] [RFC PATCH 64/97] drm/i915/guc: Reset implementation for new GuC interface

2021-06-02 Thread Tvrtko Ursulin
On 06/05/2021 20:14, Matthew Brost wrote: Reset implementation for new GuC interface. This is the legacy reset implementation which is called when the i915 owns the engine hang check. Future patches will offload the engine hang check to GuC but we will continue to maintain this legacy path as

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: Only set bind_async_flags when concurrent access wa is not active, v3. (rev3)

2021-06-02 Thread Patchwork
== Series Details == Series: drm/i915: Only set bind_async_flags when concurrent access wa is not active, v3. (rev3) URL : https://patchwork.freedesktop.org/series/90818/ State : failure == Summary == CI Bug Log - changes from CI_DRM_10160 -> Patchwork_20264

Re: [Intel-gfx] [PATCH 03/11] drm/panfrost: Use xarray and helpers for depedency tracking

2021-06-02 Thread Steven Price
On 21/05/2021 10:09, Daniel Vetter wrote: > More consistency and prep work for the next patch. > > Aside: I wonder whether we shouldn't just move this entire xarray > business into the scheduler so that not everyone has to reinvent the > same wheels. Cc'ing some scheduler people for this too. >

Re: [Intel-gfx] [PATCH 2/3] drm/i915: Fix incorrect assert about pending power domain async-put work

2021-06-02 Thread Imre Deak
On Wed, Jun 02, 2021 at 02:35:28PM +0530, Anshuman Gupta wrote: > On 2021-05-26 at 20:07:28 +0530, Imre Deak wrote: > > It's possible that an already dequeued put_async_work() will release the > > reference (*) that was put asynchronously after the dequeue happened. > > This leaves an async-put

Re: [Intel-gfx] Merging TTM branches through the Intel tree?

2021-06-02 Thread Christian König
Am 02.06.21 um 11:16 schrieb Thomas Hellström (Intel): On 6/2/21 10:32 AM, Christian König wrote: Uff I'm just waiting for feedback from Philip to merge a large patch set for TTM through drm-misc-next. I'm pretty sure we will run into merge conflicts if you try to push your changes through

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915: Only set bind_async_flags when concurrent access wa is not active, v3. (rev3)

2021-06-02 Thread Patchwork
== Series Details == Series: drm/i915: Only set bind_async_flags when concurrent access wa is not active, v3. (rev3) URL : https://patchwork.freedesktop.org/series/90818/ State : warning == Summary == $ dim checkpatch origin/drm-tip 056e7f6133a9 drm/i915: Only set bind_async_flags when

Re: [Intel-gfx] [RFC PATCH 63/97] drm/i915/guc: Direct all breadcrumbs for a class to single breadcrumbs

2021-06-02 Thread Tvrtko Ursulin
On 06/05/2021 20:14, Matthew Brost wrote: With GuC virtual engines the physical engine which a request executes and completes on isn't known to the i915. Therefore we can't attach a request to a physical engines breadcrumbs. To work around this we create a single breadcrumbs per engine class

[Intel-gfx] [PATCH v2 1/1] drm/i915/xelpd: Enabling dithering after the CC1

2021-06-02 Thread Nischal Varide
If the panel is 12bpc then Dithering is not enabled in the Legacy dithering block , instead its Enabled after the C1 CC1 pipe post color space conversion.For a 6bpc pannel Dithering is enabled in Legacy block. Signed-off-by: Nischal Varide --- drivers/gpu/drm/i915/display/intel_color.c | 7

[Intel-gfx] [PATCH v2 0/1] Enabling dithering after the CC1

2021-06-02 Thread Nischal Varide
If the panel is 12bpc then Dithering is not enabled in the Legacy dithering block , instead its Enabled after the C1 CC1 pipe post color space conversion.For a 6bpc pannel Dithering is enabled in Legacy block. This is Version 2 of the patch, after addresing few review comments. Nischal Varide

  1   2   >