== Series Details ==
Series: drm/i915: Remove dubious Valleyview PCI IDs
URL : https://patchwork.freedesktop.org/series/76578/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8377 -> Patchwork_17488
Summary
---
**SUCCE
== Series Details ==
Series: drm/i915: Remove dubious Valleyview PCI IDs
URL : https://patchwork.freedesktop.org/series/76578/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
2efbc6a316e7 drm/i915: Remove dubious Valleyview PCI IDs
-:7: ERROR:GIT_COMMIT_ID: Please use git commit
== Series Details ==
Series: drm/i915: Add PCI IDs for Skylake GT1.5
URL : https://patchwork.freedesktop.org/series/76577/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8377 -> Patchwork_17487
Summary
---
**SUCCESS**
0x0155 is rather Ivy Bridge PCI-E Root Port.
0x0157 from the same commit ff049b6ce21d2814451afd4a116d001712e0116b
is likely wrong too. Nowhere is it independetly confirmed or mentioned.
Signed-off-by: Alexei Podtelezhnikov
---
include/drm/i915_pciids.h | 4 +---
1 file changed, 1 insertion(+), 3
These devices are also known as iSKLULTGT15 and iSKLDTGT15.
Signed-off-by: Alexei Podtelezhnikov
---
include/drm/i915_pciids.h | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/src/i915_pciids.h b/src/i915_pciids.h
index 1d2c1221..a9c88eab 100644
--- a/include/drm/i915_pciid
== Series Details ==
Series: series starting with [PATCHv2.99,01/11] PM: QoS: Add
CPU_SCALING_RESPONSE global PM QoS limit.
URL : https://patchwork.freedesktop.org/series/76576/
State : failure
== Summary ==
Applying: PM: QoS: Add CPU_SCALING_RESPONSE global PM QoS limit.
Applying: drm/i915:
Signed-off-by: Francisco Jerez
---
drivers/cpufreq/intel_pstate.c | 9 ++---
include/trace/events/power.h | 13 +
2 files changed, 15 insertions(+), 7 deletions(-)
diff --git a/drivers/cpufreq/intel_pstate.c b/drivers/cpufreq/intel_pstate.c
index 2458a821195f..dd86505d7855 100
This addresses the technical concerns people brought up about my
previous v2 revision of this series. Other than a few bug fixes, the
only major change relative to v2 is that the controller is now exposed
as a new CPUFREQ generic governor as requested by Rafael (named
"adaptive" in this RFC though
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
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
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
== 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,
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
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
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
== 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
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
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
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 ++-
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
== 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
==
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: 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,
> 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,
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
== 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
== 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
---
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/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
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: 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
==
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
> > ---
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: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/
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
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/
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
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
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
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 +
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
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
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
== 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
== 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 : warning
== Summary ==
$ dim checkpatch origin/drm-tip
0411865923e7 drm/i915/gt: Fix up clock frequency
-:159: CHECK:USLEEP_RANGE: usleep_range is preferred over
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 (rev4)
URL : https://patchwork.freedesktop.org/series/76512/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_8373 -> Patchwork_17479
Summary
---
**FAILUR
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
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
== 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
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
>
> 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
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
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
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
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 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 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
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 (rev2)
URL : https://patchwork.freedesktop.org/series/76512/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_8372 -> Patchwork_17476
Summary
---
**FAILUR
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
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 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
== 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
===
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
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
== 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
== 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: 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: 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: 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
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
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
== 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*
== 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: 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
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
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
== 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
== 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
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: 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
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
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
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
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
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
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(-)
1 - 100 of 108 matches
Mail list logo
