Re: [Intel-gfx] [PATCH 0/2] drm: link status property and DP link training failure handling

On Fri, 2016-12-16 at 16:47 +0200, Jani Nikula wrote: > On Fri, 16 Dec 2016, Daniel Vetter wrote: > > On Fri, Dec 16, 2016 at 12:29:05PM +0200, Jani Nikula wrote: > >> The two remaining patches from [1], rebased. > >> > >> BR, > >> Jani. > >> > >> > >> [1] > >>

Re: [Intel-gfx] [PATCH v2 i-g-t] tools: Add intel_dp_compliance for DisplayPort 1.2 compliance automation

On Wed, Dec 07, 2016 at 02:04:52PM -0800, Manasi Navare wrote: > This is the userspace component of the Displayport Compliance > testing software required for compliance testing of the I915 > Display Port driver. This must be running in order to successfully > complete Display Port compliance

Re: [Intel-gfx] [PATCH 1/9] drm/i915: Keep i915_handle_error kerneldoc parameters together

On Fri, Dec 16, 2016 at 12:20:02PM -0800, Michel Thierry wrote: > And before the function description. > Tidy up from commit 14bb2c11796d70b ("drm/i915: Fix a buch of kerneldoc > warnings"), all others kerneldoc blocks look ok. > > Cc: Tvrtko Ursulin > Signed-off-by:

Re: [Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/4] drm/i915: introduce GEM_WARN_ON

On Tue, Dec 13, 2016 at 09:15:35PM -, Patchwork wrote: > == Series Details == > > Series: series starting with [1/4] drm/i915: introduce GEM_WARN_ON > URL : https://patchwork.freedesktop.org/series/16758/ > State : success > > == Summary == > > Series 16758v1 Series without cover letter >

Re: [Intel-gfx] [PATCH 6/9] drm/i915/tdr: Add engine reset count to error state

On 16/12/16 12:37, Chris Wilson wrote: On Fri, Dec 16, 2016 at 12:20:07PM -0800, Michel Thierry wrote: From: Arun Siluvery Driver maintains count of how many times a given engine is reset, useful to capture this in error state also. It gives an idea of how

[Intel-gfx] ✗ Fi.CI.BAT: warning for Execlist based engine-reset

== Series Details == Series: Execlist based engine-reset URL : https://patchwork.freedesktop.org/series/16936/ State : warning == Summary == Series 16936v1 Execlist based engine-reset https://patchwork.freedesktop.org/api/1.0/series/16936/revisions/1/mbox/ Test kms_pipe_crc_basic:

Re: [Intel-gfx] [PATCH 4/9] drm/i915/tdr: Add support for per engine reset recovery

On Fri, Dec 16, 2016 at 12:20:05PM -0800, Michel Thierry wrote: > From: Arun Siluvery > > This change implements support for per-engine reset as an initial, less > intrusive hang recovery option to be attempted before falling back to the > legacy full GPU reset

Re: [Intel-gfx] [PATCH 6/9] drm/i915/tdr: Add engine reset count to error state

On Fri, Dec 16, 2016 at 12:20:07PM -0800, Michel Thierry wrote: > From: Arun Siluvery > > Driver maintains count of how many times a given engine is reset, useful to > capture this in error state also. It gives an idea of how engine is coping > up with the

[Intel-gfx] [PATCH i-g-t] igt_kms: Use const parameters for igt_assert_crc_equal

Since we're not modifying these anywhere, let's make them const so as to not break code doing comparisons against compile-time CRCs. Signed-off-by: Lyude --- lib/igt_debugfs.c | 2 +- lib/igt_debugfs.h | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git

[Intel-gfx] [PATCH 3/9] drm/i915/tdr: Modify error handler for per engine hang recovery

From: Arun Siluvery This is a preparatory patch which modifies error handler to do per engine hang recovery. The actual patch which implements this sequence follows later in the series. The aim is to prepare existing recovery function to adapt to this new function

[Intel-gfx] [RFC 9/9] drm/i915: Add engine reset count in get-reset-stats ioctl

Users/tests relying on the total reset count will start seeing a smaller number since most of the hangs can be handled by engine reset. Note that if reset engine x, context a running on engine y will be unaware and unaffected. To start the discussion, include just a total engine reset count. If

[Intel-gfx] ✗ Fi.CI.BAT: warning for series starting with [v3,01/38] drm/i915: Use the MRU stack search after evicting

== Series Details == Series: series starting with [v3,01/38] drm/i915: Use the MRU stack search after evicting URL : https://patchwork.freedesktop.org/series/16934/ State : warning == Summary == Series 16934v1 Series without cover letter

[Intel-gfx] [PATCH 5/9] drm/i915: Skip reset request if there is one already

From: Mika Kuoppala To perform engine reset we first disable engine to capture its state. This is done by issuing a reset request. Because we are reusing existing infrastructure, again when we actually reset an engine, reset function checks engine mask and issues

