Re: [Intel-gfx] GuC based SLPC

2019-01-23 Thread Tvrtko Ursulin
On 24/01/2019 05:07, Kedar J. Karanje wrote: Hello All, Could some one please let me know who can we contact for the below patch series https://patchwork.freedesktop.org/series/2691/ https://patchwork.freedesktop.org/series/11356/ The mail-ids mentioned in patchwork are failing. Maybe

[Intel-gfx] [PATCH i-g-t] How far have we got in converting the world to igt_dummyload?

2019-01-23 Thread Chris Wilson
--- lib/igt_dummyload.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/lib/igt_dummyload.c b/lib/igt_dummyload.c index 982906f29..7ea6793d4 100644 --- a/lib/igt_dummyload.c +++ b/lib/igt_dummyload.c @@ -91,6 +91,8 @@ emit_recursive_batch(igt_spin_t *spin, uint32_t *batch,

Re: [Intel-gfx] [PATCH v9 5/7] drm/i915: keep track of used entries in MOCS table

2019-01-23 Thread Chris Wilson
Quoting Lucas De Marchi (2019-01-24 00:06:02) > Instead of considering we have defined entries for any index in the > table, let's keep track of the ones we explicitly defined. This will > allow Gen 11 to have it's new table defined in which we have holes of > undefined entries. > > Repeated

Re: [Intel-gfx] [PATCH v9 4/7] drm/i915: use a macro to define MOCS entries

2019-01-23 Thread Chris Wilson
Quoting Lucas De Marchi (2019-01-24 00:06:01) > Let's use a macro to make tables smaller and at the same time allow us > to add fields that apply to all entries in future. > > v2: rewrap lines to respect 80 chars limit and make it more readable > (from Chris) > > Signed-off-by: Lucas De

Re: [Intel-gfx] [PATCH v2 7/7] drm/i915/crt: simplify CRT VBT check on pre-VLV/DDI

2019-01-23 Thread Jani Nikula
On Wed, 23 Jan 2019, Ville Syrjälä wrote: > On Tue, Jan 22, 2019 at 10:23:07AM +0200, Jani Nikula wrote: >> The VBT int_crt_support can't be trusted on earlier platforms, and is >> always set to true in intel_bios.c for pre-DDI and pre-VLV platforms. We >> can simplify the output setup by

Re: [Intel-gfx] [PATCH i-g-t] lib: Be strict in applying verification for spin batch

2019-01-23 Thread Chris Wilson
Quoting Chris Wilson (2019-01-24 07:31:41) > We want to test batch promotion fully, so be strict in asking for it. Bah, it's not poll per se we need to check. Do we need a new flag? -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org

[Intel-gfx] [PATCH i-g-t] lib: Be strict in applying verification for spin batch

2019-01-23 Thread Chris Wilson
We want to test batch promotion fully, so be strict in asking for it. Signed-off-by: Chris Wilson Cc: Mika Kuoppala --- lib/i915/gem_submission.c | 12 lib/i915/gem_submission.h | 6 ++ lib/igt_dummyload.c | 5 + 3 files changed, 23 insertions(+) diff --git

Re: [Intel-gfx] [PATCH] drm/modes: Prevent division by zero htotal

2019-01-23 Thread Zhang, Tina
> -Original Message- > From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch] On Behalf Of Daniel Vetter > Sent: Wednesday, January 23, 2019 6:56 PM > To: Zhang, Tina > Cc: intel-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org; Adam > Jackson ; Dave Airlie ; Daniel Vetter > >

[Intel-gfx] [PULL] gvt-fixes

2019-01-23 Thread Zhenyu Wang
Hi, Here's one fix for gvt to destroy shadow batch and indirect context properly. Thanks. -- The following changes since commit 51b00d8509dc69c98740da2ad07308b630d3eb7d: drm/i915/gvt: Fix mmap range check (2019-01-15 19:04:45 +0800) are available in the Git repository at:

[Intel-gfx] GuC based SLPC

2019-01-23 Thread Kedar J. Karanje
Hello All, Could some one please let me know who can we contact for the below patch series https://patchwork.freedesktop.org/series/2691/ https://patchwork.freedesktop.org/series/11356/ The mail-ids mentioned in patchwork are failing. Thanks, Kedar

[Intel-gfx] [PULL] gvt-next

2019-01-23 Thread Zhenyu Wang
Hi, Here is gvt-next stuff. This includes Coffeelake support for GVT, making kvmgt as self load module to have better dependence with vfio/mdev, with some const treatment and kernel type change. Thanks. -- The following changes since commit d1810909d841314ba94b14dc3de9e9fbc13b046a:

Re: [Intel-gfx] [PATCH 4/5] drm/i915/icl: keep track of unused pll while looping

2019-01-23 Thread Paulo Zanoni
Em qui, 2019-01-17 às 12:21 -0800, Lucas De Marchi escreveu: > Instead of looping again on the range of plls, just keep track of one > unused one and use it later. > Reviewed-by: Paulo Zanoni > Signed-off-by: Lucas De Marchi > --- > drivers/gpu/drm/i915/intel_dpll_mgr.c | 19

[Intel-gfx] ✓ Fi.CI.IGT: success for Define MOCS table for Icelake (rev3)

2019-01-23 Thread Patchwork
== Series Details == Series: Define MOCS table for Icelake (rev3) URL : https://patchwork.freedesktop.org/series/54070/ State : success == Summary == CI Bug Log - changes from CI_DRM_5471_full -> Patchwork_12021_full Summary ---

