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

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 desired > - verifies that it transitions to enabled > > Does this for both

Re: [Intel-gfx] [PATCH i-g-t 1/2] CONTRIBUTING: Fix spelling mistake and line length

On Tue, Dec 05, 2017 at 12:23:32AM -0500, Sean Paul wrote: > Noticed while I was reading it. Makes for a good first contribution, I > guess. > > Signed-off-by: Sean Paul Reviewed-by: Petri Latvala > --- > CONTRIBUTING | 8 > 1 file

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Disable display crc feature for vgpu

== Series Details == Series: drm/i915: Disable display crc feature for vgpu URL : https://patchwork.freedesktop.org/series/34889/ State : success == Summary == Series 34889v1 drm/i915: Disable display crc feature for vgpu

Re: [Intel-gfx] [PATCH v3 3/9] drm: Add Content Protection property

On 12/05/2017 06:15 AM, Sean Paul wrote: > This patch adds a new optional connector property to allow userspace to enable > protection over the content it is displaying. This will typically be > implemented > by the driver using HDCP. > > The property is a tri-state with the following values: >

Re: [Intel-gfx] [PATCH] drm/i915: Fix compilation (panel orientation x enum plane rename).

Hi, On 05-12-17 01:58, Rodrigo Vivi wrote: On Tue, Dec 05, 2017 at 12:09:35AM +, Michel Thierry wrote: On 12/4/2017 4:04 PM, Rodrigo Vivi wrote: When commit '82daca297506 ("drm/i915: Add "panel orientation" property to the panel connector, v6.")' was done and tested by CI, commit

Re: [Intel-gfx] [PATCH i-g-t] intel_aubdump: Add ability to simulate execlist submission

On 2017-11-28 15:51:19, Scott D Phillips wrote: > Newer devices do not have the legacy ring buffer submission model, > so aub files generated using that model cannot be handled by some > internal tools. The execlist submission modeled by this change is > pretty simplistic, using GGTT only and

[Intel-gfx] [PATCH] drm/i915: Disable display crc feature for vgpu

for vgpu, it doesn't support display crc feature. this patch is to skip pipe crc create and report ENODEV during set_crc_source. igt display crc relatated cases will be failed instead of dead sleep. Signed-off-by: Xiaolin Zhang --- drivers/gpu/drm/i915/intel_pipe_crc.c

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

On Tuesday 05 December 2017 10:45 AM, 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 actually

Re: [Intel-gfx] ✗ Fi.CI.IGT: warning for series starting with [1/2] CONTRIBUTING: Fix spelling mistake and line length

On Tue, Dec 05, 2017 at 06:35:20AM +, Patchwork wrote: > == Series Details == > > Series: series starting with [1/2] CONTRIBUTING: Fix spelling mistake and > line length > URL : https://patchwork.freedesktop.org/series/34881/ > State : warning > > == Summary == > > Test

Re: [Intel-gfx] ✗ Fi.CI.IGT: warning for series starting with [1/2] CONTRIBUTING: Fix spelling mistake and line length

On Tue, Dec 05, 2017 at 10:26:50AM +0200, Petri Latvala wrote: > On Tue, Dec 05, 2017 at 06:35:20AM +, Patchwork wrote: > > == Series Details == > > > > Series: series starting with [1/2] CONTRIBUTING: Fix spelling mistake and > > line length > > URL :

Re: [Intel-gfx] [PATCH i-g-t 1/3] lib: avoid < in gtkdoc comments

On Mon, 2017-12-04 at 21:48 +0100, Daniel Vetter wrote: > For reasons entirely not clear to me meson gtkdoc runs in strict > xml parsing mode, whereas automake gtkdoc doesn't. And gtkdoc itself > is to dense to correctly escape this stuff. > > Paper around this. > > v2: {foo} instead of

Re: [Intel-gfx] [PATCH i-g-t 2/3] meson: gtkdoc support

On Mon, Dec 04, 2017 at 09:48:36PM +0100, Daniel Vetter wrote: > Bunch of neat improvements: > > - xml generates correctly depend upon the test binaries > - no need to re-run autogen.sh when new chapters/functions get added, > all handed by meson > > Still one issue: > > - the gtkdoc target

