Re: [Intel-gfx] [PATCH V6] drm/i915: Disable stolen memory when i915 runs in guest vm

> On ke, 2017-05-03 at 09:22 +, Zhang, Xiong Y wrote: > > > > > > > > > > > + David and Jon > > > > > > > > On ti, 2017-04-25 at 18:34 +0800, Xiong Zhang wrote: > > > > > > > > The blocking issue I see is that bisecting is still not pointing at > > > > relevant commits. Both bisected commits

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/guc: capture GuC logs if FW fails to load (rev3)

== Series Details == Series: drm/i915/guc: capture GuC logs if FW fails to load (rev3) URL : https://patchwork.freedesktop.org/series/23982/ State : success == Summary == Series 23982v3 drm/i915/guc: capture GuC logs if FW fails to load

[Intel-gfx] [PATCH v3] drm/i915/guc: capture GuC logs if FW fails to load

We're currently deleting the GuC logs if the FW fails to load, but those are still useful to understand why the loading failed. Keeping the object around allows us to access them after driver load is completed. v2: keep the object around instead of using kernel memory (chris) don't store the

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/guc: Dump the GuC stage descriptor pool in debugfs

== Series Details == Series: drm/i915/guc: Dump the GuC stage descriptor pool in debugfs URL : https://patchwork.freedesktop.org/series/24051/ State : success == Summary == Series 24051v1 drm/i915/guc: Dump the GuC stage descriptor pool in debugfs

Re: [Intel-gfx] [PATCH RESEND] drm/i915: Fix pipe/transcoder enum mismatches

Hi, El Fri, May 05, 2017 at 01:29:32PM -0700 Grant Grundler ha dit: > On Fri, May 5, 2017 at 1:08 PM, Ville Syrjälä > wrote: > ... > >> > I'm not convinced the patch is making things any better really. To > >> > fix this really properly, I think we'd need to

[Intel-gfx] [PATCH] drm/i915/guc: Dump the GuC stage descriptor pool in debugfs

We are missing pieces of information that could be useful for GuC debugging. Cc: Daniele Ceraolo Spurio Cc: Joonas Lahtinen Signed-off-by: Oscar Mateo --- drivers/gpu/drm/i915/i915_debugfs.c | 61

Re: [Intel-gfx] [PATCH 15/15] drm/i915: Simplify cursor register write sequence

On Mon, Mar 27, 2017 at 09:55:46PM +0300, ville.syrj...@linux.intel.com wrote: > From: Ville Syrjälä > > It looks like simply writing all the cursor register every single > time might be slightly faster than checking to see of each of > them need to be written. So

[Intel-gfx] ✓ Fi.CI.BAT: success for Kernel PSR Fix-ups

== Series Details == Series: Kernel PSR Fix-ups URL : https://patchwork.freedesktop.org/series/24049/ State : success == Summary == Series 24049v1 Kernel PSR Fix-ups https://patchwork.freedesktop.org/api/1.0/series/24049/revisions/1/mbox/ Test gem_exec_flush: Subgroup

Re: [Intel-gfx] [PATCH 14/15] drm/i915: Relax 845/865 CURBASE alignemnt requirement to 32 bytes

On Mon, Mar 27, 2017 at 09:55:45PM +0300, ville.syrj...@linux.intel.com wrote: > From: Ville Syrjälä > > Supposedly 845/865 require only 32 byte alignment for CURBASE. Let's > relax the checks to allow that instead of demanding 4KiB alignment. > This will allow

[Intel-gfx] [PATCH IGT 4/5] tests/kms_frontbuffer_tracking: Refactor to use IGT PSR library functions

Cc: Rodrigo Vivi Cc: Paulo Zanoni Signed-off-by: Jim Bride --- tests/kms_frontbuffer_tracking.c | 95 +--- 1 file changed, 10 insertions(+), 85 deletions(-) diff --git

[Intel-gfx] [PATCH IGT 5/5] tests/kms_fbcon_fbt: Refactor to use IGT PSR library functions

Cc: Rodrigo Vivi Cc: Paulo Zanoni Signed-off-by: Jim Bride --- tests/kms_fbcon_fbt.c| 56 tests/kms_psr_sink_crc.c | 36 +-- 2 files

[Intel-gfx] [PATCH IGT 1/5] tests/kms_psr_sink_crc: Change assert_or_manual() to a macro

Make assert_or_manual() a macro so that we get accurate line number information when this assertion fails. Cc: Rodrigo Vivi Cc: Paulo Zanoni Signed-off-by: Jim Bride --- tests/kms_psr_sink_crc.c | 10 +- 1

[Intel-gfx] [PATCH IGT 3/5] tests/kms_psr_sink_crc: Refactor to use new PSR library primitives

Cc: Rodrigo Vivi Cc: Paulo Zanoni Signed-off-by: Jim Bride --- tests/kms_psr_sink_crc.c | 28 1 file changed, 8 insertions(+), 20 deletions(-) diff --git a/tests/kms_psr_sink_crc.c

[Intel-gfx] [PATCH IGT 0/5] PSR IGT Test Fix-ups