Re: [Intel-gfx] [PATCH 3/5] drm/i915/icl: remove dpll from clk_sel

2019-01-23 Thread Paulo Zanoni
Em qui, 2019-01-17 às 12:21 -0800, Lucas De Marchi escreveu: > We should not pass DPLL_ID_ICL_DPLL0 or DPLL_ID_ICL_DPLL1 to this > function because the path is only taken for non-combophy ports. Let the > warning trigger if improper value is given. > > While at it, rename the function to match

Re: [Intel-gfx] [PATCH 1/5] drm/i915/icl: use tc_port in MG_PLL macros

2019-01-23 Thread Paulo Zanoni
Em qui, 2019-01-17 às 12:21 -0800, Lucas De Marchi escreveu: > Fix the TODO leftover in the code by changing the argument in MG_PLL > macros. The MG_PLL ids used to access the register values can be > converted from tc_port rather than port. > An explanation on why the new model is better would

[Intel-gfx] ✓ Fi.CI.BAT: success for Define MOCS table for Icelake (rev3)

2019-01-23 Thread Patchwork
== Series Details == Series: Define MOCS table for Icelake (rev3) URL : https://patchwork.freedesktop.org/series/54070/ State : success == Summary == CI Bug Log - changes from CI_DRM_5471 -> Patchwork_12021 Summary --- **SUCCESS**

Re: [Intel-gfx] [PATCH v4 1/2] drm: Add color management LUT validation helper (v4)

2019-01-23 Thread Matt Roper
On Sat, Jan 12, 2019 at 01:07:14PM +0100, Daniel Vetter wrote: > On Fri, Jan 11, 2019 at 02:27:00PM -0800, Matt Roper wrote: > > Dave, Daniel - any concerns if we merge this drm core patch through the > > Intel tree? The second patch in the series doesn't apply cleanly in > > drm-misc-next. > >

Re: [Intel-gfx] [RFC] drm/i915/dp: Preliminary support for 2 pipe 1 port mode for 5K@120

2019-01-23 Thread Manasi Navare
Hi Ville/Maarten/Matt, Thanks for all your comments, please see my comments/concerns below On Wed, Jan 23, 2019 at 06:58:22PM +0200, Ville Syrjälä wrote: > On Tue, Jan 22, 2019 at 01:12:07PM -0800, Manasi Navare wrote: > > On Gen 11 platform, to enable resolutions like 5K@120 where > > the pixel

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for Define MOCS table for Icelake (rev3)

2019-01-23 Thread Patchwork
== Series Details == Series: Define MOCS table for Icelake (rev3) URL : https://patchwork.freedesktop.org/series/54070/ State : warning == Summary == $ dim checkpatch origin/drm-tip 655b6926dbca drm/i915: initialize unused MOCS entries to PTE 2bef84e70dcf drm/i915: Simplify MOCS table

Re: [Intel-gfx] drm/i915: Only process VCS2 only when supported

2019-01-23 Thread Carlos Santa
On Mon, 2019-01-07 at 12:40 +, Tvrtko Ursulin wrote: > On 05/01/2019 02:39, Carlos Santa wrote: > > Not checking for BSD2 causes a segfault on GPU revs > > with no h/w support for the extra media engines. > > > > Segfault on ULX GT2 (0x591e) follows: > > > > Patch shared by Michel Thierry on

Re: [Intel-gfx] drm/i915: Watchdog timeout: IRQ handler for gen8+

