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

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

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

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

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

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

[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] [PATCH i-g-t 2/2] kms_content_protection: Add Content Protection test

On Tue, Dec 5, 2017 at 11:07 AM, Ville Syrjälä 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

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

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

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 >

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

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

[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

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

[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

[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

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

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

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?

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

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

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/2] igt/pm_rc6_residency: Replace hard-coded sleep before rc6 with a probe

== Series Details == Series: series starting with [1/2] igt/pm_rc6_residency: Replace hard-coded sleep before rc6 with a probe URL : https://patchwork.freedesktop.org/series/34897/ State : success == Summary == IGT patchset tested on top of latest successful build

[Intel-gfx] ✗ Fi.CI.IGT: failure 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 : failure == Summary == Test kms_flip: Subgroup plain-flip-fb-recreate-interruptible: pass -> FAIL

[Intel-gfx] [PATCH 2/2] drm/i915: Track GGTT 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

[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] [PATCH igt] lib: Check and report if a subtest triggers a new kernel taint

Checking for a tainted kernel is a convenient way to see if the test generated a critical error such as a oops, or machine check. v2: Docs? Signed-off-by: Chris Wilson Cc: Daniel Vetter Cc: Radoslaw Szwichtenberg

Re: [Intel-gfx] [PATCH igt] lib: Check and report if a subtest triggers a new kernel taint

On Tue, Dec 05, 2017 at 12:24:53PM +, Chris Wilson wrote: > Checking for a tainted kernel is a convenient way to see if the test > generated a critical error such as a oops, or machine check. > > v2: Docs? > > Signed-off-by: Chris Wilson > Cc: Daniel Vetter

[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/34900/ State : failure == Summary == Series 34900v1 series starting with [1/2] drm/i915: Flush pending GTT writes before unbinding

Re: [Intel-gfx] [PATCH igt] lib: Check and report if a subtest triggers a new kernel taint

On Tue, Dec 05, 2017 at 12:38:19PM +, Chris Wilson wrote: > Quoting Petri Latvala (2017-12-05 12:32:36) > > On Tue, Dec 05, 2017 at 12:24:53PM +, Chris Wilson wrote: > > > Checking for a tainted kernel is a convenient way to see if the test > > > generated a critical error such as a oops,

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

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) && ! > > IS_SKYLAKE(dev_priv)) > > > > Nitpick: could be just

[Intel-gfx] [PATCH v2] 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 igt 1/2] igt/pm_rc6_residency: Replace hard-coded sleep before rc6 with a probe

On 05/12/2017 10:56, Chris Wilson wrote: 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:

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

Quoting Tvrtko Ursulin (2017-12-05 12:05:14) > > On 05/12/2017 10:56, Chris Wilson wrote: > > 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

[Intel-gfx] ✗ Fi.CI.IGT: warning for series starting with [1/2] igt/pm_rc6_residency: Replace hard-coded sleep before rc6 with a probe

== Series Details == Series: series starting with [1/2] igt/pm_rc6_residency: Replace hard-coded sleep before rc6 with a probe URL : https://patchwork.freedesktop.org/series/34897/ State : warning == Summary == Test kms_setmode: Subgroup basic: fail -> PASS

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

On Sat, Dec 02, 2017 at 01:58:12AM +0200, Rogozhkin, Dmitry V wrote: > On Thu, 2017-11-30 at 13:19 +0200, Imre Deak wrote: > > On Thu, Nov 30, 2017 at 09:45:25AM +, Chris Wilson wrote: > > > Quoting Tvrtko Ursulin (2017-11-30 09:18:20) > > > > From: Tvrtko Ursulin >

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

On 05/12/2017 10:56, Chris Wilson wrote: 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:

Re: [Intel-gfx] [PATCH igt] lib: Check and report if a subtest triggers a new kernel taint

Quoting Petri Latvala (2017-12-05 12:32:36) > On Tue, Dec 05, 2017 at 12:24:53PM +, Chris Wilson wrote: > > Checking for a tainted kernel is a convenient way to see if the test > > generated a critical error such as a oops, or machine check. > > > > v2: Docs? > > > > Signed-off-by: Chris

Re: [Intel-gfx] [PATCH] drm/i915/skl: DMC firmware for skylake v1.27

On Thu, Nov 09, 2017 at 05:18:32PM -0800, Anusha Srivatsa wrote: > There is a new version of dmc available for skylake. > Following additions from ver1.27 > > 1. Fix for the issue where DC_STATE was getting enabled even when > disabled by driver causing data corruption. > > Cc: Rodrigo Vivi

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

