[Intel-gfx] ✗ Fi.CI.BAT: warning for Prep. for DP audio MST support (rev11)

== Series Details == Series: Prep. for DP audio MST support (rev11) URL : https://patchwork.freedesktop.org/series/11129/ State : warning == Summary == Series 11129v11 Prep. for DP audio MST support https://patchwork.freedesktop.org/api/1.0/series/11129/revisions/11/mbox/ Test

[Intel-gfx] [PATCH v7 5/5] drm/i915: start adding dp mst audio

From: Libin Yang (This patch is developed by Dave Airlie originally) This patch adds support for DP MST audio in i915. Enable audio codec when DP MST is enabled if has_audio flag is set. Disable audio codec when DP MST is disabled if has_audio

[Intel-gfx] [PATCH v7 1/5] drm/i915: Standardize port type for DVO encoders

From: "Pandiyan, Dhinakaran" Changing the return type from 'char' to 'enum port' in intel_dvo_port_name() makes it easier to later move the port information to intel_encoder. In addition, the port type conforms to what we have elsewhere. Removing the last

[Intel-gfx] [PATCH v7 3/5] drm/i915: Switch to using port stored in intel_encoder

From: "Pandiyan, Dhinakaran" Now that we have the port enum stored in intel_encoder, use that instead of dereferencing intel_dig_port. Saves us a few locals. struct intel_encoder variables have been renamed to be consistent and convey type information. v2: Fix

[Intel-gfx] [PATCH v7 4/5] drm/i915: Move audio_connector to intel_encoder

From: "Pandiyan, Dhinakaran" With DP MST, a digital_port can carry more than one audio stream. Hence, more than one audio_connector needs to be attached to intel_digital_port in such cases. However, each stream is associated with an unique encoder. So, instead of

[Intel-gfx] [PATCH v7 2/5] drm/i915: Store port enum in intel_encoder

From: "Pandiyan, Dhinakaran" Storing the port enum in intel_encoder makes it convenient to know the port attached to an encoder. Moving the port information up from intel_digital_port to intel_encoder avoids unecessary intel_digital_port access and handles MST

[Intel-gfx] [PATCH v7 0/5] Prep. for DP audio MST support

This series lays the groundwork for more DP MST audio work that will follow. v7: Added R-B tags and rebased. v6: Modified the return type for a helper that returns port in intel_dvo.c v5: Really renamed the port enum member from 'attached_port' to 'port' Rebased on atomic changes. v4: Fixed

[Intel-gfx] [PATCH] tests/kms_psr_sink_crc: commit before querying mode

From: Mika Kuoppala Commit to a mode before querying it. Tested-by: Rodrigo Vivi References: https://bugs.freedesktop.org/show_bug.cgi?id=97172 Cc: Maarten Lankhorst Signed-off-by: Mika Kuoppala

[Intel-gfx] ✗ Fi.CI.BAT: warning for drm: Fix typo in encoder docs

== Series Details == Series: drm: Fix typo in encoder docs URL : https://patchwork.freedesktop.org/series/12666/ State : warning == Summary == Series 12666v1 drm: Fix typo in encoder docs https://patchwork.freedesktop.org/api/1.0/series/12666/revisions/1/mbox/ Test kms_pipe_crc_basic:

[Intel-gfx] [PATCH] drm: Fix typo in encoder docs

Corrected typo in bridge and encoder comparison. Also, added a one-line encoder description from the previous documentation. Cc: Daniel Vetter Cc: Archit Taneja Signed-off-by: Dhinakaran Pandiyan ---

Re: [Intel-gfx] [PATCH v3 4/9] drm/i915: Decode system memory bandwidth

Hi Em Sex, 2016-09-09 às 13:31 +0530, Kumar, Mahesh escreveu: > From: Mahesh Kumar > > This patch adds support to decode system memory bandwidth > which will be used for arbitrated display memory percentage > calculation in GEN9 based system. This is not a complete

Re: [Intel-gfx] [i915] monitor is not detected unless it was active during boot

I checked both monitors, on displayport they work, on HDMI they share the same trouble. An interesting observation is that when plug the monitor into another system which has an older nvidia card using nouveau (only HDMI is available, card is too old for displayport). It seems that the i2c

Re: [Intel-gfx] [PATCH 1/7] drm/i915: Update i915.reset to handle engine resets

On Mon, Sep 19, 2016 at 04:30:13PM +0100, Matthew Auld wrote: > From: "arun.siluv...@linux.intel.com" > > In preparation for engine reset work update this parameter to handle more > than one type of reset. Default at the moment is still full gpu reset. This is not

Re: [Intel-gfx] [PATCH 3/7] drm/i915/tdr: Add support for per engine reset recovery

On Mon, Sep 19, 2016 at 04:30:15PM +0100, Matthew Auld wrote: > From: "arun.siluv...@linux.intel.com" > > This change implements support for per-engine reset as an initial, less > intrusive hang recovery option to be attempted before falling back to the > legacy

