Re: [Intel-gfx] [PATCH 3/8] drm/i915/kbl: KBL also needs to run the SAGV code

Em Qua, 2016-09-14 às 12:59 +0300, Jani Nikula escreveu: > On Tue, 13 Sep 2016, "Zanoni, Paulo R" > wrote: > > > > I got confirmation from the Hardware guys that KBL does need to run > > the > > SAGV code, and it has the same latency as SKL. Also, all SKL > > production

Re: [Intel-gfx] [PATCH 0/9] SKL/KBL watermark fixes, v2

Em Qua, 2016-09-14 às 12:34 +0300, Jani Nikula escreveu: > On Wed, 14 Sep 2016, Paulo Zanoni wrote: > > > > Hi > > > > Here's the series with the reviews implemented. There's a new > > patch, > > based on the additional issue spotted by Lyude. > > There's a bunch of

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: Only expand COND once in wait_for() (rev2)

== Series Details == Series: drm/i915: Only expand COND once in wait_for() (rev2) URL : https://patchwork.freedesktop.org/series/12403/ State : failure == Summary == Series 12403v2 drm/i915: Only expand COND once in wait_for()

[Intel-gfx] [PATCH] drm/i915: Only expand COND once in wait_for()

Commentary from Chris Wilson's original version: > I was looking at some wait_for() timeouts on a slow system, with lots of > debug enabled (KASAN, lockdep, mmio_debug). Thinking that we were > mishandling the timeout, I tried to ensure that we loop at least once > after first testing COND.

Re: [Intel-gfx] [PATCH v4] drm/i915/skl: New ddb allocation algorithm

Hi, There was an issue with transition WM, it was getting enabled & causing fifo underrun. I fixed the condition, After that tested kms_plane & not getting any underrun. Please let me know if you see any other issue. Regards, -Mahesh On Tuesday 13 September 2016 06:10 PM, Maarten Lankhorst

Re: [Intel-gfx] 4.8-rc1: it is now common that machine needs re-run of xrandr after resume

