Re: [Intel-gfx] [PATCH] drm/i915/execlists: Document runtime pm for intel_lrc_irq_handler()

2017-04-12 Thread Tvrtko Ursulin
On 11/04/2017 18:58, Chris Wilson wrote: We indirectly hold the runtime-pm for the intel_lrc_irq_handler() by virtue of dev_priv->gt.awake keeping a wakeref whilst the requests are busy. As this is not obvious from the code, add a comment. Signed-off-by: Chris Wilson Cc: Tvrtko Ursulin --- d

Re: [Intel-gfx] [PATCH igt] igt/vc4_dmabuf_poll: Add a test for polling to wait for dmabuf fences.

2017-04-12 Thread Daniel Vetter
On Mon, Apr 10, 2017 at 06:24:32PM -0700, Eric Anholt wrote: > This successfully catches vc4's lack of dmabuf fencing. > > Signed-off-by: Eric Anholt > --- > > Has anyone looked into shared infrastructure for tests to do > KMS/dmabuf/etc. things with a generic "get a BO that's being rendered > t

Re: [Intel-gfx] [PATCH 01/13] drm/i915: Remove unused members from intel_tv.c

2017-04-12 Thread Daniel Vetter
On Fri, Apr 07, 2017 at 08:07:50AM +0200, Maarten Lankhorst wrote: > They have been unused since 2010, after the code for > intel_tv_save/restore was removed. For reference, might want to add: commit 6443170f6d862a1cc89e61e4bb2410b714b875f4 Author: Eric Anholt Date: Fri Apr 2 15:24:27 2010 -07

Re: [Intel-gfx] [PATCH 02/13] drm/i915: Convert intel_tv connector properties to atomic, v5.

2017-04-12 Thread Daniel Vetter
On Fri, Apr 07, 2017 at 08:07:51AM +0200, Maarten Lankhorst wrote: > As a proof of concept, first try to convert intel_tv, which is a rarely > used connector. It has 5 properties, tv format and 4 margins. > > I'm less certain about the state behavior itself, should we pass a size > parameter to in

Re: [Intel-gfx] [PATCH 03/13] drm/i915: Convert intel_dp_mst connector properties to atomic.

2017-04-12 Thread Daniel Vetter
On Fri, Apr 07, 2017 at 08:07:52AM +0200, Maarten Lankhorst wrote: > MST doesn't support setting any properties, but it should still > use the atomic helper for setting properties. > > Only path and tile properties are supported (read-only). > Those are immutable, and handled by drm core. > > Sig

Re: [Intel-gfx] [PATCH 02/13] drm/i915: Convert intel_tv connector properties to atomic, v5.

2017-04-12 Thread Maarten Lankhorst
Op 12-04-17 om 09:38 schreef Daniel Vetter: > On Fri, Apr 07, 2017 at 08:07:51AM +0200, Maarten Lankhorst wrote: >> As a proof of concept, first try to convert intel_tv, which is a rarely >> used connector. It has 5 properties, tv format and 4 margins. >> >> I'm less certain about the state behavio

Re: [Intel-gfx] [PATCH 04/13] drm/i915: Convert intel_crt connector properties to atomic.

2017-04-12 Thread Daniel Vetter
On Fri, Apr 07, 2017 at 08:07:53AM +0200, Maarten Lankhorst wrote: > No properties are supported, so just use the helper and reject > everything. > > Signed-off-by: Maarten Lankhorst Reviewed-by: Daniel Vetter > --- > drivers/gpu/drm/i915/intel_crt.c | 10 +- > 1 file changed, 1 inser

Re: [Intel-gfx] [PATCH] drm/i915: Fix use after free in lpe_audio_platdev_destroy()

2017-04-12 Thread Ville Syrjälä
On Wed, Apr 12, 2017 at 06:59:55AM +0200, Takashi Iwai wrote: > On Tue, 11 Apr 2017 23:27:07 +0200, > Chris Wilson wrote: > > > > On Tue, Apr 11, 2017 at 10:20:56PM +0100, Chris Wilson wrote: > > > On Tue, Apr 11, 2017 at 11:01:57PM +0200, Takashi Iwai wrote: > > > > On Tue, 11 Apr 2017 22:41:12 +

Re: [Intel-gfx] [PATCH v3 2.5/13] drm/i915: Remove unused dp properties for dp-mst.

2017-04-12 Thread Daniel Vetter
On Mon, Apr 10, 2017 at 12:51:10PM +0200, Maarten Lankhorst wrote: > Those properties are not hooked up on MST and were ignored. Best not expose > them at all. > Without this the next patch fails to start on X.org, because the DP-MST > properties could > not be read. > > Signed-off-by: Maarten L

Re: [Intel-gfx] [PATCH v3 04/13] drm/i915: Convert intel_crt connector properties to atomic.

2017-04-12 Thread Daniel Vetter
On Mon, Apr 10, 2017 at 11:07:10AM +0200, Maarten Lankhorst wrote: > No properties are supported, so just use the helper and reject > everything. > > Signed-off-by: Maarten Lankhorst Reviewed-by: Daniel Vetter > --- > drivers/gpu/drm/i915/intel_crt.c | 10 +- > 1 file changed, 1 inser

Re: [Intel-gfx] [PATCH v3 05/13] drm/i915: Convert intel DVO connector to atomic

2017-04-12 Thread Daniel Vetter
On Mon, Apr 10, 2017 at 11:07:11AM +0200, Maarten Lankhorst wrote: > No properties are supported, so just use the helper and reject everything. > > Signed-off-by: Maarten Lankhorst Reviewed-by: Daniel Vetter > --- > drivers/gpu/drm/i915/intel_dvo.c | 2 +- > 1 file changed, 1 insertion(+), 1 d

