[Intel-gfx] [GIT PULL] gvt-fixes for 4.15-rc3

Hi, Here's gvt-fixes for 4.15-rc3 with several fixes backported. thanks -- The following changes since commit b721b65af4eb46df6a1d9e34b14003225e403565: drm/i915/gvt: Correct ADDR_4K/2M/1G_MASK definition (2017-11-28 17:24:30 +0800) are available in the Git repository at:

Re: [Intel-gfx] Fixes that failed to cleanly apply to v4.15-rc1

On 2017.12.05 17:02:34 +0200, Joonas Lahtinen wrote: > Dropping GVT folks that are not affected. > > Keeping Zhenyu and Zhi as a heads-up, there's no need for GVT pull for this > rc? > I need to backport one from -next once it's pulled and it's done now. I will send a fixes pull today. thanks

Re: [Intel-gfx] drm-intel/for-linux-next disabled on linux-next?

On Dec 5, 2017, at 6:11 PM, Stephen Rothwell > wrote: Hi Rodrigo, On Tue, 5 Dec 2017 17:19:21 -0800 Rodrigo Vivi > wrote: We noticed that drm-intel/for-linux-next is currently disabled

Re: [Intel-gfx] linux-next: build failure after merge of the drm-misc tree

Hi Rodrigo, On Tue, 5 Dec 2017 17:21:54 -0800 Rodrigo Vivi wrote: > > I had just written the email for you about this. > Feel free to ignore that one since you already found the solution > and sorry for the delay on warning you. And I should read all my email before

Re: [Intel-gfx] drm-intel/for-linux-next disabled on linux-next?

