Re: [Intel-gfx] [PATCH 0/7] drm/edid and drivers: ELD refactoring

On Wed, Nov 1, 2017 at 10:20 AM, Jani Nikula wrote: > We were recently bitten by drm_edid_to_eld() clearing the connector > type, and us failing to set it back for DP. Here's a few ELD related > patches to try to unify ELD handling and make it a bit simpler for > drivers to

[Intel-gfx] [PATCH] drm/i915/dmc: DMC 1.04 for Kabylake

There is a new version of DMC available for KBL. The release notes mentions: 1. Fix for the issue where DC_STATE was getting enabled even when disabled by driver causing data corruption. Adding the pull request here as an experiment- The following changes since commit

Re: [Intel-gfx] [PATCH] drm/i915/guc: Clear terminated attribute bit on GuC preemption context

On 01/11/17 15:16, jeff.mc...@intel.com wrote: From: Jeff McGee If GuC firmware performs an engine reset while that engine had a preemption pending, it will set the terminated attribute bit on our preemption stage descriptor. GuC firmware retains all pending work items

[Intel-gfx] [PATCH igt v2] igt/gem_ctx_isolation: Check isolation of registers between contexts

A new context assumes that all of its registers are in the default state when it is created. What may happen is that a register written by one context may leak into the second, causing mass confusion. v2: extend back to Sandybridge, ignore non-priv registers that are not context-saved (remind me

Re: [Intel-gfx] [PATCH] drm/i915/gen9: Add WaVFEStateAfterPipeControlwithMediaStateClear

Quoting Arun Siluvery (2016-06-03 12:40:00) > Kernel only need to add a register to HW whitelist, required for a > preemption related issue. > > Reference: HSD#2131039 > Signed-off-by: Arun Siluvery > --- > drivers/gpu/drm/i915/i915_reg.h | 1 + >

[Intel-gfx] [PATCH] drm/i915/guc: Clear terminated attribute bit on GuC preemption context

From: Jeff McGee If GuC firmware performs an engine reset while that engine had a preemption pending, it will set the terminated attribute bit on our preemption stage descriptor. GuC firmware retains all pending work items for a high-priority GuC client, unlike the

[Intel-gfx] [PULL] drm-intel-fixes

Hi Dave, Here goes drm-intel-fixes-2017-11-01. Fixes for Stable: - Fix KBL Blank Screen (Jani) - Fix FIFO Underrun on SNB (Maarten) Other fixes: - Fix GPU Hang on i915gm (Chris) - Fix gem_tiled_pread_pwrite IGT case (Chris) - Cancel modeset retry work during modeset clean-up (Manasi) Thanks,

[Intel-gfx] ✓ Fi.CI.IGT: success for drm: drm_plane_helper_check_state() related stuff (rev3)

== Series Details == Series: drm: drm_plane_helper_check_state() related stuff (rev3) URL : https://patchwork.freedesktop.org/series/33002/ State : success == Summary == Test drv_module_reload: Subgroup basic-reload: pass -> DMESG-WARN (shard-hsw) fdo#102707 Test

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Implement ReadHitWriteOnlyDisable.

== Series Details == Series: drm/i915: Implement ReadHitWriteOnlyDisable. URL : https://patchwork.freedesktop.org/series/32991/ State : success == Summary == Series 32991v1 drm/i915: Implement ReadHitWriteOnlyDisable. https://patchwork.freedesktop.org/api/1.0/series/32991/revisions/1/mbox/

Re: [Intel-gfx] [PATCH] drm/i915: Implement ReadHitWriteOnlyDisable.

On Wed, Nov 01, 2017 at 02:11:05PM -0700, Rodrigo Vivi wrote: > On Wed, Nov 01, 2017 at 04:32:35PM +, Rafael Antognolli wrote: > > The workaround for this is described as: > > > > "if RenderSurfaceState.Num_Multisamples > 1, disable RCC clock gating if > > RenderSurfaceState.Num_Multisamples

[Intel-gfx] ✗ Fi.CI.BAT: warning for drm/i915: Flush the irq and tasklets before asserting engine is idle

== Series Details == Series: drm/i915: Flush the irq and tasklets before asserting engine is idle URL : https://patchwork.freedesktop.org/series/33009/ State : warning == Summary == Series 33009v1 drm/i915: Flush the irq and tasklets before asserting engine is idle

Re: [Intel-gfx] [PATCH v2] drm/i915/cnl: Symmetric scalers for each pipe

On Wed, Nov 01, 2017 at 10:08:50AM +, Mika Kahola wrote: > For Cannonlake the number of scalers for each pipe is 2. Let's increase > the number of scalers for pipe C. > > v2: Use INTEL_GEN() instead of IS_CANNONLAKE() > > Signed-off-by: Mika Kahola also... merged to

Re: [Intel-gfx] [PATCH v2] drm/i915/cnl: Symmetric scalers for each pipe

On Wed, Nov 01, 2017 at 10:08:50AM +, Mika Kahola wrote: > For Cannonlake the number of scalers for each pipe is 2. Let's increase > the number of scalers for pipe C. > > v2: Use INTEL_GEN() instead of IS_CANNONLAKE() > > Signed-off-by: Mika Kahola Reviewed-by:

Re: [Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915: Implement ReadHitWriteOnlyDisable.

On Wed, Nov 01, 2017 at 08:56:59PM +, Patchwork wrote: > == Series Details == > > Series: drm/i915: Implement ReadHitWriteOnlyDisable. > URL : https://patchwork.freedesktop.org/series/32991/ > State : failure > > == Summary == > > Test kms_flip: > Subgroup

[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915: Don't try to use negative pll_id.

== Series Details == Series: drm/i915: Don't try to use negative pll_id. URL : https://patchwork.freedesktop.org/series/33004/ State : failure == Summary == Test kms_frontbuffer_tracking: Subgroup fbc-1p-pri-indfb-multidraw: pass -> FAIL (shard-hsw) Test

Re: [Intel-gfx] [PATCH] drm/i915: Implement ReadHitWriteOnlyDisable.

On Wed, Nov 01, 2017 at 04:32:35PM +, Rafael Antognolli wrote: > The workaround for this is described as: > > "if RenderSurfaceState.Num_Multisamples > 1, disable RCC clock gating if > RenderSurfaceState.Num_Multisamples == 1, set 0x7010[14] = 1" > > So it looks like the userspace should be

[Intel-gfx] ✓ Fi.CI.BAT: success for drm: drm_plane_helper_check_state() related stuff (rev3)

== Series Details == Series: drm: drm_plane_helper_check_state() related stuff (rev3) URL : https://patchwork.freedesktop.org/series/33002/ State : success == Summary == Series 33002v3 drm: drm_plane_helper_check_state() related stuff

[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915: Implement ReadHitWriteOnlyDisable.

== Series Details == Series: drm/i915: Implement ReadHitWriteOnlyDisable. URL : https://patchwork.freedesktop.org/series/32991/ State : failure == Summary == Test kms_flip: Subgroup plain-flip-fb-recreate-interruptible: pass -> FAIL (shard-hsw) fdo#100368

Re: [Intel-gfx] [PATCH v6] drm/i915/guc: Add support for reset engine using GuC commands

On Wed, Nov 01, 2017 at 01:58:04PM +, Chris Wilson wrote: > Quoting Michel Thierry (2017-10-31 22:53:09) > > This patch adds per engine reset and recovery (TDR) support when GuC is > > used to submit workloads to GPU. > > > > In the case of i915 directly submission to ELSP, driver manages

[Intel-gfx] [PATCH] drm/i915: Flush the irq and tasklets before asserting engine is idle

Before we assert that the engine is idle, make sure we flush any residual tasklet. After that point, if the engine is not idle, more work may be queued despite us trying to park the engine and go to sleep. References: https://bugs.freedesktop.org/show_bug.cgi?id=103479 Signed-off-by: Chris Wilson

[Intel-gfx] [PATCH v2 5/5] drm: Move drm_plane_helper_check_state() into drm_atomic_helper.c

From: Ville Syrjälä drm_plane_helper_check_update() isn't a transitional helper, so let's rename it to drm_atomic_helper_check_plane_state() and move it into drm_atomic_helper.c. v2: Fix the WARNs about plane_state->crtc matching crtc_state->crtc Cc: Daniel

[Intel-gfx] [PATCH v2 4/5] drm: Check crtc_state->enable rather than crtc->enabled in drm_plane_helper_check_state()

From: Ville Syrjälä drm_plane_helper_check_state() is supposed to do things the atomic way, so it should not be inspecting crtc->enabled. Rather we should be looking at crtc_state->enable. We have a slight complication due to drm_plane_helper_check_update()

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Don't try to use negative pll_id.

== Series Details == Series: drm/i915: Don't try to use negative pll_id. URL : https://patchwork.freedesktop.org/series/33004/ State : success == Summary == Series 33004v1 drm/i915: Don't try to use negative pll_id. https://patchwork.freedesktop.org/api/1.0/series/33004/revisions/1/mbox/

Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for drm: drm_plane_helper_check_state() related stuff

On Wed, Nov 01, 2017 at 07:46:18PM -, Patchwork wrote: > == Series Details == > > Series: drm: drm_plane_helper_check_state() related stuff > URL : https://patchwork.freedesktop.org/series/33002/ > State : failure > > == Summary == > > Series 33002v1 drm: drm_plane_helper_check_state()

Re: [Intel-gfx] [maintainer-tools PATCH] dim: Sign commits in addition to tags

> -Original Message- > From: dim-tools [mailto:dim-tools-boun...@lists.freedesktop.org] On Behalf > Of Sean Paul > Sent: Wednesday, November 01, 2017 8:52 AM > To: Gustavo Padovan > Cc: Daniel Vetter; Intel Graphics Development; dim- > to...@lists.freedesktop.org; dri-devel; Daniel Vetter

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm: drm_plane_helper_check_state() related stuff

== Series Details == Series: drm: drm_plane_helper_check_state() related stuff URL : https://patchwork.freedesktop.org/series/33002/ State : failure == Summary == Series 33002v1 drm: drm_plane_helper_check_state() related stuff

Re: [Intel-gfx] [PATCH] drm/i915: Don't try to use negative pll_id.

On Wed, Nov 01, 2017 at 07:08:52PM +, Manasi Navare wrote: > On Wed, Nov 01, 2017 at 11:44:58AM -0700, Rodrigo Vivi wrote: > > It is unlikely we are getting the -1 here. > > But if we propagate that pll_id -1 to the rest of the code > > we might have funny calculations on link_clock and who >

Re: [Intel-gfx] [PATCH] drm/i915: Don't try to use negative pll_id.

On Wed, Nov 01, 2017 at 12:13:42PM -0700, Rodrigo Vivi wrote: > On Wed, Nov 01, 2017 at 06:56:55PM +, Ville Syrjälä wrote: > > On Wed, Nov 01, 2017 at 11:44:58AM -0700, Rodrigo Vivi wrote: > > > It is unlikely we are getting the -1 here. > > > But if we propagate that pll_id -1 to the rest of

[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [1/2] drm/i915: Ignore previous watermarks on ILK if inherited

== Series Details == Series: series starting with [1/2] drm/i915: Ignore previous watermarks on ILK if inherited URL : https://patchwork.freedesktop.org/series/32995/ State : failure == Summary == Series 32995 revision 1 was fully merged or fully failed: no git log

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Implement ReadHitWriteOnlyDisable.

== Series Details == Series: drm/i915: Implement ReadHitWriteOnlyDisable. URL : https://patchwork.freedesktop.org/series/32991/ State : success == Summary == Series 32991v1 drm/i915: Implement ReadHitWriteOnlyDisable. https://patchwork.freedesktop.org/api/1.0/series/32991/revisions/1/mbox/

Re: [Intel-gfx] [PATCH] drm/i915: Don't try to use negative pll_id.

On Wed, Nov 01, 2017 at 06:56:55PM +, Ville Syrjälä wrote: > On Wed, Nov 01, 2017 at 11:44:58AM -0700, Rodrigo Vivi wrote: > > It is unlikely we are getting the -1 here. > > But if we propagate that pll_id -1 to the rest of the code > > we might have funny calculations on link_clock and who >

Re: [Intel-gfx] [PATCH] drm/i915: Don't try to use negative pll_id.

On Wed, Nov 01, 2017 at 11:44:58AM -0700, Rodrigo Vivi wrote: > It is unlikely we are getting the -1 here. > But if we propagate that pll_id -1 to the rest of the code > we might have funny calculations on link_clock and who > knows what registers we end up accessing. > > Better to protect the

Re: [Intel-gfx] [PATCH] drm/i915: Don't try to use negative pll_id.

On Wed, Nov 01, 2017 at 11:44:58AM -0700, Rodrigo Vivi wrote: > It is unlikely we are getting the -1 here. > But if we propagate that pll_id -1 to the rest of the code > we might have funny calculations on link_clock and who > knows what registers we end up accessing. > > Better to protect the

[Intel-gfx] ✗ Fi.CI.BAT: warning for drm/edid and drivers: ELD refactoring

== Series Details == Series: drm/edid and drivers: ELD refactoring URL : https://patchwork.freedesktop.org/series/32979/ State : warning == Summary == Series 32979v1 drm/edid and drivers: ELD refactoring https://patchwork.freedesktop.org/api/1.0/series/32979/revisions/1/mbox/ Test chamelium:

[Intel-gfx] [PATCH] drm/i915: Don't try to use negative pll_id.

It is unlikely we are getting the -1 here. But if we propagate that pll_id -1 to the rest of the code we might have funny calculations on link_clock and who knows what registers we end up accessing. Better to protect the code. Also better with errno number instead of generic -1. Cc: Manasi

[Intel-gfx] [PATCH 4/5] drm: Check crtc_state->enable rather than crtc->enabled in drm_plane_helper_check_state()

From: Ville Syrjälä drm_plane_helper_check_state() is supposed to do things the atomic way, so it should not be inspecting crtc->enabled. Rather we should be looking at crtc_state->enable. We have a slight complication due to drm_plane_helper_check_update()

[Intel-gfx] [PATCH 5/5] drm: Move drm_plane_helper_check_state() into drm_atomic_helper.c

From: Ville Syrjälä drm_plane_helper_check_update() isn't a transitional helper, so let's rename it to drm_atomic_helper_check_plane_state() and move it into drm_atomic_helper.c. Cc: Daniel Vetter Suggested-by: Daniel Vetter

[Intel-gfx] [PATCH 2/5] drm/vmwgfx: Use drm_plane_helper_check_state()

From: Ville Syrjälä Atomic drivers have no reason to use drm_plane_helper_check_update() instead of drm_plane_helper_check_state(). So let's switch over. Cc: VMware Graphics Cc: Sinclair Yeh Cc: Thomas

[Intel-gfx] [PATCH 3/5] drm/vmwgfx: Try to fix plane clipping

From: Ville Syrjälä Try to fix the code to actually clip the plane to the crtc bounds instead of the user provided crtc coordinates (which would be a no-op since those are exactly the coordinates before clipping). Cc: VMware Graphics

[Intel-gfx] [PATCH 0/5] drm: drm_plane_helper_check_state() related stuff

From: Ville Syrjälä While trawling the tree I spotted some issues with the way vmwgfx uses drm_plane_helper_check_state(). Here's my attempt at fixing it. Do note that I haven't actually tested the resulting code at all, but it does build at least. And while

[Intel-gfx] [PATCH 1/5] drm/vmwgfx: Remove bogus crtc coords vs fb size check

From: Ville Syrjälä Throw away the bugs crtc coords vs. fb size check. Crtc coords don't define the viewport inside the fb, that's a job for the src coords, which have been checked by the core already. Cc: VMware Graphics Cc:

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/4] drm: Enable pr_debug() for drm_printer

== Series Details == Series: series starting with [1/4] drm: Enable pr_debug() for drm_printer URL : https://patchwork.freedesktop.org/series/32750/ State : success == Summary == Series 32750v1 series starting with [1/4] drm: Enable pr_debug() for drm_printer

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/drm_vma_manager.c: Remove useless goto statement

== Series Details == Series: drm/drm_vma_manager.c: Remove useless goto statement URL : https://patchwork.freedesktop.org/series/32987/ State : success == Summary == Test kms_flip: Subgroup flip-vs-blocking-wf-vblank: fail -> PASS (shard-hsw)

Re: [Intel-gfx] [maintainer-tools PATCH] dim: Sign commits in addition to tags

On Wed, Nov 1, 2017 at 1:00 PM, Eric Anholt wrote: > Sean Paul writes: > >> On Wed, Nov 1, 2017 at 7:12 AM, Gustavo Padovan wrote: >>> 2017-10-31 Sean Paul : >>> On Tue, Oct 31, 2017 at 1:31 PM, Daniel

[Intel-gfx] [(RESEND for CI) PATCH 2/2] drm/i915: Re-enable fastboot by default

This fix was originally reverted because it left a chromebook pixel black, and no immediate fix was available. This has been fixed in the meantime. Rather than trying to remove the parameter, set it to default to true for now, so we can always back out if required. Signed-off-by: Maarten

[Intel-gfx] [PATCH 1/2] drm/i915: Ignore previous watermarks on ILK if inherited

Fixes the following error when fastset is enabled, caught by CI: [drm:ilk_validate_wm_level.part.8 [i915]] Sprite WM0 too large 56 (max 0) [drm:ilk_validate_pipe_wm [i915]] LP0 watermark invalid [drm:intel_crtc_atomic_check [i915]] No valid intermediate pipe watermarks are possible Triggered on

Re: [Intel-gfx] [PATCH] drm/atomic: Try to preserve the crtc enabled state in drm_atomic_remove_fb, v2.

Op 01-11-17 om 18:00 schreef Ville Syrjälä: > On Wed, Nov 01, 2017 at 04:55:06PM +0100, Maarten Lankhorst wrote: >> Op 01-11-17 om 16:29 schreef Ville Syrjälä: >>> On Wed, Nov 01, 2017 at 04:04:33PM +0100, Maarten Lankhorst wrote: This introduces a slight behavioral change to rmfb. Instead of

[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [1/4] drm: Enable pr_debug() for drm_printer

== Series Details == Series: series starting with [1/4] drm: Enable pr_debug() for drm_printer URL : https://patchwork.freedesktop.org/series/32750/ State : failure == Summary == Series 32750v1 series starting with [1/4] drm: Enable pr_debug() for drm_printer

Re: [Intel-gfx] [PATCH v3] drm/i915: Remove unsafe i915.enable_rc6

On Wed, Nov 01, 2017 at 04:21:08PM +, Ben Widawsky wrote: > On 17-11-01 18:09:47, Joonas Lahtinen wrote: > > + Kimmo and Paul > > > > On Wed, 2017-11-01 at 07:43 -0700, Ben Widawsky wrote: > > > On 17-11-01 14:07:28, Joonas Lahtinen wrote: > > > > On Mon, 2017-10-30 at 10:48 -0700, Rodrigo

Re: [Intel-gfx] [PATCH] drm/atomic: Try to preserve the crtc enabled state in drm_atomic_remove_fb, v2.

On Wed, Nov 01, 2017 at 04:55:06PM +0100, Maarten Lankhorst wrote: > Op 01-11-17 om 16:29 schreef Ville Syrjälä: > > On Wed, Nov 01, 2017 at 04:04:33PM +0100, Maarten Lankhorst wrote: > >> This introduces a slight behavioral change to rmfb. Instead of > >> disabling a crtc when the primary plane

Re: [Intel-gfx] [maintainer-tools PATCH] dim: Sign commits in addition to tags

Sean Paul writes: > On Wed, Nov 1, 2017 at 7:12 AM, Gustavo Padovan wrote: >> 2017-10-31 Sean Paul : >> >>> On Tue, Oct 31, 2017 at 1:31 PM, Daniel Vetter wrote: >>> > On Tue, Oct 31, 2017 at 5:14 PM, Sean Paul

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/drm_vma_manager.c: Remove useless goto statement

== Series Details == Series: drm/drm_vma_manager.c: Remove useless goto statement URL : https://patchwork.freedesktop.org/series/32987/ State : success == Summary == Series 32987v1 drm/drm_vma_manager.c: Remove useless goto statement

Re: [Intel-gfx] [PATCH 6/7] drm/drivers: drop redundant drm_edid_to_eld() calls

Jani Nikula writes: > drm_add_edid_modes() now fills in the ELD automatically, so the calls to > drm_edid_to_eld() are redundant. Remove them. > > All the other places are obvious, but nv50 has detached > drm_edid_to_eld() from the drm_add_edid_modes() call. Nice! For

Re: [Intel-gfx] [PATCH 1/2] drm/i915: Runtime disable for eDP DRRS

> -Original Message- > From: Vivi, Rodrigo > Sent: Wednesday, November 1, 2017 12:27 AM > To: C, Ramalingam > Cc: intel-gfx@lists.freedesktop.org; Zanoni, Paulo R > ; ch...@chris-wilson.co.uk > Subject: Re: [PATCH 1/2] drm/i915: Runtime

[Intel-gfx] [PATCH] drm/i915: Implement ReadHitWriteOnlyDisable.

The workaround for this is described as: "if RenderSurfaceState.Num_Multisamples > 1, disable RCC clock gating if RenderSurfaceState.Num_Multisamples == 1, set 0x7010[14] = 1" So it looks like the userspace should be responsible for setting these, based on the number of multisamples dependency.

[Intel-gfx] ✗ Fi.CI.BAT: warning for drm/atomic: Try to preserve the crtc enabled state in drm_atomic_remove_fb, v2.

== Series Details == Series: drm/atomic: Try to preserve the crtc enabled state in drm_atomic_remove_fb, v2. URL : https://patchwork.freedesktop.org/series/32985/ State : warning == Summary == Series 32985v1 drm/atomic: Try to preserve the crtc enabled state in drm_atomic_remove_fb, v2.

Re: [Intel-gfx] [PATCH v3] drm/i915: Remove unsafe i915.enable_rc6

On 17-11-01 18:09:47, Joonas Lahtinen wrote: + Kimmo and Paul On Wed, 2017-11-01 at 07:43 -0700, Ben Widawsky wrote: On 17-11-01 14:07:28, Joonas Lahtinen wrote: > On Mon, 2017-10-30 at 10:48 -0700, Rodrigo Vivi wrote: > > On Mon, Oct 30, 2017 at 01:00:51PM +, David Weinehall wrote: > > >

Re: [Intel-gfx] [PATCH v3] drm/i915: Remove unsafe i915.enable_rc6

+ Kimmo and Paul On Wed, 2017-11-01 at 07:43 -0700, Ben Widawsky wrote: > On 17-11-01 14:07:28, Joonas Lahtinen wrote: > > On Mon, 2017-10-30 at 10:48 -0700, Rodrigo Vivi wrote: > > > On Mon, Oct 30, 2017 at 01:00:51PM +, David Weinehall wrote: > > > > On Fri, Oct 27, 2017 at 01:57:09PM

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: Re-enable fastboot by default

== Series Details == Series: drm/i915: Re-enable fastboot by default URL : https://patchwork.freedesktop.org/series/32984/ State : failure == Summary == Series 32984v1 drm/i915: Re-enable fastboot by default https://patchwork.freedesktop.org/api/1.0/series/32984/revisions/1/mbox/ Test

Re: [Intel-gfx] [PATCH v2 2/2] Test case for drm_vblank_cleanup refcount validation patch

Hi Daniel, On 1 November 2017 at 14:23, Daniel Vetter wrote: > On Wed, Nov 01, 2017 at 09:48:28AM +0530, PrasannaKumar Muralidharan wrote: >> Hi Daniel, >> >> On 31 October 2017 at 21:57, Daniel Vetter wrote: >> > On Tue, Oct 31, 2017 at 08:37:21PM +0530,

Re: [Intel-gfx] [PATCH] drm/atomic: Try to preserve the crtc enabled state in drm_atomic_remove_fb, v2.

Op 01-11-17 om 16:29 schreef Ville Syrjälä: > On Wed, Nov 01, 2017 at 04:04:33PM +0100, Maarten Lankhorst wrote: >> This introduces a slight behavioral change to rmfb. Instead of >> disabling a crtc when the primary plane is disabled, we try to >> preserve it. >> >> Apart from old versions of the

[Intel-gfx] [drm-intel:for-linux-next 3/4] drivers/gpu/drm/i915/intel_engine_cs.c:1620:30: error: 'dev_priv' undeclared

tree: git://anongit.freedesktop.org/drm-intel for-linux-next head: 3265124a2d3744d789ede58452ab6f8a9b454be8 commit: 680273879d125d644831b8de42c66576e6290378 [3/4] drm/i915: Move parking-while-active warning to intel_engines_park() config: i386-randconfig-x003-201744 (attached as .config)

[Intel-gfx] ✗ Fi.CI.BAT: warning for drm/edid and drivers: ELD refactoring

== Series Details == Series: drm/edid and drivers: ELD refactoring URL : https://patchwork.freedesktop.org/series/32979/ State : warning == Summary == Series 32979v1 drm/edid and drivers: ELD refactoring https://patchwork.freedesktop.org/api/1.0/series/32979/revisions/1/mbox/ Test

Re: [Intel-gfx] [PATCH] drm/atomic: Try to preserve the crtc enabled state in drm_atomic_remove_fb, v2.

On Wed, Nov 01, 2017 at 04:04:33PM +0100, Maarten Lankhorst wrote: > This introduces a slight behavioral change to rmfb. Instead of > disabling a crtc when the primary plane is disabled, we try to > preserve it. > > Apart from old versions of the vmwgfx xorg driver, there is > nothing depending

Re: [Intel-gfx] [PATCH] drm/i915: Generalize transcoder looping

On Wed, 01 Nov 2017, Mika Kahola wrote: > To make looping through transcoders in intel_ddi.c more generic, let's switch > to use 'for_each_pipe()' macro to do this. > > Signed-off-by: Mika Kahola > --- > drivers/gpu/drm/i915/intel_ddi.c | 2 +- > 1

[Intel-gfx] ✗ Fi.CI.BAT: warning for drm/edid and drivers: ELD refactoring

== Series Details == Series: drm/edid and drivers: ELD refactoring URL : https://patchwork.freedesktop.org/series/32979/ State : warning == Summary == Series 32979v1 drm/edid and drivers: ELD refactoring https://patchwork.freedesktop.org/api/1.0/series/32979/revisions/1/mbox/ Test chamelium:

Re: [Intel-gfx] [PATCH] drm/i915: Re-enable fastboot by default

On Wed, Nov 01, 2017 at 05:06:43PM +0200, Ville Syrjälä wrote: > On Wed, Nov 01, 2017 at 03:53:25PM +0100, Maarten Lankhorst wrote: > > This fix was originally reverted because it left a chromebook pixel > > black, and no immediate fix was available. This has been fixed in the > > meantime. > > >

Re: [Intel-gfx] [PATCH 4/4] drm/i915: Give more details for the active-when-parking warning for the engines

Quoting Mika Kuoppala (2017-10-27 14:25:09) > Chris Wilson writes: > > > If the we think the engine is still active when we attempt to park it, > > we want more details -- so dump the engine state. > > > > References: https://bugs.freedesktop.org/show_bug.cgi?id=103479

[Intel-gfx] [PATCH v2] drm/drm_vma_manager.c: Remove useless goto statement

Commit db2395eccf08i ("drm: Convert drm_vma_manager to embedded interval-tree in drm_mm") removed a line in drm_vma_offset_add() function that makes checking the result of calling drm_mm_insert_node() and the goto call redundant. Rework the function (as suggested by Chris Wilson) to eliminate the

Re: [Intel-gfx] [PATCH] drm/i915: Re-enable fastboot by default

On Wed, Nov 01, 2017 at 03:53:25PM +0100, Maarten Lankhorst wrote: > This fix was originally reverted because it left a chromebook pixel > black, and no immediate fix was available. This has been fixed in the > meantime. > > Rather than trying to remove the parameter, set it to default to true >

Re: [Intel-gfx] [PATCH 6/7] drm/drivers: drop redundant drm_edid_to_eld() calls

On Wed, Nov 01, 2017 at 04:21:02PM +0200, Jani Nikula wrote: > diff --git a/drivers/gpu/drm/nouveau/nv50_display.c > b/drivers/gpu/drm/nouveau/nv50_display.c > index e4751f92b342..e0a190a0f029 100644 > --- a/drivers/gpu/drm/nouveau/nv50_display.c > +++ b/drivers/gpu/drm/nouveau/nv50_display.c >

[Intel-gfx] [PATCH] drm/atomic: Try to preserve the crtc enabled state in drm_atomic_remove_fb, v2.

This introduces a slight behavioral change to rmfb. Instead of disabling a crtc when the primary plane is disabled, we try to preserve it. Apart from old versions of the vmwgfx xorg driver, there is nothing depending on rmfb disabling a crtc. Vmwgfx' and simple kms helper atomic implementation

Re: [Intel-gfx] [PATCH 0/7] drm/edid and drivers: ELD refactoring

On Wed, Nov 01, 2017 at 04:20:56PM +0200, Jani Nikula wrote: > We were recently bitten by drm_edid_to_eld() clearing the connector > type, and us failing to set it back for DP. Here's a few ELD related > patches to try to unify ELD handling and make it a bit simpler for > drivers to get it right.

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: Check that the breadcrumb wasn't disarmed automatically before parking

== Series Details == Series: drm/i915: Check that the breadcrumb wasn't disarmed automatically before parking URL : https://patchwork.freedesktop.org/series/32903/ State : failure == Summary == Series 32903 revision 1 was fully merged or fully failed: no git log == Logs == For more details

[Intel-gfx] [PATCH] drm/i915: Re-enable fastboot by default

This fix was originally reverted because it left a chromebook pixel black, and no immediate fix was available. This has been fixed in the meantime. Rather than trying to remove the parameter, set it to default to true for now, so we can always back out if required. Signed-off-by: Maarten

Re: [Intel-gfx] [PATCH v2] drm/drm_vma_manager.c: Remove useless goto statement

Quoting Liviu Dudau (2017-11-01 14:44:58) > Commit db2395eccf08i ("drm: Convert drm_vma_manager to embedded > interval-tree in drm_mm") removed a line in drm_vma_offset_add() function that > makes checking the result of calling drm_mm_insert_node() and the goto > call redundant. Rework the

Re: [Intel-gfx] [PATCH v3] drm/i915: Remove unsafe i915.enable_rc6

On 17-11-01 14:07:28, Joonas Lahtinen wrote: On Mon, 2017-10-30 at 10:48 -0700, Rodrigo Vivi wrote: On Mon, Oct 30, 2017 at 01:00:51PM +, David Weinehall wrote: > On Fri, Oct 27, 2017 at 01:57:09PM -0700, Daniele Ceraolo Spurio wrote: > > > > > > On 26/10/17 03:32, Chris Wilson wrote: > > >

Re: [Intel-gfx] [PATCH] drm/i915/guc: Split GuC firmware xfer function into clear steps

On 11/1/2017 7:54 PM, Michal Wajdeczko wrote: On Mon, 30 Oct 2017 15:00:52 +0100, Sagar Arun Kamble wrote: On 10/27/2017 10:45 PM, Michal Wajdeczko wrote: Transfer of GuC firmware requires few steps that currently are implemented in two large functions. Split

Re: [Intel-gfx] [PATCH 2/2] drm/i915: Warn in debug builds of incorrect usages of ptr_pack_bits

Quoting Tvrtko Ursulin (2017-10-31 10:23:26) > From: Tvrtko Ursulin > > GEM_BUG_ON if the packed bits do not fit into the specified width. > > Signed-off-by: Tvrtko Ursulin Reviewed-by: Chris Wilson -Chris

Re: [Intel-gfx] [PATCH 1/2] drm/i915: Reject unknown syncobj flags

Quoting Tvrtko Ursulin (2017-10-31 10:23:25) > From: Tvrtko Ursulin > > We have to reject unknown flags for uAPI considerations, and also > because the curent implementation limits their i915 storage space > to two bits. > > v2: (Chris Wilson) > * Fix fail in ABI

Re: [Intel-gfx] [PATCH] drm/i915/guc: Split GuC firmware xfer function into clear steps

On Mon, 30 Oct 2017 15:00:52 +0100, Sagar Arun Kamble wrote: On 10/27/2017 10:45 PM, Michal Wajdeczko wrote: Transfer of GuC firmware requires few steps that currently are implemented in two large functions. Split this code into smaller functions to make these

Re: [Intel-gfx] [PATCH i-g-t] kms_atomic_transition: Add subtest time limit/randomize plane, pipe combinations

Op 01-11-17 om 13:55 schreef Imre Deak: > On Wed, Nov 01, 2017 at 12:32:37PM +0100, Maarten Lankhorst wrote: >> Op 31-10-17 om 14:44 schreef Imre Deak: >>> Doing modeset on internal panels may have a considerable overhead due to >>> the panel specific power sequencing delays. To avoid long test

[Intel-gfx] [PATCH 4/7] drm/edid: abstract connector ELD clearing

Preparation for future work. No functional changes. Signed-off-by: Jani Nikula --- drivers/gpu/drm/drm_edid.c | 21 + 1 file changed, 13 insertions(+), 8 deletions(-) diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c index

[Intel-gfx] [PATCH 6/7] drm/drivers: drop redundant drm_edid_to_eld() calls

drm_add_edid_modes() now fills in the ELD automatically, so the calls to drm_edid_to_eld() are redundant. Remove them. All the other places are obvious, but nv50 has detached drm_edid_to_eld() from the drm_add_edid_modes() call. Cc: Alex Deucher Cc: Christian König

[Intel-gfx] [PATCH 7/7] drm/edid: make drm_edid_to_eld() static

This is no longer needed outside of drm_edid.c. Signed-off-by: Jani Nikula --- drivers/gpu/drm/drm_edid.c | 5 ++--- include/drm/drm_edid.h | 1 - include/drm/drm_modeset_helper_vtables.h | 3 --- 3 files changed, 2 insertions(+), 7

[Intel-gfx] [PATCH 5/7] drm/edid: build ELD in drm_add_edid_modes()

Call drm_edid_to_eld() from drm_add_edid_modes() to fill in the ELD automatically. There's no harm in doing this for connectors that do not support audio. Signed-off-by: Jani Nikula --- drivers/gpu/drm/drm_edid.c | 8 ++-- 1 file changed, 6 insertions(+), 2

[Intel-gfx] [PATCH 3/7] drm/i915: remove redundant ELD connector type update

drm_edid_to_eld() now sets ELD connector type, remove the redundant update. Signed-off-by: Jani Nikula --- drivers/gpu/drm/i915/intel_modes.c | 17 - 1 file changed, 17 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_modes.c

[Intel-gfx] [PATCH 2/7] drm/edid: set ELD connector type in drm_edid_to_eld()

Since drm_edid_to_eld() knows the connector type, we can set the type in ELD while at it. Most connectors this gets called on are not DP encoders, and with the HDMI type being 0, this does not change behaviour for non-DP. For i915 having this in place earlier would have saved a considerable

[Intel-gfx] [PATCH 0/7] drm/edid and drivers: ELD refactoring

We were recently bitten by drm_edid_to_eld() clearing the connector type, and us failing to set it back for DP. Here's a few ELD related patches to try to unify ELD handling and make it a bit simpler for drivers to get it right. Apologies for the massive Cc list; it's the maintainers of all

[Intel-gfx] [PATCH 1/7] drm/edid: use macros for ELD offsets and values

We have the macros, use them. No functional changes. Signed-off-by: Jani Nikula --- drivers/gpu/drm/drm_edid.c | 27 ++- 1 file changed, 14 insertions(+), 13 deletions(-) diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c index

Re: [Intel-gfx] [PATCH] drm: Require __GFP_NOFAIL for the legacy drm_modeset_lock_all

Quoting Daniel Vetter (2017-10-31 16:38:26) > On Tue, Oct 31, 2017 at 03:28:01PM +0200, Ville Syrjälä wrote: > > On Tue, Oct 31, 2017 at 11:55:35AM +, Chris Wilson wrote: > > > To acquire all modeset locks requires a ww_ctx to be allocated. As this > > > is the legacy path and the allocation

Re: [Intel-gfx] [PATCH v6] drm/i915/guc: Add support for reset engine using GuC commands

Quoting Michel Thierry (2017-10-31 22:53:09) > This patch adds per engine reset and recovery (TDR) support when GuC is > used to submit workloads to GPU. > > In the case of i915 directly submission to ELSP, driver manages hang > detection, recovery and resubmission. With GuC submission these

Re: [Intel-gfx] [PATCH] drm/i915: Check that the breadcrumb wasn't disarmed automatically before parking

Quoting Joonas Lahtinen (2017-11-01 13:38:19) > On Tue, 2017-10-31 at 12:22 +, Chris Wilson wrote: > > We will disarm the breadcrumb interrupt if we see a user interrupt > > whilst no one is waiting. This may race with the call to > > intel_engine_disarm_breadcrumbs() triggering an assert that

Re: [Intel-gfx] [PATCH 1/2] drm/i915/guc: Add GuC Load time to dmesg log.

Quoting David Weinehall (2017-11-01 13:38:48) > On Tue, Oct 31, 2017 at 05:11:20PM -0700, Anusha Srivatsa wrote: > > Calculate the time that GuC takes to load using > > jiffies. This information could be very useful in > > determining if GuC is taking unreasonably long time > > to load in a

Re: [Intel-gfx] [resend] drm/i915: Check incoming alignment for unfenced buffers (on i915gm)

Quoting Joonas Lahtinen (2017-11-01 13:17:11) > On Tue, 2017-10-31 at 10:36 +, Chris Wilson wrote: > > In case the object has changed tiling between calls to execbuf, we need > > to check if the existing offset inside the GTT matches the new tiling > > constraint. We even need to do this for

Re: [Intel-gfx] [PATCH 1/2] drm/i915/guc: Add GuC Load time to dmesg log.

On Tue, Oct 31, 2017 at 05:11:20PM -0700, Anusha Srivatsa wrote: > Calculate the time that GuC takes to load using > jiffies. This information could be very useful in > determining if GuC is taking unreasonably long time > to load in a certain platforms. > > v2: Calculate time before logs are

Re: [Intel-gfx] [PATCH] drm/i915: Check that the breadcrumb wasn't disarmed automatically before parking

On Tue, 2017-10-31 at 12:22 +, Chris Wilson wrote: > We will disarm the breadcrumb interrupt if we see a user interrupt > whilst no one is waiting. This may race with the call to > intel_engine_disarm_breadcrumbs() triggering an assert that we aren't > trying to do the same job twice. Prevent

Re: [Intel-gfx] [PATCH 2/2] drm/i915/huc: Add HuC Load time to dmesg log.

On Wed, 01 Nov 2017 01:11:21 +0100, Anusha Srivatsa wrote: This patch uses jiffies to calculate the huc ^^^ ^^^ Please update commit message to match final change and use correct name for HuC (s/huc/HuC) load time.This

Re: [Intel-gfx] [PATCH 1/2] drm/i915/guc: Add GuC Load time to dmesg log.

Quoting Michal Wajdeczko (2017-11-01 13:14:33) > On Wed, 01 Nov 2017 01:11:20 +0100, Anusha Srivatsa > > @@ -172,13 +174,18 @@ static int guc_ucode_xfer_dma(struct > > drm_i915_private *dev_priv, > >*/ > > ret = wait_for(guc_ucode_response(dev_priv, ), 100); > > + load_time =

Re: [Intel-gfx] [resend] drm/i915: Check incoming alignment for unfenced buffers (on i915gm)

On Tue, 2017-10-31 at 10:36 +, Chris Wilson wrote: > In case the object has changed tiling between calls to execbuf, we need > to check if the existing offset inside the GTT matches the new tiling > constraint. We even need to do this for "unfenced" tiled objects, where > the 3D commands use

  1   2   >