On Tue, 2017-12-12 at 19:07 -0500, Sinan Kaya wrote:
> On 12/12/2017 9:04 AM, Joonas Lahtinen wrote:
> > Hi,
> >
> > I sent this individual i915 patch to our CI, and it is passing on
> > all platforms:
> >
> > https://patchwork.freedesktop.org/series/34822/
> >
> > Is it ok if I merge this to dr
On Tue, Dec 12, 2017 at 02:33:38PM +, Lionel Landwerlin wrote:
> On 12/12/17 11:19, Tvrtko Ursulin wrote:
> >
> > On 11/12/2017 21:05, Daniel Vetter wrote:
> > > On Mon, Dec 11, 2017 at 02:38:53PM +, Tvrtko Ursulin wrote:
> > > > On 11/12/2017 10:50, Joonas Lahtinen wrote:
> > > > > + Dani
On Tue, 2017-12-12 at 14:56 -0800, Jackie Li wrote:
> intel_guc_reg.h should only include definition for GuC registers
> and related register bits. GuC WOPCM related values should not
> be defined in intel_guc_reg.h
>
> This patch creates a better file structure by moving GuC WOPCM
> related defin
There are a set of values in the drm_display_info structure for each
connector which hold information derived from EDID. These are computed
in drm_add_display_info. Before this patch, that was only called in
drm_add_edid_modes. This meant that they were only set when EDID was
present and never rese
== Series Details ==
Series: drm: Update edid-derived drm_display_info fields at edid property set
[v2]
URL : https://patchwork.freedesktop.org/series/35271/
State : success
== Summary ==
Series 35271v1 drm: Update edid-derived drm_display_info fields at edid
property set [v2]
https://patchw
On Tue, 2017-12-12 at 14:56 -0800, Jackie Li wrote:
> Hardware may have specific restrictions on GuC WOPCM partition
> size versus HuC firmware size. With static WOPCM partitioning,
> there's no way to adjust the GuC WOPCM partition size based on
> the actual HuC firmware size, so that GuC/HuC load
crtc_mask is defined explicitly defined for a certain number of pipes per
platform. Let's generalize this in a way that crtc_mask dependens only on
the number of pipes defined in device info.
v2: Use BIT() macro wherever possible (Ville)
Drop generalization for all other connectors except DDI
> -Original Message-
> From: Takashi Iwai [mailto:ti...@suse.de]
> Sent: Tuesday, December 12, 2017 5:45 PM
> To: Chen, Augustine
> Cc: Ville Syrjälä ; Anand, Jerome
> ; Thomas Gleixner ; intel-
> g...@lists.freedesktop.org; alsa-de...@alsa-project.org; Bossart, Pierre-louis
> ; Ingo Mol
From: Arkadiusz Hiler
Compiler complained on crc_lowres and crc_hires2 being uninitialized
and indeed, display_commit_mode() seems to have intention of retruning
the value through the parameter that is only a single pointer.
This couses only the local copy of the pointer, the one inside
display_
From: Mahesh Kumar
PIPEC doesnt have 3rd plane in GEN9. So, we skip the
3rd plane related scaling test where 2nd OVERLAY
plane is not available.
Restricting downscaling to (9/10)x original size of the
image to avoid "Max pixel rate limitation" of the hardware.
Later patches in this series will
This series fixes the current scaler igt test failures and enhances
kms_plane_scaling and kms_plane for covering subtests below:
- verify all the supported pixel formats in planes
- combination of rotation and scaling
- combination of tiling and scaling
- multi-plane/multi-pipe scaling
It also enha
From: Mahesh Kumar
This patch adds a subtest related to pixel format testing. The test
create framebuffer with all supported pixel formats for primary and
sprite planes which can be drawn using cairo and commits the same on display.
Signed-off-by: Mahesh Kumar
Signed-off-by: Jyoti Yadav
Signed
From: Jyoti Yadav
Patch adds subtest to display primary and overlay planes on two
connected pipes and runs scaling test on both pipes
Signed-off-by: Jyoti Yadav
Signed-off-by: Mahesh Kumar
Signed-off-by: Vidya Srinivas
---
tests/kms_plane_scaling.c | 114 +
From: Jyoti Yadav
This patch adds subtest for testing scaling in combination with rotation
and pixel formats.
Signed-off-by: Jyoti Yadav
Signed-off-by: Mahesh Kumar
Signed-off-by: Vidya Srinivas
---
tests/kms_plane_scaling.c | 203 --
1 file change
From: Jyoti Yadav
This patch adds subtest to test scaler clipping and clamping
scenario
Signed-off-by: Jyoti Yadav
Signed-off-by: Mahesh Kumar
Signed-off-by: Vidya Srinivas
---
tests/kms_plane_scaling.c | 69 +++
1 file changed, 69 insertions(+)
d
From: Mahesh Kumar
This patch adds the following:
- Query supported pixel formats from kernel for a given
plane.
- Get number of supported pixel formats for a plane
- Check if format is supported by cairo
- Add support to get format name string
Signed-off-by: Mahesh Kumar
Signed-off-by: Jyoti Y
== Series Details ==
Series: drm/i915: Generalize definition for crtc mask (rev2)
URL : https://patchwork.freedesktop.org/series/34894/
State : success
== Summary ==
Series 34894v2 drm/i915: Generalize definition for crtc mask
https://patchwork.freedesktop.org/api/1.0/series/34894/revisions/2/
It is illegal to perform an immediate free of the struct irq_work from
inside the irq_work callback (as irq_work_run_list modifies work->flags
after execution of the work->func()). As we use the irq_work to
coordinate the freeing of the callback from two different softirq paths,
we need to defer th
== Series Details ==
Series: drm: Update edid-derived drm_display_info fields at edid property set
[v2]
URL : https://patchwork.freedesktop.org/series/35271/
State : success
== Summary ==
Test gem_pwrite:
Subgroup huge-gtt-backwards:
incomplete -> PASS (shard-hsw
On Tue, Dec 12, 2017 at 05:22:01PM +, Chris Wilson wrote:
> As a simple fail-safe against a bad installation, check the tools exist
> before testing whether they work.
>
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=102935
> Signed-off-by: Chris Wilson
> ---
> tests/tools_test.c |
== Series Details ==
Series: test/kms_plane_lowres: Fix display_commit_mode() so it returns the crc
(rev4)
URL : https://patchwork.freedesktop.org/series/34749/
State : success
== Summary ==
IGT patchset tested on top of latest successful build
74407418720ff7a9de7caabec05d4c3afe9a5c51 igt/kms
On Tue, 12 Dec 2017, Lucas De Marchi wrote:
> On Tue, Dec 12, 2017 at 1:53 AM, Joonas Lahtinen
> wrote:
>> + Jani, who'll continue with -fixes
>>
>> On Mon, 2017-12-11 at 13:50 -0800, Lucas De Marchi wrote:
>>> On Mon, Dec 11, 2017 at 2:26 AM, Joonas Lahtinen
>>> wrote:
>>> > On Fri, 2017-12-08
On Mon, 11 Dec 2017, Lucas De Marchi wrote:
> On Mon, Dec 11, 2017 at 2:26 AM, Joonas Lahtinen
> wrote:
>> On Fri, 2017-12-08 at 10:47 -0800, Lucas De Marchi wrote:
>>> CFL was missing from intel_early_ids[].
>>>
>>> Cc: Ingo Molnar
>>> Cc: H. Peter Anvin
>>> Cc: Thomas Gleixner
>>> Cc: x...@k
== Series Details ==
Series: drm/i915: Use rcu to defer freeing of irq_work
URL : https://patchwork.freedesktop.org/series/35277/
State : success
== Summary ==
Series 35277v1 drm/i915: Use rcu to defer freeing of irq_work
https://patchwork.freedesktop.org/api/1.0/series/35277/revisions/1/mbox/
== Series Details ==
Series: drm/i915: Generalize definition for crtc mask (rev2)
URL : https://patchwork.freedesktop.org/series/34894/
State : warning
== Summary ==
Test kms_frontbuffer_tracking:
Subgroup fbc-1p-offscren-pri-shrfb-draw-render:
pass -> FAIL
On Fri, Dec 08, 2017 at 02:06:46PM -0800, Lucas De Marchi wrote:
> This copies include/drm/i915_pciids.h from kernel as of drm-tip:
> drm-tip: 2017y-12m-08d-21h-06m-35s UTC + patch adding INTEL_CFL_IDS that
> was missing there[1]. The goal is to keep track of the PCI IDs in a
> single place (kernel
Sean,
Adding few more observations.
On Thursday 07 December 2017 05:47 AM, Sean Paul wrote:
Pretty simple test:
- initializes the output
- clears the content protection property
- verifies that it clears
- sets the content protection property to desired
- verifies that it transitions to enable
On Wed, 2017-12-13 at 10:35 +0100, Maarten Lankhorst wrote:
> From: Arkadiusz Hiler
>
> Compiler complained on crc_lowres and crc_hires2 being uninitialized
> and indeed, display_commit_mode() seems to have intention of
> retruning
> the value through the parameter that is only a single pointer.
PROBE_DEFER also uses system_wq to reprobe drivers, which means when
that again fails, and we try to flush the overall system_wq (to get
all the delayed connectore cleanup work_struct completed), we
deadlock.
Fix this by using just a single cleanup work, so that we can only
flush that one and don'
On Wed, 29 Nov 2017, Gustavo Padovan wrote:
> 2017-11-24 Sean Paul :
>
>> On Thu, Nov 23, 2017, 7:12 AM Jani Nikula wrote:
>>
>> > I'm juggling too many things, and drm-misc maintenance is one that I
>> > keep dropping on the floor. Admit reality and remove myself as
>> > maintainer. This still
On Tue, 2017-12-12 at 17:22 +, Chris Wilson wrote:
> As a simple fail-safe against a bad installation, check the tools exist
> before testing whether they work.
>
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=102935
> Signed-off-by: Chris Wilson
Reviewed-by: Joonas Lahtinen
Rega
On 13/12/2017 09:48, Chris Wilson wrote:
It is illegal to perform an immediate free of the struct irq_work from
inside the irq_work callback (as irq_work_run_list modifies work->flags
after execution of the work->func()). As we use the irq_work to
coordinate the freeing of the callback from two
On Tue, 2017-12-12 at 16:17 -0800, Lucas De Marchi wrote:
> On Tue, Dec 12, 2017 at 1:53 AM, Joonas Lahtinen
> wrote:
> > + Jani, who'll continue with -fixes
> >
> > On Mon, 2017-12-11 at 13:50 -0800, Lucas De Marchi wrote:
> > > On Mon, Dec 11, 2017 at 2:26 AM, Joonas Lahtinen
> > > wrote:
> >
Quoting Daniel Vetter (2017-12-13 10:45:53)
> PROBE_DEFER also uses system_wq to reprobe drivers, which means when
> that again fails, and we try to flush the overall system_wq (to get
> all the delayed connectore cleanup work_struct completed), we
> deadlock.
>
> Fix this by using just a single c
On Tue, 2017-12-12 at 13:21 +, Chris Wilson wrote:
> i915_gem_wait_for_idle() is called from inside the shrinker, to ensure
> that we drain the last resources from the GPU in dire circumstances (OOM).
> As we may allocate whilst building a request, it is then possible to hit
> the shrinker with
On Tue, 2017-12-12 at 18:06 +, Chris Wilson wrote:
> As kmalloc is allowed to block (if given the right flags), mark up the
> two i915_sw_fence routines that may call kmalloc as potential sleeping
> routines.
>
> Signed-off-by: Chris Wilson
> Cc: Tvrtko Ursulin
> Cc: Joonas Lahtinen
Review
== Series Details ==
Series: test/kms_plane_lowres: Fix display_commit_mode() so it returns the crc
(rev4)
URL : https://patchwork.freedesktop.org/series/34749/
State : warning
== Summary ==
Test pm_rc6_residency:
Subgroup rc6-accuracy:
pass -> SKIP (shard-
On Tue, 2017-12-12 at 18:06 +, Chris Wilson wrote:
> If a fence allocation fails in a blocking context, we will sleep on the
> fence as a last resort. We can therefore allow ourselves to fail and
> sleep on the fence instead of triggering a system-wide oom. This allows
> us to throttle maliciou
On Tue, 2017-12-12 at 18:06 +, Chris Wilson wrote:
> If we fail to allocate a request, we can reap the outstanding requests
> and push them to the request's slab's freelist before trying again. This
> forces us to ratelimit malicious clients that tie up all of the system
> resources in requests
Quoting Joonas Lahtinen (2017-12-13 11:15:23)
> On Tue, 2017-12-12 at 18:06 +, Chris Wilson wrote:
> > If a fence allocation fails in a blocking context, we will sleep on the
> > fence as a last resort. We can therefore allow ourselves to fail and
> > sleep on the fence instead of triggering a
Quoting Joonas Lahtinen (2017-12-13 11:18:42)
> On Tue, 2017-12-12 at 18:06 +, Chris Wilson wrote:
> > If we fail to allocate a request, we can reap the outstanding requests
> > and push them to the request's slab's freelist before trying again. This
> > forces us to ratelimit malicious clients
On Tue, 2017-12-12 at 21:43 +, Chris Wilson wrote:
> Having discovered that we would encounter an indefinite wait in the
> shrinker within execbuf/request construction, try to exercise that path
> by emitting lots of execbuf with fences (which require allocation inside
> request construction) w
On Wed, Dec 13, 2017 at 11:08:39AM +, Patchwork wrote:
> == Series Details ==
>
> Series: test/kms_plane_lowres: Fix display_commit_mode() so it returns the
> crc (rev4)
> URL : https://patchwork.freedesktop.org/series/34749/
> State : warning
>
> == Summary ==
>
> Test pm_rc6_residency:
On Wed, 13 Dec 2017, Anand, Jerome wrote:
> > -Original Message-
> > From: Thomas Gleixner [mailto:t...@linutronix.de]
> > Sent: Tuesday, December 12, 2017 10:37 PM
> > To: Anand, Jerome
> > Cc: Ville Syrjälä ; Chen, Augustine
> > ; intel-gfx@lists.freedesktop.org;
> > alsa-devel@alsa-
>
Quoting Joonas Lahtinen (2017-12-13 11:30:22)
> On Tue, 2017-12-12 at 21:43 +, Chris Wilson wrote:
> > Having discovered that we would encounter an indefinite wait in the
> > shrinker within execbuf/request construction, try to exercise that path
> > by emitting lots of execbuf with fences (whi
== Series Details ==
Series: drm: rework delayed connector cleanup in connector_iter
URL : https://patchwork.freedesktop.org/series/35282/
State : failure
== Summary ==
Series 35282v1 drm: rework delayed connector cleanup in connector_iter
https://patchwork.freedesktop.org/api/1.0/series/35282
== Series Details ==
Series: drm/i915: Use rcu to defer freeing of irq_work
URL : https://patchwork.freedesktop.org/series/35277/
State : success
== Summary ==
Test gem_softpin:
Subgroup noreloc-s4:
fail -> SKIP (shard-snb) fdo#103375
Test gem_tiled_swapping
On Wed, 13 Dec 2017 12:35:54 +0100,
Thomas Gleixner wrote:
>
> > > On Mon, 11 Dec 2017, Anand, Jerome wrote:
> > > > > On Fri, 8 Dec 2017, Ville Syrjälä wrote:
> > > > >
> > > > > > On Fri, Dec 08, 2017 at 05:33:23PM +0800, Augustine.Chen wrote:
> > > > > > > The chip data of HDMI LPE audio is set
Quoting Patchwork (2017-12-13 11:50:03)
> == Series Details ==
>
> Series: drm/i915: Use rcu to defer freeing of irq_work
> URL : https://patchwork.freedesktop.org/series/35277/
> State : success
>
> == Summary ==
>
> Test gem_softpin:
> Subgroup noreloc-s4:
> fail
Quoting Tvrtko Ursulin (2017-12-13 10:54:55)
>
> On 13/12/2017 09:48, Chris Wilson wrote:
> > It is illegal to perform an immediate free of the struct irq_work from
> > inside the irq_work callback (as irq_work_run_list modifies work->flags
> > after execution of the work->func()). As we use the i
Quoting Joonas Lahtinen (2017-12-13 11:07:01)
> On Tue, 2017-12-12 at 13:21 +, Chris Wilson wrote:
> > i915_gem_wait_for_idle() is called from inside the shrinker, to ensure
> > that we drain the last resources from the GPU in dire circumstances (OOM).
> > As we may allocate whilst building a r
Hi Daniel,
On 2017-12-13 11:45, Daniel Vetter wrote:
PROBE_DEFER also uses system_wq to reprobe drivers, which means when
that again fails, and we try to flush the overall system_wq (to get
all the delayed connectore cleanup work_struct completed), we
deadlock.
Fix this by using just a single c
On Wed, 2017-12-13 at 09:48 +, Chris Wilson wrote:
> It is illegal to perform an immediate free of the struct irq_work from
> inside the irq_work callback (as irq_work_run_list modifies work->flags
> after execution of the work->func()). As we use the irq_work to
> coordinate the freeing of the
Quoting Joonas Lahtinen (2017-12-13 12:34:10)
> On Wed, 2017-12-13 at 09:48 +, Chris Wilson wrote:
> > It is illegal to perform an immediate free of the struct irq_work from
> > inside the irq_work callback (as irq_work_run_list modifies work->flags
> > after execution of the work->func()). As
PROBE_DEFER also uses system_wq to reprobe drivers, which means when
that again fails, and we try to flush the overall system_wq (to get
all the delayed connectore cleanup work_struct completed), we
deadlock.
Fix this by using just a single cleanup work, so that we can only
flush that one and don'
We need shared data for actions (e.g. guc suspend/resume), and we're
using those with GuC submission disabled.
Let's introduce intel_guc_init and move shared data alloc there.
This fixes GPF during module unload with HuC, but without GuC submission:
BUG: unable to handle kernel NULL pointer deref
To make this operation a bit cleaner, we should make sure that the HW
can catch up by calling the new implementation right away.
Note that currently we're only touching the vfunc at module load time
(before GuC is even loaded), so this shouldn't cause any functional
changes.
Suggested-by: Chris Wi
After GPU reset, GuC HW needs to be reinitialized (with FW reload).
Unfortunately, we're doing some extra work there (mostly allocating stuff),
work that can be moved to guc_init and called once at driver load time.
As a side effect we're no longer hitting an assert in
i915_ggtt_enable_guc on susp
This gets rid of the following lockdep splat:
==
WARNING: possible circular locking dependency detected
4.15.0-rc2-CI-Patchwork_7428+ #1 Not tainted
--
debugfs_test/1351 is trying to acquire loc
Full GPU reset causes GuC to be reset. This means that every time we're
doing a reset, we need to talk to GuC and tell it about doorbells.
Let's separate the communication part (create_doorbell) from our
internal bookkeeping (reserve_doorbell) so that we can cleanly separate
the initialization done
We can now move the clients allocation to submission_init path, rather
than keeping the condition inside submission_enable called on every
reset.
Signed-off-by: Michał Winiarski
Cc: Chris Wilson
Cc: Joonas Lahtinen
Cc: Michal Wajdeczko
---
drivers/gpu/drm/i915/intel_guc_submission.c | 33
We have the selftest that's checking doorbell create/destroy, so there's
no need to check all doorbells delaying the reset every time.
We do want to have that extra sanity check at module load/unload though.
Signed-off-by: Michał Winiarski
Cc: Chris Wilson
Cc: Joonas Lahtinen
Cc: Michal Wajdecz
Also:
Revert "drm/i915/GuC/GLK: Load GuC on GLK"
Now that we no longer have fallback to execlists submission available,
if the firmware is selected by the driver but is not available on the
system (like in this case - where the FW is not yet released), we're
unable to get a clean CI run.
This re
Signed-off-by: Petri Latvala
Cc: Arkadiusz Hiler
---
scripts/run-tests.sh | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/scripts/run-tests.sh b/scripts/run-tests.sh
index acd2ae2f..a98e06ce 100755
--- a/scripts/run-tests.sh
+++ b/scripts/run-tests.sh
@@ -24,7 +24,7 @@
ROO
Original patch from Antonio Argenziano, split into separate commits
for its separate steps.
New directory created, tests/hw-tests, meant for tests that target the
hardware's behaviour more than the driver's (or the combination
thereof). Currently just gem_bad_address moved, with Antonio's
changes
From: Antonio Argenziano
When writing to an invalid memory location, the HW should be clever
enough to silently discard the write without disrupting execution.
gem_bad_address aim at just that. The test has been updated to move away
from the libDrm wrappers and use the IOCTL wrappers instead. Als
Since the test is considered to be HW focused, meaning that it doesn't
really exercise the driver but rather an HW feature, it is placed in
tests/hw-tests.
Signed-off-by: Petri Latvala
Cc: Antonio Argenziano
---
tests/Makefile.sources | 1 -
tests/hw-tests/Makefile.sources
The hw-tests subdirectory is meant for tests that target the
hardware's behaviour without the kernel having much say in
matters. Tests in the directory are not meant for regular CI runs, and
running them requires setting IGT_TEST_ROOT to that directory when
using piglit.
Signed-off-by: Petri Latva
Hi Daniel,
On 2017-12-13 13:49, Daniel Vetter wrote:
PROBE_DEFER also uses system_wq to reprobe drivers, which means when
that again fails, and we try to flush the overall system_wq (to get
all the delayed connectore cleanup work_struct completed), we
deadlock.
Fix this by using just a single c
Quoting Daniel Vetter (2017-12-13 12:49:36)
> PROBE_DEFER also uses system_wq to reprobe drivers, which means when
> that again fails, and we try to flush the overall system_wq (to get
> all the delayed connectore cleanup work_struct completed), we
> deadlock.
>
> Fix this by using just a single c
Quoting Petri Latvala (2017-12-13 12:58:14)
> Since the test is considered to be HW focused, meaning that it doesn't
> really exercise the driver but rather an HW feature, it is placed in
> tests/hw-tests.
Do we really want to keep this test at all? It's an interesting debate
whether we want to sh
Quoting Patchwork (2017-12-12 19:20:00)
> == Series Details ==
>
> Series: series starting with [1/3] drm/i915: Mark up potential allocation
> paths within i915_sw_fence as might_sleep
> URL : https://patchwork.freedesktop.org/series/35239/
> State : success
>
> == Summary ==
>
> Test gem_til
On Wed, Dec 13, 2017 at 01:05:49PM +, Chris Wilson wrote:
> Quoting Daniel Vetter (2017-12-13 12:49:36)
> > PROBE_DEFER also uses system_wq to reprobe drivers, which means when
> > that again fails, and we try to flush the overall system_wq (to get
> > all the delayed connectore cleanup work_st
Quoting Daniel Vetter (2017-12-13 08:17:17)
> On Tue, Dec 12, 2017 at 02:33:38PM +, Lionel Landwerlin wrote:
> > On 12/12/17 11:19, Tvrtko Ursulin wrote:
> > >
> > > On 11/12/2017 21:05, Daniel Vetter wrote:
> > > > On Mon, Dec 11, 2017 at 02:38:53PM +, Tvrtko Ursulin wrote:
> > > > > On 1
Since Michal introduced new errors other than -EIO during
i915_gem_init(), we need to actually unwind on the error path as we have
to abort the module load (and we expect to do so cleanly!).
As we now teardown key state and then mark the driver as wedged (on
EIO), we have to be careful to not allo
On Wed, Dec 13, 2017 at 12:44:26AM -0800, Keith Packard wrote:
> There are a set of values in the drm_display_info structure for each
> connector which hold information derived from EDID. These are computed
> in drm_add_display_info. Before this patch, that was only called in
> drm_add_edid_modes.
On Thu, 2017-11-30 at 16:19 +0100, Sebastian Andrzej Siewior wrote:
> The code has an ifdef and uses two functions to either init the bare
> spinlock or init it and set a lock-class. It is possible to do the same
> thing without an ifdef.
> With this patch (in debug case) we first use the "default"
On Wed, 13 Dec 2017, Takashi Iwai wrote:
> On Wed, 13 Dec 2017 12:35:54 +0100,
> Thomas Gleixner wrote:
> >
> > > > On Mon, 11 Dec 2017, Anand, Jerome wrote:
> > > > > > On Fri, 8 Dec 2017, Ville Syrjälä wrote:
> > > > > >
> > > > > > > On Fri, Dec 08, 2017 at 05:33:23PM +0800, Augustine.Chen wrot
On Thu, 07 Dec 2017 22:00:48 +0100, Daniel Vetter wrote:
On Thu, Dec 07, 2017 at 04:59:36PM +, Chris Wilson wrote:
Quoting Michal Wajdeczko (2017-12-07 16:52:46)
> In some cases debugfs or sysfs may return errors that we
> want to check. Return -errno from helper functions to make
> assert
== Series Details ==
Series: drm: rework delayed connector cleanup in connector_iter (rev2)
URL : https://patchwork.freedesktop.org/series/35282/
State : success
== Summary ==
Series 35282v2 drm: rework delayed connector cleanup in connector_iter
https://patchwork.freedesktop.org/api/1.0/serie
As a simple fail-safe against a bad installation, check the tools exist
before testing whether they work.
v2: Check intel_l3_parity as well
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=102935
Signed-off-by: Chris Wilson
Reviewed-by: Petri Latvala
Reviewed-by: Joonas Lahtinen
---
tes
On 13/12/17 08:17, Daniel Vetter wrote:
On Tue, Dec 12, 2017 at 02:33:38PM +, Lionel Landwerlin wrote:
On 12/12/17 11:19, Tvrtko Ursulin wrote:
On 11/12/2017 21:05, Daniel Vetter wrote:
On Mon, Dec 11, 2017 at 02:38:53PM +, Tvrtko Ursulin wrote:
On 11/12/2017 10:50, Joonas Lahtinen wr
On 2017-12-13 16:00:49 [+0200], Joonas Lahtinen wrote:
> On Thu, 2017-11-30 at 16:19 +0100, Sebastian Andrzej Siewior wrote:
> > The code has an ifdef and uses two functions to either init the bare
> > spinlock or init it and set a lock-class. It is possible to do the same
> > thing without an ifde
== Series Details ==
Series: series starting with [1/8] drm/i915/guc: Move shared data allocation
away from submission path
URL : https://patchwork.freedesktop.org/series/35287/
State : success
== Summary ==
Series 35287v1 series starting with [1/8] drm/i915/guc: Move shared data
allocation
On 13/12/17 13:35, Chris Wilson wrote:
Quoting Daniel Vetter (2017-12-13 08:17:17)
On Tue, Dec 12, 2017 at 02:33:38PM +, Lionel Landwerlin wrote:
On 12/12/17 11:19, Tvrtko Ursulin wrote:
On 11/12/2017 21:05, Daniel Vetter wrote:
On Mon, Dec 11, 2017 at 02:38:53PM +, Tvrtko Ursulin wro
On Wed, 13 Dec 2017 13:50:45 +0100, Michał Winiarski
wrote:
We have the selftest that's checking doorbell create/destroy, so there's
no need to check all doorbells delaying the reset every time.
We do want to have that extra sanity check at module load/unload though.
Signed-off-by: Michał Wi
Quoting Michał Winiarski (2017-12-13 12:50:40)
> This gets rid of the following lockdep splat:
>
> ==
> WARNING: possible circular locking dependency detected
> 4.15.0-rc2-CI-Patchwork_7428+ #1 Not tainted
> --
Quoting Michał Winiarski (2017-12-13 12:50:42)
> To make this operation a bit cleaner, we should make sure that the HW
> can catch up by calling the new implementation right away.
> Note that currently we're only touching the vfunc at module load time
> (before GuC is even loaded), so this shouldn'
Quoting Michał Winiarski (2017-12-13 12:50:39)
> We need shared data for actions (e.g. guc suspend/resume), and we're
> using those with GuC submission disabled.
> Let's introduce intel_guc_init and move shared data alloc there.
>
> This fixes GPF during module unload with HuC, but without GuC sub
On Wed, 2017-12-13 at 16:06 +0100, Sebastian Andrzej Siewior wrote:
> On 2017-12-13 16:00:49 [+0200], Joonas Lahtinen wrote:
> > On Thu, 2017-11-30 at 16:19 +0100, Sebastian Andrzej Siewior wrote:
> > > The code has an ifdef and uses two functions to either init the bare
> > > spinlock or init it a
References: https://bugs.freedesktop.org/show_bug.cgi?id=104009
Suggest-Cc: Kirill A. Shutemov
Suggest-Cc: Vlastimil Babka
Suggest-Cc: Jerome Marchand
Suggest-Cc: Andrea Arcangeli
Suggest-Cc: Hugh Dickins
Suggest-Cc: Dave Hansen
Suggest-Cc: Mel Gorman
Suggest-Cc: Rik van Riel
Suggest-Cc: J
== Series Details ==
Series: drm/i915: Unwind i915_gem_init() failure (rev4)
URL : https://patchwork.freedesktop.org/series/35060/
State : success
== Summary ==
Series 35060v4 drm/i915: Unwind i915_gem_init() failure
https://patchwork.freedesktop.org/api/1.0/series/35060/revisions/4/mbox/
Tes
Quoting Chris Wilson (2017-12-13 15:23:31)
> Quoting Michał Winiarski (2017-12-13 12:50:40)
> > This gets rid of the following lockdep splat:
> >
> > ==
> > WARNING: possible circular locking dependency detected
> > 4.15.0-rc2-CI-Patchwork_7428+
On Wed, Dec 13, 2017 at 02:58:16PM +0200, Petri Latvala wrote:
> Signed-off-by: Petri Latvala
> Cc: Arkadiusz Hiler
Reviewed-by: Arkadiusz Hiler
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/i
Generated using make header_install.
Generated from drm-intel-next-queued commit
53ff2641a817099e1c6d1aef409ba004c3a9f1ea
Signed-off-by: Michał Winiarski
---
include/drm/i915_drm.h | 215 ++---
1 file changed, 202 insertions(+), 13 deletions(-)
diff
== Series Details ==
Series: HAX mm: Prevent stalling for lock_page in deferred_split_scan
URL : https://patchwork.freedesktop.org/series/35294/
State : success
== Summary ==
Series 35294v1 HAX mm: Prevent stalling for lock_page in deferred_split_scan
https://patchwork.freedesktop.org/api/1.0/
== Series Details ==
Series: Create a new directory for hardware-targeting tests
URL : https://patchwork.freedesktop.org/series/35288/
State : success
== Summary ==
IGT patchset tested on top of latest successful build
4112f30aedbb252bf8cdd27dbba485c0458faca7 igt/gem_shrink: Exercise allocatio
Hi All,
intel_cherryview_info in drivers/gpu/drm/i915/i915_pci.c
does not have has_fbc set. Is this an oversight / does
the i915 code need work to allow FBC on CHT, or does CHT
actually not have FBC?
Regards,
Hans
___
Intel-gfx mailing list
Intel-gfx@
On Wed, Dec 13, 2017 at 05:45:01PM +0100, Hans de Goede wrote:
> Hi All,
>
> intel_cherryview_info in drivers/gpu/drm/i915/i915_pci.c
> does not have has_fbc set. Is this an oversight / does
> the i915 code need work to allow FBC on CHT, or does CHT
> actually not have FBC?
The code is correct. N
== Series Details ==
Series: tests/kms_frontbuffer_tracking: Correctly handle debugfs errors
URL : https://patchwork.freedesktop.org/series/34555/
State : success
== Summary ==
IGT patchset tested on top of latest successful build
4112f30aedbb252bf8cdd27dbba485c0458faca7 igt/gem_shrink: Exerci
1 - 100 of 155 matches
Mail list logo