Re: [Intel-gfx] [PATCH] drm/i915: Fix compilation (panel orientation x enum plane rename).

On Tue, Dec 05, 2017 at 12:12:27PM +0200, Joonas Lahtinen wrote: > On Tue, 2017-12-05 at 09:18 +0100, Hans de Goede wrote: > > Hi, > > > > On 05-12-17 01:58, Rodrigo Vivi wrote: > > > On Tue, Dec 05, 2017 at 12:09:35AM +, Michel Thierry wrote: > > > > On 12/4/2017 4:04 PM, Rodrigo Vivi wrote:

Re: [Intel-gfx] [PATCH i-g-t 1/1] lib/igt_gt: Add sentinel to intel_execution_engines2

On 05/12/2017 10:16, Petri Latvala wrote: The for_each_engine_class_instance macro stops at e__->name being NULL, so add an object that is so. Signed-off-by: Petri Latvala Cc: Tvrtko Ursulin Cc: Chris Wilson ---

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/1] lib/igt_gt: Add sentinel to intel_execution_engines2

== Series Details == Series: series starting with [1/1] lib/igt_gt: Add sentinel to intel_execution_engines2 URL : https://patchwork.freedesktop.org/series/34892/ State : success == Summary == IGT patchset tested on top of latest successful build ece35d37e6b0afc0ba99f66179279960042c87bc

Re: [Intel-gfx] [PATCH] drm/i915: Fix compilation (panel orientation x enum plane rename).

Hi, On 05-12-17 11:14, Daniel Vetter wrote: On Tue, Dec 05, 2017 at 12:12:27PM +0200, Joonas Lahtinen wrote: On Tue, 2017-12-05 at 09:18 +0100, Hans de Goede wrote: Hi, On 05-12-17 01:58, Rodrigo Vivi wrote: On Tue, Dec 05, 2017 at 12:09:35AM +, Michel Thierry wrote: On 12/4/2017 4:04

Re: [Intel-gfx] [PATCH 3/3] i965: check scratch page in a locked fashion on each ioctl

Thanks, I will make a v2 and post it shortly to correct for my terribly embarrassing omission caused by even more terribly embarrassing ignorance. -Kevin -Original Message- From: Chris Wilson [mailto:ch...@chris-wilson.co.uk] Sent: Tuesday, December 5, 2017 12:39 PM To: Rogovin, Kevin

[Intel-gfx] [PATCH 2/2] drm/i915: Assert GGTT writes were flushed before unbinding a GGTT 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. However, we track the PTE using multiple vma, but only a single write_domain on the object, so before unbinding

[Intel-gfx] [PATCH 1/2] drm/i915: Flush pending GTT writes before unbinding

From the shrinker paths, we want to relinquish the GPU and GGTT access to the object, releasing the backing storage back to the system for swapout. As a part of that process we would unpin the pages, marking them for access by the CPU (for the swapout/swapin). However, if that process was

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/3] lib: avoid < in gtkdoc comments

== Series Details == Series: series starting with [1/3] lib: avoid < in gtkdoc comments URL : https://patchwork.freedesktop.org/series/34893/ State : success == Summary == IGT patchset tested on top of latest successful build ece35d37e6b0afc0ba99f66179279960042c87bc tests/gem_seqno_wrap: Drop

Re: [Intel-gfx] [PATCH] drm: savely free connectors from connector_iter

On Mon, Dec 04, 2017 at 09:48:18PM +0100, Daniel Vetter wrote: > In > > commit 613051dac40da1751ab269572766d3348d45a197 > Author: Daniel Vetter > Date: Wed Dec 14 00:08:06 2016 +0100 > > drm: locking iterators for connector_list > > we've went to extreme lengths

Re: [Intel-gfx] [PATCH 3/3] i965: check scratch page in a locked fashion on each ioctl

Quoting Rogovin, Kevin (2017-12-05 10:30:04) > Hi, > > > Per context, then you can remove the locking. It's fitting since the > > scratch page is per-context anyway. > > The scratch page is per context? This I did not know, I thought it was per > PPGTT. If that is the case, then my proposed

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

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 displaying. This will typically be > > implemented > > by the