2019-01-23 Thread Carlos Santa
On Mon, 2019-01-07 at 11:58 +, Tvrtko Ursulin wrote: [snip] > > > > > > static void gen8_gt_irq_ack(struct drm_i915_private *i915, > > @@ -3329,7 +3332,7 @@ void i915_handle_error(struct > > drm_i915_private *dev_priv, > > if (intel_has_reset_engine(dev_priv) && > >

[Intel-gfx] [PATCH v9 6/7] drm/i915: cache number of MOCS entries

2019-01-23 Thread Lucas De Marchi
Instead of checking the gen number every time we need to know the max number of entries, just save it into the table struct so we don't need extra branches throughout the code. This will be useful for Ice Lake that has 64 rather than 62 defined entries. Ice Lake changes will be added in a follow

[Intel-gfx] [PATCH v9 7/7] drm/i915/icl: Define MOCS table for Icelake

2019-01-23 Thread Lucas De Marchi
From: Tomasz Lis The table has been unified across OSes to minimize virtualization overhead. The MOCS table is now published as part of bspec, and versioned. Entries are supposed to never be modified, but new ones can be added. Adding entries increases table version. The patch includes version

[Intel-gfx] [PATCH v9 4/7] drm/i915: use a macro to define MOCS entries

2019-01-23 Thread Lucas De Marchi
Let's use a macro to make tables smaller and at the same time allow us to add fields that apply to all entries in future. v2: rewrap lines to respect 80 chars limit and make it more readable (from Chris) Signed-off-by: Lucas De Marchi Reviewed-by: Tomasz Lis ---

[Intel-gfx] [PATCH v9 1/7] drm/i915: initialize unused MOCS entries to PTE

2019-01-23 Thread Lucas De Marchi
Instead of initializing them to uncached, let's set them to PTE for kernel tracking. While at it do some minor adjustments to comments and coding style. From Chris: "What it does mean is that the buffer contents are consistent with our cache tracking; and for userspace the results were always

[Intel-gfx] [PATCH v9 3/7] drm/i915/skl: Rework MOCS tables to keep common part in a define

2019-01-23 Thread Lucas De Marchi
From: Tomasz Lis The MOCS tables are going to be very similar across platforms. To reduce the amount of copied code, this patch rips the common part and puts it into a definition valid for all gen9 platforms. v2: Made defines for or-ing flags. Renamed macros from MOCS_TABLE to

[Intel-gfx] [PATCH v9 0/7] Define MOCS table for Icelake

2019-01-23 Thread Lucas De Marchi
v9 of https://patchwork.freedesktop.org/series/54070/ Changes: - Add the R-b received - Wrap lines in "drm/i915: use a macro to define MOCS entries" - Add helper functions in "drm/i915: keep track of used entries in MOCS table" Lucas De Marchi (5): drm/i915: initialize unused MOCS

[Intel-gfx] [PATCH v9 2/7] drm/i915: Simplify MOCS table definition

2019-01-23 Thread Lucas De Marchi
Make the defines for LE and L3 caching options to contain the shifts and remove the zeros from the tables as shifting zeros always result in zero. Starting from Ice Lake the MOCS table is defined in the spec and contains all entries. So to simplify checking the table with the values set in code,

[Intel-gfx] [PATCH v9 5/7] drm/i915: keep track of used entries in MOCS table

2019-01-23 Thread Lucas De Marchi
Instead of considering we have defined entries for any index in the table, let's keep track of the ones we explicitly defined. This will allow Gen 11 to have it's new table defined in which we have holes of undefined entries. Repeated comments about the meaning of undefined entries were removed

Re: [Intel-gfx] [PATCH 25/34] drm/i915: Track active timelines

2019-01-23 Thread Chris Wilson
Quoting John Harrison (2019-01-23 22:32:54) > On 1/22/2019 07:17, Chris Wilson wrote: > > Quoting Tvrtko Ursulin (2019-01-22 14:56:32) > >> On 21/01/2019 22:21, Chris Wilson wrote: > >>> +static void timeline_active(struct i915_timeline *tl) > >>> +{ > >>> + struct i915_gt_timelines *gt =

[Intel-gfx] [PATCH i-g-t] i915/gem_sync: Make switch-default asymmetric

2019-01-23 Thread Chris Wilson
To make the demonstration of the cheeky preemption more impactful, make the second context a nop to contrast the first being 1024 MI_STORE_DWORD_IMM. Then if we execute and wait on the second context before executing the first, the client latency is even more drastically reduced. To more clearly

Re: [Intel-gfx] [PATCH 25/34] drm/i915: Track active timelines

2019-01-23 Thread John Harrison
On 1/22/2019 07:17, Chris Wilson wrote: Quoting Tvrtko Ursulin (2019-01-22 14:56:32) On 21/01/2019 22:21, Chris Wilson wrote: Now that we pin timelines around use, we have a clearly defined lifetime and convenient points at which we can track only the active timelines. This allows us to reduce

Re: [Intel-gfx] [PATCH v8 5/7] drm/i915: keep track of used entries in MOCS table

2019-01-23 Thread Lucas De Marchi
On Tue, Jan 22, 2019 at 02:40:48PM +, Chris Wilson wrote: Quoting Lucas De Marchi (2019-01-22 05:12:25) Instead of considering we have defined entries for any index in the table, let's keep track of the ones we explicitly defined. This will allow Gen 11 to have it's new table defined in

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/icl: Delay hotplug sequence for TC ports

2019-01-23 Thread Patchwork
== Series Details == Series: drm/i915/icl: Delay hotplug sequence for TC ports URL : https://patchwork.freedesktop.org/series/55649/ State : success == Summary == CI Bug Log - changes from CI_DRM_5471_full -> Patchwork_12020_full Summary

Re: [Intel-gfx] [PATCH 1/3] treewide: Lift switch variables out of switches

2019-01-23 Thread Kees Cook
On Thu, Jan 24, 2019 at 8:18 AM Matthew Wilcox wrote: > > On Wed, Jan 23, 2019 at 04:17:30PM +0200, Jani Nikula wrote: > > Can't have: > > > > switch (i) { > > int j; > > case 0: > > /* ... */ > > } > > > > because it can't be turned into: > > > >

[Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [v2,1/2] drm/i915/execlists: Suppress preempting self

2019-01-23 Thread Patchwork
== Series Details == Series: series starting with [v2,1/2] drm/i915/execlists: Suppress preempting self URL : https://patchwork.freedesktop.org/series/55648/ State : success == Summary == CI Bug Log - changes from CI_DRM_5471_full -> Patchwork_12019_full

Re: [Intel-gfx] [PATCH 1/3] treewide: Lift switch variables out of switches

2019-01-23 Thread Matthew Wilcox
On Wed, Jan 23, 2019 at 04:17:30PM +0200, Jani Nikula wrote: > Can't have: > > switch (i) { > int j; > case 0: > /* ... */ > } > > because it can't be turned into: > > switch (i) { > int j = 0; /* not valid C */ > case 0: >

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/icl: Delay hotplug sequence for TC ports

2019-01-23 Thread Patchwork
== Series Details == Series: drm/i915/icl: Delay hotplug sequence for TC ports URL : https://patchwork.freedesktop.org/series/55649/ State : success == Summary == CI Bug Log - changes from CI_DRM_5471 -> Patchwork_12020 Summary ---

Re: [Intel-gfx] [PATCH v8 7/7] drm/i915/icl: Define MOCS table for Icelake

2019-01-23 Thread Lis, Tomasz
On 2019-01-22 06:12, Lucas De Marchi wrote: From: Tomasz Lis The table has been unified across OSes to minimize virtualization overhead. The MOCS table is now published as part of bspec, and versioned. Entries are supposed to never be modified, but new ones can be added. Adding entries

Re: [Intel-gfx] [PATCH v8 6/7] drm/i915: cache number of MOCS entries

2019-01-23 Thread Lis, Tomasz
On 2019-01-22 06:12, Lucas De Marchi wrote: Instead of checking the gen number every time we need to know the max number of entries, just save it into the table struct so we don't need extra branches throughout the code. This will be useful for Ice Lake that has 64 rather than 62 defined

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915/icl: Delay hotplug sequence for TC ports

2019-01-23 Thread Patchwork
== Series Details == Series: drm/i915/icl: Delay hotplug sequence for TC ports URL : https://patchwork.freedesktop.org/series/55649/ State : warning == Summary == $ dim sparse origin/drm-tip Sparse version: v0.5.2 Commit: drm/i915/icl: Delay hotplug sequence for TC ports

Re: [Intel-gfx] [PATCH 1/3] treewide: Lift switch variables out of switches

2019-01-23 Thread Kees Cook
On Thu, Jan 24, 2019 at 4:44 AM Jani Nikula wrote: > > On Wed, 23 Jan 2019, Edwin Zimmerman wrote: > > On Wed, 23 Jan 2019, Jani Nikula wrote: > >> On Wed, 23 Jan 2019, Greg KH wrote: > >> > On Wed, Jan 23, 2019 at 03:03:47AM -0800, Kees Cook wrote: > >> >> Variables declared in a switch

Re: [Intel-gfx] [PATCH v8 4/7] drm/i915: use a macro to define MOCS entries

2019-01-23 Thread Lucas De Marchi
On Tue, Jan 22, 2019 at 09:37:02PM +, Chris Wilson wrote: Quoting Lucas De Marchi (2019-01-22 21:33:25) On Tue, Jan 22, 2019 at 6:32 AM Chris Wilson wrote: > > Quoting Lucas De Marchi (2019-01-22 05:12:24) > > Let's use a macro to make tables smaller and at the same time allow us > > to

[Intel-gfx] [PATCH] drm/i915/icl: Delay hotplug sequence for TC ports

2019-01-23 Thread José Roberto de Souza
Some unpowered USB type-c dongles requires some time to power on before being able to process aux channel transactions. It was not a problem for older platforms because there was a hardware bridge between DDI/DP ports and type-c controller adding a implicit delay that hid this issue but ICL have

Re: [Intel-gfx] [PATCH v8 5/7] drm/i915: keep track of used entries in MOCS table

2019-01-23 Thread Lis, Tomasz
On 2019-01-22 06:12, Lucas De Marchi wrote: Instead of considering we have defined entries for any index in the table, let's keep track of the ones we explicitly defined. This will allow Gen 11 to have it's new table defined in which we have holes of undefined entries. Repeated comments about

Re: [Intel-gfx] [PATCH v8 4/7] drm/i915: use a macro to define MOCS entries

2019-01-23 Thread Lis, Tomasz
On 2019-01-22 06:12, Lucas De Marchi wrote: Let's use a macro to make tables smaller and at the same time allow us to add fields that apply to all entries in future. For the sake of readability, I'm calling an exception on 80 chars limit. Lines are aligned for easy comparison of the entry

Re: [Intel-gfx] [PATCH v8 1/7] drm/i915: initialize unused MOCS entries to PTE

2019-01-23 Thread Lucas De Marchi
On Wed, Jan 23, 2019 at 07:33:35PM +0100, Tomasz Lis wrote: On 2019-01-22 06:12, Lucas De Marchi wrote: Instead of initializing them to uncached, let's set them to PTE for kernel tracking. While at it do some minor adjustments to comments and coding style. Signed-off-by: Lucas De Marchi

Re: [Intel-gfx] [PATCH] drm/i915/icl: do a posting read after irq install

2019-01-23 Thread Daniele Ceraolo Spurio
On 01/23/2019 03:40 AM, Mika Kuoppala wrote: Daniele Ceraolo Spurio writes: On 1/22/2019 6:32 PM, Daniele Ceraolo Spurio wrote: When reading GEN11_GT_INTR_DWx closely after enabling the interrupts in gen11_irq_postinstall, the returned value is garbage. This can To clarify, this only

Re: [Intel-gfx] [PATCH v2 7/7] drm/i915/crt: simplify CRT VBT check on pre-VLV/DDI

2019-01-23 Thread Ville Syrjälä
On Tue, Jan 22, 2019 at 10:23:07AM +0200, Jani Nikula wrote: > The VBT int_crt_support can't be trusted on earlier platforms, and is > always set to true in intel_bios.c for pre-DDI and pre-VLV platforms. We > can simplify the output setup by unconditionally calling > intel_crt_init() for these

Re: [Intel-gfx] [PATCH v2 6/7] drm/i915/lvds: simplify gen 2 lvds presence

2019-01-23 Thread Ville Syrjälä
On Tue, Jan 22, 2019 at 10:23:06AM +0200, Jani Nikula wrote: > Gen 2 mobile and not I830 is, in fact, I85X. Simplify. > > Suggested-by: Ville Syrjälä > Signed-off-by: Jani Nikula Reviewed-by: Ville Syrjälä > --- > drivers/gpu/drm/i915/intel_display.c | 2 +- > 1 file changed, 1

Re: [Intel-gfx] [PATCH v2 5/7] drm/i915: rename has_edp_a() to ilk_has_edp_a()

2019-01-23 Thread Ville Syrjälä
On Tue, Jan 22, 2019 at 10:23:05AM +0200, Jani Nikula wrote: > Clarify that the name is specific to ILK+ PCH platforms. > > v2: prefix the name with ilk rather than pch (Ville) > > Signed-off-by: Jani Nikula Reviewed-by: Ville Syrjälä > --- > drivers/gpu/drm/i915/intel_display.c | 4 ++-- >

Re: [Intel-gfx] [PATCH v8 3/7] drm/i915/skl: Rework MOCS tables to keep common part in a define

2019-01-23 Thread Lis, Tomasz
On 2019-01-22 06:12, Lucas De Marchi wrote: From: Tomasz Lis The MOCS tables are going to be very similar across platforms. To reduce the amount of copied code, this patch rips the common part and puts it into a definition valid for all gen9 platforms. v2: Made defines for or-ing flags.

Re: [Intel-gfx] [PATCH v8 1/7] drm/i915: initialize unused MOCS entries to PTE

2019-01-23 Thread Lis, Tomasz
On 2019-01-22 06:12, Lucas De Marchi wrote: Instead of initializing them to uncached, let's set them to PTE for kernel tracking. While at it do some minor adjustments to comments and coding style. Signed-off-by: Lucas De Marchi Reviewed-by: Tomasz Lis One comment (with no expectations for

Re: [Intel-gfx] [PATCH v8 2/7] drm/i915: Simplify MOCS table definition

2019-01-23 Thread Lis, Tomasz
On 2019-01-22 06:12, Lucas De Marchi wrote: Make the defines for LE and L3 caching options to contain the shifts and remove the zeros from the tables as shifting zeros always result in zero. Starting from Ice Lake the MOCS table is defined in the spec and contains all entries. So to simplify

Re: [Intel-gfx] [PATCH] drm/i915: Avoid divide by zero

2019-01-23 Thread Ville Syrjälä
On Wed, Jan 23, 2019 at 07:21:57AM +, Kahola, Mika wrote: > On Tue, 2019-01-22 at 21:09 +0200, Ville Syrjälä wrote: > > On Tue, Jan 22, 2019 at 08:09:40PM +0200, Jani Nikula wrote: > > > On Tue, 22 Jan 2019, Ville Syrjälä > > > wrote: > > > > On Tue, Jan 22, 2019 at 02:58:24PM +0200, Mika

[Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [1/3] drm/i915/execlists: Mark up priority boost on preemption (rev2)

2019-01-23 Thread Patchwork
== Series Details == Series: series starting with [1/3] drm/i915/execlists: Mark up priority boost on preemption (rev2) URL : https://patchwork.freedesktop.org/series/55638/ State : success == Summary == CI Bug Log - changes from CI_DRM_5470_full -> Patchwork_12017_full

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [v2,1/2] drm/i915/execlists: Suppress preempting self

2019-01-23 Thread Patchwork
== Series Details == Series: series starting with [v2,1/2] drm/i915/execlists: Suppress preempting self URL : https://patchwork.freedesktop.org/series/55648/ State : success == Summary == CI Bug Log - changes from CI_DRM_5471 -> Patchwork_12019

Re: [Intel-gfx] [PATCH 2/5] drm/i915: always return something

2019-01-23 Thread Lucas De Marchi
On Wed, Jan 23, 2019 at 04:19:30PM +0200, Joonas Lahtinen wrote: The subject of this patch could really be bit more specific "... on DDI clock selection". Fixed. I'll wait for reviews on other patches to re-spin this series as it's already conflicting. thanks Lucas De Marchi Regards,

Re: [Intel-gfx] [PATCH 0/5] icl: Misc PLL patches

2019-01-23 Thread Lucas De Marchi
CC'ing people who have commits related to this series. Could you take a look on it? thanks Lucas De Marchi On Thu, Jan 17, 2019 at 12:21:08PM -0800, Lucas De Marchi wrote: Some PLL reworks on ICL. Patches are more or less independent of each other, but touch the same part of the code. Lucas

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for series starting with [v2,1/2] drm/i915/execlists: Suppress preempting self

2019-01-23 Thread Patchwork
== Series Details == Series: series starting with [v2,1/2] drm/i915/execlists: Suppress preempting self URL : https://patchwork.freedesktop.org/series/55648/ State : warning == Summary == $ dim sparse origin/drm-tip Sparse version: v0.5.2 Commit: drm/i915/execlists: Suppress preempting self

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [v2,1/2] drm/i915/execlists: Suppress preempting self

2019-01-23 Thread Patchwork
== Series Details == Series: series starting with [v2,1/2] drm/i915/execlists: Suppress preempting self URL : https://patchwork.freedesktop.org/series/55648/ State : warning == Summary == $ dim checkpatch origin/drm-tip b7170f749928 drm/i915/execlists: Suppress preempting self -:22:

[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [1/3] drm/i915/execlists: Mark up priority boost on preemption (rev3)

2019-01-23 Thread Patchwork
== Series Details == Series: series starting with [1/3] drm/i915/execlists: Mark up priority boost on preemption (rev3) URL : https://patchwork.freedesktop.org/series/55638/ State : failure == Summary == Applying: drm/i915/execlists: Mark up priority boost on preemption Using index info to

[Intel-gfx] [PATCH v2 1/2] drm/i915/execlists: Suppress preempting self

2019-01-23 Thread Chris Wilson
In order to avoid preempting ourselves, we currently refuse to schedule the tasklet if we reschedule an inflight context. However, this glosses over a few issues such as what happens after a CS completion event and we then preempt the newly executing context with itself, or if something else

[Intel-gfx] [PATCH v2 2/2] drm/i915/execlists: Suppress redundant preemption

2019-01-23 Thread Chris Wilson
On unwinding the active request we give it a small (limited to internal priority levels) boost to prevent it from being gazumped a second time. However, this means that it can be promoted to above the request that triggered the preemption request, causing a preempt-to-idle cycle for no change. We

[Intel-gfx] [PATCH v2] drm/i915/execlists: Suppress preempting self

2019-01-23 Thread Chris Wilson
In order to avoid preempting ourselves, we currently refuse to schedule the tasklet if we reschedule an inflight context. However, this glosses over a few issues such as what happens after a CS completion event and we then preempt the newly executing context with itself, or if something else

Re: [Intel-gfx] [RFC] drm/i915/dp: Preliminary support for 2 pipe 1 port mode for 5K@120

2019-01-23 Thread Matt Roper
On Tue, Jan 22, 2019 at 01:12:07PM -0800, Manasi Navare wrote: > On Gen 11 platform, to enable resolutions like 5K@120 where > the pixel clock is greater than pipe pixel rate, we need to split it across > 2 pipes and enable it using DSC and big joiner. In order to support this > dual pipe single

Re: [Intel-gfx] [PATCH 2/3] drm/i915/execlists: Suppress preempting self

2019-01-23 Thread Chris Wilson
Quoting Tvrtko Ursulin (2019-01-23 16:40:44) > > On 23/01/2019 14:22, Chris Wilson wrote: > > Quoting Tvrtko Ursulin (2019-01-23 14:08:56) > >> > >> On 23/01/2019 12:36, Chris Wilson wrote: > >>> In order to avoid preempting ourselves, we currently refuse to schedule > >>> the tasklet if we

Re: [Intel-gfx] [PATCH] drm: Split out drm_probe_helper.h

2019-01-23 Thread Sam Ravnborg
Hi Daniel. On Thu, Jan 17, 2019 at 10:03:34PM +0100, Daniel Vetter wrote: > Having the probe helper stuff (which pretty much everyone needs) in > the drm_crtc_helper.h file (which atomic drivers should never need) is > confusing. Split them out. > > To make sure I actually achieved the goal here

Re: [Intel-gfx] [RFC] drm/i915/dp: Preliminary support for 2 pipe 1 port mode for 5K@120

2019-01-23 Thread Ville Syrjälä
On Tue, Jan 22, 2019 at 01:12:07PM -0800, Manasi Navare wrote: > On Gen 11 platform, to enable resolutions like 5K@120 where > the pixel clock is greater than pipe pixel rate, we need to split it across > 2 pipes and enable it using DSC and big joiner. In order to support this > dual pipe single

Re: [Intel-gfx] [PATCH 1/3] treewide: Lift switch variables out of switches

2019-01-23 Thread Jann Horn
On Wed, Jan 23, 2019 at 1:04 PM Greg KH wrote: > On Wed, Jan 23, 2019 at 03:03:47AM -0800, Kees Cook wrote: > > Variables declared in a switch statement before any case statements > > cannot be initialized, so move all instances out of the switches. > > After this, future always-initialized stack

Re: [Intel-gfx] [PATCH 1/3] treewide: Lift switch variables out of switches

2019-01-23 Thread Ard Biesheuvel
On Wed, 23 Jan 2019 at 13:09, Jann Horn wrote: > > On Wed, Jan 23, 2019 at 1:04 PM Greg KH wrote: > > On Wed, Jan 23, 2019 at 03:03:47AM -0800, Kees Cook wrote: > > > Variables declared in a switch statement before any case statements > > > cannot be initialized, so move all instances out of the

Re: [Intel-gfx] [PATCH 1/3] treewide: Lift switch variables out of switches

2019-01-23 Thread William Kucharski
> On Jan 23, 2019, at 5:09 AM, Jann Horn wrote: > > AFAICS this only applies to switch statements (because they jump to a > case and don't execute stuff at the start of the block), not blocks > after if/while/... . It bothers me that we are going out of our way to deprecate valid C constructs

Re: [Intel-gfx] [PATCH 1/3] treewide: Lift switch variables out of switches

2019-01-23 Thread Edwin Zimmerman
On Wed, 23 Jan 2019, Jani Nikula wrote: > On Wed, 23 Jan 2019, Greg KH wrote: > > On Wed, Jan 23, 2019 at 03:03:47AM -0800, Kees Cook wrote: > >> Variables declared in a switch statement before any case statements > >> cannot be initialized, so move all instances out of the switches. > >> After

Re: [Intel-gfx] [Intel-wired-lan] [PATCH 1/3] treewide: Lift switch variables out of switches

2019-01-23 Thread Jeff Kirsher
On Wed, 2019-01-23 at 03:03 -0800, Kees Cook wrote: > Variables declared in a switch statement before any case statements > cannot be initialized, so move all instances out of the switches. > After this, future always-initialized stack variables will work > and not throw warnings like this: > >

Re: [Intel-gfx] [PATCH] iommu/intel: quirk to disable DMAR for QM57 igfx

2019-01-23 Thread Joerg Roedel
On Wed, Jan 23, 2019 at 05:02:38PM +0200, Joonas Lahtinen wrote: > We have many reports where just having intel_iommu=on (and using the > system normally, without any virtualization stuff going on) will cause > unexplained GPU hangs. For those users, simply switching to > intel_iommu=igfx_off

Re: [Intel-gfx] [PATCH 2/3] drm/i915/execlists: Suppress preempting self

2019-01-23 Thread Tvrtko Ursulin
On 23/01/2019 14:22, Chris Wilson wrote: Quoting Tvrtko Ursulin (2019-01-23 14:08:56) On 23/01/2019 12:36, Chris Wilson wrote: In order to avoid preempting ourselves, we currently refuse to schedule the tasklet if we reschedule an inflight context. However, this glosses over a few issues

Re: [Intel-gfx] [PATCH 14/15] drm/i915/tv: Fix >1024 modes on gen3

2019-01-23 Thread Ville Syrjälä
On Wed, Jan 23, 2019 at 03:49:02PM +0200, Imre Deak wrote: > On Mon, Nov 12, 2018 at 06:59:59PM +0200, Ville Syrjala wrote: > > From: Ville Syrjälä > > > > On gen3 we must disable the TV encoder vertical filter for >1024 > > pixel wide sources. Once that's done all we can is try to center > >

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/execlists: Mark up priority boost on preemption

2019-01-23 Thread Patchwork
== Series Details == Series: drm/i915/execlists: Mark up priority boost on preemption URL : https://patchwork.freedesktop.org/series/55641/ State : success == Summary == CI Bug Log - changes from CI_DRM_5470_full -> Patchwork_12016_full

Re: [Intel-gfx] [PATCH 28/34] drm/i915: Replace global breadcrumbs with per-context interrupt tracking

2019-01-23 Thread Tvrtko Ursulin
On 23/01/2019 10:01, Chris Wilson wrote: Quoting Tvrtko Ursulin (2019-01-23 09:21:45) On 21/01/2019 22:21, Chris Wilson wrote: -static void error_record_engine_waiters(struct intel_engine_cs *engine, - struct drm_i915_error_engine *ee) -{ - struct

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/3] drm/i915/execlists: Mark up priority boost on preemption (rev2)

2019-01-23 Thread Patchwork
== Series Details == Series: series starting with [1/3] drm/i915/execlists: Mark up priority boost on preemption (rev2) URL : https://patchwork.freedesktop.org/series/55638/ State : success == Summary == CI Bug Log - changes from CI_DRM_5470 -> Patchwork_12017

Re: [Intel-gfx] [PATCH 1/3] treewide: Lift switch variables out of switches

2019-01-23 Thread Jani Nikula
On Wed, 23 Jan 2019, Edwin Zimmerman wrote: > On Wed, 23 Jan 2019, Jani Nikula wrote: >> On Wed, 23 Jan 2019, Greg KH wrote: >> > On Wed, Jan 23, 2019 at 03:03:47AM -0800, Kees Cook wrote: >> >> Variables declared in a switch statement before any case statements >> >> cannot be initialized, so

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for series starting with [1/3] drm/i915/execlists: Mark up priority boost on preemption (rev2)

2019-01-23 Thread Patchwork
== Series Details == Series: series starting with [1/3] drm/i915/execlists: Mark up priority boost on preemption (rev2) URL : https://patchwork.freedesktop.org/series/55638/ State : warning == Summary == $ dim sparse origin/drm-tip Sparse version: v0.5.2 Commit: drm/i915/execlists: Mark up

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [1/3] drm/i915/execlists: Mark up priority boost on preemption (rev2)

2019-01-23 Thread Patchwork
== Series Details == Series: series starting with [1/3] drm/i915/execlists: Mark up priority boost on preemption (rev2) URL : https://patchwork.freedesktop.org/series/55638/ State : warning == Summary == $ dim checkpatch origin/drm-tip 8de30aea3cc3 drm/i915/execlists: Mark up priority boost

[Intel-gfx] [PATCH i-g-t] intel-ci: Drop gem_exec_nop from BAT

2019-01-23 Thread Chris Wilson
This pair, gem_exec_nop/{series,parallel}, are very light stress tests of which we already perform the same sequence inside i915_selftests/live_requests. We keep basic uABI coverage (i.e. plain old gem_execbuf) via the likes of gem_exec_basic and gem_exec_reloc so all gem_exec_nop adds are

[Intel-gfx] [PATCH v2] drm/i915/execlists: Suppress redundant preemption

2019-01-23 Thread Chris Wilson
On unwinding the active request we give it a small (limited to internal priority levels) boost to prevent it from being gazumped a second time. However, this means that it can be promoted to above the request that triggered the preemption request, causing a preempt-to-idle cycle for no change. We

Re: [Intel-gfx] [PATCH] iommu/intel: quirk to disable DMAR for QM57 igfx

2019-01-23 Thread Joonas Lahtinen
Quoting Joerg Roedel (2019-01-22 18:51:35) > On Tue, Jan 22, 2019 at 04:48:26PM +0200, Joonas Lahtinen wrote: > > According to our IOMMU folks there exists some desire to be able to assign > > the iGFX device aka have intel_iommu=on instead of intel_iommu=igfx_off > > due to how the devices might

Re: [Intel-gfx] [PATCH 3/3] drm/i915/execlists: Suppress redundant preemption

2019-01-23 Thread Chris Wilson
Quoting Chris Wilson (2019-01-23 14:14:05) > Quoting Chris Wilson (2019-01-23 13:47:29) > > Quoting Chris Wilson (2019-01-23 12:36:02) > > > On unwinding the active request we give it a small (limited to internal > > > priority levels) boost to prevent it from being gazumped a second time. > > >

Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for gcc-plugins: Introduce stackinit plugin

2019-01-23 Thread Jani Nikula
On Wed, 23 Jan 2019, Patchwork wrote: > == Series Details == > > Series: gcc-plugins: Introduce stackinit plugin > URL : https://patchwork.freedesktop.org/series/55630/ > State : failure > > == Summary == > > Applying: treewide: Lift switch variables out of switches > Using index info to

Re: [Intel-gfx] [PATCH i-g-t] lib/draw: Align mmap requests to page boundaries

2019-01-23 Thread Chris Wilson
Quoting Joonas Lahtinen (2019-01-23 14:22:54) > Quoting Chris Wilson (2019-01-07 12:56:36) > > Since we trust fb->size as either calculated by calc_fb_size() or the > > supplied by the user, it invariably isn't page aligned. The mmap > > routines and ioctls only deal in pages... > > > > Not sure

Re: [Intel-gfx] [PATCH i-g-t] lib/draw: Align mmap requests to page boundaries

2019-01-23 Thread Joonas Lahtinen
Quoting Chris Wilson (2019-01-07 12:56:36) > Since we trust fb->size as either calculated by calc_fb_size() or the > supplied by the user, it invariably isn't page aligned. The mmap > routines and ioctls only deal in pages... > > Not sure if fb->size should be page aligned, but that may break >

Re: [Intel-gfx] [PATCH 1/3] treewide: Lift switch variables out of switches

2019-01-23 Thread Jani Nikula
On Wed, 23 Jan 2019, Jani Nikula wrote: > On Wed, 23 Jan 2019, Greg KH wrote: >> On Wed, Jan 23, 2019 at 03:03:47AM -0800, Kees Cook wrote: >>> Variables declared in a switch statement before any case statements >>> cannot be initialized, so move all instances out of the switches. >>> After

Re: [Intel-gfx] [PATCH 2/3] drm/i915/execlists: Suppress preempting self

2019-01-23 Thread Chris Wilson
Quoting Tvrtko Ursulin (2019-01-23 14:08:56) > > On 23/01/2019 12:36, Chris Wilson wrote: > > In order to avoid preempting ourselves, we currently refuse to schedule > > the tasklet if we reschedule an inflight context. However, this glosses > > over a few issues such as what happens after a CS

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/execlists: Mark up priority boost on preemption

2019-01-23 Thread Patchwork
== Series Details == Series: drm/i915/execlists: Mark up priority boost on preemption URL : https://patchwork.freedesktop.org/series/55641/ State : success == Summary == CI Bug Log - changes from CI_DRM_5470 -> Patchwork_12016 Summary

Re: [Intel-gfx] [PATCH 2/5] drm/i915: always return something

2019-01-23 Thread Joonas Lahtinen
The subject of this patch could really be bit more specific "... on DDI clock selection". Regards, Joonas Quoting Lucas De Marchi (2019-01-17 22:21:10) > Even if we don't have the correct clock and get a warning, we should not > skip the return. > > Fixes: 1fa11ee2d9d0 ("drm/i915/icl: start

Re: [Intel-gfx] [PATCH 1/3] treewide: Lift switch variables out of switches

2019-01-23 Thread Jani Nikula
On Wed, 23 Jan 2019, Greg KH wrote: > On Wed, Jan 23, 2019 at 03:03:47AM -0800, Kees Cook wrote: >> Variables declared in a switch statement before any case statements >> cannot be initialized, so move all instances out of the switches. >> After this, future always-initialized stack variables

Re: [Intel-gfx] [PATCH 3/3] drm/i915/execlists: Suppress redundant preemption

2019-01-23 Thread Chris Wilson
Quoting Chris Wilson (2019-01-23 13:47:29) > Quoting Chris Wilson (2019-01-23 12:36:02) > > On unwinding the active request we give it a small (limited to internal > > priority levels) boost to prevent it from being gazumped a second time. > > However, this means that it can be promoted to above

Re: [Intel-gfx] [PATCH 2/3] drm/i915/execlists: Suppress preempting self

2019-01-23 Thread Tvrtko Ursulin
On 23/01/2019 12:36, Chris Wilson wrote: In order to avoid preempting ourselves, we currently refuse to schedule the tasklet if we reschedule an inflight context. However, this glosses over a few issues such as what happens after a CS completion event and we then preempt the newly executing

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915/execlists: Mark up priority boost on preemption

2019-01-23 Thread Patchwork
== Series Details == Series: drm/i915/execlists: Mark up priority boost on preemption URL : https://patchwork.freedesktop.org/series/55641/ State : warning == Summary == $ dim sparse origin/drm-tip Sparse version: v0.5.2 Commit: drm/i915/execlists: Mark up priority boost on preemption

[Intel-gfx] [CI] drm/i915/execlists: Mark up priority boost on preemption

2019-01-23 Thread Chris Wilson
Record the priority boost we giving to the preempted client or else we may end up in a situation where the priority queue no longer matches the request priority order and so we can end up in an infinite loop of preempting the same pair of requests. Fixes: e9eaf82d97a2 ("drm/i915: Priority boost

Re: [Intel-gfx] [PATCH 15/15] drm/i915/tv: Filter out >1024 wide modes that would need vertical scaling on gen3

2019-01-23 Thread Imre Deak
On Mon, Nov 12, 2018 at 07:00:00PM +0200, Ville Syrjala wrote: > From: Ville Syrjälä > > Since gen3 can't handle >1024 wide sources with vertical scaling > let's not advertize such modes in the mode list. Less tempetation > to the user to try out things that won't work. > > Signed-off-by: Ville

  1   2   >