== Series Details ==
Series: drm/i915: conversion to new drm logging macros. (rev2)
URL : https://patchwork.freedesktop.org/series/72350/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
ad71a2dc560c drm/i915/atomic: use struct drm_device logging macros
1b633a003740 drm/i915/bios:
== Series Details ==
Series: drm/i915: conversion to new drm logging macros. (rev2)
URL : https://patchwork.freedesktop.org/series/72350/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_7787 -> Patchwork_16205
Summary
---
On Tue, 21 Jan 2020, "Vivi, Rodrigo" wrote:
> On Jan 21, 2020, at 4:01 AM, Joonas Lahtinen
> wrote:
>
> Quoting Jani Nikula (2020-01-21 12:30:20)
>
> It's been a long enough transition period since the DRM_I915_FORCE_PROBE
> config and i915.force_probe module parameter were introduced in com
On Fri, 17 Jan 2020, Lyude Paul wrote:
> Despite the fact that the VBT appears to have a field for specifying
> that a system is equipped with a panel that supports standard VESA
> backlight controls over the DP AUX channel, so far every system we've
> spotted DPCD backlight control support on doe
Platforms without a HW detiler doesn't support the get_tiling IOCTL.
Fix the drm_intel_bo_gem_create_from_* functions assuming the default
no-tiling, no-swizzling setting for the GEM buffer in this case.
v2:
- Add the missing gem handle IOCTL parameter. (Eric)
Signed-off-by: Imre Deak
Reviewed-b
On Tue, 21 Jan 2020, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Replace the drm_connector loops with intel_connector loops to
> streamline the code.
>
> Signed-off-by: Ville Syrjälä
Reviewed-by: Jani Nikula
> ---
> drivers/gpu/drm/i915/display/intel_hotplug.c | 83 +---
>
== Series Details ==
Series: drm/i915: drop alpha_support for good in favour of force_probe (rev2)
URL : https://patchwork.freedesktop.org/series/72326/
State : failure
== Summary ==
Applying: drm/i915: drop alpha_support for good in favour of force_probe
Using index info to reconstruct a base
From: Tvrtko Ursulin
With the introduction of dynamic subtests we got one step closer towards
eliminating the duality of static and dynamic engine enumeration.
This patch makes one more step in that direction by removing the
dependency on the static list when generating probed engine names.
Sig
On 22/01/2020 10:10, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
With the introduction of dynamic subtests we got one step closer towards
eliminating the duality of static and dynamic engine enumeration.
This patch makes one more step in that direction by removing the
dependency on the static
On Wed, Jan 22, 2020 at 10:15:56AM +, Tvrtko Ursulin wrote:
>
> On 22/01/2020 10:10, Tvrtko Ursulin wrote:
> > From: Tvrtko Ursulin
> >
> > With the introduction of dynamic subtests we got one step closer towards
> > eliminating the duality of static and dynamic engine enumeration.
> >
> >
On 21.01.2020 21:27, Alexey Budankov wrote:
>
> On 21.01.2020 20:55, Alexei Starovoitov wrote:
>> On Tue, Jan 21, 2020 at 9:31 AM Alexey Budankov
>> wrote:
>>>
>>>
>>> On 21.01.2020 17:43, Stephen Smalley wrote:
On 1/20/20 6:23 AM, Alexey Budankov wrote:
>
> Introduce CAP_PERFMON c
Since the introduction of preempt-to-busy, we leave the request on the
HW as we process the preemption request. This means that the request may
complete while it is on the submission queue, and once completed it may
be retired. We assumed that a single reference for the construction to
retirement l
Quoting Chris Wilson (2020-01-22 10:53:19)
> Since the introduction of preempt-to-busy, we leave the request on the
> HW as we process the preemption request. This means that the request may
> complete while it is on the submission queue, and once completed it may
> be retired. We assumed that a si
Keep the rq->fence.flags consistent with the status of the
rq->sched.link, and clear the associated bits when decoupling the link
on retirement (as we may wish to inspect those flags independent of
other state).
Fixes: 32ff621fd744 ("drm/i915/gt: Allow temporary suspension of inflight
requests")
If we encounter a hang on a virtual engine, as we process the hang the
request may already have been moved back to the virtual engine (we are
processing the hang on the physical engine). We need to reclaim the
request from the virtual engine so that the locking is consistent and
local to the real e
Thanks to preempt-to-busy, we leave the request on the HW as we submit
the preemption request. This means that the request may complete at any
moment as we process HW events, and in particular the request may be
retired as we are planning to capture it for a preemption timeout.
Be more careful whi
Quoting Chris Wilson (2020-01-22 11:29:03)
> Thanks to preempt-to-busy, we leave the request on the HW as we submit
> the preemption request. This means that the request may complete at any
> moment as we process HW events, and in particular the request may be
> retired as we are planning to captur
Thanks to preempt-to-busy, we leave the request on the HW as we submit
the preemption request. This means that the request may complete at any
moment as we process HW events, and in particular the request may be
retired as we are planning to capture it for a preemption timeout.
Be more careful whi
== Series Details ==
Series: drm/i915/execlists: Hold reference while on pqueue
URL : https://patchwork.freedesktop.org/series/72386/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
fd4e70d530f6 drm/i915/execlists: Hold reference while on pqueue
-:18: WARNING:COMMIT_LOG_LONG_LINE
== Series Details ==
Series: drm/i915/execlists: Hold reference while on pqueue
URL : https://patchwork.freedesktop.org/series/72386/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_7789 -> Patchwork_16207
Summary
---
We have two trace messages that rely on the function name for
distinction. However, if gcc inlines the function, the two traces end up
with the same function name and are indistinguishable. Add a different
message to each to clarify which one we hit, i.e. which phase of engine
parking we are proces
Quoting Fernando Pacheco (2020-01-22 00:18:22)
> Signed-off-by: Fernando Pacheco
> ---
> 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 947d0a38fa3c..4d
On 21/01/2020 14:11, Thomas Preston wrote:
> We're actually debugging this to close-in on *another* ZaphodHead+TearFree
> issue which appears on a 4.14 kernel (among other userland upgrades). At
> some point :0.0 head gets stuck between two buffers (current + shadow) and
> switches between the two
Chris Wilson writes:
> While we do flush writes to the vma before unbinding (to make sure they
> go through the right detiling register), we may also be concurrently
> poking at the GGTT_WRITE bit from set-domain, as we mark all GGTT vma
> associated with an object. We know this is for another vm
On 22/01/2020 11:34, Chris Wilson wrote:
Thanks to preempt-to-busy, we leave the request on the HW as we submit
the preemption request. This means that the request may complete at any
moment as we process HW events, and in particular the request may be
retired as we are planning to capture it f
On Tue, Jan 14, 2020 at 10:49 PM Pankaj Bharadiya
wrote:
>
> Add new struct drm_device based WARN* macros. These are modeled after
> the core kernel device based WARN* macros. These would be preferred
> over the regular WARN* macros, where possible.
>
> These macros include device information in t
On 21/01/2020 17:57, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2020-01-21 17:43:37)
On 21/01/2020 17:32, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2020-01-21 17:19:52)
On 21/01/2020 14:07, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2020-01-21 13:55:29)
On 21/01/2020 13:04, Chris W
On 22/01/2020 11:29, Chris Wilson wrote:
If we encounter a hang on a virtual engine, as we process the hang the
request may already have been moved back to the virtual engine (we are
processing the hang on the physical engine). We need to reclaim the
request from the virtual engine so that the
On 22/01/2020 11:29, Chris Wilson wrote:
Keep the rq->fence.flags consistent with the status of the
rq->sched.link, and clear the associated bits when decoupling the link
on retirement (as we may wish to inspect those flags independent of
other state).
Fixes: 32ff621fd744 ("drm/i915/gt: Allow
== Series Details ==
Series: series starting with [v2] drm/i915/execlists: Take a reference while
capturing the guilty request (rev2)
URL : https://patchwork.freedesktop.org/series/72391/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_7790 -> Patchwork_16208
==
Add a helper for calculating the rc buffer size from the DCPD offsets
DP_DSC_RC_BUF_BLK_SIZE and DP_DSC_RC_BUF_SIZE.
Cc: Alex Deucher
Cc: Harry Wentland
Cc: Manasi Navare
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/drm_dsc.c | 27 +++
include/drm/drm_dsc.h | 1
Make it possible to adjust the rc_model_size parameter instead of
hardcoding it all over the place. Only actually change the size for i915
DSI DSC.
Patch 3 for AMD isn't really required, but it felt like a natural
cleanup to incorporate.
Vandita, please check if this helps with the DSI DSC woes.
Use the new drm_dsc_dp_rc_buffer_size() helper to simplify rc buffer
size computation. No functional changes.
Cc: Alex Deucher
Cc: Harry Wentland
Cc: Manasi Navare
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/amd/display/dc/dsc/dc_dsc.c | 37 -
1 file changed, 7 insertio
The PPS is supposed to reflect the DSC config instead of hard coding the
rc_model_size. Make it so.
Currently all users of drm_dsc_pps_payload_pack() hard code the size to
8192 also in the DSC config, so this change should have no impact, other
than allowing the drivers to use other sizes as neede
The rc_model_size is specified in the DSC config, and the hardware
programming should respect that instead of hard coding a value of 8192.
Regardless, the rc_model_size in DSC config is currently hard coded to
the same value, so this should have no impact, other than allowing the
use of other size
Move the intialization of the rc_model_size from the common code into
encoder code, allowing different encoders to specify the size according
to their needs. Keep using the hard coded value in the encoders for now
to make this a non-functional change.
Cc: Manasi Navare
Signed-off-by: Jani Nikula
The VBT fields match the DPCD data, so use the same helper.
Cc: Manasi Navare
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/display/intel_bios.c | 11 +++
1 file changed, 3 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_bios.c
b/drivers/gpu/drm/i91
Stop overriding the VBT defined value for rc_model_size.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/display/icl_dsi.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/icl_dsi.c
b/drivers/gpu/drm/i915/display/icl_dsi.c
index 2ca4b0382eb9..a7457303c62e 1
== Series Details ==
Series: drm/i915/gt: Include a tell-tale for engine parking
URL : https://patchwork.freedesktop.org/series/72392/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_7790 -> Patchwork_16209
Summary
---
Thanks to preempt-to-busy, we leave the request on the HW as we submit
the preemption request. This means that the request may complete at any
moment as we process HW events, and in particular the request may be
retired as we are planning to capture it for a preemption timeout.
Be more careful whi
== Series Details ==
Series: drm/dsc: fixes and cleanups around rc_model_size
URL : https://patchwork.freedesktop.org/series/72396/
State : failure
== Summary ==
CALLscripts/checksyscalls.sh
CALLscripts/atomic/check-atomics.sh
DESCEND objtool
CHK include/generated/compile.h
Allow a mask of features to be passed to drm_core_check_feature(). All
features in the mask are required.
v2:
- fix kernel-doc (Ville)
- add an extra variable for clarity (Ville)
Reviewed-by: Ville Syrjälä
Signed-off-by: Jani Nikula
---
include/drm/drm_drv.h | 12
1 file changed,
Keep the rq->fence.flags consistent with the status of the
rq->sched.link, and clear the associated bits when decoupling the link
on retirement (as we may wish to inspect those flags independent of
other state).
Fixes: 32ff621fd744 ("drm/i915/gt: Allow temporary suspension of inflight
requests")
If we encounter a hang on a virtual engine, as we process the hang the
request may already have been moved back to the virtual engine (we are
processing the hang on the physical engine). We need to reclaim the
request from the virtual engine so that the locking is consistent and
local to the real e
Use drm_core_check_feature() to ensure both the driver features and the
per-device driver features are taken into account when registering
debugfs files.
Reviewed-by: Ville Syrjälä
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/drm_debugfs.c | 5 +
1 file changed, 1 insertion(+), 4 deletion
On 2020-01-21 at 14:15:57 +0200, Jani Nikula wrote:
> On Tue, 21 Jan 2020, Ramalingam C wrote:
> > On 2020-01-20 at 11:19:54 +0530, Anshuman Gupta wrote:
> >> Content Protection property should be updated as per the kernel
> >> internal state. Let's say if Content protection is disabled
> >> by us
On 22/01/2020 12:41, Chris Wilson wrote:
We have two trace messages that rely on the function name for
distinction. However, if gcc inlines the function, the two traces end up
with the same function name and are indistinguishable. Add a different
message to each to clarify which one we hit, i.e
Hi Jani
Am 22.01.20 um 15:02 schrieb Jani Nikula:
> Allow a mask of features to be passed to drm_core_check_feature(). All
> features in the mask are required.
>
> v2:
> - fix kernel-doc (Ville)
> - add an extra variable for clarity (Ville)
>
> Reviewed-by: Ville Syrjälä
> Signed-off-by: Jani N
On Tue, Jan 21, 2020 at 12:39:55PM +0530, Ramalingam C wrote:
> As we are not using the sysfs infrastructure anymore, link to it is
> removed. And global srm data and mutex to protect it are removed,
> with required handling at revocation check function.
>
Hi Ram,
Thanks for taking this on. A few
On 22.01.2020 17:07, Stephen Smalley wrote:
> On 1/22/20 5:45 AM, Alexey Budankov wrote:
>>
>> On 21.01.2020 21:27, Alexey Budankov wrote:
>>>
>>> On 21.01.2020 20:55, Alexei Starovoitov wrote:
On Tue, Jan 21, 2020 at 9:31 AM Alexey Budankov
wrote:
>
>
> On 21.01.2020 17:43,
On Wed, 22 Jan 2020, Thomas Zimmermann wrote:
> Hi Jani
>
> Am 22.01.20 um 15:02 schrieb Jani Nikula:
>> Allow a mask of features to be passed to drm_core_check_feature(). All
>> features in the mask are required.
>>
>> v2:
>> - fix kernel-doc (Ville)
>> - add an extra variable for clarity (Ville
Chris Wilson writes:
> We have two trace messages that rely on the function name for
> distinction. However, if gcc inlines the function, the two traces end up
> with the same function name and are indistinguishable. Add a different
> message to each to clarify which one we hit, i.e. which phase
From: Tvrtko Ursulin
With the introduction of dynamic subtests we got one step closer towards
eliminating the duality of static and dynamic engine enumeration.
This patch makes one more step in that direction by removing the
dependency on the static list when generating probed engine names.
v2:
Quoting Mika Kuoppala (2020-01-22 14:39:19)
> Chris Wilson writes:
>
> > We have two trace messages that rely on the function name for
> > distinction. However, if gcc inlines the function, the two traces end up
> > with the same function name and are indistinguishable. Add a different
> > messag
Op 10-01-2020 om 19:32 schreef Ville Syrjala:
> From: Ville Syrjälä
>
> Let's do the intel_plane_copy_uapi_to_hw_state() before we bail out
> due to both old and new uapi.crtc being NULL. This will drop the
> reference to the old hw.fb for planes that are transitioning from
> being a slave plane t
Quoting Tvrtko Ursulin (2020-01-22 14:40:28)
> static void init_engine(struct intel_execution_engine2 *e2,
> int class, int instance, uint64_t flags)
> {
> - const struct intel_execution_engine2 *__e2;
> - static const char *unknown_name = "unknown",
> -
On 22/01/2020 14:46, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2020-01-22 14:40:28)
static void init_engine(struct intel_execution_engine2 *e2,
int class, int instance, uint64_t flags)
{
- const struct intel_execution_engine2 *__e2;
- static const cha
On Wed, 22 Jan 2020, Ramalingam C wrote:
> On 2020-01-21 at 14:15:57 +0200, Jani Nikula wrote:
>> On Tue, 21 Jan 2020, Ramalingam C wrote:
>> > On 2020-01-20 at 11:19:54 +0530, Anshuman Gupta wrote:
>> >> Content Protection property should be updated as per the kernel
>> >> internal state. Let's
On 22/01/2020 14:53, Tvrtko Ursulin wrote:
On 22/01/2020 14:46, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2020-01-22 14:40:28)
static void init_engine(struct intel_execution_engine2 *e2,
int class, int instance, uint64_t flags)
{
- const struct intel_execu
From: Tvrtko Ursulin
Engine class/instance have to be u16 for the virtual engine check to work.
Signed-off-by: Tvrtko Ursulin
Reported-by: Chris Wilson
---
lib/i915/gem_engine_topology.c | 2 +-
lib/igt_gt.h | 4 ++--
2 files changed, 3 insertions(+), 3 deletions(-)
diff --
== Series Details ==
Series: drm/i915: Don't show the blank process name for internal/simulated
errors
URL : https://patchwork.freedesktop.org/series/72337/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_7783_full -> Patchwork_16188_full
===
From: Tvrtko Ursulin
With the introduction of dynamic subtests we got one step closer towards
eliminating the duality of static and dynamic engine enumeration.
This patch makes one more step in that direction by removing the
dependency on the static list when generating probed engine names.
v2:
== Series Details ==
Series: series starting with [CI,1/3] drm/i915/execlists: Take a reference
while capturing the guilty request
URL : https://patchwork.freedesktop.org/series/72400/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
8f0868652c32 drm/i915/execlists: Take a refere
Hi Maarten/Maxime,
Please pull the drm_device based drm_WARN* macros from the topic
branch. I'll pull the same to drm-intel-next-queued.
I like to use the topic branch here, because due to timing it'll take
forever for the full feature route through drm-next and backmerges.
The baseline was ch
Hi Chris,
On Thursday, January 9, 2020 4:03:30 PM CET Chris Wilson wrote:
> Quoting Janusz Krzysztofik (2020-01-09 14:01:25)
> > On future hardware with missing GGTT BAR we won't be able to exercise
> > dma-buf access via that path. An alternative to basic-gtt subtest for
> > testing dma-buf acce
Hi
Am 22.01.20 um 15:27 schrieb Jani Nikula:
> On Wed, 22 Jan 2020, Thomas Zimmermann wrote:
>> Hi Jani
>>
>> Am 22.01.20 um 15:02 schrieb Jani Nikula:
>>> Allow a mask of features to be passed to drm_core_check_feature(). All
>>> features in the mask are required.
>>>
>>> v2:
>>> - fix kernel-do
On Wed, 22 Jan 2020, Sean Paul wrote:
> On Tue, Jan 14, 2020 at 10:49 PM Pankaj Bharadiya
> wrote:
>>
>> Add new struct drm_device based WARN* macros. These are modeled after
>> the core kernel device based WARN* macros. These would be preferred
>> over the regular WARN* macros, where possible.
>
Add new drm_core_check_all_features() function to check for a mask of
features. All features in the mask are required.
Redefine existing drm_core_check_feature() in terms of this function,
using the drm_driver_feature enum for the parameter.
v3:
- add drm_core_check_all_features() (Thomas)
v2:
-
Use drm_core_check_all_features() to ensure both the driver features and
the per-device driver features are taken into account when registering
debugfs files.
v2:
- use drm_core_check_all_features()
Cc: Ville Syrjälä
Cc: Thomas Zimmermann
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/drm_deb
The file is not part of the global drm resource and can be released
prior to take the global mutex to drop the open_count (and potentially
close) the drm device.
However, inside drm_close_helper() there are a number of dev->driver
callbacks that take the drm_device as the first parameter... Worryi
>-Original Message-
>From: Intel-gfx On Behalf Of Chris
>Wilson
>Sent: Monday, January 20, 2020 5:49 AM
>To: intel-gfx@lists.freedesktop.org
>Cc: Auld, Matthew
>Subject: [Intel-gfx] [PATCH 4/5] drm/i915/gem: Convert vm idr to xarray
>
>Replace the vm_idr + vm_idr_mutex to an XArray. The X
Quoting Ruhl, Michael J (2020-01-22 16:00:25)
> >-Original Message-
> >From: Intel-gfx On Behalf Of Chris
> >Wilson
> >@@ -876,23 +868,13 @@ int i915_gem_vm_create_ioctl(struct drm_device
> >*dev, void *data,
> > goto err_put;
> > }
> >
> >- err = mutex_loc
Hi
Am 22.01.20 um 16:50 schrieb Jani Nikula:
> Add new drm_core_check_all_features() function to check for a mask of
> features. All features in the mask are required.
>
> Redefine existing drm_core_check_feature() in terms of this function,
> using the drm_driver_feature enum for the parameter.
Hi
Am 22.01.20 um 16:50 schrieb Jani Nikula:
> Use drm_core_check_all_features() to ensure both the driver features and
> the per-device driver features are taken into account when registering
> debugfs files.
>
> v2:
> - use drm_core_check_all_features()
>
> Cc: Ville Syrjälä
> Cc: Thomas Zimm
Replace the vm_idr + vm_idr_mutex to an XArray. The XArray data
structure is now used to implement IDRs, and provides its own locking.
We can simply remove the IDR wrapper and in the process also remove our
extra mutex.
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
Reviewed-by: Michael J. Ruhl
>-Original Message-
>From: Chris Wilson
>Sent: Wednesday, January 22, 2020 11:09 AM
>To: Ruhl, Michael J ; intel-
>g...@lists.freedesktop.org
>Cc: Auld, Matthew
>Subject: RE: [Intel-gfx] [PATCH 4/5] drm/i915/gem: Convert vm idr to xarray
>
>Quoting Ruhl, Michael J (2020-01-22 16:00:25)
Quoting Ruhl, Michael J (2020-01-22 16:15:17)
>
>
> >-Original Message-
> >From: Chris Wilson
> >Sent: Wednesday, January 22, 2020 11:09 AM
> >To: Ruhl, Michael J ; intel-
> >g...@lists.freedesktop.org
> >Cc: Auld, Matthew
> >Subject: RE: [Intel-gfx] [PATCH 4/5] drm/i915/gem: Convert vm
On Wed, 15 Jan 2020, Pankaj Bharadiya
wrote:
> Device specific dev_WARN and dev_WARN_ONCE macros available in kernel
> include device information in the backtrace, so we know what device
> the warnings originate from.
>
> Similar to this, add new struct drm_device based drm_WARN* macros. These
>
Working with a userptr GEM object backed by any type of mapping to
another GEM object, not only GTT mapping currently examined bu the
test, may cause a currently unavoidable lockdep splat inside the i915
driver. Then, such operations are expected to fail in advance to
prevent from that badness to
On 22/01/2020 16:15, Chris Wilson wrote:
Replace the vm_idr + vm_idr_mutex to an XArray. The XArray data
structure is now used to implement IDRs, and provides its own locking.
We can simply remove the IDR wrapper and in the process also remove our
extra mutex.
Signed-off-by: Chris Wilson
Cc:
Double check that the i915_active is finally idle after waiting, and
flushing its callback, just in case we need to re-activate it, for
example to keep the vma alive a bit longer due to last minute HW
activity (e.g. saving the context before unbinding).
Closes: https://gitlab.freedesktop.org/drm/i
== Series Details ==
Series: drm/i915/execlists: Reclaim hanging virtual request (rev4)
URL : https://patchwork.freedesktop.org/series/72320/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_7783_full -> Patchwork_16189_full
S
== Series Details ==
Series: series starting with [CI,1/3] drm/i915/execlists: Take a reference
while capturing the guilty request
URL : https://patchwork.freedesktop.org/series/72400/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_7793 -> Patchwork_16211
=
Quoting Tvrtko Ursulin (2020-01-22 15:23:48)
> From: Tvrtko Ursulin
>
> With the introduction of dynamic subtests we got one step closer towards
> eliminating the duality of static and dynamic engine enumeration.
>
> This patch makes one more step in that direction by removing the
> dependency o
Quoting Tvrtko Ursulin (2020-01-22 15:23:49)
> From: Tvrtko Ursulin
>
> Engine class/instance have to be u16 for the virtual engine check to work.
>
> Signed-off-by: Tvrtko Ursulin
> Reported-by: Chris Wilson
I feel there may be more, but this seems to be a crucial one.
Reviewed-by: Chris Wi
This will calculaet the DC3CO exit delay only once per full modeset.
Cc: Imre Deak
Cc: Anshuman Gupta
Reviewed-by: Anshuman Gupta
Signed-off-by: José Roberto de Souza
---
drivers/gpu/drm/i915/display/intel_psr.c | 10 --
1 file changed, 4 insertions(+), 6 deletions(-)
diff --git a/dr
A recent change in BSpec allow us to change EXTLINE while transcoder
is enabled so this allow us to change it even when doing the first
fastset after taking over previous hardware state set by BIOS.
BIOS don't enable PSR, so if sink supports PSR it will be enabled on
the first fastset, so moving th
On Mon, 2020-01-20 at 19:47 +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Move the initial setup of state-
> >{cdclk,min_cdclk[],min_voltage_level[]}
> into intel_modeset_calc_cdclk(), and we'll move the counterparts into
> intel_cdclk_swap_state(). This encapsulates the cdclk state much
As we use a mutex to serialise the first acquire (as it may be a lengthy
operation), but only an atomic decrement for the release, we have to
be careful in case a second thread races and completes both
acquire/release as the first finishes its acquire.
Fixes: c9ad602feabe ("drm/i915: Split i915_ac
Double check that the i915_active is finally idle after waiting, and
flushing its callback, just in case we need to re-activate it, for
example to keep the vma alive a bit longer due to last minute HW
activity (e.g. saving the context before unbinding).
Closes: https://gitlab.freedesktop.org/drm/i
If we find ourselves waiting on a MI_SEMAPHORE_WAIT, either within the
user batch or in our own preamble, the engine raises a
GT_WAIT_ON_SEMAPHORE interrupt. We can unmask that interrupt and so
respond to a semaphore wait by yielding the timeslice, if we have
another context to yield to!
The only
<0> [198.668822] gem_exec-12460 193899010us : timeline_advance:
timeline_advance:387 GEM_BUG_ON(!atomic_read(&tl->pin_count))
<0> [198.668859] -
<4> [198.669619] [ cut here ]
<2> [198.669621] kernel BUG at drivers/gpu/drm/i915/gt/inte
On Mon, 2020-01-20 at 19:47 +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Move the min_cdclk[] and min_voltage_level[] arrays under the
> rest of the cdclk state. And while at it provide a simple
> helper (intel_cdclk_clear_state()) to clear the state during
> the ww_mutex backoff dance.
On Mon, 2020-01-20 at 19:47 +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Move all the old vs. new state shenanigans
> into intel_set_cdclk_{pre,post}_plane_update() so that the caller
> doesn't need to know any of it.
Reviewed-by: José Roberto de Souza
>
> Signed-off-by: Ville Syrjäl
On Mon, 2020-01-20 at 19:47 +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> I want to have a higher level cdclk state object so let's rename
> the current lower level thing to cdclk_config (because I lack
> imagination).
Reviewed-by: José Roberto de Souza
>
> Signed-off-by: Ville Syrjäl
On Mon, 2020-01-20 at 19:47 +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Use the same structure to store the cdclk state in both
> intel_atomic_state and dev_priv. First step towards proper
> old vs. new cdclk states.
>
Reviewed-by: José Roberto de Souza
> Signed-off-by: Ville Syrjäl
On Mon, 2020-01-20 at 19:47 +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Our current global state handling is pretty ad-hoc. Let's try to
> make it better by imitating the standard drm core private object
> approach.
>
> The reason why we don't want to directly use the private objects
>
On Wed, Jan 22, 2020 at 07:00:27PM +, Souza, Jose wrote:
> On Mon, 2020-01-20 at 19:47 +0200, Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > Our current global state handling is pretty ad-hoc. Let's try to
> > make it better by imitating the standard drm core private object
> > approach
>From commit 84b1ca2f0e68 ("drm/i915/uc: prefer intel_gt over i915
in GuC/HuC paths") we stopped using HUC_STATUS error -ENODEV only
to indicate lack of HuC hardware and we started to use this error
also for all other cases when HuC was not in use or supported.
Fix that by relying again on HAS_GT_
Using a clear page for scratch means that we have relatively benign
errors in case it is accidentally used, but that can be rather too
benign for debugging. If we poison the scratch, ideally it quickly
results in an obvious error.
Suggested-by: Mika Kuoppala
Signed-off-by: Chris Wilson
Cc: Mika
1 - 100 of 145 matches
Mail list logo
