[Intel-gfx] Delayed mail delivery problem

I had some replies to this mailing list yesterday, but received below notification: --- Delivery is delayed to these recipients or groups: intel-gfx@lists.freedesktop.org Subject: RE: [RFCv2 PATCH 00/14] gvt: Hacking i915 for GVT context requirement This message hasn't been delivered yet.

Re: [Intel-gfx] [4.4-rc1][Regression] drm/i915: Check live status before reading edid

Hi Joe, Yes, first thing to try is to increase the tries. Can you please point me to the bug and provide more details like platform, monitor, cable. Are you referring to the same issue as Oleksandr reported where a single link dvi/hdmi cable didn’t work and dual link worked? Regards, Sonika

[Intel-gfx] [4.4-rc1][Regression] drm/i915: Check live status before reading edid

Hi Sonika, A kernel bug report was opened against Ubuntu [0]. After a kernel bisect, it was found that reverting the following commit resolved this bug: commit 237ed86c693d8a8e4db476976aeb30df4deac74b Author: Sonika Jindal Date: Tue Sep 15 09:44:20 2015 +0530

Re: [Intel-gfx] [BUG] HDMI 12bpc causing occasional flickering and blanking

On Wed, Feb 24, 2016 at 06:48:35PM +0100, Tore Anderson wrote: > Hi Ville, > > > Well, just to check the details of your particular cable/dongle, > > maybe you can post the dmesg with drm.debug=0xe with my branch? > > Or at least the parts that refer to DP dual mode adaptors. > > Here:

[Intel-gfx] [PATCH 3/4] drm/i915/gen9: Disable DC states if power well support is disabled

If power well support is disabled via the i915.disable_power_well module option we should never enable DC states. Currently we would enable DC states even in this case during system suspend, where we need to disable all power wells regardless of the disable_power_well option. CC: Patrik Jakobsson

[Intel-gfx] [PATCH 1/4] drm/i915/skl: Fix power domain suspend sequence

During system suspend we need to first disable power wells then unitialize the display core. In case power well support is disabled we did this in the wrong order, so fix this up. Fixes: d314cd43 ("drm/i915: fix handling of the disable_power_well module option") CC: sta...@vger.kernel.org CC:

[Intel-gfx] [PATCH 2/4] drm/i915/gen9: Sanitize handling of allowed DC states

We can simplify the conditions selecting the target DC state during runtime by calculating the allowed DC states in advance during driver loading. This also makes it easier to disable DC states depending on the i915.disable_power_well module option, added in the next patch. CC: Patrik Jakobsson

[Intel-gfx] [PATCH 4/4] drm/i915/gen9: Remove state asserts when disabling DC states

Disabling the DC states when it's already disabled is a valid scenario, for example during HW state sanitization during driver loading and resuming or when DC states are disabled via the i915.enable_dc or disable_power_well option. CC: Patrik Jakobsson

[Intel-gfx] [PATCH 0/4] drm/915: Sanitize DC state handling

This patchset simplifies the way how we select the target DC state based on the platform and module options. It also fixes one ordering problem I noticed while going through the code, see the first patch. Imre Deak (4): drm/i915/skl: Fix power domain suspend sequence drm/i915/gen9: Sanitize

Re: [Intel-gfx] [BUG] HDMI 12bpc causing occasional flickering and blanking

Hi Ville, > Well, just to check the details of your particular cable/dongle, > maybe you can post the dmesg with drm.debug=0xe with my branch? > Or at least the parts that refer to DP dual mode adaptors. Here: http://filebin.net/gd91wnltky/dmesg.4.5.0-rc4-g32fa589.txt I'm assuming the most

Re: [Intel-gfx] [PATCH 2/4] drm/i915: Respect DP++ adaptor TMDS clock limit

On Tue, Feb 23, 2016 at 06:46:26PM +0200, ville.syrj...@linux.intel.com wrote: > From: Ville Syrjälä > > Try to detect the max TMDS clock limit for the DP++ adaptor (if any) > and take it into account when checking the port clock. > > Note that as with the sink

[Intel-gfx] [PATCH] drm/i915/guc: Support GuC SKL v6.1