These patches, along with the kernel series at https://patchwork.freedesktop.org/series/24049/ allow our PSR IGT tests to run more predictably on HSW, SKL, and KBL. These patches depend on the kernel series in order to run properly. On the systems I have available the following sets of tests run

[Intel-gfx] [PATCH IGT 2/5] lib: Add PSR utility functions to igt library.

Factor out some code that was replicated in three test utilities into some new IGT library functions so that we are checking PSR status in a consistent fashion across all of our PSR tests. Cc: Rodrigo Vivi Cc: Paulo Zanoni Signed-off-by: Jim

[Intel-gfx] [PATCH 4/4] drm/i915/psr: Account for sink CRC raciness on some panels

According to the eDP spec, when the count field in TEST_SINK_MISC increments then the six bytes of sink CRC information in the DPCD should be valid. Unfortunately, this doesn't seem to be the case on some panels, and as a result we get some incorrect and inconsistent values from the sink CRC DPCD

[Intel-gfx] [PATCH 2/4] drm/i915/psr: Clean-up intel_enable_source_psr1()

On SKL+ there is a bit in SRD_CTL that software is not supposed to modify, but we currently clobber that bit when we enable PSR. In order to preserve the value of that bit, go ahead and read SRD_CTL and do a field-wise setting of the various bits that we need to initialize before writing the

[Intel-gfx] [PATCH 3/4] drm/i915/edp: Be less aggressive about changing link config on eDP

This set of changes has some history to them. There were several attempts to add what was called "fast link training" to i915, which actually wasn't fast link training as per the DP spec. These changes were 5fa836a9d859 ("drm/i915: DP link training optimization") 4e96c97742f4 ("drm/i915: eDP

[Intel-gfx] [PATCH 1/4] drm/i915/edp: Allow alternate fixed mode for eDP if available.

Some fixed resolution panels actually support more than one mode, with the only thing different being the refresh rate. Having this alternate mode available to us is desirable, because it allows us to test PSR on panels whose setup time at the preferred mode is too long. With this patch we allow

[Intel-gfx] [PATCH 0/4] Kernel PSR Fix-ups

These patches, along with an upcoming series for IGT, enable our PSR IGT tests to run reliably once again. The first change enables us to run the PSR tests on SKL and KBL RVP platforms, whose panels have too slow of a setup time when running in their preferred mode. The second fixes a minor

Re: [Intel-gfx] [PATCH 13/15] drm/i915: Handle fb offset and src coordinates for cursors

On Mon, Mar 27, 2017 at 09:55:44PM +0300, ville.syrj...@linux.intel.com wrote: > From: Ville Syrjälä > > The cursor plane doesn't have any kind of source offset register, so > the only form of panning possible is via a the base address register. > The alignment

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/2] drm/i915/guc: Get rid of the enable_guc_loading module parameter

== Series Details == Series: series starting with [1/2] drm/i915/guc: Get rid of the enable_guc_loading module parameter URL : https://patchwork.freedesktop.org/series/24048/ State : success == Summary == Series 24048v1 Series without cover letter

Re: [Intel-gfx] [PATCH] drm/i915/cnp: Backlight support for CNP.

>-Original Message- >From: Pandiyan, Dhinakaran >Sent: Friday, May 5, 2017 1:35 PM >To: Nikula, Jani >Cc: intel-gfx@lists.freedesktop.org; Vivi, Rodrigo ; >Taylor, Clinton A ; Srivatsa, Anusha

Re: [Intel-gfx] [PATCH] drm/i915/cnp: Backlight support for CNP.

On Fri, 2017-05-05 at 19:50 +0300, Jani Nikula wrote: > On Fri, 05 May 2017, "Srivatsa, Anusha" wrote: > >>-Original Message- > >>From: Nikula, Jani > >>Sent: Thursday, May 4, 2017 2:25 AM > >>To: Srivatsa, Anusha ; intel- >

Re: [Intel-gfx] [PATCH RFC 2/2] drm/i915/guc: Rename has_guc to has_uc

>-Original Message- >From: Mateo Lozano, Oscar >Sent: Friday, May 5, 2017 6:23 AM >To: intel-gfx@lists.freedesktop.org >Cc: Mateo Lozano, Oscar ; Srivatsa, Anusha >; Ceraolo Spurio, Daniele >; Chris Wilson

Re: [Intel-gfx] [PATCH RESEND] drm/i915: Fix pipe/transcoder enum mismatches

On Fri, May 5, 2017 at 1:08 PM, Ville Syrjälä wrote: ... >> > I'm not convinced the patch is making things any better really. To >> > fix this really properly, I think we'd need to introduce a new enum >> > pch_transcoder and thus avoid the confusion of which type

Re: [Intel-gfx] i915 I2C failures with recent chips and docking stations

On Fri, May 05, 2017 at 03:53:39AM -0400, Sanford Rockowitz wrote: > I am the author of ddcutil (www.ddcutil.com), a Linux utility that > manages monitor settings using DDC/CI. I am seeing a pattern of user > error reports in which I2C communication is not working when a system > with a recent

[Intel-gfx] [PATCH RFC 2/2] drm/i915/guc: Rename has_guc to has_uc