On Wed, 14 Sep 2016, Jani Nikula wrote: > On Wed, 14 Sep 2016, Pavel Machek wrote: >> For the "sometimes need xrandr after resume": I don't think I can >> bisect that. It only happens sometimes :-(. But there's something >> helpful in the logs: > >> [

Re: [Intel-gfx] [PATCH] drm/i915: prefer INTEL_GEN(dev_priv) to INTEL_INFO(dev)->gen

On 14/09/16 13:32, Dave Gordon wrote: On 13/09/16 10:10, Jani Nikula wrote: On Sat, 10 Sep 2016, Dave Gordon wrote: Thanks, the other things I was thinking of fixing in the remaining files were generally things like if (INTEL_INFO(dev)->gen < 5 || IS_G33(dev))

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Unlock PPS registers after GPU reset

== Series Details == Series: drm/i915: Unlock PPS registers after GPU reset URL : https://patchwork.freedesktop.org/series/12446/ State : success == Summary == Series 12446v1 drm/i915: Unlock PPS registers after GPU reset

Re: [Intel-gfx] [PATCH] drm/i915: prefer INTEL_GEN(dev_priv) to INTEL_INFO(dev)->gen

On 13/09/16 10:10, Jani Nikula wrote: On Sat, 10 Sep 2016, Dave Gordon wrote: Thanks, the other things I was thinking of fixing in the remaining files were generally things like if (INTEL_INFO(dev)->gen < 5 || IS_G33(dev)) Is that a real or a made up example?

Re: [Intel-gfx] 4.8-rc1: it is now common that machine needs re-run of xrandr after resume

Am Mittwoch, 14. September 2016, 12:17:53 CEST schrieb Jani Nikula: > On Wed, 14 Sep 2016, Pavel Machek wrote: > > For the "sometimes need xrandr after resume": I don't think I can > > bisect that. It only happens sometimes :-(. But there's something > > helpful in the logs: > > >

Re: [Intel-gfx] [PATCH] drm/i915: Only expand COND once in wait_for()

Em Qua, 2016-09-14 às 10:22 +0100, Chris Wilson escreveu: > On Tue, Sep 13, 2016 at 08:40:19PM +0100, Chris Wilson wrote: > > > > I was looking at some wait_for() timeouts on a slow system, with > > lots of > > debug enabled (KASAN, lockdep, mmio_debug). Thinking that we were > > mishandling the

Re: [Intel-gfx] [PATCH] drm/i915: Queue page flip work with high priority

On ti, 2016-09-13 at 12:12 +0100, Tvrtko Ursulin wrote: > On 13/09/16 11:31, Imre Deak wrote: > > On ti, 2016-09-13 at 11:24 +0100, Tvrtko Ursulin wrote: > > > On 12/09/16 15:09, Imre Deak wrote: > > > > While user space has control over the scheduling priority of > > > > its > > > > page > > > >

[Intel-gfx] [PATCH v4] drm/i915/bxt: Implement Transition WM

From: Mahesh Kumar This patch enables Transition WM for SKL+ platforms. Transition WM are used if IPC is enabled, to decide, number of blocks to be fetched before reducing the priority of display to fetch from memory. Changes since v1: - Don't enable transition WM for

Re: [Intel-gfx] [PATCH i-g-t v2 01/13] lib/sw_sync: Add helper functions for managing synchronization primitives

On Tue, Sep 13, 2016 at 11:40:18AM -0400, Robert Foss wrote: > > > On 2016-09-13 07:03 AM, Chris Wilson wrote: > >Try: > > > >int __sw_sync_fence_create(int fd, int32_t seqno) /* int32_t not unsigned ? > >*/ > >{ > > > > struct sw_sync_create_fence_data data; > > > > memset(, 0,

Re: [Intel-gfx] [PATCH 11/18] drm/i915: Record space required for request emission

On 14/09/2016 07:52, Chris Wilson wrote: In the next patch, we will use deferred request emission. That requires reserving sufficient space in the ringbuffer to emit the request, which first requires us to know how large the request is. Signed-off-by: Chris Wilson

[Intel-gfx] [PATCH v5 03/11] drm/i915: return EACCES for check_cmd() failures

check_cmd() is checking whether a command adheres to certain restrictions that ensure it's safe to execute within a privileged batch buffer. Returning false implies a privilege problem, not that the command is invalid. The distinction makes the difference between allowing the buffer to be

[Intel-gfx] [PATCH v5 06/11] drm/i915: Enable i915 perf stream for Haswell OA unit

Gen graphics hardware can be set up to periodically write snapshots of performance counters into a circular buffer via its Observation Architecture and this patch exposes that capability to userspace via the i915 perf interface. Cc: Chris Wilson Signed-off-by: Robert

[Intel-gfx] [PATCH v5 07/11] drm/i915: advertise available metrics via sysfs

Each metric set is given a sysfs entry like: /sys/class/drm/card0/metrics//id This allows userspace to enumerate the specific sets that are available for the current system. The 'id' file contains an unsigned integer that can be used to open the associated metric set via

[Intel-gfx] [PATCH v5 10/11] drm/i915: Add more Haswell OA metric sets

This adds 'compute', 'compute extended', 'memory reads', 'memory writes' and 'sampler balance' metric sets for Haswell. The code is auto generated from an XML description of metric sets, currently maintained in gputop, ref: https://github.com/rib/gputop > gputop-data/oa-*.xml >

[Intel-gfx] [PATCH v5 09/11] drm/i915: add oa_event_min_timer_exponent sysctl

The minimal sampling period is now configurable via a dev.i915.oa_min_timer_exponent sysctl parameter. Following the precedent set by perf, the default is the minimum that won't (on its own) exceed the default kernel.perf_event_max_sample_rate default of 10 samples/s. Signed-off-by: Robert

[Intel-gfx] [PATCH v5 08/11] drm/i915: Add dev.i915.perf_event_paranoid sysctl option

Consistent with the kernel.perf_event_paranoid sysctl option that can allow non-root users to access system wide cpu metrics, this can optionally allow non-root users to access system wide OA counter metrics from Gen graphics hardware. Signed-off-by: Robert Bragg ---

Re: [Intel-gfx] [PATCH] drm/i915: introduce & use i915_gem_object_{set, clear, is}_dirty()

On 12/09/16 16:48, Tvrtko Ursulin wrote: Hi, On 09/09/16 20:48, Dave Gordon wrote: This just hides the existing obj->dirty flag inside a trivial inline setter, to discourage non-GEM code from looking too closely. The flag is renamed to emphasise that it is private to the GEM memory-

Re: [Intel-gfx] [PATCH i-g-t v2 01/13] lib/sw_sync: Add helper functions for managing synchronization primitives

On 2016-09-14 08:18 AM, Chris Wilson wrote: On Tue, Sep 13, 2016 at 11:40:18AM -0400, Robert Foss wrote: On 2016-09-13 07:03 AM, Chris Wilson wrote: Try: int __sw_sync_fence_create(int fd, int32_t seqno) /* int32_t not unsigned ? */ { struct sw_sync_create_fence_data data;

Re: [Intel-gfx] [PATCH v5 01/11] drm/i915: Add i915 perf infrastructure

On Wed, Sep 14, 2016 at 3:42 PM, Emil Velikov wrote: > Hi Robert, > > I think I've spotted one interesting, yet trivial bit. > > On 14 September 2016 at 15:19, Robert Bragg wrote: > > Adds base i915 perf infrastructure for Gen performance metrics.

Re: [Intel-gfx] [PATCH 1/3] drm/i915: clarify PMINTRMSK/pm_intr_keep usage

On 12/09/2016 21:19, Dave Gordon wrote: No functional changes; just renaming a bit, tweaking a datatype, prettifying layout, and adding comments, in particular in the GuC setup code that touches this data. Signed-off-by: Dave Gordon ---

[Intel-gfx] [PATCH i-g-t v4 04/13] tests/sw_sync: Add subtest test_alloc_fence_invalid_timeline

From: Robert Foss This subtests tests that creating fences on negative timelines fail. Signed-off-by: Robert Foss Reviewed-by: Eric Engestrom --- tests/sw_sync.c | 7 +++ 1 file changed, 7 insertions(+) diff --git

[Intel-gfx] [PATCH i-g-t v4 13/13] tests/sw_sync: Add subtest test_sync_multi_producer_single_consumer

From: Robert Foss This subtest runs a single consumer thread and multiple producer thread that are synchronized using multiple timelines. Signed-off-by: Robert Foss Reviewed-by: Eric Engestrom --- tests/sw_sync.c | 139

Re: [Intel-gfx] [PATCH 3/3] drm/i915/guc: general tidying up (submission)

On 12/09/2016 21:19, Dave Gordon wrote: Renaming to more consistent scheme, and updating comments, mostly about i915_guc_wq_reserve(), aka i915_guc_wq_check_space(). Signed-off-by: Dave Gordon --- drivers/gpu/drm/i915/i915_guc_submission.c | 63

[Intel-gfx] [PATCH v5 05/11] drm/i915: Add 'render basic' Haswell OA unit config

Adds a static OA unit, MUX + B Counter configuration for basic render metrics on Haswell. This is auto generated from an XML description of metric sets, currently maintained in gputop, ref: https://github.com/rib/gputop > gputop-data/oa-*.xml > scripts/i915-perf-kernelgen.py $ make -C

[Intel-gfx] [PATCH v5 11/11] drm/i915: Add a kerneldoc summary for i915_perf.c

In particular this tries to capture for posterity some of the early challenges we had with using the core perf infrastructure in case we ever want to revisit adapting perf for device metrics. Cc: Chris Wilson Signed-off-by: Robert Bragg ---

[Intel-gfx] [PATCH v5 04/11] drm/i915: don't whitelist oacontrol in cmd parser

Being able to program OACONTROL from a non-privileged batch buffer is not sufficient to be able to configure the OA unit. This was originally allowed to help enable Mesa to expose OA counters via the INTEL_performance_query extension, but the current implementation based on programming OACONTROL

[Intel-gfx] [PATCH i-g-t v4 00/13] Implement sw_sync test

From: Robert Foss s series implements the sw_sync test and the lib/sw_sync helper functions for said test. Gustavo Padovans sw_sync series was just de-staged in gregkh-staging/staging-next [1], and this test is targeted at verifying the functionality implemented in

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: introduce & use i915_gem_object_{set, clear, is}_dirty() (rev2)

== Series Details == Series: drm/i915: introduce & use i915_gem_object_{set, clear, is}_dirty() (rev2) URL : https://patchwork.freedesktop.org/series/12262/ State : failure == Summary == Series 12262v2 drm/i915: introduce & use i915_gem_object_{set, clear, is}_dirty()

[Intel-gfx] [PATCH v2 0/5] drm: clean up several wrapper functions

Changes in v2: - Split per-driver - Remove i915_driver_open() - Fix dce_virtual_hw_init() as well Masahiro Yamada (5): drm/amdgpu: squash lines for simple wrapper functions drm/radeon: squash lines for simple wrapper functions drm/bridge: squash lines for simple wrapper functions

[Intel-gfx] [PATCH v2 5/5] drm/i915: use i915_gem_open() directly instead of i915_driver_open()

i915_driver_open() is equivalent to i915_gem_open(). Replace the i915_driver_open with the direct use of i915_gem_open(). Signed-off-by: Masahiro Yamada --- drivers/gpu/drm/i915/i915_drv.c | 13 + 1 file changed, 1 insertion(+), 12 deletions(-) diff

[Intel-gfx] [PATCH i-g-t v4 10/13] tests/sw_sync: Add subtest test_sync_multi_consumer_producer

From: Robert Foss This test verifies that stressing the kernel by creating multiple consumer/producer threads that wait on a single timeline to be incremented by another conumer/producer thread does not fail. And that the order amongst the threads is maintained.

[Intel-gfx] [PATCH i-g-t v4 03/13] tests/sw_sync: Add subtest test_alloc_fence

From: Robert Foss Add subtest alloc_fence that verifies that it's possible to allocate a fence on a timeline. Signed-off-by: Robert Foss Reviewed-by: Eric Engestrom --- tests/sw_sync.c | 16 1 file

[Intel-gfx] [PATCH i-g-t v4 01/13] lib/sw_sync: Add helper functions for managing synchronization primitives

From: Robert Foss Base functions to help testing the Sync File Framework (explicit fencing mechanism ported from Android). These functions allow you to create, use and destroy timelines and fences. Signed-off-by: Robert Foss Signed-off-by:

[Intel-gfx] [PATCH i-g-t v4 06/13] tests/sw_sync: Add subtest test_sync_wait

From: Robert Foss This subtest verifies that waiting on fences works properly. Signed-off-by: Robert Foss Reviewed-by: Eric Engestrom --- tests/sw_sync.c | 38 ++ 1 file changed, 38

[Intel-gfx] [PATCH i-g-t v4 07/13] tests/sw_sync: Add subtest test_sync_merge

From: Robert Foss Add subtest test_sync_merge that tests merging fences and the validity of the resulting merged fence. Signed-off-by: Robert Foss Reviewed-by: Eric Engestrom --- tests/sw_sync.c | 67

[Intel-gfx] [PATCH i-g-t v4 05/13] tests/sw_sync: Add subtest test_alloc_merge_fence

From: Robert Foss This subtest verifies that merging two fences works in the simples possible case. Signed-off-by: Robert Foss Reviewed-by: Eric Engestrom --- tests/sw_sync.c | 23 +++ 1 file

[Intel-gfx] [PATCH i-g-t v4 02/13] tests/sw_sync: Add sw_sync test

From: Robert Foss Add initial tests for sw_sync. Signed-off-by: Robert Foss Signed-off-by: Gustavo Padovan Reviewed-by: Eric Engestrom --- tests/Makefile.sources | 1 + tests/sw_sync.c

[Intel-gfx] [PATCH i-g-t v4 09/13] tests/sw_sync: Add subtest test_sync_multi_consumer

From: Robert Foss This subtest verifies the access ordering of multiple consumer threads. Signed-off-by: Robert Foss Reviewed-by: Eric Engestrom --- tests/sw_sync.c | 103

[Intel-gfx] [PATCH i-g-t v4 11/13] tests/sw_sync: Add subtest test_sync_random_merge

From: Robert Foss This subtest verifies that creating many timelines and merging random fences from each timeline with eachother results in merged fences that are fully functional. Signed-off-by: Robert Foss Reviewed-by: Eric Engestrom

[Intel-gfx] [PATCH i-g-t v4 12/13] tests/sw_sync: Add subtest test_sync_multi_timeline_wait

From: Robert Foss This subtest verifies that waiting, timing out on a wait and that counting fences in various states works. Signed-off-by: Robert Foss Reviewed-by: Eric Engestrom --- tests/sw_sync.c | 66

[Intel-gfx] [PATCH i-g-t v4 08/13] tests/sw_sync: Add subtest test_sync_merge_same

From: Robert Foss This subtest verifies merging a fence with itself does not fail. Signed-off-by: Robert Foss Reviewed-by: Eric Engestrom --- tests/sw_sync.c | 37 - 1 file changed,

Re: [Intel-gfx] [PATCH 2/3] drm/i915/guc: general tidying up (loader)

On 12/09/2016 21:19, Dave Gordon wrote: Renaming to more consistent scheme, delete unused definitions Signed-off-by: Dave Gordon --- drivers/gpu/drm/i915/i915_guc_reg.h | 3 --- drivers/gpu/drm/i915/intel_guc_loader.c | 27 --- 2

Re: [Intel-gfx] [PATCH v5 01/11] drm/i915: Add i915 perf infrastructure

Hi Robert, I think I've spotted one interesting, yet trivial bit. On 14 September 2016 at 15:19, Robert Bragg wrote: > Adds base i915 perf infrastructure for Gen performance metrics. > > This adds a DRM_IOCTL_I915_PERF_OPEN ioctl that takes an array of uint64 > properties

[Intel-gfx] [PATCH v3] drm/i915: introduce & use i915_gem_object_{set, clear, is}_dirty()

This just hides the existing obj->dirty flag inside a trivial inline setter, to discourage non-GEM code from looking too closely. The flag is renamed to emphasise that it is private to the GEM memory- management code and ensure that no legacy code continues to use it directly. v2: Use Chris

[Intel-gfx] ✗ Fi.CI.BAT: failure for Enable i915 perf stream for Haswell OA unit (rev3)

== Series Details == Series: Enable i915 perf stream for Haswell OA unit (rev3) URL : https://patchwork.freedesktop.org/series/11295/ State : failure == Summary == Series 11295v3 Enable i915 perf stream for Haswell OA unit

Re: [Intel-gfx] [PATCH 08/18] drm/i915: Combine seqno + tracking into a global timeline struct

On ke, 2016-09-14 at 07:52 +0100, Chris Wilson wrote: >  i915_next_seqno_get(void *data, u64 *val) >  { >   struct drm_i915_private *dev_priv = data; > - int ret; > - > - ret = mutex_lock_interruptible(_priv->drm.struct_mutex); > - if (ret) > - return ret; > - > -

[Intel-gfx] [PATCH v5 00/11] Enable i915 perf stream for Haswell OA unit

This just rebases my i915 perf series on a recent drm-intel-nightly. Considering now that this series has been reviewed a number of times by Chris, and I think I've responded to his feedback: I wonder if this series is ready to be added to drm-intel-nightly soon? I think most of the effort for

[Intel-gfx] [PATCH v5 01/11] drm/i915: Add i915 perf infrastructure

Adds base i915 perf infrastructure for Gen performance metrics. This adds a DRM_IOCTL_I915_PERF_OPEN ioctl that takes an array of uint64 properties to configure a stream of metrics and returns a new fd usable with standard VFS system calls including read() to read typed and sized records; ioctl()

[Intel-gfx] [PATCH v5 02/11] drm/i915: rename OACONTROL GEN7_OACONTROL

OACONTROL changes quite a bit for gen8, with some bits split out into a per-context OACTXCONTROL register. Rename now before adding more gen7 OA registers Signed-off-by: Robert Bragg --- drivers/gpu/drm/i915/i915_cmd_parser.c | 4 ++-- drivers/gpu/drm/i915/i915_reg.h

[Intel-gfx] [PATCH] drm/i915: Add i915 perf infrastructure

Adds base i915 perf infrastructure for Gen performance metrics. This adds a DRM_IOCTL_I915_PERF_OPEN ioctl that takes an array of uint64 properties to configure a stream of metrics and returns a new fd usable with standard VFS system calls including read() to read typed and sized records; ioctl()

[Intel-gfx] ✗ Fi.CI.BAT: failure for Enable i915 perf stream for Haswell OA unit (rev4)

== Series Details == Series: Enable i915 perf stream for Haswell OA unit (rev4) URL : https://patchwork.freedesktop.org/series/11295/ State : failure == Summary == Series 11295v4 Enable i915 perf stream for Haswell OA unit

Re: [Intel-gfx] [PATCH 3/3] drm/i915/guc: general tidying up (submission)

On 14/09/16 16:22, Tvrtko Ursulin wrote: On 12/09/2016 21:19, Dave Gordon wrote: Renaming to more consistent scheme, and updating comments, mostly about i915_guc_wq_reserve(), aka i915_guc_wq_check_space(). Signed-off-by: Dave Gordon ---

[Intel-gfx] [PATCH v2] drm/i915: Queue page flip work via a low latency, unbound workqueue

While user space has control over the scheduling priority of its page flipping thread, the corresponding work the driver schedules for MMIO flips always runs from the generic system workqueue which has some scheduling overhead due it being CPU bound. This would hinder an application that wants

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: Queue page flip work with high priority (rev2)

== Series Details == Series: drm/i915: Queue page flip work with high priority (rev2) URL : https://patchwork.freedesktop.org/series/12336/ State : failure == Summary == Series 12336v2 drm/i915: Queue page flip work with high priority

Re: [Intel-gfx] [PATCH 11/18] drm/i915: Record space required for request emission

On Wed, Sep 14, 2016 at 02:30:20PM +0100, Tvrtko Ursulin wrote: > > On 14/09/2016 07:52, Chris Wilson wrote: > >In the next patch, we will use deferred request emission. That requires > >reserving sufficient space in the ringbuffer to emit the request, which > >first requires us to know how large

Re: [Intel-gfx] [PATCH 05/18] drm/i915: Move GEM activity tracking into a common struct reservation_object

On Wed, Sep 14, 2016 at 12:44:04PM +0300, Joonas Lahtinen wrote: > On ke, 2016-09-14 at 07:52 +0100, Chris Wilson wrote: > > -static inline bool > > -i915_gem_object_has_active_engine(const struct drm_i915_gem_object *obj, > > -   int engine) > > -{ > > - return

Re: [Intel-gfx] [PATCH] drm/i915: Only expand COND once in wait_for()

Em Qua, 2016-09-14 às 13:10 +0100, Dave Gordon escreveu: > Commentary from Chris Wilson's original version: > > > > > I was looking at some wait_for() timeouts on a slow system, with > > lots of > > debug enabled (KASAN, lockdep, mmio_debug). Thinking that we were > > mishandling the timeout, I

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: Standardize port type for DVO encoders (rev2)

== Series Details == Series: drm/i915: Standardize port type for DVO encoders (rev2) URL : https://patchwork.freedesktop.org/series/12418/ State : failure == Summary == Series 12418v2 drm/i915: Standardize port type for DVO encoders

[Intel-gfx] [PATCH v2] drm/i915: Standardize port type for DVO encoders

Changing the return type from 'char' to 'enum port' in intel_dvo_port_name() makes it easier to later move the port information to intel_encoder. In addition, the port type conforms to what we have elsewhere. Removing the last conditional that handles invalid port because dvo_reg is intialized to

Re: [Intel-gfx] 4.8-rc1: it is now common that machine needs re-run of xrandr after resume

On Tue, Sep 13, 2016 at 11:04:37PM +0200, Pavel Machek wrote: > Hi! > > > I have > > > > 00:02.0 VGA compatible controller: Intel Corporation 4 Series Chipset > > Integrated Graphics Controller (rev 03) > > > > In previous kernels, resume worked ok. With 4.8-rc1, I quite often (1 > > in 10

Re: [Intel-gfx] [PATCH v2] drm/i915: Standardize port type for DVO encoders

This version of the patch has been included in the series "Prep. for DP audio MST support" since the helper is used by the patch that stores port in struct intel_encoder. On Wed, 2016-09-14 at 14:03 -0700, Dhinakaran Pandiyan wrote: > Changing the return type from 'char' to 'enum port' in >

[Intel-gfx] ✗ Fi.CI.BAT: failure for Prep. for DP audio MST support (rev10)

== Series Details == Series: Prep. for DP audio MST support (rev10) URL : https://patchwork.freedesktop.org/series/11129/ State : failure == Summary == Series 11129v10 Prep. for DP audio MST support https://patchwork.freedesktop.org/api/1.0/series/11129/revisions/10/mbox/ Test

[Intel-gfx] [PATCH v6 2/5] drm/i915: Store port enum in intel_encoder

Storing the port enum in intel_encoder makes it convenient to know the port attached to an encoder. Moving the port information up from intel_digital_port to intel_encoder avoids unecessary intel_digital_port access and handles MST encoders cleanly without requiring conditional checks for them

[Intel-gfx] [PATCH v6 0/5] Prep. for DP audio MST support

This series lays the groundwork for more DP MST audio work that will follow. v2: Different solution replacing the enc_to_dig_port() fix (Ville, Lyude). No changes to MST audio enabling and move audio_connector patches. Reordered the patches (Lyude) v3: Different solution to get port from encoder

[Intel-gfx] [PATCH v6 3/5] drm/i915: Switch to using port stored in intel_encoder

Now that we have the port enum stored in intel_encoder, use that instead of dereferencing intel_dig_port. Saves us a few locals. struct intel_encoder variables have been renamed to be consistent and convey type information. v2: Fix incorrect 'enum port' member names - s/attached_port/port

[Intel-gfx] [PATCH v6 1/5] drm/i915: Standardize port type for DVO encoders

Changing the return type from 'char' to 'enum port' in intel_dvo_port_name() makes it easier to later move the port information to intel_encoder. In addition, the port type conforms to what we have elsewhere. Removing the last conditional that handles invalid port because dvo_reg is intialized to

[Intel-gfx] [PATCH v6 5/5] drm/i915: start adding dp mst audio

From: Libin Yang (This patch is developed by Dave Airlie originally) This patch adds support for DP MST audio in i915. Enable audio codec when DP MST is enabled if has_audio flag is set. Disable audio codec when DP MST is disabled if has_audio

[Intel-gfx] [PATCH v6 4/5] drm/i915: Move audio_connector to intel_encoder

With DP MST, a digital_port can carry more than one audio stream. Hence, more than one audio_connector needs to be attached to intel_digital_port in such cases. However, each stream is associated with an unique encoder. So, instead of creating an array of audio_connectors per port, move

[Intel-gfx] [PATCH 17/18] drm/i915: Enable userspace to opt-out of implicit fencing

Userspace is faced with a dilemma. The kernel requires implicit fencing to manage resource usage (we always must wait for the GPU to finish before releasing its PTE) and for third parties. However, userspace may wish to avoid this serialisation if it is either using explicit fencing between

[Intel-gfx] [PATCH 03/18] drm/i915: Rearrange i915_wait_request() accounting with callers

Our low-level wait routine has evolved from our generic wait interface that handled unlocked, RPS boosting, waits with time tracking. If we push our GEM fence tracking to use reservation_objects (required for handling multiple timelines), we lose the ability to pass the required information down

[Intel-gfx] [PATCH 14/18] drm/i915: Create a unique name for the context

This will be used for communicating issues with this context to userspace, so we want to identify the parent process and the individual context. Note that the name isn't quite unique, it makes the presumption of there only being a single device fd per process. Signed-off-by: Chris Wilson

[Intel-gfx] [PATCH 08/18] drm/i915: Combine seqno + tracking into a global timeline struct

Our timelines are more than just a seqno. They also provide an ordered list of requests to be executed. Due to the restriction of handling individual address spaces, we are limited to a timeline per address space but we use a fence context per engine within. Our first step to introducing

[Intel-gfx] [PATCH 07/18] drm/i915: Restore nonblocking awaits for modesetting

After combining the dma-buf reservation object and the GEM reservation object, we lost the ability to do a nonblocking wait on the i915 request (as we blocked upon the reservation object during prepare_fb). We can instead convert the reservation object into a fence upon which we can asynchronously

[Intel-gfx] [PATCH 09/18] drm/i915: Wait first for submission, before waiting for request completion

In future patches, we will no longer be able to wait on a static global seqno and instead have to break our wait up into phases. First we wait for the global seqno assignment (upon submission to hardware), and once submitted we wait for the hardware to complete. Signed-off-by: Chris Wilson

[Intel-gfx] [PATCH 16/18] drm/i915: Enable multiple timelines

With the infrastructure converted over to tracking multiple timelines in the GEM API whilst preserving the efficiency of using a single execution timeline internally, we can now assign a separate timeline to every context with full-ppgtt. Signed-off-by: Chris Wilson ---

[Intel-gfx] [PATCH 05/18] drm/i915: Move GEM activity tracking into a common struct reservation_object

In preparation to support many distinct timelines, we need to expand the activity tracking on the GEM object to handle more than just a request per engine. We already use the struct reservation_object on the dma-buf to handle many fence contexts, so integrating that into the GEM object itself is

[Intel-gfx] [PATCH 12/18] drm/i915: Defer request emission

Move the actual emission of the request (the closing breadcrumb) from i915_add_request() to the submit callback. (It can be moved later when required.) This allows us to defer the allocation of the global_seqno from request construction to actual submission, allowing us to emit the requests out of

[Intel-gfx] [PATCH 02/18] drm/i915: Allow i915_sw_fence_await_sw_fence() to allocate

In forthcoming patches, we want to be able to dynamically allocate the wait_queue_t used whilst awaiting. This is more convenient if we extend the i915_sw_fence_await_sw_fence() to perform the allocation for us if we pass in a gfp mask rather than a preallocate struct. Signed-off-by: Chris Wilson

[Intel-gfx] [PATCH 11/18] drm/i915: Record space required for request emission

In the next patch, we will use deferred request emission. That requires reserving sufficient space in the ringbuffer to emit the request, which first requires us to know how large the request is. Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/i915_gem_request.c |

[Intel-gfx] [PATCH 15/18] drm/i915: Reserve space in the global seqno during request allocation

A restriction on our global seqno is that they cannot wrap, and that we cannot use the value 0. This allows us to detect when a request has not yet been submitted, its global seqno is still 0, and ensures that hardware semaphores are monotonic as required by older hardware. To meet these

[Intel-gfx] [PATCH 01/18] drm/i915: Support asynchronous waits on struct fence from i915_gem_request

We will need to wait on DMA completion (as signaled via struct fence) before executing our i915_gem_request. Therefore we want to expose a method for adding the await on the fence itself to the request. Signed-off-by: Chris Wilson ---

[Intel-gfx] [PATCH 18/18] drm/i915: Support explicit fencing for execbuf

Now that the user can opt-out of implicit fencing, we need to give them back control over the fencing. We employ sync_file to wrap our drm_i915_gem_request and provide an fd that userspace can merge with other sync_file fds and pass back to the kernel to wait upon before future execution.

[Intel-gfx] [PATCH 06/18] drm: Add reference counting to drm_atomic_state

drm_atomic_state has a complicated single owner model that tracks the single reference from allocation through to destruction on another thread - or perhaps on a local error path. We can simplify this tracking by using reference counting (at a cost of a few more atomics). This is even more

[Intel-gfx] [PATCH 04/18] drm/i915: Remove unused i915_gem_active_wait() in favour of _unlocked()

Since we only use the more generic unlocked variant, just rename it as the normal i915_gem_active_wait(). The temporary cost is that we need to always acquire the reference in a RCU safe manner, but the benefit is that we will combine the common paths. Signed-off-by: Chris Wilson

[Intel-gfx] [PATCH 10/18] drm/i915: Introduce a global_seqno for each request

Though we will have multiple timelines, we still have a single timeline of execution. This we can use to provide an execution and retirement order of requests. This keeps tracking execution of requests simple, and vital for preserving a single waiter (i.e. so that we can order the waiters so that

[Intel-gfx] [PATCH 13/18] drm/i915: Move the global sync optimisation to the timeline

Currently we try to reduce the number of synchronisations (now the number of requests we need to wait upon) by noting that if we have earlier waited upon a request, all subsequent requests in the timeline will be after the wait. This only applies to requests in this timeline, as other timelines

[Intel-gfx] Tracking multiple timelines (full-ppgtt)

Here's how I think we can handle multiple timelines whilst preserving the efficiency of retirement ordering of requests and the single waiter property. -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org

Re: [Intel-gfx] [PATCH 0/9] SKL/KBL watermark fixes, v2

On Wed, 14 Sep 2016, Paulo Zanoni wrote: > Hi > > Here's the series with the reviews implemented. There's a new patch, > based on the additional issue spotted by Lyude. There's a bunch of cc: stable patches mixed with non cc: stable patches in the series. Do the cc:

Re: [Intel-gfx] intel_opregion_get_panel_type potential bug fix

On Mon, 29 Aug 2016, Sean Greenslade wrote: > In investigating the issue myself, I discovered that the root of the > problem seemed to be that the new code for getting the panel type from > the opregion seems to believe it is getting good data, but it is not. > The

Re: [Intel-gfx] Bad flicker on skylake HQD due to code in the 4.7 merge window

On Mon, 20 Jun 2016, James Bottomley wrote: > On Fri, 2016-06-17 at 16:06 -0700, James Bottomley wrote: >> On Fri, 2016-06-17 at 16:34 +0300, Jani Nikula wrote: >> > On Fri, 17 Jun 2016, Daniel Vetter wrote: >> > > On Thu, Jun 16, 2016 at

Re: [Intel-gfx] [PATCH 05/18] drm/i915: Move GEM activity tracking into a common struct reservation_object

On ke, 2016-09-14 at 07:52 +0100, Chris Wilson wrote: > In preparation to support many distinct timelines, we need to expand the > activity tracking on the GEM object to handle more than just a request > per engine. We already use the struct reservation_object on the dma-buf > to handle many fence

Re: [Intel-gfx] [PATCH 3/8] drm/i915/kbl: KBL also needs to run the SAGV code

On Tue, 13 Sep 2016, "Zanoni, Paulo R" wrote: > I got confirmation from the Hardware guys that KBL does need to run the > SAGV code, and it has the same latency as SKL. Also, all SKL production > steppings need to run the SAGV code. Can you get confirmation what's the

Re: [Intel-gfx] 4.8-rc1: it is now common that machine needs re-run of xrandr after resume

On Wed, 14 Sep 2016, Pavel Machek wrote: > Intel folks, any ideas? Can you reproduce it? It's possible (but not confirmed yet) we've seen this in our CI, but has slipped through because it's sporadic. BR, Jani. -- Jani Nikula, Intel Open Source Technology Center

[Intel-gfx] [PATCH] drm/i915: Unlock PPS registers after GPU reset

Reapply the PPS register unlock workaround after GPU reset on platforms where the reset clobbers the display HW state. This at least gets rid of the related WARN during LVDS encoder enabling on PNV. Fixes: ed6143b8f75 ("drm/i915/lvds: Restore initial HW state during encoder enabling")

Re: [Intel-gfx] [PATCH 02/18] drm/i915: Allow i915_sw_fence_await_sw_fence() to allocate

On ke, 2016-09-14 at 07:52 +0100, Chris Wilson wrote: > @@ -678,7 +678,7 @@ void __i915_add_request(struct drm_i915_gem_request > *request, bool flush_caches) >      >i915->drm.struct_mutex); >   if (prev) >   i915_sw_fence_await_sw_fence(>submit,

  1   2   >