Quoting Daniel Vetter (2017-12-05 15:34:36) > Two bits missing imo: > - Should explain that userspace should poll this property to detect a > change from ENABLED to DESIRED (and take adequate actions and e.g. stop > the stream). No uevent will be sent out because the HDCP specs require >

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

On Tue, Dec 5, 2017 at 3:22 AM, 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

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 Can we get a chamelium

[Intel-gfx] ✗ Fi.CI.BAT: failure 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 : failure == Summary == Series 24017v6 drm/i915: Restore GT performance in headless mode with DMC loaded

Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: Implement HDCP (rev3)

On Tue, Dec 05, 2017 at 05:21:25AM -, Patchwork wrote: > == Series Details == > > Series: drm/i915: Implement HDCP (rev3) > URL : https://patchwork.freedesktop.org/series/34671/ > State : failure > > == Summary == > > Applying: drm: Fix link-status kerneldoc line lengths > error: Failed

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

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? On Tue, 2017-11-28 at 10:54 +0200, Joonas Lahtinen wrote: > Hello, > > TL;DR Reply with backported patches for v4.15-rc1 latest TODAY > > Dear patch authors/Cc:s, the

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

On Tue, Dec 05, 2017 at 09:07:58AM +0100, Hans Verkuil wrote: > 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

[Intel-gfx] [PATCH] lockdep: Mark up lock disabling with TAINT_CRAP

When testing with lockdep disabled, if it becomes disabled due to some error or other that makes subsequenting testing incomplete, it taints the test result. Make this obvious to the test infrastructure by adding TAINT_CRAP. Signed-off-by: Chris Wilson Cc: Tomi Sarvela

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

On Tue, Dec 05, 2017 at 12:15:02AM -0500, 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

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

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

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

Quoting Tvrtko Ursulin (2017-12-05 13:28:54) > From: Tvrtko Ursulin > > It seems that the DMC likes to transition between the DC states a lot when > there are no connected displays (no active power domains) during command > submission. > > This activity on DC states

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

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 of pipes defined in device info. > > Signed-off-by: Mika Kahola

Re: [Intel-gfx] [RFC 4/4] drm/i915/perf: Send system clock monotonic time in perf samples

On 15/11/17 12:13, Sagar Arun Kamble wrote: From: Sourab Gupta Currently, we have the ability to only forward the GPU timestamps in the samples (which are generated via OA reports). This limits the ability to correlate these samples with the system events. An ability

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

On Mon, Dec 04, 2017 at 04:04:15PM -0800, Rodrigo Vivi wrote: > When commit '82daca297506 ("drm/i915: Add "panel orientation" > property to the panel connector, v6.")' was done and tested > by CI, commit 'ed15030d7ab0 ("drm/i915: s/enum plane/enum > i9xx_plane_id/")' wasn't there already. > > On

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

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 > > been > > using in Chrome for the past 3 years. I posted the property to the list back > >

Re: [Intel-gfx] [RFC 1/4] drm/i915/perf: Add support to correlate GPU timestamp with system time

On 15/11/17 12:25, Chris Wilson wrote: Quoting Sagar Arun Kamble (2017-11-15 12:13:51) #include #include @@ -2149,6 +2150,14 @@ struct i915_perf_stream { * @oa_config: The OA configuration used by the stream. */ struct i915_oa_config *oa_config; + + /**

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

On Tue, 2017-12-05 at 10:41 +, Rogovin, Kevin wrote: > Thanks, I will make a v2 and post it shortly to correct for my > terribly embarrassing omission caused by even more terribly > embarrassing ignorance. To avoid v3, do concept the code around suggested existing I915_GEM_CONTEXT_GETPARAM

Re: [Intel-gfx] ✗ Fi.CI.IGT: warning for drm/i915/skl: DMC firmware for skylake v1.27

On Fri, Nov 10, 2017 at 09:20:10AM +, Patchwork wrote: > == Series Details == > > Series: drm/i915/skl: DMC firmware for skylake v1.27 > URL : https://patchwork.freedesktop.org/series/33568/ > State : warning Thanks for the patch, pushed it to drm-tip. > > == Summary == > > Test

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

On Tue, 2017-12-05 at 15:38 +0200, Ville Syrjälä wrote: > On Mon, Dec 04, 2017 at 04:04:15PM -0800, Rodrigo Vivi wrote: > > When commit '82daca297506 ("drm/i915: Add "panel orientation" > > property to the panel connector, v6.")' was done and tested > > by CI, commit 'ed15030d7ab0 ("drm/i915:

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

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 to add too much logic into the kernel and tried to sample both cpu clocks & gpu timestamps from

[Intel-gfx] ✓ Fi.CI.BAT: success 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 : success == Summary == Series 34900v2 series starting with [1/2] drm/i915: Flush pending GTT writes before

<    1   2