AFAIK, every platform with a HuC has a GuC and viceversa, so make it explicit. Cc: Anusha Srivatsa Cc: Daniele Ceraolo Spurio Cc: Chris Wilson CC: Arkadiusz Hiler Signed-off-by:

[Intel-gfx] [PATCH 1/2] drm/i915/guc: Get rid of the enable_guc_loading module parameter

The decission to enable GuC loading shouldn't be left to the user. Provided the HW supports the GuC, there are only two reasons to load it: - The user has requested GuC submission. - We have a HuC firmware available (so we need the GuC to validate it). We leave the enable_guc_submission

Re: [Intel-gfx] i915 I2C failures with recent chips and docking stations

On Fri, 05 May 2017, Sanford Rockowitz wrote: > Last question (I think). You wrote: > >> You'll want the DP MST I2C code fixed. Well, at least it's my *guess* > that's where the problem is. > > Where do I go to post this problem? Sorry, I could have added that in my

Re: [Intel-gfx] [PATCH RESEND] drm/i915: Fix pipe/transcoder enum mismatches

On Fri, May 05, 2017 at 12:12:49PM -0700, Grant Grundler wrote: > On Fri, May 5, 2017 at 10:40 AM, Ville Syrjälä > wrote: > > On Fri, May 05, 2017 at 10:26:36AM -0700, Matthias Kaehlcke wrote: > >> El Thu, Apr 20, 2017 at 02:56:05PM -0700 Matthias Kaehlcke ha dit: >

Re: [Intel-gfx] i915 I2C failures with recent chips and docking stations

Last question (I think). You wrote: > You'll want the DP MST I2C code fixed. Well, at least it's my *guess* that's where the problem is. Where do I go to post this problem? Thanks, Sanford On 05/05/2017 12:49 PM, Jani Nikula wrote: > On Fri, 05 May 2017, Sanford Rockowitz

Re: [Intel-gfx] [PATCH] drm/i915: Update MOCS settings for gen 9

On Friday, May 5, 2017 9:21:54 AM PDT Dmitry Rogozhkin wrote: > > My point largely stands, when redirected - someone is developing a > > broken closed source userspace driver and is apparently unwilling to > > change it. That's the real problem. > Broken? Have you ever attempted to run functional

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/guc: capture GuC logs if FW fails to load (rev2)

== Series Details == Series: drm/i915/guc: capture GuC logs if FW fails to load (rev2) URL : https://patchwork.freedesktop.org/series/23982/ State : success == Summary == Series 23982v2 drm/i915/guc: capture GuC logs if FW fails to load

Re: [Intel-gfx] [PATCH v2] drm/i915/guc: capture GuC logs if FW fails to load

On Fri, May 05, 2017 at 10:45:47AM -0700, Daniele Ceraolo Spurio wrote: > We're currently deleting the GuC logs if the FW fails to load, but those > are still useful to understand why the loading failed. Keeping the > object around allows us to access them after driver load is completed. > > v2:

Re: [Intel-gfx] [PATCH RESEND] drm/i915: Fix pipe/transcoder enum mismatches

On Fri, May 5, 2017 at 10:40 AM, Ville Syrjälä wrote: > On Fri, May 05, 2017 at 10:26:36AM -0700, Matthias Kaehlcke wrote: >> El Thu, Apr 20, 2017 at 02:56:05PM -0700 Matthias Kaehlcke ha dit: >> >> > In several instances the driver passes an 'enum pipe' value to a

Re: [Intel-gfx] [PATCH 12/15] drm/i915: Fix gen3 physical cursor alignment requirements

On Mon, Mar 27, 2017 at 09:55:43PM +0300, ville.syrj...@linux.intel.com wrote: > From: Ville Syrjälä > > Bspec tells us that gen3 platforms need 4KiB alignment for CURBASE > rather than the 256 byte alignment required by i85x. Let's fix that > and pull the code to

[Intel-gfx] [PATCH v6 4/9] drm/i915: Allow choosing how to adjust brightness if both supported

Add option to allow choosing how to adjust brightness if panel supports both PWM pin and AUX channel. Signed-off-by: Puthikorn Voravootivat --- Fix compile error in v5 drivers/gpu/drm/i915/i915_params.c| 8 +--- drivers/gpu/drm/i915/i915_params.h

[Intel-gfx] [PATCH v2] drm/i915/guc: capture GuC logs if FW fails to load

We're currently deleting the GuC logs if the FW fails to load, but those are still useful to understand why the loading failed. Keeping the object around allows us to access them after driver load is completed. v2: keep the object around instead of using kernel memory (chris) don't store the

Re: [Intel-gfx] [PATCH RESEND] drm/i915: Fix pipe/transcoder enum mismatches

On Fri, May 05, 2017 at 10:26:36AM -0700, Matthias Kaehlcke wrote: > El Thu, Apr 20, 2017 at 02:56:05PM -0700 Matthias Kaehlcke ha dit: > > > In several instances the driver passes an 'enum pipe' value to a > > function expecting an 'enum transcoder' and viceversa. Since PIPE_x and > >