From: Alex Dai This version of GuC firmware fixes the engine reset issue where golden context LRC address is treated as page index by mistake. It also fixes the problem that scheduler stops submiting to one engine when the other engine work queue is full. Signed-off-by: Alex

Re: [Intel-gfx] [PATCH v6 3/8] drm/i915: Kill off intel_crtc->atomic.wait_vblank, v6.

Em Qua, 2016-02-24 às 11:24 +0100, Maarten Lankhorst escreveu: > Currently we perform our own wait in post_plane_update, > but the atomic core performs another one in wait_for_vblanks. > This means that 2 vblanks are done when a fb is changed, > which is a bit overkill. > > Merge them by creating

Re: [Intel-gfx] [PATCH v2] drm/i915: Avoid selecting unavailable BSD2 ring

On 23.02.2016 21:36, Dave Gordon wrote: On 23/02/16 14:39, Tvrtko Ursulin wrote: On 23/02/16 14:03, Chris Wilson wrote: On Tue, Feb 23, 2016 at 01:31:17PM +, Tvrtko Ursulin wrote: On 23/02/16 13:06, Gabriel Feceoru wrote: On 23.02.2016 13:05, Tvrtko Ursulin wrote: Hi, On

Re: [Intel-gfx] [BUG] HDMI 12bpc causing occasional flickering and blanking

On Tue, Feb 23, 2016 at 08:44:49PM +0100, Tore Anderson wrote: > Hi Ville, > > > "The monitor is connected with a DP+-to-HDMI cable" > > This and some reading of the DP dual mode spec gave me another idea; > > The DP->HDMI adaptor may simply be degrading the signal quality too > > much. According

[Intel-gfx] [PATCH v2 2/6] drm/atomic: Pass connector and state to update_connector_routing.

Minor cleanup, connector and connector_state are always non-NULL here. Signed-off-by: Maarten Lankhorst --- drivers/gpu/drm/drm_atomic_helper.c | 15 +-- 1 file changed, 5 insertions(+), 10 deletions(-) diff --git

Re: [Intel-gfx] [RFCv2 04/14] drm/i915: factor out alloc_context_idr() and __i915_gem_create_context()

> From: Wang, Zhi A > Sent: Thursday, February 18, 2016 7:42 PM > > For flexible GEM context creation, we factor out __i915_gem_create_context > as the core logic of creation a GEM context. After the refactor, it more > likesa context creation servcie, which is able to create context by >

Re: [Intel-gfx] [RFCv2 PATCH 00/14] gvt: Hacking i915 for GVT context requirement

> From: Wang, Zhi A > Sent: Thursday, February 18, 2016 7:42 PM > > This patchset is used to discuss and finalize the i915 changes required by > GVT context. Previously we have discussed about how to hack i915 to meet > GVT context requirement, and thanks for the idea and comments. > > In this

Re: [Intel-gfx] [PATCH] drm/i915: Update state before setting watermarks.

On 24/02/16 13:54, Maarten Lankhorst wrote: When intel_update_watermarks is called on skylake it inspects crtc->state, which should show as disabled. This wasn't the case, and this resulted in a divide-by-zero in skl_ddb_get_pipe_allocation_limits when intel_update_watermarks was called.

[Intel-gfx] [PATCH] drm/i915: Fix bogus dig_port_map[] assignment for pre-HSW

The recent commit [0bdf5a05647a: drm/i915: Add reverse mapping between port and intel_encoder] introduced a reverse mapping to retrieve intel_dig_port object from the port number. The code assumed that the port vs intel_dig_port are 1:1 mapping. But in reality, this was a too naive assumption.

[Intel-gfx] [PATCH v2 5/6] drm/atomic: Handle encoder assignment conflicts in a separate check.

The current check doesn't handle the case where we don't steal an encoder, but keep it on the current connector. If we repurpose disable_conflicting_encoders to do the checking, we just have to reject the ones that conflict. Signed-off-by: Maarten Lankhorst

[Intel-gfx] [PATCH v2 6/6] drm/atomic: Clean up steal_encoder

Now that only encoders can be stolen that are part of the state steal_encoder no longer needs to inspect all connectors, just those that are part of the atomic state. Signed-off-by: Maarten Lankhorst --- drivers/gpu/drm/drm_atomic_helper.c | 11 ++- 1

