Re: [Intel-gfx] [PATCH 08/10] drm/i915: Trim the flush for the execlists request emission

On to, 2016-04-28 at 17:24 +0100, Chris Wilson wrote: > At the start of request emission, we flush some space for the request, > estimating the typical size for the request body. The common tail is now > much larger than the typical body, so we can shrink the flush > substantially. > >

Re: [Intel-gfx] [PATCH 01/10] drm/i915: Apply strongly ordered RCS breadcrumb to gen8/legacy

On to, 2016-04-28 at 17:24 +0100, Chris Wilson wrote: > For legacy ringbuffer mode, we need the new ordered breadcrumb emission > tried and tested on execlists. > > Signed-off-by: Chris Wilson > --- >  drivers/gpu/drm/i915/intel_ringbuffer.c | 37 >

Re: [Intel-gfx] [PATCH v2] drm/i915/execlists: Refactor common engine setup

On 28/04/16 18:35, Chris Wilson wrote: Move all of the constant assignments up front and into a common function. This is primarily to ensure the backpointers are set as early as possible for later use during initialisation. v2: Use a constant struct so that all the similar values are set

[Intel-gfx] [PATCHv2 4/5] drm: Add an blend_color property

From: Damien Lespiau Add blend color property and update the documentation for the same V2: Add blend color support in get property. Signed-off-by: Damien Lespiau Signed-off-by: vandita kulkarni ---

[Intel-gfx] [PATCHv2 1/5] drm: Introduce the blend-func property

From: Damien Lespiau We'd like to be able to program the blending modes of display planes. Ville suggested to use something similar to the GL blend states, which does seem like a good idea. For now, we only consider blend factors, but room is left for extensions: blend

Re: [Intel-gfx] [PATCH v2] drm/i915/execlists: Refactor common engine setup

On Fri, Apr 29, 2016 at 10:25:41AM +0100, Tvrtko Ursulin wrote: > On 29/04/16 10:15, Chris Wilson wrote: > >diff --git a/drivers/gpu/drm/i915/intel_lrc.c > >b/drivers/gpu/drm/i915/intel_lrc.c > >index 2e0eaa9fa240..2c94072ab085 100644 > >--- a/drivers/gpu/drm/i915/intel_lrc.c > >+++

[Intel-gfx] [PATCH] drm/i915/lvds: do not set border bits when panel fitter is not enabled

We also don't read the border bits in i9xx_get_pfit_config() when the panel fitter is not enabled, causing the state checker warning: [drm:intel_pipe_config_compare [i915]] *ERROR* mismatch in gmch_pfit.lvds_border_bits (expected 0x8000, found 0x) Cc: Ville Syrjälä

Re: [Intel-gfx] [PATCH v2 2/2] drm/i915/bxt: Fix inadvertent CPU snooping due to incorrect MOCS config

Hi, On 27.04.2016 17:53, Chris Wilson wrote: On Wed, Apr 27, 2016 at 04:25:09PM +0300, Eero Tamminen wrote: [...] Daniel, Chris, did you have some concrete example in mind where 3D driver would require CPU to snoop GPU? Not mesa, but X can do concurrent rendering to a Pixmap whilst also

Re: [Intel-gfx] [PATCH v2] drm/i915/execlists: Refactor common engine setup

On 29/04/16 10:15, Chris Wilson wrote: On Fri, Apr 29, 2016 at 10:04:35AM +0100, Tvrtko Ursulin wrote: On 28/04/16 18:35, Chris Wilson wrote: Move all of the constant assignments up front and into a common function. This is primarily to ensure the backpointers are set as early as possible

Re: [Intel-gfx] [PATCH 06/10] drm/i915: Bump reserved size for legacy gen8 semaphore emission

On to, 2016-04-28 at 17:24 +0100, Chris Wilson wrote: > With 5 rings and a flush, we need 192 bytes of space to emit the > breadcrumb and semaphores. However, we need some spare room the size of > the single largest packet (36 dwords, 144 bytes) to accommodate > wraparound giving a grand total of

Re: [Intel-gfx] [PATCH v2] drm/i915/execlists: Refactor common engine setup

On Fri, Apr 29, 2016 at 10:04:35AM +0100, Tvrtko Ursulin wrote: > > On 28/04/16 18:35, Chris Wilson wrote: > >Move all of the constant assignments up front and into a common > >function. This is primarily to ensure the backpointers are set as early > >as possible for later use during

[Intel-gfx] [PATCHv2 0/5] Support blending modes of display planes

From: vandita kulkarni The below patches support plane and pixel blending by adding two properties blend_func and blend_color. As per Damien's initial patches, this design based on OpenGL's blend equations is suggested by Ville. All the below patches are tested on

[Intel-gfx] [PATCHv2 2/5] drm/i915/skl: Add blend_func to SKL/BXT sprite planes