Re: [Intel-gfx] [PATCH 2/7] drm/i915/tdr: Modify error handler for per engine hang recovery

On Mon, Sep 19, 2016 at 04:30:14PM +0100, Matthew Auld wrote: > From: "arun.siluv...@linux.intel.com" > > This is a preparatory patch which modifies error handler to do per engine > hang recovery. The actual patch which implements this sequence follows > later in

Re: [Intel-gfx] [i915] monitor is not detected unless it was active during boot

The previous messages are about using the HDMI connection of my monitor on the HDMI 2.0->DP bridge (whatever the formal name may be) of my motherboard, Using the HDMI 1.4 connection of my motherboard: [ 55.744581] [drm:intel_get_hpd_pins] hotplug event received, stat 0x0040, dig

Re: [Intel-gfx] Skylake graphics regression: projector failure with 4.8-rc3

On Mon, 2016-09-19 at 08:09 -0700, James Bottomley wrote: > On Sun, 2016-09-18 at 13:35 +0200, Thorsten Leemhuis wrote: > > Hi! James & Paulo: What's the current status of this? > > No, the only interaction has been the suggestion below for a revert, > which didn't fix the problem. > > > Was

Re: [Intel-gfx] [i915] monitor is not detected unless it was active during boot

Hi Maarten, Is this the Debug message when you are connected to the external DP Port or the HDMI port? I want to know if the problem is with the native DP connector or LSPCON? Also could you send the log that has the Video Bios Table information (VBT) information? Manasi From: Intel-gfx

Re: [Intel-gfx] [i915] monitor is not detected unless it was active during boot

And the normal output at bootup: [2.826131] [drm:drm_helper_probe_single_connector_modes] [CONNECTOR:48:DP-2] [2.826135] [drm:intel_dp_detect] [CONNECTOR:48:DP-2] [2.826645] [drm:intel_dp_get_dpcd] DPCD: 12 14 c4 01 01 15 00 01 00 00 04 00 0f 00 00 [2.827032]

[Intel-gfx] [i915] monitor is not detected unless it was active during boot

Hi, I have a monitor, that when connected a skylake system, doesn't ever come up when hotplugging or after resume. The "bios" seems to not have problems bringing it up, even at the native 3840x2160 resolution, and when it works, all modes are correctly read (checked via xrandr). I tried both the

Re: [Intel-gfx] [PATCH v3 2/9] drm/i915/skl+: use linetime latency instead of ddb size

Em Seg, 2016-09-19 às 15:19 -0300, Paulo Zanoni escreveu: > Em Sex, 2016-09-09 às 13:30 +0530, Kumar, Mahesh escreveu: > > > > From: Mahesh Kumar > > > > This patch make changes to use linetime latency instead of > > allocated > > DDB size during plane watermark

Re: [Intel-gfx] [PATCH v3 2/9] drm/i915/skl+: use linetime latency instead of ddb size

Em Sex, 2016-09-09 às 13:30 +0530, Kumar, Mahesh escreveu: > From: Mahesh Kumar > > This patch make changes to use linetime latency instead of allocated > DDB size during plane watermark calculation in switch case, This is > required to implement new DDB allocation

[Intel-gfx] ✗ Fi.CI.BAT: warning for drm/i915/bxt: Broxton decoupled MMIO (rev2)

== Series Details == Series: drm/i915/bxt: Broxton decoupled MMIO (rev2) URL : https://patchwork.freedesktop.org/series/12028/ State : warning == Summary == Series 12028v2 drm/i915/bxt: Broxton decoupled MMIO https://patchwork.freedesktop.org/api/1.0/series/12028/revisions/2/mbox/ Test

Re: [Intel-gfx] [PATCH v3 5/5] drm/i915/dp/mst: Add support for upfront link training for DP MST

On Mon, Sep 19, 2016 at 10:03:29AM -0700, Jim Bride wrote: > On Thu, Sep 15, 2016 at 12:25:51PM -0700, Manasi Navare wrote: > > On Thu, Sep 15, 2016 at 10:48:17AM -0700, Pandiyan, Dhinakaran wrote: > > > On Tue, 2016-09-13 at 18:08 -0700, Manasi Navare wrote: > > > > From: Jim Bride

[Intel-gfx] [PATCH v2] drm/i915/bxt: Broxton decoupled MMIO

Decoupled MMIO is an alternative way to access forcewake domain registers, which requires less cycles and avoids frequent software forcewake. v2: - Moved platform check out of the function and got rid of duplicate functions to find out decoupled power domain. - Added a check for forcewake already

Re: [Intel-gfx] [PATCH v3 5/5] drm/i915/dp/mst: Add support for upfront link training for DP MST

On Thu, Sep 15, 2016 at 12:25:51PM -0700, Manasi Navare wrote: > On Thu, Sep 15, 2016 at 10:48:17AM -0700, Pandiyan, Dhinakaran wrote: > > On Tue, 2016-09-13 at 18:08 -0700, Manasi Navare wrote: > > > From: Jim Bride > > > > > > Add upfront link training to