[Intel-gfx] [PATCH 7/9] drm/i915/tdr: Export per-engine reset count info to debugfs

From: Arun Siluvery A new variable is added to export the reset counts to debugfs, this includes full gpu reset and engine reset count. This is useful for tests where they are expected to trigger reset; these counts are checked before and after the test to ensure

[Intel-gfx] [PATCH 6/9] drm/i915/tdr: Add engine reset count to error state

From: Arun Siluvery Driver maintains count of how many times a given engine is reset, useful to capture this in error state also. It gives an idea of how engine is coping up with the workloads it is executing before this error state. Cc: Chris Wilson

[Intel-gfx] [PATCH 0/9] Execlist based engine-reset

These patches are to add engine reset feature from Gen8. This is also referred to as Timeout detection and recovery (TDR). This complements to the full gpu reset feature available in i915 but it only allows to reset a particular engine instead of all engines thus providing a light weight engine

[Intel-gfx] [PATCH 1/9] drm/i915: Keep i915_handle_error kerneldoc parameters together

And before the function description. Tidy up from commit 14bb2c11796d70b ("drm/i915: Fix a buch of kerneldoc warnings"), all others kerneldoc blocks look ok. Cc: Tvrtko Ursulin Signed-off-by: Michel Thierry --- drivers/gpu/drm/i915/i915_irq.c

[Intel-gfx] [PATCH 8/9] drm/i915/tdr: Enable Engine reset and recovery support

From: Arun Siluvery This feature is made available only from Gen8, for previous gen devices driver uses legacy full gpu reset. Cc: Chris Wilson Cc: Mika Kuoppala Signed-off-by: Tomas Elf

[Intel-gfx] [PATCH 2/9] drm/i915: Update i915.reset to handle engine resets

From: Arun Siluvery In preparation for engine reset work update this parameter to handle more than one type of reset. Default at the moment is still full gpu reset. Cc: Chris Wilson Cc: Mika Kuoppala

Re: [Intel-gfx] [PATCH v3 04/38] lib: Add a simple prime number generator