From: Damien Lespiau This patch adds the blend functions, and as per the blend function, updates the plane control register values V2: Add blend support for all RGB formats Fix the reg writes on plane_ctl_alpha bits. V3: Add support support for primary and cursor

[Intel-gfx] [PATCHv2 5/5] drm/i915/skl: Add support for blending modes

From: Damien Lespiau This patch adds support for blending modes involving color. V2: Add support for primary plane. Separate out plane alpha disable functionality from per pixel drop_alpha blend function and add another blend function case for disabling plane alpha.

[Intel-gfx] [PATCHv2 3/5] drm: Introduce DRM_MODE_COLOR()

From: Damien Lespiau In the hope of expressing colors in the KMS API in a consitant want, let's introduce a ARGB 16161616 color and a few convinience macros around it. Signed-off-by: Damien Lespiau --- include/uapi/drm/drm_mode.h | 34

Re: [Intel-gfx] [PATCH 21/21] drm/i915/slpc: Fail intel_runtime_suspend if SLPC or RPS not active

On to, 2016-04-28 at 09:00 +0100, Chris Wilson wrote: > On Thu, Apr 28, 2016 at 10:57:20AM +0300, Imre Deak wrote: > > On to, 2016-04-28 at 07:56 +0100, Chris Wilson wrote: > > > On Wed, Apr 27, 2016 at 06:11:05PM -0700, tom.orou...@intel.com > > > wrote: > > > > From: Sagar Arun Kamble

Re: [Intel-gfx] [PATCH v4 00/21] Add support for GuC-based SLPC

On Thu, Apr 28, 2016 at 04:01:14PM -0700, O'Rourke, Tom wrote: > On Wed, Apr 27, 2016 at 06:10:44PM -0700, tom.orou...@intel.com wrote: > > From: Tom O'Rourke > > > > SLPC (Single Loop Power Controller) is a replacement for > > some host-based power management features.

[Intel-gfx] [PULL] topic/drm-misc

Hi Dave, - prep work for struct_mutex-less gem_free_object - more invasive/tricky mst fixes from Lyude for broken hw. I discussed this with Ville/Jani and we all agreed more soaking in -next would be real good this late in the -rc cycle. They're cc: stable too to make sure they're not

Re: [Intel-gfx] [PATCH 03/10] drm/i915: Fix gen8 semaphores id for legacy mode

On Fri, Apr 29, 2016 at 09:36:37AM +0100, Tvrtko Ursulin wrote: > > On 28/04/16 17:24, Chris Wilson wrote: > >With the introduction of a distinct engine->id vs the hardware id, we need > >to fix up the value we use for selecting the target engine when signaling > >a semaphore. Note that these

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

Hi Dave, drm-intel-next-2016-04-25: - more userptr cornercase fixes from Chris - clean up and tune forcewake handling (Tvrtko) - more underrun fixes from Ville, mostly for ilk to appeas CI - fix unclaimed register warnings on vlv/chv and enable the debug code to catch them by default (Ville) -

[Intel-gfx] [CI 1/3] drm/i915: Bump reserved size for legacy gen8 semaphore emission

With 5 rings and a flush, we need 192 bytes of space to emit the breadcrumb and semaphores. However, we need some spare room the size of the single largest packet (36 dwords, 144 bytes) to accommodate wraparound giving a grand total of 336 bytes Signed-off-by: Chris Wilson

[Intel-gfx] [CI 2/3] drm/i915: Trim the flush for the legacy request emission

At the start of request emission, we flush some space for the request, estimating the typical size for the request body. The tail is now much larger than the typical body, so we can shrink the flush slightly. Signed-off-by: Chris Wilson Reviewed-by: Joonas Lahtinen

[Intel-gfx] [CI 3/3] drm/i915: Trim the flush for the execlists request emission

At the start of request emission, we flush some space for the request, estimating the typical size for the request body. The common tail is now much larger than the typical body, so we can shrink the flush substantially. Signed-off-by: Chris Wilson Reviewed-by: Joonas

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [CI,1/3] drm/i915: Bump reserved size for legacy gen8 semaphore emission

== Series Details == Series: series starting with [CI,1/3] drm/i915: Bump reserved size for legacy gen8 semaphore emission URL : https://patchwork.freedesktop.org/series/6523/ State : success == Summary == Series 6523v1 Series without cover letter

Re: [Intel-gfx] [PATCH] i915 suspend/resume_noirq instead of suspend_late/resume_early

On Wed, Apr 27, 2016 at 11:46:22AM -0700, Todd Brandt wrote: > I'd like to propose that we push the i915 suspend_late/resume_early code > into suspend_noirq/resume_noirq in order to reduce the total suspend time > by ~15ms. According to the comments, when i915_pm_suspend_late was first >

Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for Unduplicate CHV phy code (rev5)

On Wed, 2016-04-27 at 17:39 +0300, Tomi Sarvela wrote: > Hello, > > On Wednesday 27 April 2016 16:36:13 Ander Conselvan De Oliveira wrote: > > > Subgroup suspend-read-crc-pipe-a: > > > pass -> INCOMPLETE (hsw-gt2) > > > > dmesg ends with > > > > [ 505.669959]

