Quoting Andi Shyti (2020-04-27 00:15:56)
> Hi Chris,
>
> > intel_uncore_forcewake_get(uncore, FORCEWAKE_ALL);
> > if (IS_CHERRYVIEW(i915))
> > - rps->enabled = chv_rps_enable(rps);
> > + enabled = chv_rps_enable(rps);
> > else if (IS_VALLEYVIEW(i915))
> >
Quoting Andi Shyti (2020-04-27 00:28:57)
> Hi Chris,
>
> On Sat, Apr 25, 2020 at 07:54:00PM +0100, Chris Wilson wrote:
> > As with the realisation for soft-rc6, we respond to idling the engines
> > within microseconds, far faster than the response times for HW RC6 and
> > RPS. Furthermore, our fas
We see that if the HW doesn't actually sleep, the HW may eat the poison
we set in its write-only HWSP during sanitize:
intel_gt_resume.part.8: :00:02.0
__gt_unpark: :00:02.0
gt_sanitize: :00:02.0 force:yes
process_csb: :00:02.0 vcs0: cs-irq head=5, tail=90
process_csb: 00
We reduced the clocks slowly after a boost event based on the
observation that the smoothness of animations suffered. However, since
reducing the evalution intervals, we should be able to respond to the
rapidly fluctuating workload of a simple desktop animation and so
restore the more aggressive do
We treat parking as a manual RPS timeout event, and downclock the GPU
for the next unpark and batch execution. However, having restored the
aggressive downclocking and observed that we have very light workloads
whose only interaction is through the manual parking events, carry over
the aggressive d
As with the realisation for soft-rc6, we respond to idling the engines
within microseconds, far faster than the response times for HW RC6 and
RPS. Furthermore, our fast parking upon idle, prevents HW RPS from
running for many desktop workloads, as the RPS evaluation intervals are
on the order of te
The bspec lists both the clock frequency and the effective interval. The
interval corresponds to observed behaviour, so adjust the frequency to
match.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gt/intel_gt_clock_utils.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
In the near future, we will utilize the busy-stats on each engine to
approximate the C0 cycles of each, and use that as an input to a manual
RPS mechanism. That entails having busy-stats always enabled and so we
can remove the enable/disable routines and simplify the pmu setup. As a
consequence of
Pull the boolean intel_rps.enabled and intel_rps.active into a single
flags field, in preparation for more.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gt/debugfs_gt_pm.c | 5 +--
drivers/gpu/drm/i915/gt/intel_rps.c | 43 ++-
drivers/gpu/drm/i915/gt/intel_rp
Use the new intel_rps.flags field to store whether or not interrupts are
being used with RPS.
Signed-off-by: Chris Wilson
Reviewed-by: Andi Shyti
---
drivers/gpu/drm/i915/gt/intel_rps.c | 17 -
drivers/gpu/drm/i915/gt/intel_rps.h | 15 +++
drivers/gpu/drm
We see that if the HW doesn't actually sleep, the HW may eat the poison
we set in its write-only HWSP during sanitize:
intel_gt_resume.part.8: :00:02.0
__gt_unpark: :00:02.0
gt_sanitize: :00:02.0 force:yes
process_csb: :00:02.0 vcs0: cs-irq head=5, tail=90
process_csb: 00
We evaluate *active, which is a pointer into execlists->inflight[]
during dequeue to decide how long a preempt-timeout we need to apply.
However, as soon as we do the submit_ports, the HW may send its ACK
interrupt causing us to promote execlists->pending[] tp
execlists->inflight[], overwriting the
From: Tvrtko Ursulin
Recently added assert in a common helper used for calculating batch
duration and preemption period is harmful when preemption is disabled on a
context. Split out into low level and high level helper and use the former
for preemption period queries.
Signed-off-by: Tvrtko Ursu
Quoting Tvrtko Ursulin (2020-04-27 10:00:14)
> From: Tvrtko Ursulin
>
> Recently added assert in a common helper used for calculating batch
> duration and preemption period is harmful when preemption is disabled on a
> context. Split out into low level and high level helper and use the former
> f
== Series Details ==
Series: drm/i915/gt: Sanitize GT first
URL : https://patchwork.freedesktop.org/series/76540/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8370 -> Patchwork_17472
Summary
---
**SUCCESS**
No re
The hwsp_cacheline pointer from i915_request is very, very flimsy. The
i915_request.timeline (and the hwsp_cacheline) are lost upon retiring
(after an RCU grace). Therefore we need to confirm that once we have the
right pointer for the cacheline, it is not in the process of being
retired and dispos
The hwsp_cacheline pointer from i915_request is very, very flimsy. The
i915_request.timeline (and the hwsp_cacheline) are lost upon retiring
(after an RCU grace). Therefore we need to confirm that once we have the
right pointer for the cacheline, it is not in the process of being
retired and dispos
== Series Details ==
Series: series starting with [1/9] drm/i915/gt: Sanitize GT first
URL : https://patchwork.freedesktop.org/series/76542/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
4233a356bc65 drm/i915/gt: Sanitize GT first
651f29e87551 drm/i915/gt: Fix up clock frequenc
== Series Details ==
Series: series starting with [1/9] drm/i915/gt: Sanitize GT first
URL : https://patchwork.freedesktop.org/series/76542/
State : warning
== Summary ==
$ dim sparse origin/drm-tip
Sparse version: v0.6.0
Commit: drm/i915/gt: Sanitize GT first
Okay!
Commit: drm/i915/gt: Fix u
On 27/04/2020 09:40, Chris Wilson wrote:
We see that if the HW doesn't actually sleep, the HW may eat the poison
we set in its write-only HWSP during sanitize:
intel_gt_resume.part.8: :00:02.0
__gt_unpark: :00:02.0
gt_sanitize: :00:02.0 force:yes
process_csb: :00:02
Quoting Tvrtko Ursulin (2020-04-27 10:50:01)
>
> On 27/04/2020 09:40, Chris Wilson wrote:
> > We see that if the HW doesn't actually sleep, the HW may eat the poison
> > we set in its write-only HWSP during sanitize:
> >
> >intel_gt_resume.part.8: :00:02.0
> >__gt_unpark: :00:02.0
== Series Details ==
Series: series starting with [1/9] drm/i915/gt: Sanitize GT first
URL : https://patchwork.freedesktop.org/series/76542/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8370 -> Patchwork_17473
Summary
== Series Details ==
Series: drm/i915/gt: Check cacheline is valid before acquiring (rev2)
URL : https://patchwork.freedesktop.org/series/76545/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
fdcf957ff1a2 drm/i915/gt: Check cacheline is valid before acquiring
-:13: WARNING:COMMI
== Series Details ==
Series: drm/i915/gt: Sanitize GT first
URL : https://patchwork.freedesktop.org/series/76540/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8370_full -> Patchwork_17472_full
Summary
---
**SUCCESS*
On 27/04/2020 10:55, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2020-04-27 10:50:01)
On 27/04/2020 09:40, Chris Wilson wrote:
We see that if the HW doesn't actually sleep, the HW may eat the poison
we set in its write-only HWSP during sanitize:
intel_gt_resume.part.8: :00:02.0
On 27/04/2020 10:29, Chris Wilson wrote:
The hwsp_cacheline pointer from i915_request is very, very flimsy. The
i915_request.timeline (and the hwsp_cacheline) are lost upon retiring
(after an RCU grace). Therefore we need to confirm that once we have the
right pointer for the cacheline, it is n
== Series Details ==
Series: drm/i915/gt: Check cacheline is valid before acquiring (rev2)
URL : https://patchwork.freedesktop.org/series/76545/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8370 -> Patchwork_17474
Summary
On 26/04/2020 10:42, Chris Wilson wrote:
We evaluate *active, which is a pointer into execlists->inflight[]
during dequeue to decide how long a preempt-timeout we need to apply.
However, as soon as we do the submit_ports, the HW may send its ACK
interrupt causing us to promote execlists->pendin
== Series Details ==
Series: In order to readout DP SDPs, refactors the handling of DP SDPs (rev12)
URL : https://patchwork.freedesktop.org/series/72853/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
80724ea91cbd video/hdmi: Add Unpack only function for DRM infoframe
447aea2fe2
== Series Details ==
Series: In order to readout DP SDPs, refactors the handling of DP SDPs (rev12)
URL : https://patchwork.freedesktop.org/series/72853/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8370 -> Patchwork_17475
== Series Details ==
Series: series starting with [1/9] drm/i915/gt: Sanitize GT first
URL : https://patchwork.freedesktop.org/series/76542/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_8370_full -> Patchwork_17473_full
Su
== Series Details ==
Series: drm/i915/gt: Check cacheline is valid before acquiring (rev2)
URL : https://patchwork.freedesktop.org/series/76545/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8370_full -> Patchwork_17474_full
The bspec lists both the clock frequency and the effective interval. The
interval corresponds to observed behaviour, so adjust the frequency to
match.
v2: Mika rightfully asked if we could measure the clock frequency from a
selftest.
Signed-off-by: Chris Wilson
Cc: Mika Kuoppala
---
.../gpu/dr
Chris Wilson writes:
> The bspec lists both the clock frequency and the effective interval. The
> interval corresponds to observed behaviour, so adjust the frequency to
> match.
>
> v2: Mika rightfully asked if we could measure the clock frequency from a
> selftest.
This kind of delivery times m
== Series Details ==
Series: In order to readout DP SDPs, refactors the handling of DP SDPs (rev12)
URL : https://patchwork.freedesktop.org/series/72853/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_8370_full -> Patchwork_17475_full
===
Quoting Mika Kuoppala (2020-04-27 13:15:23)
> Chris Wilson writes:
>
> > The bspec lists both the clock frequency and the effective interval. The
> > interval corresponds to observed behaviour, so adjust the frequency to
> > match.
> >
> > v2: Mika rightfully asked if we could measure the clock f
Chris Wilson writes:
> Quoting Mika Kuoppala (2020-04-27 13:15:23)
>> Chris Wilson writes:
>>
>> > The bspec lists both the clock frequency and the effective interval. The
>> > interval corresponds to observed behaviour, so adjust the frequency to
>> > match.
>> >
>> > v2: Mika rightfully asked
Quoting Chris Wilson (2020-04-27 09:54:08)
> We reduced the clocks slowly after a boost event based on the
> observation that the smoothness of animations suffered. However, since
> reducing the evalution intervals, we should be able to respond to the
> rapidly fluctuating workload of a simple desk
== Series Details ==
Series: drm/i915/gt: Fix up clock frequency (rev2)
URL : https://patchwork.freedesktop.org/series/76512/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_8372 -> Patchwork_17476
Summary
---
**FAILUR
The bspec lists both the clock frequency and the effective interval. The
interval corresponds to observed behaviour, so adjust the frequency to
match.
v2: Mika rightfully asked if we could measure the clock frequency from a
selftest.
Signed-off-by: Chris Wilson
Cc: Mika Kuoppala
Acked-by: Mika
On Fri, Apr 24, 2020 at 04:14:23PM -0700, Matt Roper wrote:
> The IRQ postinstall handling had open-coded pipe fault mask selection
> that never got updated for gen11. Switch it to use
> gen8_de_pipe_fault_mask() to ensure we don't miss updates for new
> platforms.
>
> Cc: José Roberto de Souza
On Fri, 24 Apr 2020, Guru Das Srinagesh wrote:
> On Fri, Apr 24, 2020 at 09:17:58AM +0300, Jani Nikula wrote:
>> On Tue, 21 Apr 2020, Guru Das Srinagesh wrote:
>> > Since the PWM framework is switching struct pwm_state.duty_cycle's
>> > datatype to u64, prepare for this transition by using DIV_RO
== Series Details ==
Series: drm/i915/gt: Fix up clock frequency (rev3)
URL : https://patchwork.freedesktop.org/series/76512/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_8372 -> Patchwork_17477
Summary
---
**FAILUR
On 21/04/2020 11:46, Maarten Lankhorst wrote:
> Now that we changed execbuf submission slightly to allow us to do all
> pinning in one place, we can now simply add ww versions on top of
> struct_mutex. All we have to do is a separate path for -EDEADLK
> handling, which needs to unpin all gem bo's
On Sun, Apr 26, 2020 at 11:22:32PM -0400, Alexei Podtelezhnikov wrote:
> In reverse order:
> - Add SKL GT1.5
> - Remove wrong and non-existant devices
> - Add Gen3/Gen4 twin IGDs
> - Amend historic records
Please split into separate patches and justify each with
a proper commit message.
>
> Sig
Quoting Ville Syrjälä (2020-04-27 15:02:48)
> On Sun, Apr 26, 2020 at 11:22:32PM -0400, Alexei Podtelezhnikov wrote:
> > In reverse order:
> > - Add SKL GT1.5
> > - Remove wrong and non-existant devices
> > - Add Gen3/Gen4 twin IGDs
> > - Amend historic records
>
> Please split into separate patc
The bspec lists both the clock frequency and the effective interval. The
interval corresponds to observed behaviour, so adjust the frequency to
match.
v2: Mika rightfully asked if we could measure the clock frequency from a
selftest.
Signed-off-by: Chris Wilson
Cc: Mika Kuoppala
Acked-by: Mika
>
> These do not exist. They are fake PCI-ID for Windows95 multi monitor.
> The single device appears twice on the bus as a second function. We
> never had that restriction and could do multiple monitors on the single
> device.
Windows 10 drivers list them, they do show up on lspci and I'll quote
Quoting Alexei Podtelezhnikov (2020-04-27 15:40:42)
> >
> > These do not exist. They are fake PCI-ID for Windows95 multi monitor.
> > The single device appears twice on the bus as a second function. We
> > never had that restriction and could do multiple monitors on the single
> > device.
>
> Wind
== Series Details ==
Series: drm/i915: Use proper fault mask in interrupt postinstall too (rev2)
URL : https://patchwork.freedesktop.org/series/76466/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8373 -> Patchwork_17478
Su
On Mon, Apr 27, 2020 at 10:45 AM Chris Wilson wrote:
>
> Quoting Alexei Podtelezhnikov (2020-04-27 15:40:42)
> > >
> > > These do not exist. They are fake PCI-ID for Windows95 multi monitor.
> > > The single device appears twice on the bus as a second function. We
> > > never had that restriction
Check that we do not submit two contexts into ELSP with the same tag
[upper portion of the descriptor].
References: https://gitlab.freedesktop.org/drm/intel/-/issues/1793
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gt/intel_lrc.c | 9 +
1 file changed, 9 insertions(+)
diff --gi
== Series Details ==
Series: drm/i915/gt: Fix up clock frequency (rev4)
URL : https://patchwork.freedesktop.org/series/76512/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_8373 -> Patchwork_17479
Summary
---
**FAILUR
The bspec lists both the clock frequency and the effective interval. The
interval corresponds to observed behaviour, so adjust the frequency to
match.
v2: Mika rightfully asked if we could measure the clock frequency from a
selftest.
Signed-off-by: Chris Wilson
Cc: Mika Kuoppala
Acked-by: Mika
== Series Details ==
Series: drm/i915/gt: Fix up clock frequency (rev5)
URL : https://patchwork.freedesktop.org/series/76512/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
0411865923e7 drm/i915/gt: Fix up clock frequency
-:159: CHECK:USLEEP_RANGE: usleep_range is preferred over
== Series Details ==
Series: drm/i915/execlists: Verify we don't submit two identical tags
URL : https://patchwork.freedesktop.org/series/76558/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_8373 -> Patchwork_17480
Summary
== Series Details ==
Series: drm/i915/gt: Fix up clock frequency (rev5)
URL : https://patchwork.freedesktop.org/series/76512/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8373 -> Patchwork_17481
Summary
---
**SUCCES
Hi Chris,
On Mon, Apr 27, 2020 at 09:54:06AM +0100, Chris Wilson wrote:
> As with the realisation for soft-rc6, we respond to idling the engines
> within microseconds, far faster than the response times for HW RC6 and
> RPS. Furthermore, our fast parking upon idle, prevents HW RPS from
> running f
Check that we do not submit two contexts into ELSP with the same tag
[upper portion of the descriptor].
References: https://gitlab.freedesktop.org/drm/intel/-/issues/1793
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gt/intel_lrc.c | 9 +
1 file changed, 9 insertions(+)
diff --gi
Check that we do not submit two contexts into ELSP with the same CCID
[upper portion of the descriptor].
References: https://gitlab.freedesktop.org/drm/intel/-/issues/1793
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gt/intel_lrc.c | 9 +
1 file changed, 9 insertions(+)
diff --g
Fixes: 2935ed5339c4 ("drm/i915: Remove logical HW ID")
Signed-off-by: Chris Wilson
Cc: Mika Kuoppala
Cc: # v5.5+
---
drivers/gpu/drm/i915/gt/intel_engine_types.h | 3 +--
drivers/gpu/drm/i915/gt/intel_lrc.c | 23 ++--
drivers/gpu/drm/i915/i915_perf.c | 3 +
Quoting Chris Wilson (2020-04-27 13:40:46)
> Quoting Chris Wilson (2020-04-27 09:54:08)
> > We reduced the clocks slowly after a boost event based on the
> > observation that the smoothness of animations suffered. However, since
> > reducing the evalution intervals, we should be able to respond to
On Mon, Apr 27, 2020 at 11:18:46AM -0400, Alexei Podtelezhnikov wrote:
> On Mon, Apr 27, 2020 at 10:45 AM Chris Wilson
> wrote:
> >
> > Quoting Alexei Podtelezhnikov (2020-04-27 15:40:42)
> > > >
> > > > These do not exist. They are fake PCI-ID for Windows95 multi monitor.
> > > > The single devi
As suggested by the TODO list of DRM subsystem:
-remove the member hsync of drm_display_mode
-convert code using hsync member to use drm_mode_hsync()
Signed-off-by: Michal Orzel
---
drivers/gpu/drm/drm_modes.c | 6 +-
drivers/gpu/drm/i915/display/intel_display.c | 1 -
inc
Chris Wilson writes:
> Fixes: 2935ed5339c4 ("drm/i915: Remove logical HW ID")
> Signed-off-by: Chris Wilson
> Cc: Mika Kuoppala
> Cc: # v5.5+
> ---
> drivers/gpu/drm/i915/gt/intel_engine_types.h | 3 +--
> drivers/gpu/drm/i915/gt/intel_lrc.c | 23 ++--
> drivers/gpu/
Chris Wilson writes:
> Check that we do not submit two contexts into ELSP with the same CCID
> [upper portion of the descriptor].
>
> References: https://gitlab.freedesktop.org/drm/intel/-/issues/1793
> Signed-off-by: Chris Wilson
> ---
> drivers/gpu/drm/i915/gt/intel_lrc.c | 9 +
> 1 f
Quoting Mika Kuoppala (2020-04-27 18:28:12)
> Chris Wilson writes:
>
> > Fixes: 2935ed5339c4 ("drm/i915: Remove logical HW ID")
> > Signed-off-by: Chris Wilson
> > Cc: Mika Kuoppala
> > Cc: # v5.5+
> > ---
> > drivers/gpu/drm/i915/gt/intel_engine_types.h | 3 +--
> > drivers/gpu/drm/i915/gt/
Fixes: 2935ed5339c4 ("drm/i915: Remove logical HW ID")
Signed-off-by: Chris Wilson
Cc: Mika Kuoppala
Cc: # v5.5+
---
drivers/gpu/drm/i915/gt/intel_engine_types.h | 3 +--
drivers/gpu/drm/i915/gt/intel_lrc.c | 25 ++--
drivers/gpu/drm/i915/i915_perf.c | 3 +
Quoting Mika Kuoppala (2020-04-27 18:31:37)
> Chris Wilson writes:
>
> > Check that we do not submit two contexts into ELSP with the same CCID
> > [upper portion of the descriptor].
> >
> > References: https://gitlab.freedesktop.org/drm/intel/-/issues/1793
> > Signed-off-by: Chris Wilson
> > ---
== Series Details ==
Series: drm/i915: Use proper fault mask in interrupt postinstall too (rev2)
URL : https://patchwork.freedesktop.org/series/76466/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8373_full -> Patchwork_17478_full
==
On Mon, Apr 27, 2020 at 06:34:33PM +, Patchwork wrote:
> == Series Details ==
>
> Series: drm/i915: Use proper fault mask in interrupt postinstall too (rev2)
> URL : https://patchwork.freedesktop.org/series/76466/
> State : success
>
> == Summary ==
>
> CI Bug Log - changes from CI_DRM_837
== Series Details ==
Series: drm/i915/execlists: Verify we don't submit two identical tags (rev2)
URL : https://patchwork.freedesktop.org/series/76558/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_8374 -> Patchwork_17482
S
Hi Chris,
On Sun, Apr 26, 2020 at 05:36:08PM +0100, Chris Wilson wrote:
> We have been preparing for a transfer of ownership of the GGTT from the
> global drm_i915_private into the intel_gt, and a part of the process has
> been to reduce the number of direct references to i915->ggtt and instead
>
== Series Details ==
Series: drm/i915/gt: Fix up clock frequency (rev5)
URL : https://patchwork.freedesktop.org/series/76512/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_8373_full -> Patchwork_17481_full
Summary
---
== Series Details ==
Series: Remove drm_display_mode.hsync
URL : https://patchwork.freedesktop.org/series/76564/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8375 -> Patchwork_17483
Summary
---
**SUCCESS**
No reg
Quoting Andi Shyti (2020-04-27 20:52:47)
> Hi Chris,
>
> On Mon, Apr 27, 2020 at 09:54:01AM +0100, Chris Wilson wrote:
> > The bspec lists both the clock frequency and the effective interval. The
> > interval corresponds to observed behaviour, so adjust the frequency to
> > match.
>
> what is the
Hi Chris,
> We see that if the HW doesn't actually sleep, the HW may eat the poison
> we set in its write-only HWSP during sanitize:
>
> intel_gt_resume.part.8: :00:02.0
> __gt_unpark: :00:02.0
> gt_sanitize: :00:02.0 force:yes
> process_csb: :00:02.0 vcs0: cs-irq head=5,
== Series Details ==
Series: In order to readout DP SDPs, refactors the handling of DP SDPs (rev12)
URL : https://patchwork.freedesktop.org/series/72853/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_8370_full -> Patchwork_17475_full
===
Hi Chris,
On Mon, Apr 27, 2020 at 09:54:01AM +0100, Chris Wilson wrote:
> The bspec lists both the clock frequency and the effective interval. The
> interval corresponds to observed behaviour, so adjust the frequency to
> match.
what is the observed behavior?
Andi
___
== Series Details ==
Series: series starting with drm/i915/execlists: Avoid reusing the same logical
CC_ID (rev2)
URL : https://patchwork.freedesktop.org/series/76563/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_8376 -> Patchwork_17484
==
The bspec is confusing on the nature of the upper 32bits of the LRC
descriptor. Once upon a time, it said that it uses the upper 32b to
decide if it should perform a lite-restore, and so we must ensure that
each unique context submitted to HW is given a unique CCID [for the
duration of it being on
Check that we do not submit two contexts into ELSP with the same CCID
[upper portion of the descriptor].
References: https://gitlab.freedesktop.org/drm/intel/-/issues/1793
Signed-off-by: Chris Wilson
Reviewed-by: Mika Kuoppala
---
drivers/gpu/drm/i915/gt/intel_lrc.c | 37 ++-
Hi Chris,
On Mon, Apr 27, 2020 at 09:54:07AM +0100, Chris Wilson wrote:
> We treat parking as a manual RPS timeout event, and downclock the GPU
> for the next unpark and batch execution. However, having restored the
> aggressive downclocking and observed that we have very light workloads
> whose o
Hi Chris,
On Mon, Apr 27, 2020 at 06:06:40PM +0100, Chris Wilson wrote:
> Quoting Chris Wilson (2020-04-27 13:40:46)
> > Quoting Chris Wilson (2020-04-27 09:54:08)
> > > We reduced the clocks slowly after a boost event based on the
> > > observation that the smoothness of animations suffered. Howe
== Series Details ==
Series: series starting with [1/2] drm/i915/execlists: Avoid reusing the same
logical CCID
URL : https://patchwork.freedesktop.org/series/76570/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_8377 -> Patchwork_17485
On Mon, Apr 27, 2020 at 10:07:06AM -0700, Rodrigo Vivi wrote:
> On Mon, Apr 27, 2020 at 11:18:46AM -0400, Alexei Podtelezhnikov wrote:
> > On Mon, Apr 27, 2020 at 10:45 AM Chris Wilson
> > wrote:
> > >
> > > Quoting Alexei Podtelezhnikov (2020-04-27 15:40:42)
> > > > >
> > > > > These do not exis
Hi Chris,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on drm-intel/for-linux-next]
[also build test ERROR on drm-tip/drm-tip]
[cannot apply to v5.7-rc3 next-20200424]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system. B
Hi Chris,
On Mon, Apr 27, 2020 at 09:54:04AM +0100, Chris Wilson wrote:
> Pull the boolean intel_rps.enabled and intel_rps.active into a single
> flags field, in preparation for more.
>
> Signed-off-by: Chris Wilson
Reviewed-by: Andi Shyti
Thanks,
Andi
== Series Details ==
Series: Remove drm_display_mode.hsync
URL : https://patchwork.freedesktop.org/series/76564/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8375_full -> Patchwork_17483_full
Summary
---
**SUCCESS**
Hi Chris,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on drm-intel/for-linux-next]
[also build test WARNING on drm-tip/drm-tip]
[cannot apply to v5.7-rc3 next-20200424]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the s
This implements a simple variably low-pass-filtering governor in
control of the HWP MIN/MAX PERF range based on the previously
introduced get_vlp_target_range(). See "cpufreq: intel_pstate:
Implement VLP controller statistics and target range calculation." for
the rationale.
v3: Fix accidental ov
Trivial.
Signed-off-by: Francisco Jerez
---
drivers/cpufreq/intel_pstate.c | 24
1 file changed, 12 insertions(+), 12 deletions(-)
diff --git a/drivers/cpufreq/intel_pstate.c b/drivers/cpufreq/intel_pstate.c
index 66ab6523c3eb..49401cfe9858 100644
--- a/drivers/cpufreq/
The goal of the statistics calculation code introduced here is to
compute two informational data structures: struct vlp_input_stats
aggregating various scheduling and PM statistics gathered in every
call of the update_util() hook, and struct vlp_status_sample which
contains status information deriv
v3: Rename CPU_RESPONSE_FREQUENCY to CPU_SCALING_RESPONSE (Rafael).
Signed-off-by: Francisco Jerez
---
drivers/gpu/drm/i915/i915_debugfs.c | 69 +
1 file changed, 69 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
This allows CPUFREQ governors to realize when the system becomes
non-CPU-bound due to GPU rendering activity, and cause them to respond
more conservatively to the workload by limiting their response
frequency: CPU energy usage will be reduced when there isn't a good
chance for system performance to
The purpose of this PM QoS limit is to give device drivers additional
control over the latency/energy efficiency trade-off made by the PM
subsystem (particularly the CPUFREQ governor). It allows device
drivers to set a lower bound on the response latency of PM (defined as
the time it takes from wa
And let it figure out whether an update_util hook is needed, and what
the appropriate function pointer is based on the CPUFREQ policy of the
current CPU.
Signed-off-by: Francisco Jerez
---
drivers/cpufreq/intel_pstate.c | 22 +++---
1 file changed, 7 insertions(+), 15 deletions(-
This defines a generic policy in addition to the existing PERFORMANCE
and POWERSAVE policies. The ADAPTIVE policy is expected to provide a
variable trade-off between performance and energy efficiency based on
the dynamic behavior of the workload -- E.g. whether the system has a
bottleneck on the C
For the moment the VLP controller is only enabled on ICL platforms
other than server FADT profiles in order to reduce the validation
effort of the initial submission. It should work on any other
processors that support HWP though (and soon enough on non-HWP too):
In order to override the default b
This is not required for the controller to work but has proven very
useful for debugging and testing of alternative heuristic parameters,
which may offer a better trade-off between energy efficiency and
latency. A warning is printed out which should taint the kernel for
the non-standard calibratio
1 - 100 of 108 matches
Mail list logo
