Re: [Intel-gfx] [PATCH 11/24] drm/i915/icl: Get DDI clock for ICL based on PLLs.

On Tue, May 22, 2018 at 02:44:43PM +0300, Mika Kahola wrote: > On Mon, 2018-05-21 at 17:25 -0700, Paulo Zanoni wrote: > > From: Manasi Navare > > > > PLLs are the source clocks for the DDIs so in order > > to determine the ddi clock we need to check the PLL > >

Re: [Intel-gfx] [PATCH] drm/i915/psr : Add psr1 live status

On 5/23/2018 1:28 AM, Dhinakaran Pandiyan wrote: On Tue, 2018-05-22 at 14:27 +0530, vathsala nagaraju wrote: From: Vathsala Nagaraju Prints live state of psr1.Extending the existing PSR2 live state function to cover psr1. Tested on KBL with psr2 and psr1 panel.

Re: [Intel-gfx] [PATCH v4 1/2] vfio/mdev: Check globally for duplicate devices

On 2018.05.22 09:53:37 -0600, Alex Williamson wrote: > [Cc +GVT-g maintainers/lists] > > On Tue, 22 May 2018 10:13:46 +0200 > Cornelia Huck wrote: > > > On Fri, 18 May 2018 13:10:25 -0600 > > Alex Williamson wrote: > > > > > When we create an

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/psr: vbt change for psr (rev10)

== Series Details == Series: drm/i915/psr: vbt change for psr (rev10) URL : https://patchwork.freedesktop.org/series/41289/ State : failure == Summary == = CI Bug Log - changes from CI_DRM_4222 -> Patchwork_9090 = == Summary - FAILURE == Serious unknown changes coming with Patchwork_9090

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915/psr: vbt change for psr (rev10)

== Series Details == Series: drm/i915/psr: vbt change for psr (rev10) URL : https://patchwork.freedesktop.org/series/41289/ State : warning == Summary == $ dim checkpatch origin/drm-tip 46c7737a0d9a drm/i915/psr: vbt change for psr -:85: CHECK:SPACING: spaces preferred around that '<<'

[Intel-gfx] [PATCH] drm/i915/psr: vbt change for psr

From: Vathsala Nagaraju For psr block #9, the vbt description has moved to options [0-3] for TP1,TP2,TP3 Wakeup time from decimal value without any change to vbt structure. Since spec does not mention from which VBT version this change was added to vbt.bsf file, we

[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915: per context slice/subslice powergating (rev5)

== Series Details == Series: drm/i915: per context slice/subslice powergating (rev5) URL : https://patchwork.freedesktop.org/series/42285/ State : failure == Summary == = CI Bug Log - changes from CI_DRM_4221_full -> Patchwork_9089_full = == Summary - FAILURE == Serious unknown changes

Re: [Intel-gfx] [PATCH] drm/i915: Special case kernel_context switch request

Quoting Mika Kuoppala (2018-05-22 13:49:24) > From: Mika Kuoppala > > When checking if engine is idling on a kernel context, > the last request emitted to it could have been the exact > request to switch into kernel context. > > Do not bail out early even if engine has

Re: [Intel-gfx] [PATCH v3 6/7] drm/i915/psr/bdw+: Enable CRC check in the static frame on the sink side

On Thu, 2018-05-17 at 15:21 -0700, José Roberto de Souza wrote: > Sink can be configured to calculate the CRC over the static frame and > compare with the CRC calculated and transmited in the VSC SDP by > source, if there is a mismatch sink will do a short pulse in HPD > and set

Re: [Intel-gfx] [PATCH v3 4/7] drm/i915/psr: Begin to handle PSR/PSR2 errors set by sink

On Thu, 2018-05-17 at 15:21 -0700, José Roberto de Souza wrote: > eDP spec states that sink device will do a short pulse in HPD > line when there is a PSR/PSR2 error that needs to be handled by > source, this is handling the first and most simples error: > DP_PSR_SINK_INTERNAL_ERROR. > > Here

Re: [Intel-gfx] [PATCH 1/2] drm/dp: Add DP_DPCD_REV_XX to drm_dp_helper

On Fri, May 04, 2018 at 03:17:59PM -0700, matthew.s.atw...@intel.com wrote: > From: Matt Atwood > > As more differentation occurs between DP spec. Its useful to have these > as macros in a drm_dp_helper. > > v2: DPCD_REV_XX to DP_DPCD_REV_XX > > Signed-off-by: Matt

Re: [Intel-gfx] [PATCH v4 38/41] drm/i915: Implement the HDCP2.2 support for DP

Hi Ramalingam, Thank you for the patch! Perhaps something to improve: [auto build test WARNING on drm-intel/for-linux-next] [also build test WARNING on next-20180517] [cannot apply to v4.17-rc6] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system]