Re: [Intel-gfx] [PATCH 07/10] drm/i915: Trim the flush for the legacy request emission

On to, 2016-04-28 at 17:24 +0100, Chris Wilson wrote: > At the start of request emission, we flush some space for the request, > estimating the typical size for the request body. The tail is now much > larger than the typical body, so we can shrink the flush slightly. > > Signed-off-by: Chris

Re: [Intel-gfx] [PATCH 03/10] drm/i915: Fix gen8 semaphores id for legacy mode

On 28/04/16 17:24, Chris Wilson wrote: With the introduction of a distinct engine->id vs the hardware id, we need to fix up the value we use for selecting the target engine when signaling a semaphore. Note that these values can be merged with engine->guc_id. So I broke something more with the

Re: [Intel-gfx] Could you merge the tsc patches directly from Len Brown's public repo?

Hi all, Since these tsc fixes blew up once already pretty bad I don't want to rush things. 4.7 merge window is also rather close, and then we'll sync up with whatever is in Len's tree. If there's still trouble after that, then we can take another look at cherry-picking patches over. But yeah I

Re: [Intel-gfx] [PATCH 15/21] drm/i915/slpc: Notification of Refresh Rate change

On Wed, Apr 27, 2016 at 06:10:59PM -0700, tom.orou...@intel.com wrote: > From: Sagar Arun Kamble > > This patch will inform GuC SLPC about changes in the refresh rate > due to Seamless DRRS. Refresh rate changes due to Static DRRS will > be notified via commit path. >

[Intel-gfx] [PATCH] drm/gem: support BO freeing without dev->struct_mutex

Finally all the core gem and a lot of drivers are entirely free of dev->struct_mutex depencies, and we can start to have an entirely lockless unref path. To make sure that no one who touches the core code accidentally breaks existing drivers which still require dev->struct_mutex I've made the

Re: [Intel-gfx] [PATCH] mfd: intel_soc_pmic_core: Terminate panel control GPIO lookup table correctly

On Fri, Apr 22, 2016 at 9:38 PM, wrote: > From: Ville Syrjälä > > GPIO lookup tables are supposed to be zero terminated. Let's do that > and avoid accidentally walking off the end. > > Cc: Shobhit Kumar >

Re: [Intel-gfx] [PATCH v2] drm/i915/execlists: Refactor common engine setup

On Fri, Apr 29, 2016 at 10:25:41AM +0100, Tvrtko Ursulin wrote: > Not the most elegant because all the hw access we have so far is in > engine->init_hw. Why can't we just make intel_engine_initialized > return false until the very last thing in engine constructors? The other thing I've been

Re: [Intel-gfx] [PATCH 11/12] drm/i915: Extend GET_APERTURE ioctl to report available map space

On Fri, Apr 29, 2016 at 11:56:28AM +0100, Tvrtko Ursulin wrote: > > On 29/04/16 11:39, Chris Wilson wrote: > >On Fri, Apr 29, 2016 at 11:26:45AM +0100, Tvrtko Ursulin wrote: > >> > >>On 29/04/16 11:18, Chris Wilson wrote: > >>>On Fri, Apr 29, 2016 at 11:06:49AM +0100, Tvrtko Ursulin wrote: >

Re: [Intel-gfx] [PATCH 11/12] drm/i915: Extend GET_APERTURE ioctl to report available map space

On 28/04/16 11:24, Chris Wilson wrote: On Thu, Apr 28, 2016 at 10:30:32AM +0100, Tvrtko Ursulin wrote: On 26/04/16 10:44, Chris Wilson wrote: On Mon, Apr 25, 2016 at 03:51:09PM +0100, Tvrtko Ursulin wrote: On 25/04/16 11:35, Ankitprasad Sharma wrote: On Thu, 2016-04-21 at 15:59 +0100,

Re: [Intel-gfx] [PATCH v2] drm/i915/execlists: Refactor common engine setup

On 29/04/16 10:39, Chris Wilson wrote: On Fri, Apr 29, 2016 at 10:25:41AM +0100, Tvrtko Ursulin wrote: On 29/04/16 10:15, Chris Wilson wrote: diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c index 2e0eaa9fa240..2c94072ab085 100644 ---

Re: [Intel-gfx] [PATCHv2 1/5] drm: Introduce the blend-func property

On Fri, Apr 29, 2016 at 02:59:13PM +0530, Vandita Kulkarni wrote: > From: Damien Lespiau > > We'd like to be able to program the blending modes of display planes. > Ville suggested to use something similar to the GL blend states, which > does seem like a good idea. > >

Re: [Intel-gfx] [PATCH v2] drm/i915/execlists: Refactor common engine setup