Hi Rodrigo, On Tue, 5 Dec 2017 17:19:21 -0800 Rodrigo Vivi wrote: > > We noticed that drm-intel/for-linux-next is currently disabled > on linux-next. What gave you that idea? > I wonder if it has to do with the compilation error we had yesterday > night (enum plane

[Intel-gfx] ✗ Fi.CI.IGT: warning for drm/i915: Track GGTT writes on the vma

== Series Details == Series: drm/i915: Track GGTT writes on the vma URL : https://patchwork.freedesktop.org/series/34944/ State : warning == Summary == Test drv_suspend: Subgroup fence-restore-tiled2untiled-hibernate: skip -> FAIL (shard-hsw) fdo#103375

Re: [Intel-gfx] linux-next: build failure after merge of the drm-misc tree

On Wed, Dec 06, 2017 at 01:00:15AM +, Stephen Rothwell wrote: > Hi all, Hi Stephen, I had just written the email for you about this. Feel free to ignore that one since you already found the solution and sorry for the delay on warning you. > > After merging the drm-misc tree, today's

[Intel-gfx] drm-intel/for-linux-next disabled on linux-next?

Hi Stephen, We noticed that drm-intel/for-linux-next is currently disabled on linux-next. I wonder if it has to do with the compilation error we had yesterday night (enum plane related). Was it the case? Our solution on drm-tip was to fix at drm-rerere side when building the branches so we

[Intel-gfx] linux-next: build failure after merge of the drm-misc tree

Hi all, After merging the drm-misc tree, today's linux-next build (x86_64 allmodconfig) failed like this: drivers/gpu/drm/i915/intel_dsi.c: In function 'intel_dsi_get_panel_orientation': drivers/gpu/drm/i915/intel_dsi.c:1673:13: error: storage size of 'plane' isn't known enum plane plane;

Re: [Intel-gfx] [GIT PULL] more gvt-next for 4.16

Applied. Thanks, I noticed the KBL patch and got curious... what about CFL and CNL? Thanks, Rodrigo. On Tue, Dec 05, 2017 at 03:26:29AM +, Zhenyu Wang wrote: > > Hi, > > Here's more gvt-next updates for 4.16. Mostly for final VFIO mdev > display dmabuf interface and gvt implementation

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Track GGTT writes on the vma

== Series Details == Series: drm/i915: Track GGTT writes on the vma URL : https://patchwork.freedesktop.org/series/34944/ State : success == Summary == Series 34944v1 drm/i915: Track GGTT writes on the vma https://patchwork.freedesktop.org/api/1.0/series/34944/revisions/1/mbox/ Test

[Intel-gfx] [PATCH] drm/i915: Track GGTT writes on the vma

As writes through the GTT and GGTT PTE updates do not share the same path, they are not strictly ordered and so we must explicitly flush the indirect writes prior to modifying the PTE. We do track outstanding GGTT writes on the object itself, but since the object may have multiple GGTT vma, that

Re: [Intel-gfx] [PATCH 5/9] drm/i915: make dsm struct resource centric

Quoting Matthew Auld (2017-12-05 21:02:45) > Now that we are using struct resource to track the stolen region, it is > more convenient if we track dsm in a resource as well. > > v2: check range_overflow when writing to 32b registers (Chris) > pepper in some comments (Chris) > v3: refit

Re: [Intel-gfx] [PATCH 6/9] drm/i915: make reserved struct resource centric

Quoting Matthew Auld (2017-12-05 21:02:46) > Now that we are using struct resource to track the stolen region, it is > more convenient if we track the reserved portion of that region in a > resource as well. > > v2: s/<= end + 1/< end/ (Chris) > v3: prefer DEFINE_RES_MEM > > Signed-off-by:

Re: [Intel-gfx] [PATCH 7/9] drm/i915: make mappable struct resource centric

Quoting Matthew Auld (2017-12-05 21:02:47) > Now that we are using struct resource to track the stolen region, it is > more convenient if we track the mappable region in a resource as well. > > v2: prefer iomap and gmadr naming scheme > prefer DEFINE_RES_MEM > > Signed-off-by: Matthew Auld

Re: [Intel-gfx] [PATCH 8/9] drm/i915: prefer resource_size_t for everything stolen

Quoting Matthew Auld (2017-12-05 21:02:48) > @@ -381,8 +381,8 @@ struct i915_ggtt { > * avoid the first page! The upper end of stolen memory is reserved > for > * hardware functions and similarly removed from the accessible range. > */ > - u32 stolen_size;

Re: [Intel-gfx] [PATCH v3 4/9] drm: Add some HDCP related #defines

Quoting Sean Paul (2017-12-05 05:15:03) > In preparation for implementing HDCP in i915, add some HDCP related > register offsets and defines. The dpcd register offsets will go in > drm_dp_helper.h whereas the ddc offsets along with generic HDCP stuff > will get stuffed in drm_hdcp.h, which is new.

Re: [Intel-gfx] [PATCH v3 2/9] drm/i915: Add more control to wait_for routines

Quoting Sean Paul (2017-12-05 05:15:01) > This patch adds a little more control to a couple wait_for routines such > that we can avoid open-coding read/wait/timeout patterns which: > - need the value of the register after the wait_for > - run arbitrary operation for the read portion > > This

[Intel-gfx] ✗ Fi.CI.IGT: failure for make stolen resource centric (rev4)

== Series Details == Series: make stolen resource centric (rev4) URL : https://patchwork.freedesktop.org/series/34256/ State : failure == Summary == Test prime_mmap_kms: Subgroup buffer-sharing: skip -> PASS (shard-snb) Test kms_flip: Subgroup

Re: [Intel-gfx] [PATCH v3 6/8] drm/i915/guc: Combine enable_guc_loading|submission modparams

Quoting Michal Wajdeczko (2017-12-05 16:38:42) > -void intel_uc_sanitize_options(struct drm_i915_private *dev_priv) > +static int __get_platform_enable_guc(struct drm_i915_private *dev_priv) > { > - if (!HAS_GUC(dev_priv)) { > - if (i915_modparams.enable_guc_loading > 0 || > -

Re: [Intel-gfx] [PATCH v3 3/8] drm/i915/guc: Introduce USES_GUC_xxx helper macros

Quoting Michal Wajdeczko (2017-12-05 16:38:39) > In the upcoming patch we will change the way how to recognize > when GuC is in use. Using helper macros will minimize scope > of that changes. While here, update dev_info message. > > Signed-off-by: Michal Wajdeczko >

Re: [Intel-gfx] [PATCH v3 4/8] drm/i915/uc: Don't fetch GuC firmware if no plan to use GuC

Quoting Michal Wajdeczko (2017-12-05 16:38:40) > If we don't plan to use GuC then we should not try to fetch GuC and > HuC firmwares. We can save memory and avoid possible dmesg noise. > > Signed-off-by: Michal Wajdeczko > Cc: Chris Wilson >

Re: [Intel-gfx] [PATCH v3 8/8] HAX enable GuC/HuC load

Is this a real attempt or enabling GuC by default or is it only for CI validating the series? If it is the second option I'd like to see CI testing this series without this patch here as well to make sure these changes are not breaking any of the current default flow. One case or the other I

Re: [Intel-gfx] [PATCH v3 2/2] drm/i915: add platform tag to WA

On Tue, Dec 05, 2017 at 07:01:18PM +, Lucas De Marchi wrote: > v2: add more missing platform tags > v3: change tag to cnp rather than using gen9,gen10 thanks! both patches merged to dinq > > Cc: Ville Syrjälä > Signed-off-by: Lucas De Marchi

[Intel-gfx] ✗ Fi.CI.IGT: warning for lib: Check and report if a subtest triggers a new kernel taint (rev2)

== Series Details == Series: lib: Check and report if a subtest triggers a new kernel taint (rev2) URL : https://patchwork.freedesktop.org/series/34616/ State : warning == Summary == Test prime_mmap_kms: Subgroup buffer-sharing: skip -> PASS (shard-snb)

[Intel-gfx] ✓ Fi.CI.BAT: success for make stolen resource centric (rev4)

== Series Details == Series: make stolen resource centric (rev4) URL : https://patchwork.freedesktop.org/series/34256/ State : success == Summary == Series 34256v4 make stolen resource centric https://patchwork.freedesktop.org/api/1.0/series/34256/revisions/4/mbox/ Test gem_mmap_gtt:

[Intel-gfx] ✗ Fi.CI.IGT: warning for series starting with [v3,1/2] drm/i915: follow single notation for workaround number

== Series Details == Series: series starting with [v3,1/2] drm/i915: follow single notation for workaround number URL : https://patchwork.freedesktop.org/series/34937/ State : warning == Summary == Test kms_flip: Subgroup vblank-vs-modeset-suspend-interruptible: skip

[Intel-gfx] ✗ Fi.CI.IGT: warning for drm/fb-helper: Add .last_close and .output_poll_changed helpers (rev3)

== Series Details == Series: drm/fb-helper: Add .last_close and .output_poll_changed helpers (rev3) URL : https://patchwork.freedesktop.org/series/32332/ State : warning == Summary == Test kms_chv_cursor_fail: Subgroup pipe-b-128x128-top-edge: incomplete -> PASS

[Intel-gfx] ✓ Fi.CI.IGT: success for e1000e: Taint a HW lockup

== Series Details == Series: e1000e: Taint a HW lockup URL : https://patchwork.freedesktop.org/series/34931/ State : success == Summary == Test kms_flip: Subgroup vblank-vs-modeset-suspend: pass -> SKIP (shard-snb) fdo#102365 Subgroup

Re: [Intel-gfx] [PATCH v3 00/11] drm/fb-helper: Add .last_close and .output_poll_changed helpers

On Tue, Dec 5, 2017 at 1:24 PM, Noralf Trønnes wrote: > The helpers are applied and have reached airlied/drm-next. > > amd has gained another .poll_changed user since last. Patches 1, 2, 9 applied to my -next tree. Thanks! Alex > > i915 doesn't really need the

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Taint (TAINT_DIE) the kernel if the GPU reset fails (rev4)

== Series Details == Series: drm/i915: Taint (TAINT_DIE) the kernel if the GPU reset fails (rev4) URL : https://patchwork.freedesktop.org/series/34623/ State : success == Summary == Test drv_suspend: Subgroup fence-restore-untiled-hibernate: fail -> SKIP

Re: [Intel-gfx] [PATCH 3/9] x86/early-quirks: reverse the if ladders

On Tue, Dec 05, 2017 at 09:02:43PM +, Matthew Auld wrote: > Makes things a little easier to follow. > > Suggested-by: Ville Syrjälä > Signed-off-by: Matthew Auld > Cc: Joonas Lahtinen > Cc: Ville

[Intel-gfx] ✓ Fi.CI.IGT: success for lockdep: Mark up lock disabling with TAINT_CRAP

== Series Details == Series: lockdep: Mark up lock disabling with TAINT_CRAP URL : https://patchwork.freedesktop.org/series/34915/ State : success == Summary == Test kms_frontbuffer_tracking: Subgroup fbc-1p-offscren-pri-shrfb-draw-blt: fail -> PASS

[Intel-gfx] [PATCH 6/9] drm/i915: make reserved struct resource centric

Now that we are using struct resource to track the stolen region, it is more convenient if we track the reserved portion of that region in a resource as well. v2: s/<= end + 1/< end/ (Chris) v3: prefer DEFINE_RES_MEM Signed-off-by: Matthew Auld Cc: Joonas Lahtinen

[Intel-gfx] [PATCH 8/9] drm/i915: prefer resource_size_t for everything stolen

Keeps things consistent now that we make use of struct resource. This should keep us covered in case we ever get huge amounts of stolen memory. v2: bunch of missing conversions (Chris) Signed-off-by: Matthew Auld Cc: Joonas Lahtinen Cc:

[Intel-gfx] [PATCH 5/9] drm/i915: make dsm struct resource centric

Now that we are using struct resource to track the stolen region, it is more convenient if we track dsm in a resource as well. v2: check range_overflow when writing to 32b registers (Chris) pepper in some comments (Chris) v3: refit i915_stolen_to_dma() Signed-off-by: Matthew Auld

[Intel-gfx] [PATCH 1/9] x86/early-quirks: Extend Intel graphics stolen memory placement to 64bit

From: Joonas Lahtinen To give upcoming SKU BIOSes more flexibility in placing the Intel graphics stolen memory, make all variables storing the placement or size compatible with full 64 bit range. Also by exporting the stolen region as a resource, we can then nuke

[Intel-gfx] [PATCH 9/9] drm/i915: use stolen_usable_size for the range sanity check

In i915_pages_create_for_stolen it probably makes more sense to check if the range overflows the stolen_usable_size, since stolen_size will also include the reserved portion which we can't touch. Signed-off-by: Matthew Auld Cc: Joonas Lahtinen

[Intel-gfx] [PATCH 7/9] drm/i915: make mappable struct resource centric

Now that we are using struct resource to track the stolen region, it is more convenient if we track the mappable region in a resource as well. v2: prefer iomap and gmadr naming scheme prefer DEFINE_RES_MEM Signed-off-by: Matthew Auld Cc: Joonas Lahtinen

[Intel-gfx] [PATCH 3/9] x86/early-quirks: reverse the if ladders

Makes things a little easier to follow. Suggested-by: Ville Syrjälä Signed-off-by: Matthew Auld Cc: Joonas Lahtinen Cc: Ville Syrjälä Cc: Chris Wilson

[Intel-gfx] [PATCH 2/9] x86/early-quirks: replace the magical increment start values

Replace the magical +2, +9 etc. with +MB, which is far easier to read. Suggested-by: Ville Syrjälä Signed-off-by: Matthew Auld Cc: Joonas Lahtinen Cc: Ville Syrjälä Cc: Chris

[Intel-gfx] [PATCH 0/9] make stolen resource centric

Continuation of Paulo' stolen series[1], addressing the feedback from Joonas and Chris. [1] https://patchwork.freedesktop.org/series/30923/ Joonas Lahtinen (1): x86/early-quirks: Extend Intel graphics stolen memory placement to 64bit Matthew Auld (8): x86/early-quirks: replace the

[Intel-gfx] [PATCH 4/9] drm/i915: nuke the duplicated stolen discovery

We duplicate the stolen discovery code in early-quirks and in i915, however now that the stolen region is exported as a resource from early-quirks we can nuke the duplication. v2: check overflows_type Signed-off-by: Matthew Auld Cc: Joonas Lahtinen

Re: [Intel-gfx] [RFC PATCH 1/6] drm: Add Content Protection property

Hi Pavel, On 5 December 2017 at 17:34, Pavel Machek wrote: > Yes, so... This patch makes it more likely to see machines with locked > down kernels, preventing developers from working with systems their > own, running hardware. That is evil, and direct threat to Free > software

[Intel-gfx] ✓ Fi.CI.BAT: success for lib: Check and report if a subtest triggers a new kernel taint (rev2)

== Series Details == Series: lib: Check and report if a subtest triggers a new kernel taint (rev2) URL : https://patchwork.freedesktop.org/series/34616/ State : success == Summary == IGT patchset tested on top of latest successful build 1db12466cb5ad8483cd469753d2e312a62d717b7 meson: build a

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [v3,1/2] drm/i915: follow single notation for workaround number

== Series Details == Series: series starting with [v3,1/2] drm/i915: follow single notation for workaround number URL : https://patchwork.freedesktop.org/series/34937/ State : success == Summary == Series 34937v1 series starting with [v3,1/2] drm/i915: follow single notation for workaround

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/fb-helper: Add .last_close and .output_poll_changed helpers (rev3)

== Series Details == Series: drm/fb-helper: Add .last_close and .output_poll_changed helpers (rev3) URL : https://patchwork.freedesktop.org/series/32332/ State : success == Summary == Series 32332v3 drm/fb-helper: Add .last_close and .output_poll_changed helpers

Re: [Intel-gfx] [RFC PATCH 1/6] drm: Add Content Protection property

On Tue, Dec 5, 2017 at 12:34 PM, Pavel Machek wrote: > On Tue 2017-12-05 11:45:38, Daniel Vetter wrote: >> On Tue, Dec 05, 2017 at 11:28:40AM +0100, Pavel Machek wrote: >> > On Wed 2017-11-29 22:08:56, Sean Paul wrote: >> > > This patch adds a new optional connector property to

[Intel-gfx] [PATCH v3 1/2] drm/i915: follow single notation for workaround number

v2: Allow to have or omit space before platform Cc: Ville Syrjälä Signed-off-by: Lucas De Marchi Reviewed-by: Rodrigo Vivi --- drivers/gpu/drm/i915/intel_hdmi.c | 2 +- drivers/gpu/drm/i915/intel_pm.c | 4 ++--

[Intel-gfx] [PATCH v3 2/2] drm/i915: add platform tag to WA

v2: add more missing platform tags v3: change tag to cnp rather than using gen9,gen10 Cc: Ville Syrjälä Signed-off-by: Lucas De Marchi Reviewed-by: Rodrigo Vivi --- drivers/gpu/drm/i915/intel_hdmi.c | 2 +-

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

On Tue, 2017-12-05 at 15:09 +0200, Imre Deak wrote: > On Sat, Dec 02, 2017 at 02:05:42AM +0200, Rogozhkin, Dmitry V wrote: > > On Thu, 2017-11-30 at 13:19 +0200, Imre Deak wrote: > > > > > +#define NEEDS_CSR_GT_PERF_WA(dev_priv) \ > > > > > + (HAS_CSR(dev_priv) && IS_GEN9(dev_priv) && ! > >

[Intel-gfx] ✓ Fi.CI.BAT: success for e1000e: Taint a HW lockup

== Series Details == Series: e1000e: Taint a HW lockup URL : https://patchwork.freedesktop.org/series/34931/ State : success == Summary == Series 34931v1 e1000e: Taint a HW lockup https://patchwork.freedesktop.org/api/1.0/series/34931/revisions/1/mbox/ fi-bdw-5557u total:288 pass:267

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Taint (TAINT_DIE) the kernel if the GPU reset fails (rev4)

== Series Details == Series: drm/i915: Taint (TAINT_DIE) the kernel if the GPU reset fails (rev4) URL : https://patchwork.freedesktop.org/series/34623/ State : success == Summary == Series 34623v4 drm/i915: Taint (TAINT_DIE) the kernel if the GPU reset fails

[Intel-gfx] [PATCH v3 11/11] drm/tegra: Use drm_fb_helper_lastclose() and _poll_changed()

This driver can use drm_fb_helper_lastclose() as its .lastclose callback. It can also use drm_fb_helper_output_poll_changed() as its .output_poll_changed callback. Cc: Thierry Reding Signed-off-by: Noralf Trønnes Acked-by: Daniel Vetter

[Intel-gfx] [PATCH v3 10/11] drm/rockchip: Use drm_fb_helper_lastclose() and _poll_changed()

This driver can use drm_fb_helper_lastclose() as its .lastclose callback. It can also use drm_fb_helper_output_poll_changed() as its .output_poll_changed callback. Cc: Mark Yao Signed-off-by: Noralf Trønnes Acked-by: Daniel Vetter

[Intel-gfx] [PATCH v3 03/11] drm/armada: Use drm_fb_helper_lastclose() and _poll_changed()

This driver can use drm_fb_helper_lastclose() as its .lastclose callback. It can also use drm_fb_helper_output_poll_changed() as its .output_poll_changed callback. Cc: Russell King Signed-off-by: Noralf Trønnes Acked-by: Russell King

[Intel-gfx] [PATCH v3 08/11] drm/omap: Use drm_fb_helper_lastclose() and _poll_changed()

This driver can use drm_fb_helper_lastclose() as its .lastclose callback. It can also use drm_fb_helper_output_poll_changed() as its .output_poll_changed callback. Cc: Tomi Valkeinen Signed-off-by: Noralf Trønnes Acked-by: Daniel Vetter

[Intel-gfx] [PATCH v3 05/11] drm/gma500: Use drm_fb_helper_lastclose() and _poll_changed()

This driver can use drm_fb_helper_lastclose() as its .lastclose callback. It can also use drm_fb_helper_output_poll_changed() as its .output_poll_changed callback. Cc: Patrik Jakobsson Signed-off-by: Noralf Trønnes Acked-by: Daniel Vetter

[Intel-gfx] [PATCH v3 09/11] drm/radeon: Use drm_fb_helper_lastclose() and _poll_changed()

This driver can use drm_fb_helper_lastclose() in its .lastclose function. It can also use drm_fb_helper_output_poll_changed() as its .output_poll_changed callback. Cc: Alex Deucher Cc: "Christian König" Signed-off-by: Noralf Trønnes

[Intel-gfx] [PATCH v3 00/11] drm/fb-helper: Add .last_close and .output_poll_changed helpers

The helpers are applied and have reached airlied/drm-next. amd has gained another .poll_changed user since last. i915 doesn't really need the .poll_changed helper since it now does a sync and has to open code it after: drm/i915/fbdev: Serialise early hotplug events with async fbdev config

[Intel-gfx] [PATCH v3 07/11] drm/nouveau: Use drm_fb_helper_output_poll_changed()

This driver can use drm_fb_helper_output_poll_changed() instead of its own nouveau_fbcon_output_poll_changed(). Cc: Ben Skeggs Signed-off-by: Noralf Trønnes Acked-by: Daniel Vetter --- drivers/gpu/drm/nouveau/nouveau_display.c |

[Intel-gfx] [PATCH v3 02/11] drm/amdgpu: Use drm_fb_helper_lastclose() and _poll_changed()

This driver can use drm_fb_helper_lastclose() in its .lastclose function. It can also use drm_fb_helper_output_poll_changed() as its .output_poll_changed callback. Remove the unused driver implementations. Cc: Alex Deucher Cc: "Christian König"

[Intel-gfx] [PATCH v3 04/11] drm/exynos: Use drm_fb_helper_lastclose() and _poll_changed()

This driver can use drm_fb_helper_lastclose() as its .lastclose callback. It can also use drm_fb_helper_output_poll_changed() as its .output_poll_changed callback. Cc: Inki Dae Cc: Joonyoung Shim Cc: Seung-Woo Kim Cc:

[Intel-gfx] [PATCH v3 06/11] drm/msm: Use drm_fb_helper_lastclose() and _poll_changed()

This driver can use drm_fb_helper_lastclose() as its .lastclose callback. It can also use drm_fb_helper_output_poll_changed() as its .output_poll_changed callback. Cc: Rob Clark Signed-off-by: Noralf Trønnes Acked-by: Daniel Vetter

[Intel-gfx] [PATCH v3 01/11] drm/amd/display: Use drm_fb_helper_poll_changed()

This driver can use drm_fb_helper_output_poll_changed() as its .output_poll_changed callback. Cc: Alex Deucher Cc: "Christian König" Signed-off-by: Noralf Trønnes --- drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 2

[Intel-gfx] ✗ Fi.CI.BAT: failure for intel/atomic: Stop updating legacy fb parameters

== Series Details == Series: intel/atomic: Stop updating legacy fb parameters URL : https://patchwork.freedesktop.org/series/34924/ State : failure == Summary == Series 34924v1 intel/atomic: Stop updating legacy fb parameters

Re: [Intel-gfx] [IGT] IGT/tests/firmware: Test firmware loading by reading debugfs

>-Original Message- >From: Vivi, Rodrigo >Sent: Friday, December 1, 2017 2:33 PM >To: Srivatsa, Anusha >Cc: intel-gfx@lists.freedesktop.org >Subject: Re: [IGT] IGT/tests/firmware: Test firmware loading by reading debugfs > >On Fri, Dec 01, 2017 at 09:40:35PM

Re: [Intel-gfx] [PATCH] e1000e: Taint a HW lockup

Quoting Chris Wilson (2017-12-05 18:00:00) > When we see an e1000e HW lockup in CI, it is typically fatal with the > hang repeating until the host is forcibly rebooted. Speed up that > process by tainting the kernel, which CI can trivially detect (and is > being used to detect similarly fatal CI

Re: [Intel-gfx] [RFC PATCH 1/6] drm: Add Content Protection property

Hi! > >> > Why would user of the machine want this to be something else than > >> > 'OFF'? > >> > > >> > If kernel implements this, will it mean hardware vendors will have to > >> > prevent user from updating kernel on machines they own? > >> > > >> > If this is merged, does it open kernel

[Intel-gfx] [PATCH] e1000e: Taint a HW lockup

When we see an e1000e HW lockup in CI, it is typically fatal with the hang repeating until the host is forcibly rebooted. Speed up that process by tainting the kernel, which CI can trivially detect (and is being used to detect similarly fatal CI conditions) and reboot soon after. Signed-off-by:

Re: [Intel-gfx] [RFC PATCH 1/6] drm: Add Content Protection property

On Tue, Dec 5, 2017 at 12:34 PM, Pavel Machek wrote: > On Tue 2017-12-05 11:45:38, Daniel Vetter wrote: >> On Tue, Dec 05, 2017 at 11:28:40AM +0100, Pavel Machek wrote: >> > On Wed 2017-11-29 22:08:56, Sean Paul wrote: >> > > This patch adds a new optional connector property to

[Intel-gfx] ✗ Fi.CI.BAT: warning for drm/i915: Restore GT performance in headless mode with DMC loaded (rev6)

== Series Details == Series: drm/i915: Restore GT performance in headless mode with DMC loaded (rev6) URL : https://patchwork.freedesktop.org/series/24017/ State : warning == Summary == Series 24017v6 drm/i915: Restore GT performance in headless mode with DMC loaded

Re: [Intel-gfx] [PATCH] intel/atomic: Stop updating legacy fb parameters

On Tue, Dec 05, 2017 at 06:00:20PM +0100, Daniel Vetter wrote: > Even fbc isn't using this stuff anymore, so time to remove it. > > Cleaning up one small piece of the atomic conversion cruft at the time > ... > > Cc: Paulo Zanoni > Cc: Ville Syrjälä

Re: [Intel-gfx] [RFC PATCH 1/6] drm: Add Content Protection property

On Tue 2017-12-05 11:45:38, Daniel Vetter wrote: > On Tue, Dec 05, 2017 at 11:28:40AM +0100, Pavel Machek wrote: > > On Wed 2017-11-29 22:08:56, Sean Paul wrote: > > > This patch adds a new optional connector property to allow userspace to > > > enable > > > protection over the content it is

Re: [Intel-gfx] [PATCH v3 6/9] drm/i915: Make use of indexed write GMBUS feature

On Tue, Dec 05, 2017 at 12:15:05AM -0500, Sean Paul wrote: > This patch enables the indexed write feature of the GMBUS to concatenate > 2 consecutive messages into one. The criteria for an indexed write is > that both messages are writes, the first is length == 1, and the second > is length > 0.

[Intel-gfx] [PATCH v4] drm/i915: Taint (TAINT_WARN) the kernel if the GPU reset fails

History tells us that if we cannot reset the GPU now, we never will. This then impacts everything that is run subsequently. On failing the reset, we mark the driver as wedged, trying to prevent further execution on the GPU, forcing userspace to fallback to using the CPU to update its framebuffers

[Intel-gfx] [PATCH v3] drm/i915: Taint (TAINT_WARN) the kernel if the GPU reset fails

History tells us that if we cannot reset the GPU now, we never will. This then impacts everything that is run subsequently. On failing the reset, we mark the driver as wedged, trying to prevent further execution on the GPU, forcing userspace to fallback to using the CPU to update its framebuffers

Re: [Intel-gfx] [PATCH] drm/i915: Generalize definition for crtc mask

On Tue, Dec 05, 2017 at 03:59:35PM +0200, Ville Syrjälä wrote: > On Tue, Dec 05, 2017 at 12:15:39PM +0200, Mika Kahola wrote: > > crtc_mask is defined explicitly defined for a certain number of pipes per > > platform. Let's generalize this in a way that crtc_mask dependens only on > > the number

Re: [Intel-gfx] [PATCH i-g-t 2/2] kms_content_protection: Add Content Protection test

On Tue, Dec 05, 2017 at 10:22:00AM +0200, Petri Latvala wrote: > On Tue, Dec 05, 2017 at 12:23:33AM -0500, Sean Paul wrote: > > Pretty simple test: > > - initializes the output > > - clears the content protection property > > - verifies that it clears > > - sets the content protection property to

[Intel-gfx] ✗ Fi.CI.BAT: warning for series starting with [v3,1/8] drm/i915/huc: Move firmware selection to init_early

== Series Details == Series: series starting with [v3,1/8] drm/i915/huc: Move firmware selection to init_early URL : https://patchwork.freedesktop.org/series/34919/ State : warning == Summary == Series 34919v1 series starting with [v3,1/8] drm/i915/huc: Move firmware selection to init_early

Re: [Intel-gfx] [PATCH v3 2/9] drm/i915: Add more control to wait_for routines

On Tue, Dec 05, 2017 at 12:15:01AM -0500, Sean Paul wrote: > This patch adds a little more control to a couple wait_for routines such > that we can avoid open-coding read/wait/timeout patterns which: > - need the value of the register after the wait_for > - run arbitrary operation for the read

Re: [Intel-gfx] [PATCH v3 9/9] drm/i915: Implement HDCP for DisplayPort

On Tue, Dec 05, 2017 at 12:15:08AM -0500, Sean Paul wrote: > This patch adds HDCP support for DisplayPort connectors by implementing > the intel_hdcp_shim. > > Most of this is straightforward read/write from/to DPCD registers. One > thing worth pointing out is the Aksv output bit. It wasn't

Re: [Intel-gfx] [PATCH v2] drm/i915: Taint (TAINT_DIE) the kernel if the GPU reset fails

Quoting Chris Wilson (2017-11-29 14:05:33) > History tells us that if we cannot reset the GPU now, we never will. This > then impacts everything that is run subsequently. On failing the reset, > we mark the driver as wedged, trying to prevent further execution on the > GPU, forcing userspace to

Re: [Intel-gfx] [PATCH v3 8/9] drm/i915: Implement HDCP for HDMI

On Tue, Dec 05, 2017 at 12:15:07AM -0500, Sean Paul wrote: > This patch adds HDCP support for HDMI connectors by implementing > the intel_hdcp_shim. > > Nothing too special, just a bunch of DDC reads/writes. > > Changes in v2: > - Rebased on drm-intel-next > Changes in v3: > - Initialize new

Re: [Intel-gfx] [PATCH v3 7/9] drm/i915: Add function to output Aksv over GMBUS

On Tue, Dec 05, 2017 at 12:15:06AM -0500, Sean Paul wrote: > Once the Aksv is available in the PCH, we need to get it on the wire to > the receiver via DDC. The hardware doesn't allow us to read the value > directly, so we need to tell GMBUS to source the Aksv internally and > send it to the right

Re: [Intel-gfx] [PATCH v3 6/9] drm/i915: Make use of indexed write GMBUS feature

On Tue, Dec 05, 2017 at 12:15:05AM -0500, Sean Paul wrote: > This patch enables the indexed write feature of the GMBUS to concatenate > 2 consecutive messages into one. The criteria for an indexed write is > that both messages are writes, the first is length == 1, and the second > is length > 0.

Re: [Intel-gfx] [PATCH v3 5/9] drm/i915: Add HDCP framework + base implementation

On Tue, Dec 05, 2017 at 12:15:04AM -0500, Sean Paul wrote: > This patch adds the framework required to add HDCP support to intel > connectors. It implements Aksv loading from fuse, and parts 1/2/3 > of the HDCP authentication scheme. > > Note that without shim implementations, this does not

[Intel-gfx] [PATCH] intel/atomic: Stop updating legacy fb parameters

Even fbc isn't using this stuff anymore, so time to remove it. Cleaning up one small piece of the atomic conversion cruft at the time ... Cc: Paulo Zanoni Cc: Ville Syrjälä Cc: Maarten Lankhorst

[Intel-gfx] ✓ Fi.CI.BAT: success for lockdep: Mark up lock disabling with TAINT_CRAP

== Series Details == Series: lockdep: Mark up lock disabling with TAINT_CRAP URL : https://patchwork.freedesktop.org/series/34915/ State : success == Summary == Series 34915v1 lockdep: Mark up lock disabling with TAINT_CRAP

Re: [Intel-gfx] [PATCH v2] drm/i915: Taint (TAINT_DIE) the kernel if the GPU reset fails

Quoting Joonas Lahtinen (2017-12-04 13:41:11) > On Wed, 2017-11-29 at 14:05 +, Chris Wilson wrote: > > History tells us that if we cannot reset the GPU now, we never will. This > > then impacts everything that is run subsequently. On failing the reset, > > we mark the driver as wedged, trying

[Intel-gfx] ✗ Fi.CI.IGT: warning for series starting with [1/2] drm/i915: Flush pending GTT writes before unbinding (rev2)

== Series Details == Series: series starting with [1/2] drm/i915: Flush pending GTT writes before unbinding (rev2) URL : https://patchwork.freedesktop.org/series/34900/ State : warning == Summary == Test kms_draw_crc: Subgroup draw-method-xrgb2101010-mmap-wc-untiled:

[Intel-gfx] [PATCH v3 7/8] drm/i915/huc: Load HuC only if requested

Our new "enable_guc" modparam allows to control whenever HuC should be loaded. However existing code will try load and authenticate HuC always when we use the GuC. This patch is trying to enforce modparam selection. v2: no need to cast PTR_ERR (Chris) fetch/fini only if required (Michal)

[Intel-gfx] [PATCH v3 8/8] HAX enable GuC/HuC load

Also revert ("drm/i915/guc: Assert that we switch between known ggtt->invalidate functions") v2: don't enable GuC on GLK Signed-off-by: Michal Wajdeczko --- drivers/gpu/drm/i915/i915_gem_gtt.c | 8 ++-- drivers/gpu/drm/i915/i915_params.h | 2 +-

[Intel-gfx] [PATCH v3 5/8] drm/i915/uc: Don't use -EIO to report missing firmware

-EIO has special meaning and is used when we want to allow engine initialization to fail and mark GPU as wedged. However here at this function we should return error code that corresponds to upload status only, as any decision how to handle missing firmware should be done higher level function

[Intel-gfx] [PATCH v3 3/8] drm/i915/guc: Introduce USES_GUC_xxx helper macros

In the upcoming patch we will change the way how to recognize when GuC is in use. Using helper macros will minimize scope of that changes. While here, update dev_info message. Signed-off-by: Michal Wajdeczko Cc: Chris Wilson Cc: Joonas

[Intel-gfx] [PATCH v3 6/8] drm/i915/guc: Combine enable_guc_loading|submission modparams

We currently have two module parameters that control GuC: "enable_guc_loading" and "enable_guc_submission". Whenever we need submission=1, we also need loading=1. We also need loading=1 when we want to want to load and verify the HuC. Lets combine above module parameters into one "enable_guc"

[Intel-gfx] [PATCH v3 4/8] drm/i915/uc: Don't fetch GuC firmware if no plan to use GuC

If we don't plan to use GuC then we should not try to fetch GuC and HuC firmwares. We can save memory and avoid possible dmesg noise. Signed-off-by: Michal Wajdeczko Cc: Chris Wilson Cc: Joonas Lahtinen Cc:

[Intel-gfx] [PATCH v3 1/8] drm/i915/huc: Move firmware selection to init_early

Doing HuC firmware path selection from sanitize_options function is not perfect, while there is no problem with doing so during early init stage as we already have all needed data. Signed-off-by: Michal Wajdeczko Cc: Chris Wilson Cc: Joonas

[Intel-gfx] [PATCH v3 2/8] drm/i915/guc: Move firmware selection to init_early

Doing GuC firmware path selection from sanitize_options function is not perfect, while there is no problem with doing so during early init stage as we already have all needed data. Signed-off-by: Michal Wajdeczko Cc: Chris Wilson Cc: Joonas

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Put all non-blocking modesets onto an ordered wq

== Series Details == Series: drm/i915: Put all non-blocking modesets onto an ordered wq URL : https://patchwork.freedesktop.org/series/33712/ State : success == Summary == Series 33712v1 drm/i915: Put all non-blocking modesets onto an ordered wq

  1   2   >