== Series Details ==
Series: Load Guc and huC on Geminilake (rev2)
URL : https://patchwork.freedesktop.org/series/43600/
State : failure
== Summary ==
= CI Bug Log - changes from CI_DRM_4222 -> Patchwork_9091 =
== Summary - FAILURE ==
Serious unknown changes coming with Patchwork_9091 abso
load the v03.00.2555 huC on geminilake.
v2:
- rebased.
- Load the correct the version. (John Spotswood)
Cc: John Spotswood
Cc: Tomi Sarvela
Cc: Jani Saarinen
Signed-off-by: Anusha Srivatsa
---
drivers/gpu/drm/i915/intel_huc_fw.c | 12
1 file changed, 12 insertions(+)
diff --git
The following changes since commit 2a9b2cf50fb32e36e4fc1586c2f6f1421913b553:
Merge branch 'for-upstreaming-v1.7.2' of
https://github.com/felix-cavium/linux-firmware (2018-05-18 08:35:22 -0400)
are available in the git repository at:
git://anongit.freedesktop.org/drm/drm-firmware master
for
From: John Spotswood
load the v11.98 guC on geminilake.
v2: rebased.
Cc: Tomi Sarvela
Cc: Jani Saarinen
Signed-off-by: Anusha Srivatsa
Signed-off-by: John Spotswood
---
drivers/gpu/drm/i915/intel_guc_fw.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/drivers/gpu/drm/i915/
Signed-off-by: Anusha Srivatsa
---
drivers/gpu/drm/i915/i915_params.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_params.h
b/drivers/gpu/drm/i915/i915_params.h
index aebe046..3e4e128 100644
--- a/drivers/gpu/drm/i915/i915_params.h
+++ b/drivers/g
>-Original Message-
>From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf Of
>Manasi Navare
>Sent: Tuesday, May 15, 2018 5:53 PM
>To: intel-gfx@lists.freedesktop.org
>Cc: Zanoni, Paulo R
>Subject: [Intel-gfx] [PATCH] drm/i915/icl: Add remaining registers and
>bitfi
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
> > configuration.
> >
> > This gets a
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.
v2: rebase
v3: DK
Renam
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 mdev device, we check for duplicates against the
>
== 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 a
== 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 '<<' (ctx:Vx
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 cannot depend on bdb->version
== 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 com
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 requests,
> if the last re
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 DP_PSR_LINK_CRC_ERR
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 taki
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 Atwood
Tested-by: Benson Le
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]
u
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
> Cc: Rodrigo Vivi
> Signed-off-by: José
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:
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 AL
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 u6
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 psr2_live_status to psr_source_st
== 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 Pat
== 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 configurati
== 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 conf
== 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 with
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: record sseu configuration pe
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 in
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 b/drivers/gpu/drm/i915/i915_perf.c
index 805dfc73
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 b/drivers/gpu/drm/i915/i915_perf
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 configuration to userspace and may
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,
Chris
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: L
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 context is adjusted before
== 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
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 synch
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 supported by a
> > given plane. In order to allow auxiliary metad
== 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 Patchwor
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, &dev_priv->gt.timelines, link) {
This can iterate over gt.active_rings for a shorter walk. See current
state of engi
== 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
On 21/05/18 17:00, Tvrtko Ursulin wrote:
+
+ /* Queue this switch after all other activity */
+ list_for_each_entry(timeline, &dev_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
== 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 comin
[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 return -EEXIST if found, but the mdev device
> > na
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
== 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 include/generat
== 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
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 is
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
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.
Fixes: a89d1f921c15 ("drm/i91
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
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.
== 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 Patchwork_
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 is
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.
Fixes: a89d1f921c15 ("drm/i91
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
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
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 Regi
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
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
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.
Fixes: a89d1f921c15 ("drm/i91
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 synch
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 St
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
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
== 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 i
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
== 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:
htt
== 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 Patc
== 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 Patchw
== 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:
htt
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
Expectation was that we wou
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.
> >
> > Cc: Vidya Srinivas
> > Cc: Maarten Lankhorst
> > Signed-o
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 requests,
> if the last re
== 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 i915_s
== 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: Include
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
> ---
> drivers/gpu/drm/i915/i915_gem_context.h | 1 +
> 1 file changed, 1 insertion(
== 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.
Externa
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.
Fixes: a89d1f921c15 ("drm/i91
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
Expectation was that we would be using these in guc. Brief hi
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
-Chris
___
Intel-g
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
-Chris
___
Inte
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 spec does not mention from which VBT version this
> change wa
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 insertion(+), 10 deletions(-)
Reviewed-by: Vathsala N
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
client's jobs were executing
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 +
drivers/gpu/drm/i915/intel_ringbuffer.h |
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
---
drivers/gpu/drm/i915/i915_drv.h
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
---
drivers/gpu/drm/i915/i915_drv.h | 4 ++
driver
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 /sys/class/drm/card0/clients/.
For in
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 (I915_CONTEXT_GET_ENGINES_BUSY) which points to struc
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 --git a/drivers/gpu/drm/i915/i915_gem_context.h
b/driver
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 --git a/drivers/gpu/drm/i915/i915_gem_context.h
b/d
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 between contexts.
v2: Fix
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
IMC reads: 5543 MiB/s
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 a/drivers/gpu/drm/i915/i915_gem_context.c
b/drivers/gpu/drm
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 deb
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 3
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
> > >
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 u6
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 3
1 - 100 of 140 matches
Mail list logo