On Fri, Apr 29, 2016 at 10:50:02AM +0100, Tvrtko Ursulin wrote: > > On 29/04/16 10:39, Chris Wilson wrote: > >On Fri, Apr 29, 2016 at 10:25:41AM +0100, Tvrtko Ursulin wrote: > >>On 29/04/16 10:15, Chris Wilson wrote: > >>>diff --git a/drivers/gpu/drm/i915/intel_lrc.c >

Re: [Intel-gfx] [PATCH v2] drm/i915/execlists: Refactor common engine setup

On 29/04/16 11:00, Chris Wilson wrote: On Fri, Apr 29, 2016 at 10:50:02AM +0100, Tvrtko Ursulin wrote: On 29/04/16 10:39, Chris Wilson wrote: On Fri, Apr 29, 2016 at 10:25:41AM +0100, Tvrtko Ursulin wrote: On 29/04/16 10:15, Chris Wilson wrote: diff --git a/drivers/gpu/drm/i915/intel_lrc.c

Re: [Intel-gfx] [PATCH 11/12] drm/i915: Extend GET_APERTURE ioctl to report available map space

On 29/04/16 11:39, Chris Wilson wrote: On Fri, Apr 29, 2016 at 11:26:45AM +0100, Tvrtko Ursulin wrote: On 29/04/16 11:18, Chris Wilson wrote: On Fri, Apr 29, 2016 at 11:06:49AM +0100, Tvrtko Ursulin wrote: I don't get it - if we are adding something why not add it in a way that makes it

Re: [Intel-gfx] [PATCH] drm/i915/lvds: do not set border bits when panel fitter is not enabled

On Fri, Apr 29, 2016 at 01:12:33PM +0300, Ville Syrjälä wrote: > On Fri, Apr 29, 2016 at 12:36:35PM +0300, Jani Nikula wrote: > > We also don't read the border bits in i9xx_get_pfit_config() when the > > panel fitter is not enabled, causing the state checker warning: > > > >

Re: [Intel-gfx] [PATCH] drm/i915/lvds: do not set border bits when panel fitter is not enabled

On Fri, Apr 29, 2016 at 12:36:35PM +0300, Jani Nikula wrote: > We also don't read the border bits in i9xx_get_pfit_config() when the > panel fitter is not enabled, causing the state checker warning: > > [drm:intel_pipe_config_compare [i915]] *ERROR* mismatch in > gmch_pfit.lvds_border_bits

[Intel-gfx] ✗ Fi.CI.BAT: failure for Support blending modes of display planes (rev2)

== Series Details == Series: Support blending modes of display planes (rev2) URL : https://patchwork.freedesktop.org/series/2582/ State : failure == Summary == Series 2582v2 Support blending modes of display planes http://patchwork.freedesktop.org/api/1.0/series/2582/revisions/2/mbox/ Test

Re: [Intel-gfx] [PATCH 11/12] drm/i915: Extend GET_APERTURE ioctl to report available map space

On 29/04/16 11:18, Chris Wilson wrote: On Fri, Apr 29, 2016 at 11:06:49AM +0100, Tvrtko Ursulin wrote: I don't get it - if we are adding something why not add it in a way that makes it clear and self-contained - what is the downside of what I propose to meet such resistance? You're

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/gem: support BO freeing without dev->struct_mutex

== Series Details == Series: drm/gem: support BO freeing without dev->struct_mutex URL : https://patchwork.freedesktop.org/series/6527/ State : failure == Summary == Series 6527v1 drm/gem: support BO freeing without dev->struct_mutex

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/lvds: do not set border bits when panel fitter is not enabled

== Series Details == Series: drm/i915/lvds: do not set border bits when panel fitter is not enabled URL : https://patchwork.freedesktop.org/series/6530/ State : success == Summary == Series 6530v1 drm/i915/lvds: do not set border bits when panel fitter is not enabled

Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for drm/gem: support BO freeing without dev->struct_mutex

On Fri, Apr 29, 2016 at 11:18:18AM -, Patchwork wrote: > == Series Details == > > Series: drm/gem: support BO freeing without dev->struct_mutex > URL : https://patchwork.freedesktop.org/series/6527/ > State : failure > > == Summary == > > Series 6527v1 drm/gem: support BO freeing without

Re: [Intel-gfx] [PATCH 11/12] drm/i915: Extend GET_APERTURE ioctl to report available map space

On Fri, Apr 29, 2016 at 11:06:49AM +0100, Tvrtko Ursulin wrote: > I don't get it - if we are adding something why not add it in a way > that makes it clear and self-contained - what is the downside of > what I propose to meet such resistance? You're suggesting to add a field I'm not going to use.

Re: [Intel-gfx] [PATCH v2] drm/i915/execlists: Refactor common engine setup

On Fri, Apr 29, 2016 at 11:11:20AM +0100, Tvrtko Ursulin wrote: > > On 29/04/16 11:00, Chris Wilson wrote: > >On Fri, Apr 29, 2016 at 10:50:02AM +0100, Tvrtko Ursulin wrote: > >> > >>On 29/04/16 10:39, Chris Wilson wrote: > >>>On Fri, Apr 29, 2016 at 10:25:41AM +0100, Tvrtko Ursulin wrote: >