Re: [Intel-gfx] [PATCH v3 3/7] drm/i915/psr: Remove intel_crtc_state parameter from disable()

On Thu, 2018-05-17 at 15:21 -0700, José Roberto de Souza wrote: > It was only used in VLV/CHV so after the removal of the PSR support > for those platforms it is not necessary any more. Right, Reviewed-by: Dhinakaran Pandiyan > > Cc: Dhinakaran Pandiyan

Re: [Intel-gfx] [PATCH v4 38/41] drm/i915: Implement the HDCP2.2 support for DP

Hi Ramalingam, Thank you for the patch! Yet something to improve: [auto build test ERROR on drm-intel/for-linux-next] [also build test ERROR on next-20180517] [cannot apply to v4.17-rc6] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url:

Re: [Intel-gfx] [PATCH 6/6] drm/i915/psr: Fix ALPM cap check for PSR2

On Tue, 2018-05-22 at 07:37 -0700, Tarun Vyas wrote: > On Fri, May 11, 2018 at 12:51:45PM -0700, Dhinakaran Pandiyan wrote: > > > > While touching the code around this, I noticed that absence of ALPM > > capability does not stop us from enabling PSR2. But, the spec > > unambiguously states that

Re: [Intel-gfx] [PATCH] drm/i915/query: nospec expects no more than an unsigned long

Quoting Lionel Landwerlin (2018-05-22 13:22:32) > On 22/05/18 13:10, Chris Wilson wrote: > > nospec quite reasonably asserts that it will never be used with an index > > larger than unsigned long (that being the largest possibly index into an > > C array). However, our ubi uses the convention of

Re: [Intel-gfx] [PATCH] drm/i915/psr : Add psr1 live status

On Tue, 2018-05-22 at 14:27 +0530, vathsala nagaraju wrote: > From: Vathsala Nagaraju > > Prints live state of psr1.Extending the existing > PSR2 live state function to cover psr1. > > Tested on KBL with psr2 and psr1 panel. > > v2: rebase > v3: DK > Rename

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: per context slice/subslice powergating (rev5)

== Series Details == Series: drm/i915: per context slice/subslice powergating (rev5) URL : https://patchwork.freedesktop.org/series/42285/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4221 -> Patchwork_9089 = == Summary - WARNING == Minor unknown changes coming with

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915: per context slice/subslice powergating (rev5)

== Series Details == Series: drm/i915: per context slice/subslice powergating (rev5) URL : https://patchwork.freedesktop.org/series/42285/ State : warning == Summary == $ dim sparse origin/drm-tip Commit: drm/i915: Program RPCS for Broadwell Okay! Commit: drm/i915: Record the sseu

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915: per context slice/subslice powergating (rev5)

== Series Details == Series: drm/i915: per context slice/subslice powergating (rev5) URL : https://patchwork.freedesktop.org/series/42285/ State : warning == Summary == $ dim checkpatch origin/drm-tip 377ebb5122c5 drm/i915: Program RPCS for Broadwell f8abc1461d28 drm/i915: Record the sseu

[Intel-gfx] ✓ Fi.CI.IGT: success for Per-context and per-client engine busyness (rev6)

== Series Details == Series: Per-context and per-client engine busyness (rev6) URL : https://patchwork.freedesktop.org/series/32645/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4220_full -> Patchwork_9081_full = == Summary - WARNING == Minor unknown changes coming

[Intel-gfx] [PATCH v6 2/7] drm/i915: Record the sseu configuration per-context & engine

From: Chris Wilson We want to expose the ability to reconfigure the slices, subslice and eu per context and per engine. To facilitate that, store the current configuration on the context for each engine, which is initially set to the device default upon creation. v2:

[Intel-gfx] [PATCH v6 5/7] drm/i915/perf: lock powergating configuration to default when active

If some of the contexts submitting workloads to the GPU have been configured to shutdown slices/subslices, we might loose the NOA configurations written in the NOA muxes. One possible solution to this problem is to reprogram the NOA muxes when we switch to a new context. We initially tried this

[Intel-gfx] [PATCH v6 4/7] drm/i915/perf: reuse intel_lrc ctx regs macro