Re: [Intel-gfx] [PATCH RESEND] drm/i915: Fix pipe/transcoder enum mismatches

El Thu, Apr 20, 2017 at 02:56:05PM -0700 Matthias Kaehlcke ha dit: > In several instances the driver passes an 'enum pipe' value to a > function expecting an 'enum transcoder' and viceversa. Since PIPE_x and > TRANSCODER_x have the same values this doesn't cause functional > problems. Still it is

Re: [Intel-gfx] [PATCH] drm/i915/cnp: Backlight support for CNP.

On Fri, 05 May 2017, "Srivatsa, Anusha" wrote: >>-Original Message- >>From: Nikula, Jani >>Sent: Thursday, May 4, 2017 2:25 AM >>To: Srivatsa, Anusha ; intel- >>g...@lists.freedesktop.org >>Cc: Vivi, Rodrigo ;

Re: [Intel-gfx] i915 I2C failures with recent chips and docking stations

On Fri, 05 May 2017, Sanford Rockowitz wrote: > Jani, > > Thanks for your quick and detailed response. > > You wrote: > >> The single DP link is divided to several logical links to sink devices. > > Suppose the dock has a DVI and/or HDMI connector. Are those connectors >

Re: [Intel-gfx] [PATCH] drm/i915/cnp: Backlight support for CNP.

>-Original Message- >From: Nikula, Jani >Sent: Thursday, May 4, 2017 2:25 AM >To: Srivatsa, Anusha ; intel- >g...@lists.freedesktop.org >Cc: Vivi, Rodrigo ; Ville Syrjala >; Srivatsa, Anusha

Re: [Intel-gfx] [PATCH] drm/i915: Restore GT performance in headless mode with DMC loaded

On Fri, May 05, 2017 at 05:13:58PM +0100, Tvrtko Ursulin wrote: > > On 05/05/2017 15:49, Ville Syrjälä wrote: > > On Fri, May 05, 2017 at 12:43:21PM +0100, Tvrtko Ursulin wrote: > >> From: Tvrtko Ursulin > >> > >> It seems that the DMC likes to transition between the DC

Re: [Intel-gfx] [PATCH] drm/i915: Update MOCS settings for gen 9

On 5/5/2017 8:44 AM, Kenneth Graunke wrote: On Thursday, May 4, 2017 7:46:34 PM PDT Dmitry Rogozhkin wrote: On 5/4/2017 9:51 AM, Kenneth Graunke wrote: MediaSDK is not a benchmark. If I'm not mistaken, it's a userspace driver produced by Intel engineers, one which Intel has the full

Re: [Intel-gfx] [PATCH] drm/i915: Restore GT performance in headless mode with DMC loaded

On 05/05/2017 15:49, Ville Syrjälä wrote: On Fri, May 05, 2017 at 12:43:21PM +0100, Tvrtko Ursulin wrote: From: Tvrtko Ursulin It seems that the DMC likes to transition between the DC states a lot when there are no connected displays (no active power domains) during

Re: [Intel-gfx] [RFC] drm/i915/guc: capture GuC logs if FW fails to load

