[Intel-gfx] ✓ Fi.CI.IGT: success for Fix PSR-vblank-DMC interaction

== Series Details == Series: Fix PSR-vblank-DMC interaction URL : https://patchwork.freedesktop.org/series/35553/ State : success == Summary == Test kms_frontbuffer_tracking: Subgroup fbc-1p-offscren-pri-shrfb-draw-render: fail -> PASS (shard-snb)

[Intel-gfx] ✓ Fi.CI.BAT: success for Fix PSR-vblank-DMC interaction

== Series Details == Series: Fix PSR-vblank-DMC interaction URL : https://patchwork.freedesktop.org/series/35553/ State : success == Summary == Series 35553v1 Fix PSR-vblank-DMC interaction https://patchwork.freedesktop.org/api/1.0/series/35553/revisions/1/mbox/ Test kms_pipe_crc_basic:

[Intel-gfx] [PATCH v2 4/8] drm/vblank: Do not update vblank counts if vblanks are already disabled.

Updating the vblank counts requires register reads and these reads may not return meaningful values after the vblank interrupts are disabled as the device may go to low power state. An additional change would be to allow the driver to save the vblank counts before entering a low power state, but

[Intel-gfx] [PATCH v2 2/8] drm/i915/psr: CAN_PSR() macro to check for PSR source and sink support.

The global variable dev_priv->psr.sink_support is set if an eDP sink supports PSR. Use this instead of redoing the check with is_edp_psr(). Combine source and sink support checks into a macro that can be used to return early from psr_{invalidate, single_frame_update, flush}. Cc: Rodrigo Vivi

[Intel-gfx] [PATCH v2 1/8] drm/i915/psr: Kill psr.source_ok flag.

This flag has become redundant since commit 4d90f2d507ab ("drm/i915: Start tracking PSR state in crtc state") It is set at the same place as psr.enabled, which is also exposed via debugfs. Cc: Rodrigo Vivi Cc: Ville Syrjälä Signed-off-by:

[Intel-gfx] [PATCH v2 7/8] drm/i915: Introduce a non-blocking power domain for vblank interrupts

When DC states are enabled and PSR is active, the hardware enters DC5/DC6 states resulting in frame counter resets. The frame counter resets mess up the vblank counting logic. In order to disable DC states when vblank interrupts are required and to disallow DC states when vblanks interrupts are

[Intel-gfx] [PATCH v2 5/8] drm/vblank: Restoring vblank counts after device runtime PM events.

The HW frame counter can get reset when devices enters low power states and this messes up any following vblank count updates. So, compute the missed vblank interrupts for that low power state duration using time stamps. This is similar to _crtc_vblank_on() except that it doesn't enable vblank

[Intel-gfx] [PATCH v2 6/8] drm/i915: Use an atomic_t array to track power domain use count.

Convert the power_domains->domain_use_count array that tracks per-domain use count to atomic_t type. This is needed to be able to read/write the use counts outside of the power domain mutex. Cc: Daniel Vetter Cc: Ville Syrjälä Cc: Rodrigo

[Intel-gfx] [PATCH v2 8/8] drm/i915: Use the vblank power domain disallow or disable DC states.

Disable DC states before enabling vblank interrupts and conversely enable DC states after disabling. Since the frame counter may have got reset between disabling and enabling, use drm_crtc_vblank_restore() to compute the missed vblanks. Cc: Daniel Vetter Cc: Ville Syrjälä

[Intel-gfx] [PATCH v2 0/8] Fix PSR-vblank-DMC interaction

The first 3 patches are minor PSR improvements. The last 5 introduce a new power domain to disable DC states when vblanks are required. The tricky part is to enable and disable the DC_OFF power well in atomic context. I have addressed the locking issues that CI caught in the last revision.

[Intel-gfx] [PATCH v2 3/8] drm/i915/psr: Avoid initializing PSR if there is no sink support.

DPCD read for the eDP is complete by the time intel_psr_init() is called, which means we can avoid initializing PSR structures and state if there is no sink support. Cc: Rodrigo Vivi Cc: Ville Syrjälä Signed-off-by: Dhinakaran Pandiyan

[Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [1/2] drm/i915: Implement WaDisableVFclkgate.

== Series Details == Series: series starting with [1/2] drm/i915: Implement WaDisableVFclkgate. URL : https://patchwork.freedesktop.org/series/35456/ State : success == Summary == Test kms_frontbuffer_tracking: Subgroup fbc-1p-offscren-pri-shrfb-draw-render: fail

Re: [Intel-gfx] [RFC] drm/i915: Add a new modparam for customized ring multiplier

On 12/18/2017 01:47 PM, Chris Wilson wrote: Quoting Jackie Li (2017-12-18 21:22:08) From: Zhipeng Gong SKL platforms requires a higher ring multiplier when there's massive GPU load. Current driver doesn't provide a way to override the ring multiplier. This patch adds

[Intel-gfx] ✗ Fi.CI.BAT: failure for overlay: parse tracepoints from sysfs to figure out fields' location (rev2)

== Series Details == Series: overlay: parse tracepoints from sysfs to figure out fields' location (rev2) URL : https://patchwork.freedesktop.org/series/35545/ State : failure == Summary == IGT patchset build failed on latest successful build cfb711c046c22c3881d2334f0b43ec4eb0b9a5fc

[Intel-gfx] [PATCH i-g-t v2] overlay: parse tracepoints from sysfs to figure out fields' location

With changes going to drm-tip, the tracepoints field locations are going to change. This change introduces a tracepoint parser (using a peg parser) which lets us figure out field positions on the fly. v2: Fix automake build (Lionel) Signed-off-by: Lionel Landwerlin

[Intel-gfx] ✗ Fi.CI.BAT: failure for overlay: parse tracepoints from sysfs to figure out fields' location

== Series Details == Series: overlay: parse tracepoints from sysfs to figure out fields' location URL : https://patchwork.freedesktop.org/series/35545/ State : failure == Summary == IGT patchset build failed on latest successful build cfb711c046c22c3881d2334f0b43ec4eb0b9a5fc scripts/trace.pl:

[Intel-gfx] [PATCH i-g-t] overlay: parse tracepoints from sysfs to figure out fields' location

With changes going to drm-tip, the tracepoints field locations are going to change. This change introduces a tracepoint parser (using a peg parser) which lets us figure out field positions on the fly. Signed-off-by: Lionel Landwerlin --- configure.ac

Re: [Intel-gfx] [PATCH i-g-t] igt/kms_rotation_crc: Add horizontal flip subtest.

>-Original Message- >From: daniel.vet...@ffwll.ch [mailto:daniel.vet...@ffwll.ch] On Behalf Of >Daniel >Vetter >Sent: Thursday, December 14, 2017 2:14 AM >To: Srivatsa, Anusha ; Strano, Luis >; Latvala, Petri ;

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/2] drm/i915: Implement WaDisableVFclkgate.

== Series Details == Series: series starting with [1/2] drm/i915: Implement WaDisableVFclkgate. URL : https://patchwork.freedesktop.org/series/35456/ State : success == Summary == Series 35456v1 series starting with [1/2] drm/i915: Implement WaDisableVFclkgate.

Re: [Intel-gfx] [PATCH v2] drm/i915: Generalize definition for crtc mask

On Wed, Dec 13, 2017 at 09:25:16AM +, Mika Kahola wrote: > crtc_mask is defined explicitly defined for a certain number of pipes per > platform. Let's generalize this in a way that crtc_mask dependens only on > the number of pipes defined in device info. > > v2: Use BIT() macro wherever

Re: [Intel-gfx] [PATCH i-g-t] igt/kms_rotation_crc: Add horizontal flip subtest.

On Thu, Dec 14, 2017 at 10:14:19AM +, Daniel Vetter wrote: > On Thu, Nov 23, 2017 at 12:05 AM, Anusha Srivatsa > wrote: > > From: Joseph Garvey > > > > Test that horizontal flip works with supported rotations. Includes > > a fix for the

Re: [Intel-gfx] No display if I plug in the VGA cable after entering OS

Hi there, Please report a bug on bugzilla.freedesktop.org as instructed on https://01.org/linuxgraphics/documentation/how-report-bugs We will need more info about your platform and more logs to determine what is happening on your case. Thanks, Rodrigo. On Mon, Dec 18, 2017 at 10:45:53AM +,

Re: [Intel-gfx] [PATCH i-g-t] scripts/trace.pl: Auto-detect tracepoint field order