Abstract the context image access a bit. Signed-off-by: Lionel Landwerlin --- drivers/gpu/drm/i915/i915_perf.c | 34 +++- 1 file changed, 16 insertions(+), 18 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_perf.c

[Intel-gfx] [PATCH v6 3/7] drm/i915/perf: simplify configure all context function

We don't need any special treatment on error so just return as soon as possible. Signed-off-by: Lionel Landwerlin --- drivers/gpu/drm/i915/i915_perf.c | 11 --- 1 file changed, 4 insertions(+), 7 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_perf.c

[Intel-gfx] [PATCH v6 1/7] drm/i915: Program RPCS for Broadwell

From: Chris Wilson Currently we only configure the power gating for Skylake and above, but the configuration should equally apply to Broadwell and Braswell. Even though, there is not as much variation as for later generations, we want to expose control over the

[Intel-gfx] [PATCH v6 0/7] drm/i915: per context slice/subslice powergating

Hi all, This iteration adds a couple of things that were missing in v5 : - Synchronize requests on the last powergating change request - Add a new sysfs entry "gem_allow_sseu" to let normal users set their sseu configuration. It's disabled by default for normal users. Cheers,

[Intel-gfx] [PATCH v6 7/7] drm/i915: add a sysfs entry to let users set sseu configs

There are concerns about denial of service around the per context sseu configuration capability. In a previous commit introducing the capability we allowed it only for capable users. This changes adds a new debugfs entry to let any user configure its own context powergating setup. Signed-off-by:

[Intel-gfx] [PATCH v6 6/7] drm/i915: Expose RPCS (SSEU) configuration to userspace

From: Chris Wilson We want to allow userspace to reconfigure the subslice configuration for its own use case. To do so, we expose a context parameter to allow adjustment of the RPCS register stored within the context image (and currently not accessible via LRI). If the

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/query: nospec expects no more than an unsigned long

== Series Details == Series: drm/i915/query: nospec expects no more than an unsigned long URL : https://patchwork.freedesktop.org/series/43569/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4220_full -> Patchwork_9080_full = == Summary - WARNING == Minor unknown changes

Re: [Intel-gfx] [PATCH] drm/i915: Prepare GEM for suspend earlier

Quoting Chris Wilson (2018-05-22 16:49:02) > In order to prepare the GPU for sleeping, we may want to submit commands > to it. This is a complicated process that may even require some swapping > in from shmemfs, if the GPU was in the wrong state. As such, we need to > do this preparation step

Re: [Intel-gfx] [PATCH v2] drm/i915: Promote .format_mod_supported() to the lead role

On Mon, May 21, 2018 at 12:21:01PM -0700, Eric Anholt wrote: > Ville Syrjala writes: > > > From: Ville Syrjälä > > > > Up to now we've used the plane's modifier list as the primary > > source of information for which modifiers are

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: Prepare GEM for suspend earlier (rev3)

== Series Details == Series: drm/i915: Prepare GEM for suspend earlier (rev3) URL : https://patchwork.freedesktop.org/series/43575/ State : failure == Summary == = CI Bug Log - changes from CI_DRM_4221 -> Patchwork_9088 = == Summary - FAILURE == Serious unknown changes coming with

Re: [Intel-gfx] [PATCH v5 7/7] drm/i915: Expose RPCS (SSEU) configuration to userspace