[Intel-gfx] [PATCH igt 1/2] igt/pm_rc6_residency: Replace hard-coded sleep before rc6 with a probe

Instead of trying to sleep for 2 evaluations intervals and then assuming that rc6 is working, poll the rc6 residency instead. References: https://bugs.freedesktop.org/show_bug.cgi?id=104099 Signed-off-by: Chris Wilson Cc: Tvrtko Ursulin ---

[Intel-gfx] [PATCH igt 2/2] igt/perf_pmu: Replace hard-coded sleep before rc6 with a probe

Instead of trying to sleep for 2 evaluations intervals and then assuming that rc6 is working, poll the rc6 residency instead. References: https://bugs.freedesktop.org/show_bug.cgi?id=103929 Signed-off-by: Chris Wilson Cc: Tvrtko Ursulin ---

[Intel-gfx] ✗ Fi.CI.BAT: warning for drm/i915: Generalize definition for crtc mask

== Series Details == Series: drm/i915: Generalize definition for crtc mask URL : https://patchwork.freedesktop.org/series/34894/ State : warning == Summary == Series 34894v1 drm/i915: Generalize definition for crtc mask https://patchwork.freedesktop.org/api/1.0/series/34894/revisions/1/mbox/

Re: [Intel-gfx] [PATCH 3/3] i965: check scratch page in a locked fashion on each ioctl

Quoting kevin.rogo...@intel.com (2017-12-05 07:48:14) > From: Kevin Rogovin > > --- > src/mesa/drivers/dri/i965/intel_batchbuffer.c | 27 > ++- > 1 file changed, 26 insertions(+), 1 deletion(-) > > diff --git

[Intel-gfx] [PATCH i-g-t 1/1] lib/igt_gt: Add sentinel to intel_execution_engines2

The for_each_engine_class_instance macro stops at e__->name being NULL, so add an object that is so. Signed-off-by: Petri Latvala Cc: Tvrtko Ursulin Cc: Chris Wilson --- lib/igt_gt.c | 1 + 1 file changed, 1

[Intel-gfx] [PATCH i-g-t 3/3] meson: build a full dependency for lib_igt_perf

meson prefers packages dependencies over passing arount static libraries, because those also include linker flags, include dirs and everything else. While at it pull the special cases out from the common build stanzas like we do with other special cases. Just a bit of ocd to keep everything

[Intel-gfx] [PATCH i-g-t 2/3] meson: gtkdoc support

Bunch of neat improvements: - xml generates correctly depend upon the test binaries - no need to re-run autogen.sh when new chapters/functions get added, all handed by meson Still one issue: - the gtkdoc target doesn't depend upon the custom_target yet, hacked around using build_by_default:

[Intel-gfx] [PATCH i-g-t 1/3] lib: avoid < in gtkdoc comments

For reasons entirely not clear to me meson gtkdoc runs in strict xml parsing mode, whereas automake gtkdoc doesn't. And gtkdoc itself is to dense to correctly escape this stuff. Paper around this. v2: {foo} instead of of tripy foo> (Joonas) v3: More fixups (Joonas) Cc: Joonas Lahtinen

Re: [Intel-gfx] [PATCH i-g-t 3/3] meson: build a full dependency for lib_igt_perf

On Tue, Dec 05, 2017 at 11:16:50AM +0100, Daniel Vetter wrote: > meson prefers packages dependencies over passing arount static > libraries, because those also include linker flags, include dirs and > everything else. > > While at it pull the special cases out from the common build stanzas > like

Re: [Intel-gfx] [PATCH] drm/i915: Fix compilation (panel orientation x enum plane rename).

On Tue, 2017-12-05 at 09:18 +0100, Hans de Goede wrote: > Hi, > > On 05-12-17 01:58, Rodrigo Vivi wrote: > > On Tue, Dec 05, 2017 at 12:09:35AM +, Michel Thierry wrote: > > > On 12/4/2017 4:04 PM, Rodrigo Vivi wrote: > > > > When commit '82daca297506 ("drm/i915: Add "panel orientation" > > >

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

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 of pipes defined in device info. Signed-off-by: Mika Kahola --- drivers/gpu/drm/i915/intel_crt.c | 9 ++---

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Disable display crc feature for vgpu