On Fri, May 05, 2017 at 08:43:36AM -0700, Daniele Ceraolo Spurio wrote: > > > On 04/05/17 14:31, Chris Wilson wrote: > >On Thu, May 04, 2017 at 09:26:35PM +, Srivatsa, Anusha wrote: > >>>+void i915_guc_load_error_log_capture(struct drm_i915_private *i915) { > >>>+ void *log, *buf; > >>>+

Re: [Intel-gfx] [PATCH] drm/i915: Update MOCS settings for gen 9

On Thursday, May 4, 2017 7:46:34 PM PDT Dmitry Rogozhkin wrote: > > On 5/4/2017 9:51 AM, Kenneth Graunke wrote: > > MediaSDK is not a benchmark. If I'm not mistaken, it's a userspace > > driver produced by Intel engineers, one which Intel has the full > > capability to change. What you're

Re: [Intel-gfx] [RFC] drm/i915/guc: capture GuC logs if FW fails to load

On 04/05/17 14:31, Chris Wilson wrote: On Thu, May 04, 2017 at 09:26:35PM +, Srivatsa, Anusha wrote: +void i915_guc_load_error_log_capture(struct drm_i915_private *i915) { + void *log, *buf; + struct i915_vma *vma = i915->guc.log.vma; + + if

Re: [Intel-gfx] [PATCH v7 11/15] drm/i915: Support variable cursor height on ivb+

On Mon, Mar 27, 2017 at 09:55:42PM +0300, ville.syrj...@linux.intel.com wrote: > From: Ville Syrjälä > > IVB introduced the CUR_FBC_CTL register which allows reducing the cursor > height down to 8 lines from the otherwise square cursor dimensions. > Implement

Re: [Intel-gfx] [RFC] drm/i915/guc: capture GuC logs if FW fails to load

On 04/05/17 14:26, Srivatsa, Anusha wrote: -Original Message- From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf Of Daniele Ceraolo Spurio Sent: Thursday, May 4, 2017 11:52 AM To: intel-gfx@lists.freedesktop.org Subject: [Intel-gfx] [RFC] drm/i915/guc:

[Intel-gfx] [maintainer-tools PATCH] docs: drm-misc: Remove misc-next merges during merge window/rc1

In the merge timeline, remove the misc-next ~> drm-next merges while the merge window is active, and during rc1. Pulls should only be requested between rc2 and rc5. Signed-off-by: Sean Paul --- While the early PR no-no is fresh in my mind, I'll update the merge timeline

[Intel-gfx] [PULL] drm-misc-next-fixes for 4.12

Hi Dave, Many apologies for missing your initial PR. Just one patch to fix up the panel for HP zBook 17 G2. drm-misc-next-fixes-2017-05-05: Core Changes: - Add quirk for LGD 764 panel to default 10bpc (Mario) Cc: Mario Kleiner Cheers, Sean The following changes

Re: [Intel-gfx] [RFC PATCH 6/6] drm/i915/gvt: support QEMU getting the dmabuf

On Fri, 05 May 2017 08:55:31 +0200 Gerd Hoffmann wrote: > Hi, > > > > >>Hmm, that looks like a rather strange way to return a file descriptor. > > > >> > > > >>What is the reason to not use ioctls on the vfio file handle, like > > > >>older version of these patches did?

Re: [Intel-gfx] [PATCH] drm/i915: Restore GT performance in headless mode with DMC loaded

On Fri, May 05, 2017 at 12:43:21PM +0100, Tvrtko Ursulin wrote: > From: Tvrtko Ursulin > > It seems that the DMC likes to transition between the DC states > a lot when there are no connected displays (no active power > domains) during simple command submission. Is it

[Intel-gfx] [PULL] drm-misc-next for 4.13

Hi Dave, Here's the first pull request for 4.13 from misc-next. It's surprisingly small given that we had an extra week of feature freeze. The highlights are below, and aside from these we had miscellaneous (heh) fixes sprinkled throughout. A bit of administrivia for you: We now have a standard

Re: [Intel-gfx] [PATCH 6/9] drm/i915: Split execlist priority queue into rbtree + linked list

On Fri, May 05, 2017 at 03:20:08PM +0100, Tvrtko Ursulin wrote: > > On 05/05/2017 14:51, Chris Wilson wrote: > >On Fri, May 05, 2017 at 02:37:41PM +0100, Tvrtko Ursulin wrote: > >> > >>On 05/05/2017 14:32, Chris Wilson wrote: > >>>On Fri, May 05, 2017 at 02:19:07PM +0100, Tvrtko Ursulin wrote: >

Re: [Intel-gfx] [PATCH 6/9] drm/i915: Split execlist priority queue into rbtree + linked list

On 05/05/2017 15:04, Chris Wilson wrote: On Fri, May 05, 2017 at 02:50:46PM +0100, Tvrtko Ursulin wrote: On 03/05/2017 12:37, Chris Wilson wrote: [snip] +#include + +static inline void __list_del_many(struct list_head *head, + struct list_head *first) +{ +

Re: [Intel-gfx] [PATCH 6/9] drm/i915: Split execlist priority queue into rbtree + linked list

On 05/05/2017 14:51, Chris Wilson wrote: On Fri, May 05, 2017 at 02:37:41PM +0100, Tvrtko Ursulin wrote: On 05/05/2017 14:32, Chris Wilson wrote: On Fri, May 05, 2017 at 02:19:07PM +0100, Tvrtko Ursulin wrote: On 03/05/2017 12:37, Chris Wilson wrote: struct intel_engine_cs { @@ -367,6

Re: [Intel-gfx] i915 I2C failures with recent chips and docking stations

Jani, Thanks for your quick and detailed response. You wrote: > The single DP link is divided to several logical links to sink devices. Suppose the dock has a DVI and/or HDMI connector. Are those connectors logical sinks to a master DisplayPort connection, or do they have their own

Re: [Intel-gfx] [PATCH 6/9] drm/i915: Split execlist priority queue into rbtree + linked list

On Fri, May 05, 2017 at 02:50:46PM +0100, Tvrtko Ursulin wrote: > > On 03/05/2017 12:37, Chris Wilson wrote: > > [snip] > > >+#include > >+ > >+static inline void __list_del_many(struct list_head *head, > >+ struct list_head *first) > >+{ > >+head->next =

Re: [Intel-gfx] [PATCH 09/15] drm/i915: Generalize cursor size checks a bit

On Mon, Mar 27, 2017 at 09:55:40PM +0300, ville.syrj...@linux.intel.com wrote: > From: Ville Syrjälä > > We have the maximum cursor dimensions stored in the mode_config, so > let's just consult that information instead of hardcoding the same > information in

Re: [Intel-gfx] [PATCH 6/9] drm/i915: Split execlist priority queue into rbtree + linked list

On Fri, May 05, 2017 at 02:37:41PM +0100, Tvrtko Ursulin wrote: > > On 05/05/2017 14:32, Chris Wilson wrote: > >On Fri, May 05, 2017 at 02:19:07PM +0100, Tvrtko Ursulin wrote: > >> > >>On 03/05/2017 12:37, Chris Wilson wrote: > >>>struct intel_engine_cs { > >>>@@ -367,6 +373,7 @@ struct

Re: [Intel-gfx] [PATCH 6/9] drm/i915: Split execlist priority queue into rbtree + linked list

On 03/05/2017 12:37, Chris Wilson wrote: [snip] +#include + +static inline void __list_del_many(struct list_head *head, + struct list_head *first) +{ + head->next = first; + first->prev = head; +} Btw it is similar to __list_cut_position, but

Re: [Intel-gfx] [PATCH 7/9] drm/i915/execlists: Reduce lock context between schedule/submit_request

On Fri, May 05, 2017 at 02:30:08PM +0100, Tvrtko Ursulin wrote: > > On 03/05/2017 12:37, Chris Wilson wrote: > >If we do not require to perform priority bumping, and we haven't yet > >submitted the request, we can update its priority in situ and skip > >acquiring the engine locks -- thus avoiding

Re: [Intel-gfx] [PATCH 6/9] drm/i915: Split execlist priority queue into rbtree + linked list

On 05/05/2017 14:32, Chris Wilson wrote: On Fri, May 05, 2017 at 02:19:07PM +0100, Tvrtko Ursulin wrote: On 03/05/2017 12:37, Chris Wilson wrote: struct intel_engine_cs { @@ -367,6 +373,7 @@ struct intel_engine_cs { /* Execlists */ struct tasklet_struct irq_tasklet; +

Re: [Intel-gfx] [PATCH 9/9] drm/i915: Don't force serialisation on marking up execlists irq posted

On 03/05/2017 12:37, Chris Wilson wrote: Since we coordinate with the execlists tasklet using a locked schedule operation that ensures that after we set the engine->irq_posted we always have an invocation of the tasklet, we do not need to use a locked operation to set the engine->irq_posted

Re: [Intel-gfx] [PATCH 6/9] drm/i915: Split execlist priority queue into rbtree + linked list

On Fri, May 05, 2017 at 02:19:07PM +0100, Tvrtko Ursulin wrote: > > On 03/05/2017 12:37, Chris Wilson wrote: > > struct intel_engine_cs { > >@@ -367,6 +373,7 @@ struct intel_engine_cs { > > > > /* Execlists */ > > struct tasklet_struct irq_tasklet; > >+struct execlist_priolist

Re: [Intel-gfx] [PATCH 7/9] drm/i915/execlists: Reduce lock context between schedule/submit_request

On 03/05/2017 12:37, Chris Wilson wrote: If we do not require to perform priority bumping, and we haven't yet submitted the request, we can update its priority in situ and skip acquiring the engine locks -- thus avoiding any contention between us and submit/execute. Signed-off-by: Chris Wilson

Re: [Intel-gfx] [PATCH 6/9] drm/i915: Split execlist priority queue into rbtree + linked list

On 03/05/2017 12:37, Chris Wilson wrote: All the requests at the same priority are executed in FIFO order. They do not need to be stored in the rbtree themselves, as they are a simple list within a level. If we move the requests at one priority into a list, we can then reduce the rbtree to the

Re: [Intel-gfx] [PATCH] drm/i915: Update MOCS settings for gen 9

On Fri, May 05, 2017 at 12:49:49PM +0100, Chris Wilson wrote: > On Fri, May 05, 2017 at 01:31:37PM +0200, Arkadiusz Hiler wrote: > > On Thu, May 04, 2017 at 07:46:34PM -0700, Dmitry Rogozhkin wrote: > > > > > > > > > On 5/4/2017 9:51 AM, Kenneth Graunke wrote: > > > > MediaSDK is not a

Re: [Intel-gfx] [PATCH 7/9] drm/i915/execlists: Reduce lock context between schedule/submit_request

s/context/contention/ in subject On Wed, May 03, 2017 at 12:37:57PM +0100, Chris Wilson wrote: > If we do not require to perform priority bumping, and we haven't yet > submitted the request, we can update its priority in situ and skip > acquiring the engine locks -- thus avoiding any contention

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Restore GT performance in headless mode with DMC loaded

== Series Details == Series: drm/i915: Restore GT performance in headless mode with DMC loaded URL : https://patchwork.freedesktop.org/series/24017/ State : success == Summary == Series 24017v1 drm/i915: Restore GT performance in headless mode with DMC loaded

Re: [Intel-gfx] [PATCH 3/9] drm/i915/execlists: Pack the count into the low bits of the port.request

On 05/05/2017 12:16, Chris Wilson wrote: On Fri, May 05, 2017 at 11:49:21AM +0100, Tvrtko Ursulin wrote: On 03/05/2017 12:37, Chris Wilson wrote: +static void port_assign(struct execlist_port *port, + struct drm_i915_gem_request *rq) +{ + GEM_BUG_ON(rq ==

Re: [Intel-gfx] [PATCH] drm/i915: Restore GT performance in headless mode with DMC loaded

On Fri, May 05, 2017 at 12:43:21PM +0100, Tvrtko Ursulin wrote: > From: Tvrtko Ursulin > > It seems that the DMC likes to transition between the DC states > a lot when there are no connected displays (no active power > domains) during simple command submission. > >

Re: [Intel-gfx] [PATCH] drm/i915: Update MOCS settings for gen 9

On Fri, May 05, 2017 at 01:31:37PM +0200, Arkadiusz Hiler wrote: > On Thu, May 04, 2017 at 07:46:34PM -0700, Dmitry Rogozhkin wrote: > > > > > > On 5/4/2017 9:51 AM, Kenneth Graunke wrote: > > > MediaSDK is not a benchmark. If I'm not mistaken, it's a userspace > > > driver produced by Intel

Re: [Intel-gfx] [PATCH i-g-t 13/13] tests/gem_exec_nop: Disable headless subtest on cairoless Android

On Thu, May 04, 2017 at 11:00:33AM +0300, Petri Latvala wrote: > On Wed, Apr 19, 2017 at 01:01:55PM +0200, Arkadiusz Hiler wrote: > > Currently whole igt_kms.c is disabled while compiling on Android without > > cairo, so this tests does not compile. > > > > There should be cleaner a way to

Re: [Intel-gfx] [PATCH i-g-t 05/13] chamelium: Fix build issues on Android

On Tue, May 02, 2017 at 12:53:16PM +0300, Petri Latvala wrote: > On Wed, Apr 19, 2017 at 01:01:47PM +0200, Arkadiusz Hiler wrote: > > Also igt_chamelium.h included config.h without proper "HAVE_CONFIG_H" > > guard, and the file itself was included unconditionally. > > I see unconditional config.h

[Intel-gfx] [PATCH] drm/i915: Restore GT performance in headless mode with DMC loaded

From: Tvrtko Ursulin It seems that the DMC likes to transition between the DC states a lot when there are no connected displays (no active power domains) during simple command submission. This frantic activity on DC states has a terrible impact on the performance of

[Intel-gfx] [PATCH v3 2/3] drm/i915/guc: Make scratch register base and count flexible

We are using some scratch registers in MMIO based send function. Make their base and count flexible in preparation of upcoming GuC firmware/hardware changes. While around, change cmd len parameter verification from WARN_ON to GEM_BUG_ON as we don't need this all the time. v2: call out

Re: [Intel-gfx] [PATCH] drm/i915: Update MOCS settings for gen 9

On Thu, May 04, 2017 at 07:46:34PM -0700, Dmitry Rogozhkin wrote: > > > On 5/4/2017 9:51 AM, Kenneth Graunke wrote: > > MediaSDK is not a benchmark. If I'm not mistaken, it's a userspace > > driver produced by Intel engineers, one which Intel has the full > > capability to change. What you're

Re: [Intel-gfx] [PATCHv4 2/3] drm/prime: Introduce drm_gem_prime_import_dev

Hi Laura, [auto build test WARNING on drm/drm-next] [also build test WARNING on next-20170505] [cannot apply to v4.11] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/Laura-Abbott/dma_buf-import

Re: [Intel-gfx] [PATCH 3/9] drm/i915/execlists: Pack the count into the low bits of the port.request

On Fri, May 05, 2017 at 11:49:21AM +0100, Tvrtko Ursulin wrote: > > On 03/05/2017 12:37, Chris Wilson wrote: > >+static void port_assign(struct execlist_port *port, > >+struct drm_i915_gem_request *rq) > >+{ > >+GEM_BUG_ON(rq == port_request(port)); > >+ > >+if

Re: [Intel-gfx] [PATCH 3/9] drm/i915/execlists: Pack the count into the low bits of the port.request

On 03/05/2017 12:37, Chris Wilson wrote: add/remove: 1/1 grow/shrink: 5/4 up/down: 391/-578 (-187) function old new delta execlists_submit_ports 262 471+209 port_assign.isra - 136+136

Re: [Intel-gfx] [PATCH] drm/i915: Fix rawclk readout for g4x

On Fri, May 05, 2017 at 09:48:08AM +0300, Jani Nikula wrote: > On Thu, 04 May 2017, ville.syrj...@linux.intel.com wrote: > > From: Ville Syrjälä > > > > Turns out our skills in decoding the CLKCFG register weren't good > > enough. On this particular elk the answer

Re: [Intel-gfx] i915 4.9 regression: DP AUX CH sanitization no longer working on Asus desktops

On Thu, May 04, 2017 at 02:52:09PM -0600, Daniel Drake wrote: > On Thu, May 4, 2017 at 2:37 PM, Ville Syrjälä > wrote: > > Please check if commit bb1d132935c2 ("drm/i915/vbt: split out defaults > > that are set when there is no VBT") fixes things for you. > > I

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Do not sync RCU during shrinking

== Series Details == Series: drm/i915: Do not sync RCU during shrinking URL : https://patchwork.freedesktop.org/series/24008/ State : success == Summary == Series 24008v1 drm/i915: Do not sync RCU during shrinking https://patchwork.freedesktop.org/api/1.0/series/24008/revisions/1/mbox/ Test

Re: [Intel-gfx] i915 I2C failures with recent chips and docking stations

On Fri, 05 May 2017, Sanford Rockowitz wrote: > I am the author of ddcutil (www.ddcutil.com), a Linux utility that > manages monitor settings using DDC/CI. I am seeing a pattern of user > error reports in which I2C communication is not working when a system > with a recent

Re: [Intel-gfx] [PATCH v1] ACPI: Switch to use generic UUID API

On Fri, May 05, 2017 at 12:50:31PM +0300, Amir Goldstein wrote: > To complete the picture for folks not cc'ed on my patches, > xfs use case suggests there is also justification for the additional helpers: > > uuid_is_null() / uuid_equal() > guid_is_null() / guid_equal() The is_null is useful and

Re: [Intel-gfx] [PATCH] drm/i915/gvt: disable GVT-g if host GuC submission is enabled

On 2017.05.05 11:55:14 +0300, Joonas Lahtinen wrote: > + Daniel > > On ke, 2017-05-03 at 16:36 +0800, Zhenyu Wang wrote: > > On 2017.05.02 16:58:31 +0800, Chuanxiao Dong wrote: > > > > > > Currently GVT-g cannot work properly when host GuC submission > > > is enabled, so disable GVT in this

Re: [Intel-gfx] [PATCH 5/9] drm/i915: Use a define for the default priority [0]

On Fri, May 05, 2017 at 10:21:32AM +0100, Tvrtko Ursulin wrote: > > On 05/05/2017 10:13, Chris Wilson wrote: > >On Fri, May 05, 2017 at 11:31:14AM +0300, Mika Kuoppala wrote: > >>Chris Wilson writes: > >> > >>>On Thu, May 04, 2017 at 04:32:34PM +0300, Joonas Lahtinen

Re: [Intel-gfx] [PATCH] drm/i915: Do not sync RCU during shrinking

On Fri, May 05, 2017 at 12:40:09PM +0300, Joonas Lahtinen wrote: > Due to the complex dependencies between workqueues and RCU, which > are not easily detected by lockdep, do not synchronize RCU during > shrinking. RCU sync gains us very little benefit in real life > scenarios where the amount of

[Intel-gfx] [PATCH] drm/i915: Do not sync RCU during shrinking

Due to the complex dependencies between workqueues and RCU, which are not easily detected by lockdep, do not synchronize RCU during shrinking. RCU sync gains us very little benefit in real life scenarios where the amount of memory used by object backing storage is dominant over the metadata under

Re: [Intel-gfx] [PATCH v1] ACPI: Switch to use generic UUID API

On Fri, 2017-05-05 at 10:06 +0300, Amir Goldstein wrote: > On Fri, May 5, 2017 at 9:20 AM, Dan Williams > wrote: > > On Thu, May 4, 2017 at 2:21 AM, Andy Shevchenko > > wrote: > > > for (i = 0; i < NFIT_UUID_MAX; i++) > > >

Re: [Intel-gfx] [PATCH 5/9] drm/i915: Use a define for the default priority [0]

On 05/05/2017 10:13, Chris Wilson wrote: On Fri, May 05, 2017 at 11:31:14AM +0300, Mika Kuoppala wrote: Chris Wilson writes: On Thu, May 04, 2017 at 04:32:34PM +0300, Joonas Lahtinen wrote: On ke, 2017-05-03 at 12:37 +0100, Chris Wilson wrote: Explicitly assign

Re: [Intel-gfx] [PATCH V6] drm/i915: Disable stolen memory when i915 runs in guest vm

On ke, 2017-05-03 at 09:22 +, Zhang, Xiong Y wrote: > > > > > > > > + David and Jon > > > > > > On ti, 2017-04-25 at 18:34 +0800, Xiong Zhang wrote: > > > > > > The blocking issue I see is that bisecting is still not pointing at > > > relevant commits. Both bisected commits from Bugzilla

Re: [Intel-gfx] [PATCH V6] drm/i915: Disable stolen memory when i915 runs in guest vm

On to, 2017-04-27 at 05:54 +, Zhang, Xiong Y wrote: > > > > Also, was fixing the IGD driver loading with zero stolen memory > > considered instead? All this information should exist in the commit > > message. > [Zhang, Xiong Y] IGD and i915 driver read pci config register 0x50 to get  > the

Re: [Intel-gfx] [PATCH 5/9] drm/i915: Use a define for the default priority [0]

On Fri, May 05, 2017 at 11:31:14AM +0300, Mika Kuoppala wrote: > Chris Wilson writes: > > > On Thu, May 04, 2017 at 04:32:34PM +0300, Joonas Lahtinen wrote: > >> On ke, 2017-05-03 at 12:37 +0100, Chris Wilson wrote: > >> > Explicitly assign the default priority, and

Re: [Intel-gfx] [PATCH] drm/i915/gvt: disable GVT-g if host GuC submission is enabled

On Fri, May 05, 2017 at 11:55:14AM +0300, Joonas Lahtinen wrote: > + Daniel > > On ke, 2017-05-03 at 16:36 +0800, Zhenyu Wang wrote: > > On 2017.05.02 16:58:31 +0800, Chuanxiao Dong wrote: > > > > > > Currently GVT-g cannot work properly when host GuC submission > > > is enabled, so disable GVT

  1   2   >