On Fri, Dec 16, 2016 at 07:25:16PM +, Chris Wilson wrote: > +static void __exit primes_exit(void) > +{ > + const struct primes *p; > + > + mutex_lock(); > + p = rcu_dereference_protected(primes, lockdep_is_held()); > + if (p != _primes) { > + kfree_rcu((struct

[Intel-gfx] [PATCH v3 09/38] drm: kselftest for drm_mm_reserve_node()

Exercise drm_mm_reserve_node(), check that we can't reserve an already occupied range and that the lists are correct after reserving/removing. v2: Check for invalid node reservation. Signed-off-by: Chris Wilson Reviewed-by: Joonas Lahtinen

[Intel-gfx] [PATCH v3 37/38] drm: Improve drm_mm search (and fix topdown allocation) with rbtrees

The drm_mm range manager claimed to support top-down insertion, but it was neither searching for the top-most hole that could fit the allocation request nor fitting the request to the hole correctly. In order to search the range efficiently, we create a secondary index for the holes using either

[Intel-gfx] [PATCH v3 23/38] drm: Detect overflow in drm_mm_reserve_node()

Protect ourselves from a caller passing in node.start + node.size that will overflow and trick us into reserving that node. Signed-off-by: Chris Wilson Reviewed-by: Joonas Lahtinen --- drivers/gpu/drm/drm_mm.c | 5 ++--- 1 file

[Intel-gfx] [PATCH v3 17/38] drm: kselftest for drm_mm and color adjustment

Check that after applying the driver's color adjustment, fitting of the node and its alignment are still correct. v2: s/no_color_touching/separate_adjacent_colors/ Signed-off-by: Chris Wilson Reviewed-by: Joonas Lahtinen ---

[Intel-gfx] [PATCH v3 24/38] drm: Simplify drm_mm_clean()

Since commit ea7b1dd44867 ("drm: mm: track free areas implicitly"), to test whether there are any nodes allocated within the range manager, we merely have to ask whether the node_list is empty. Signed-off-by: Chris Wilson Reviewed-by: Joonas Lahtinen

[Intel-gfx] [PATCH v3 25/38] drm: Add asserts to catch overflow in drm_mm_init() and drm_mm_init_scan()

A simple assert to ensure that we don't overflow start + size when initialising the drm_mm, or its scanner. In future, we may want to switch to tracking the value of ranges (rather than size) so that we can cover the full u64, for example like resource tracking. Signed-off-by: Chris Wilson

[Intel-gfx] [PATCH v3 28/38] drm: Unconditionally do the range check in drm_mm_scan_add_block()

Doing the check is trivial (low cost in comparison to overall eviction) and helps simplify the code. Signed-off-by: Chris Wilson Reviewed-by: Joonas Lahtinen --- drivers/gpu/drm/drm_mm.c | 53

[Intel-gfx] [PATCH v3 30/38] drm: Compute tight evictions for drm_mm_scan

Compute the minimal required hole during scan and only evict those nodes that overlap. This enables us to reduce the number of nodes we need to evict to the bare minimum. Signed-off-by: Chris Wilson Reviewed-by: Joonas Lahtinen ---

[Intel-gfx] [PATCH v3 26/38] drm: Extract struct drm_mm_scan from struct drm_mm

The scan state occupies a large proportion of the struct drm_mm and is rarely used and only contains temporary state. That makes it suitable to moving to its struct and onto the stack of the callers. Signed-off-by: Chris Wilson Reviewed-by: Joonas Lahtinen

[Intel-gfx] [PATCH v3 32/38] drm: Simplify drm_mm scan-list manipulation

Since we mandate a strict reverse-order of drm_mm_scan_remove_block() after drm_mm_scan_add_block() we can further simplify the list manipulations when generating the temporary scan-hole. v2: Highlight the games being played with the lists to track the scan holes without allocation.

[Intel-gfx] [PATCH v3 35/38] drm: Apply range restriction after color adjustment when allocation

mm->color_adjust() compares the hole with its neighbouring nodes. They only abutt before we restrict the hole, so we have to apply color_adjust before we apply the range restriction. Signed-off-by: Chris Wilson Reviewed-by: Joonas Lahtinen

[Intel-gfx] [PATCH v3 12/38] drm: kselftest for drm_mm_insert_node_in_range()

Exercise drm_mm_insert_node_in_range(), check that we only allocate from the specified range. v2: Use all allocation flags Signed-off-by: Chris Wilson Reviewed-by: Joonas Lahtinen --- drivers/gpu/drm/selftests/drm_mm_selftests.h | 1

[Intel-gfx] [PATCH v3 16/38] drm: kselftest for drm_mm and top-down allocation

Check that if we request top-down allocation from drm_mm_insert_node() we receive the next available hole from the top. Signed-off-by: Chris Wilson Reviewed-by: Joonas Lahtinen --- drivers/gpu/drm/selftests/drm_mm_selftests.h | 1 +

[Intel-gfx] [PATCH v3 07/38] drm: kselftest for drm_mm_init()

Simple first test to just exercise initialisation of struct drm_mm. Signed-off-by: Chris Wilson Reviewed-by: Joonas Lahtinen --- drivers/gpu/drm/selftests/drm_mm_selftests.h | 1 + drivers/gpu/drm/selftests/test-drm_mm.c | 114

[Intel-gfx] [PATCH v3 21/38] drm: Promote drm_mm alignment to u64

In places (e.g. i915.ko), the alignment is exported to userspace as u64 and there now exists hardware for which we can indeed utilize a u64 alignment. As such, we need to keep 64bit integers throughout when handling alignment. Testcase: igt/drm_mm/align64 Testcase: igt/gem_exec_alignment

[Intel-gfx] [PATCH v3 33/38] drm: Apply tight eviction scanning to color_adjust

Using mm->color_adjust makes the eviction scanner much tricker since we don't know the actual neighbours of the target hole until after it is created (after scanning is complete). To work out whether we need to evict the neighbours because they impact upon the hole, we have to then check the hole

[Intel-gfx] [PATCH v3 29/38] drm: Fix application of color vs range restriction when scanning drm_mm

The range restriction should be applied after the color adjustment, or else we may inadvertently apply the color adjustment to the restricted hole (and not against its neighbours). Signed-off-by: Chris Wilson Reviewed-by: Joonas Lahtinen

[Intel-gfx] [PATCH v3 13/38] drm: kselftest for drm_mm and alignment

Check that we can request alignment to any power-of-two or prime using a plain drm_mm_node_insert(), and also handle a reasonable selection of primes. v2: Exercise all allocation flags Signed-off-by: Chris Wilson Reviewed-by: Joonas Lahtinen

[Intel-gfx] [PATCH v3 19/38] drm: kselftest for drm_mm and restricted color eviction

Check that after applying the driver's color adjustment, restricted eviction scanning find a suitable hole. Signed-off-by: Chris Wilson Reviewed-by: Joonas Lahtinen --- drivers/gpu/drm/selftests/drm_mm_selftests.h | 1 +

[Intel-gfx] [PATCH v3 31/38] drm: Optimise power-of-two alignments in drm_mm_scan_add_block()

For power-of-two alignments, we can avoid the 64bit divide and do a simple bitwise add instead. v2: s/alignment_mask/remainder_mask/ Signed-off-by: Chris Wilson Reviewed-by: Joonas Lahtinen --- drivers/gpu/drm/drm_mm.c | 9 -

[Intel-gfx] [PATCH v3 14/38] drm: kselftest for drm_mm and eviction

Check that we add arbitrary blocks to the eviction scanner in order to find the first minimal hole that matches our request. v2: Refactor out some common eviction code for later Signed-off-by: Chris Wilson Reviewed-by: Joonas Lahtinen

[Intel-gfx] [PATCH v3 15/38] drm: kselftest for drm_mm and range restricted eviction

Check that we add arbitrary blocks to a restrited eviction scanner in order to find the first minimal hole that matches our request. Signed-off-by: Chris Wilson Reviewed-by: Joonas Lahtinen ---

[Intel-gfx] [PATCH v3 18/38] drm: kselftest for drm_mm and color eviction

Check that after applying the driver's color adjustment, eviction scanning find a suitable hole. Signed-off-by: Chris Wilson Reviewed-by: Joonas Lahtinen --- drivers/gpu/drm/selftests/drm_mm_selftests.h | 1 +

[Intel-gfx] [PATCH v3 34/38] drm: Wrap drm_mm_node.hole_follows

Insulate users from changed to the internal hole tracking within struct drm_mm_node by using an accessor for hole_follows. Signed-off-by: Chris Wilson Reviewed-by: Joonas Lahtinen --- drivers/gpu/drm/drm_mm.c| 12

[Intel-gfx] [PATCH v3 36/38] drm: Use drm_mm_insert_node_in_range_generic() for everyone

Remove a superfluous helper as drm_mm_insert_node is equivalent to insert_node_in_range with a range of (0, U64_MAX). Signed-off-by: Chris Wilson Reviewed-by: Joonas Lahtinen --- drivers/gpu/drm/drm_mm.c | 166

[Intel-gfx] [PATCH v3 04/38] lib: Add a simple prime number generator

Prime numbers are interesting for testing components that use multiplies and divides, such as testing DRM's struct drm_mm alignment computations. v2: Move to lib/, add selftest v3: Fix initial constants (exclude 0/1 from being primes) v4: More RCU markup to keep 0day/sparse happy Signed-off-by:

[Intel-gfx] [PATCH v3 22/38] drm: Fix kerneldoc for drm_mm_scan_remove_block()

The nodes must be removed in the *reverse* order. This is correct in the overview, but backwards in the function description. Whilst here add Intel's copyright statement and tweak some formatting. Signed-off-by: Chris Wilson Reviewed-by: Joonas Lahtinen

[Intel-gfx] [PATCH v3 02/38] drm: Use drm_mm_nodes() as shorthand for the list of nodes under struct drm_mm

Fairly commonly we want to inspect the node list on the struct drm_mm, which is buried within an embedded node. Bring it to the surface with a bit of syntatic sugar. Note this was intended to be split from commit ad579002c8ec ("drm: Add drm_mm_for_each_node_safe()") before being applied, but my

[Intel-gfx] [PATCH v3 11/38] drm: kselftest for drm_mm_replace_node()

Reuse drm_mm_insert_node() with a temporary node to exercise drm_mm_replace_node(). We use the previous test in order to exercise the various lists following replacement. v2: Check that we copy across the important (user) details of the node. The internal details (such as lists and hole tracking)

[Intel-gfx] [PATCH v3 20/38] drm/i915: Build DRM range manager selftests for CI

Build the struct drm_mm selftests so that we can trivially run them within our CI. "Enable debug, become developer." - Joonas Lahtinen Signed-off-by: Chris Wilson Reviewed-by: Joonas Lahtinen --- drivers/gpu/drm/i915/Kconfig.debug | 1

[Intel-gfx] [PATCH v3 10/38] drm: kselftest for drm_mm_insert_node()

Exercise drm_mm_insert_node(), check that we can't overfill a range and that the lists are correct after reserving/removing. v2: Extract helpers for the repeated tests v3: Iterate over all allocation flags Signed-off-by: Chris Wilson Reviewed-by: Joonas Lahtinen

[Intel-gfx] [PATCH v3 06/38] drm: Add some kselftests for the DRM range manager (struct drm_mm)

First we introduce a smattering of infrastructure for writing selftests. The idea is that we have a test module that exercises a particular portion of the exported API, and that module provides a set of tests that can either be run as an ensemble via kselftest or individually via an igt harness

[Intel-gfx] [PATCH v3 05/38] drm: Add a simple generator of random permutations

When testing, we want a random but yet reproducible order in which to process elements. Here we create an array which is a random (using the Tausworthe PRNG) permutation of the order in which to execute. Note these are simple helpers intended to be merged upstream in lib/ v2: Tidier code by

[Intel-gfx] [PATCH v3 38/38] drm: kselftest for drm_mm and bottom-up allocation

Check that if we request bottom-up allocation from drm_mm_insert_node() we receive the next available hole from the bottom. Signed-off-by: Chris Wilson Reviewed-by: Joonas Lahtinen --- drivers/gpu/drm/selftests/drm_mm_selftests.h | 1

[Intel-gfx] [PATCH v3 01/38] drm/i915: Use the MRU stack search after evicting

When we evict from the GTT to make room for an object, the hole we create is put onto the MRU stack inside the drm_mm range manager. On the next search pass, we can speed up a PIN_HIGH allocation by referencing that stack for the new hole. v2: Pull together the 3 identical implements (ahem, a

[Intel-gfx] [PATCH v3 08/38] drm: kselftest for drm_mm_debug()

Simple test to just exercise calling the debug dumper on the drm_mm. Signed-off-by: Chris Wilson Reviewed-by: Joonas Lahtinen --- drivers/gpu/drm/selftests/drm_mm_selftests.h | 1 + drivers/gpu/drm/selftests/test-drm_mm.c | 35

[Intel-gfx] [PATCH v3 03/38] drm: Compile time enabling for asserts in drm_mm

Use CONFIG_DRM_DEBUG_MM to conditionally enable the internal and validation checking using BUG_ON. Ideally these paths should all be exercised by CI selftests (with the asserts enabled). Signed-off-by: Chris Wilson Reviewed-by: Joonas Lahtinen

[Intel-gfx] [PATCH v3 27/38] drm: Rename prev_node to hole in drm_mm_scan_add_block()

Acknowledging that we were building up the hole was more useful to me when reading the code, than knowing the relationship between this node and the previous node. Signed-off-by: Chris Wilson Reviewed-by: Joonas Lahtinen ---

[Intel-gfx] drm_mm fixes, take 3, final?

With a lot of polish applied, Joonas has reviewed the series - all but for [04/38] "lib: Add a simple prime number generator" [lib/prime_numbers.c]. Anyone feel like poking around at a bit of number theory? Other than it would appear to be ready for Daniel to sort out the merge between

Re: [Intel-gfx] [PATCH i-g-t v2 10/12] tests/kms_atomic_transition: add out_fences tests

On Fri, Dec 16, 2016 at 03:59:00AM -0500, Robert Foss wrote: On 2016-12-14 11:57 AM, Brian Starkey wrote: On Wed, Dec 14, 2016 at 04:05:07AM -0500, Robert Foss wrote: From: Gustavo Padovan Signed-off-by: Gustavo Padovan

Re: [Intel-gfx] [PATCH i-g-t v2 08/12] tests/kms_atomic: stress possible fence settings

On Fri, Dec 16, 2016 at 03:35:36AM -0500, Robert Foss wrote: On 2016-12-14 11:39 AM, Brian Starkey wrote: Hi, On Wed, Dec 14, 2016 at 04:05:05AM -0500, Robert Foss wrote: From: Gustavo Padovan Signed-off-by: Gustavo Padovan

Re: [Intel-gfx] [PATCH i-g-t v2 07/12] lib/igt_kms: Add support for the OUT_FENCE_PTR property

On Fri, Dec 16, 2016 at 03:21:45AM -0500, Robert Foss wrote: On 2016-12-14 11:13 AM, Brian Starkey wrote: Hi, On Wed, Dec 14, 2016 at 04:05:04AM -0500, Robert Foss wrote: From: Gustavo Padovan Add support for the OUT_FENCE_PTR property to enable setting

Re: [Intel-gfx] [PATCH 8/8] drm/i915/get_params: Add HuC status to getparams

>-Original Message- >From: Chris Wilson [mailto:ch...@chris-wilson.co.uk] >Sent: Friday, December 16, 2016 10:47 AM >To: Srivatsa, Anusha >Cc: Hiler, Arkadiusz ; >intel-gfx@lists.freedesktop.org >Subject: Re: [Intel-gfx] [PATCH 8/8]

Re: [Intel-gfx] [PATCH v3] lib: Add a simple prime number generator

Hi Chris, [auto build test WARNING on linus/master] [also build test WARNING on v4.9 next-20161216] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/Chris-Wilson/lib-Add-a-simple-prime-number

Re: [Intel-gfx] [PATCH 8/8] drm/i915/get_params: Add HuC status to getparams

On Fri, Dec 16, 2016 at 06:31:46PM +, Srivatsa, Anusha wrote: > > > >-Original Message- > >From: Chris Wilson [mailto:ch...@chris-wilson.co.uk] > >Sent: Friday, December 16, 2016 8:31 AM > >To: Hiler, Arkadiusz > >Cc: Srivatsa, Anusha

Re: [Intel-gfx] [PATCH 4/8] drm/i915/huc: Add BXT HuC Loading Support

>-Original Message- >From: Tvrtko Ursulin [mailto:tvrtko.ursu...@linux.intel.com] >Sent: Friday, December 16, 2016 8:16 AM >To: Srivatsa, Anusha ; intel- >g...@lists.freedesktop.org >Subject: Re: [Intel-gfx] [PATCH 4/8] drm/i915/huc: Add BXT HuC Loading Support

Re: [Intel-gfx] [PATCH 8/8] drm/i915/get_params: Add HuC status to getparams

>-Original Message- >From: Chris Wilson [mailto:ch...@chris-wilson.co.uk] >Sent: Friday, December 16, 2016 8:31 AM >To: Hiler, Arkadiusz >Cc: Srivatsa, Anusha ; intel- >g...@lists.freedesktop.org >Subject: Re: [Intel-gfx] [PATCH 8/8]

Re: [Intel-gfx] [PATCH 3/5] drm/i915/guc: Simplify intel_guc_load()

+ +fail: + /* +* We've failed to load the firmware :( +* +* Decide whether to disable GuC submission and fall back to +* execlist mode, and whether to hide the error by returning +* zero or to return -EIO, which the caller will treat as a +

[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [1/3] drm/i915/DMC/GLK: Load DMC on GLK

== Series Details == Series: series starting with [1/3] drm/i915/DMC/GLK: Load DMC on GLK URL : https://patchwork.freedesktop.org/series/16926/ State : failure == Summary == Series 16926v1 Series without cover letter https://patchwork.freedesktop.org/api/1.0/series/16926/revisions/1/mbox/

Re: [Intel-gfx] [PATCH 2/2] drm/i915: Dump more configuration information for DSI

On Wed, Dec 14, 2016 at 07:14:05PM +0200, ville.syrj...@linux.intel.com wrote: > From: Ville Syrjälä > > Dump out more of the DSI configuration details during init. > This includes pclk, burst_mode_ratio, lane_count, pixel_overlap, > video_mode_format and

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm: Use drm_mm_nodes() as shorthand for the list of nodes under struct drm_mm

== Series Details == Series: drm: Use drm_mm_nodes() as shorthand for the list of nodes under struct drm_mm URL : https://patchwork.freedesktop.org/series/16920/ State : failure == Summary == Series 16920v1 drm: Use drm_mm_nodes() as shorthand for the list of nodes under struct drm_mm

Re: [Intel-gfx] [PATCH 3/8] drm/i915/huc: Add HuC fw loading support

On 16/12/2016 16:29, Arkadiusz Hiler wrote: On Fri, Dec 16, 2016 at 04:13:14PM +, Tvrtko Ursulin wrote: On 15/12/2016 22:29, anushasr wrote: From: Anusha Srivatsa The HuC loading process is similar to GuC. The intel_uc_fw_fetch() is used for both cases. HuC

[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [v2,01/40] drm/i915: Use the MRU stack search after evicting (rev3)

== Series Details == Series: series starting with [v2,01/40] drm/i915: Use the MRU stack search after evicting (rev3) URL : https://patchwork.freedesktop.org/series/16906/ State : failure == Summary == CC net/ipv4/tcp_cubic.o CC net/ipv4/xfrm4_policy.o LD

Re: [Intel-gfx] [PATCH 8/8] drm/i915/get_params: Add HuC status to getparams

On Fri, Dec 16, 2016 at 05:21:38PM +0100, Arkadiusz Hiler wrote: > On Fri, Dec 16, 2016 at 04:12:36PM +, Chris Wilson wrote: > > On Fri, Dec 16, 2016 at 03:43:46PM +0100, Arkadiusz Hiler wrote: > > > On Thu, Dec 15, 2016 at 10:42:53PM +, Chris Wilson wrote: > > > > On Thu, Dec 15, 2016 at

Re: [Intel-gfx] [PATCH 3/8] drm/i915/huc: Add HuC fw loading support

On Fri, Dec 16, 2016 at 04:13:14PM +, Tvrtko Ursulin wrote: > > On 15/12/2016 22:29, anushasr wrote: > > From: Anusha Srivatsa > > > > The HuC loading process is similar to GuC. The intel_uc_fw_fetch() > > is used for both cases. > > > > HuC loading needs to be

Re: [Intel-gfx] [PATCH 8/8] drm/i915/get_params: Add HuC status to getparams

On Fri, Dec 16, 2016 at 04:12:36PM +, Chris Wilson wrote: > On Fri, Dec 16, 2016 at 03:43:46PM +0100, Arkadiusz Hiler wrote: > > On Thu, Dec 15, 2016 at 10:42:53PM +, Chris Wilson wrote: > > > On Thu, Dec 15, 2016 at 02:29:50PM -0800, anushasr wrote: > > > > From: Peter Antoine

Re: [Intel-gfx] [PATCH 5/8] drm/i915/HuC: Add KBL huC loading Support

On 15/12/2016 22:29, anushasr wrote: From: Anusha Srivatsa This patch adds the support to load HuC on KBL Version 2.0 v2: rebased. v3: rebased on top of drm-tip v4: rebased. v5: rebased. Rename KBL_FW_ to KBL_HUC_FW_ Cc: Jeff Mcgee

Re: [Intel-gfx] [PATCH 7/8] drm/i915/huc: Support HuC authentication

On Thu, Dec 15, 2016 at 02:29:49PM -0800, anushasr wrote: > From: Peter Antoine > > The HuC authentication is done by host2guc call. The HuC RSA keys > are sent to GuC for authentication. > > v2: rebased on top of drm-intel-nightly. > changed name format and upped

Re: [Intel-gfx] [PATCH 4/8] drm/i915/huc: Add BXT HuC Loading Support

On 15/12/2016 22:29, anushasr wrote: From: Anusha Srivatsa This patch adds the HuC Loading for the BXT by using the updated file construction. Version 1.7 of the HuC firmware. v2: rebased. v3: rebased on top of drm-tip v4: rebased. v5: rebased. Rename BXT_FW_MAJOR

Re: [Intel-gfx] [PATCH 3/8] drm/i915/huc: Add HuC fw loading support

On 15/12/2016 22:29, anushasr wrote: From: Anusha Srivatsa The HuC loading process is similar to GuC. The intel_uc_fw_fetch() is used for both cases. HuC loading needs to be before GuC loading. The WOPCM setting must be done early before loading any of them. v2:

Re: [Intel-gfx] [PATCH 8/8] drm/i915/get_params: Add HuC status to getparams

On Fri, Dec 16, 2016 at 03:43:46PM +0100, Arkadiusz Hiler wrote: > On Thu, Dec 15, 2016 at 10:42:53PM +, Chris Wilson wrote: > > On Thu, Dec 15, 2016 at 02:29:50PM -0800, anushasr wrote: > > > From: Peter Antoine > > > > > > This patch will allow for getparams to

Re: [Intel-gfx] Guc parameter Handling

On Thu, Dec 15, 2016 at 10:36:40PM +, Srivatsa, Anusha wrote: > Hi All, > > I was wondering if we intend to keep -1 and 2 for the > enable_guc_submission parameter. Since now we are gating guc loads if > either guc_submission or enable_huc parameter is set, why have a > -1(platform default)

Re: [Intel-gfx] [PATCH 1/8] drm/i915/guc: Make the GuC fw loading helper functions general

On 15/12/2016 22:29, anushasr wrote: From: Peter Antoine Rename some of the GuC fw loading code to make them more general. We will utilise them for HuC loading as well. s/intel_guc_fw/intel_uc_fw/g s/GUC_FIRMWARE/UC_FIRMWARE/g Struct intel_guc_fw is renamed

Re: [Intel-gfx] [PATCH 5/5] drm/i915/guc: Simplify guc_fw_path

On 15/12/2016 15:47, Arkadiusz Hiler wrote: Currently guc_fw_path values can represent one of three possible states: 1) NULL - device without GuC 2) '\0' - device with GuC but no known firmware 3) else - device with GuC and known firmware Second case is used only to WARN at the later

Re: [Intel-gfx] [PATCH 8/8] drm/i915/get_params: Add HuC status to getparams

On Thu, Dec 15, 2016 at 02:29:50PM -0800, anushasr wrote: > From: Peter Antoine > > This patch will allow for getparams to return the status of the HuC. > As the HuC has to be validated by the GuC this patch uses the validated > status to show when the HuC is loaded and

Re: [Intel-gfx] [PATCH 3/5] drm/i915/guc: Simplify intel_guc_load()

On 15/12/2016 15:47, Arkadiusz Hiler wrote: Current version of intel_guc_load() does a lot: - cares about submission - loads huc Not yet, no? So instead you could say that you are preparing the groundworks to make adding in the HuC fit better. - implement WA This change offloads some

[Intel-gfx] [drm-intel:drm-intel-nightly 922/930] include/linux/list.h:385:29: error: initialization discards 'const' qualifier from pointer target type

tree: git://anongit.freedesktop.org/drm-intel drm-intel-nightly head: ca1c03136b168816ac65c5945776908e464fca6b commit: 45b186f111f1623b257d183920cd4aab16a1acd5 [922/930] drm: Constify the drm_mm API config: x86_64-randconfig-x008-201650 (attached as .config) compiler: gcc-6 (Debian 6.2.0-3)

[Intel-gfx] [PATCH 2/3] drm/i915/glk: Add missing bits to allow runtime pm suspend on GLK.

From: Rodrigo Vivi Besides having the DMC firmware in place and loaded let's handle runtime suspend and dc9 as we do for Broxton. Cc: Ander Conselvan de Oliveira Signed-off-by: Rodrigo Vivi Reviewed-by:

[Intel-gfx] [PATCH 1/3] drm/i915/DMC/GLK: Load DMC on GLK

From: Anusha Srivatsa This patch loads the DMC on GLK. There is a single firmware image for all steppings on a GLK. Cc: Rodrigo Vivi Signed-off-by: Anusha Srivatsa Reviewed-by: Rodrigo Vivi

[Intel-gfx] [PATCH 3/3] drm/i915/glk: Convert a few more IS_BROXTON() to IS_GEN9_LP()

From: Michel Thierry Commit 89b3c3c7ee9d ("drm/i915/glk: Reuse broxton's cdclk code for GLK") missed a few of occurences of IS_BROXTON() that should have been coverted to IS_GEN9_LP(). Fixes: 89b3c3c7ee9d ("drm/i915/glk: Reuse broxton's cdclk code for GLK") Cc: Ander

[Intel-gfx] [drm-intel:drm-intel-nightly 922/930] drivers/gpu/drm/i915/i915_gem_gtt.c:2732:9: note: in expansion of macro 'list_first_entry_or_null'

tree: git://anongit.freedesktop.org/drm-intel drm-intel-nightly head: ca1c03136b168816ac65c5945776908e464fca6b commit: 45b186f111f1623b257d183920cd4aab16a1acd5 [922/930] drm: Constify the drm_mm API config: i386-randconfig-x005-201650 (attached as .config) compiler: gcc-6 (Debian 6.2.0-3)

Re: [Intel-gfx] [PATCH 09/13] drm: Tighten locking in drm_mode_getconnector

On Tue, Dec 13, 2016 at 6:08 PM, Daniel Vetter wrote: > - Modeset state needs mode_config->connection mutex, that covers > figuring out the encoder, and reading properties (since in the > atomic case those need to look at connector->state). > > - Don't hold any locks

Re: [Intel-gfx] [PATCH 07/13] drm: Clean up connectors by unreferencing them

On Tue, Dec 13, 2016 at 6:08 PM, Daniel Vetter wrote: > Only static connectors should be left at this point, and we should be > able to clean them out by simply dropping that last reference still > around from drm_connector_init. > > If that leaves anything behind then we

Re: [Intel-gfx] [PATCH 08/13] drm: prevent double-(un)registration for connectors

On Tue, Dec 13, 2016 at 6:08 PM, Daniel Vetter wrote: > If we're unlucky then the registration from a hotplugged connector > might race with the final registration step on driver load. And since > MST topology discover is asynchronous that's even somewhat likely. > > v2:

Re: [Intel-gfx] [PATCH] drm: Convert all helpers to drm_connector_list_iter

On Thu, Dec 15, 2016 at 10:58 AM, Daniel Vetter wrote: > Mostly nothing special (except making sure that really all error paths > and friends call iter_put). > > v2: Don't forget the raw connector_list walking in > drm_helper_move_panel_connectors_to_head. That one

Re: [Intel-gfx] [PATCH 04/13] drm: Drop locking cargo-cult from drm_mode_config_init

On Tue, Dec 13, 2016 at 6:08 PM, Daniel Vetter wrote: > This is single-threaded setup code, no need for locks. And anyway, > all properties need to be set up before the driver is registered > anyway, they can't be hot-added. > Reviewed-by: Sean Paul

Re: [Intel-gfx] [PATCH 05/13] drm: locking iterators for connector_list

On Tue, Dec 13, 2016 at 6:08 PM, Daniel Vetter wrote: > The requirements for connector_list locking are a bit tricky: > - We need to be able to jump over zombie conectors (i.e. with refcount > == 0, but not yet removed from the list). If instead we require that >

Re: [Intel-gfx] [PATCH 02/13] drm: Move atomic debugfs functions into drm_crtc_internal.h

On Tue, Dec 13, 2016 at 6:08 PM, Daniel Vetter wrote: > This is not driver interface stuff. > Reviewed-by: Sean Paul > Fixes: 6559c901cb48 ("drm/atomic: add debugfs file to dump out atomic state") > Cc: Rob Clark > Cc: Sean

Re: [Intel-gfx] [PATCH 01/13] drm/irq: drm_legacy_ prefix for legacy ioctls

On Tue, Dec 13, 2016 at 6:08 PM, Daniel Vetter wrote: > Spotted while auditing our ioctl table. Also nuke the > not-really-kerneldoc comments, we don't document internals and > definitely don't want to mislead people with the old dragons. > > I think with this all the

Re: [Intel-gfx] [PATCH v2 12/40] drm: kselftest for drm_mm_insert_node()

On Fri, Dec 16, 2016 at 04:02:12PM +0200, Joonas Lahtinen wrote: > On pe, 2016-12-16 at 07:46 +, Chris Wilson wrote: > > Exercise drm_mm_insert_node(), check that we can't overfill a range and > > that the lists are correct after reserving/removing. > > > > v2: Extract helpers for the

  1   2   >