[Intel-gfx] [PATCH v2 0/6] drm/atomic: Fix encoder stealing, v2.

After trying out various ways to handle encoder stealing better I came up with a cleaner way. The first patch cleans up update_output_state and only adds affected connectors. This is required to determine which connectors are not part of the atomic state, and allow disabling them if they have

[Intel-gfx] [PATCH v2 1/6] drm/atomic: Clean up update_output_state.

With the addition of crtc_state->connector_mask other connectors from different crtc's aren't needed any more to determine if a crtc has connectors, so only call add_affected_connectors on the target crtc. This allows a cleanup to first remove all current connectors, then add all set->connectors

Re: [Intel-gfx] [BUG] [REGRESSION] [BISECTED] -rc1 breaks audio over HDMI for i915

On Tue, 23 Feb 2016 20:09:02 +0100, Martin Kepplinger wrote: > > Am 2016-02-23 um 18:14 schrieb Ville Syrjälä: > > On Tue, Feb 23, 2016 at 05:57:40PM +0100, Takashi Iwai wrote: > >> On Mon, 22 Feb 2016 22:37:28 +0100, > >> Martin Kepplinger wrote: > >>> > >>> Am 2016-02-22 um 20:10 schrieb

Re: [Intel-gfx] [RFCv2 10/14] drm/i915: update PDPs by condition when submit the LRC context

> From: Wang, Zhi A > Sent: Thursday, February 18, 2016 7:42 PM > > Previously the PDPs inside the ring context are updated at: > > - When populate a LRC context > - Before submitting a LRC context (only for 32 bit PPGTT, as the amount > of used PDPs may change) > > This patch postpones the

Re: [Intel-gfx] [RFCv2 PATCH 00/14] gvt: Hacking i915 for GVT context requirement

Hi Kevin: Now our context switch is covered by context status change notification handler. In the status change handler we will save render registers. As GVT context will be a single submission context we will restore the render registers when the GVT context is scheduled-out by HW. >

[Intel-gfx] [PATCH 1/2] drm/i915/dsi: Added the generic gpio sequence support and gpio table