On 12/18/2017 4:02 AM, Tvrtko Ursulin wrote: From: Tvrtko Ursulin Instead of hard-coding the order of key-value pairs into regular expressions, auto-detect them as we go. At the same time re-factor the code so it is smaller and even slightly faster (10-15% by a quick

[Intel-gfx] No display if I plug in the VGA cable after entering OS

Hello, I need you help. I have a display problem about Intel Graphics driver. I use CentOS7.4(Kernel 3.10.0-693), and enter to OS without VGA cable. After entering OS, I plug in VGA cable but without display on my monitor. I also try to test Win10. If I install the Graphics driver, this problem

Re: [Intel-gfx] [PATCH] drm/i915/cnl: Add support for horizontal plane flipping

On Sat, Dec 16, 2017 at 03:25:01PM +, Ville Syrjälä wrote: > On Fri, Dec 15, 2017 at 10:22:25PM +, Chris Wilson wrote: > > Quoting Rodrigo Vivi (2017-12-15 21:38:00) > > > From: Joonas Lahtinen > > > > > > CNL supports horizontal plane flipping on

[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915: Add a new modparam for customized ring multiplier

== Series Details == Series: drm/i915: Add a new modparam for customized ring multiplier URL : https://patchwork.freedesktop.org/series/35535/ State : failure == Summary == Test kms_fbcon_fbt: Subgroup fbc-suspend: pass -> SKIP (shard-hsw) Test

Re: [Intel-gfx] [PATCH v2] drm/i915: Protect DDI port to DPLL map from theoretical race.

On Mon, Dec 18, 2017 at 10:40:02AM +, Maarten Lankhorst wrote: > Op 15-12-17 om 23:43 schreef Rodrigo Vivi: > > In case we have multiple modesets for different connectors > > happening in parallel we could have a race on the RMW on these > > shared registers. > > > > This possibility was

Re: [Intel-gfx] [PATCH 3/3] drm/i915/selftests: Fix up igt_reset_engine

Quoting Michel Thierry (2017-12-18 21:50:17) > On 17/12/17 05:28, Chris Wilson wrote: > > Now that we skip a per-engine reset on an idle engine, we need to update > > the selftest to take that into account. In the process, we find that we > > were not stressing the per-engine reset very hard, so

Re: [Intel-gfx] [PATCH 3/3] drm/i915/selftests: Fix up igt_reset_engine

On 17/12/17 05:28, Chris Wilson wrote: Now that we skip a per-engine reset on an idle engine, we need to update the selftest to take that into account. In the process, we find that we were not stressing the per-engine reset very hard, so add those missing active resets. v2: Actually test

Re: [Intel-gfx] [RFC] drm/i915: Add a new modparam for customized ring multiplier

Quoting Jackie Li (2017-12-18 21:22:08) > From: Zhipeng Gong > > SKL platforms requires a higher ring multiplier when there's massive > GPU load. Current driver doesn't provide a way to override the ring > multiplier. > > This patch adds a new module parameter to allow

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Add a new modparam for customized ring multiplier

== Series Details == Series: drm/i915: Add a new modparam for customized ring multiplier URL : https://patchwork.freedesktop.org/series/35535/ State : success == Summary == Series 35535v1 drm/i915: Add a new modparam for customized ring multiplier

[Intel-gfx] [RFC] drm/i915: Add a new modparam for customized ring multiplier

From: Zhipeng Gong SKL platforms requires a higher ring multiplier when there's massive GPU load. Current driver doesn't provide a way to override the ring multiplier. This patch adds a new module parameter to allow the overriding of ring multiplier for Gen9 platforms.

Re: [Intel-gfx] [PATCH 1/2] drm/i915: Add pretty printer for device info flags

Quoting Jani Nikula (2017-12-18 17:37:13) > On Mon, 18 Dec 2017, Chris Wilson wrote: > > Looks good, I'm thinking we might push the drm_printer to the caller of > > intel_device_info_dump(), but this is already a substantial improvement > > Param ordering seems a bit

Re: [Intel-gfx] [PATCH] drm/i915/glk: Disable Guc and HuC on GLK

On Mon, 18 Dec 2017 20:25:17 +0100, Srivatsa, Anusha wrote: -Original Message- From: Vivi, Rodrigo Sent: Friday, December 15, 2017 3:03 PM To: Wajdeczko, Michal Cc: intel-gfx@lists.freedesktop.org; Srivatsa, Anusha

Re: [Intel-gfx] [PATCH i-g-t] tests/gem_ctx_param: Update invalid param

Quoting Antonio Argenziano (2017-12-18 18:15:35) > > > On 15/12/17 16:14, Chris Wilson wrote: > > Quoting Antonio Argenziano (2017-12-15 19:01:11) > >> + arg.param = I915_CONTEXT_PARAM_PRIORITY; > >> + > >> + igt_subtest("root-set-priority") { > >> + arg.ctx_id = ctx; >

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/guc : Decoupling ADS and logs from submission

== Series Details == Series: drm/i915/guc : Decoupling ADS and logs from submission URL : https://patchwork.freedesktop.org/series/35530/ State : success == Summary == Test drv_suspend: Subgroup debugfs-reader: skip -> PASS (shard-hsw) Test

[Intel-gfx] [PULL] drm-intel-next

Hi Dave, I expect to have one more pile next week for rc6. But for now consider already applying this one. On this one here we had one backmerge for a reconciliation drm_print.h between us and drm-misc-next. But that should be transparent to you. On the GVT side it is worth to highlight that

Re: [Intel-gfx] [PATCH v4 0/9] drm/i915: Implement HDCP

On Thu, Dec 7, 2017 at 5:38 AM, Jose Abreu wrote: > Hi Sean, > > On 07-12-2017 00:00, Sean Paul wrote: >> Welcome to version 4 of the patchset. I think we're nearing the finish line >> (hopefully) now. This set addresses the review feedback from v3. I applied >> some >>

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/guc : Decoupling ADS and logs from submission

== Series Details == Series: drm/i915/guc : Decoupling ADS and logs from submission URL : https://patchwork.freedesktop.org/series/35530/ State : success == Summary == Series 35530v1 drm/i915/guc : Decoupling ADS and logs from submission

[Intel-gfx] ✗ Fi.CI.IGT: warning for scripts/trace.pl: Remove some old code

== Series Details == Series: scripts/trace.pl: Remove some old code URL : https://patchwork.freedesktop.org/series/35526/ State : warning == Summary == Test kms_frontbuffer_tracking: Subgroup fbc-1p-offscren-pri-shrfb-draw-render: fail -> PASS (shard-snb)

Re: [Intel-gfx] [PATCH] drm/i915/glk: Disable Guc and HuC on GLK

>-Original Message- >From: Vivi, Rodrigo >Sent: Friday, December 15, 2017 3:03 PM >To: Wajdeczko, Michal >Cc: intel-gfx@lists.freedesktop.org; Srivatsa, Anusha > >Subject: Re: [Intel-gfx] [PATCH] drm/i915/glk: Disable Guc and HuC on

Re: [Intel-gfx] [PATCH 5/5] drm/i915: Add YCBCR 4:2:0 support for LSPCON

Op 14-11-17 om 16:17 schreef Shashank Sharma: > LSPCON chips are capable of generating YCBCR 4:2:0 outputs, if asked > nicely :). In order to generate YCBCR 4:2:0 outputs, a source must: > - send YCBCR 4:4:4 signals to LSPCON > - program color space as 4:2:0 in AVI infoframes > > This will

Re: [Intel-gfx] [PATCH 4/5] drm/i915: Write AVI infoframes for Parade LSPCON

Op 14-11-17 om 16:17 schreef Shashank Sharma: > Different LSPCON vendors specify their custom methods to pass > AVI infoframes to the LSPCON chip, so does Parade tech. > > This patch adds functions to arrange and write AVI infoframes > into Parade LSPCON chips. > > Signed-off-by: Shashank Sharma

[Intel-gfx] [PATCH] drm/i915/guc : Decoupling ADS and logs from submission

The Additional Data Struct (ADS) contains objects that are required by GuC post FW load and are not necessarily submission-only. Even with submission disabled we may require something inside the ADS, so it makes more sense for them to be always created. Similarly, we still want to access GuC logs

Re: [Intel-gfx] [PATCH i-g-t] tests/gem_ctx_param: Update invalid param

On 15/12/17 16:14, Chris Wilson wrote: Quoting Antonio Argenziano (2017-12-15 19:01:11) Since commit: drm/i915/scheduler: Support user-defined priorities, the driver support an extra context param to set context's priority. Add tests for that interface and update invalid tests.

[Intel-gfx] ✓ Fi.CI.BAT: success for scripts/trace.pl: Remove some old code

== Series Details == Series: scripts/trace.pl: Remove some old code URL : https://patchwork.freedesktop.org/series/35526/ State : success == Summary == IGT patchset tested on top of latest successful build cfb711c046c22c3881d2334f0b43ec4eb0b9a5fc scripts/trace.pl: Auto-detect tracepoint

Re: [Intel-gfx] [PATCH] kthread: finer-grained lockdep/cross-release completion

On Sun, Dec 17, 2017 at 11:11 PM, Daniel Vetter wrote: > > This didn't seem to have made it into -rc4. Anything needed to get it > going? Do you actually see the problem in -rc4? Because we ended up removing the cross-release checking due to other developers complaining. It

Re: [Intel-gfx] [PATCH 1/2] drm/i915: Add pretty printer for device info flags

On Mon, 18 Dec 2017, Chris Wilson wrote: > Quoting Michal Wajdeczko (2017-12-18 15:51:31) >> We dump device flags in few places (init_early, debugfs, gpu_error) >> using different functions. Lets add reusable function to avoid >> code duplication. >> >> add/remove: 1/0

[Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [1/2] drm/i915: Add pretty printer for device info flags

== Series Details == Series: series starting with [1/2] drm/i915: Add pretty printer for device info flags URL : https://patchwork.freedesktop.org/series/35521/ State : success == Summary == Test drv_selftest: Subgroup live_hangcheck: incomplete -> PASS

Re: [Intel-gfx] 995d11c4c0 ("drm: rework delayed connector cleanup in .."): WARNING: possible circular locking dependency detected

Op 18-12-17 om 08:08 schreef Daniel Vetter: > Hm, the bisect looks funny. Only way I can explain that is that my > patch fixed a pre-existing lockdep splat, and uncovered the issue in > the ww-mutex self tests. That one is uncovered by the new > cross-release lockdep checks in 4.15. > > Anyway I

[Intel-gfx] [PATCH i-g-t] scripts/trace.pl: Remove some old code

From: Tvrtko Ursulin Remove some inactive code which was only uised to support the old execlists implementation. It is hidden behind a toggle which is not user accesible anyway. Signed-off-by: Tvrtko Ursulin Cc: John Harrison

[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915: improve tracepoints for process/hw_id tracking (rev2)

== Series Details == Series: drm/i915: improve tracepoints for process/hw_id tracking (rev2) URL : https://patchwork.freedesktop.org/series/35506/ State : failure == Summary == Test kms_pipe_crc_basic: Subgroup suspend-read-crc-pipe-a: pass -> SKIP

Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for tests: add i915 query tests

Oops, forgot to send the patch dumping the i915 headers :( On 18/12/17 16:49, Patchwork wrote: == Series Details == Series: tests: add i915 query tests URL : https://patchwork.freedesktop.org/series/35520/ State : failure == Summary == IGT patchset build failed on latest successful build

[Intel-gfx] ✗ Fi.CI.BAT: failure for tests: add i915 query tests

== Series Details == Series: tests: add i915 query tests URL : https://patchwork.freedesktop.org/series/35520/ State : failure == Summary == IGT patchset build failed on latest successful build c0be3310715e2f744b892c51f09e62273bcc8e57 tests/kms_frontbuffer_tracking: Correctly handle debugfs

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/2] drm/i915: Add pretty printer for device info flags

== Series Details == Series: series starting with [1/2] drm/i915: Add pretty printer for device info flags URL : https://patchwork.freedesktop.org/series/35521/ State : success == Summary == Series 35521v1 series starting with [1/2] drm/i915: Add pretty printer for device info flags

Re: [Intel-gfx] [PATCH v2 2/2] drm/i915/trace: add hw_id to gem requests trace points

On 18/12/17 15:22, Chris Wilson wrote: Quoting Lionel Landwerlin (2017-12-18 15:19:59) When monitoring the GPU with i915 perf, reports are tagged with a hw id. Gem context creation tracepoints already have a hw_id field, unfortunately you only get this correlation between a process id and a hw

Re: [Intel-gfx] [PATCH 4/5] drm/atomic: document how to handle driver private objects

Hi Daniel, Thank you for the patch. On Thursday, 14 December 2017 22:30:53 EET Daniel Vetter wrote: > DK put some nice docs into the commit introducing driver private > state, but in the git history alone it'll be lost. You might want to spell DK's name fully. > Also, since Ville remove the

Re: [Intel-gfx] [PATCH 2/2] drm/i915: Add pretty printer for modparams

Quoting Michal Wajdeczko (2017-12-18 15:51:32) > We dump modparams in few places (debugfs, gpu_error) using different > functions. Lets add reusable function to avoid code duplication. > > add/remove: 1/0 grow/shrink: 0/2 up/down: 1096/-2339 (-1243) > Function

Re: [Intel-gfx] [PATCH 4/5] drm/atomic: document how to handle driver private objects

Hi Alex, On Friday, 15 December 2017 03:57:48 EET Alex Deucher wrote: > On Thu, Dec 14, 2017 at 3:30 PM, Daniel Vetter wrote: > > DK put some nice docs into the commit introducing driver private > > state, but in the git history alone it'll be lost. > > > > Also, since Ville remove the void*

Re: [Intel-gfx] [PATCH 1/2] drm/i915: Add pretty printer for device info flags

Quoting Michal Wajdeczko (2017-12-18 15:51:31) > We dump device flags in few places (init_early, debugfs, gpu_error) > using different functions. Lets add reusable function to avoid > code duplication. > > add/remove: 1/0 grow/shrink: 0/3 up/down: 1296/-3572 (-2276) > Function

[Intel-gfx] ✗ Fi.CI.BAT: warning for drm/i915: expose RCS topology to userspace

== Series Details == Series: drm/i915: expose RCS topology to userspace URL : https://patchwork.freedesktop.org/series/35519/ State : warning == Summary == Series 35519v1 drm/i915: expose RCS topology to userspace https://patchwork.freedesktop.org/api/1.0/series/35519/revisions/1/mbox/ Test

Re: [Intel-gfx] [PATCH i-g-t] scripts/trace.pl: Auto-detect tracepoint field order

On 18/12/17 12:02, Tvrtko Ursulin wrote: From: Tvrtko Ursulin Instead of hard-coding the order of key-value pairs into regular expressions, auto-detect them as we go. At the same time re-factor the code so it is smaller and even slightly faster (10-15% by a quick

[Intel-gfx] [PATCH 1/2] drm/i915: Add pretty printer for device info flags

We dump device flags in few places (init_early, debugfs, gpu_error) using different functions. Lets add reusable function to avoid code duplication. add/remove: 1/0 grow/shrink: 0/3 up/down: 1296/-3572 (-2276) Function old new delta

[Intel-gfx] [PATCH 2/2] drm/i915: Add pretty printer for modparams

We dump modparams in few places (debugfs, gpu_error) using different functions. Lets add reusable function to avoid code duplication. add/remove: 1/0 grow/shrink: 0/2 up/down: 1096/-2339 (-1243) Function old new delta i915_params_dump

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: improve tracepoints for process/hw_id tracking (rev2)

== Series Details == Series: drm/i915: improve tracepoints for process/hw_id tracking (rev2) URL : https://patchwork.freedesktop.org/series/35506/ State : success == Summary == Series 35506v2 drm/i915: improve tracepoints for process/hw_id tracking

Re: [Intel-gfx] [PATCH 4/6] drm/i915: add rcs topology to error state

Quoting Lionel Landwerlin (2017-12-18 15:35:18) > This might be useful information for developers looking at an error > state. > > Signed-off-by: Lionel Landwerlin > --- > drivers/gpu/drm/i915/i915_gpu_error.c | 35 > +++ > 1 file

[Intel-gfx] [PATCH i-g-t] tests: add i915 query tests

Signed-off-by: Lionel Landwerlin --- tests/Makefile.sources | 1 + tests/meson.build | 1 + tests/query.c | 262 + 3 files changed, 264 insertions(+) create mode 100644 tests/query.c diff --git

[Intel-gfx] [PATCH 5/6] drm/i915: add query uAPI

There are a number of information that are readable from hardware registers and that we would like to make accessible to userspace. One particular example is the topology of the execution units (how are execution units grouped in subslices and slices and also which ones have been fused off for die

[Intel-gfx] [PATCH 4/6] drm/i915: add rcs topology to error state

This might be useful information for developers looking at an error state. Signed-off-by: Lionel Landwerlin --- drivers/gpu/drm/i915/i915_gpu_error.c | 35 +++ 1 file changed, 35 insertions(+) diff --git

[Intel-gfx] [PATCH 6/6] drm/i915: expose rcs topology through query uAPI

With the introduction of asymetric slices in CNL, we cannot rely on the previous SUBSLICE_MASK getparam to tell userspace what subslices are available. Here we introduce a more detailed way of querying the Gen's GPU topology that doesn't aggregate numbers. This is essential for monitoring parts

[Intel-gfx] [PATCH 3/6] drm/i915/debugfs: add rcs topology entry

While the end goal is to make this information available to userspace through a new ioctl, there is no reason we can't display it in a human readable fashion through debugfs. slice0 (subslice_mask=0x7): subslice0: eu_mask: 0xff (8) subslice1:

[Intel-gfx] [PATCH 2/6] drm/i915/debugfs: reuse max slice/subslices already stored in sseu

Now that we have that information in topology fields, let's just reused it. Signed-off-by: Lionel Landwerlin --- drivers/gpu/drm/i915/i915_debugfs.c | 26 ++ 1 file changed, 10 insertions(+), 16 deletions(-) diff --git

[Intel-gfx] [PATCH 0/6] drm/i915: expose RCS topology to userspace

Hi all, This series a respin of a few attempts ([1], [2], [3]) to expose RCS topology to userspace. The motivation for this is to be able to monitor part of the GPU using i915 perf and have detailled knowledge about what execution units are fused off. Let's say you monitor slice 1, knowing how

[Intel-gfx] [PATCH 1/6] drm/i915: store all subslice masks

Up to now, subslice mask was assumed to be uniform across slices. But starting with Cannonlake, slices can be asymetric (for example slice0 has different number of subslices as slice1+). This change stores all subslices masks for all slices rather than having a single mask that applies to all

Re: [Intel-gfx] [PATCH v2 2/2] drm/i915/trace: add hw_id to gem requests trace points

Quoting Lionel Landwerlin (2017-12-18 15:19:59) > When monitoring the GPU with i915 perf, reports are tagged with a hw > id. Gem context creation tracepoints already have a hw_id field, > unfortunately you only get this correlation between a process id and a > hw context id once when the context

[Intel-gfx] [PATCH v2 0/2] drm/i915: improve tracepoints for process/hw_id tracking

Hey, I did miss a tracepoint in patch 2. Fixed! Cheers, Lionel Landwerlin (2): drm/i915: reorder field in gem_request tracepoints drm/i915/trace: add hw_id to gem requests trace points drivers/gpu/drm/i915/i915_trace.h | 40 +++ 1 file changed, 24

[Intel-gfx] [PATCH v2 2/2] drm/i915/trace: add hw_id to gem requests trace points

When monitoring the GPU with i915 perf, reports are tagged with a hw id. Gem context creation tracepoints already have a hw_id field, unfortunately you only get this correlation between a process id and a hw context id once when the context is created. It doesn't help if you started monitoring

[Intel-gfx] [PATCH v2 1/2] drm/i915: reorder field in gem_request tracepoints

Let's make the order of the fields of the tracepoints involving gem request match across i915. This makes userspace processing of tracepoint a bit easier. Suggested-by: Chris Wilson Signed-off-by: Lionel Landwerlin Reviewed-by: Chris

[Intel-gfx] ✗ Fi.CI.BAT: failure for intel_vbt_decode: Typo fixes

== Series Details == Series: intel_vbt_decode: Typo fixes URL : https://patchwork.freedesktop.org/series/35441/ State : failure == Summary == IGT patchset tested on top of latest successful build c0be3310715e2f744b892c51f09e62273bcc8e57 tests/kms_frontbuffer_tracking: Correctly handle

Re: [Intel-gfx] [PATCH 2/2] drm/i915/trace: add hw_id to gem requests trace points

On 18/12/17 13:35, Chris Wilson wrote: Quoting Lionel Landwerlin (2017-12-18 12:12:48) When monitoring the GPU with i915 perf, reports are tagged with a hw id. Gem context creation tracepoints already have a hw_id field, unfortunately you only get this correlation between a process id and a hw

[Intel-gfx] ✓ Fi.CI.BAT: success for scripts/trace.pl: Auto-detect tracepoint field order

== Series Details == Series: scripts/trace.pl: Auto-detect tracepoint field order URL : https://patchwork.freedesktop.org/series/35504/ State : success == Summary == IGT patchset tested on top of latest successful build c0be3310715e2f744b892c51f09e62273bcc8e57 tests/kms_frontbuffer_tracking:

Re: [Intel-gfx] [PATCH 2/2] drm/i915/trace: add hw_id to gem requests trace points

Quoting Lionel Landwerlin (2017-12-18 12:12:48) > When monitoring the GPU with i915 perf, reports are tagged with a hw > id. Gem context creation tracepoints already have a hw_id field, > unfortunately you only get this correlation between a process id and a > hw context id once when the context

Re: [Intel-gfx] [PATCH 1/2] drm/i915: reorder field in gem_request tracepoints

Quoting Lionel Landwerlin (2017-12-18 12:12:47) > Let's make the order of the fields of the tracepoints involving gem > request match across i915. This makes userspace processing of > tracepoint a bit easier. > > Suggested-by: Chris Wilson > Signed-off-by: Lionel

[Intel-gfx] ✗ Fi.CI.BAT: warning for intel_vbt_decode: Typo fixes

== Series Details == Series: intel_vbt_decode: Typo fixes URL : https://patchwork.freedesktop.org/series/35441/ State : warning == Summary == IGT patchset tested on top of latest successful build c0be3310715e2f744b892c51f09e62273bcc8e57 tests/kms_frontbuffer_tracking: Correctly handle

Re: [Intel-gfx] [PATCH v4] drm/i915: Show IPEIR and IPEHR in the engine dump

Quoting Tvrtko Ursulin (2017-12-18 12:58:51) > > On 18/12/2017 12:39, Chris Wilson wrote: > > A useful bit of information for inspecting GPU stalls from > > intel_engine_dump() are the error registers, IPEIR and IPEHR. > > > > v2: Fixup gen changes in register offsets (Tvrtko) > > v3: Old FADDR

Re: [Intel-gfx] [PATCH v5] drm/i915/userptr: Probe vma range before gup

On 15/12/2017 14:48, Chris Wilson wrote: We want to exclude any GGTT objects from being present on our internal lists to avoid the deadlock we may run into with our requirement for struct_mutex during invalidate. However, if the gup_fast fails, we put the userptr onto the workqueue and mark it

[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [1/3] drm/i915: Re-enable GGTT earlier after GPU reset (rev4)

== Series Details == Series: series starting with [1/3] drm/i915: Re-enable GGTT earlier after GPU reset (rev4) URL : https://patchwork.freedesktop.org/series/35471/ State : failure == Summary == Series 35471v4 series starting with [1/3] drm/i915: Re-enable GGTT earlier after GPU reset

Re: [Intel-gfx] [PATCH 4/4] drm/i915: push shared dpll enable to encoders on DDI platforms

> -Original Message- > From: Nikula, Jani > Sent: Monday, December 18, 2017 6:21 PM > To: Chauhan, Madhav ; intel- > g...@lists.freedesktop.org > Cc: Daniel Vetter > Subject: RE: [Intel-gfx] [PATCH 4/4] drm/i915: push shared dpll enable to

Re: [Intel-gfx] [PATCH v4] drm/i915: Show IPEIR and IPEHR in the engine dump

On 18/12/2017 12:39, Chris Wilson wrote: A useful bit of information for inspecting GPU stalls from intel_engine_dump() are the error registers, IPEIR and IPEHR. v2: Fixup gen changes in register offsets (Tvrtko) v3: Old FADDR location as well v4: Use I915_READ64_2x32 Signed-off-by: Chris

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: improve tracepoints for process/hw_id tracking

== Series Details == Series: drm/i915: improve tracepoints for process/hw_id tracking URL : https://patchwork.freedesktop.org/series/35506/ State : success == Summary == Series 35506v1 drm/i915: improve tracepoints for process/hw_id tracking

Re: [Intel-gfx] [PATCH 4/4] drm/i915: push shared dpll enable to encoders on DDI platforms

On Mon, 18 Dec 2017, "Chauhan, Madhav" wrote: >> -Original Message- >> From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf Of >> Jani Nikula >> Sent: Thursday, October 12, 2017 9:36 PM >> To: intel-gfx@lists.freedesktop.org >> Cc: Nikula,

[Intel-gfx] [PATCH v4] drm/i915: Show IPEIR and IPEHR in the engine dump

A useful bit of information for inspecting GPU stalls from intel_engine_dump() are the error registers, IPEIR and IPEHR. v2: Fixup gen changes in register offsets (Tvrtko) v3: Old FADDR location as well v4: Use I915_READ64_2x32 Signed-off-by: Chris Wilson Cc: Mika

Re: [Intel-gfx] [PATCH v3] drm/i915: Show IPEIR and IPEHR in the engine dump

Quoting Tvrtko Ursulin (2017-12-18 12:32:37) > > On 18/12/2017 12:17, Chris Wilson wrote: > > A useful bit of information for inspecting GPU stalls from > > intel_engine_dump() are the error registers, IPEIR and IPEHR. > > > > v2: Fixup gen changes in register offsets (Tvrtko) > > v3: Old FADDR

Re: [Intel-gfx] [PATCH v3] drm/i915: Show IPEIR and IPEHR in the engine dump

On 18/12/2017 12:17, Chris Wilson wrote: A useful bit of information for inspecting GPU stalls from intel_engine_dump() are the error registers, IPEIR and IPEHR. v2: Fixup gen changes in register offsets (Tvrtko) v3: Old FADDR location as well Signed-off-by: Chris Wilson

Re: [Intel-gfx] [PATCH 4/4] drm/i915: push shared dpll enable to encoders on DDI platforms

> -Original Message- > From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf Of > Jani Nikula > Sent: Thursday, October 12, 2017 9:36 PM > To: intel-gfx@lists.freedesktop.org > Cc: Nikula, Jani ; Daniel Vetter > >

[Intel-gfx] [PATCH v3] drm/i915: Show IPEIR and IPEHR in the engine dump

A useful bit of information for inspecting GPU stalls from intel_engine_dump() are the error registers, IPEIR and IPEHR. v2: Fixup gen changes in register offsets (Tvrtko) v3: Old FADDR location as well Signed-off-by: Chris Wilson Cc: Mika Kuoppala

[Intel-gfx] [PATCH 0/2] drm/i915: improve tracepoints for process/hw_id tracking

Hi, These are just a couple of changes to allow process/hw_id correlation when using i915 perf to monitor the workloads on the GPU. Cheers, Lionel Landwerlin (2): drm/i915: reorder field in gem_request tracepoints drm/i915/trace: add hw_id to gem requests trace points

[Intel-gfx] [PATCH 2/2] drm/i915/trace: add hw_id to gem requests trace points

When monitoring the GPU with i915 perf, reports are tagged with a hw id. Gem context creation tracepoints already have a hw_id field, unfortunately you only get this correlation between a process id and a hw context id once when the context is created. It doesn't help if you started monitoring

[Intel-gfx] [PATCH 1/2] drm/i915: reorder field in gem_request tracepoints

Let's make the order of the fields of the tracepoints involving gem request match across i915. This makes userspace processing of tracepoint a bit easier. Suggested-by: Chris Wilson Signed-off-by: Lionel Landwerlin ---

Re: [Intel-gfx] [PATCH v2] drm/i915: Show IPEIR and IPEHR in the engine dump

On 18/12/2017 11:26, Chris Wilson wrote: A useful bit of information for inspecting GPU stalls from intel_engine_dump() are the error registers, IPEIR and IPEHR. v2: Fixup gen changes in register offsets (Tvrtko) Signed-off-by: Chris Wilson Cc: Mika Kuoppala

  1   2   >