Re: [Intel-gfx] [PATCH 02/10] drm/i915: Fix ordering of sanitize ppgtt and sanitize execlists

On to, 2016-04-28 at 17:24 +0100, Chris Wilson wrote: > The i915.enable_ppgtt option depends upon the state of > i915.enable_execlists option - so we need to sanitize execlists first. > Reviewed-by: Joonas Lahtinen > Signed-off-by: Chris Wilson

[Intel-gfx] [CI 6/7] drm/i915: Enable semaphores for legacy submission on gen8

We have sufficient evidence from igt to support that semaphores are in a working state. Enabling semaphores now for legacy provides a better comparison of execlists against legacy ring submission. Signed-off-by: Chris Wilson Acked-by: Daniel Vetter

[Intel-gfx] [CI 7/7] drm/i915: Enable legacy/semaphores for CI

--- drivers/gpu/drm/i915/intel_lrc.c | 4 1 file changed, 4 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c index d8763524319d..0713acb52ce4 100644 --- a/drivers/gpu/drm/i915/intel_lrc.c +++ b/drivers/gpu/drm/i915/intel_lrc.c @@ -260,10 +260,6

[Intel-gfx] [CI 2/7] drm/i915: Fix ordering of sanitize ppgtt and sanitize execlists

The i915.enable_ppgtt option depends upon the state of i915.enable_execlists option - so we need to sanitize execlists first. Signed-off-by: Chris Wilson Reviewed-by: Joonas Lahtinen --- drivers/gpu/drm/i915/i915_dma.c | 13

[Intel-gfx] [CI 5/7] drm/i915: Reload PD tables after semaphore wait on gen8

When the engine idles waiting upon a semaphore, it loses its pagetables and we must reload them before executing the batch. v2: Restrict w/a to non-RCS rings (RCS works correctly apparently). Signed-off-by: Chris Wilson Cc: Ville Syrjälä

[Intel-gfx] [CI 3/7] drm/i915: Fix gen8 semaphores id for legacy mode

With the introduction of a distinct engine->id vs the hardware id, we need to fix up the value we use for selecting the target engine when signaling a semaphore. Note that these values can be merged with engine->guc_id. Fixes: de1add360522c876c25ef2ab1c94bdb509ab Signed-off-by: Chris Wilson

[Intel-gfx] [CI 4/7] drm/i915: Fix serialisation of pipecontrol write vs semaphore signal

In order for the MI_SEMAPHORE_SIGNAL command to wait until after the pipecontrol writing the signal value is complete, we have to pause the CS inside the PIPE_CONTROL with the CS_STALL bit. Signed-off-by: Chris Wilson Reviewed-by: Ville Syrjälä

[Intel-gfx] [CI 1/7] drm/i915: Apply strongly ordered RCS breadcrumb to gen8/legacy

For legacy ringbuffer mode, we need the new ordered breadcrumb emission tried and tested on execlists in order to avoid the dreaded "missed interrupt" syndrome. A secondary advantage of the execlists method is that it writes to an arbitrary address, useful if one wants to write a breadcrumb

Re: [Intel-gfx] i915 ERRORs and WARN_ON()s

On Fri, Apr 29, 2016 at 04:27:08AM +0200, Florian Zumbiehl wrote: > Hi, > > > The Bugzilla at https://bugs.freedesktop.org is our tool of choice for > > tracking bugs in drm/i915. It's your choice to not create an account > > there, but please, don't expect us to work as a proxy between you and >

Re: [Intel-gfx] [PATCH 11/12] drm/i915: Extend GET_APERTURE ioctl to report available map space

On Fri, Apr 29, 2016 at 11:26:45AM +0100, Tvrtko Ursulin wrote: > > On 29/04/16 11:18, Chris Wilson wrote: > >On Fri, Apr 29, 2016 at 11:06:49AM +0100, Tvrtko Ursulin wrote: > >>I don't get it - if we are adding something why not add it in a way > >>that makes it clear and self-contained - what

[Intel-gfx] ✗ Fi.CI.BAT: warning for series starting with [CI,1/7] drm/i915: Apply strongly ordered RCS breadcrumb to gen8/legacy

== Series Details == Series: series starting with [CI,1/7] drm/i915: Apply strongly ordered RCS breadcrumb to gen8/legacy URL : https://patchwork.freedesktop.org/series/6532/ State : warning == Summary == Series 6532v1 Series without cover letter

[Intel-gfx] [PATCH i-g-t] tools/intel_watermark: Dump linetime watermarks on hsw/bdw

From: Ville Syrjälä Signed-off-by: Ville Syrjälä --- tools/intel_watermark.c | 46 -- 1 file changed, 36 insertions(+), 10 deletions(-) diff --git a/tools/intel_watermark.c

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [CI,1/5] drm/i915: Apply strongly ordered RCS breadcrumb to gen8/legacy

