On Fri, 02 Mar 2018, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Parametrize the DVO pipe select bits.
>
> For consistency with the new way of doing things, let's read out the
> pipe select bits even when the port is disable, even though we don't
> need that behaviour for asserts in this case.
On Fri, 02 Mar 2018, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Almost all of the GEN7 checks in the DP code are actually looking for
> IVB. HSW doesn't even take these codepaths, and VLV is excluded on
> account of not having port A. So let's change the checks to IS_IVB to
> make the code le
On Fri, 02 Mar 2018, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> The ddi code no longer uses intel_ddi_get_crtc_new_encoder(). Move it
> elsewhere where we have some users left.
>
> Signed-off-by: Ville Syrjälä
A bit sad for adding more stuff to intel_display.c, but seems like a
better match
On 3/19/2018 8:58 PM, Michal Wajdeczko wrote:
There is no need to mix parameter types in public CT functions
as we can always accept intel_guc_ct.
Signed-off-by: Michal Wajdeczko
Cc: Sagar Arun Kamble
Cc: Chris Wilson
---
drivers/gpu/drm/i915/intel_guc_ct.c | 34 --
In one of our bugs we very rarely see a lockdep splat on boot-up. The
locking loop only happens when the console_sem semaphore is contended
in a specific path, which doesn't happen all too often. Help out
lockdep a bit with a might_lock annotation.
For reference, the full splat:
WARNING: CPU: 0 P
== Series Details ==
Series: semaphore: might_lock(->pi_lock) in up()
URL : https://patchwork.freedesktop.org/series/40256/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
757a703afe1d semaphore: might_lock(->pi_lock) in up()
-:24: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped
== Series Details ==
Series: semaphore: might_lock(->pi_lock) in up()
URL : https://patchwork.freedesktop.org/series/40256/
State : success
== Summary ==
Series 40256v1 semaphore: might_lock(->pi_lock) in up()
https://patchwork.freedesktop.org/api/1.0/series/40256/revisions/1/mbox/
Known
On Fri, 02 Mar 2018, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Parametrize the TRANS_DP_PORT_SEL macros.
>
> Signed-off-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/i915_reg.h | 8 +++-
> drivers/gpu/drm/i915/intel_display.c | 23 +++
> 2 files changed, 10 i
When changing the default values for guc_log_level, we accidentally left
the log enabled on non-guc platforms. Let's fix that.
v2: Define the levels used and remove (now obsolete) comments (Chris)
Fixes: 9605d1ce7c6b ("drm/i915/guc: Default to non-verbose GuC logging")
Reported-by: Chris Wilson
At least trackpoint_disconnect wants to remove some sysfs files, and
we can't remove sysfs files while holding psmouse_mutex:
==
WARNING: possible circular locking dependency detected
4.16.0-rc5-g613eb885b69e-drmtip_1+ #1 Tainted: G U
---
Level is unsigned, so not less than 0 (line 230).
julia
-- Forwarded message --
Date: Tue, 20 Mar 2018 16:39:16 +0800
From: kbuild test robot
To: kbu...@01.org
Cc: Julia Lawall
Subject: [drm-intel:drm-intel-next-queued 13/14]
drivers/gpu/drm/i915/intel_guc.c:230:12-17: WARNI
== Series Details ==
Series: semaphore: might_lock(->pi_lock) in up()
URL : https://patchwork.freedesktop.org/series/40256/
State : success
== Summary ==
Known issues:
Test kms_cursor_legacy:
Subgroup 2x-long-flip-vs-cursor-legacy:
incomplete -> PASS (shard-
== Series Details ==
Series: drm/i915/guc: Don't try to enable GuC logging when we're not using GuC
(rev2)
URL : https://patchwork.freedesktop.org/series/40239/
State : success
== Summary ==
Series 40239v2 drm/i915/guc: Don't try to enable GuC logging when we're not
using GuC
https://patchwo
== Series Details ==
Series: input/psmouse: Don't hold the mutex while calling ->disconnect
URL : https://patchwork.freedesktop.org/series/40259/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
cc6c0846e22c input/psmouse: Don't hold the mutex while calling ->disconnect
-:18: WARN
== Series Details ==
Series: input/psmouse: Don't hold the mutex while calling ->disconnect
URL : https://patchwork.freedesktop.org/series/40259/
State : success
== Summary ==
Series 40259v1 input/psmouse: Don't hold the mutex while calling ->disconnect
https://patchwork.freedesktop.org/api/1.
On Mon, Mar 19, 2018 at 11:24:17PM -0700, Lucas De Marchi wrote:
> This will allow the struct to be embedded in intel_shared_dpll.
>
> Signed-off-by: Lucas De Marchi
> ---
> drivers/gpu/drm/i915/intel_dpll_mgr.c | 7 ---
> drivers/gpu/drm/i915/intel_dpll_mgr.h | 10 ++
> 2 files cha
On Mon, Mar 19, 2018 at 11:24:16PM -0700, Lucas De Marchi wrote:
>
> This is an alternative to my previous patch
> "drm/i915: Remove hole and padding from intel_shared_dpll".
>
> Not sure if I split this too much, but I think it's easier to review
> this way. We can always squash them if wanted.
Not all callers want the GPU error to handled in the same way, so expose
a control parameter. In the first instance, some callers do not want the
heavyweight error capture so add a bit to request the state to be
captured and saved.
v2: Pass msg down to i915_reset/i915_reset_engine so that we inclu
If the GPU is stuck waiting for an event or for a semaphore, we need to
reset the GPU in order to recover. We have to tell the reset routine
which engines we want reset, but we were still using the old interface
and declaring it as "not-fatal".
Fixes: 14b730fcb8d9 ("drm/i915/tdr: Prepare error han
== Series Details ==
Series: series starting with [1/2] drm/i915: Specify which engines to reset
following semaphore/event lockups
URL : https://patchwork.freedesktop.org/series/40265/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
02b19c71acb4 drm/i915: Specify which engines t
== Series Details ==
Series: series starting with [1/2] drm/i915: Specify which engines to reset
following semaphore/event lockups
URL : https://patchwork.freedesktop.org/series/40265/
State : success
== Summary ==
Series 40265v1 series starting with [1/2] drm/i915: Specify which engines to
== Series Details ==
Series: drm/i915/guc: Don't try to enable GuC logging when we're not using GuC
(rev2)
URL : https://patchwork.freedesktop.org/series/40239/
State : success
== Summary ==
Known issues:
Test gem_exec_suspend:
Subgroup basic-s3:
pass -> IN
Quoting Michał Winiarski (2018-03-20 08:49:29)
> When changing the default values for guc_log_level, we accidentally left
> the log enabled on non-guc platforms. Let's fix that.
>
> v2: Define the levels used and remove (now obsolete) comments (Chris)
>
> Fixes: 9605d1ce7c6b ("drm/i915/guc: Defau
== Series Details ==
Series: input/psmouse: Don't hold the mutex while calling ->disconnect
URL : https://patchwork.freedesktop.org/series/40259/
State : success
== Summary ==
Known issues:
Test gem_softpin:
Subgroup noreloc-s3:
dmesg-warn -> PASS (shard-snb
Hi Ulrich,
Thank you for the patch.
On Thursday, 15 March 2018 16:45:38 EET Ulrich Hecht wrote:
> Fixes false negatives on non-i915 platforms.
>
> Signed-off-by: Ulrich Hecht
> ---
> tests/kms_panel_fitting.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/tests/kms_panel_fitting.c b
Hi Ulrich,
Thank you for the patch.
On Thursday, 15 March 2018 16:45:37 EET Ulrich Hecht wrote:
> Add is_i915_device() requirement to tests using Intel-specific APIs.
>
> Signed-off-by: Ulrich Hecht
Reviewed-by: Laurent Pinchart
> ---
> tests/kms_addfb_basic.c | 3 +++
> 1 file changed, 3 i
Hello,
On Monday, 19 March 2018 18:41:05 EET Ulrich Hecht wrote:
> On Fri, Mar 16, 2018 at 9:55 AM, Daniel Vetter wrote:
> > On Thu, Mar 15, 2018 at 03:45:36PM +0100, Ulrich Hecht wrote:
> >> Hi!
> >>
> >> I have run the tests on a Renesas R-Car M3-W's DU device, and have found
> >> a number of
When changing the default values for guc_log_level, we accidentally left
the log enabled on non-guc platforms. Let's fix that.
v2: Define the levels used and remove (now obsolete) comments (Chris)
v3: Use "IS" rather than "TO" for booleans (Chris)
Fixes: 9605d1ce7c6b ("drm/i915/guc: Default to no
== Series Details ==
Series: series starting with [1/2] drm/i915: Specify which engines to reset
following semaphore/event lockups
URL : https://patchwork.freedesktop.org/series/40265/
State : failure
== Summary ==
Possible new issues:
Test kms_flip_tiling:
Subgroup flip-changes
== Series Details ==
Series: drm/i915/guc: Don't try to enable GuC logging when we're not using GuC
(rev3)
URL : https://patchwork.freedesktop.org/series/40239/
State : success
== Summary ==
Series 40239v3 drm/i915/guc: Don't try to enable GuC logging when we're not
using GuC
https://patchwo
select in Kconfig isn't recursive, we need to select the stuff our
selects select, too. Fix that.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/Kconfig.debug | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/i915/Kconfig.debug
b/drivers/gpu/drm/i915/Kconfig.debug
index
On Tue, 20 Mar 2018 08:24:14 +0100, Sagar Arun Kamble
wrote:
On 3/19/2018 8:58 PM, Michal Wajdeczko wrote:
There is no need to mix parameter types in public CT functions
as we can always accept intel_guc_ct.
Signed-off-by: Michal Wajdeczko
Cc: Sagar Arun Kamble
Cc: Chris Wilson
---
d
== Series Details ==
Series: drm/i915: Select STACKDEPOT for DRM_I915_DEBUG
URL : https://patchwork.freedesktop.org/series/40274/
State : failure
== Summary ==
Series 40274v1 drm/i915: Select STACKDEPOT for DRM_I915_DEBUG
https://patchwork.freedesktop.org/api/1.0/series/40274/revisions/1/mbox/
Quoting Daniel Vetter (2018-03-20 12:50:09)
> select in Kconfig isn't recursive, we need to select the stuff our
> selects select, too. Fix that.
Really? That's quite painful.
That will limit the usefulness but on the other hand avoid
the illegal configurations all over.
> Signed
From: Tvrtko Ursulin
More than one test assumes that the spinner is running pretty much
immediately after we have create or submitted it.
In actuality there is a variable delay, especially on execlists platforms,
between submission and spin batch starting to run on the hardware.
To enable tests
We do end up setting ring frequencies on a hardware
which is not yet there wrt runtime pm enablement.
Instead of ending up in an endless loop iterating through
frequencies if min and max frequencies are still set to zero,
warn and bail out early.
Cc: Chris Wilson
Signed-off-by: Mika Kuoppala
--
On 3/20/2018 3:04 AM, Chris Wilson wrote:
If the GPU is stuck waiting for an event or for a semaphore, we need to
reset the GPU in order to recover. We have to tell the reset routine
which engines we want reset, but we were still using the old interface
and declaring it as "not-fatal".
Fixes: 14
On 3/20/2018 3:04 AM, Chris Wilson wrote:
Not all callers want the GPU error to handled in the same way, so expose
a control parameter. In the first instance, some callers do not want the
heavyweight error capture so add a bit to request the state to be
captured and saved.
v2: Pass msg down to i
On Tue, Mar 20, 2018 at 01:19:01PM +, Chris Wilson wrote:
> Quoting Daniel Vetter (2018-03-20 12:50:09)
> > select in Kconfig isn't recursive, we need to select the stuff our
> > selects select, too. Fix that.
>
> Really? That's quite painful.
>
> That will limit the usefulness but on
Quoting Mika Kuoppala (2018-03-20 13:58:42)
> We do end up setting ring frequencies on a hardware
> which is not yet there wrt runtime pm enablement.
>
> Instead of ending up in an endless loop iterating through
> frequencies if min and max frequencies are still set to zero,
> warn and bail out ea
== Series Details ==
Series: drm/i915/pm: Warn if rpm frequencies are not set
URL : https://patchwork.freedesktop.org/series/40281/
State : success
== Summary ==
Series 40281v1 drm/i915/pm: Warn if rpm frequencies are not set
https://patchwork.freedesktop.org/api/1.0/series/40281/revisions/1/m
Mika Kuoppala writes:
> From: Kelvin Gardiner
>
> ICL 11 has a greater number of maximum subslices. This patch
> reflects this.
>
> v2: GEN11 updates to MCR_SELECTOR (Oscar)
> v3: Copypasta error in the new defines (Lionel)
>
> Bspec: 21139
> BSpec: 21108
>
> Signed-off-by: Kelvin Gardiner
> Re
Chris Wilson writes:
> Quoting Mika Kuoppala (2018-03-20 13:58:42)
>> We do end up setting ring frequencies on a hardware
>> which is not yet there wrt runtime pm enablement.
>>
>> Instead of ending up in an endless loop iterating through
>> frequencies if min and max frequencies are still set t
== Series Details ==
Series: drm/i915/guc: Don't try to enable GuC logging when we're not using GuC
(rev3)
URL : https://patchwork.freedesktop.org/series/40239/
State : success
== Summary ==
Known issues:
Test kms_flip:
Subgroup flip-vs-expired-vblank-interruptible:
Quoting Patchwork (2018-03-20 14:52:05)
> == Series Details ==
>
> Series: drm/i915/guc: Don't try to enable GuC logging when we're not using
> GuC (rev3)
> URL : https://patchwork.freedesktop.org/series/40239/
> State : success
>
> == Summary ==
>
No more editing, pushed! Thanks,
-Chris
___
Quoting Michel Thierry (2018-03-20 14:11:03)
> On 3/20/2018 3:04 AM, Chris Wilson wrote:
> > Not all callers want the GPU error to handled in the same way, so expose
> > a control parameter. In the first instance, some callers do not want the
> > heavyweight error capture so add a bit to request th
On 3/20/2018 6:30 PM, Michal Wajdeczko wrote:
On Tue, 20 Mar 2018 08:24:14 +0100, Sagar Arun Kamble
wrote:
On 3/19/2018 8:58 PM, Michal Wajdeczko wrote:
There is no need to mix parameter types in public CT functions
as we can always accept intel_guc_ct.
Signed-off-by: Michal Wajdeczko
This functionality is used by new OCL drvier (aka. NEO):
https://github.com/intel/compute-runtime
Starting from commit: 933312e0986d3a7c1ef557e511eb4ced301ea292
-Original Message-
From: Joonas Lahtinen [mailto:joonas.lahti...@linux.intel.com]
Sent: Monday, March 19, 2018 2:54 PM
To: Lis
Warn on enabling rps when our hw max is invalid.
Cc: Chris Wilson
Signed-off-by: Mika Kuoppala
---
drivers/gpu/drm/i915/intel_pm.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 19e82aaa9863..bc335c52a17a 100644
---
Looping through rps frequencies when both min and max are zero
ends up into an endless loop. This can happen during hardware
enablement.
Bail out early if rps frequencies are not correctly set yet.
Cc: Chris Wilson
Signed-off-by: Mika Kuoppala
---
drivers/gpu/drm/i915/intel_pm.c | 9 ++---
== Series Details ==
Series: drm/i915/pm: Warn if rpm frequencies are not set
URL : https://patchwork.freedesktop.org/series/40281/
State : warning
== Summary ==
Possible new issues:
Test kms_mmio_vs_cs_flip:
Subgroup setcrtc_vs_cs_flip:
pass -> SKIP (
On Tue, Feb 27, 2018 at 12:08:25PM +0200, Ville Syrjälä wrote:
> On Wed, Feb 07, 2018 at 10:57:59AM -, Patchwork wrote:
> > == Series Details ==
> >
> > Series: YCBCR 4:2:0/4:4:4 output support for LSPCON (rev3)
> > URL : https://patchwork.freedesktop.org/series/36068/
> > State : warning
>
== Series Details ==
Series: series starting with [1/2] drm/i915: Avoid setting ring freq on invalid
rps freqs
URL : https://patchwork.freedesktop.org/series/40289/
State : warning
== Summary ==
Series 40289v1 series starting with [1/2] drm/i915: Avoid setting ring freq on
invalid rps freqs
Sometimes it's really easy to know which object has gone boom and
where the offending code is, and sometimes it's really hard. One case
we're trying to hunt down is when module unload catches a live debug
object, with a module with lots of them.
Capture a full stack trace from debug_object_init()
On Mon, Mar 19, 2018 at 05:56:54PM -0700, Michel Thierry wrote:
> Probably lost while rebasing commit eacd8391f977 ("drm/i915/guc: Keep GuC
> interrupts enabled when using GuC").
>
> Not really needed since i915_gem_init_hw is called before uc_resume, but
> it brings symmetry to uc_suspend.
>
> S
== Series Details ==
Series: RFC: debugobjects: capture stack traces at _init() time
URL : https://patchwork.freedesktop.org/series/40294/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
bf60db68fbc5 RFC: debugobjects: capture stack traces at _init() time
-:124: CHECK:SPACING: sp
There is no need to mix parameter types in public CT functions
as we can always accept intel_guc_ct.
v2: fix 'Return' doc, s/dev_priv/i915 (Sagar)
Signed-off-by: Michal Wajdeczko
Cc: Sagar Arun Kamble
Cc: Chris Wilson
Reviewed-by: Sagar Arun Kamble
---
drivers/gpu/drm/i915/intel_guc_ct.c | 4
Mika Kuoppala writes:
> Warn on enabling rps when our hw max is invalid.
>
> Cc: Chris Wilson
> Signed-off-by: Mika Kuoppala
> ---
> drivers/gpu/drm/i915/intel_pm.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
> in
== Series Details ==
Series: RFC: debugobjects: capture stack traces at _init() time
URL : https://patchwork.freedesktop.org/series/40294/
State : success
== Summary ==
Series 40294v1 RFC: debugobjects: capture stack traces at _init() time
https://patchwork.freedesktop.org/api/1.0/series/40294
== Series Details ==
Series: drm/i915/guc: Unify parameters of public CT functions (rev2)
URL : https://patchwork.freedesktop.org/series/40197/
State : success
== Summary ==
Series 40197v2 drm/i915/guc: Unify parameters of public CT functions
https://patchwork.freedesktop.org/api/1.0/series/40
On 2018-03-19 15:26, Chris Wilson wrote:
Quoting Lis, Tomasz (2018-03-19 14:14:19)
On 2018-03-19 13:43, Chris Wilson wrote:
Quoting Tomasz Lis (2018-03-19 12:37:35)
The patch adds a parameter to control the data port coherency functionality
on a per-exec call basis. When data port coherency
Quoting Mika Kuoppala (2018-03-20 16:28:20)
> Mika Kuoppala writes:
>
> > Warn on enabling rps when our hw max is invalid.
> >
> > Cc: Chris Wilson
> > Signed-off-by: Mika Kuoppala
> > ---
> > drivers/gpu/drm/i915/intel_pm.c | 2 ++
> > 1 file changed, 2 insertions(+)
> >
> > diff --git a/driv
We should avoid using guc_log prefix for functions that don't
operate on GuC log, but rather request action from the GuC.
Better to use guc_action prefix.
v2: rebase + naming compromise
v3: rebase
Signed-off-by: Michal Wajdeczko
Cc: Michal Winiarski
Cc: Sagar Arun Kamble
Reviewed-by: Michał Wi
Usually we use shift/mask macros for bit field definitions.
Union guc_log_control was not following that pattern.
Additional bonus:
add/remove: 0/0 grow/shrink: 0/1 up/down: 0/-25 (-25)
Function old new delta
intel_guc_log_level_set 3
While today we are modifying GuC enabled msg mask only in GuC
log, this code should be defined as generic GuC to allow future
code reuse.
Signed-off-by: Michal Wajdeczko
Cc: Michal Winiarski
Cc: Sagar Arun Kamble
Cc: Chris Wilson
Reviewed-by: Michał Winiarski
---
drivers/gpu/drm/i915/intel_g
From: Kelvin Gardiner
This patch adds support to detect ICL, slice, subslice and EU fuse
settings.
Add addresses for ICL 11 slice, subslice and EU fuses registers.
These register addresses are the same as previous platforms but the
format and / or the meaning of the information is different. The
On 3/19/2018 7:14 AM, Lis, Tomasz wrote:
On 2018-03-19 13:43, Chris Wilson wrote:
Quoting Tomasz Lis (2018-03-19 12:37:35)
The patch adds a parameter to control the data port coherency
functionality
on a per-exec call basis. When data port coherency flag value is
different
than what it was
On 20/03/18 18:37, Oscar Mateo wrote:
From: Kelvin Gardiner
This patch adds support to detect ICL, slice, subslice and EU fuse
settings.
Add addresses for ICL 11 slice, subslice and EU fuses registers.
These register addresses are the same as previous platforms but the
format and / or the mean
On Mon, Mar 19, 2018 at 12:50:49PM +, Michal Wajdeczko wrote:
> We already try to keep all GuC log related code in separate file,
> handling flush event should be placed there too. This will also
> allow future code reuse.
>
> v2: rebased
>
> Signed-off-by: Michal Wajdeczko
> Cc: Michal Wini
== Series Details ==
Series: series starting with [CI,1/3] drm/i915/guc: Unify naming of private GuC
action functions
URL : https://patchwork.freedesktop.org/series/40311/
State : success
== Summary ==
Series 40311v1 series starting with [CI,1/3] drm/i915/guc: Unify naming of
private GuC act
== Series Details ==
Series: drm/i915/icl: Added ICL 11 slice, subslice and EU fuse detection
URL : https://patchwork.freedesktop.org/series/40315/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
f61c5df8f12d drm/i915/icl: Added ICL 11 slice, subslice and EU fuse detection
-:32:
From: Ville Syrjälä
When doing forced load detection testing we should totally ignore any
hotplug status for the connector. This is mostly relevant for machines
where we already ignore the hotplug status based on the DMI quirks. On
other machines we would currently skip the force load detection t
From: Ville Syrjälä
Currently we're leaking fbs on load detect on account of nothing setting
up plane->old_fb for the drm_atomic_clean_old_fb() call in
drm_atomic_helper_commit_duplicated_state(). Removing the
drm_atomic_clean_old_fb() call seems like the right call to me here.
This does mean we
From: Ville Syrjälä
Keep the primary->crtc in sync with the state->crtc (also with
primary->fb and state->fb) when disabling the crtc (and thus also
the primary) via setcrtc().
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/drm_crtc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
di
From: Ville Syrjälä
drm_atomic_helper_commit_duplicated_state() should only be called
resume/reset/load_detect paths where plane->old_fb should always be
NULL and plane->fb should be equal to the new_plane_state->fb.
Assert that is indeed the case.
Cc: martin.pe...@free.fr
Cc: ch...@chris-wilson
From: Ville Syrjälä
Actually turn the planes back on after were done with
the load detection.
Fixes: 20bdc112bbe4 ("drm/i915: Disable all planes for load detection, v2.")
Cc: Maarten Lankhorst
Cc: Daniel Vetter
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_display.c | 2 ++
1 f
From: Ville Syrjälä
drm_atomic_helper_shutdown() needs to release the reference held by
plane->fb, so we want to use drm_atomic_clean_old_fb() in
drm_atomic_helper_disable_all(). However during suspend/resume, gpu
reset and load detection we should probably leave that stuff alone,
as otherwise we
== Series Details ==
Series: RFC: debugobjects: capture stack traces at _init() time
URL : https://patchwork.freedesktop.org/series/40294/
State : success
== Summary ==
Known issues:
Test gem_exec_suspend:
Subgroup basic-s3:
pass -> SKIP (shard-snb) fd
== Series Details ==
Series: drm/i915/icl: Added ICL 11 slice, subslice and EU fuse detection
URL : https://patchwork.freedesktop.org/series/40315/
State : success
== Summary ==
Series 40315v1 drm/i915/icl: Added ICL 11 slice, subslice and EU fuse detection
https://patchwork.freedesktop.org/ap
== Series Details ==
Series: series starting with [1/6] Revert "drm/atomic-helper: Fix leak in
disable_all"
URL : https://patchwork.freedesktop.org/series/40321/
State : success
== Summary ==
Series 40321v1 series starting with [1/6] Revert "drm/atomic-helper: Fix leak
in disable_all"
https:
From: Kelvin Gardiner
This patch adds support to detect ICL, slice, subslice and EU fuse
settings.
Add addresses for ICL 11 slice, subslice and EU fuses registers.
These register addresses are the same as previous platforms but the
format and / or the meaning of the information is different. The
== Series Details ==
Series: drm/i915/guc: Unify parameters of public CT functions (rev2)
URL : https://patchwork.freedesktop.org/series/40197/
State : success
== Summary ==
Known issues:
Test kms_setmode:
Subgroup basic:
pass -> FAIL (shard-apl) fdo#9
== Series Details ==
Series: drm/i915/icl: Added ICL 11 slice, subslice and EU fuse detection (rev2)
URL : https://patchwork.freedesktop.org/series/40315/
State : success
== Summary ==
Series 40315v2 drm/i915/icl: Added ICL 11 slice, subslice and EU fuse detection
https://patchwork.freedesktop
On Tue, 20 Mar 2018, Daniel Vetter wrote:
> Sometimes it's really easy to know which object has gone boom and
> where the offending code is, and sometimes it's really hard. One case
> we're trying to hunt down is when module unload catches a live debug
> object, with a module with lots of them.
>
Chamelium support requires igt_frame to be built, which requires both
GSL and Pixman.
Signed-off-by: Daniel Stone
---
meson.build | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/meson.build b/meson.build
index ef7017cb..5b783e5d 100644
--- a/meson.build
+++ b/meson.build
@@ -
== Series Details ==
Series: meson: Chamelium depends on GSL
URL : https://patchwork.freedesktop.org/series/40328/
State : success
== Summary ==
IGT patchset tested on top of latest successful build
94e886203a99ef19b8319489a45cd348e76e8ccd igt: Replace 'all-engines' magic
numbers with macro
On Tue, Mar 20, 2018 at 2:56 AM, Ville Syrjälä
wrote:
> On Mon, Mar 19, 2018 at 11:24:17PM -0700, Lucas De Marchi wrote:
>> This will allow the struct to be embedded in intel_shared_dpll.
>>
>> Signed-off-by: Lucas De Marchi
>> ---
>> drivers/gpu/drm/i915/intel_dpll_mgr.c | 7 ---
>> driver
This way we can stop copying fields from dpll_info to intel_shared_dpll
one by one. The migration of each field will come on separate patches.
Signed-off-by: Lucas De Marchi
---
drivers/gpu/drm/i915/intel_dpll_mgr.c | 1 +
drivers/gpu/drm/i915/intel_dpll_mgr.h | 5 +
2 files changed, 6 inser
v2:
- Make dpll_info a pointer inside intel_shared_dpll
- Add a patch to reorder dpll_info members
Lucas De Marchi (7):
drm/i915: move dpll_info to header
drm/i915: add dpll_info inside intel_shared_dpll
drm/i915: use funcs from intel_shared_dpll.info
drm/i915: use name from intel_shared_d
Remove 4-bytes hole in this struct an reorder tables accordingly. This
also changes the last element of the tables to be more future-proof.
Signed-off-by: Lucas De Marchi
---
drivers/gpu/drm/i915/intel_dpll_mgr.c | 48 +--
drivers/gpu/drm/i915/intel_dpll_mgr.h | 1
Replace all users of pll->name to use pll->info->name.
Signed-off-by: Lucas De Marchi
---
drivers/gpu/drm/i915/i915_debugfs.c | 3 ++-
drivers/gpu/drm/i915/intel_display.c | 7 ---
drivers/gpu/drm/i915/intel_dpll_mgr.c | 26 ++
drivers/gpu/drm/i915/intel_dpll_mgr
Replace all users of pll->flags to use pll->info.flags.
Signed-off-by: Lucas De Marchi
---
drivers/gpu/drm/i915/intel_display.c | 2 +-
drivers/gpu/drm/i915/intel_dpll_mgr.c | 2 --
drivers/gpu/drm/i915/intel_dpll_mgr.h | 18 --
3 files changed, 9 insertions(+), 13 deletions(-
Replace all users of pll->funcs.* to use
pll->info->funcs->*. The extra indirection here is not on any critical
path and we can leave all const data together.
Signed-off-by: Lucas De Marchi
---
drivers/gpu/drm/i915/intel_display.c | 16
drivers/gpu/drm/i915/intel_dpll_mgr.c |
This will allow the struct to be embedded in intel_shared_dpll.
Signed-off-by: Lucas De Marchi
---
drivers/gpu/drm/i915/intel_dpll_mgr.c | 7 ---
drivers/gpu/drm/i915/intel_dpll_mgr.h | 10 ++
2 files changed, 10 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel
Replace all users of pll->id to use pll->info->id. In functions using
this more than once it was preferred to add an id variable to make the
code easier to read.
Signed-off-by: Lucas De Marchi
---
drivers/gpu/drm/i915/i915_debugfs.c | 2 +-
drivers/gpu/drm/i915/intel_ddi.c | 8 +-
dri
== Series Details ==
Series: drm/i915: move dpll_info inside intel_shared_dpll (rev2)
URL : https://patchwork.freedesktop.org/series/40251/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
9ddcc8463efd drm/i915: move dpll_info to header
ccdf20dad80f drm/i915: add dpll_info inside
== Series Details ==
Series: drm/i915: move dpll_info inside intel_shared_dpll (rev2)
URL : https://patchwork.freedesktop.org/series/40251/
State : success
== Summary ==
Series 40251v2 drm/i915: move dpll_info inside intel_shared_dpll
https://patchwork.freedesktop.org/api/1.0/series/40251/revi
Interrupts other than the one for AUX errors are required only for debug,
so unmask them via debugfs when the user requests debug.
User can make such a request with
echo 1 > /dri/0/i915_edp_psr_debug
Cc: Rodrigo Vivi
Cc: Ville Syrjälä
Cc: Daniel Vetter
Signed-off-by: Dhinakaran Pandiyan
---
From: Daniel Vetter
The definitions for the error register should be valid on bdw/skl too,
but there we haven't even enabled DE_MISC handling yet.
Somewhat confusing the the moved register offset on bdw is only for
the _CTL/_AUX register, and that _IIR/IMR stayed where they have been
on bdw.
v2
Timestamps are useful for IGT tests that trigger PSR exit and/or wait for
PSR entry.
Cc: Ville Syrjälä
Cc: Rodrigo Vivi
Cc: Daniel Vetter
Signed-off-by: Dhinakaran Pandiyan
---
drivers/gpu/drm/i915/i915_debugfs.c | 12
drivers/gpu/drm/i915/i915_drv.h | 3 +++
drivers/gpu/drm
1 - 100 of 110 matches
Mail list logo