== Series Details == Series: drm/i915: Disable display crc feature for vgpu URL : https://patchwork.freedesktop.org/series/34889/ State : success == Summary == Test gem_tiled_swapping: Subgroup non-threaded: pass -> INCOMPLETE (shard-snb) fdo#104009 Test gem_eio:

Re: [Intel-gfx] [PATCH 3/3] i965: check scratch page in a locked fashion on each ioctl

Hi, > Per context, then you can remove the locking. It's fitting since the scratch > page is per-context anyway. The scratch page is per context? This I did not know, I thought it was per PPGTT. If that is the case, then my proposed interface to get/set the scratch page contents is wrong

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

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 displaying. This will typically be > implemented > by the driver using HDCP. > > The property is a tri-state with the following

Re: [Intel-gfx] [PATCH i-g-t 3/3] meson: build a full dependency for lib_igt_perf

On Tue, Dec 05, 2017 at 12:44:02PM +0200, Petri Latvala wrote: > On Tue, Dec 05, 2017 at 11:16:50AM +0100, Daniel Vetter wrote: > > meson prefers packages dependencies over passing arount static > > libraries, because those also include linker flags, include dirs and > > everything else. > > > >

[Intel-gfx] ✗ Fi.CI.IGT: failure for series starting with [1/1] lib/igt_gt: Add sentinel to intel_execution_engines2

== Series Details == Series: series starting with [1/1] lib/igt_gt: Add sentinel to intel_execution_engines2 URL : https://patchwork.freedesktop.org/series/34892/ State : failure == Summary == Test drv_module_reload: Subgroup basic-no-display: pass -> DMESG-WARN

[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [1/2] drm/i915: Flush pending GTT writes before unbinding

== Series Details == Series: series starting with [1/2] drm/i915: Flush pending GTT writes before unbinding URL : https://patchwork.freedesktop.org/series/34899/ State : failure == Summary == Series 34899v1 series starting with [1/2] drm/i915: Flush pending GTT writes before unbinding

Re: [Intel-gfx] [RFC 0/4] GPU/CPU timestamps correlation for relating OA samples with system events

On Tue, Dec 5, 2017 at 2:16 PM, Lionel Landwerlin < lionel.g.landwer...@intel.com> wrote: > Hey Sagar, > > Sorry for the delay looking into this series. > I've done some userspace/UI work in GPUTop to try to correlate perf > samples/tracepoints with i915 perf reports. > > I wanted to avoid having

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

On Tuesday 05 December 2017 10:45 AM, Sean Paul wrote: +static +bool intel_dp_hdcp_check_link(struct intel_digital_port *intel_dig_port) +{ + ssize_t ret; + u8 bstatus; + ret = drm_dp_dpcd_read(_dig_port->dp.aux, DP_AUX_HDCP_BSTATUS, + , 1); +

Re: [Intel-gfx] [RFC 0/4] GPU/CPU timestamps correlation for relating OA samples with system events

On 05/12/17 14:28, Robert Bragg wrote: On Tue, Dec 5, 2017 at 2:16 PM, Lionel Landwerlin > wrote: Hey Sagar, Sorry for the delay looking into this series. I've done some userspace/UI work in GPUTop to try to

Re: [Intel-gfx] [RFC PATCH 0/6] drm/i915: Implement HDCP

On Tue, Dec 5, 2017 at 8:45 AM, Ville Syrjälä wrote: > On Thu, Nov 30, 2017 at 08:50:38AM +0100, Daniel Vetter wrote: >> On Wed, Nov 29, 2017 at 10:08:55PM -0500, Sean Paul wrote: >> > Here's the RFC for my i915 HDCP patchset. The UABI is based on what we've >> >

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

On Tue, 2017-12-05 at 15:59 +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

[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

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

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

[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] ✓ 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

[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)

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] [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

[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 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 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 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 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 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 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

[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 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] ✗ 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

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.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

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

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 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

[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 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] [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 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 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] [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 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] 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 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] [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

[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] 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] [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] [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: 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

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: 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] [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

[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

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 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

  1   2   >