== Series Details == Series: series starting with [CI,1/5] drm/i915: Apply strongly ordered RCS breadcrumb to gen8/legacy URL : https://patchwork.freedesktop.org/series/6534/ State : success == Summary == Series 6534v1 Series without cover letter

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/2] drm/i915/lvds: separate border enable readout from panel fitter

== Series Details == Series: series starting with [1/2] drm/i915/lvds: separate border enable readout from panel fitter URL : https://patchwork.freedesktop.org/series/6535/ State : success == Summary == Series 6535v1 Series without cover letter

Re: [Intel-gfx] [PATCH 05/19] drm/i915: Unify unpin_work and mmio_work into flip_work.

On Tue, Apr 19, 2016 at 09:52:25AM +0200, Maarten Lankhorst wrote: > Rename intel_unpin_work to intel_flip_work and use it for mmio flips > and unpinning. Use flip_queued_req to hold the wait request in the > mmio case, and the vblank counter from intel_crtc_get_vblank_counter. > > Signed-off-by:

[Intel-gfx] [PATCH 1/2] drm/i915/lvds: separate border enable readout from panel fitter

The LVDS border enable is independent from the panel fitter. Move the readout of the "border bits" from i9xx_get_pfit_config() to intel_lvds_get_config(), where it will be read if LVDS is enabled even if the panel fitter is not. This fixes the state checker warning:

[Intel-gfx] [PATCH 2/2] drm/i915: do not set border enable software state for VLV/CHV

VLV/CHV use intel_gmch_panel_fitting() for eDP and DSI. They don't use the border enable software state for anything, so don't set it either. This should avoid a state checker warning on lvds_border_bits, although one hasn't been spotted in the wild. Signed-off-by: Jani Nikula

Re: [Intel-gfx] [PATCH 2/2] drm/i915: do not set border enable software state for VLV/CHV

On Fri, Apr 29, 2016 at 03:34:03PM +0300, Jani Nikula wrote: > VLV/CHV use intel_gmch_panel_fitting() for eDP and DSI. They don't use > the border enable software state for anything, so don't set it > either. This should avoid a state checker warning on lvds_border_bits, > although one hasn't been

[Intel-gfx] [PATCH i-g-t 2/2] autotools, assembler: Fix check target for tests in assembler.

assembler suffers from the same issue as lib/tests, adjust it so it allows us to do a check. Have to make autotools happy by having an empty Makefile.am. Signed-off-by: Marius Vlad --- assembler/Makefile.am | 108 -

[Intel-gfx] [PATCH i-g-t 1/2] autotools: Check target requires to a have the list of tests built.

We need to have the test list generated before running the check target. Migrated igt_command_line.sh to tests/ from lib/tests/, which allows to building the tests and execute the script. This would allow cleaning followed by a make check. Signed-off-by: Marius Vlad ---

Re: [Intel-gfx] [PATCH 1/2] drm/i915/lvds: separate border enable readout from panel fitter

On Fri, Apr 29, 2016 at 03:34:02PM +0300, Jani Nikula wrote: > The LVDS border enable is independent from the panel fitter. Move the > readout of the "border bits" from i9xx_get_pfit_config() to > intel_lvds_get_config(), where it will be read if LVDS is enabled even > if the panel fitter is not.

[Intel-gfx] [CI 2/5] drm/i915: Fix ordering of sanitize ppgtt and sanitize execlists

The i915.enable_ppgtt option depends upon the state of i915.enable_execlists option - so we need to sanitize execlists first. Signed-off-by: Chris Wilson Reviewed-by: Joonas Lahtinen --- drivers/gpu/drm/i915/i915_dma.c | 13

[Intel-gfx] [CI 5/5] drm/i915: Reload PD tables after semaphore wait on gen8

When the engine idles waiting upon a semaphore, it loses its pagetables and we must reload them before executing the batch. v2: Restrict w/a to non-RCS rings (RCS works correctly apparently). Signed-off-by: Chris Wilson Cc: Ville Syrjälä

[Intel-gfx] [CI 1/5] drm/i915: Apply strongly ordered RCS breadcrumb to gen8/legacy

For legacy ringbuffer mode, we need the new ordered breadcrumb emission tried and tested on execlists in order to avoid the dreaded "missed interrupt" syndrome. A secondary advantage of the execlists method is that it writes to an arbitrary address, useful if one wants to write a breadcrumb

[Intel-gfx] [CI 3/5] drm/i915: Fix gen8 semaphores id for legacy mode

With the introduction of a distinct engine->id vs the hardware id, we need to fix up the value we use for selecting the target engine when signaling a semaphore. Note that these values can be merged with engine->guc_id. Fixes: de1add360522c876c25ef2ab1c94bdb509ab Signed-off-by: Chris Wilson

