Hi,
Please pull more gvt-next updates for 4.16. Mostly on code and
regression fixes for last two gvt-next pulls and more refinement.
Details below.
thanks
--
The following changes since commit 1603660b3342269c95fcafee1945790342a8c28e:
drm/i915/gvt: set max priority for gvt context (2017-12-04
== Series Details ==
Series: tests/gem_reset_stats: Fix retrieval of hangcheck stats expectation
(rev2)
URL : https://patchwork.freedesktop.org/series/35101/
State : warning
== Summary ==
Test kms_draw_crc:
Subgroup draw-method-rgb565-mmap-wc-untiled:
skip -> PAS
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 drm-tip already?
As long as you have this change in your tree, it shoul
On Tue, Dec 12, 2017 at 9:32 PM, Imre Deak wrote:
> On Fri, Dec 08, 2017 at 10:31:30AM +, Daniel Drake wrote:
>> Hi,
>>
>> Adding intel-gfx list in case i915 developers can help. Updated summary
>> below.
>>
>> On Thu, Dec 7, 2017 at 2:14 AM, Chris Chiu wrote:
>> > On Wed, Dec 6, 2017 at 9:3
== Series Details ==
Series: tests/gem_reset_stats: Fix retrieval of hangcheck stats expectation
(rev2)
URL : https://patchwork.freedesktop.org/series/35101/
State : success
== Summary ==
IGT patchset tested on top of latest successful build
ea7015f1fabbdfdd52a145162c658d2e90161ec5 lib/core:
The test expected IOCTL 'I915_GET_RESET_STATS' would return an error
when not root. That is no longer true in the driver since commit
4c9c0d09741d ("drm/i915: Fix retrieval of hangcheck stats") and therefore
the test was incorrectly failing.
v2:
- Add the commit that changed the behaviour
== Series Details ==
Series: series starting with [CI,1/7] drm/i915/guc: Move shared data allocation
away from submission path
URL : https://patchwork.freedesktop.org/series/35321/
State : warning
== Summary ==
Warning: bzip Patchwork_7492/shard-snb5/results20.json.bz2 wasn't in correct
JSON
Hi all,
Today's linux-next merge of the drm tree got a conflict in:
drivers/gpu/drm/drm_edid.c
between commit:
4b4df570b41d ("drm: Update edid-derived drm_display_info fields at edid
property set [v2]")
from the drm-misc-fixes tree and commit:
c945b8c14bb7 ("drm/edid: build ELD in drm_
On 12/13/2017 01:34 PM, Michal Wajdeczko wrote:
On Wed, 13 Dec 2017 19:19:06 +0100, Yaodong Li
wrote:
On 12/13/2017 01:11 AM, Joonas Lahtinen wrote:
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 si
== Series Details ==
Series: x86/gpu: add CFL to early quirks (rev2)
URL : https://patchwork.freedesktop.org/series/35109/
State : warning
== Summary ==
Test gem_softpin:
Subgroup noreloc-s4:
fail -> SKIP (shard-snb) fdo#103375 +2
Test pm_rc6_residency:
== Series Details ==
Series: series starting with [CI,1/7] drm/i915/guc: Move shared data allocation
away from submission path
URL : https://patchwork.freedesktop.org/series/35321/
State : success
== Summary ==
Series 35321v1 series starting with [CI,1/7] drm/i915/guc: Move shared data
alloc
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
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
Reviewed-by: Michel Thierry
---
drivers/gpu/drm/i915/int
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
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
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
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
On 2017-12-13 12:23 PM, Maarten Lankhorst wrote:
Op 13-12-17 om 17:19 schreef Leo Li:
Hi Daniel, Maarten,
Just digging an old thread out of the grave:
https://lists.freedesktop.org/archives/dri-devel/2017-August/150495.html
It's suppose to fix a memory leak on the drm_commit object during
no
On Wed, Dec 13, 2017 at 02:35:16PM +0100, Daniel Vetter wrote:
> On Wed, Dec 13, 2017 at 01:05:49PM +, Chris Wilson wrote:
> > Quoting Daniel Vetter (2017-12-13 12:49:36)
> > > diff --git a/drivers/gpu/drm/drm_mode_config.c
> > > b/drivers/gpu/drm/drm_mode_config.c
> > > index 6ffe952142e6..76
On Wed, 13 Dec 2017 19:19:06 +0100, Yaodong Li
wrote:
On 12/13/2017 01:11 AM, Joonas Lahtinen wrote:
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 w
== Series Details ==
Series: drm/i915: Disable the fake-irq when disabled by the user/debugfs
URL : https://patchwork.freedesktop.org/series/35319/
State : warning
== Summary ==
Series 35319v1 drm/i915: Disable the fake-irq when disabled by the user/debugfs
https://patchwork.freedesktop.org/ap
== Series Details ==
Series: x86/gpu: add CFL to early quirks (rev2)
URL : https://patchwork.freedesktop.org/series/35109/
State : success
== Summary ==
Series 35109v2 x86/gpu: add CFL to early quirks
https://patchwork.freedesktop.org/api/1.0/series/35109/revisions/2/mbox/
Test debugfs_test:
Through debugfs, we expose methods for igt to check and control use of
the fake-irq (for missed breadcrumb detection). Currently, we don't
disable the fake-irq immediately after noticing the bit being cleared,
presuming that we will idle soon enough. However, we can check within
the fake-irq worker
== Series Details ==
Series: drm/i915/lpe: Remove double-encapsulation of info string
URL : https://patchwork.freedesktop.org/series/35303/
State : success
== Summary ==
Test gem_eio:
Subgroup in-flight:
pass -> DMESG-WARN (shard-snb) fdo#104058
Test kms_setmode:
CFL was missing from intel_early_ids[]. The PCI ID needs to be there to
allow the memory region to be stolen, otherwise we could have RAM being
arbitrarily overwritten if for example we keep using the UEFI framebuffer,
depending on how BIOS has set up the e820 map.
Fixes: b056f8f3d6b9 ("drm/i915/c
== Series Details ==
Series: tests/psr: Test vblank continuity with PSR enabled
URL : https://patchwork.freedesktop.org/series/35306/
State : failure
== Summary ==
IGT patchset tested on top of latest successful build
ea7015f1fabbdfdd52a145162c658d2e90161ec5 lib/core: Don't leak dummyloads
be
== Series Details ==
Series: Non-blocking commits on -ERESTARTSYS
URL : https://patchwork.freedesktop.org/series/35299/
State : failure
== Summary ==
Test kms_frontbuffer_tracking:
Subgroup fbc-1p-offscren-pri-indfb-draw-mmap-gtt:
pass -> SKIP (shard-hsw) fd
== Series Details ==
Series: drm/i915: make CS frequency read support missing more obvious
URL : https://patchwork.freedesktop.org/series/35298/
State : success
== Summary ==
Test kms_cursor_crc:
Subgroup cursor-256x256-suspend:
skip -> PASS (shard-snb) fdo#
PSR allows DMC to put the system to low power states when active, but
this can reset the frame counter on some platforms. The frame counter reset
leads to a negative diff applied to vblank count. This subtest checks
for that.
v2: Some optimizations and data type changes.
Cc: Rodrigo Vivi
Cc: Dani
On 13/12/17 07:23, Michal Wajdeczko wrote:
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 loa
On 13/12/17 04:50, Michał Winiarski wrote:
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
---
Reviewe
On 13/12/17 04:50, Winiarski, Michal wrote:
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 w
Quoting Lionel Landwerlin (2017-12-13 17:11:54)
> As suggested by Chris, we should make this more obvious for people
> working with newer generations.
>
> Suggested-by: Chris Wilson
> Signed-off-by: Lionel Landwerlin
> ---
> drivers/gpu/drm/i915/intel_device_info.c | 2 +-
> 1 file changed, 1 i
== Series Details ==
Series: igt/tools_test: Check the tools exist before executing (rev2)
URL : https://patchwork.freedesktop.org/series/35237/
State : warning
== Summary ==
Test kms_flip:
Subgroup plain-flip-fb-recreate-interruptible:
pass -> FAIL (shard-h
Quoting Patchwork (2017-12-13 18:26:21)
> == Series Details ==
>
> Series: drm/i915: Unwind i915_gem_init() failure (rev4)
> URL : https://patchwork.freedesktop.org/series/35060/
> State : warning
>
> == Summary ==
>
> Test gem_tiled_swapping:
> Subgroup non-threaded:
>
== Series Details ==
Series: drm/i915/lpe: Remove double-encapsulation of info string
URL : https://patchwork.freedesktop.org/series/35303/
State : success
== Summary ==
Series 35303v1 drm/i915/lpe: Remove double-encapsulation of info string
https://patchwork.freedesktop.org/api/1.0/series/353
On Wed, Dec 13, 2017 at 06:36:33PM +0100, Sebastian Andrzej Siewior wrote:
> +peterz
> context: http://www.spinics.net/lists/intel-gfx/msg149011.html
>
> On 2017-12-13 17:37:21 [+0200], Joonas Lahtinen wrote:
> > On Wed, 2017-12-13 at 16:06 +0100, Sebastian Andrzej Siewior wrote:
> > > On 2017-12-
== Series Details ==
Series: HAX mm: Prevent stalling for lock_page in deferred_split_scan
URL : https://patchwork.freedesktop.org/series/35294/
State : success
== Summary ==
Test kms_frontbuffer_tracking:
Subgroup fbc-1p-primscrn-pri-shrfb-draw-render:
pass -> FA
== Series Details ==
Series: drm/i915: Unwind i915_gem_init() failure (rev4)
URL : https://patchwork.freedesktop.org/series/35060/
State : warning
== Summary ==
Test gem_tiled_swapping:
Subgroup non-threaded:
pass -> INCOMPLETE (shard-snb) fdo#104009
== Series Details ==
Series: tests/kms_frontbuffer_tracking: Correctly handle debugfs errors
URL : https://patchwork.freedesktop.org/series/34555/
State : warning
== Summary ==
Test kms_frontbuffer_tracking:
Subgroup fbc-1p-offscren-pri-shrfb-draw-blt:
fail -> PAS
== Series Details ==
Series: Create a new directory for hardware-targeting tests
URL : https://patchwork.freedesktop.org/series/35288/
State : success
== Summary ==
Test kms_cursor_crc:
Subgroup cursor-256x256-suspend:
skip -> PASS (shard-snb) fdo#103375
Tes
On 12/13/2017 12:19 AM, Joonas Lahtinen wrote:
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 struc
Just printk the string, or at least do not double up on the newlines!
Fixes: eef57324d926 ("drm/i915: setup bridge for HDMI LPE audio driver")
Signed-off-by: Chris Wilson
Cc: Pierre-Louis Bossart
Cc: Jerome Anand
Cc: Jani Nikula
Cc: Takashi Iwai
---
drivers/gpu/drm/i915/intel_lpe_audio.c | 2
On 12/13/2017 01:11 AM, Joonas Lahtinen wrote:
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 actu
On Wed, Dec 13, 2017 at 2:11 AM, Jani Nikula
wrote:
> 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
Quoting Michał Winiarski (2017-12-13 12:50:46)
> 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 no
== Series Details ==
Series: Non-blocking commits on -ERESTARTSYS
URL : https://patchwork.freedesktop.org/series/35299/
State : success
== Summary ==
Series 35299v1 Non-blocking commits on -ERESTARTSYS
https://patchwork.freedesktop.org/api/1.0/series/35299/revisions/1/mbox/
Test kms_pipe_crc_
+peterz
context: http://www.spinics.net/lists/intel-gfx/msg149011.html
On 2017-12-13 17:37:21 [+0200], Joonas Lahtinen wrote:
> 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, Se
== Series Details ==
Series: drm/i915: make CS frequency read support missing more obvious
URL : https://patchwork.freedesktop.org/series/35298/
State : success
== Summary ==
Series 35298v1 drm/i915: make CS frequency read support missing more obvious
https://patchwork.freedesktop.org/api/1.0/
== 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 ==
Warning: bzip CI_DRM_3507/shard-glkb6/results33.json.bz2 wasn't in correct JSON
form
== Series Details ==
Series: drm: rework delayed connector cleanup in connector_iter (rev2)
URL : https://patchwork.freedesktop.org/series/35282/
State : warning
== Summary ==
Warning: bzip CI_DRM_3507/shard-glkb6/results33.json.bz2 wasn't in correct JSON
format
Test kms_setmode:
Subg
Op 13-12-17 om 17:19 schreef Leo Li:
> Hi Daniel, Maarten,
>
> Just digging an old thread out of the grave:
> https://lists.freedesktop.org/archives/dri-devel/2017-August/150495.html
>
> It's suppose to fix a memory leak on the drm_commit object during
> non-blocking commits. Within drm_atomic_help
== Series Details ==
Series: igt/tools_test: Check the tools exist before executing (rev2)
URL : https://patchwork.freedesktop.org/series/35237/
State : success
== Summary ==
IGT patchset tested on top of latest successful build
4112f30aedbb252bf8cdd27dbba485c0458faca7 igt/gem_shrink: Exercise
As suggested by Chris, we should make this more obvious for people
working with newer generations.
Suggested-by: Chris Wilson
Signed-off-by: Lionel Landwerlin
---
drivers/gpu/drm/i915/intel_device_info.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/in
== 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
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
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@
== 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
== 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/
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
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
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+
== 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
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
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
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
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'
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
> --
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
== 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 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
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
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
== 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
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
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, 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, 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.
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
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
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 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
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 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
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
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
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
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
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
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
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
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
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
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
1 - 100 of 155 matches
Mail list logo