Re: [Intel-gfx] [PATCH v3 06/13] drm/i915: Add plumbing for digital connector state.

2017-04-12 Thread Daniel Vetter
On Mon, Apr 10, 2017 at 11:07:12AM +0200, Maarten Lankhorst wrote: > +int intel_digital_connector_atomic_get_property(struct drm_connector > *connector, > + const struct > drm_connector_state *state, > + struc

[Intel-gfx] [PATCH v2] drm/i915: Fix use after free in lpe_audio_platdev_destroy()

2017-04-12 Thread Chris Wilson
[31908.547136] BUG: KASAN: use-after-free in intel_lpe_audio_teardown+0x78/0xb0 [i915] at addr 8801f7788358 [31908.547297] Read of size 8 by task drv_selftest/3781 [31908.547405] CPU: 0 PID: 3781 Comm: drv_selftest Tainted: GBU W 4.10.0+ #451 [31908.547553] Hardware name:

Re: [Intel-gfx] [PATCH] drm: Only take cursor locks when the cursor plane exists

2017-04-12 Thread Tony Lindgren
* Daniel Vetter [170407 09:50]: > I thought I've fixed this, but maybe not. Anyway, clearly broken, and > easy fix. > > Cc: Tony Lindgren > Reported-by: Tony Lindgren > Fixes: b95ff0319a82 ("drm: Remove drm_modeset_(un)lock_crtc") > Cc: Harry Wentland > Cc: Maarten Lankhorst > Cc: Daniel Vett

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Fix use after free in lpe_audio_platdev_destroy() (rev2)

2017-04-12 Thread Patchwork
== Series Details == Series: drm/i915: Fix use after free in lpe_audio_platdev_destroy() (rev2) URL : https://patchwork.freedesktop.org/series/20476/ State : success == Summary == Series 20476v2 drm/i915: Fix use after free in lpe_audio_platdev_destroy() https://patchwork.freedesktop.org/api/1

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

2017-04-12 Thread Chris Wilson
On Mon, Apr 10, 2017 at 02:40:24AM +, Dong, Chuanxiao wrote: > > -Original Message- > > From: intel-gvt-dev [mailto:intel-gvt-dev-boun...@lists.freedesktop.org] On > > Behalf Of Dong, Chuanxiao > > Sent: Thursday, April 6, 2017 11:19 PM > > To: Chris Wilson > > Cc: Tian, Kevin ; intel-

Re: [Intel-gfx] [PATCH] drm/i915: Fix use after free in lpe_audio_platdev_destroy()

2017-04-12 Thread Chris Wilson
On Wed, Apr 12, 2017 at 10:46:30AM +0300, Ville Syrjälä wrote: > On Wed, Apr 12, 2017 at 06:59:55AM +0200, Takashi Iwai wrote: > > On Tue, 11 Apr 2017 23:27:07 +0200, > > Chris Wilson wrote: > > > > > > On Tue, Apr 11, 2017 at 10:20:56PM +0100, Chris Wilson wrote: > > > > On Tue, Apr 11, 2017 at 1

Re: [Intel-gfx] [PATCH] drm/i915/execlists: Document runtime pm for intel_lrc_irq_handler()

2017-04-12 Thread Chris Wilson
On Wed, Apr 12, 2017 at 08:12:17AM +0100, Tvrtko Ursulin wrote: > > On 11/04/2017 18:58, Chris Wilson wrote: > >We indirectly hold the runtime-pm for the intel_lrc_irq_handler() by > >virtue of dev_priv->gt.awake keeping a wakeref whilst the requests are > >busy. As this is not obvious from the co

[Intel-gfx] [PATCH v3] drm/i915: Fix use after free in lpe_audio_platdev_destroy()

2017-04-12 Thread Chris Wilson
[31908.547136] BUG: KASAN: use-after-free in intel_lpe_audio_teardown+0x78/0xb0 [i915] at addr 8801f7788358 [31908.547297] Read of size 8 by task drv_selftest/3781 [31908.547405] CPU: 0 PID: 3781 Comm: drv_selftest Tainted: GBU W 4.10.0+ #451 [31908.547553] Hardware name:

Re: [Intel-gfx] [PATCH 1/2] drm/i915: Combine write_domain flushes to a single function

2017-04-12 Thread Joonas Lahtinen
On ti, 2017-04-11 at 14:47 +0100, Chris Wilson wrote: > In the next patch, we will introduce a new cache domain for > differentiating between GTT access and direct WC access. This will > require us to include WC in our write_domain flushes. Rather than > duplicate a third function, combine the exis

[Intel-gfx] [PATCH] drm/i915/gvt: return the actual aperture size under gvt environment

2017-04-12 Thread Weinan Li
I915_GEM_GET_APERTURE ioctl is used to probe aperture size from userspace. Some applications like OpenCL use this information to know how much GM resource can it use. In gvt environment, each vm only use the ballooned part of aperture, so we should return the actual aperture size exclude the reserv

Re: [Intel-gfx] [PATCH 1/3] drm/i915: Add stub mmio read/write routines to mock device

2017-04-12 Thread Joonas Lahtinen
On ke, 2017-04-12 at 00:44 +0100, Chris Wilson wrote: > Provide dummy function pointers for the mock device in case we do hit > mmio during testing. > > Signed-off-by: Chris Wilson Reviewed-by: Joonas Lahtinen Regards, Joonas -- Joonas Lahtinen Open Source Technology Center Intel Corporation

Re: [Intel-gfx] [PATCH 2/3] drm/i915: Pretend the engine is always idle when mocking

2017-04-12 Thread Joonas Lahtinen
On ke, 2017-04-12 at 00:44 +0100, Chris Wilson wrote: > If we have a mock engine and it has no more requests in flight, report > it as idle as there is no hardware to contradict us! Otherwise we > attempt to query the hw that doesn't exist and find that the hw hasn't > set its idle bit and we get u

Re: [Intel-gfx] [PATCH 3/3] drm/i915: Wake device for emitting request during selftest

2017-04-12 Thread Joonas Lahtinen
On ke, 2017-04-12 at 00:44 +0100, Chris Wilson wrote: > igt_mmap_offset_exhaustion() selftest was using live requests to make an > object busy, but we did not hold a runtime pm wakeref for submitting the > requests. Acquire it to avoid triggering "RPM wakelock ref not held > during HW access" warni

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Fix use after free in lpe_audio_platdev_destroy() (rev4)

2017-04-12 Thread Patchwork
== Series Details == Series: drm/i915: Fix use after free in lpe_audio_platdev_destroy() (rev4) URL : https://patchwork.freedesktop.org/series/20476/ State : success == Summary == Series 20476v4 drm/i915: Fix use after free in lpe_audio_platdev_destroy() https://patchwork.freedesktop.org/api/1

Re: [Intel-gfx] [PATCH v3] drm/i915: Fix use after free in lpe_audio_platdev_destroy()

2017-04-12 Thread Ville Syrjälä
On Wed, Apr 12, 2017 at 09:31:39AM +0100, Chris Wilson wrote: > [31908.547136] BUG: KASAN: use-after-free in > intel_lpe_audio_teardown+0x78/0xb0 [i915] at addr 8801f7788358 > [31908.547297] Read of size 8 by task drv_selftest/3781 > [31908.547405] CPU: 0 PID: 3781 Comm: drv_selftest Tainted:

Re: [Intel-gfx] [PATCH] Revert "drm/i915: Lock mode_config.mutex in intel_display_resume."

2017-04-12 Thread Daniel Vetter
On Tue, Apr 04, 2017 at 03:22:48PM +0200, Maarten Lankhorst wrote: > This reverts commit ea49c9acf2db7082f0406bb3a570cc6bad37082b. > > mode_config.mutex was originally added to fix WARNs in connector > functions, but now that atomic nonblocking modeset support is > included, we will likely never h

Re: [Intel-gfx] [PATCH] drm/i915/gvt: return the actual aperture size under gvt environment

2017-04-12 Thread Chris Wilson
On Wed, Apr 12, 2017 at 04:36:57PM +0800, Weinan Li wrote: > I915_GEM_GET_APERTURE ioctl is used to probe aperture size from userspace. > Some applications like OpenCL use this information to know how much GM > resource can it use. That's a userspace bug. > In gvt environment, each vm only use th

Re: [Intel-gfx] [PATCH] drm/i915: Do not use lock all in hsw_trans_edp_pipe_A_crc_wa

2017-04-12 Thread Daniel Vetter
On Tue, Apr 04, 2017 at 03:24:57PM +0200, Maarten Lankhorst wrote: > There is no need to acquire all locks here, > doing a commit after forcing a modeset on the affected crtc > is enough. Any other locks needed will be acquired as needed. > > Signed-off-by: Maarten Lankhorst > --- > drivers/gpu/

Re: [Intel-gfx] [PATCH v3] drm/i915: Fix use after free in lpe_audio_platdev_destroy()

2017-04-12 Thread Chris Wilson
On Wed, Apr 12, 2017 at 11:52:54AM +0300, Ville Syrjälä wrote: > On Wed, Apr 12, 2017 at 09:31:39AM +0100, Chris Wilson wrote: > > drivers/gpu/drm/i915/intel_lpe_audio.c | 4 ++-- > > 1 file changed, 2 insertions(+), 2 deletions(-) > > > > diff --git a/drivers/gpu/drm/i915/intel_lpe_audio.c > >

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

2017-04-12 Thread Dong, Chuanxiao
> -Original Message- > From: intel-gvt-dev [mailto:intel-gvt-dev-boun...@lists.freedesktop.org] On > Behalf Of Chris Wilson > Sent: Wednesday, April 12, 2017 4:22 PM > To: Dong, Chuanxiao > Cc: Tian, Kevin ; intel-gvt-...@lists.freedesktop.org; > intel-gfx@lists.freedesktop.org; joonas.l

Re: [Intel-gfx] [PATCH 5/8] drm/i915/skl+: ddb min requirement may exceed allocation

2017-04-12 Thread Ander Conselvan De Oliveira
On Tue, 2017-02-28 at 17:01 +0530, Mahesh Kumar wrote: > DDB minimum requirement may also exceed the allocated DDB for CRTC. > Instead of directly deducting from alloc_size, check against > total_min_ddb requirement. if exceeding fail the flip. Instead of doing a low level description of the code

[Intel-gfx] [PATCH v2] drm/i915: Add stub mmio read/write routines to mock device

2017-04-12 Thread Chris Wilson
Provide dummy function pointers for the mock device in case we do hit mmio during testing. v2: Use ASSIGN_READ/WRITE_MMIO_FUNCS macros Signed-off-by: Chris Wilson Reviewed-by: Joonas Lahtinen #v1 --- drivers/gpu/drm/i915/intel_uncore.c | 47 drivers/gpu/dr

Re: [Intel-gfx] [PATCH] drm: Document code of conduct

2017-04-12 Thread Michel Dänzer
On 11/04/17 03:48 PM, Daniel Vetter wrote: > freedesktop.org has adopted a formal&enforced code of conduct: > > https://www.fooishbar.org/blog/fdo-contributor-covenant/ > https://www.freedesktop.org/wiki/CodeOfConduct/ > > Besides formalizing things a bit more I don't think this changes > anythin

Re: [Intel-gfx] [PATCH] drm: Document code of conduct

2017-04-12 Thread Laurent Pinchart
Hi Daniel, On Tuesday 11 Apr 2017 11:03:33 Daniel Vetter wrote: > On Tue, Apr 11, 2017 at 08:48:15AM +0200, Daniel Vetter wrote: > > freedesktop.org has adopted a formal&enforced code of conduct: > > > > https://www.fooishbar.org/blog/fdo-contributor-covenant/ > > https://www.freedesktop.org/wiki

Re: [Intel-gfx] [PATCH v2] drm/i915: Add stub mmio read/write routines to mock device

2017-04-12 Thread Michal Wajdeczko
On Wed, Apr 12, 2017 at 10:21:43AM +0100, Chris Wilson wrote: > Provide dummy function pointers for the mock device in case we do hit > mmio during testing. > > v2: Use ASSIGN_READ/WRITE_MMIO_FUNCS macros > > Signed-off-by: Chris Wilson > Reviewed-by: Joonas Lahtinen #v1 > --- > drivers/gpu/dr

[Intel-gfx] [PATCH v2] drm/i915: Combine write_domain flushes to a single function

2017-04-12 Thread Chris Wilson
In the next patch, we will introduce a new cache domain for differentiating between GTT access and direct WC access. This will require us to include WC in our write_domain flushes. Rather than duplicate a third function, combine the existing two into one and flushing WC writes will then be automati

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

2017-04-12 Thread Jose Abreu
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 output modes > other than RGB, this patch adds a functi

Re: [Intel-gfx] [PATCH v2] drm/i915: Combine write_domain flushes to a single function

2017-04-12 Thread Joonas Lahtinen
On ke, 2017-04-12 at 10:42 +0100, Chris Wilson wrote: > In the next patch, we will introduce a new cache domain for > differentiating between GTT access and direct WC access. This will > require us to include WC in our write_domain flushes. Rather than > duplicate a third function, combine the exis

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

2017-04-12 Thread Jose Abreu
Hi Shashank, On 07-04-2017 17:39, Shashank Sharma wrote: > HDMI displays can support various output types, based on > the color space and subsampling type. The possible > outputs from a HDMI 2.0 monitor could be: > - RGB > - YCBCR 444 > - YCBCR 422 > - YCBCR 420 > > This patch adds a drm prop

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/gvt: return the actual aperture size under gvt environment

2017-04-12 Thread Patchwork
== Series Details == Series: drm/i915/gvt: return the actual aperture size under gvt environment URL : https://patchwork.freedesktop.org/series/22910/ State : failure == Summary == Series 22910v1 drm/i915/gvt: return the actual aperture size under gvt environment https://patchwork.freedesktop

Re: [Intel-gfx] [PATCH] drm/i915/gvt: return the actual aperture size under gvt environment

2017-04-12 Thread Joonas Lahtinen
On ke, 2017-04-12 at 09:53 +0100, Chris Wilson wrote: > On Wed, Apr 12, 2017 at 04:36:57PM +0800, Weinan Li wrote: > > > > I915_GEM_GET_APERTURE ioctl is used to probe aperture size from userspace. > > Some applications like OpenCL use this information to know how much GM > > resource can it use.

Re: [Intel-gfx] [PATCH] drm/i915/execlists: Document runtime pm for intel_lrc_irq_handler()

2017-04-12 Thread Tvrtko Ursulin
On 12/04/2017 09:31, Chris Wilson wrote: On Wed, Apr 12, 2017 at 08:12:17AM +0100, Tvrtko Ursulin wrote: On 11/04/2017 18:58, Chris Wilson wrote: We indirectly hold the runtime-pm for the intel_lrc_irq_handler() by virtue of dev_priv->gt.awake keeping a wakeref whilst the requests are busy. A

Re: [Intel-gfx] [PATCH v2] drm/i915: Combine write_domain flushes to a single function

2017-04-12 Thread Chris Wilson
On Wed, Apr 12, 2017 at 01:06:04PM +0300, Joonas Lahtinen wrote: > On ke, 2017-04-12 at 10:42 +0100, Chris Wilson wrote: > > In the next patch, we will introduce a new cache domain for > > differentiating between GTT access and direct WC access. This will > > require us to include WC in our write_d

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [v2] drm/i915: Add stub mmio read/write routines to mock device (rev2)

2017-04-12 Thread Patchwork
== Series Details == Series: series starting with [v2] drm/i915: Add stub mmio read/write routines to mock device (rev2) URL : https://patchwork.freedesktop.org/series/22891/ State : success == Summary == Series 22891v2 Series without cover letter https://patchwork.freedesktop.org/api/1.0/ser

[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [v2] drm/i915: Combine write_domain flushes to a single function (rev2)

2017-04-12 Thread Patchwork
== Series Details == Series: series starting with [v2] drm/i915: Combine write_domain flushes to a single function (rev2) URL : https://patchwork.freedesktop.org/series/22855/ State : failure == Summary == LD [M] drivers/net/ethernet/intel/igbvf/igbvf.o CC [M] drivers/gpu/drm/i915/intel

[Intel-gfx] [RFC] drm/i915: Simplify waiting for registers

2017-04-12 Thread Tvrtko Ursulin
From: Tvrtko Ursulin I was thinking if we could get away with simplifying the API a bit by getting rid of the _fw variant and only have these three functions with a common implementation: intel_wait_for_register intel_wait_for_register_atomic __intel_wait_for_register The fast/busy loop i

Re: [Intel-gfx] [RFC] drm/i915: Simplify waiting for registers

2017-04-12 Thread Tvrtko Ursulin
On 12/04/2017 11:36, Tvrtko Ursulin wrote: From: Tvrtko Ursulin I was thinking if we could get away with simplifying the API a bit by getting rid of the _fw variant and only have these three functions with a common implementation: intel_wait_for_register intel_wait_for_register_atomic _

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

2017-04-12 Thread Maarten Lankhorst
Signed-off-by: Maarten Lankhorst --- drivers/gpu/drm/i915/intel_dsi.c | 57 +++- 1 file changed, 9 insertions(+), 48 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_dsi.c b/drivers/gpu/drm/i915/intel_dsi.c index e787142025ac..1d8621538563 100644 --- a/dri

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

2017-04-12 Thread Maarten Lankhorst
First part has been reviewed and upstreamed, second part resubmitted here with fix to core to handle aspect ratio and scaling mode. :) Only 'add plumbing for digital connector state' had significant changes, rest was just fixed to use the new place for aspect ratio and scaling mode. Maarten Lankh

[Intel-gfx] [PATCH v4 8/9] drm/i915: Handle force_audio correctly in intel_sdvo

2017-04-12 Thread Maarten Lankhorst
Do the same as other connectors, attempt to detect hdmi audio in the detect() callback, and only use the force_audio property as override. Compute has_audio in pipe_config, and use that value instead of the probed value directly. Signed-off-by: Maarten Lankhorst --- drivers/gpu/drm/i915/intel_sd

[Intel-gfx] [PATCH v4 5/9] drm/i915: Make intel_dp->has_audio reflect hw state only

2017-04-12 Thread Maarten Lankhorst
Always detect if audio is available during edid detection. With less magic switching it's easier to convert the dp connector properties to atomic. Signed-off-by: Maarten Lankhorst --- drivers/gpu/drm/i915/intel_dp.c | 38 -- 1 file changed, 16 insertions(+), 2

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

2017-04-12 Thread Maarten Lankhorst
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 state, so sdvo_connector_state subclasses intel_digital_connector_state. set_pro

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

2017-04-12 Thread Maarten Lankhorst
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 being converted. Implement the properties required for the connectors: - scal

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

2017-04-12 Thread Maarten Lankhorst
Signed-off-by: Maarten Lankhorst --- drivers/gpu/drm/i915/intel_lvds.c | 56 +++ 1 file changed, 15 insertions(+), 41 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_lvds.c b/drivers/gpu/drm/i915/intel_lvds.c index 919d84290774..39d983d9b702 100644 --- a

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

2017-04-12 Thread Maarten Lankhorst
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 --- drivers/gpu/drm/i915/intel_dp.c | 136 +++--

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

2017-04-12 Thread Maarten Lankhorst
This is required to for i915 to convert connector properties to atomic. Signed-off-by: Maarten Lankhorst Cc: dri-de...@lists.freedesktop.org --- drivers/gpu/drm/drm_atomic.c | 8 include/drm/drm_connector.h | 3 +++ 2 files changed, 11 insertions(+) diff --git a/drivers/gpu/drm/drm_at

[Intel-gfx] [PATCH v4 7/9] drm/i915: Convert intel_hdmi connector properties to atomic

2017-04-12 Thread Maarten Lankhorst
intel_hdmi supports 3 properties, force_audio, broadcast rgb and scaling mode. The last one is only created for eDP, so the is_eDP in set_property is not required. panel fitting and broadcast rgb are straightforward and only requires changing compute_config. force_audio is also used to force DVI

Re: [Intel-gfx] [RFC] drm/i915: Simplify waiting for registers

2017-04-12 Thread Chris Wilson
On Wed, Apr 12, 2017 at 11:42:55AM +0100, Tvrtko Ursulin wrote: > > On 12/04/2017 11:36, Tvrtko Ursulin wrote: > >From: Tvrtko Ursulin > > > >I was thinking if we could get away with simplifying the API > >a bit by getting rid of the _fw variant and only have these > >three functions with a commo

[Intel-gfx] ✗ Fi.CI.BAT: warning for drm/i915: Simplify waiting for registers

2017-04-12 Thread Patchwork
== Series Details == Series: drm/i915: Simplify waiting for registers URL : https://patchwork.freedesktop.org/series/22915/ State : warning == Summary == Series 22915v1 drm/i915: Simplify waiting for registers https://patchwork.freedesktop.org/api/1.0/series/22915/revisions/1/mbox/ Test gem_e

[Intel-gfx] [CI 2/2] drm/i915: Treat WC a separate cache domain

2017-04-12 Thread Chris Wilson
When discussing a new WC mmap, we based the interface upon the assumption that GTT was fully coherent. How naive! Commits 3b5724d702ef ("drm/i915: Wait for writes through the GTT to land before reading back") and ed4596ea992d ("drm/i915/guc: WA to address the Ringbuffer coherency issue") demonstrat

[Intel-gfx] [CI 1/2] drm/i915: Combine write_domain flushes to a single function

2017-04-12 Thread Chris Wilson
In the next patch, we will introduce a new cache domain for differentiating between GTT access and direct WC access. This will require us to include WC in our write_domain flushes. Rather than duplicate a third function, combine the existing two into one and flushing WC writes will then be automati

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Convert connector properties to atomic. (rev4)

2017-04-12 Thread Patchwork
== Series Details == Series: drm/i915: Convert connector properties to atomic. (rev4) URL : https://patchwork.freedesktop.org/series/22634/ State : success == Summary == Series 22634v4 drm/i915: Convert connector properties to atomic. https://patchwork.freedesktop.org/api/1.0/series/22634/revi

Re: [Intel-gfx] [RFC] drm/i915: Introduce GEM_MAYBE_BUILD_BUG_ON

2017-04-12 Thread Tvrtko Ursulin
On 11/04/2017 14:57, Michal Wajdeczko wrote: > This is slightly weaker version of MAYBE_BUILD_BUG_ON that allows > us to avoid adding implicit BUG but still detect as much as possible > during the build. With this new macro we can fix the problem with > GCC 4.4.7 that wrongly triggers build break

Re: [Intel-gfx] [RFC] drm/i915: Introduce GEM_MAYBE_BUILD_BUG_ON

2017-04-12 Thread Chris Wilson
On Wed, Apr 12, 2017 at 12:13:51PM +0100, Tvrtko Ursulin wrote: > > On 11/04/2017 14:57, Michal Wajdeczko wrote: > > This is slightly weaker version of MAYBE_BUILD_BUG_ON that allows > > us to avoid adding implicit BUG but still detect as much as possible > > during the build. With this new macro

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [CI,1/2] drm/i915: Combine write_domain flushes to a single function

2017-04-12 Thread Patchwork
== Series Details == Series: series starting with [CI,1/2] drm/i915: Combine write_domain flushes to a single function URL : https://patchwork.freedesktop.org/series/22921/ State : success == Summary == Series 22921v1 Series without cover letter https://patchwork.freedesktop.org/api/1.0/serie

Re: [Intel-gfx] [PATCH v3 4/7] drm/i915/perf: Add OA unit support for Gen 8+

2017-04-12 Thread Matthew Auld
On 04/05, Robert Bragg wrote: > Enables access to OA unit metrics for BDW, CHV, SKL and BXT which all > share (more-or-less) the same OA unit design. > > Of particular note in comparison to Haswell: some OA unit HW config > state has become per-context state and as a consequence it is somewhat > m

Re: [Intel-gfx] [PATCH v3 7/7] drm/i915/perf: remove perf.hook_lock

2017-04-12 Thread Matthew Auld
On 04/05, Robert Bragg wrote: > In earlier iterations of the i915-perf driver we had a number of > callbacks/hooks from other parts of the i915 driver to e.g. notify us > when a legacy context was pinned and these could run asynchronously with > respect to the stream file operations and might also

Re: [Intel-gfx] [PATCH] drm/i915: Implement dma_buf_ops->kmap

2017-04-12 Thread Joonas Lahtinen
On pe, 2017-04-07 at 22:36 +0100, Chris Wilson wrote: > Since kmap allows us to block we can pin the pages and use our normal > page lookup routine making the implementation simple. > > Testcase: igt/drv_selftest/dmabuf > Testcase: igt/prime_rw > Signed-off-by: Chris Wilson > +static int igt_d

Re: [Intel-gfx] [PATCH v3] drm/i915: Fix use after free in lpe_audio_platdev_destroy()

2017-04-12 Thread Takashi Iwai
On Wed, 12 Apr 2017 10:52:54 +0200, Ville Syrjälä wrote: > > On Wed, Apr 12, 2017 at 09:31:39AM +0100, Chris Wilson wrote: > > [31908.547136] BUG: KASAN: use-after-free in > > intel_lpe_audio_teardown+0x78/0xb0 [i915] at addr 8801f7788358 > > [31908.547297] Read of size 8 by task drv_selftest

Re: [Intel-gfx] [PATCH v2] drm/i915: Fix use after free in lpe_audio_platdev_destroy()

2017-04-12 Thread Takashi Iwai
On Wed, 12 Apr 2017 10:02:51 +0200, Chris Wilson wrote: > > [31908.547136] BUG: KASAN: use-after-free in > intel_lpe_audio_teardown+0x78/0xb0 [i915] at addr 8801f7788358 > [31908.547297] Read of size 8 by task drv_selftest/3781 > [31908.547405] CPU: 0 PID: 3781 Comm: drv_selftest Tainted: G

Re: [Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [CI,1/2] drm/i915: Combine write_domain flushes to a single function

2017-04-12 Thread Chris Wilson
On Wed, Apr 12, 2017 at 11:29:21AM -, Patchwork wrote: > == Series Details == > > Series: series starting with [CI,1/2] drm/i915: Combine write_domain flushes > to a single function > URL : https://patchwork.freedesktop.org/series/22921/ > State : success > > == Summary == > > Series 2292

[Intel-gfx] freedesktop bug id: 100548, bisected to sched/clock commit

2017-04-12 Thread Lofstedt, Marta
Hi, We have this "old" Lenovo Cantiga laptop(Intel Core 2 Duo L9400), hocked up to our i915 pre-merge CI system, that has started to give unstable results after commit: commit 7b09cc5a9debc86c903c2eff8f8a1fdef773c649 Author: Pavel Tatashin Date: Wed Mar 22 16:24:17 2017 -0400 sched/cloc

[Intel-gfx] [PATCH V5] drm/i915: Disable stolen memory when i915 runs on qemu

2017-04-12 Thread Xiong Zhang
Stolen memory isn't a standard pci resource and exists in RMRR which has identity mapping in iommu table, IGD could access stolen memory in host OS. While according to 'commit c875d2c1b808 ("iommu/vt-d: Exclude devices using RMRRs from IOMMU API domains")',RMRR isn't supported by kvm, then both EPT

Re: [Intel-gfx] [PATCH v2] drm/i915: Add stub mmio read/write routines to mock device

2017-04-12 Thread Joonas Lahtinen
On ke, 2017-04-12 at 10:21 +0100, Chris Wilson wrote: > Provide dummy function pointers for the mock device in case we do hit > mmio during testing. > > v2: Use ASSIGN_READ/WRITE_MMIO_FUNCS macros > > Signed-off-by: Chris Wilson > Reviewed-by: Joonas Lahtinen #v1 Reviewed-by: Joonas Lahtinen

Re: [Intel-gfx] freedesktop bug id: 100548, bisected to sched/clock commit

2017-04-12 Thread Peter Zijlstra
On Wed, Apr 12, 2017 at 12:04:00PM +, Lofstedt, Marta wrote: > Hi, > > We have this "old" Lenovo Cantiga laptop(Intel Core 2 Duo L9400), hocked up > to our i915 pre-merge CI system, that has started to give unstable results > after commit: > > commit 7b09cc5a9debc86c903c2eff8f8a1fdef773c649

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Enhanced disable access to stolen memory as a guest (rev5)

2017-04-12 Thread Patchwork
== Series Details == Series: drm/i915: Enhanced disable access to stolen memory as a guest (rev5) URL : https://patchwork.freedesktop.org/series/21818/ State : success == Summary == Series 21818v5 drm/i915: Enhanced disable access to stolen memory as a guest https://patchwork.freedesktop.org/a

Re: [Intel-gfx] [PATCH] drm/i915: Prevent the system suspend complete optimization

2017-04-12 Thread Chris Wilson
On Tue, Apr 11, 2017 at 08:09:17PM +0300, Imre Deak wrote: > On Tue, Apr 11, 2017 at 05:54:07PM +0100, Chris Wilson wrote: > > On Tue, Apr 11, 2017 at 07:12:35PM +0300, Imre Deak wrote: > > > +static int i915_pm_prepare(struct device *kdev) > > > +{ > > > + /* > > > + * Get a reference to disable

Re: [Intel-gfx] [PATCH v2] drm/i915/perf: per-gen timebase for checking sample freq

2017-04-12 Thread Matthew Auld
On 5 April 2017 at 20:05, Robert Bragg wrote: > An oa_exponent_to_ns() utility and per-gen timebase constants where were > recently removed when updating the tail pointer race condition WA, and > this restores those so we can update the _PROP_OA_EXPONENT validation > done in read_properties_unloc

Re: [Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [v2] drm/i915: Add stub mmio read/write routines to mock device (rev2)

2017-04-12 Thread Chris Wilson
On Wed, Apr 12, 2017 at 10:30:10AM -, Patchwork wrote: > == Series Details == > > Series: series starting with [v2] drm/i915: Add stub mmio read/write routines > to mock device (rev2) > URL : https://patchwork.freedesktop.org/series/22891/ > State : success > > == Summary == > > Series 22

[Intel-gfx] [PATCH v2 3/9] drm/i915: Make ptr_unpack_bits() more function-like

2017-04-12 Thread Chris Wilson
ptr_unpack_bits() is a function-like macro, as such it is meant to be replaceable by a function. In this case, we should be passing in the out-param as a pointer. Bizarrely this does affect code generation: function old new delta i915_gem_object_pin_map

[Intel-gfx] [PATCH v2 6/9] drm/i915: Rename intel_timeline.sync_seqno[] to .global_sync[]

2017-04-12 Thread Chris Wilson
With the addition of the inter-context intel_time.sync map, having a very similar sync_seqno[] is confusing. Aide the reader by denoting that this a pre-allocated array for storing semaphore sync points wrt to the global seqno. Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/i915_gem_reques

[Intel-gfx] [PATCH v2 1/9] drm/i915: Mark up clflushes as belonging to an unordered timeline

2017-04-12 Thread Chris Wilson
2 clflushes on two different objects are not ordered, and so do not belong to the same timeline (context). Either we use a unique context for each, or we reserve a special global context to mean unordered. Ideally, we would reserve 0 to mean unordered (DMA_FENCE_NO_CONTEXT) to have the same semanti

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

2017-04-12 Thread Chris Wilson
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 --- drivers/gpu/drm/i915/i915_gem_request.c | 3

[Intel-gfx] [PATCH v2 8/9] drm/i915: Do not record a successful syncpoint for a dma-await

2017-04-12 Thread Chris Wilson
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 --- drivers/gpu/drm/i9

[Intel-gfx] [PATCH v2 2/9] drm/i915: Lift timeline ordering to await_dma_fence

2017-04-12 Thread Chris Wilson
Currently we filter out repeated use of the same timeline in the low level i915_gem_request_await_request(), after having added the dependency on the old request. However, we can lift this to i915_gem_request_await_dma_fence() (before the dependency is added) using the observation that requests alo

[Intel-gfx] [PATCH v2 5/9] drm/i915: Squash repeated awaits on the same fence

2017-04-12 Thread Chris Wilson
Track the latest fence waited upon on each context, and only add a new asynchronous wait if the new fence is more recent than the recorded fence for that context. This requires us to filter out unordered timelines, which are noted by DMA_FENCE_NO_CONTEXT. However, in the absence of a universal iden

[Intel-gfx] [PATCH v2 4/9] drm/i915: Redefine ptr_pack_bits() and friends

2017-04-12 Thread Chris Wilson
Rebrand the current (pointer | bits) pack/unpack utility macros as explicit bit twiddling for PAGE_SIZE so that we can use the more flexible underlying macros for different bits. Signed-off-by: Chris Wilson Reviewed-by: Joonas Lahtinen --- drivers/gpu/drm/i915/i915_cmd_parser.c | 2 +- drivers

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

2017-04-12 Thread Chris Wilson
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 --- drivers/gpu/drm/i915/i915_gem_request.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/i915_gem_request.c b/d

Re: [Intel-gfx] The i915 stable patch marking is totally broken

2017-04-12 Thread Greg KH
On Mon, Mar 13, 2017 at 07:49:59AM +0100, Daniel Vetter wrote: > On Sun, Mar 12, 2017 at 10:52 PM, Greg KH wrote: > > Why don't the maintainers know which tree to put them in when they are > > submitted? As an example, if I get a patch that needs to go to Linus, I > > put it in my usb-linus branc

Re: [Intel-gfx] Potential BUG in drm/i915/execlists: Reset RING registers upon resume

2017-04-12 Thread Greg Kroah-Hartman
On Mon, Mar 20, 2017 at 11:24:38AM -0400, Eric Blau wrote: > On Mon, Mar 20, 2017 at 11:13 AM, Greg Kroah-Hartman > wrote: > > On Mon, Mar 20, 2017 at 05:01:34PM +0200, Jani Nikula wrote: > >> On Tue, 14 Mar 2017, Eric Blau wrote: > >> > That's funny. I have a MacBook Pro 12,1 from late 2015. Hib

Re: [Intel-gfx] The i915 stable patch marking is totally broken

2017-04-12 Thread Greg KH
On Wed, Apr 12, 2017 at 02:48:55PM +0200, Greg KH wrote: > On Mon, Mar 13, 2017 at 07:49:59AM +0100, Daniel Vetter wrote: > > On Sun, Mar 12, 2017 at 10:52 PM, Greg KH > > wrote: > > > Why don't the maintainers know which tree to put them in when they are > > > submitted? As an example, if I get

Re: [Intel-gfx] [RFC] drm/i915: Introduce GEM_MAYBE_BUILD_BUG_ON

2017-04-12 Thread Michal Wajdeczko
On Wed, Apr 12, 2017 at 12:13:51PM +0100, Tvrtko Ursulin wrote: > > On 11/04/2017 14:57, Michal Wajdeczko wrote: > > This is slightly weaker version of MAYBE_BUILD_BUG_ON that allows > > us to avoid adding implicit BUG but still detect as much as possible > > during the build. With this new macro

Re: [Intel-gfx] [PATCH] drm: Document code of conduct

2017-04-12 Thread Sumit Semwal
Hi Daniel, On 11 April 2017 at 13:03, Sumit Semwal wrote: > On 11 April 2017 at 12:38, Daniel Stone wrote: >> Hi, >> >> On 11 April 2017 at 07:48, Daniel Vetter wrote: >>> Note: As Daniel Stone mentioned in the announcement fd.o admins >>> started chatting with the communities their hosting, wh

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [v2,1/9] drm/i915: Mark up clflushes as belonging to an unordered timeline

2017-04-12 Thread Patchwork
== Series Details == Series: series starting with [v2,1/9] drm/i915: Mark up clflushes as belonging to an unordered timeline URL : https://patchwork.freedesktop.org/series/22924/ State : success == Summary == Series 22924v1 Series without cover letter https://patchwork.freedesktop.org/api/1.0

Re: [Intel-gfx] [PATCH V5] drm/i915: Disable stolen memory when i915 runs on qemu

2017-04-12 Thread Joonas Lahtinen
+ Kevin and David On ke, 2017-04-12 at 20:20 +0800, Xiong Zhang wrote: > Stolen memory isn't a standard pci resource and exists in RMRR which has > identity mapping in iommu table, IGD could access stolen memory in host OS. > While according to 'commit c875d2c1b808 ("iommu/vt-d: Exclude devices us

Re: [Intel-gfx] freedesktop bug id: 100548, bisected to sched/clock commit

2017-04-12 Thread Jani Nikula
On Wed, 12 Apr 2017, Peter Zijlstra wrote: > On Wed, Apr 12, 2017 at 12:04:00PM +, Lofstedt, Marta wrote: >> Hi, >> >> We have this "old" Lenovo Cantiga laptop(Intel Core 2 Duo L9400), hocked up >> to our i915 pre-merge CI system, that has started to give unstable results >> after commit: >

Re: [Intel-gfx] [PATCH] drm: Document code of conduct

2017-04-12 Thread Keith Packard
Daniel Vetter writes: > freedesktop.org has adopted a formal&enforced code of conduct: Acked-by: Keith Packard -- -keith signature.asc Description: PGP signature ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.

Re: [Intel-gfx] Potential BUG in drm/i915/execlists: Reset RING registers upon resume

2017-04-12 Thread Jani Nikula
On Wed, 12 Apr 2017, Greg Kroah-Hartman wrote: > On Mon, Mar 20, 2017 at 11:24:38AM -0400, Eric Blau wrote: >> On Mon, Mar 20, 2017 at 11:13 AM, Greg Kroah-Hartman >> wrote: >> > On Mon, Mar 20, 2017 at 05:01:34PM +0200, Jani Nikula wrote: >> >> On Tue, 14 Mar 2017, Eric Blau wrote: >> >> > That

Re: [Intel-gfx] freedesktop bug id: 100548, bisected to sched/clock commit

2017-04-12 Thread Martin Peres
On 12/04/17 15:31, Peter Zijlstra wrote: On Wed, Apr 12, 2017 at 12:04:00PM +, Lofstedt, Marta wrote: Hi, We have this "old" Lenovo Cantiga laptop(Intel Core 2 Duo L9400), hocked up to our i915 pre-merge CI system, that has started to give unstable results after commit: commit 7b09cc5a9

  1   2   >