Re: [Intel-gfx] [PATCH] drm/i915/bxt: Broxton decoupled MMIO

On Tuesday 06 September 2016 12:06 PM, Chris Wilson wrote: On Tue, Sep 06, 2016 at 10:54:14AM +0530, Praveen Paneri wrote: Decoupled MMIO is an alternative way to access forcewake domain registers, which requires less cycles and avoids frequent software forcewake. How about when forcewake

[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [1/7] drm/i915: Update i915.reset to handle engine resets

== Series Details == Series: series starting with [1/7] drm/i915: Update i915.reset to handle engine resets URL : https://patchwork.freedesktop.org/series/12651/ State : failure == Summary == Series 12651v1 Series without cover letter

Re: [Intel-gfx] [PATCH i-g-t] tests: kms_pipe_color: fix ctm tests

On Mon, 19 Sep 2016, Lionel Landwerlin wrote: > Some of the Intel platforms have odd numbers of LUT entries and we > need to tests a couple of values around the expected result. Bring > back the CRC equal function we need that doesn't trigger an assert > right away,

[Intel-gfx] [PATCH i-g-t] tests: kms_pipe_color: fix ctm tests

Some of the Intel platforms have odd numbers of LUT entries and we need to tests a couple of values around the expected result. Bring back the CRC equal function we need that doesn't trigger an assert right away, while we still assert if we can't find a correct result in the outter loop.

Re: [Intel-gfx] [PATCH 3/6] drm/i915: keep declarations in i915_drv.h

On to, 2016-09-15 at 16:28 +0300, Jani Nikula wrote: > Fix sparse warnings: > > drivers/gpu/drm/i915/i915_drv.c:1179:5: warning: symbol > 'i915_driver_load' was not declared. Should it be static? > > drivers/gpu/drm/i915/i915_drv.c:1267:6: warning: symbol > 'i915_driver_unload' was not declared.

Re: [Intel-gfx] [PATCH 11/18] drm/i915: Record space required for request emission

On ma, 2016-09-19 at 12:32 +0100, Chris Wilson wrote: > On Mon, Sep 19, 2016 at 01:47:30PM +0300, Joonas Lahtinen wrote: > > On ke, 2016-09-14 at 07:52 +0100, Chris Wilson wrote: > > > @@ -2677,8 +2681,21 @@ static void intel_ring_default_vfuncs(struct > > > drm_i915_private *dev_priv, > > >

Re: [Intel-gfx] [PATCH 15/18] drm/i915: Reserve space in the global seqno during request allocation

On ma, 2016-09-19 at 18:35 +0300, Jani Nikula wrote: > > On Mon, 19 Sep 2016, Joonas Lahtinen > > wrote: > > > > On ke, 2016-09-14 at 07:52 +0100, Chris Wilson wrote: > > > > > > +static int reserve_global_seqno(struct drm_i915_private *i915) > > >  { > > > -

Re: [Intel-gfx] [PATCH 07/18] drm/i915: Restore nonblocking awaits for modesetting

Maarten, could you give this a look? On ke, 2016-09-14 at 07:52 +0100, Chris Wilson wrote: > After combining the dma-buf reservation object and the GEM reservation > object, we lost the ability to do a nonblocking wait on the i915 request > (as we blocked upon the reservation object during

Re: [Intel-gfx] [PATCH 1/7] drm/i915: Update i915.reset to handle engine resets

On ma, 2016-09-19 at 16:30 +0100, Matthew Auld wrote: > From: "arun.siluv...@linux.intel.com" > I assume "From:" needs to be properly formatted just like "Signed-off-by:". So in all patches; From: Arun Siluvery Cover letters are

Re: [Intel-gfx] [PATCH 16/18] drm/i915: Enable multiple timelines

On ke, 2016-09-14 at 07:52 +0100, Chris Wilson wrote: > @@ -315,17 +304,42 @@ submit_notify(struct i915_sw_fence *fence, enum > i915_sw_fence_notify state) >  { >   struct drm_i915_gem_request *request = >   container_of(fence, typeof(*request), submit); > + struct

Re: [Intel-gfx] [PATCH v2 0/7] drm/i915: clean up dsi sequences

On Mon, 19 Sep 2016, Ville Syrjälä wrote: > On Mon, Sep 19, 2016 at 03:02:23PM +0300, Jani Nikula wrote: >> v2 of an old series, addressing issues pointed out by Ville. > > Entire series looks reasonable. Spec is vague, so hard to be 100% sure. We're about to find

Re: [Intel-gfx] [PATCH 15/18] drm/i915: Reserve space in the global seqno during request allocation

On Mon, 19 Sep 2016, Joonas Lahtinen wrote: > On ke, 2016-09-14 at 07:52 +0100, Chris Wilson wrote: >> +static int reserve_global_seqno(struct drm_i915_private *i915) >>  { >> -struct i915_gem_timeline *tl = _priv->gt.global_timeline; >> +struct

[Intel-gfx] [PATCH 5/7] drm/i915/tdr: Add engine reset count to error state

From: "arun.siluv...@linux.intel.com" Driver maintains count of how many times a given engine is reset, useful to capture this in error state also. It gives an idea of how engine is coping up with the workloads it is executing before this error state. v2 -

[Intel-gfx] [PATCH 3/7] drm/i915/tdr: Add support for per engine reset recovery

From: "arun.siluv...@linux.intel.com" This change implements support for per-engine reset as an initial, less intrusive hang recovery option to be attempted before falling back to the legacy full GPU reset recovery mode if necessary. This is only supported from

[Intel-gfx] [PATCH 6/7] drm/i915/tdr: Export reset count info to debugfs

From: "arun.siluv...@linux.intel.com" A new variable is added to export the reset counts to debugfs, this includes full gpu reset and engine reset count. This is useful for tests where they areexpected to trigger reset; these counts are checked before and after the

[Intel-gfx] [PATCH 2/7] drm/i915/tdr: Modify error handler for per engine hang recovery

From: "arun.siluv...@linux.intel.com" This is a preparatory patch which modifies error handler to do per engine hang recovery. The actual patch which implements this sequence follows later in the series. The aim is to prepare existing recovery function to adapt to

[Intel-gfx] [PATCH 4/7] drm/i915: Skip reset request if there is one already

From: Mika Kuoppala To perform engine reset we first disable engine to capture its state. This is done by issuing a reset request. Because we are reusing existing infrastructure, again when we actually reset an engine, reset function checks engine mask and issues

[Intel-gfx] [PATCH 7/7] drm/i915/tdr: Enable Engine reset and recovery support

From: "arun.siluv...@linux.intel.com" This feature is made available only from Gen8, for previous gen devices driver uses legacy full gpu reset. v2 - rebase Cc: Chris Wilson Cc: Mika Kuoppala

[Intel-gfx] [PATCH 1/7] drm/i915: Update i915.reset to handle engine resets

From: "arun.siluv...@linux.intel.com" In preparation for engine reset work update this parameter to handle more than one type of reset. Default at the moment is still full gpu reset. v2 - rebase Cc: Chris Wilson Cc: Mika Kuoppala

Re: [Intel-gfx] Skylake graphics regression: projector failure with 4.8-rc3

On Sun, 2016-09-18 at 13:35 +0200, Thorsten Leemhuis wrote: > Hi! James & Paulo: What's the current status of this? No, the only interaction has been the suggestion below for a revert, which didn't fix the problem. > Was this issue discussed elsewhere or even fixed in between? Just > asking,

Re: [Intel-gfx] [PATCH] drm: fix implicit declaration build error on ia64

On Fri, Sep 16, 2016 at 01:06:36PM +0300, Jani Nikula wrote: >drivers/gpu/drm/drm_dp_helper.c: In function 'drm_dp_downstream_debug': > >> drivers/gpu/drm/drm_dp_helper.c:551:2: error: implicit declaration of > >> function 'seq_printf' [-Werror=implicit-function-declaration] >

Re: [Intel-gfx] [PATCH 03/10] drm: Move all decl for drm_edid.c to drm_edid.h

On Tue, Sep 06, 2016 at 12:59:39PM -0400, Sean Paul wrote: > On Wed, Aug 31, 2016 at 12:09 PM, Daniel Vetter > wrote: > > Some were still left in drm_crtc.h. Also include drm_edid.h in the > > rst files. > > > > Signed-off-by: Daniel Vetter > >

Re: [Intel-gfx] [PATCH v2 0/7] drm/i915: clean up dsi sequences

On Mon, Sep 19, 2016 at 03:02:23PM +0300, Jani Nikula wrote: > v2 of an old series, addressing issues pointed out by Ville. Entire series looks reasonable. Spec is vague, so hard to be 100% sure. Reviewed-by: Ville Syrjälä > > BR, > Jani. > > Jani Nikula (7): >

Re: [Intel-gfx] [PATCH 15/18] drm/i915: Reserve space in the global seqno during request allocation

On ke, 2016-09-14 at 07:52 +0100, Chris Wilson wrote: > +static int reserve_global_seqno(struct drm_i915_private *i915) >  { > - struct i915_gem_timeline *tl = _priv->gt.global_timeline; > + struct i915_gem_timeline *tl = >gt.global_timeline; > + u32 next_seqno =

Re: [Intel-gfx] [PATCH 14/18] drm/i915: Create a unique name for the context

On ke, 2016-09-14 at 07:52 +0100, Chris Wilson wrote: > @@ -310,12 +311,21 @@ __create_hw_context(struct drm_device *dev, >   goto err_out; >   } else >   ret = DEFAULT_CONTEXT_HANDLE; Confusing indent, so add braces to above else and a newline here.

Re: [Intel-gfx] [PATCH 13/18] drm/i915: Move the global sync optimisation to the timeline

On ke, 2016-09-14 at 07:52 +0100, Chris Wilson wrote: > @@ -262,6 +263,12 @@ static int i915_gem_init_global_seqno(struct > drm_i915_private *dev_priv, >   for_each_engine(engine, dev_priv) >   intel_engine_init_global_seqno(engine, seqno); >   > + list_for_each_entry(tl,

Re: [Intel-gfx] [PATCH 05/10] drm/doc: Polish for drm_plane.[hc]

On Fri, Sep 02, 2016 at 03:00:38PM +0530, Archit Taneja wrote: > > > On 8/31/2016 9:39 PM, Daniel Vetter wrote: > > Big thing is untangling and carefully documenting the different uapi > > types of planes. I also sprinkled a few more cross references around > > to make this easier to discover. >

Re: [Intel-gfx] [PATCH 04/10] drm: Extract drm_plane.[hc]

On Tue, Sep 06, 2016 at 12:59:31PM -0400, Sean Paul wrote: > On Wed, Aug 31, 2016 at 12:09 PM, Daniel Vetter > wrote: > > Just pure code movement, cleanup and polish will happen in later > > patches. > > > > v2: Don't forget all the ioctl! To extract those cleanly I

[Intel-gfx] ✗ Fi.CI.BAT: warning for drm/i915: clean up dsi sequences

== Series Details == Series: drm/i915: clean up dsi sequences URL : https://patchwork.freedesktop.org/series/12640/ State : warning == Summary == Series 12640v1 drm/i915: clean up dsi sequences https://patchwork.freedesktop.org/api/1.0/series/12640/revisions/1/mbox/ Test kms_pipe_crc_basic:

Re: [Intel-gfx] [PATCH 1/2] drm/i915: Only shrink the unbound objects during freeze

On ma, 2016-09-19 at 09:38 +0100, Chris Wilson wrote: > On Mon, Sep 19, 2016 at 11:31:37AM +0300, Joonas Lahtinen wrote: > > > > On pe, 2016-09-16 at 20:23 +0100, Chris Wilson wrote: > > > > > >  int i915_gem_freeze_late(struct drm_i915_private *dev_priv) > > >  { > > > > > > > > > > > >  

Re: [Intel-gfx] [PATCH 12/18] drm/i915: Defer request emission

On ke, 2016-09-14 at 07:52 +0100, Chris Wilson wrote: > +static void gen8_emit_wa_tail(struct drm_i915_gem_request *request, u32 *out) >  { > - struct intel_ring *ring = request->ring; > - int ret; > - > - ret = intel_ring_begin(request, 6 + WA_TAIL_DWORDS); > - if (ret) > -

[Intel-gfx] [PATCH v2 6/7] drm/i915/bios: log about presence of DSI sequences we do not run

Leave behind some debugging clues in case some panels don't work properly. Signed-off-by: Jani Nikula --- drivers/gpu/drm/i915/intel_bios.c | 4 1 file changed, 4 insertions(+) diff --git a/drivers/gpu/drm/i915/intel_bios.c b/drivers/gpu/drm/i915/intel_bios.c index

[Intel-gfx] [PATCH v2 5/7] drm/i915/dsi: run backlight on/off sequences in panel enable/disable hooks

Based on the documentation alone, it's anyone's guess when exactly we should be running these sequences. Add them where it feels logical. The drm panel hooks don't currently offer us more granularity anyway. Signed-off-by: Jani Nikula ---

[Intel-gfx] [PATCH v2 4/7] drm/i915/dsi: update reset and power sequences in panel prepare/unprepare hooks

Based on the documentation alone, it's anyone's guess when exactly we should be running these sequences. Add power on/off sequences where they feel logical and update assert/deassert reset. The drm panel hooks don't currently offer us more granularity anyway. v2: update assert/deassert reset as

[Intel-gfx] [PATCH v2 7/7] drm/i915/dsi: double check element parsing against size if present

Be a little paranoid in case the specs change or something. Signed-off-by: Jani Nikula --- drivers/gpu/drm/i915/intel_dsi_panel_vbt.c | 8 1 file changed, 8 insertions(+) diff --git a/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c

[Intel-gfx] [PATCH v2 2/7] drm/i915/dsi: add debug logging to element execution

Just simple breadcrumbs for now. While at it, rename the i2c skip function. Signed-off-by: Jani Nikula --- drivers/gpu/drm/i915/intel_dsi_panel_vbt.c | 12 ++-- 1 file changed, 10 insertions(+), 2 deletions(-) diff --git

[Intel-gfx] [PATCH v2 3/7] drm/i915/dsi: add skip functions for spi and pmic elements

In sequence block v3 these are gracefully skipped anyway, but add the functions so we can have some debug breadcrumbs. v2: the pmic block is 15 bytes (Ville) Signed-off-by: Jani Nikula --- drivers/gpu/drm/i915/intel_dsi_panel_vbt.c | 16 1 file changed,

[Intel-gfx] [PATCH v2 1/7] drm/i915/dsi: don't debug log "missing" sequences

This is not interesting. They are not "missing", they are just not part of the VBT sequences for the panel. Signed-off-by: Jani Nikula --- drivers/gpu/drm/i915/intel_dsi_panel_vbt.c | 5 + 1 file changed, 1 insertion(+), 4 deletions(-) diff --git

[Intel-gfx] [PATCH v2 0/7] drm/i915: clean up dsi sequences

v2 of an old series, addressing issues pointed out by Ville. BR, Jani. Jani Nikula (7): drm/i915/dsi: don't debug log "missing" sequences drm/i915/dsi: add debug logging to element execution drm/i915/dsi: add skip functions for spi and pmic elements drm/i915/dsi: update reset and power

Re: [Intel-gfx] [PATCH 11/18] drm/i915: Record space required for request emission

On Mon, Sep 19, 2016 at 01:47:30PM +0300, Joonas Lahtinen wrote: > On ke, 2016-09-14 at 07:52 +0100, Chris Wilson wrote: > > @@ -2677,8 +2681,21 @@ static void intel_ring_default_vfuncs(struct > > drm_i915_private *dev_priv, > >   engine->reset_hw = reset_ring_common; > >   > >  

Re: [Intel-gfx] [PATCH 01/18] drm/i915: Support asynchronous waits on struct fence from i915_gem_request

On Wed, Sep 14, 2016 at 10:37:18AM +0300, Joonas Lahtinen wrote: > On ke, 2016-09-14 at 07:52 +0100, Chris Wilson wrote: > > + array = to_fence_array(fence); > > + for (i = 0; i < array->num_fences; i++) { > > + struct fence *child = array->fences[i]; > > + > > + if

[Intel-gfx] ✗ Fi.CI.BAT: warning for drm/i915: fix pwm increment setup

== Series Details == Series: drm/i915: fix pwm increment setup URL : https://patchwork.freedesktop.org/series/12636/ State : warning == Summary == Series 12636v1 drm/i915: fix pwm increment setup https://patchwork.freedesktop.org/api/1.0/series/12636/revisions/1/mbox/ Test

Re: [Intel-gfx] [PATCH v2] drm/i915 : Restore PWM_GRANULARITY after resume

nce) to record what (public, well-known) commit your patch series was built on] [Check https://git-scm.com/docs/git-format-patch for more information] url: https://github.com/0day-ci/linux/commits/Lee-Shawn-C/drm-i915-Restore-PWM_GRANULARITY-after-resume/20160919-180644 base:

Re: [Intel-gfx] [PATCH] drm/i915/backlight: setup backlight pwm alternate increment on backlight enable

nce) to record what (public, well-known) commit your patch series was built on] [Check https://git-scm.com/docs/git-format-patch for more information] url: https://github.com/0day-ci/linux/commits/Jani-Nikula/drm-i915-backlight-setup-backlight-pwm-alternate-increment-on-backlight-enable/20160

Re: [Intel-gfx] [PATCH 11/18] drm/i915: Record space required for request emission

On ke, 2016-09-14 at 07:52 +0100, Chris Wilson wrote: > @@ -1572,6 +1572,8 @@ static int gen8_emit_request(struct > drm_i915_gem_request *request) >   return intel_logical_ring_advance(request); >  } >   > +static const int gen8_emit_request_sz = 6 + WA_TAIL_DWORDS; Could argue these to be

Re: [Intel-gfx] [PATCH 10/18] drm/i915: Introduce a global_seqno for each request

On ke, 2016-09-14 at 07:52 +0100, Chris Wilson wrote: > @@ -465,8 +466,15 @@ i915_gem_request_await_request(struct > drm_i915_gem_request *to, >   return ret < 0 ? ret : 0; >   } >   > + if (from->global_seqno == 0) { Just use (!from->global_seqno) here too, for consistency.

[Intel-gfx] [PATCH 1/2] drm/i915/backlight: setup and cache pwm alternate increment value

This will also be needed later on when setting up the alternate increment in backlight enable. Cc: Shawn Lee Signed-off-by: Jani Nikula --- drivers/gpu/drm/i915/intel_drv.h | 1 + drivers/gpu/drm/i915/intel_panel.c | 14 +++--- 2 files

[Intel-gfx] [PATCH 2/2] drm/i915/backlight: setup backlight pwm alternate increment on backlight enable

From: Shawn Lee Backlight enable is supposed to do a full setup of the backlight. We were missing the PWM alternate increment bit in the south chicken registers on lpt+ pch. This potentially caused a PWM frequency change when the chicken register value was lost e.g. on

[Intel-gfx] [PATCH 0/2] drm/i915: fix pwm increment setup

CI got confused by all the patches flowing in the earlier thread, so resend. No changes. BR, Jani. Jani Nikula (1): drm/i915/backlight: setup and cache pwm alternate increment value Shawn Lee (1): drm/i915/backlight: setup backlight pwm alternate increment on backlight enable

Re: [Intel-gfx] [PATCH v2] drm/i915 : Restore PWM_GRANULARITY after resume

uto for convenience) to record what (public, well-known) commit your patch series was built on] [Check https://git-scm.com/docs/git-format-patch for more information] url: https://github.com/0day-ci/linux/commits/Lee-Shawn-C/drm-i915-Restore-PWM_GRANULARITY-after-resume/20160919-180644 base:

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915 : Restore PWM_GRANULARITY after resume (rev3)

== Series Details == Series: drm/i915 : Restore PWM_GRANULARITY after resume (rev3) URL : https://patchwork.freedesktop.org/series/12165/ State : success == Summary == Series 12165v3 drm/i915 : Restore PWM_GRANULARITY after resume

Re: [Intel-gfx] [PATCH] drm/i915 : Restore PWM_GRANULARITY after resume

Understood. Thanks! -Original Message- From: Nikula, Jani Sent: Monday, September 19, 2016 5:43 PM To: Lee, Shawn C ; intel-gfx@lists.freedesktop.org Cc: Lee, Shawn C Subject: Re: [PATCH] drm/i915 : Restore PWM_GRANULARITY after resume On

Re: [Intel-gfx] [PATCH v4] drm/i915/skl: New ddb allocation algorithm

Op 14-09-16 om 14:36 schreef Mahesh Kumar: > Hi, > There was an issue with transition WM, it was getting enabled & causing fifo > underrun. > I fixed the condition, After that tested kms_plane & not getting any underrun. > Please let me know if you see any other issue. > > Regards, > -Mahesh > >

Re: [Intel-gfx] [PATCH] drm/i915 : Restore PWM_GRANULARITY after resume

On Mon, 19 Sep 2016, "Lee, Shawn C" wrote: > From: "Lee, Shawn C" > > SPT_PWM_GRANULARITY (SOUTH_CHICKEN1, bit 0) controls the granularity > (minimum increment) of the PWM backlight control counter. PWM frequency > adjustment on 128 clock increments

[Intel-gfx] [PATCH] drm/i915 : Restore PWM_GRANULARITY after resume

From: "Lee, Shawn C" SPT_PWM_GRANULARITY (SOUTH_CHICKEN1, bit 0) controls the granularity (minimum increment) of the PWM backlight control counter. PWM frequency adjustment on 128 clock increments when this bit was 1. And 16 clock increments when it was 0. PWM frequency

Re: [Intel-gfx] [PATCH v2 1/2] drm/i915/backlight: setup and cache pwm alternate increment value

On Mon, 19 Sep 2016, "Lee, Shawn C" wrote: > PWM was enabled in bios. i915 driver will save max duty to > panel->backlight.max. > So *_hz_to_pwm will not be called if backlight.max not zero. And what difference does it make? BR, Jani. > > pch_ctl2 =

Re: [Intel-gfx] [PATCH v2 1/2] drm/i915/backlight: setup and cache pwm alternate increment value

PWM was enabled in bios. i915 driver will save max duty to panel->backlight.max. So *_hz_to_pwm will not be called if backlight.max not zero. pch_ctl2 = I915_READ(BLC_PWM_PCH_CTL2); panel->backlight.max = pch_ctl2 >> 16; if (!panel->backlight.max)

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

at: git://anongit.freedesktop.org/drm-intel tags/drm-intel-next-2016-09-19 for you to fetch changes up to 6e05f3d3b9298a56d6f1acb474a75cf14a17c31e: drm/i915: Update DRIVER_DATE to 20160919 (2016-09-19 09:26:08 +0200) - refactor

[Intel-gfx] Updated drm-intel-testing

Hi all, New -testing cycle with cool stuff: - refactor the sseu code (Imre) - refine guc dmesg output (Dave Gordon) - more vgpu work - more skl wm fixes (Lyude) - refactor dpll code in prep for upfront link training (Jim Bride et al) - consolidate all platform feature checks into

Re: [Intel-gfx] [PATCH 09/18] drm/i915: Wait first for submission, before waiting for request completion

On ke, 2016-09-14 at 07:52 +0100, Chris Wilson wrote: > +static long > +__i915_request_wait_for_submit(struct drm_i915_gem_request *request, > +    unsigned int flags, > +    long timeout) > +{ > + const int state = flags &

Re: [Intel-gfx] [PATCH v2] drm/i915 : Restore PWM_GRANULARITY after resume

On Mon, 19 Sep 2016, "Lee, Shawn C" wrote: > + if (HAS_PCH_LPT(dev_priv)) { > + mul = I915_READ(SOUTH_CHICKEN2); > + mul &= ~LPT_PWM_GRANULARITY; > + I915_WRITE(SOUTH_CHICKEN2, mul | > (panel->backlight.pwm_alternate_increment <<

Re: [Intel-gfx] [PATCH 1/2] drm/i915: Only shrink the unbound objects during freeze

On Mon, Sep 19, 2016 at 11:31:37AM +0300, Joonas Lahtinen wrote: > On pe, 2016-09-16 at 20:23 +0100, Chris Wilson wrote: > >  int i915_gem_freeze_late(struct drm_i915_private *dev_priv) > >  { > > >   struct drm_i915_gem_object *obj; > > @@ -4692,7 +4705,8 @@ int i915_gem_freeze_late(struct

Re: [Intel-gfx] [PATCH v2] drm/i915 : Restore PWM_GRANULARITY after resume

On Mon, 19 Sep 2016, "Lee, Shawn C" wrote: > From: "Lee, Shawn C" > > SPT_PWM_GRANULARITY (SOUTH_CHICKEN1, bit 0) controls the granularity > (minimum increment) of the PWM backlight control counter. PWM frequency > adjustment on 128 clock increments

Re: [Intel-gfx] [PATCH v2 2/2] drm/i915/backlight: setup backlight pwm alternate increment on backlight enable

On Mon, 19 Sep 2016, Jani Nikula wrote: > From: Shawn Lee > > Backlight enable is supposed to do a full setup of the backlight. We > were missing the PWM alternate increment bit in the south chicken > registers on lpt+ pch. This potentially caused a

[Intel-gfx] [PATCH v2] drm/i915 : Restore PWM_GRANULARITY after resume

From: "Lee, Shawn C" SPT_PWM_GRANULARITY (SOUTH_CHICKEN1, bit 0) controls the granularity (minimum increment) of the PWM backlight control counter. PWM frequency adjustment on 128 clock increments when this bit was 1. And 16 clock increments when it was 0. PWM frequency

Re: [Intel-gfx] [PATCH 1/2] drm/i915: Only shrink the unbound objects during freeze

On pe, 2016-09-16 at 20:23 +0100, Chris Wilson wrote: >  int i915_gem_freeze_late(struct drm_i915_private *dev_priv) >  { > >   struct drm_i915_gem_object *obj; > @@ -4692,7 +4705,8 @@ int i915_gem_freeze_late(struct drm_i915_private > *dev_priv) > >    * the objects as well. > >    */ >  

Re: [Intel-gfx] [PATCH v4] drm/i915/skl: New ddb allocation algorithm

Hey, Op 14-09-16 om 14:36 schreef Mahesh Kumar: > Hi, > There was an issue with transition WM, it was getting enabled & causing fifo > underrun. > I fixed the condition, After that tested kms_plane & not getting any underrun. > Please let me know if you see any other issue.

Re: [Intel-gfx] [PATCH 2/2] drm/i915/execlists: Reset RING registers upon resume

On pe, 2016-09-16 at 20:23 +0100, Chris Wilson wrote: >  void intel_lr_context_resume(struct drm_i915_private *dev_priv) >  { > > - struct i915_gem_context *ctx = dev_priv->kernel_context; > >   struct intel_engine_cs *engine; > > + struct i915_gem_context *ctx; > + > > + /* Because we

Re: [Intel-gfx] [PATCH] drm/i915/backlight: setup backlight pwm alternate increment on backlight enable

On Mon, 19 Sep 2016, Jani Nikula wrote: > From: Shawn Lee > > Backlight enable is supposed to do a full setup of the backlight. We > were missing the PWM alternate increment bit in the south chicken > registers on lpt+ pch. This potentially caused a

[Intel-gfx] [PATCH v2 2/2] drm/i915/backlight: setup backlight pwm alternate increment on backlight enable

From: Shawn Lee Backlight enable is supposed to do a full setup of the backlight. We were missing the PWM alternate increment bit in the south chicken registers on lpt+ pch. This potentially caused a PWM frequency change when the chicken register value was lost e.g. on

[Intel-gfx] [PATCH v2 1/2] drm/i915/backlight: setup and cache pwm alternate increment value

This will also be needed later on when setting up the alternate increment in backlight enable. Cc: Shawn Lee Signed-off-by: Jani Nikula --- drivers/gpu/drm/i915/intel_drv.h | 1 + drivers/gpu/drm/i915/intel_panel.c | 14 +++--- 2 files

[Intel-gfx] [PATCH] drm/i915/backlight: setup backlight pwm alternate increment on backlight enable

From: Shawn Lee Backlight enable is supposed to do a full setup of the backlight. We were missing the PWM alternate increment bit in the south chicken registers on lpt+ pch. This potentially caused a PWM frequency change when the chicken register value was lost e.g. on

Re: [Intel-gfx] [PATCH 1/5] drm/i915/skl: drop workarounds for A0 and B0 revisions

On Mon, 19 Sep 2016, Mika Kahola wrote: > On Fri, 2016-09-16 at 16:59 +0300, Jani Nikula wrote: >> Pre-production hardware is not supported. >> >> Signed-off-by: Jani Nikula >> --- >>  drivers/gpu/drm/i915/intel_dp.c   |  4 >>  

Re: [Intel-gfx] [PATCH 1/5] drm/i915/skl: drop workarounds for A0 and B0 revisions

On Fri, 2016-09-16 at 16:59 +0300, Jani Nikula wrote: > Pre-production hardware is not supported. > > Signed-off-by: Jani Nikula > --- >  drivers/gpu/drm/i915/intel_dp.c   |  4 >  drivers/gpu/drm/i915/intel_dp_link_training.c |  3 --- >  

  1   2   >