[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/scheduler: add gvt force-single-submission and notification for guc (rev4)

== Series Details == Series: drm/i915/scheduler: add gvt force-single-submission and notification for guc (rev4) URL : https://patchwork.freedesktop.org/series/21972/ State : failure == Summary == Series 21972v4 drm/i915/scheduler: add gvt force-single-submission and notification for guc htt

Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/scheduler: add gvt force-single-submission and notification for guc (rev4)

Hi, > == Series Details == > > Series: drm/i915/scheduler: add gvt force-single-submission and notification > for guc (rev4) > URL : https://patchwork.freedesktop.org/series/21972/ > State : failure > > == Summary == > > Series 21972v4 drm/i915/scheduler: add gvt force-single-submission and >

Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/scheduler: add gvt force-single-submission and notification for guc (rev4)

> -Original Message- > From: Saarinen, Jani > Sent: Thursday, April 20, 2017 2:30 PM > To: intel-gfx@lists.freedesktop.org; Dong, Chuanxiao > > Subject: RE: [Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/scheduler: add gvt > force-single-submission and notification for guc (rev4) > > Hi,

Re: [Intel-gfx] [PATCH v4 2/9] drm/i915: Add plumbing for digital connector state, v2.

On 19-04-17 17:48, Daniel Vetter wrote: > On Wed, Apr 12, 2017 at 12:50:00PM +0200, Maarten Lankhorst wrote: >> Some atomic properties are common between the various kinds of >> connectors, for example a lot of them use panel fitting mode. >> It makes sense to put a lot of it in a common place, so

[Intel-gfx] [RESEND][GIT PULL] GVT-g next fixes for 4.12

Hi, Please pull gvt next fixes for 4.12. (resend with subscribed mail address.) Thanks. -- The following changes since commit b35f34d1da4e77637869c8041a355da810f69fb6: drm/i915/gvt: control the scheduler by timeslice usage (2017-03-30 13:34:10 +0800) are available in the git repository a

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/scheduler: add gvt force-single-submission and notification for guc (rev4)

== Series Details == Series: drm/i915/scheduler: add gvt force-single-submission and notification for guc (rev4) URL : https://patchwork.freedesktop.org/series/21972/ State : failure == Summary == Series 21972v4 drm/i915/scheduler: add gvt force-single-submission and notification for guc htt

[Intel-gfx] [GIT PULL] GVT-g next fixes for 4.12

Hi, Please pull gvt next fixes for 4.12. Thanks -- The following changes since commit b35f34d1da4e77637869c8041a355da810f69fb6: drm/i915/gvt: control the scheduler by timeslice usage (2017-03-30 13:34:10 +0800) are available in the git repository at: https://github.com/01org/gvt-linux.g

[Intel-gfx] [PATCH 4/4] drm/i915/scheduler: add gvt notification for guc

GVT request needs a manual mmio load/restore. Before GuC submit a request, send notification to gvt for mmio loading. And after the GuC finished this GVT request, notify gvt again for mmio restore. This follows the usage when using execlists submission. Cc: xiao.zh...@intel.com Cc: kevin.t...@inte

[Intel-gfx] [PATCH 2/4] drm/i915: refactor gvt context notification

refactor gvt context notification to proper files v1: use context_status_change instead of execlists_context_status_change for better understanding(ZhengXiao) remove the comment as it is obvious and not friendly to the caller(Kevin) fix indent issues(Joonas) rename the context_status_change to int

[Intel-gfx] [PATCH 3/4] drm/i915/scheduler: add gvt force-single-submission for guc

GVT needs single submission and cannot allow merge. So when GuC submitting a GVT request, the next one should be submitted to guc later until the previous one is completed. This is following the usage when using execlist mode submission. Cc: ch...@chris-wilson.co.uk Signed-off-by: Chuanxiao Dong

[Intel-gfx] [PATCH 1/4] drm/i915: refactor gvt force-single-submission

refactor gvt force-single-submission to proper files v1: make force-single-submission specific to gvt (Chris) keep the original code implementation (Chris) Cc: ch...@chris-wilson.co.uk Signed-off-by: Chuanxiao Dong --- drivers/gpu/drm/i915/i915_gem_context.h | 13 + drivers/gpu/drm/

Re: [Intel-gfx] [PATCH v6 18/20] drm/i915: Watchdog timeout: DRM kernel interface to set the timeout

On 18/04/17 13:23, Michel Thierry wrote: Final enablement patch for GPU hang detection using watchdog timeout. Using the gem_context_setparam ioctl, users can specify the desired timeout value in microseconds, and the driver will do the conversion to 'timestamps'. The recommended default watchdo

Re: [Intel-gfx] [PATCH v2] dma-buf: Rename dma-ops to prevent conflict with kunmap_atomic macro

On 04/19/2017 12:36 PM, Logan Gunthorpe wrote: Seeing the kunmap_atomic dma_buf_ops share the same name with a macro in highmem.h, the former can be aliased if any dma-buf user includes that header. I'm personally trying to include highmem.h inside scatterlist.h and this breaks the dma-buf code

Re: [Intel-gfx] [PATCH v6 14/20] drm/i915/guc: Add support for reset engine using GuC commands

On 19/04/17 03:27, Chris Wilson wrote: On Tue, Apr 18, 2017 at 01:23:29PM -0700, Michel Thierry wrote: This patch adds per engine reset and recovery (TDR) support when GuC is used to submit workloads to GPU. In the case of i915 directly submission to ELSP, driver manages hang detection, recover

Re: [Intel-gfx] [PATCH 02/27] drm/i915: Mark CPU cache as dirty on every transition for CPU writes

Chris, I am sorry that I didn't tell you about GPU that I am working on. It is GEN9LP. Our target is APL-I. So no LLC is available. On Wed, Apr 19, 2017 at 07:26:29PM +0100, Chris Wilson wrote: > On Wed, Apr 19, 2017 at 11:13:17AM -0700, Dongwon Kim wrote: > > Chris, > > > > Just to make sure,

Re: [Intel-gfx] [PATCH 02/27] drm/i915: Mark CPU cache as dirty on every transition for CPU writes

Chris, I think my assumption was not correct. I took out write_domain check but it is still failing. However, here are couple of observation points. I did some experiments.. One of them is to take out even cache_dirty check from eb_move_to_gpu. With this, all sample tests were passing but as you

Re: [Intel-gfx] [PATCH v7 1/2] ACPI / bus: Introduce a list of ids for "always present" devices

On Wed, Apr 19, 2017 at 2:04 PM, Hans de Goede wrote: > Several Bay / Cherry Trail devices (all of which ship with Windows 10) hide > the LPSS PWM controller in ACPI, typically the _STA method looks like this: > > Method (_STA, 0, NotSerialized) // _STA: Status > { > If (OSID == O

[Intel-gfx] ✓ Fi.CI.BAT: success for dma-buf: Rename dma-ops to prevent conflict with kunmap_atomic macro (rev2)

== Series Details == Series: dma-buf: Rename dma-ops to prevent conflict with kunmap_atomic macro (rev2) URL : https://patchwork.freedesktop.org/series/23207/ State : success == Summary == Series 23207v2 dma-buf: Rename dma-ops to prevent conflict with kunmap_atomic macro https://patchwork.f

Re: [Intel-gfx] [PATCH v6 1/3] ACPI / bus: Introduce a list of ids for "always present" devices

On Wed, Apr 19, 2017 at 6:17 PM, Lukas Wunner wrote: > On Wed, Apr 19, 2017 at 12:28:50PM +0200, Rafael J. Wysocki wrote: >> On Wed, Apr 19, 2017 at 10:59 AM, Hans de Goede wrote: >> > On 18-04-17 15:34, Rafael J. Wysocki wrote: >> >> On Tue, Apr 18, 2017 at 1:54 PM, Hans de Goede >> >> wrote:

[Intel-gfx] [PATCH v2] dma-buf: Rename dma-ops to prevent conflict with kunmap_atomic macro

Seeing the kunmap_atomic dma_buf_ops share the same name with a macro in highmem.h, the former can be aliased if any dma-buf user includes that header. I'm personally trying to include highmem.h inside scatterlist.h and this breaks the dma-buf code proper. Christoph Hellwig suggested [1] renaming

[Intel-gfx] [PATCH v6 13/20] drm/i915/guc: Provide register list to be saved/restored during engine reset

From: Arun Siluvery GuC expects a list of registers from the driver which are saved/restored during engine reset. The type of value to be saved is controlled by flags. We provide a minimal set of registers that we want GuC to save and restore. This is not an issue in case of engine reset as drive

Re: [Intel-gfx] [PATCH 02/27] drm/i915: Mark CPU cache as dirty on every transition for CPU writes

On Wed, Apr 19, 2017 at 11:13:17AM -0700, Dongwon Kim wrote: > Chris, > > Just to make sure, you want to just remove write_domain check from > if statement before clflush in execbuffer_move_to_gpu. Am I right? > I will try both (cache_dirty only vs cache_dirty & !cache_coherent) > and get back to

Re: [Intel-gfx] [PATCH 02/27] drm/i915: Mark CPU cache as dirty on every transition for CPU writes

Chris, Just to make sure, you want to just remove write_domain check from if statement before clflush in execbuffer_move_to_gpu. Am I right? I will try both (cache_dirty only vs cache_dirty & !cache_coherent) and get back to you shortly. On Wed, Apr 19, 2017 at 07:08:33PM +0100, Chris Wilson wr

Re: [Intel-gfx] [PATCH v6 16/20] drm/i915: Watchdog timeout: IRQ handler for gen8+

On 19/04/17 10:51, Chris Wilson wrote: On Wed, Apr 19, 2017 at 10:11:37AM -0700, Michel Thierry wrote: On 19/04/17 03:20, Chris Wilson wrote: On Tue, Apr 18, 2017 at 01:23:31PM -0700, Michel Thierry wrote: *** General *** Watchdog timeout (or "media engine reset") is a feature that allows

Re: [Intel-gfx] [PATCH 02/27] drm/i915: Mark CPU cache as dirty on every transition for CPU writes

On Wed, Apr 19, 2017 at 09:52:28AM -0700, Dongwon Kim wrote: > I tried your patch but it didn't fix the original > problem. I think it is somehow related to the flushing condition > here: > > @@ -1129,10 +1129,8 @@ i915_gem_execbuffer_move_to_gpu(struct > drm_i915_gem_request *req, > if (v

Re: [Intel-gfx] [PATCH v6 16/20] drm/i915: Watchdog timeout: IRQ handler for gen8+

On Wed, Apr 19, 2017 at 10:11:37AM -0700, Michel Thierry wrote: > > > On 19/04/17 03:20, Chris Wilson wrote: > >On Tue, Apr 18, 2017 at 01:23:31PM -0700, Michel Thierry wrote: > >>*** General *** > >> > >>Watchdog timeout (or "media engine reset") is a feature that allows > >>userland application

Re: [Intel-gfx] [PATCH 02/27] drm/i915: Mark CPU cache as dirty on every transition for CPU writes

On Wed, Apr 19, 2017 at 09:52:28AM -0700, Dongwon Kim wrote: > I tried your patch but it didn't fix the original > problem. I think it is somehow related to the flushing condition > here: I don't think I actually checked what GPU you observed it on - I was assuming llc, since that was the last bu

Re: [Intel-gfx] [PATCH 02/27] drm/i915: Mark CPU cache as dirty on every transition for CPU writes

On Wed, Apr 19, 2017 at 09:52:28AM -0700, Dongwon Kim wrote: > I tried your patch but it didn't fix the original > problem. I think it is somehow related to the flushing condition > here: > > @@ -1129,10 +1129,8 @@ i915_gem_execbuffer_move_to_gpu(struct > drm_i915_gem_request *req, > if (v

Re: [Intel-gfx] [PATCH v6 16/20] drm/i915: Watchdog timeout: IRQ handler for gen8+

On 19/04/17 03:20, Chris Wilson wrote: On Tue, Apr 18, 2017 at 01:23:31PM -0700, Michel Thierry wrote: *** General *** Watchdog timeout (or "media engine reset") is a feature that allows userland applications to enable hang detection on individual batch buffers. The detection mechanism itself

Re: [Intel-gfx] [PATCH] dma-buf: Rename dma-ops to prevent conflict with kunmap_atomic macro

Minor nits, otherwise the vmwgfx part, Reviewed-by: Sinclair Yeh On Tue, Apr 18, 2017 at 06:17:00PM -0600, Logan Gunthorpe wrote: > Seeing the kunmap_atomic dma_buf_op shares the same name with a macro s^ > in higmem.h, the former can be aliased if any dma-b

Re: [Intel-gfx] [PATCH v6 18/20] drm/i915: Watchdog timeout: DRM kernel interface to set the timeout

On 18/04/17 13:23, Michel Thierry wrote: Final enablement patch for GPU hang detection using watchdog timeout. Using the gem_context_setparam ioctl, users can specify the desired timeout value in microseconds, and the driver will do the conversion to 'timestamps'. The recommended default watch

Re: [Intel-gfx] [PATCH i-g-t 08/13] benchmarks/Android.mk: Add gem_latency to skip list

On Wed, Apr 19, 2017 at 01:01:50PM +0200, Arkadiusz Hiler wrote: > AOSP, as of this commit, does not include libdrm with fence defines. Pushed local defines that should keep the benchmark happy. Please do reset the configure libdrm requirements to what is available on min(Android, debian stable).

Re: [Intel-gfx] [PATCH v6 18/20] drm/i915: Watchdog timeout: DRM kernel interface to set the timeout

On Tue, Apr 18, 2017 at 01:23:33PM -0700, Michel Thierry wrote: > Final enablement patch for GPU hang detection using watchdog timeout. > Using the gem_context_setparam ioctl, users can specify the desired > timeout value in microseconds, and the driver will do the conversion to > 'timestamps'. >

Re: [Intel-gfx] [PATCH 02/27] drm/i915: Mark CPU cache as dirty on every transition for CPU writes

I tried your patch but it didn't fix the original problem. I think it is somehow related to the flushing condition here: @@ -1129,10 +1129,8 @@ i915_gem_execbuffer_move_to_gpu(struct drm_i915_gem_request *req, if (vma->exec_entry->flags & EXEC_OBJECT_ASYNC) continue;

Re: [Intel-gfx] [PATCH 2/2] drm/i915: Reset hangcheck timeouts upon idling

On Wed, Apr 19, 2017 at 05:09:46PM +0300, Mika Kuoppala wrote: > Chris Wilson writes: > > > If we have a long period of idleness, we turn off the hangcheck timer > > and stop polling the hardware. Before we restart the hangcheck, we > > should clear the previous timestamps to prevent us thinking

Re: [Intel-gfx] [PATCH v6 1/3] ACPI / bus: Introduce a list of ids for "always present" devices

On Wed, Apr 19, 2017 at 12:28:50PM +0200, Rafael J. Wysocki wrote: > On Wed, Apr 19, 2017 at 10:59 AM, Hans de Goede wrote: > > On 18-04-17 15:34, Rafael J. Wysocki wrote: > >> On Tue, Apr 18, 2017 at 1:54 PM, Hans de Goede wrote: > >>> > >>> Several Cherry Trail devices (all of which ship with W

Re: [Intel-gfx] [PATCH 04/11] drm: parse ycbcr420 vcb block

Regards Shashank On 4/8/2017 11:13 PM, Emil Velikov wrote: Hi Shashank, On 7 April 2017 at 17:39, Shashank Sharma wrote: + u64 hdmi_420_cap_map = connector->display_info.hdmi.ycbcr420_vcb_map; for (i = 0; i < len; i++) { struct drm_display_mode *mode;

Re: [Intel-gfx] [PATCH 01/11] drm: Add HDMI 2.0 VIC support for AVI info-frames

Regards Shashank On 4/10/2017 3:17 PM, Andrzej Hajda wrote: On 07.04.2017 18:39, Shashank Sharma wrote: HDMI 1.4b support the CEA video modes as per range of CEA-861-D (VIC 1-64). For any other mode, the VIC filed in AVI infoframes should be 0. HDMI 2.0 sinks, support video modes range as per

Re: [Intel-gfx] [PATCH v4 9/9] drm/i915: Convert intel_sdvo connector properties to atomic.

On Wed, Apr 12, 2017 at 12:50:07PM +0200, Maarten Lankhorst wrote: > SDVO was the last connector that's still using the legacy paths > for properties, and this is with a reason! > > This connector implements a lot of properties dynamically, > and some of them shared with the digital connector stat

Re: [Intel-gfx] [PATCH 07/11] drm: set output colorspace in AVI infoframe

Regards Shashank On 4/12/2017 3:19 PM, Jose Abreu wrote: Hi Shashank, On 07-04-2017 17:39, Shashank Sharma wrote: HDMI source must set output colorspace information in AVI infoframes, so that the sink can decode upcoming frames accordingly. As this patch series is adding support for HDMI o

Re: [Intel-gfx] [PATCH v4 6/9] drm/i915: Convert intel_dp properties to atomic.

On Wed, Apr 12, 2017 at 12:50:04PM +0200, Maarten Lankhorst wrote: > intel_dp supports 3 properties, scaling mode, broadcast rgb and > force_audio. intel_digital_connector handles the plumbing, > so we only have to hook this up in compute_config and init. > > Signed-off-by: Maarten Lankhorst > --

Re: [Intel-gfx] [PATCH 06/11] drm: create hdmi output property

Hello Jose, Sorry for delay in response, I was on vacation. Please find my comments inline. Regards Shashank On 4/12/2017 3:28 PM, Jose Abreu wrote: Hi Shashank, On 07-04-2017 17:39, Shashank Sharma wrote: HDMI displays can support various output types, based on the color space and subsampli

Re: [Intel-gfx] [PATCH v4 2/9] drm/i915: Add plumbing for digital connector state, v2.

On Wed, Apr 12, 2017 at 12:50:00PM +0200, Maarten Lankhorst wrote: > Some atomic properties are common between the various kinds of > connectors, for example a lot of them use panel fitting mode. > It makes sense to put a lot of it in a common place, so each > connector can use it while they're bei

Re: [Intel-gfx] [PATCH v4.1 01/9] drm/atomic: Handle aspect ratio and scaling mode in core, v2.

On Thu, Apr 13, 2017 at 11:15:37AM +0200, Maarten Lankhorst wrote: > This is required to for i915 to convert connector properties to atomic. > > Changes since v1: > - Add docbook info. (danvet) > - Change picture_aspect_ratio to enum hdmi_picture_aspect. > > Signed-off-by: Maarten Lankhorst > Cc

Re: [Intel-gfx] [PATCH i-g-t 03/13] lib/igt_aux: Include unistd.h for gettid() on Android

On Wed, 19 Apr 2017, Arkadiusz Hiler wrote: > On Wed, Apr 19, 2017 at 03:22:19PM +0300, Jani Nikula wrote: >> On Wed, 19 Apr 2017, Arkadiusz Hiler wrote: >> > We define gettid() using syscall() because glibc does not provide a >> > wrapper. >> > >> > Android's bionic got the syscall covered thoug

Re: [Intel-gfx] [PATCH 2/2] drm/i915: Reset hangcheck timeouts upon idling

Chris Wilson writes: > If we have a long period of idleness, we turn off the hangcheck timer > and stop polling the hardware. Before we restart the hangcheck, we > should clear the previous timestamps to prevent us thinking that the > engine was stalled for a long time, if the seqno were manipula

Re: [Intel-gfx] [PATCH i-g-t 03/13] lib/igt_aux: Include unistd.h for gettid() on Android

On Wed, Apr 19, 2017 at 03:22:19PM +0300, Jani Nikula wrote: > On Wed, 19 Apr 2017, Arkadiusz Hiler wrote: > > We define gettid() using syscall() because glibc does not provide a > > wrapper. > > > > Android's bionic got the syscall covered though. > > > > Signed-off-by: Arkadiusz Hiler > > --- >

Re: [Intel-gfx] [PATCH v6 05/20] drm/i915/tdr: Add support for per engine reset recovery

On Wed, Apr 19, 2017 at 11:49:26AM +0100, Chris Wilson wrote: > On Tue, Apr 18, 2017 at 01:23:20PM -0700, Michel Thierry wrote: > > + ret = i915_gem_reset_prepare_engine(engine); > > + if (ret) { > > + DRM_ERROR("Previous reset failed - promote to full reset\n"); > > + goto

[Intel-gfx] [PATCH i-g-t v2] lib/igt_aux: Make procps optional

Android does not have procps and it's not easy to compile it as a dependency. We can provide alternative, "naive" implementation that just shells out to external commands (i.e. pkill and lsof) in case we do not have the library. v2: do not ifdef insides of functions (J. Nikula) Cc: Jani Nikula

Re: [Intel-gfx] [PATCH] drm: i915: Avoid format string expansion from engine names

On Tue, 11 Apr 2017, Kees Cook wrote: > While highly unlikely, this makes sure that the string built from > engine names won't be processed as a format string. > > Signed-off-by: Kees Cook Pushed to drm-intel-next-queued, thanks for the patch. BR, Jani. > --- > drivers/gpu/drm/i915/intel_hang

Re: [Intel-gfx] [PATCH igt] tests/gem_spin_batch: Add multiengine test

Chris Wilson writes: > On Thu, Apr 13, 2017 at 01:02:37PM +0300, Mika Kuoppala wrote: >> Parallel spin on all engines. >> >> Signed-off-by: Mika Kuoppala >> --- >> tests/gem_spin_batch.c | 31 +-- >> 1 file changed, 29 insertions(+), 2 deletions(-) >> >> diff --git

Re: [Intel-gfx] [PATCH i-g-t 04/13] lib/igt_aux: Make procps optional

On Wed, 19 Apr 2017, Arkadiusz Hiler wrote: > Android does not have procps and it's not easy to compile it as a > dependency. > > We can provide alternative, "naive" implementation that just shells out > to external commands (i.e. pkill and lsof) in case we do not have the > library. > > Signed-of

Re: [Intel-gfx] [PATCH i-g-t 03/13] lib/igt_aux: Include unistd.h for gettid() on Android

On Wed, 19 Apr 2017, Arkadiusz Hiler wrote: > We define gettid() using syscall() because glibc does not provide a > wrapper. > > Android's bionic got the syscall covered though. > > Signed-off-by: Arkadiusz Hiler > --- > lib/igt_aux.h | 5 + > 1 file changed, 5 insertions(+) > > diff --git a

[Intel-gfx] [PATCH v7 1/2] ACPI / bus: Introduce a list of ids for "always present" devices

Several Bay / Cherry Trail devices (all of which ship with Windows 10) hide the LPSS PWM controller in ACPI, typically the _STA method looks like this: Method (_STA, 0, NotSerialized) // _STA: Status { If (OSID == One) { Return (Zero) } Return

[Intel-gfx] [PATCH v7 2/2] ACPI / bus: Add INT0002 to list of always-present devices

The INT0002 device is necessary to clear wakeup interrupt sources on Cherry Trail devices, without it we get nobody cared IRQ msgs and some systems don't properly resume at all without it. Signed-off-by: Hans de Goede --- Changes in v6: -This is a new patch in v6 of this patch-set Changes in v7:

Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: Fix GCC 4.4 build issue with __intel_wait_for_register_fw (rev2)

On 18/04/2017 12:17, Patchwork wrote: == Series Details == Series: drm/i915: Fix GCC 4.4 build issue with __intel_wait_for_register_fw (rev2) URL : https://patchwork.freedesktop.org/series/23020/ State : failure == Summary == Series 23020v2 drm/i915: Fix GCC 4.4 build issue with __intel_w

Re: [Intel-gfx] [PATCH 27/27] drm/i915/scheduler: Support user-defined priorities

On 19/04/2017 11:09, Chris Wilson wrote: On Wed, Apr 19, 2017 at 10:41:43AM +0100, Chris Wilson wrote: diff --git a/include/uapi/drm/i915_drm.h b/include/uapi/drm/i915_drm.h index f43a22ae955b..200f2cf393b2 100644 --- a/include/uapi/drm/i915_drm.h +++ b/include/uapi/drm/i915_drm.h @@ -395,6 +39

[Intel-gfx] [PATCH i-g-t 09/13] Android.mk: Fix libkmod use

On Android libkmod.h is nested under libkmod directory, so we should include appropriately. Also we need to link with it. Signed-off-by: Arkadiusz Hiler --- benchmarks/Android.mk | 2 ++ lib/Android.mk| 1 + lib/igt_kmod.h| 4 tests/Android.mk | 4 ++-- tools/Android.m

[Intel-gfx] [PATCH i-g-t 05/13] chamelium: Fix build issues on Android

Makefile.sources are included 1:1 in Android.mk files, and are not parsed by automake. And yet those had some automake conditional logic. Moving it to .am file is enough for now. Also igt_chamelium.h included config.h without proper "HAVE_CONFIG_H" guard, and the file itself was included unconditi

[Intel-gfx] [PATCH i-g-t 04/13] lib/igt_aux: Make procps optional

Android does not have procps and it's not easy to compile it as a dependency. We can provide alternative, "naive" implementation that just shells out to external commands (i.e. pkill and lsof) in case we do not have the library. Signed-off-by: Arkadiusz Hiler --- configure.ac | 6 +- lib/

[Intel-gfx] [PATCH i-g-t 07/13] tests/Android.mk: Add perf to skip list

It does not build on Android with top libdrm. Temporary hax. Signed-off-by: Arkadiusz Hiler --- tests/Android.mk | 1 + 1 file changed, 1 insertion(+) diff --git a/tests/Android.mk b/tests/Android.mk index 3186a2a..c67ddbd 100644 --- a/tests/Android.mk +++ b/tests/Android.mk @@ -59,6 +59,7 @@

[Intel-gfx] [PATCH i-g-t 11/13] Android.mk: Use drm stubs

Use drm stubs that sit under lib/stubs. Also drop strange, nonexistent additions to LOCAL_C_INCLUDES. Signed-off-by: Arkadiusz Hiler --- benchmarks/Android.mk | 3 ++- demos/Android.mk | 3 ++- lib/Android.mk| 4 ++-- lib/tests/Android.mk | 4 ++-- tests/Android.mk | 4 ++--

[Intel-gfx] [PATCH i-g-t 12/13] tools/Android.mk: Fix zlib inclusion

Add dependency on libz instead of doing path magic. Signed-off-by: Arkadiusz Hiler --- tools/Android.mk | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/tools/Android.mk b/tools/Android.mk index 5653572..96075c9 100644 --- a/tools/Android.mk +++ b/tools/Android.mk @@ -

[Intel-gfx] [PATCH i-g-t 08/13] benchmarks/Android.mk: Add gem_latency to skip list

AOSP, as of this commit, does not include libdrm with fence defines. Signed-off-by: Arkadiusz Hiler --- benchmarks/Android.mk | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/benchmarks/Android.mk b/benchmarks/Android.mk index c0fa09f..a790ec7 100644 --- a/benchmarks/Androi

[Intel-gfx] [PATCH i-g-t 13/13] tests/gem_exec_nop: Disable headless subtest on cairoless Android

Currently whole igt_kms.c is disabled while compiling on Android without cairo, so this tests does not compile. There should be cleaner a way to disable only cairo dependant parts which should allow us to enable at least some of the KMS tests, but that's a bigger rework for another time. Signed-o

[Intel-gfx] [PATCH i-g-t 10/13] Android.mk: Filter out *.h from src files

Newer Android's build system complains about unused files if we leave those there. Signed-off-by: Arkadiusz Hiler --- lib/Android.mk | 2 +- tools/Android.mk | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/lib/Android.mk b/lib/Android.mk index 0596e4a..003ade5 100644 ---

[Intel-gfx] [PATCH i-g-t 06/13] tools/Android.mk: Add guc_logger and l3_parity skip list

Those tools does not build on Android due to "Linux-only" dependencies. Let's blacklist them for now. Signed-off-by: Arkadiusz Hiler --- tools/Android.mk | 2 ++ 1 file changed, 2 insertions(+) diff --git a/tools/Android.mk b/tools/Android.mk index 6cdedeb..0602e8c 100644 --- a/tools/Android.m

[Intel-gfx] [PATCH i-g-t 03/13] lib/igt_aux: Include unistd.h for gettid() on Android

We define gettid() using syscall() because glibc does not provide a wrapper. Android's bionic got the syscall covered though. Signed-off-by: Arkadiusz Hiler --- lib/igt_aux.h | 5 + 1 file changed, 5 insertions(+) diff --git a/lib/igt_aux.h b/lib/igt_aux.h index e62858e..54b9716 100644 ---

[Intel-gfx] [PATCH i-g-t 02/13] Make conditions on HAVE_UDEV consistent

We have a lot of `#ifdef HAVE_UDEV` and ` #if HAVE_UDEV` all over the place, but ifdef and if have a slightly different semantics. Let make it consistent by using #ifdefs only. Signed-off-by: Arkadiusz Hiler --- lib/igt_aux.c | 2 +- tests/testdisplay_hotplug.c| 2 +- tools

[Intel-gfx] [PATCH i-g-t 01/13] tests/drm_import_export: Include {i915_, }drm.h properly

Using `libdrm/` impairs compatibility with android build system and pkg-config manages -I for us on regular distros. Signed-off-by: Arkadiusz Hiler --- tests/drm_import_export.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/tests/drm_import_export.c b/tests/drm_import_e

[Intel-gfx] [PATCH i-g-t 00/13] Fix IGTs for Android

IGTs are broken for Android since the introduction of dependency on procps. Over time other incompatibilities built up. I took the liberty to fix some of the issues, workaround couple of others and blacklist heavily incompatible tools/tests. It builds on (almost) vanilla AOSP now. Github:

Re: [Intel-gfx] [PATCH v6 05/20] drm/i915/tdr: Add support for per engine reset recovery

On Tue, Apr 18, 2017 at 01:23:20PM -0700, 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 recovery mode if necessary. This is

Re: [Intel-gfx] [PATCH v6 1/3] ACPI / bus: Introduce a list of ids for "always present" devices

On Wed, Apr 19, 2017 at 10:59 AM, Hans de Goede wrote: > Hi, > > > On 18-04-17 15:34, Rafael J. Wysocki wrote: >> >> On Tue, Apr 18, 2017 at 1:54 PM, Hans de Goede >> wrote: >>> >>> Several Cherry Trail devices (all of which ship with Windows 10) hide the >>> LPSS PWM controller in ACPI, typicall

Re: [Intel-gfx] [PATCH v6 14/20] drm/i915/guc: Add support for reset engine using GuC commands

On Tue, Apr 18, 2017 at 01:23:29PM -0700, Michel Thierry wrote: > This patch adds per engine reset and recovery (TDR) support when GuC is > used to submit workloads to GPU. > > In the case of i915 directly submission to ELSP, driver manages hang > detection, recovery and resubmission. With GuC sub

Re: [Intel-gfx] [PATCH v6 16/20] drm/i915: Watchdog timeout: IRQ handler for gen8+

On Tue, Apr 18, 2017 at 01:23:31PM -0700, Michel Thierry wrote: > *** General *** > > Watchdog timeout (or "media engine reset") is a feature that allows > userland applications to enable hang detection on individual batch buffers. > The detection mechanism itself is mostly bound to the hardware a

Re: [Intel-gfx] [PATCH i-g-t] tests/meta_test: Add a meta test for sanity checks of CI systems

> -Original Message- > From: Latvala, Petri > Sent: Wednesday, April 19, 2017 12:08 PM > To: Lofstedt, Marta > Cc: intel-gfx@lists.freedesktop.org > Subject: Re: [PATCH i-g-t] tests/meta_test: Add a meta test for sanity checks > of CI systems > > On Wed, Apr 05, 2017 at 01:11:53PM +0300

Re: [Intel-gfx] [PATCH 27/27] drm/i915/scheduler: Support user-defined priorities

On Wed, Apr 19, 2017 at 10:41:43AM +0100, Chris Wilson wrote: > diff --git a/include/uapi/drm/i915_drm.h b/include/uapi/drm/i915_drm.h > index f43a22ae955b..200f2cf393b2 100644 > --- a/include/uapi/drm/i915_drm.h > +++ b/include/uapi/drm/i915_drm.h > @@ -395,6 +395,8 @@ typedef struct drm_i915_irq_

[Intel-gfx] [PATCH i-g-t v2] tests/meta_test: Add a meta test for sanity checks of CI systems

From: Marta Löfstedt The intention of this test is use it to test that the CI system that runs IGT is collecting the results correctly. For: VIZ-10281 v2: minor edits Signed-off-by: Marta Lofstedt Reviewed-by: Petri Latvala --- tests/Makefile.sources | 1 + tests/intel-ci/meta.testl

Re: [Intel-gfx] [PATCH 16/22] xen-blkfront: Make use of the new sg_map helper function

From: Logan Gunthorpe > Sent: 13 April 2017 23:05 > Straightforward conversion to the new helper, except due to > the lack of error path, we have to warn if unmapable memory > is ever present in the sgl. > > Signed-off-by: Logan Gunthorpe > --- > drivers/block/xen-blkfront.c | 33 +++

Re: [Intel-gfx] [PATCH v4] ACPI / bus: Introduce a list of ids for "always present" devices

Hi, On 18-04-17 10:31, Andy Shevchenko wrote: On Mon, 2017-04-10 at 17:49 +0200, Hans de Goede wrote: Several cherrytrail devices (all of which ship with windows 10) hide the lpss pwm controller in ACPI, typically the _STA method looks like this: CherryTrail PWM LPSS All fixed. Met

[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [01/27] drm/i915/selftests: Allocate inode/file dynamically

== Series Details == Series: series starting with [01/27] drm/i915/selftests: Allocate inode/file dynamically URL : https://patchwork.freedesktop.org/series/23227/ State : failure == Summary == Series 23227v1 Series without cover letter https://patchwork.freedesktop.org/api/1.0/series/23227/r

[Intel-gfx] [PATCH 18/27] drm/i915: Use vma->exec_entry as our double-entry placeholder

This has the benefit of not requiring us to manipulate the vma->exec_link list when tearing down the execbuffer, and is a marginally cheaper test to detect the user error. Signed-off-by: Chris Wilson Reviewed-by: Joonas Lahtinen --- drivers/gpu/drm/i915/i915_gem_evict.c | 17 ++- drive

[Intel-gfx] [PATCH 24/27] drm/i915: Wait upon userptr get-user-pages within execbuffer

This simply hides the EAGAIN caused by userptr when userspace causes resource contention. However, it is quite beneficial with highly contended userptr users as we avoid repeating the setup costs and kernel-user context switches. Signed-off-by: Chris Wilson Reviewed-by: Michał Winiarski --- dri

[Intel-gfx] [PATCH 23/27] drm/i915: First try the previous execbuffer location

When choosing a slot for an execbuffer, we ideally want to use the same address as last time (so that we don't have to rebind it) and the same address as expected by the user (so that we don't have to fixup any relocations pointing to it). If we first try to bind the incoming execbuffer->offset fro

[Intel-gfx] [PATCH 17/27] drm/i915: Amalgamate execbuffer parameter structures

Combine the two slightly overlapping parameter structures we pass around the execbuffer routines into one. Signed-off-by: Chris Wilson Reviewed-by: Joonas Lahtinen --- drivers/gpu/drm/i915/i915_gem_execbuffer.c | 550 - 1 file changed, 233 insertions(+), 317 deletion

[Intel-gfx] [PATCH 19/27] drm/i915: Split vma exec_link/evict_link

Currently the vma has one link member that is used for both holding its place in the execbuf reservation list, and in any eviction list. This dual property is quite tricky and error prone. Signed-off-by: Chris Wilson Reviewed-by: Mika Kuoppala --- drivers/gpu/drm/i915/i915_gem_evict.c | 14

[Intel-gfx] [PATCH 26/27] drm/i915: Async GPU relocation processing

If the user requires patching of their batch or auxiliary buffers, we currently make the alterations on the cpu. If they are active on the GPU at the time, we wait under the struct_mutex for them to finish executing before we rewrite the contents. This happens if shared relocation trees are used be

[Intel-gfx] [PATCH 25/27] drm/i915: Allow execbuffer to use the first object as the batch

Currently, the last object in the execlist is the always the batch. However, when building the batch buffer we often know the batch object first and if we can use the first slot in the execlist we can emit relocation instructions relative to it immediately and avoid a separate pass to adjust the re

[Intel-gfx] [PATCH 27/27] drm/i915/scheduler: Support user-defined priorities

Use a priority stored in the context as the initial value when submitting a request. This allows us to change the default priority on a per-context basis, allowing different contexts to be favoured with GPU time at the expense of lower importance work. The user can adjust the context's priority via

[Intel-gfx] [PATCH 11/27] drm/i915: Switch the global i915.semaphores check to a local predicate

Rather than use a global modparam, we can just check to see if the engine has semaphores configured upon it. Signed-off-by: Chris Wilson Reviewed-by: Joonas Lahtinen --- drivers/gpu/drm/i915/i915_gem_request.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/dr

[Intel-gfx] [PATCH 20/27] drm/i915: Store a direct lookup from object handle to vma

The advent of full-ppgtt lead to an extra indirection between the object and its binding. That extra indirection has a noticeable impact on how fast we can convert from the user handles to our internal vma for execbuffer. In order to bypass the extra indirection, we use a resizable hashtable to jum

[Intel-gfx] [PATCH 21/27] drm/i915: Pass vma to relocate entry

We can simplify our tracking of pending writes in an execbuf to the single bit in the vma->exec_entry->flags, but that requires the relocation function knowing the object's vma. Pass it along. Note we have only been using a single bit to track flushing since commit cc889e0f6ce6a63c62db17d702ecfed

[Intel-gfx] [PATCH 22/27] drm/i915: Eliminate lots of iterations over the execobjects array

The major scaling bottleneck in execbuffer is the processing of the execobjects. Creating an auxiliary list is inefficient when compared to using the execobject array we already have allocated. Reservation is then split into phases. As we lookup up the VMA, we try and bind it back into active loca

[Intel-gfx] [PATCH 13/27] drm/i915/execlists: Pack the count into the low bits of the port.request

add/remove: 1/1 grow/shrink: 5/4 up/down: 391/-578 (-187) function old new delta execlists_submit_ports 262 471+209 port_assign.isra - 136+136 capture 63

[Intel-gfx] [PATCH 16/27] drm/i915: Reinstate reservation_object zapping for batch_pool objects

I removed the zapping of the reservation_object->fence array of shared fences prematurely. We don't yet have the code to zap that array when retiring the object, and so currently it remains possible to continually grow the shared array trapping requests when reusing the batch_pool object across man

[Intel-gfx] [PATCH 15/27] drm/i915: Split execlist priority queue into rbtree + linked list

All the requests at the same priority are executed in FIFO order. They do not need to be stored in the rbtree themselves, as they are a simple list within a level. If we move the requests at one priority into a list, we can then reduce the rbtree to the set of priorities. This should keep the heigh

[Intel-gfx] [PATCH 14/27] drm/i915: Don't mark an execlists context-switch when idle

If we *know* that the engine is idle, i.e. we have not more contexts in lift, we can skip any spurious CSB idle interrupts. These spurious interrupts seem to arrive long after we assert that the engines are completely idle, triggering later assertions: [ 178.896646] intel_engine_is_idle(bcs): int

[Intel-gfx] [PATCH 09/27] drm/i915: Confirm the request is still active before adding it to the await

Although we do check the completion-status of the request before actually adding a wait on it (either to its submit fence or its completion dma-fence), we currently do not check before adding it to the dependency lists. Signed-off-by: Chris Wilson Reviewed-by: Michał Winiarski Reviewed-by: Joona

[Intel-gfx] [PATCH 12/27] drm/i915: Only report a wakeup if the waiter was truly asleep

If we attempt to wake up a waiter, who is currently checking the seqno it will be in the TASK_INTERRUPTIBLE state and ttwu will report success. However, it is actually awake and functioning -- so delay reporting the actual wake up until it sleeps. v2: Defend against !CONFIG_SMP v3: Don't filter ou

[Intel-gfx] [PATCH 10/27] drm/i915: Do not record a successful syncpoint for a dma-await

As we may unwind the requests, even though the request we are awaiting has a global_seqno that seqno may be revoked during the await and so we can not reliably use it as a barrier for all future awaits on the same timeline. Signed-off-by: Chris Wilson Cc: Michał Winiarski Reviewed-by: Michał Win

  1   2   >