On 22/05/18 17:11, Lionel Landwerlin wrote: On 21/05/18 17:00, Tvrtko Ursulin wrote: + +    /* Queue this switch after all other activity */ +    list_for_each_entry(timeline, _priv->gt.timelines, link) { This can iterate over gt.active_rings for a shorter walk. See current state of

[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [1/4] drm/i915: Prepare GEM for suspend earlier

== Series Details == Series: series starting with [1/4] drm/i915: Prepare GEM for suspend earlier URL : https://patchwork.freedesktop.org/series/43578/ State : failure == Summary == = CI Bug Log - changes from CI_DRM_4221 -> Patchwork_9087 = == Summary - FAILURE == Serious unknown changes

Re: [Intel-gfx] [PATCH v5 7/7] drm/i915: Expose RPCS (SSEU) configuration to userspace

On 21/05/18 17:00, Tvrtko Ursulin wrote: + +    /* Queue this switch after all other activity */ +    list_for_each_entry(timeline, _priv->gt.timelines, link) { This can iterate over gt.active_rings for a shorter walk. See current state of engine_has_idle_kernel_context. For some reason,

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/execlists: Wait for ELSP submission on restart

== Series Details == Series: drm/i915/execlists: Wait for ELSP submission on restart URL : https://patchwork.freedesktop.org/series/43563/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4219_full -> Patchwork_9078_full = == Summary - WARNING == Minor unknown changes

Re: [Intel-gfx] [PATCH v4 1/2] vfio/mdev: Check globally for duplicate devices

[Cc +GVT-g maintainers/lists] On Tue, 22 May 2018 10:13:46 +0200 Cornelia Huck wrote: > On Fri, 18 May 2018 13:10:25 -0600 > Alex Williamson wrote: > > > When we create an mdev device, we check for duplicates against the > > parent device and

[Intel-gfx] [PATCH] drm/i915: Prepare GEM for suspend earlier

In order to prepare the GPU for sleeping, we may want to submit commands to it. This is a complicated process that may even require some swapping in from shmemfs, if the GPU was in the wrong state. As such, we need to do this preparation step synchronously before the rest of the system has started

[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [1/4] drm/i915: Prepare GEM for suspend earlier

== Series Details == Series: series starting with [1/4] drm/i915: Prepare GEM for suspend earlier URL : https://patchwork.freedesktop.org/series/43577/ State : failure == Summary == CHK include/config/kernel.release CHK include/generated/uapi/linux/version.h CHK

[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [1/3] drm/i915: Prepare GEM for suspend earlier

== Series Details == Series: series starting with [1/3] drm/i915: Prepare GEM for suspend earlier URL : https://patchwork.freedesktop.org/series/43576/ State : failure == Summary == = CI Bug Log - changes from CI_DRM_4221 -> Patchwork_9085 = == Summary - FAILURE == Serious unknown changes

[Intel-gfx] [PATCH 4/4] drm/i915: "Race-to-idle" after switching to the kernel context

During suspend we want to flush out all active contexts and their rendering. To do so we queue a request from the kernel's context, once we know that request is done, we know the GPU is completely idle. To speed up that switch bump the GPU clocks. Switching to the kernel context prior to idling

[Intel-gfx] [PATCH 3/4] RFC drm/i915: Switch to kernel context before idling at runtime

We can reduce our exposure to random neutrinos by resting on the kernel context having flushed out the user contexts to system memory and beyond. The corollary is that we then we require two passes through the idle handler to go to sleep, which on a truly idle system involves an extra pass through

[Intel-gfx] [PATCH 2/4] drm/i915: Special case kernel_context switch request

From: Mika Kuoppala When checking if engine is idling on a kernel context, the last request emitted to it could have been the exact request to switch into kernel context. Do not bail out early even if engine has requests, if the last request was for kernel context.

[Intel-gfx] [PATCH 1/4] drm/i915: Prepare GEM for suspend earlier

In order to prepare the GPU for sleeping, we may want to submit commands to it. This is a complicated process that may even require some swapping in from shmemfs, if the GPU was in the wrong state. As such, we need to do this preparation step synchronously before the rest of the system has started

Re: [Intel-gfx] [PATCH 4/4] drm/i915: "Race-to-idle" on switching to the kernel context

Quoting Chris Wilson (2018-05-22 16:08:30) > During suspend we want to flush out all active contexts and their > rendering. To do so we queue a request from the kernel's context, once > we know that request is done, we know the GPU is completely idle. To > speed up that switch bump the GPU clocks.

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Prepare GEM for suspend earlier (rev2)

== Series Details == Series: drm/i915: Prepare GEM for suspend earlier (rev2) URL : https://patchwork.freedesktop.org/series/43575/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4221 -> Patchwork_9084 = == Summary - WARNING == Minor unknown changes coming with

[Intel-gfx] [PATCH 4/4] drm/i915: "Race-to-idle" on switching to the kernel context

During suspend we want to flush out all active contexts and their rendering. To do so we queue a request from the kernel's context, once we know that request is done, we know the GPU is completely idle. To speed up that switch bump the GPU clocks. Switching to the kernel context prior to idling

[Intel-gfx] [PATCH 2/4] drm/i915: Special case kernel_context switch request

From: Mika Kuoppala When checking if engine is idling on a kernel context, the last request emitted to it could have been the exact request to switch into kernel context. Do not bail out early even if engine has requests, if the last request was for kernel context.

[Intel-gfx] [PATCH 3/4] RFC drm/i915: Switch to kernel context before idling at runtime

We can reduce our exposure to random neutrinos by resting on the kernel context having flushed out the user contexts to system memory and beyond. The corollary is that we then we require two passes through the idle handler to go to sleep, which on a truly idle system involves an extra pass through

[Intel-gfx] [PATCH 1/4] drm/i915: Prepare GEM for suspend earlier

In order to prepare the GPU for sleeping, we may want to submit commands to it. This is a complicated process that may even require some swapping in from shmemfs, if the GPU was in the wrong state. As such, we need to do this preparation step synchronously before the rest of the system has started

Re: [Intel-gfx] [PATCH v3] drm/i915/gen11: Preempt-to-idle support in execlists.

On 2018-05-22 16:39, Ceraolo Spurio, Daniele wrote: On 5/21/2018 3:16 AM, Lis, Tomasz wrote: On 2018-05-18 23:08, Daniele Ceraolo Spurio wrote: On 11/05/18 08:45, Tomasz Lis wrote: The patch adds support of preempt-to-idle requesting by setting a proper bit within Execlist Control

[Intel-gfx] [PATCH 3/3] RFC drm/i915: Switch to kernel context before idling at runtime

We can reduce our exposure to random neutrinos by resting on the kernel context having flushed out the user contexts to system memory and beyond. The corollary is that we then we require two passes through the idle handler to go to sleep, which on a truly idle system involves an extra pass through

[Intel-gfx] [PATCH 1/3] drm/i915: Prepare GEM for suspend earlier

In order to prepare the GPU for sleeping, we may want to submit commands to it. This is a complicated process that may even require some swapping in from shmemfs, if the GPU was in the wrong state. As such, we need to do this preparation step synchronously before the rest of the system has started

[Intel-gfx] [PATCH 2/3] drm/i915: Special case kernel_context switch request

From: Mika Kuoppala When checking if engine is idling on a kernel context, the last request emitted to it could have been the exact request to switch into kernel context. Do not bail out early even if engine has requests, if the last request was for kernel context.

Re: [Intel-gfx] [PATCH v2] drm/i915: Prepare GEM for suspend earlier

Quoting Chris Wilson (2018-05-22 15:35:34) > In order to prepare the GPU for sleeping, we may want to submit commands > to it. This is a complicated process that may even require some swapping > in from shmemfs, if the GPU was in the wrong state. As such, we need to > do this preparation step

Re: [Intel-gfx] [PATCH v3] drm/i915/gen11: Preempt-to-idle support in execlists.

On 5/21/2018 3:16 AM, Lis, Tomasz wrote: On 2018-05-18 23:08, Daniele Ceraolo Spurio wrote: On 11/05/18 08:45, Tomasz Lis wrote: The patch adds support of preempt-to-idle requesting by setting a proper bit within Execlist Control Register, and receiving preemption result from Context

Re: [Intel-gfx] [PATCH 6/6] drm/i915/psr: Fix ALPM cap check for PSR2

On Fri, May 11, 2018 at 12:51:45PM -0700, Dhinakaran Pandiyan wrote: > While touching the code around this, I noticed that absence of ALPM > capability does not stop us from enabling PSR2. But, the spec > unambiguously states that ALPM is required for PSR2 and so does this > commit that introduced

[Intel-gfx] [PATCH v2] drm/i915: Prepare GEM for suspend earlier

In order to prepare the GPU for sleeping, we may want to submit commands to it. This is a complicated process that may even require some swapping in from shmemfs, if the GPU was in the wrong state. As such, we need to do this preparation step synchronously before the rest of the system has started

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: Prepare GEM for suspend earlier

== Series Details == Series: drm/i915: Prepare GEM for suspend earlier URL : https://patchwork.freedesktop.org/series/43575/ State : failure == Summary == CHK include/config/kernel.release CHK include/generated/uapi/linux/version.h CHK include/generated/utsrelease.h CHK

[Intel-gfx] [PATCH] drm/i915: Prepare GEM for suspend earlier

In order to prepare the GPU for sleeping, we may want to submit commands to it. This is a complicated process that may even require some swapping in from shmemfs, if the GPU was in the wrong state. As such, we need to do this preparation step synchronously before the rest of the system has started

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/psr: vbt change for psr (rev9)

== Series Details == Series: drm/i915/psr: vbt change for psr (rev9) URL : https://patchwork.freedesktop.org/series/41289/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4218_full -> Patchwork_9077_full = == Summary - SUCCESS == No regressions found. External URL:

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: Special case kernel_context switch request

== Series Details == Series: drm/i915: Special case kernel_context switch request URL : https://patchwork.freedesktop.org/series/43572/ State : failure == Summary == = CI Bug Log - changes from CI_DRM_4221 -> Patchwork_9082 = == Summary - FAILURE == Serious unknown changes coming with

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/psr : Add psr1 live status (rev3)

== Series Details == Series: drm/i915/psr : Add psr1 live status (rev3) URL : https://patchwork.freedesktop.org/series/42021/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4218_full -> Patchwork_9076_full = == Summary - WARNING == Minor unknown changes coming with

[Intel-gfx] ✓ Fi.CI.BAT: success for Per-context and per-client engine busyness (rev6)

== Series Details == Series: Per-context and per-client engine busyness (rev6) URL : https://patchwork.freedesktop.org/series/32645/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4220 -> Patchwork_9081 = == Summary - SUCCESS == No regressions found. External URL:

Re: [Intel-gfx] [RFC 04/10] drm/i915: Move intel_engine_context_in/out into intel_lrc.c

On 22/05/2018 13:46, Chris Wilson wrote: Quoting Tvrtko Ursulin (2018-05-22 13:30:14) From: Tvrtko Ursulin Intel_lrc.c is the only caller and so to avoid some header file ordering issues in future patches move these two over there. Signed-off-by: Tvrtko Ursulin

Re: [Intel-gfx] [PATCH 1/2] drm/i915: Remove bogus NV12 PLANE_COLOR_CTL setup

On Tue, May 22, 2018 at 01:16:59PM +0300, Jani Nikula wrote: > On Mon, 21 May 2018, Ville Syrjala wrote: > > From: Ville Syrjälä > > > > We already handle the color encoding mode properly. Remove the broken > > NV12 special case. > >

Re: [Intel-gfx] [PATCH] drm/i915: Special case kernel_context switch request

Quoting Mika Kuoppala (2018-05-22 13:49:24) > From: Mika Kuoppala > > When checking if engine is idling on a kernel context, > the last request emitted to it could have been the exact > request to switch into kernel context. > > Do not bail out early even if engine has

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for Per-context and per-client engine busyness (rev6)

== Series Details == Series: Per-context and per-client engine busyness (rev6) URL : https://patchwork.freedesktop.org/series/32645/ State : warning == Summary == $ dim sparse origin/drm-tip Commit: drm/i915: Store engine backpointer in the intel_context Okay! Commit: drm/i915: Include

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for Per-context and per-client engine busyness (rev6)

== Series Details == Series: Per-context and per-client engine busyness (rev6) URL : https://patchwork.freedesktop.org/series/32645/ State : warning == Summary == $ dim checkpatch origin/drm-tip 7817526ffcfb drm/i915: Store engine backpointer in the intel_context e39413c3a24f drm/i915:

Re: [Intel-gfx] [RFC 02/10] drm/i915: Include i915_scheduler.h from i915_gem_context.h

Tvrtko Ursulin writes: > From: Tvrtko Ursulin > > struct i915_gem_context embeds structr i915_sched_attr so needs to include > the respective header. s/structr/struct -Mika > > Signed-off-by: Tvrtko Ursulin > --- >

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/query: nospec expects no more than an unsigned long

== Series Details == Series: drm/i915/query: nospec expects no more than an unsigned long URL : https://patchwork.freedesktop.org/series/43569/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4220 -> Patchwork_9080 = == Summary - SUCCESS == No regressions found.

[Intel-gfx] [PATCH] drm/i915: Special case kernel_context switch request

From: Mika Kuoppala When checking if engine is idling on a kernel context, the last request emitted to it could have been the exact request to switch into kernel context. Do not bail out early even if engine has requests, if the last request was for kernel context.

Re: [Intel-gfx] [RFC 04/10] drm/i915: Move intel_engine_context_in/out into intel_lrc.c

Quoting Tvrtko Ursulin (2018-05-22 13:30:14) > From: Tvrtko Ursulin > > Intel_lrc.c is the only caller and so to avoid some header file ordering > issues in future patches move these two over there. > > Signed-off-by: Tvrtko Ursulin

Re: [Intel-gfx] [RFC 02/10] drm/i915: Include i915_scheduler.h from i915_gem_context.h

Quoting Tvrtko Ursulin (2018-05-22 13:30:12) > From: Tvrtko Ursulin > > struct i915_gem_context embeds structr i915_sched_attr so needs to include > the respective header. > > Signed-off-by: Tvrtko Ursulin Reviewed-by: Chris Wilson

Re: [Intel-gfx] [RFC 03/10] drm/i915: Forward declare struct intel_context

Quoting Tvrtko Ursulin (2018-05-22 13:30:13) > From: Tvrtko Ursulin > > This is to avoid an error with structure declared in parameter list if the > include ordering changes. > > Signed-off-by: Tvrtko Ursulin Reviewed-by: Chris Wilson

Re: [Intel-gfx] [PATCH] drm/i915/psr: vbt change for psr

On Tue, 22 May 2018, vathsala nagaraju wrote: > From: Vathsala Nagaraju > > For psr block #9, the vbt description has moved to options [0-3] for > TP1,TP2,TP3 Wakeup time from decimal value without any change to vbt > structure. Since

Re: [Intel-gfx] [PATCH 4/6] drm/i915/psr: Avoid unnecessary DPCD read of DP_PSR_CAPS

On 5/12/2018 1:21 AM, Dhinakaran Pandiyan wrote: intel_dp->psr_dpcd already has the required values. Cc: Jose Roberto de Souza Signed-off-by: Dhinakaran Pandiyan --- drivers/gpu/drm/i915/intel_psr.c | 11 +-- 1 file changed, 1

[Intel-gfx] [RFC 04/10] drm/i915: Move intel_engine_context_in/out into intel_lrc.c

From: Tvrtko Ursulin Intel_lrc.c is the only caller and so to avoid some header file ordering issues in future patches move these two over there. Signed-off-by: Tvrtko Ursulin --- drivers/gpu/drm/i915/intel_lrc.c| 57

[Intel-gfx] [RFC 08/10] drm/i915: Expose per-engine client busyness

From: Tvrtko Ursulin Expose per-client and per-engine busyness under the previously added sysfs client root. The new files are one per-engine instance and located under the 'busy' directory. Each contains a monotonically increasing nano-second resolution times each

[Intel-gfx] [RFC 07/10] drm/i915: Update client name on context create

From: Tvrtko Ursulin Some clients have the DRM fd passed to them over a socket by the X server. Grab the real client and pid when they create their first context and update the exposed data for more useful enumeration. Signed-off-by: Tvrtko Ursulin

[Intel-gfx] [RFC 09/10] drm/i915: Add sysfs toggle to enable per-client engine stats

From: Tvrtko Ursulin By default we are not collecting any per-engine and per-context statistcs. Add a new sysfs toggle to enable this facility: $ echo 1 >/sys/class/drm/card0/clients/enable_stats v2: Rebase. Signed-off-by: Tvrtko Ursulin

[Intel-gfx] [RFC 10/10] drm/i915: Allow clients to query own per-engine busyness

From: Tvrtko Ursulin Some customers want to know how much of the GPU time are their clients using in order to make dynamic load balancing decisions. With the accounting infrastructure in place in the previous patch, we add a new context param

[Intel-gfx] [RFC 06/10] drm/i915: Expose list of clients in sysfs

From: Tvrtko Ursulin Expose a list of clients with open file handles in sysfs. This will be a basis for a top-like utility showing per-client and per- engine GPU load. Currently we only expose each client's pid and name under opaque numbered directories in

[Intel-gfx] [RFC 02/10] drm/i915: Include i915_scheduler.h from i915_gem_context.h

From: Tvrtko Ursulin struct i915_gem_context embeds structr i915_sched_attr so needs to include the respective header. Signed-off-by: Tvrtko Ursulin --- drivers/gpu/drm/i915/i915_gem_context.h | 1 + 1 file changed, 1 insertion(+) diff

[Intel-gfx] [RFC 03/10] drm/i915: Forward declare struct intel_context

From: Tvrtko Ursulin This is to avoid an error with structure declared in parameter list if the include ordering changes. Signed-off-by: Tvrtko Ursulin --- drivers/gpu/drm/i915/i915_gem_context.h | 2 ++ 1 file changed, 2 insertions(+) diff

[Intel-gfx] [RFC 05/10] drm/i915: Track per-context engine busyness

From: Tvrtko Ursulin Some customers want to know how much of the GPU time are their clients using in order to make dynamic load balancing decisions. With the hooks already in place which track the overall engine busyness, we can extend that slightly to split that time

[Intel-gfx] [RFC 01/10] drm/i915: Store engine backpointer in the intel_context

From: Tvrtko Ursulin It will become useful in a later patch. Signed-off-by: Tvrtko Ursulin --- drivers/gpu/drm/i915/i915_gem_context.c | 1 + drivers/gpu/drm/i915/i915_gem_context.h | 1 + 2 files changed, 2 insertions(+) diff --git

[Intel-gfx] [RFC v5 00/10] Per-context and per-client engine busyness

From: Tvrtko Ursulin Another re-post of my earlier, now slightly updated work, to expose a DRM client hierarchy in sysfs in order to enable a top like tool: intel-gpu-top - load avg 40.80, 27.11, 1.50; 882/ 950 MHz;0% RC6; 13.26 Watts; 261903 irqs/s

Re: [Intel-gfx] [PATCH 1/6] drm/i915/psr: Avoid DPCD reads when panel does not support PSR

On 5/12/2018 1:21 AM, Dhinakaran Pandiyan wrote: Ville noticed that we are unncessarily reading DPCD's after knowing panel did not support PSR. Looks like this check that was present earlier got removed unintentionally, let's put it back. While we do this, add the PSR version number in the

Re: [Intel-gfx] [PATCH] drm/i915/query: nospec expects no more than an unsigned long

On 22/05/18 13:10, Chris Wilson wrote: nospec quite reasonably asserts that it will never be used with an index larger than unsigned long (that being the largest possibly index into an C array). However, our ubi uses the convention of u64 for any large integer, running afoul of the assertion on

Re: [Intel-gfx] [PATCH] drm/i915/query: nospec expects no more than an unsigned long

Quoting Chris Wilson (2018-05-22 13:17:06) > Quoting Lionel Landwerlin (2018-05-22 13:13:03) > > On 22/05/18 13:10, Chris Wilson wrote: > > > nospec quite reasonably asserts that it will never be used with an index > > > larger than unsigned long (that being the largest possibly index into an > >

Re: [Intel-gfx] [PATCH] drm/i915/query: nospec expects no more than an unsigned long

Quoting Lionel Landwerlin (2018-05-22 13:13:03) > On 22/05/18 13:10, Chris Wilson wrote: > > nospec quite reasonably asserts that it will never be used with an index > > larger than unsigned long (that being the largest possibly index into an > > C array). However, our ubi uses the convention of

Re: [Intel-gfx] [PATCH] drm/i915/query: nospec expects no more than an unsigned long

On 22/05/18 13:10, Chris Wilson wrote: nospec quite reasonably asserts that it will never be used with an index larger than unsigned long (that being the largest possibly index into an C array). However, our ubi uses the convention of u64 for any large integer, running afoul of the assertion on

[Intel-gfx] ✗ Fi.CI.BAT: failure for RFC drm/i915: Switch to kernel context before idling at runtime (rev2)

== Series Details == Series: RFC drm/i915: Switch to kernel context before idling at runtime (rev2) URL : https://patchwork.freedesktop.org/series/42321/ State : failure == Summary == = CI Bug Log - changes from CI_DRM_4219 -> Patchwork_9079 = == Summary - FAILURE == Serious unknown

[Intel-gfx] [PATCH] drm/i915/query: nospec expects no more than an unsigned long

nospec quite reasonably asserts that it will never be used with an index larger than unsigned long (that being the largest possibly index into an C array). However, our ubi uses the convention of u64 for any large integer, running afoul of the assertion on 32b. Reduce our index to an unsigned

[Intel-gfx] [drm-intel:drm-intel-next-queued 1/2] include/linux/nospec.h:53:2: note: in expansion of macro 'BUILD_BUG_ON'

tree: git://anongit.freedesktop.org/drm-intel drm-intel-next-queued head: 1abb70f5955d1a9021f96359a2c6502ca569b68d commit: 84b510e22da7926522a257cfe295d3695346a0bd [1/2] drm/i915/query: Protect tainted function pointer lookup config: i386-randconfig-x012-201820 (attached as .config) compiler:

Re: [Intel-gfx] [PATCH i-g-t 3/3] benchmarks/gem_syslatency: Specify batch duration

On 22/05/2018 12:00, Chris Wilson wrote: While for stressing the system we want to submit as many batches as we can as that shows us worst case impact on system latency, it is not a very realistic case. To introduce a bit more realism allow the batches run for a user defined duration.

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/execlists: Wait for ELSP submission on restart

== Series Details == Series: drm/i915/execlists: Wait for ELSP submission on restart URL : https://patchwork.freedesktop.org/series/43563/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4219 -> Patchwork_9078 = == Summary - WARNING == Minor unknown changes coming with

Re: [Intel-gfx] [PATCH 11/24] drm/i915/icl: Get DDI clock for ICL based on PLLs.

On Mon, 2018-05-21 at 17:25 -0700, Paulo Zanoni wrote: > From: Manasi Navare > > PLLs are the source clocks for the DDIs so in order > to determine the ddi clock we need to check the PLL > configuration. > > This gets a little tricky for ICL since there is > no

  1   2   >