The generic gpio is sequence is parsed from the VBT and the GPIO table is updated with the North core, South core and SUS core elements. v2: Move changes in sideband.c file to new patch(Jani), rebase v3: Moved the Macro`s to intel_dsi_panel_vbt.c (Jani) v3 by Jani - rebase on previous patches -

Re: [Intel-gfx] [PATCH] drm/i915: Add two-stage ILK-style watermark programming (v11)

Op 24-02-16 om 02:24 schreef Matt Roper: > On Tue, Feb 23, 2016 at 05:20:13PM -0800, Matt Roper wrote: >> In addition to calculating final watermarks, let's also pre-calculate a >> set of intermediate watermark values at atomic check time. These >> intermediate watermarks are a combination of the

Re: [Intel-gfx] [RFCv2 03/14] drm/i915: Introduce host graphics memory/fence partition for GVT-g

> From: Wang, Zhi A > Sent: Tuesday, February 23, 2016 9:23 PM > >> --- a/drivers/gpu/drm/i915/gvt/gvt.c > >> +++ b/drivers/gpu/drm/i915/gvt/gvt.c > >> @@ -348,6 +348,10 @@ void *gvt_create_pgt_device(struct drm_i915_private > *dev_priv) > >>goto err; > >>} > >> > >> +

Re: [Intel-gfx] [REGRESSION] i915: No HDMI output with 4.4

Hi Ville, We will look into this in sometime. Right now team is slightly loaded due to project milestone. Last time I looked into this, we dint have this HW to reproduce this issue. Regards Shashank -Original Message- From: Ville Syrjälä [mailto:ville.syrj...@linux.intel.com] Sent:

Re: [Intel-gfx] [RFCv2 02/14] drm/i915/gvt: Introduce the basic architecture of GVT-g

> From: Joonas Lahtinen [mailto:joonas.lahti...@linux.intel.com] > Sent: Tuesday, February 23, 2016 8:42 PM > > Hi, > > Code is looking a lot better. > > A general question still; why you seem to be preferring multi-stage > alloc and destroy? One reason for multi-stage, IMO, is that GVT needs

Re: [Intel-gfx] [PATCH v6 3/7] drm/i915: Add per context timelines to fence object

Op 22-02-16 om 15:33 schreef John Harrison: > On 18/02/2016 14:49, Chris Wilson wrote: >> On Thu, Feb 18, 2016 at 02:24:06PM +, john.c.harri...@intel.com wrote: >>> From: John Harrison >>> >>> The fence object used inside the request structure requires a sequence

Re: [Intel-gfx] [RFCv2 06/14] drm/i915: let __i915_gem_context_create() takes context creation params

> From: Wang, Zhi A > Sent: Thursday, February 18, 2016 7:42 PM > > Let the core logic of context creation service creats the GEM context by > context creation params. > > Now it provides following options for context creation: > - Need to create legacy context for this GEM context? > - Need to

Re: [Intel-gfx] [RFCv2 07/14] drm/i915: factor out __intel_lr_context_deferred_alloc()

> From: Wang, Zhi A > Sent: Thursday, February 18, 2016 7:42 PM > diff --git a/drivers/gpu/drm/i915/intel_lrc.h > b/drivers/gpu/drm/i915/intel_lrc.h > index e6cda3e..528c4fb 100644 > --- a/drivers/gpu/drm/i915/intel_lrc.h > +++ b/drivers/gpu/drm/i915/intel_lrc.h > @@ -97,10 +97,18 @@ static

[Intel-gfx] [PATCH 2/2] drm/i915: GPIO for CHT generic MIPI

From: Yogesh Mohan Marimuthu The GPIO configuration and register offsets are different from baytrail for cherrytrail. Port the gpio programming accordingly for cherrytrail in this patch. v2: Removing the duplication of parsing v3: Moved the macro def to

Re: [Intel-gfx] [BUG] [REGRESSION] [BISECTED] -rc1 breaks audio over HDMI for i915

On Wed, 24 Feb 2016 08:51:32 +0100, Takashi Iwai wrote: > > Since dig_port_map[] is used only for the audio callback, we can > assign it dynamically just before the callbacks. > > Could you try the patch below? (It's totally untested.) The one below might be safer, it's setting in the mutex

Re: [Intel-gfx] [REGRESSION] i915: No HDMI output with 4.4

24.02.2016 06:40, Jindal, Sonika написав: Do you have logs for the failure with the single link hdmi cable and the register dump which you have given for the working case? If not, can you please capture the logs and register dump. Also which platform is this? If it is live status related issue,

Re: [Intel-gfx] [REGRESSION] i915: No HDMI output with 4.4

23.02.2016 17:08, Ville Syrjälä написав: In the meantime I think as a workaround I think you could use something like video=HDMI-A-1:e on the kernel command line (not sure I got the connector name right for your system). I think that should result in the live status check to be skipped, at least

[Intel-gfx] [PATCH v2 4/6] drm/atomic: Handle encoder stealing from set_config better.

Instead of failing with -EINVAL when conflicting encoders are found, the legacy set_config will disable other connectors when encoders conflict. With the cleanup to update_output_state this is a lot easier to implement. set_config only adds connectors to the state that are modified, and because

Re: [Intel-gfx] [PATCH i-g-t] tests/gem_buffered_svm: Buffered SVM tests

Hi, On 10/02/16 18:01, Vinay Belgaumkar wrote: These tests were initially reviewed/merged under the gem_softpin title. They use softpinning and userptr mechanism to share buffers between CPU and GPU. The userptr part was decoupled from them recently. Adding these tests under a different name

[Intel-gfx] [PATCH] drm/i915: Update state before setting watermarks.

When intel_update_watermarks is called on skylake it inspects crtc->state, which should show as disabled. This wasn't the case, and this resulted in a divide-by-zero in skl_ddb_get_pipe_allocation_limits when intel_update_watermarks was called. [ cut here ] WARNING: CPU:

[Intel-gfx] [PATCH v2 3/6] drm/atomic: Always call steal_encoder.

There's no need to have a separate function to get the crtc which is stolen, this can already be found when actually stealing the encoder. drm_for_each_connector already checks for connection_mutex, so use that macro now. Signed-off-by: Maarten Lankhorst ---

Re: [Intel-gfx] [RFCv2 02/14] drm/i915/gvt: Introduce the basic architecture of GVT-g

> From: Joonas Lahtinen [mailto:joonas.lahti...@linux.intel.com] > Sent: Tuesday, February 23, 2016 8:54 PM > > diff --git a/drivers/gpu/drm/i915/gvt/Makefile > > b/drivers/gpu/drm/i915/gvt/Makefile > > new file mode 100644 > > index 000..959305f > > --- /dev/null > > +++

Re: [Intel-gfx] [RFCv2 03/14] drm/i915: Introduce host graphics memory/fence partition for GVT-g

> From: Wang, Zhi A > Sent: Thursday, February 18, 2016 7:42 PM > diff --git a/drivers/gpu/drm/i915/gvt/gvt.c b/drivers/gpu/drm/i915/gvt/gvt.c > index 52cfa32..2099b7e 100644 > --- a/drivers/gpu/drm/i915/gvt/gvt.c > +++ b/drivers/gpu/drm/i915/gvt/gvt.c > @@ -348,6 +348,10 @@ void

[Intel-gfx] Q: The relationship between "BIOS GT RC6 option" and RC_CONTROL

Hi: Had a question about "BIOS GT RC6 option". If I disabled the BIOS GT RC6 option, does that mean RC6 will be disabled no matter how driver configure RC_CONTROL registers on core platform? Looks currently on some SoC platform e.g. BXT, the status of "BIOS GT RC6 option" will be reflected

Re: [Intel-gfx] [RFCv2 PATCH 00/14] gvt: Hacking i915 for GVT context requirement

> From: Wang, Zhi A > Sent: Wednesday, February 24, 2016 5:19 PM > > Hi Kevin: > Now our context switch is covered by context status change notification > handler. In the > status change handler we will save render registers. As GVT context will be a > single > submission context we will

Re: [Intel-gfx] [PATCH 3/3] drm/atomic: Refuse to steal encoders from connectors not part of the state.

Hey, Op 18-02-16 om 13:59 schreef Ville Syrjälä: > On Thu, Feb 18, 2016 at 01:43:11PM +0100, Daniel Vetter wrote: >> On Thu, Feb 18, 2016 at 12:18:53PM +0100, Maarten Lankhorst wrote: >>> Op 18-02-16 om 12:07 schreef Daniel Vetter: On Thu, Feb 18, 2016 at 09:54:43AM +0100, Maarten Lankhorst

[Intel-gfx] [PATCH v6 3/8] drm/i915: Kill off intel_crtc->atomic.wait_vblank, v6.

Currently we perform our own wait in post_plane_update, but the atomic core performs another one in wait_for_vblanks. This means that 2 vblanks are done when a fb is changed, which is a bit overkill. Merge them by creating a helper function that takes a crtc mask for the planes to wait on. The

[Intel-gfx] [PATCH v5] drm/i915/execlists: Move WA_TAIL_DWORDS to callee

From: Chris Wilson Currently emit-request starts writing to the ring and reserves space for a workaround to be emitted later whilst submitting the request. It is easier to read if the caller only allocates sufficient space for its access (then the reader can quickly

Re: [Intel-gfx] [RFCv2 08/14] drm/i915: Support per-PPGTT address space mode

> From: Wang, Zhi A > Sent: Thursday, February 18, 2016 7:42 PM > -static int gen8_ppgtt_init(struct i915_hw_ppgtt *ppgtt) > +static int gen8_ppgtt_init(struct i915_hw_ppgtt *ppgtt, int > address_space_mode) address_space_mode -> address_bits? > { > int ret; > > @@ -1518,7 +1524,7 @@

Re: [Intel-gfx] [RFCv2 13/14] drm/i915: Support context single submission when GVT is active

> From: Wang, Zhi A > Sent: Thursday, February 18, 2016 7:42 PM > diff --git a/drivers/gpu/drm/i915/intel_lrc.c > b/drivers/gpu/drm/i915/intel_lrc.c > index 1c0366a..2a6d6fe 100644 > --- a/drivers/gpu/drm/i915/intel_lrc.c > +++ b/drivers/gpu/drm/i915/intel_lrc.c > @@ -479,6 +479,40 @@ static void