[Intel-gfx] [CI 4/5] drm/i915: Fix serialisation of pipecontrol write vs semaphore signal

In order for the MI_SEMAPHORE_SIGNAL command to wait until after the pipecontrol writing the signal value is complete, we have to pause the CS inside the PIPE_CONTROL with the CS_STALL bit. Signed-off-by: Chris Wilson Reviewed-by: Ville Syrjälä

Re: [Intel-gfx] [PATCH] drm/i915/lvds: do not set border bits when panel fitter is not enabled

On Fri, 29 Apr 2016, Ville Syrjälä wrote: > On Fri, Apr 29, 2016 at 01:12:33PM +0300, Ville Syrjälä wrote: >> On Fri, Apr 29, 2016 at 12:36:35PM +0300, Jani Nikula wrote: >> > We also don't read the border bits in i9xx_get_pfit_config() when the >> > panel fitter is

[Intel-gfx] [PATCH i-g-t] tools/intel_reg_decode: drop confusing use of IS_965()

Unlike in the kernel driver coding style, IS_965() matches the platform and all subsequent ones. Replace IS_965() with suitable but less confusing alternatives. Most occurences are on code paths that only get called for gens 2, 3 and 4, so replace those with IS_GEN4(). In the one other call site

Re: [Intel-gfx] [PATCH v2 3/5] drm/i915/guc: don't spinwait if the GuC's workqueue is full

On 27/04/16 19:03, Dave Gordon wrote: Rather than wait to see whether more space becomes available in the GuC submission workqueue, we can just return -EAGAIN and let the caller try again in a little while. This gets rid of an uninterruptable sleep in the polling code :) We'll also add a

Re: [Intel-gfx] [PATCH 2/2] drm/i915: do not set border enable software state for VLV/CHV

On Fri, 29 Apr 2016, Ville Syrjälä wrote: > On Fri, Apr 29, 2016 at 03:34:03PM +0300, Jani Nikula wrote: >> VLV/CHV use intel_gmch_panel_fitting() for eDP and DSI. They don't use >> the border enable software state for anything, so don't set it >> either. This

[Intel-gfx] [PATCH 2/2] drm/i915: Add a FIXME about crtc !active vs. watermarks

From: Ville Syrjälä When the crtc is enabled but !active, we should still compute the watermarks as if the planes were visible. That would make it more likely that the we can later transition to active without errors. Add a FIXME to remind people that we're doing

[Intel-gfx] [PATCH i-g-t] lib/intel_chipset: drop unused IS_9XX()

It's also confusing as the style differs from the kernel (exact platform in the kernel vs. the platform and any later ones in igt). Signed-off-by: Jani Nikula --- lib/intel_chipset.h | 8 1 file changed, 8 deletions(-) diff --git a/lib/intel_chipset.h

[Intel-gfx] [PATCH v2 2/2] drm/i915: Render decompression support for Gen9 and above

This patch includes enabling render decompression (RC) after checking all the requirements (format, tiling, rotation etc.). TODO: 1. Disable stereo 3D when render decomp is enabled (bit 7:6) 2. Render decompression must not be used in VTd pass-through mode 3. Program hashing select CHICKEN_MISC1

[Intel-gfx] [PATCH 1/2] drm/i915: Calculate IPS linetime watermark based on future cdclk

From: Ville Syrjälä Use the cdclk we're going to be using when the pipe gets enabled to compute the IPS linetime watermark. The current cdclk frequency is irrelevant at this point since it can still change. Cc: Maarten Lankhorst

[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [1/2] drm: Add aux plane verification in addFB2 (rev2)

== Series Details == Series: series starting with [1/2] drm: Add aux plane verification in addFB2 (rev2) URL : https://patchwork.freedesktop.org/series/4641/ State : failure == Summary == CC [M] drivers/net/ethernet/intel/igb/e1000_nvm.o CC [M]

Re: [Intel-gfx] [PATCH v2 2/2] drm/i915: Render decompression support for Gen9 and above

On Fri, Apr 29, 2016 at 08:27:00PM +0530, Vandana Kannan wrote: > This patch includes enabling render decompression (RC) after checking > all the requirements (format, tiling, rotation etc.). > > TODO: > 1. Disable stereo 3D when render decomp is enabled (bit 7:6) > 2. Render decompression must

Re: [Intel-gfx] [PATCH v2 2/5] drm/i915/guc: pass request (not client) to i915_guc_{wq_check_space, submit}()

On 27/04/16 19:03, Dave Gordon wrote: The knowledge of how to derive the relevant client from the request should be localised within i915_guc_submission.c; the LRC code shouldn't have to know about the internal details of the GuC submission process. And all the information the GuC code needs

Re: [Intel-gfx] [PATCH v2 1/5] drm/i915/guc: add enable_guc_loading parameter

Hi, On 27/04/16 19:03, Dave Gordon wrote: Split the function of "enable_guc_submission" into two separate options. The new one ("enable_guc_loading") controls only the *fetching and loading* of the GuC firmware image. The existing one is redefined to control only the *use* of the GuC for

Re: [Intel-gfx] [PATCH] prime_mmap_kms: show case dma-buf new API and processes restrictions

On Mon, Apr 25, 2016 at 11:07:48AM -0300, Tiago Vignatti wrote: > dma-buf new API consists of: > > - mmap(dma_buf_fd): the ability to map a dma-buf file-descriptor to the > user-space, and most importantly, to actually write on the mapped pointer. > Worth to note that the Direct Rendering Manager

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/2] drm/i915: Calculate IPS linetime watermark based on future cdclk

