[Intel-gfx] [RFC PATCH] drm/vblanks: Deal with HW vblank counter resets.

2017-11-06 Thread Dhinakaran Pandiyan
Some HW vblank counters reset due to power management events, which messes up the vblank counting logic. This leads to screen freezes with user space waiting on vblank events that may not occur if the counter keeps resetting. For e.g., After the HW vblank counter resets [9.007359] [drm:drm_upd

[Intel-gfx] [PATCH v3] drm/i915: Object w/o backing stroage is banned by -ENXIO

2017-11-06 Thread Tina Zhang
-ENXIO should be returned when operations are banned from changing backing storage of objects without backing storage. v3: - Separate this patch from "Introduce GEM proxy" patch-set. (Joonas) v2: - update the patch description and subject to just mention objects w/o backing storage, instead of

Re: [Intel-gfx] [PATCH 2/5] drm/i915/guc: Release all client doorbells on suspend and acquire on resume

2017-11-06 Thread Sagar Arun Kamble
On 11/6/2017 5:43 PM, Chris Wilson wrote: Quoting Sagar Arun Kamble (2017-11-05 13:39:40) Before GT device suspend, i915 should release GuC client doorbells by stopping doorbell controller snooping and doorbell deallocation through GuC. They need to be acquired again on resume. This will also

Re: [Intel-gfx] [PATCH v16 5/6] vfio: ABI for mdev display dma-buf operation

2017-11-06 Thread Zhang, Tina
> -Original Message- > From: intel-gvt-dev [mailto:intel-gvt-dev-boun...@lists.freedesktop.org] On > Behalf Of Gerd Hoffmann > Sent: Monday, November 6, 2017 5:01 PM > To: Zhang, Tina ; alex.william...@redhat.com; > ch...@chris-wilson.co.uk; joonas.lahti...@linux.intel.com; > zhen...@linu

Re: [Intel-gfx] [PATCH v16 5/6] vfio: ABI for mdev display dma-buf operation

2017-11-06 Thread Zhang, Tina
> -Original Message- > From: Alex Williamson [mailto:alex.william...@redhat.com] > Sent: Tuesday, November 7, 2017 4:37 AM > To: Gerd Hoffmann > Cc: Zhang, Tina ; Tian, Kevin ; > Daniel Vetter ; intel-gfx@lists.freedesktop.org; > joonas.lahti...@linux.intel.com; linux-ker...@vger.kernel.

Re: [Intel-gfx] [PATCH v2 2/2] drm/i915: Object w/o backing stroage is banned by -ENXIO

2017-11-06 Thread Zhang, Tina
> -Original Message- > From: Joonas Lahtinen [mailto:joonas.lahti...@linux.intel.com] > Sent: Monday, November 6, 2017 6:57 PM > To: Zhang, Tina ; zhen...@linux.intel.com; Wang, Zhi > A ; dan...@ffwll.ch; ch...@chris-wilson.co.uk > Cc: intel-gfx@lists.freedesktop.org; intel-gvt-...@lists.

Re: [Intel-gfx] [PATCH v2 1/2] drm/i915: Introduce GEM proxy

2017-11-06 Thread Zhang, Tina
> -Original Message- > From: intel-gvt-dev [mailto:intel-gvt-dev-boun...@lists.freedesktop.org] On > Behalf Of Joonas Lahtinen > Sent: Monday, November 6, 2017 7:24 PM > To: Zhang, Tina ; zhen...@linux.intel.com; Wang, Zhi > A ; dan...@ffwll.ch; ch...@chris-wilson.co.uk > Cc: Daniel Vette

[Intel-gfx] [PATCH] tests/kms_plane_scaling: Enhanced plane scaler test case.

2017-11-06 Thread Yadav Jyoti
From: Jyoti Yadav Added few subtests to cover below gaps. 1. scaler with pixelformat and tiling. 2. scaler with rotation 3. scaler with multiple planes 4. scaler with multi pipe 5. scaler with clipping/clamping scenario Signed-off-by: Jyoti Yadav --- tes

[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/glk: Refactor handling of PLANE_COLOR_CTL for GLK+ (rev4)

2017-11-06 Thread Patchwork
== Series Details == Series: drm/i915/glk: Refactor handling of PLANE_COLOR_CTL for GLK+ (rev4) URL : https://patchwork.freedesktop.org/series/33087/ State : failure == Summary == Test kms_setmode: Subgroup basic: pass -> FAIL (shard-hsw) fdo#99912 Test kms_

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/glk: Refactor handling of PLANE_COLOR_CTL for GLK+ (rev4)

2017-11-06 Thread Patchwork
== Series Details == Series: drm/i915/glk: Refactor handling of PLANE_COLOR_CTL for GLK+ (rev4) URL : https://patchwork.freedesktop.org/series/33087/ State : success == Summary == Series 33087v4 drm/i915/glk: Refactor handling of PLANE_COLOR_CTL for GLK+ https://patchwork.freedesktop.org/api/1

Re: [Intel-gfx] [PATCH v2 6/9] drm/i915: expose command stream timestamp frequency to userspace

2017-11-06 Thread Rafael Antognolli
This patch, along with the respective ones for Mesa, does fix the gl timestamp query piglit failures on CNL. So it is Tested-by: Rafael Antognolli On Thu, Nov 02, 2017 at 04:29:46PM +, Lionel Landwerlin wrote: > We use to have this fixed per generation, but starting with CNL userspace > cann

[Intel-gfx] [CI v3] drm/i915/glk: Refactor handling of PLANE_COLOR_CTL for GLK+

2017-11-06 Thread James Ausmus
Since GLK, some plane configuration settings have moved to the PLANE_COLOR_CTL register. Refactor handling of the register to work like PLANE_CTL. This also allows us to fix the set/read of the plane Alpha Mode for GLK+. v2: Adjust ordering of platform checks to be newest->oldest, drop redundant c

[Intel-gfx] [RESEND PATCH v3 05/12] drm/i915: Use drm_fb_helper_output_poll_changed()

2017-11-06 Thread Noralf Trønnes
This driver can use drm_fb_helper_output_poll_changed() as its .output_poll_changed callback. Cc: Jani Nikula Cc: Joonas Lahtinen Cc: Rodrigo Vivi Signed-off-by: Noralf Trønnes Reviewed-by: Daniel Vetter --- I'm resending to get a CI run. Noralf. drivers/gpu/drm/i915/intel_display.c | 2 +

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/glk: Refactor handling of PLANE_COLOR_CTL for GLK+ (rev3)

2017-11-06 Thread Patchwork
== Series Details == Series: drm/i915/glk: Refactor handling of PLANE_COLOR_CTL for GLK+ (rev3) URL : https://patchwork.freedesktop.org/series/33087/ State : failure == Summary == Series 33087v3 drm/i915/glk: Refactor handling of PLANE_COLOR_CTL for GLK+ https://patchwork.freedesktop.org/api/1

[Intel-gfx] ✗ Fi.CI.BAT: warning for drm/i915: Deconstruct struct sgt_dma initialiser

2017-11-06 Thread Patchwork
== Series Details == Series: drm/i915: Deconstruct struct sgt_dma initialiser URL : https://patchwork.freedesktop.org/series/33291/ State : warning == Summary == Series 33291v1 drm/i915: Deconstruct struct sgt_dma initialiser https://patchwork.freedesktop.org/api/1.0/series/33291/revisions/1/m

[Intel-gfx] [PATCH] drm/i915: Deconstruct struct sgt_dma initialiser

2017-11-06 Thread Chris Wilson
gcc-4.4 complains about: struct sgt_dma iter = { .sg = vma->pages->sgl, .dma = sg_dma_address(iter.sg), .max = iter.dma + iter.sg->length, }; drivers/gpu/drm/i915/i915_gem_gtt.c: In function ‘gen8_ppgtt_insert_4lvl’: drivers/gpu/drm/

Re: [Intel-gfx] [PATCH v16 5/6] vfio: ABI for mdev display dma-buf operation

2017-11-06 Thread Alex Williamson
On Mon, 06 Nov 2017 10:05:34 +0100 Gerd Hoffmann wrote: > Hi, > > > > I thought we had agreed to make this behave similar to > > > VFIO_GROUP_GET_DEVICE_FD, the ioctl would take a __u32 dmabuf_id > > > and > > > return the file descriptor as the ioctl return value.  Thanks, > > > > If we fo

Re: [Intel-gfx] [PATCH 1/2] drm/i915: implemented dynamic WOPCM partition.

2017-11-06 Thread Yaodong Li
On 11/06/2017 12:16 AM, Sagar Arun Kamble wrote: Please update the subject to "Implement dynamic WOPCM partitioning" Also, commit description should be written in present tense form. Will update it in v2. On 11/4/2017 5:48 AM, Jackie Li wrote: Static WOPCM partitioning would lead to GuC loadi

Re: [Intel-gfx] [PATCH i-g-t v2 RESEND] tests/kms_fbcon_fbt: Report fbc_status on error

2017-11-06 Thread Paulo Zanoni
Em Seg, 2017-11-06 às 16:16 -0200, Gabriel Krisman Bertazi escreveu: > Paulo Zanoni writes: > > > Em Seg, 2017-10-30 às 15:54 -0200, Gabriel Krisman Bertazi > > escreveu: > > > knowing the assertion triggered on wait_until_enabled() is not > > > that > > > useful without knowing what exactly caus

[Intel-gfx] ✓ Fi.CI.IGT: success for tests/kms_plane_scaling: Fix off-by-one plane selection

2017-11-06 Thread Patchwork
== Series Details == Series: tests/kms_plane_scaling: Fix off-by-one plane selection URL : https://patchwork.freedesktop.org/series/33277/ State : success == Summary == Test kms_flip: Subgroup dpms-vs-vblank-race-interruptible: fail -> PASS (shard-hsw) fdo#1

Re: [Intel-gfx] [RFC PATCH 04/20] drm/i915: Transform context WAs into static tables

2017-11-06 Thread Oscar Mateo
On 11/06/2017 03:59 AM, Joonas Lahtinen wrote: On Fri, 2017-11-03 at 11:09 -0700, Oscar Mateo wrote: This is for WAs that need to touch registers that get saved/restored together with the logical context. The idea is that WAs are "pretty" static, so a table is more declarative than a programma

[Intel-gfx] ✓ Fi.CI.BAT: success for tests/kms_plane_scaling: Fix off-by-one plane selection

2017-11-06 Thread Patchwork
== Series Details == Series: tests/kms_plane_scaling: Fix off-by-one plane selection URL : https://patchwork.freedesktop.org/series/33277/ State : success == Summary == IGT patchset tested on top of latest successful build b9f2abda9503bd55690cf3c2ccf2f20e8fc19ab3 tests/gem_eio: Nerf in-flight-

Re: [Intel-gfx] [PATCH i-g-t] tests/kms_plane_scaling: Fix off-by-one plane selection

2017-11-06 Thread Robert Foss
Hey Gabriel, I've reviewed and pushed this patch. Thanks. Rob. On Mon, 2017-11-06 at 16:28 -0200, Gabriel Krisman Bertazi wrote: > Commit ca20170afc6f ("tests/kms_plane_scaling: Add support for > dynamic > number of planes") shifted the tested planes by one after the > refactoring, accidentally

[Intel-gfx] [PATCH i-g-t] tests/kms_plane_scaling: Fix off-by-one plane selection

2017-11-06 Thread Gabriel Krisman Bertazi
Commit ca20170afc6f ("tests/kms_plane_scaling: Add support for dynamic number of planes") shifted the tested planes by one after the refactoring, accidentally ignoring the first plane, which is zero indexed. A symptom of the issue appears on KBL, where the third plane is already the shared cursor,

Re: [Intel-gfx] [PATCH 1/2] drm/i915: implemented dynamic WOPCM partition.

2017-11-06 Thread Yaodong Li
On 11/06/2017 05:24 AM, Ville Syrjälä wrote: On Fri, Nov 03, 2017 at 05:01:09PM -0700, Jackie Li wrote: Static WOPCM partitioning would lead to GuC loading failure if the GuC/HuC firmware size exceeded current static 512KB partition boundary. This patch enabled the dynamical calculation of the

Re: [Intel-gfx] [PATCH i-g-t v2 RESEND] tests/kms_fbcon_fbt: Report fbc_status on error

2017-11-06 Thread Gabriel Krisman Bertazi
Paulo Zanoni writes: > Em Seg, 2017-10-30 às 15:54 -0200, Gabriel Krisman Bertazi escreveu: >> knowing the assertion triggered on wait_until_enabled() is not that >> useful without knowing what exactly caused the failure.  It might be >> an >> user error, like too little stolen memory by the bios

Re: [Intel-gfx] [PATCH 3/5] drm/vmwgfx: Try to fix plane clipping

2017-11-06 Thread Ville Syrjälä
On Thu, Nov 02, 2017 at 03:19:30PM +0200, Ville Syrjälä wrote: > On Thu, Nov 02, 2017 at 11:12:09AM +0100, Daniel Vetter wrote: > > On Wed, Nov 01, 2017 at 08:29:18PM +0200, Ville Syrjala wrote: > > > From: Ville Syrjälä > > > > > > Try to fix the code to actually clip the plane to the crtc bound

Re: [Intel-gfx] [PATCH i-g-t v2 RESEND] tests/kms_fbcon_fbt: Report fbc_status on error

2017-11-06 Thread Paulo Zanoni
Em Seg, 2017-10-30 às 15:54 -0200, Gabriel Krisman Bertazi escreveu: > knowing the assertion triggered on wait_until_enabled() is not that > useful without knowing what exactly caused the failure.  It might be > an > user error, like too little stolen memory by the bios, or an actual > issue in the

Re: [Intel-gfx] [PATCH] drm/atomic: Try to preserve the crtc enabled state in drm_atomic_remove_fb, v2.

2017-11-06 Thread Ville Syrjälä
On Mon, Nov 06, 2017 at 04:43:17PM +0100, Maarten Lankhorst wrote: > Op 06-11-17 om 15:06 schreef Ville Syrjälä: > > On Mon, Nov 06, 2017 at 04:01:20PM +0200, Ville Syrjälä wrote: > >> On Thu, Nov 02, 2017 at 09:55:40AM +0100, Maarten Lankhorst wrote: > >>> Op 01-11-17 om 18:00 schreef Ville Syrjäl

Re: [Intel-gfx] [PATCH] drm/atomic: Try to preserve the crtc enabled state in drm_atomic_remove_fb, v2.

2017-11-06 Thread Maarten Lankhorst
Op 06-11-17 om 15:06 schreef Ville Syrjälä: > On Mon, Nov 06, 2017 at 04:01:20PM +0200, Ville Syrjälä wrote: >> On Thu, Nov 02, 2017 at 09:55:40AM +0100, Maarten Lankhorst wrote: >>> Op 01-11-17 om 18:00 schreef Ville Syrjälä: On Wed, Nov 01, 2017 at 04:55:06PM +0100, Maarten Lankhorst wrote:

[Intel-gfx] i915: pipe B vblank wait timed out

2017-11-06 Thread Borislav Petkov
Hi, I see this on an 32-bit acer atom mini-laptop with -rc8+tip: [2.399416] pipe B vblank wait timed out [2.399506] [ cut here ] [2.399533] WARNING: CPU: 1 PID: 22 at /mnt/kernel/kernel/linux-2.6/drivers/gpu/drm/i915/intel_display.c:12176 intel_atomic_commit_

Re: [Intel-gfx] [PATCH 0/7] drm/edid and drivers: ELD refactoring

2017-11-06 Thread Thierry Reding
On Wed, Nov 01, 2017 at 04:20:56PM +0200, Jani Nikula wrote: > We were recently bitten by drm_edid_to_eld() clearing the connector > type, and us failing to set it back for DP. Here's a few ELD related > patches to try to unify ELD handling and make it a bit simpler for > drivers to get it right. >

Re: [Intel-gfx] [PATCH] drm/i915: Reserve powerctx for chv from the stolen allocator

2017-11-06 Thread Chris Wilson
Quoting Ville Syrjälä (2017-11-06 14:43:12) > On Mon, Nov 06, 2017 at 02:32:50PM +, Chris Wilson wrote: > > Quoting Ville Syrjälä (2017-11-06 14:23:24) > > > On Sat, Nov 04, 2017 at 09:43:38PM +, Chris Wilson wrote: > > > > Ensure that we do not overwrite the cherryview power context by > >

Re: [Intel-gfx] [PATCH] drm/i915: Reserve powerctx for chv from the stolen allocator

2017-11-06 Thread Ville Syrjälä
On Mon, Nov 06, 2017 at 02:32:50PM +, Chris Wilson wrote: > Quoting Ville Syrjälä (2017-11-06 14:23:24) > > On Sat, Nov 04, 2017 at 09:43:38PM +, Chris Wilson wrote: > > > Ensure that we do not overwrite the cherryview power context by > > > reserving its range in the stolen allocator; exac

Re: [Intel-gfx] [PATCH] drm/i915: Reserve powerctx for chv from the stolen allocator

2017-11-06 Thread Chris Wilson
Quoting Ville Syrjälä (2017-11-06 14:23:24) > On Sat, Nov 04, 2017 at 09:43:38PM +, Chris Wilson wrote: > > Ensure that we do not overwrite the cherryview power context by > > reserving its range in the stolen allocator; exactly like how we handle > > the same reservation for valleyview. > > I

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/guc: Assert ctch->vma is allocated

2017-11-06 Thread Patchwork
== Series Details == Series: drm/i915/guc: Assert ctch->vma is allocated URL : https://patchwork.freedesktop.org/series/33257/ State : failure == Summary == Series 33257v1 drm/i915/guc: Assert ctch->vma is allocated https://patchwork.freedesktop.org/api/1.0/series/33257/revisions/1/mbox/ Test

Re: [Intel-gfx] [PATCH] drm/i915: Reserve powerctx for chv from the stolen allocator

2017-11-06 Thread Ville Syrjälä
On Sat, Nov 04, 2017 at 09:43:38PM +, Chris Wilson wrote: > Ensure that we do not overwrite the cherryview power context by > reserving its range in the stolen allocator; exactly like how we handle > the same reservation for valleyview. IIRC CHV pctx must live inside the "reserved" region. So

Re: [Intel-gfx] [PATCH v6 1/3] drm/i915: Add Guc/HuC firmware details to error state

2017-11-06 Thread Chris Wilson
Quoting Michal Wajdeczko (2017-10-26 18:36:55) > Include GuC and HuC firmware details in captured error state > to provide additional debug information. To reuse existing > uc firmware pretty printer, introduce new drm-printer variant > that works with our i915_error_state_buf output. Also update >

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: Generalize transcoder looping (rev2)

2017-11-06 Thread Patchwork
== Series Details == Series: drm/i915: Generalize transcoder looping (rev2) URL : https://patchwork.freedesktop.org/series/32965/ State : failure == Summary == Series 32965v2 drm/i915: Generalize transcoder looping https://patchwork.freedesktop.org/api/1.0/series/32965/revisions/2/mbox/ Test

Re: [Intel-gfx] [PATCH] drm/atomic: Try to preserve the crtc enabled state in drm_atomic_remove_fb, v2.

2017-11-06 Thread Ville Syrjälä
On Mon, Nov 06, 2017 at 04:01:20PM +0200, Ville Syrjälä wrote: > On Thu, Nov 02, 2017 at 09:55:40AM +0100, Maarten Lankhorst wrote: > > Op 01-11-17 om 18:00 schreef Ville Syrjälä: > > > On Wed, Nov 01, 2017 at 04:55:06PM +0100, Maarten Lankhorst wrote: > > >> Op 01-11-17 om 16:29 schreef Ville Syrj

Re: [Intel-gfx] [PATCH] drm/atomic: Try to preserve the crtc enabled state in drm_atomic_remove_fb, v2.

2017-11-06 Thread Ville Syrjälä
On Thu, Nov 02, 2017 at 09:55:40AM +0100, Maarten Lankhorst wrote: > Op 01-11-17 om 18:00 schreef Ville Syrjälä: > > On Wed, Nov 01, 2017 at 04:55:06PM +0100, Maarten Lankhorst wrote: > >> Op 01-11-17 om 16:29 schreef Ville Syrjälä: > >>> On Wed, Nov 01, 2017 at 04:04:33PM +0100, Maarten Lankhorst

[Intel-gfx] [PATCH] drm/i915/guc: Assert ctch->vma is allocated

2017-11-06 Thread Michal Wajdeczko
Silence smatch by demonstrating that ctch->vma is allocated following a successful chch_init() drivers/gpu/drm/i915/intel_guc_ct.c:204 ctch_open() error: we previously assumed 'ctch->vma' could be null (see line 197) Signed-off-by: Michal Wajdeczko Cc: Chris Wilson Cc: Joonas Lahtinen --- dr

[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [CI,1/8] drm/i915: Assert guc->stage_desc_pool is allocated

2017-11-06 Thread Patchwork
== Series Details == Series: series starting with [CI,1/8] drm/i915: Assert guc->stage_desc_pool is allocated URL : https://patchwork.freedesktop.org/series/33254/ State : failure == Summary == Series 33254v1 series starting with [CI,1/8] drm/i915: Assert guc->stage_desc_pool is allocated ht

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Assert guc->stage_desc_pool is allocated

2017-11-06 Thread Patchwork
== Series Details == Series: drm/i915: Assert guc->stage_desc_pool is allocated URL : https://patchwork.freedesktop.org/series/33248/ State : success == Summary == Test kms_setmode: Subgroup basic: pass -> FAIL (shard-hsw) fdo#99912 Test kms_flip: Su

Re: [Intel-gfx] [PATCH] drm/i915: Assert guc->stage_desc_pool is allocated

2017-11-06 Thread Michal Wajdeczko
On Mon, Nov 06, 2017 at 11:48:33AM +, Chris Wilson wrote: > Silence smatch by demonstrating that guc->stage_desc_pool is allocated > following a successful guc_stage_desc_pool_create() > > drivers/gpu/drm/i915/i915_guc_submission.c:1293 i915_guc_submission_init() > error: we previously assume

[Intel-gfx] [CI 8/8] drm/i915: Stop caching the "golden" renderstate

2017-11-06 Thread Chris Wilson
As we now record the default HW state and so only emit the "golden" renderstate once to prepare the HW, there is no advantage in keeping the renderstate batch around as it will never be used again. Signed-off-by: Chris Wilson Reviewed-by: Joonas Lahtinen --- drivers/gpu/drm/i915/i915_drv.h

[Intel-gfx] [PATCH v2] drm/i915: Generalize transcoder looping

2017-11-06 Thread Mika Kahola
To make looping through transcoders in intel_ddi.c more generic, let's switch to use 'for_each_pipe()' macro to do this. v2: Add a notion that we are dealing with transcoders instead of pipes (Jani) Signed-off-by: Mika Kahola --- drivers/gpu/drm/i915/intel_ddi.c | 11 +++ 1 file changed

[Intel-gfx] [CI 1/8] drm/i915: Assert guc->stage_desc_pool is allocated

2017-11-06 Thread Chris Wilson
Silence smatch by demonstrating that guc->stage_desc_pool is allocated following a successful guc_stage_desc_pool_create() drivers/gpu/drm/i915/i915_guc_submission.c:1293 i915_guc_submission_init() error: we previously assumed 'guc->stage_desc_pool' could be null (see line 1261 Signed-off-by: Ch

[Intel-gfx] [CI 2/8] drm/i915: Define an engine class enum for the uABI

2017-11-06 Thread Chris Wilson
From: Tvrtko Ursulin We want to be able to report back to userspace details about an engine's class, and in return for userspace to be able to request actions regarding certain classes of engines. To isolate the uABI from any variations between hw generations, we define an abstract class for the

[Intel-gfx] [CI 4/8] drm/i915: Move GT powersaving init to i915_gem_init()

2017-11-06 Thread Chris Wilson
GT powersaving is tightly coupled to the request infrastructure. To avoid complications with the order of initialisation in the next patch (where we want to send requests to hw during GEM init) move the powersaving initialisation into the purview of i915_gem_init(). Signed-off-by: Chris Wilson Cc

[Intel-gfx] [CI 5/8] drm/i915: Inline intel_modeset_gem_init()

2017-11-06 Thread Chris Wilson
intel_modeset_gem_init() now only sets up the legacy overlay, so let's remove the function and call the setup directly during driver load. This should help us find a better point in the initialisation sequence for it later. Signed-off-by: Chris Wilson Reviewed-by: Joonas Lahtinen Reviewed-by: Mi

[Intel-gfx] [CI 6/8] drm/i915: Mark the context state as dirty/written

2017-11-06 Thread Chris Wilson
In the next few patches, we will want to both copy out of the context image and write a valid image into a new context. To be completely safe, we should then couple in our domain tracking to ensure that we don't have any issues with stale data remaining in unwanted cachelines. Historically, we omi

[Intel-gfx] [CI 7/8] drm/i915: Record the default hw state after reset upon load

2017-11-06 Thread Chris Wilson
Take a copy of the HW state after a reset upon module loading by executing a context switch from a blank context to the kernel context, thus saving the default hw state over the blank context image. We can then use the default hw state to initialise any future context, ensuring that each starts wit

[Intel-gfx] [CI 3/8] drm/i915: Force the switch to the i915->kernel_context

2017-11-06 Thread Chris Wilson
In the next few patches, we will have a hard requirement that we emit a context-switch to the perma-pinned i915->kernel_context (so that we can save the HW state using that context-switch). As the first context itself may be classed as a kernel context, we want to be explicit in our comparison. For

Re: [Intel-gfx] [PATCH 1/2] drm/i915: implemented dynamic WOPCM partition.

2017-11-06 Thread Ville Syrjälä
On Fri, Nov 03, 2017 at 05:01:09PM -0700, Jackie Li wrote: > Static WOPCM partitioning would lead to GuC loading failure > if the GuC/HuC firmware size exceeded current static 512KB > partition boundary. > > This patch enabled the dynamical calculation of the WOPCM aperture > used by GuC/HuC firmw

Re: [Intel-gfx] [PATCH] drm/i915/selftests: Hide dangerous tests

2017-11-06 Thread Chris Wilson
Quoting Joonas Lahtinen (2017-11-06 10:47:52) > On Wed, 2017-10-25 at 16:32 +0100, Chris Wilson wrote: > > Some tests are designed to exercise the limits of the HW and may trigger > > unintended side-effects making the machine unusable. This should not be > > executed by default, but are still usef

Re: [Intel-gfx] [PATCH] drm/i915: Lock llist_del_first() vs llist_del_all()

2017-11-06 Thread Chris Wilson
Quoting Mika Kuoppala (2017-11-06 11:46:16) > Chris Wilson writes: > > > An oversight in commit 87701b4b5593 ("drm/i915: Only free the oldest > > stale object before a fresh allocation") was that not only do we have to > > serialise concurrent users of llist_del_first(), but we also have to > > l

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Lock llist_del_first() vs llist_del_all() (rev2)

2017-11-06 Thread Patchwork
== Series Details == Series: drm/i915: Lock llist_del_first() vs llist_del_all() (rev2) URL : https://patchwork.freedesktop.org/series/33241/ State : success == Summary == Test drv_module_reload: Subgroup basic-reload-inject: pass -> DMESG-WARN (shard-hsw) fdo#102

Re: [Intel-gfx] [RFC PATCH 02/20] drm/i915: Move a bunch of workaround-related code to its own file

2017-11-06 Thread Joonas Lahtinen
On Mon, 2017-11-06 at 12:42 +, Chris Wilson wrote: > Quoting Oscar Mateo (2017-11-03 18:09:30) > > This has grown to be a sizable amount of code, so move it to > > its own file before we try to refactor anything. For the moment, > > we are leaving behind the WA BB code and the WAs that get appl

Re: [Intel-gfx] [RFC PATCH 02/20] drm/i915: Move a bunch of workaround-related code to its own file

2017-11-06 Thread Chris Wilson
Quoting Oscar Mateo (2017-11-03 18:09:30) > This has grown to be a sizable amount of code, so move it to > its own file before we try to refactor anything. For the moment, > we are leaving behind the WA BB code and the WAs that get applied > (incorrectly) in init_clock_gating, but we will deal with

Re: [Intel-gfx] [RFC PATCH 01/20] drm/i915: Remove Gen9 WAs with no effect

2017-11-06 Thread Chris Wilson
Quoting Oscar Mateo (2017-11-03 18:09:29) > GEN8_CONFIG0 (0xD00) is a protected by a lock (bit 31) which is set by > the BIOS, so there is no way we can enable the three chicken bits > mandated by the WA (the BIOS should be doing it instead). > > v2: Rebased > v3: Standalone patch > > Signed-off-

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Assert guc->stage_desc_pool is allocated

2017-11-06 Thread Patchwork
== Series Details == Series: drm/i915: Assert guc->stage_desc_pool is allocated URL : https://patchwork.freedesktop.org/series/33248/ State : success == Summary == Series 33248v1 drm/i915: Assert guc->stage_desc_pool is allocated https://patchwork.freedesktop.org/api/1.0/series/33248/revisions

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm: i915: remove timeval users

2017-11-06 Thread Patchwork
== Series Details == Series: drm: i915: remove timeval users URL : https://patchwork.freedesktop.org/series/33147/ State : failure == Summary == Series 33147v1 drm: i915: remove timeval users https://patchwork.freedesktop.org/api/1.0/series/33147/revisions/1/mbox/ Test kms_addfb_basic:

Re: [Intel-gfx] [PATCH 2/5] drm/i915/guc: Release all client doorbells on suspend and acquire on resume

2017-11-06 Thread Chris Wilson
Quoting Sagar Arun Kamble (2017-11-05 13:39:40) > Before GT device suspend, i915 should release GuC client doorbells by > stopping doorbell controller snooping and doorbell deallocation through > GuC. They need to be acquired again on resume. This will also resolve > the driver unload issue with Gu

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Lock llist_del_first() vs llist_del_all() (rev2)

2017-11-06 Thread Patchwork
== Series Details == Series: drm/i915: Lock llist_del_first() vs llist_del_all() (rev2) URL : https://patchwork.freedesktop.org/series/33241/ State : success == Summary == Series 33241v2 drm/i915: Lock llist_del_first() vs llist_del_all() https://patchwork.freedesktop.org/api/1.0/series/33241/

Re: [Intel-gfx] [RFC PATCH 04/20] drm/i915: Transform context WAs into static tables

2017-11-06 Thread Joonas Lahtinen
On Fri, 2017-11-03 at 11:09 -0700, Oscar Mateo wrote: > This is for WAs that need to touch registers that get saved/restored > together with the logical context. The idea is that WAs are "pretty" > static, so a table is more declarative than a programmatic approah. > Note however that some amount i

[Intel-gfx] [PATCH] drm/i915: Assert guc->stage_desc_pool is allocated

2017-11-06 Thread Chris Wilson
Silence smatch by demonstrating that guc->stage_desc_pool is allocated following a successful guc_stage_desc_pool_create() drivers/gpu/drm/i915/i915_guc_submission.c:1293 i915_guc_submission_init() error: we previously assumed 'guc->stage_desc_pool' could be null (see line 1261 Signed-off-by: Ch

Re: [Intel-gfx] [PATCH] drm/i915: Lock llist_del_first() vs llist_del_all()

2017-11-06 Thread Mika Kuoppala
Chris Wilson writes: > An oversight in commit 87701b4b5593 ("drm/i915: Only free the oldest > stale object before a fresh allocation") was that not only do we have to > serialise concurrent users of llist_del_first(), but we also have to > lock llist_del_first() vs llist_del_all(). > > From llist

Re: [Intel-gfx] Patch tag ordering (Was: Re: [PATCH v5 2/5] drm/i915/guc : Removing i915_modparams.enable_guc_loading module)

2017-11-06 Thread Jani Nikula
On Mon, 06 Nov 2017, Joonas Lahtinen wrote: > + Jani (and Daniel as emeritus maintainer) > > On Fri, 2017-11-03 at 10:08 -0700, Rodrigo Vivi wrote: >> On Fri, Nov 03, 2017 at 08:36:01AM +, Joonas Lahtinen wrote: >> > On Fri, 2017-11-03 at 00:03 +, Chris Wilson wrote: >> > > Quoting Rodrigo

Re: [Intel-gfx] [PATCH v2 1/2] drm/i915: Introduce GEM proxy

2017-11-06 Thread Joonas Lahtinen
On Wed, 2017-11-01 at 17:22 +0800, Tina Zhang wrote: > GEM proxy is a kind of GEM, whose backing physical memory is pinned > and produced by guest VM and is used by host as read only. With GEM > proxy, host is able to access guest physical memory through GEM object > interface. As GEM proxy is such

[Intel-gfx] [PATCH] drm/i915: Lock llist_del_first() vs llist_del_all()

2017-11-06 Thread Chris Wilson
An oversight in commit 87701b4b5593 ("drm/i915: Only free the oldest stale object before a fresh allocation") was that not only do we have to serialise concurrent users of llist_del_first(), but we also have to lock llist_del_first() vs llist_del_all(). From llist.h, * This can be summarized as

[Intel-gfx] [PATCH] drm/i915: Lock llist_del_first() vs llist_del_all()

2017-11-06 Thread Chris Wilson
An oversight in commit 87701b4b5593 ("drm/i915: Only free the oldest stale object before a fresh allocation") was that not only do we have to serialise concurrent users of llist_del_first(), but we also have to lock llist_del_first() vs llist_del_all(). From llist.h, * This can be summarized as

[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [v3,1/2] lib/gt: Mark up engine classes

2017-11-06 Thread Patchwork
== Series Details == Series: series starting with [v3,1/2] lib/gt: Mark up engine classes URL : https://patchwork.freedesktop.org/series/33239/ State : failure == Summary == IGT patchset tested on top of latest successful build c8d1ea24d3bfaf11b223bbe22407aeca196d0d89 tests/debugfs_test: Prett

Re: [Intel-gfx] [PATCH v2 2/2] drm/i915: Object w/o backing stroage is banned by -ENXIO

2017-11-06 Thread Joonas Lahtinen
Hi Tina, Please send this patch alone (or in the beginning of your series), so it can be merged already. That'll save you the effort of carrying this patch. Regards, Joonas On Wed, 2017-11-01 at 17:22 +0800, Tina Zhang wrote: > -ENXIO should be returned when operations are banned from changing

[Intel-gfx] ✗ Fi.CI.BAT: failure for lib/gt: Mark up engine classes

2017-11-06 Thread Patchwork
== Series Details == Series: lib/gt: Mark up engine classes URL : https://patchwork.freedesktop.org/series/33235/ State : failure == Summary == IGT patchset tested on top of latest successful build c8d1ea24d3bfaf11b223bbe22407aeca196d0d89 tests/debugfs_test: Pretty print subdirectories with

[Intel-gfx] [PATCH igt v3 1/2] lib/gt: Mark up engine classes

2017-11-06 Thread Chris Wilson
We introduce the concept of classes that each engine may belong to. There may be more than one engine available in each class, but each engine only belongs to one class. Each class has a unique set of capabilities and purpose (e.g. 3D rendering or video decode), but different engines within each cl

[Intel-gfx] [PATCH igt v3 2/2] igt/gem_ctx_isolation: Check isolation of registers between contexts

2017-11-06 Thread Chris Wilson
A new context assumes that all of its registers are in the default state when it is created. What may happen is that a register written by one context may leak into the second, causing mass confusion. v2: extend back to Sandybridge, ignore non-priv registers that are not context-saved (remind me w

Re: [Intel-gfx] [PATCH] drm/i915/selftests: Hide dangerous tests

2017-11-06 Thread Joonas Lahtinen
On Wed, 2017-10-25 at 16:32 +0100, Chris Wilson wrote: > Some tests are designed to exercise the limits of the HW and may trigger > unintended side-effects making the machine unusable. This should not be > executed by default, but are still useful for early platform validation. > > References: htt

Re: [Intel-gfx] [PATCH] drm/i915: Move hsw GT w/a to engine initialisation

2017-11-06 Thread Chris Wilson
Quoting Chris Wilson (2017-11-03 10:38:38) > Quoting Ville Syrjälä (2017-11-03 10:25:17) > > This problem doesn't seem like it should be specific to HSW. So I wonder > > if we should start by just reverting that offending patch and move just > > the watermark thing out to some earlier position in t

[Intel-gfx] Patch tag ordering (Was: Re: [PATCH v5 2/5] drm/i915/guc : Removing i915_modparams.enable_guc_loading module)

2017-11-06 Thread Joonas Lahtinen
+ Jani (and Daniel as emeritus maintainer) On Fri, 2017-11-03 at 10:08 -0700, Rodrigo Vivi wrote: > On Fri, Nov 03, 2017 at 08:36:01AM +, Joonas Lahtinen wrote: > > On Fri, 2017-11-03 at 00:03 +, Chris Wilson wrote: > > > Quoting Rodrigo Vivi (2017-11-02 23:52:45) > > > > On Wed, Oct 4, 20

[Intel-gfx] [PATCH igt] lib/gt: Mark up engine classes

2017-11-06 Thread Chris Wilson
We introduce the concept of classes that each engine may belong to. There may be more than one engine available in each class, but each engine only belongs to one class. Each class has a unique set of capabilities and purpose (e.g. 3D rendering or video decode), but different engines within each cl

Re: [Intel-gfx] [PATCH v5 5/7] drm/i915: Add "panel orientation" property to the panel connector

2017-11-06 Thread Daniel Vetter
On Sat, Nov 04, 2017 at 03:08:26PM +0100, Hans de Goede wrote: > Ideally we could use the VBT for this, that would be simple, in > intel_dsi_init() check dev_priv->vbt.dsi.config->rotation, set > connector->display_info.panel_orientation accordingly and call > drm_connector_init_panel_orientation_p

Re: [Intel-gfx] [PATCH v5 4/7] drm/fb-helper: Apply panel orientation connector prop to the primary plane

2017-11-06 Thread Daniel Vetter
On Sat, Nov 04, 2017 at 03:08:25PM +0100, Hans de Goede wrote: > Apply the "panel orientation" drm connector prop to the primary plane so > that fbcon and fbdev using userspace programs display the right way up. > > Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=94894 > Signed-off-by: Hans de

Re: [Intel-gfx] [PATCH v5 3/7] drm: Add support for a panel-orientation connector property

2017-11-06 Thread Daniel Vetter
On Sat, Nov 04, 2017 at 03:08:24PM +0100, Hans de Goede wrote: > On some devices the LCD panel is mounted in the casing in such a way that > the up/top side of the panel does not match with the top side of the > device (e.g. it is mounted upside-down). > > This commit adds the necessary infra for

Re: [Intel-gfx] [PATCH v5 2/7] drm: Add panel orientation quirks

2017-11-06 Thread Daniel Vetter
On Sat, Nov 04, 2017 at 03:08:23PM +0100, Hans de Goede wrote: > Some x86 clamshell design devices use portrait tablet screens and a display > engine which cannot rotate in hardware, so the firmware just leaves things > as is and we cannot figure out that the display is oriented non upright > from

Re: [Intel-gfx] [PATCH v16 1/6] drm/i915/gvt: Add framebuffer decoder support

2017-11-06 Thread Zhang, Tina
> -Original Message- > From: intel-gvt-dev [mailto:intel-gvt-dev-boun...@lists.freedesktop.org] On > Behalf Of Gerd Hoffmann > Sent: Monday, November 6, 2017 4:49 PM > To: Zhang, Tina ; alex.william...@redhat.com; > ch...@chris-wilson.co.uk; joonas.lahti...@linux.intel.com; > zhen...@linu

Re: [Intel-gfx] [PATCH v16 5/6] vfio: ABI for mdev display dma-buf operation

2017-11-06 Thread Gerd Hoffmann
Hi, > > I thought we had agreed to make this behave similar to > > VFIO_GROUP_GET_DEVICE_FD, the ioctl would take a __u32 dmabuf_id > > and > > return the file descriptor as the ioctl return value.  Thanks, > > If we follow VFIO_GROUP_GET_DEVICE_FD, we would lose flags > functionality. > Zhi an

Re: [Intel-gfx] [PATCH v16 5/6] vfio: ABI for mdev display dma-buf operation

2017-11-06 Thread Gerd Hoffmann
Hi, > +/** > + * VFIO_DEVICE_QUERY_GFX_PLANE - _IOW(VFIO_TYPE, VFIO_BASE + 14, > + *struct > vfio_device_query_gfx_plane) > + * > + * Set the drm_plane_type and flags, then retrieve the gfx plane > info. > + * > + * flags supported: > + * - VFIO_GFX_PLANE_TYPE

Re: [Intel-gfx] [PATCH v16 1/6] drm/i915/gvt: Add framebuffer decoder support

2017-11-06 Thread Gerd Hoffmann
Hi, > +static struct pixel_format bdw_pixel_formats[] = { > + {DRM_FORMAT_C8, 8, "8-bit Indexed"}, > +static struct pixel_format skl_pixel_formats[] = { > + {DRM_FORMAT_YUYV, 16, "16-bit packed YUYV (8:8:8:8 MSB- > V:Y2:U:Y1)"}, Broadwell and Skylake. What is the state for newer chips

Re: [Intel-gfx] [PATCH 1/2] drm/i915: implemented dynamic WOPCM partition.

2017-11-06 Thread Sagar Arun Kamble
Please update the subject to "Implement dynamic WOPCM partitioning" Also, commit description should be written in present tense form. On 11/4/2017 5:48 AM, Jackie Li wrote: Static WOPCM partitioning would lead to GuC loading failure if the GuC/HuC firmware size exceeded current static 512KB part