== Series Details == Series: series starting with [1/2] drm/i915: Calculate IPS linetime watermark based on future cdclk URL : https://patchwork.freedesktop.org/series/6544/ State : success == Summary == Series 6544v1 Series without cover letter

Re: [Intel-gfx] [PATCH v2 3/5] drm/i915/guc: don't spinwait if the GuC's workqueue is full

One late comment: On 27/04/16 19:03, Dave Gordon wrote: Rather than wait to see whether more space becomes available in the GuC submission workqueue, we can just return -EAGAIN and let the caller try again in a little while. This gets rid of an uninterruptable sleep in the polling code :)

Re: [Intel-gfx] [PATCH v2 4/5] drm/i915/guc: rework guc_add_workqueue_item()

On Fri, Apr 29, 2016 at 04:44:24PM +0100, Tvrtko Ursulin wrote: > > On 27/04/16 19:03, Dave Gordon wrote: > >Mostly little optimisations; for instance, if the driver is correctly > >following the submission protocol, the "out of space" condition is > >impossible, so the previous runtime WARN_ON()

Re: [Intel-gfx] [PATCH v2 4/5] drm/i915/guc: rework guc_add_workqueue_item()

On 27/04/16 19:03, Dave Gordon wrote: Mostly little optimisations; for instance, if the driver is correctly following the submission protocol, the "out of space" condition is impossible, so the previous runtime WARN_ON() is promoted to a GEM_BUG_ON() for a more dramatic effect in development

[Intel-gfx] Intel eDP and fixed_mode probing/initialization

Hoping someone can point me in the right direction to understanding how intel_connector->panel.fixed_mode gets probed, as it's referenced in function "intel_dp_mode_valid" at drivers/gpu/drm/i915/intel_dp.c. I am working with a panel hooked up via DSUB to a port that is internally wired as eDP-1.

[Intel-gfx] [PATCH i-g-t] tools: Add intel_dp_compliance for DisplayPort 1.2 compliance automation

This is the userspace component of the Displayport Compliance testing software required for compliance testing of the I915 Display Port driver. This must be running in order to successfully complete Display Port compliance testing. This app and the kernel code that accompanies it has been written

[Intel-gfx] [PATCH 5/5] drm/i915: Implement intel_dp_autotest_video_pattern function for DP Video pattern compliance tests

This video pattern test function gets invoked through the compliance test handler on a HPD short pulse if the test type is set to DP_TEST_VIDEO_PATTERN. This performs the DPCD registers reads to read the requested test pattern, video pattern resolution, frame rate and bits per color value. The

[Intel-gfx] [PATCH 1/5] drm/i915: Invoke the DP Compliance test request handler in the short pulse path

HPD Short pulse test requests occur for DP Compliance Link Training and Video Pattern tests.The DP Test request handler needs to be invoked by these tests in the short pulse path in order to support automated DP Compliance tests. Signed-off-by: Manasi Navare ---

[Intel-gfx] [PATCH 2/5] drm/i915: Disable the Link training automation support

Kernel does not have automation support for DP compliance Link training tests. So the Link Training test handler should return a TEST_NAK. Signed-off-by: Manasi Navare --- drivers/gpu/drm/i915/intel_dp.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff

[Intel-gfx] [PATCH 0/5] Add automation support for DP compliance Tests

This patch series adds the automation support for DP Compliance Tests for EDID and Video Pattern generation from CTS specification 1.2 Rev 1.1. Jim Bride (1): Add support for forcing 6 bpc on DP pipes. Manasi Navare (4): drm/i915: Invoke the DP Compliance test request handler in the short

[Intel-gfx] [PATCH 4/5] Add support for forcing 6 bpc on DP pipes.

From: Jim Bride For DP compliance we need to be able to control the output color type for the pipe associated with the DP port. To do this we rely on the intel_dp_test_force_bpc debugfs file and the associated value stored in struct intel_dp. If the debugfs file has a

[Intel-gfx] [PATCH 3/5] drm/i915: Fixes to support the DP Compliance EDID tests.

This patch addresses a few issues from the original patch for DP Compliance EDID test support submitted by Todd Previte Video Mode requested in the EDID test handler for the EDID Read test (CTS 4.2.2.3) should be set to PREFERRED as per the CTS spec. Intel connector status

  1   2   >